httpbis minutes - ietf84 ======================== Session One - Tuesday --------------------- ### agenda bashing None ### httpbis -20 changes no comments.. ok to close tickets ### http/1.1 status mnot: target wglc p 1+2 by end of august masinter: why not now mnot: go read parts 1 and 2 everyone.. 4 week lc window lear: are you publicizing we are going to lc? (mnot w3c is aware, and this is WGlc) ### p1+p2 issues link idempotent - mark suggests unknown type.. roy says they are idempotent.. then a bunch of off mic conversation ticket 22 - roy: will resolve soon. mnot: unsure if it generic or etag specific.. rajeev becker: ws exists where etag reflects the state of the object not the state of the response roy: etag will never reference content ticket 364 - allow blank idempotent registry value - no discussion #### wglc issues in p4 through p7 effectively done except for editorial review no discussion #### http 2.0 authentication EOI summary review of 6 proposals mnot: not a lot of interest in any of them.. particularly with security AD and browser implementaitons.. lack of consensus. that means tieing this work to http/2 is risky. still impt to do this work. passwords cited as a specific problem. ad proposal take this set of drafts and use as input into new wg in security area perhaps for experimental rfcs. chair says the group owns http at its core and needs to stay vital, interoperational and secure and crossing the streams is a risk for core. jeff hodges: if we are doing http/2 what about allowing a hook for a blob to be defined later as an auth mechanism mnot: extensions to http/* don't need to be in the core. apps area wg? yoav: not sure apps wg drives browser adoption in the same way httpbis does mnot: not sure that if httpbis does something it means it gets implemented paul leach: if it is cleanly definable as an extension it should not be core.. but auth is not obviously clean. suggest this group makes sure it is possible to cleanly define extensions for authentication. p7 for http/2.0 paul hoffman: idea of not doing these here is fine. security people aren't that interested in transport portions of http/2. p7 bis? proposals applicable to http/1 and 2 oiwa: supports a framework in http/2 to tie authentication into protocol.. mark says semantically hard to make that http/1 compat wes hardaker: concerned that protocol won't support necessary mechanisms for security needs - mid stream reaut is an example jeff hodges: shares wes's concern ekr: one difficulty is that the alleged problem is unclear - shown by diversity of proposals. a number of the proposals don't meet any real needs roy: we tried to do this in 1994. security ad was supposed to take responsibility for that at that time. Maybe this belongs in appsarea instead of security, even if not httpbis roberto: world has realized that http is impt - motivations for doing this work have changed roy: in apps area - yes.. security maybe not ekr: web form is better ui.. fancy crypto does not add value.. http protocols don't elp with ui modalities leif jpnasson: everyone doesn't want the same thing.. webservice may want something different ekr: client certs keep failing to get market uptake oiwa: agrees there is a user interface issue.. comments or improvements on http auth extension draft (which trying to solve this) welcome lear: ui is crucial issue.. sad list has article on survey of all mechanisms in the field that is a good input mnot: we've discussed this a long time in the ietf and I haven't yet seen anything that convinces me we'll succeed. deserves experimental. w3c (and others) may also play a role here ### Tim Bray - 451 mnot: initally dismissive as a feel good activity using a constrained resource (status code). however, tomas roesseler mentioned a use case of web hosts making dmca takedowns could enable spidering/automatic/tracking of that kind of action barry hatless: what do you expect clients to do differently with 451 than 4xx? bray: browsers would have different default text stpeter] localization is hard [mnot: http has content negotiation hoffman: says there is a strong machine readable reason for doing this beyond end user ui alissa cooper: argument that ietf validates censorship isn't valid,more reflection of reality eric ??: how to differentiate between unavail to everyone vs unavail to _you_ mnot: that messes with cache behavior ???: geographic restrictions might be a use case lear: govts would take the view that the ietf is taking a position opposite to their own policies. also - is there a way this can be gamed? masinter: not fine grained enough.. probably shouldn't be done. governance can include regulatory activity.. defining when it applies is not something the IETF should be involved in bray: legal demand is clear mnot: what does 451 with same content as 200 mean? alyssa: legal demand is good line roberto peon: like the idea - concerned about secondary effects of misuse barry: extensible response body definition for a code so we don't need to burn a code for each use case wes hardaker: does this help the end user? yes! forget the misues ian fette: status code exhaustion not a serious problem mnot: 410 gone lack of adoption is concerning. link relations might be applicable. hum - is this worth pursuing (i.e. further discussion) and should we stop (options 1 and 2) - received very similar support Session Two - Wednesday ----------------------- Where we are: last time we agreed to solicit for proposals, SPDY, S+M, Network-Friendly Upgrade came in. Today, we are here to discuss and work out how to move forward. But before that, a sanity check: ws-* seemed like a good idea at the time; pipelining is getting deployment We have a huge investment in things as they are; there are also opportunity costs. Mark is comfortable now, though he has gone back and forth on this. He believes that with these ideas and the current state, he is comfortable with the 2.0 work going forward now. Larry Masinter: I think looking at the future of HTTP 2.0 is a great idea (the charter may not, but we're not discussing that now) Discussion of expressions of interest, then charter drafting is today's agenda. Reminder: all decisions are ratified on the list. Charter draft must be ratified by the IESG. Mark believes that there is clear consensus that the basis of our approach should substantially be draft-mbelshe-httpbis-spdy Question to be how to structure it as the basis. just SPDY; pick-and-choose, start with HTTPbis p1; SPDY with instructions/caveats/inputs From Mark's standpoint: he does not believe we should start from a clean slate. We don't need to have an incredibly restrictive charter—but the consensus should happen in the working group, not in the charter bashes His favorite: SPDY with instructions/caveats/inputs Any other thoughts? (Larry's opinion is solicited by the chair) Larry: starting with a starting point without knowing what you are optimizing and for whom is procedurally a mistake. Larry: I'm happy with the process you've outlined, but the starting point is not clear: performance, reliability, privacy? For some of these there is not enough to make a choice. Mark: if we had more data, would we make a different choice? Larry: possibly, but not clear that the guidelines are well formed. Larry: example: sniffing; can we turn it off for 2.0 Sean Turner: Maybe on of the things we can do is publish SPDY as an Informational, to get it out as a stable spec. Mark: I think SPDY is still evolving. Ian: No objection, but don't get what publishing SPDY would get you. People have access to SPDY if they want to implement. How does it help get us toward HTTP 2.0. Better to focus on what needs work, areas that we need to pay attention to. Pete Resnick, covering his dot: Agrees with Ian; publishing as informational is just delaying. Pete: Chair has two options: start with a new doc and take suggestion; start with a doc and take objections/diffs. Pete: Not seeing why the second is a concern. Pete: don't see why we shouldn't start with a base spec. Mark: I'm happy to start with a base document, adding incrementally and pulling from other documents. SPDY seems like it is hitting a lot of the right issues. The end document may look a lot different, but that's expected. Eliot Lear: he has a mixed opinion. Eliot: He would like to start with a description of the problems/goals. Eliot: aim spdy at those goals. (discussion of encryption deferred) Next phase of this is the charter, concerns may be addressed there. Roy Fielding: it would be good to work on SPDY as SPDY, as a mechanism for tunneling HTTP through to account based services; it is very good at that. Roy: I think it is a mistake to design things to be generic from the start; HTTP did that and it has warts. If we want to make SPDY that ugly, we can, but not sure why we would want that. Roy: would be better to have it focused on its use case; if other people want to start different efforts, those could be valuable to. SPDY could be a standard on its own, not as HTTP 2.0. Roberto: The idea behind what SPDY was: changes wire representation, but leaves everything else as it was for HTTP. That has had some benefit. Roberto: I believe what we are doing here is HTTP 2.0—same semantics Patrick McManus: I have implemented off many of these, and my opinion is that it doesn't really matter what we start with. There are advantages for starting as HTTPbis ; starting there as the scope may have the least confusion. Mark: I think we should focus on what is p1, not revising in p2 or p3 (is in p1). Mark: Roy reminded me of a discussion with Barry the other day in which it is good to have clarity on what the expectation. Mark: is our thinking that http 1.1 and http 2.0 will coexist indefinitely, that 2.0 will cover the full suite of use cases covered in http 1.1? Mark: there may be many things that we do not cover (interception proxies, backend systems). Mark: major orphaned use cases should be avoided. We should eventually (20 years) cover them all. Larry: I don't love interception proxies; people buy them and use them Mark: we will have a 5m conversation about interception proxies Ted: interception proxies are used because we don't offer an explicit way of solving the use case Larry: it should be a part of the charter then Ted: SPDY is nice as a starting point; it's nice to have that to frame the discussion. Ted: Not starting from a clean slate is important Ted: we'll make faster progress if we don't clean slate Mark: Ted reminded that we may need to take up other elements, like proxy.pac to get some elements of the work done. Salvatore: interception proxies are used in telephone networks a lot. Salvatore: having said that, we see some benefit from SPDY Sean Turner: starting at a blank slate will add a year to the process Salvatore: I sent out an expression of interest; he suggests pick and choose—picking mostly from SPDY Salvatore: even better, take the SPDY proposal and remove the controversial parts Mark: I see the difference between that and the SPDY with instructions as determining things before, versus determining as we go along. I think I'd rather we do it as we go. Larry: I'd rather start with the caveats and instructions than the starting point Mark: we agreed in Paris to start with a starting parting. Larry: okay Eliot: The encryption issue is an elephant in the room; this starting point may have an impact on this Sean Turner: okay so I'm convinced don't both publishing spdy on inf Mike Belshe: proxies don't have a strong issue with SPDY, they have one with TLS, but SPDY doesn't mandate TLS Mark: Agreed, the document does not mandate SPDY Rob Trace: encryption issue is a distraction; focus on multiplexing and let's get going Rajeev Bector: can we talk about the goal Mark: get consensus Mark: maintain deployability mark: modernized security, ensure it's no more difficult to deploy Mark: improve security Mark: maintain all of the existing actors Mike Belshe: we have the same question: does this replace all of HTTP 1.1? Mike Belshe: everything that runs over 1.1 should be able to run 2.0. But that doesn't mean everyone will change. Mike Belshe: There may be cases where you can't make improvement for every uses. Mark: yes, but I don't want to drop use cases because "they can use 1.1" Mike Belshe: there are cases that are hard (youtube) where it may not fit the use case. Ted Hardie> Mark: remind folks of your affiliation Mike: I have not worked at Google for a year. Gabriel Montegro: would still prefer from starting from a clean slate. If someone is asleep at the helm, you may not end up cutting things that actually are controversial. Add only as you need, rather than starting from really big and cutting down. He doesn't believe that works as well as starting only from what is justified and agreed upon. Ian Fette: I think we may be talking past each other. There likely are things in the SPDY spec. that we do not have consensus on. Ian Fette: If we start with "pick and choose", we could do a patchwork (which might not read well) from multiple drafts to create an input draft. Or we can start from one and mark different sections as needing discussion. That seems to get us to a working draft much faster. Rajeev: people who control their destiny are one user community; then there are user communities that depend on intermediaries. We need a balanced approach that covers all stakeholders. Sean Turner: it's in a WG draft by definition we don't have consensus on it Joe: I came up to agree with Ian, with the caveat that we must maintain backward compatibility with SPDY. As long as nobody is going to argue that. Joe: then, I am fine. Mark; that should be a given Joe: actually not; can be chartered other way Patrick: we will be actively pushing old versions of SPDY off the web; that's been clear during this phase. Mark: Just to clarify, backwards compatibility is a non-goal; will clarify in the charter. Leif: do we want to call consensus on that last point? Mark: will do so as part of charter discussion. Mark: now reviewing charter sent to the mailing list Adds a new work item for http 2.0, The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 as the definition of HTTP/1.1 and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP/1.1 * A document (or set of documents) that specifies HTTP/2.0, an improved binding of HTTP's semantics to an underlying transport. It is expected that HTTP/2.0 will: * Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP. * Not require multiple connections to a server to enable parallelism. * Require no more configuration or tuning than current HTTP deployments; preferably, less. * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields. * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2). * Clearly identify any new extensibility points and policy for their appropriate use. Joe Hildebrand: Do we want to add something about congestion control, as a motivator? Mark: sure. Mark: "improving the use of TCP, especially regarding congestion control" to be wordsmithed The resulting specification(s) are expected to be meet these goals for common existing deployments of HTTP; in particular, Web browsing (desktop and mobile), Web serving (at a variety of scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content Delivery Networks). Note that this does not include uses of HTTP where non-specified behaviours are relied upon (e.g., connection state such as timeouts or client affinity, and "interception" proxies); these uses may or may not be enabled by the final product. Explicitly out-of-scope items include: * Specifying the use of alternate transport protocols. Note that it is expected that the Working Group will define how the protocol is used with the TLS protocol. * Specifying new semantics for HTTP (whether specific to HTTP/2 or not). However, the Working Group may request a re-charter to start work on such items (during or after work on HTTP/2.0), provided there is consensus to do so, and it does not interfere with work on the "core" (both HTTP/1.x and HTTP/2.0). Mark: Possibly adding a specific "out of scope" for p2-p7 List of specific issues: Mandatory TLS Header Compression Upgrade/Handshake Server "push" Flow control Security properties Let's get out of the way the mandatory TLS issue Mark: we don't have consensus on this Mark: the current uses of spdy require the use of TLS Mark: discussing this with the authors and implementors, I think we may have a way around this Mark: if we take the approach that HTTPS URLs should work the same in the two versions, we're actually pretty close (modulo NPN) The issue is "http" not "https" URLs. Mark: a real negotiation may be needed, with "optimistic TLS" as a possibility This would block passive eavesdropping , but does not provide certificate-checking Mark: charter impact is to include negotiation mechanism, potential coordination with others, All* other discussion of topic out of scope Mark: how many people have read the "tussle" paper? Mark: it's a good explication of how these issues arise and might be resolved Larry: it was my impression was that the primary issue was a deployment issue Mark: some people have put that forth. Larry: I have heard it as significant issue. As stated, this would make deployment considerations out of scope. That's what this says to me. Mark: that's not the intent Larry: nowhere in the charter is there a mandate to document deployment considerations Mark: do you want to hear from Mike? Mike: of course deployment considerations are important. Even subtle things can be issues, so we understand this. Going over TLS is a deployment factor. Mike: there haven't be any ways to put new protocols over port 80. Even changes over TLS are hard. Mike: But it kind of doesn't matter from the protocol specification Jim Gettys: I think the primary motivation is fine. Jim: in some parts of the world, caching is a necessary thing; to the extent this hurts caching, this is an issue. Mark: One of my primary concerns is caching, but this still allows both configured and gateway proxies to cache. Interception proxies are not as useful, but that's not here. Yoav: NPN was not accepted by TLS Mark: don't want to discuss the politics of other groups. Yoav: don't see how that will work over port 80 Mark: doesn't say port 80 there. Rajeeve: The site owner can't control when clients negotiation. Mark: This gives both sides power Rajeev: there are three parties here: clients, servers, content owner Rajeev: this will be an impediment to deployment Mark: impediment to "optimistic" TLS Rajeev: yes Mark: optimistic TLS will not show as secure in browser chrome etc. ekr: as chair, note TLS still has not accepted this work, so building on it a bit worrying ekr: as individiual, this might be used to break existing connections that are TLS protected; negotiation is a good idea, but this might not be it. PHB: I don't like it when application layer protocols do a half-assed job of security. PHB: Why pick only one attack (passive attacker) and address only that? PHB: There is no web browser I'm aware of that doesn't have TLS today. PHB: those that don't have it have a different security model Mark: there is not a mandate here. PHB: if it is not mandatory, why is it called that? Mark: just slide title, that'a red herring PHB: Mandatory to implement? Mark: no PHB: head explodes Roberto: if we put a question mark in the title of the slide, it becomes accurate roberto: on the caching thing, yes we do need to consider caching. Even under the SPDY work, we have been thinking of this; have an id out. Patrick: I want to re-iterate that making explicit proxies a bigger part of this; there are value-added services possible there. Patrick: that's both for wpad and pac; we need to serve better, we're not trying to eliminate them Patrick: it would be my preference for TLS everyhwere; if there is an actual person there, there needs are paramount Patrick: but this is a workable way to move forward. Tim: more or less plus 1; this is a reasonable compromise Elliot Lear: let's be clear on what we're getting: only sniffing problem Elliot: I don't think that solves Mike's big problem—new feature. These things in the middle are the first things that need to negotiate Paul Leech: I applaud the attempt to get out of the conundrum Paul: but I dont' think this is enough; the standard attack is an active attack, and this handles only passive attacks. Mark: there has to be knowledge that this is trivial to overcome with active attacks. Mark: but this is a building block Hannes: For a long time, I've gotten the impression that it is really difficult to change HTTP Hannes: now, for some reason, this is not a problem anymore. How did that happen? Hannes: I don't see how that can work unless tunneled on top of TLS. Hannes: Now folks are saying that we are not mandating TLS, but that makes it hard to see a road to deployment. Mark: folks have made that assertion, but I think that is worth re-examining. There may be multiple ways to upgrade HTTP Stephen: echoing a bit of PHB's comments. If people are arguing for privacy, you're undermining your own argument; it's not providing that. Ian: Some of these arguments are following the fallacy of perfect security. Sean Turner: +1 to raising the bar Ian: often we are just raising the bar; the perfect can be the enemy of the good. Ian: as to TLS, does TLS solve the upgrade problem? Ian: in a perfect world, we could use ports, but that's not the world we live in. At the moment "virtual ports" over 443 is where we are Ian: that could ossify too, but that's what we have now. Hannes: even if you use existing ports, you run into trouble Hannes: are you planning to fold that concept into the design? how do you see the bigger picture? Ian: wrt origin-bound certs, etc, we don't know if it's deployable yet Ian: so let's not put that in the starting point. Ian: if it's useful and deployable, we'd bring it here. Mark: cut the line Mark: we'll find a way to upgrade to 2.0 Will/Google: clarification: one way to negotiate between client/server, "alternate-protocol" header will: hint to move to 443 w/ SPDY + NPN Will: if you want real security, use HTTPS Will: but doing http over SSL is reasonable (note: i didn't quite understand his point, obviously) Yutaka: we need to describe how protected/unprotected each of these mechanisms are Yutaka: ? Mark: self-signed certs would no longer set off all of the warning lights. Mark: that's more of a w3c issue. our job is to define a new mode of use for http roberto: s/optimistic/unauthenticated/ roberto: NPN-like, not NPN, but whatever TLS wg comes up with Ted: charter item for explicit negotiation. if we add something else later, we can add it to the negotiation along w/ these 3 Mark: we are really talking about negotiation, not mandating a specific TLS implementation Mark: now hum Two questions: who believes we should have language in our charter describing a negotiation mechanism (potentially encompassing choices beyond 1.1 and 2). Second: who believes we should not have such language in our charter. Larry: I'd like to have a deliverable on deployment and TLS Mark: I'm not against that, but many decisions would need to be made first. Elliot: I'd like a third choice "Even if the working group can agree on unauthenticated TLS, then we move forward". Mark: This is basically a "should we have a discussion on this"—everything is subject to the stuff working. Cullen: I didn't understand the humms; make them less fluffy, please? Mark shows the charter and suggests that the negotiation mechanism be discussed/addressed The definition of unauthenticate TLS with HTTP, along with a negotiation mechanism for it for HTTP URIs. Gabriel: I think the charter should have the negotiation mechanism, but the TLS method doesn't make sense to discuss here. Gabriel: this allows us to make use of those options. Mark: At the moment, there is a static binding between HTTP and HTTPS and their TLS state; we'd like to have more negotiation room. ekr: I don't mean to sound like boundary maintenance guy, but I will ekr: There's a number of things being discussed here: indicators to try TLS, new bindings, etc. ekr: I'm in favor of this work, but talking about it as a charter item is confusing, because it doesn't belong here. ekr: this should go into 2818bis. There's also impact in (inaudible) ekr: that said, the message to TLS that you want this done is received. Mike Belshe: are we still talking about mandatory TLS? Mike: we'd like to see that, but from the reality perspective, it may not happen here. Mike: but the proposal here is half-breed and it is going to have a lot of wholes. Sean Turner: and I think ekr agreed to work on 2818bis: https://www.ietf.org/mail-archive/web/tls/current/msg08844.html belshe: if we're not going to do mandatory tls, we don't have to talk about it mark: do you want this knob to tune? Mike: it's fine. ted: I was going to rise to say "keep the negotiation mechanism", even if we don't have a current thing to negotiate to. A better thing to negotiate to may arise…. Larry: When we talk about issues, we talk about problems to be solved. Larry: maybe we should do that, instead of talking about the proposal just given Larry: are we starting with SPDY as deployed or as documented? Roberto: as documented Mark: asks question about including this language in the charter. Hum in favor Hum against Mark calls strong hum for including in the charter. Mark: header compression—there has been discussion on the list. GZIP may not be a slam-dunk, but we can address on list; he adds a bullet for header compression as a bullet on the charter. Upgrade handshake has already been covered. Now, server push. Mark: we don't seem to have consensus that it should be part of the base protocol. He proposes we continue to discuss and get further data before putting it into the charter. It may be a feature at risk. Joe Hildebrand: as long as there is a feature negotiation, this is fine. Mark: there are ways to do this: we can take it out later, put it in later, mark it as feature at risk. Roberto: we're not talking about a negotiation mechanism at this point, we're talking about getting data about the mechanisms that might be needed to meet that need. Roy: header compression/re-encoding/tokenization as alternate ways of handling that should be in the charter Gabriel: Server push could be client pull then Mark: isn't that get? Gabriel: but this can change? Mark: yes, but listing the SPDY feature here means we will talk about the need that feature meets. Mark: flow control will be discussed Jim: part of how the internet has gotten into this terrible mess is that HTTP was of the few things allowed to get through firewalls. People behind broken things shoved it over HTTP to get it through. Jim: it is vital, in my view, that this WG work with transport folks as much as possible Mark: can we address that by adding transport to the Coordination list? Jim: yes Jim: this needs to be a data driven approach Jim: things have to be validated in a serious way Jim: last comment: It's been really fascinating to watch content-centric networking. There could be interesting cross-fertilization (not a charter comment, just a pointer) Roberto: I talk to Matt about these issues and certain level of transport interaction will be an important part of coordination. On data-driven, it is difficult to say what the datum of interest is. There still may be interpretation. Gabriel: +1 for coordination with transport Gabriel: multiplexing should not be taken lightly. It should be done once, not twice. Gabriel; e.g. websockets should be a customer of this work, not re-invent. Gabriel: come to hybi to discuss Ben: there is one issue nagging away at me: debuggability. Ben: there are nice aspects to HTTP 1.1 for debugging; losing a lot of that as we go forward. We should think of it conciously. Ido Safruti: push certificates or dns-related data? That could be addressed Mark: don't see a need to add that to the charter as an issue; it will get discussed Roy: it seems odd that we don't have Head of Line blocking on there Mark: okay, sure; Roy: this is part of flow control Jim: SCTP can really solve that in the long run. That maps well to transport. This is part of why talking to transport important. Mark: The charter will go to the list. Larry: note that coordination items will not be in expressed in terms of changes to that document. Mark: will massage this text, removing "all" Now, "Security Properties" document. This must be finished before going to IETF LC on HTTPbis. Mark: I need editors Volunteers needed—it needs to move forward, and it is dead now. Related efforts: protocol lab? Test suite? Might include a content corpus I'd note that if HTTP over TLS is defined by the security area, perhaps they should be responsible for the security analysis also. but if it's already in the charter, it's too late, i suppose. Will get discussed as part of the process; will not get into the charter, but happy to help with setting it up. Mark: might end with this on github. Finally, Looking Ahead Review of schedule September for first draft of HTTP 2.0, presuming charter approved. Lucy reminds that we never did the "pick among" bit Mark asks for objections to putting SPDY into the XXX slot on the charter? Elliot: no objections, but concern that we remain conservative in our approach. Elliot: want to flag that. Elliot: need strong chair and area director control Mark: there will be change in control. Cullen: that wasn't the issue Cullen: the issue is whether assuming it currently has consensus and changes need consensus or whether it is the set of words for consensus decision Mark: Explains the way it will work Cullen: thumbs up No further objections Mark: this group will remain the locus of HTTP work in the IETF, so it may take on other work if required. Mark: These may be HTTP1.1 Mark: This is because some HTTP work is going on in APPSAREA WG, but the locus of expertise is here. Barry: Assuming it makes it in the charter, if it becomes a flood, it will get pulled back out. Ben: I'm okay with this, but it might be useful to add a sentence Ben: Clarifying the process where the first port of call will be Barry: I don't need to put it in the charter; if it goes to APPSAREAWG, they will send it here Mark: the schedule is aspiration, but it will go to the list.