Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)

[Eric Rescorla <[e-mail]>]

I don't think there is anything new to say here, other than that I am not
in favor of these changes to the charter, which I believe would be unwise.

-Ekr


On Wed, Feb 12, 2020 at 7:29 AM Mirja Kuehlewind <[e-mail]>
wrote:

> Yes, that is a decision by the IESG so we should not baked it into the
> WebTransport charter at this point of time. What I’m requesting is to
> rather remove the following sentence from the proposed new charter text:
>
> "The WebTransport working group may define extensions to these protocols,
> but any working group last call defining such extensions shall also be sent
> to the mailing list of the respective working group.”
>
> And then the following sentence should probably also be change to remove
> the word “core” or even replace “changes to these core protocols” with
> “extension to the respective protocols”:
>
> "In particular, any changes to these core protocols shall be discussed in
> their respective working groups.”
>
> I think it is actually true for all three protocols (QUIC, HTTP, and TLS)
> that changes to the _core_ protocol must be done in the respectively
> working group.
>
> Mirja
>
>
>
> > On 12. Feb 2020, at 16:21, Eric Rescorla <[e-mail]> wrote:
> >
> > Well, I don't really agree that this needs to be a live issue, but as
> you insist:
> > Extensions to QUIC should be possible in WGs across the IETF, with
> proper coordination with the QUIC WG. This isn't really a decision for the
> QUIC WG, but rather for the IESG, In any case, this is precisely what is
> contemplated by the current draft. If you think this needs to go in some
> charter text, then it should go there now.
> >
> > -Ekr
> >
> >
> > On Wed, Feb 12, 2020 at 7:17 AM Mirja Kuehlewind <[e-mail]>
> wrote:
> >
> >
> > > On 12. Feb 2020, at 16:13, Eric Rescorla <[e-mail]> wrote:
> > >
> > >
> > >
> > > On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind <[e-mail]>
> wrote:
> > > The whole point is that the QUIC protocol is not finished yet and the
> respective registry doesn’t exists yet.
> > >
> > > And WebTransport will have a normative dependency on QUIC and
> therefore will not be finished prior to that registry existing.
> >
> > But the charter will be finished before that and we need to decide now
> what to write in there. That’s what we are discussing.
> >
> > >
> > >
> > > All I’m saying that we should not bake process in the the webtransport
> charter that might restrict a future discuss we want to have in the QUIC
> group.
> > >
> > > What future discussion? As I said, the IANA considerations implicit
> decide this matter. Is someone arguing to change those to Standards Track?
> >
> > As Magnus wrote several times in the resented re-chartering discussion:
> >
> > "A reason for the two step rechartering is that I think we will need to
> have a
> > serious discussion of how to work on v2 and extensions more generally. I
> think
> > going into these details now is premature. But we will need to come back
> to this
> > later.”
> >
> > Mirja
> >
> >
> >
> > >
> > > -Ekr
> > >
> > >
> > >
> > > > On 12. Feb 2020, at 15:26, Barry Leiba <[e-mail]>
> wrote:
> > > >
> > > > I have to agree with EKR here: I'm not aware of any other protocols
> > > > that define Specification Required extension mechanisms where we say
> > > > that the original working group should be in control of the
> > > > extensions.  I wouldn't want to start it here.
> > > >
> > > > The ADs will designate experts to review the extension
> specifications,
> > > > and that is the mechanism for the working group to have its say in
> the
> > > > extensions.  And in this case, the charter explicitly says that
> > > > webtrans will coordinate with quic.  I see no reason to be more
> > > > specific here, nor to require more.
> > > >
> > > > Barry
> > > >
> > > > On Wed, Feb 12, 2020 at 9:15 AM Eric Rescorla <[e-mail]> wrote:
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind <
> [e-mail]> wrote:
> > > >>>
> > > >>> Hi Ekr,
> > > >>>
> > > >>> Yes, it is specification required, however, if we decide to
> pushing an RFC then we need to decide where this work in the IETF can be
> don best.
> > > >>
> > > >>
> > > >> This seems like a very odd position. As soon as the QUIC RFC is
> published, anyone else in the world can assign new QUIC code points, but
> inside the IETF, until there;s some discussion in the QUIC there won't be
> any process other than asking the QUIC WG?
> > > >>
> > > >>
> > > >>>
> > > >>> All I’m saying that the process how and where to define QUIC
> extensions in the IETF needs to be decided by the QUIC group and a future
> QUIC charter and not by the charter of any other working group.
> > > >>
> > > >>
> > > >> I don't understand what process you think requires this. There was
> never any such formal discussion in the TLS WG AFAIK. In my experience when
> some WG wants to define a TLS extension there's a brief discussion between
> the chairs and ADs about whether it's orthogonal enough to do separately.
> It's not in the TLS charter, for instance, AFAICT.
> > > >>
> > > >> -Ekr
> > > >>
> > > >>> Again that doesn’t mean that in future it will not be possible for
> other groups to define extension but we need to have that discussion first.
> > > >>>
> > > >>> Mirja
> > > >>>
> > > >>>
> > > >>>
> > > >>>> On 11. Feb 2020, at 22:34, Eric Rescorla <[e-mail]> wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja Kühlewind (IETF)" <
> [e-mail]> wrote:
> > > >>>> Hi David,
> > > >>>>
> > > >>>> I didn’t say that other groups cannot define extension. I did say
> that it’s the decision of the working group that maintains the protocol how
> to handle that and for Quic we didn’t have had that discussion yet.
> > > >>>>
> > > >>>> Examples for groups that explicitly define process for extending
> the protocol in their charter are dhc and 6man. As you can see different
> groups/protocols have different process and as we didn’t define anything
> yet for Quic, the working assumption for now should be that all extension
> work will be fine in the Quic group.
> > > >>>>
> > > >>>> Well, the IANA considerations for QUIC transport seem fairly
> clear:
> > > >>>>
> > > >>>>
> https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4
> > > >>>>
> > > >>>> Most of the code points are assigned via Specification Required,
> so I don't see why you would infer that all extensions happen within the
> QUIC WG..
> > > >>>>
> > > >>>> -Ekr
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> Mirja
> > > >>>>
> > > >>>>
> > > >>>>> Am 11.02.2020 um 21:47 schrieb David Schinazi <
> [e-mail]>:
> > > >>>>>
> > > >>>>> 
> > > >>>>> Hi Mirja,
> > > >>>>>
> > > >>>>> I'm not sure I agree with your interpretation.. The fact that a
> WG is
> > > >>>>> responsible for a protocol does not mean that other working
> groups
> > > >>>>> cannot write extensions to that protocol.
> > > >>>>>
> > > >>>>> For example, the QUIC WG is defining the
> quic_transport_parameters
> > > >>>>> TLS extension. That extension is not defined in the TLS WG.
> > > >>>>> https://tools.ietf.org/html/draft-ietf-quic-tls-25#section-8.2
> > > >>>>>
> > > >>>>> Similarly, the ACME WG is defining the Cert-Not-Before HTTP
> > > >>>>> header, not the HTTP WG.
> > > >>>>> https://tools.ietf.org/html/draft-ietf-acme-star-11#section-6.7
> > > >>>>>
> > > >>>>> Additionally, MPTCP is an extension to TCP that was not
> > > >>>>> defined in the TCPM WG. The list goes on.
> > > >>>>>
> > > >>>>> We don't yet have examples for QUIC as the QUIC IANA
> > > >>>>> registries haven't been created yet, but I don't see why QUIC
> > > >>>>> would be different from TLS, HTTP, or TCP.
> > > >>>>>
> > > >>>>> David
> > > >>>>>
> > > >>>>>
> > > >>>>> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind <
> [e-mail]> wrote:
> > > >>>>> Hi David,
> > > >>>>>
> > > >>>>> One more comment below.
> > > >>>>>
> > > >>>>>> On 6. Feb 2020, at 14:46, David Schinazi <
> [e-mail]> wrote:
> > > >>>>>>
> > > >>>>>> Hi Magnus,
> > > >>>>>>
> > > >>>>>> I realized that some of our earlier replies were accidentally
> not sent to
> > > >>>>>> the IESG list, for which I apologize.
> > > >>>>>>
> > > >>>>>> To summarize that discussion:
> > > >>>>>>
> > > >>>>>> - It is not our intention to build a new transport protocol
> here.
> > > >>>>>> The WEBTRANS WG would build application protocols that
> > > >>>>>> run over QUIC, or TLS/TCP. This would ensure we benefit
> > > >>>>>> from their security and congestion control properties.
> > > >>>>>> Here is a PR to the charter that should clarify this:
> > > >>>>>>
> https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files
> > > >>>>>>
> > > >>>>>> - The WEBTRANS WG would not modify QUIC or HTTP.
> > > >>>>>> Any discussion of modifying those core protocols would
> > > >>>>>> happen in their existing respective working groups..
> > > >>>>>> However, discussion of extensions to these protocols could
> > > >>>>>> be allowed in this WG, as long as any document WGLC is
> > > >>>>>> also sent to the mailing list responsible for that protocol.
> > > >>>>>
> > > >>>>> I think this is not sufficient, at least not for QUIC. More
> discussion is needed in the QUIC group on this but currently I think the
> assumption should be that all extensions will be done within the QUIC
> group. So just sending a WGLC there is not sufficient.
> > > >>>>>
> > > >>>>> More generally deciding on processes for other protocols/groups
> in this charter is not appropriate. I’m not sure what the defined process
> is for HTTP and TLS but that should be specified in their charter and not
> here.
> > > >>>>>
> > > >>>>> For QUIC, I would like to rather see that extension or
> modification are out of scope for this group. Of course that doesn’t mean
> that this group cannot talk about any extension but as soon as the group
> thinks an extension is needed, it needs to go to the QUIC group and cannot
> just adapt anything within WebTransport.
> > > >>>>>
> > > >>>>> Please also double-check what the right process is for TLS and
> HTTP. I assume for TLS it's the same but for HTTP it might be different…?
> > > >>>>>
> > > >>>>> Mirja
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>
> > > >>>>>> Would that be an acceptable scope?
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>> David
> > > >>>>>>
> > > >>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev <
> [e-mail]> wrote:
> > > >>>>>> I believe most of those have been addressed in David's PR, so
> I'll try to reply
> > > >>>>>> primarily to those that I have something to add to..
> > > >>>>>>
> > > >>>>>> On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via
> Datatracker <noreply@ietf..org> wrote:
> > > >>>>>> Magnus Westerlund has entered the following ballot position for
> > > >>>>>> charter-ietf-webtrans-00-00: Block
> > > >>>>>>
> > > >>>>>> When responding, please keep the subject line intact and reply
> to all
> > > >>>>>> email addresses included in the To and CC lines. (Feel free to
> cut this
> > > >>>>>> introductory paragraph, however.)
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> The document, along with other ballot positions, can be found
> here:
> > > >>>>>> https://datatracker.ietf.org/doc/charter-ietf-webtrans/
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> ----------------------------------------------------------------------
> > > >>>>>> BLOCK:
> > > >>>>>>
> ----------------------------------------------------------------------
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> [snip]
> > > >>>>>>
> > > >>>>>> The group will also coordinate with related working groups
> within the IETF,
> > > >>>>>> such as QUIC and HTTPBIS, as appropriate.
> > > >>>>>>
> > > >>>>>> With the current state of QUIC developement and HTTP/3 mapping
> definition, i.e.
> > > >>>>>> still working on the initial version, I would like to have a
> more firm wording
> > > >>>>>> that the WebTrans WG will actually have to take any requests
> for extensions of
> > > >>>>>> HTTP/3 and QUIC to the relevant WG.
> > > >>>>>>
> > > >>>>>> While there are no extensions to QUIC among the proposed WG
> documents, some of
> > > >>>>>> the drafts do extend HTTP using custom SETTINGS parameters
> (which is the
> > > >>>>>> intended HTTP extensibility mechanism).  I've hitherto assumed
> that webtrans
> > > >>>>>> would work with HTTP experts in httpbis/quic to ensure that the
> proposed
> > > >>>>>> extensions are architecturally sound and follow best practices,
> but the main
> > > >>>>>> bulk of work would be done in the new working group itself.
> > > >>>>>>
> > > >>>>>>
> ----------------------------------------------------------------------
> > > >>>>>> COMMENT:
> > > >>>>>>
> ----------------------------------------------------------------------
> > > >>>>>>
> > > >>>>>> I also would appreciate if someone can clarify what stage of
> formality the
> > > >>>>>> Web-Transport API has been adopted in W3C and is being worked
> on. Trying to
> > > >>>>>> find anything about which group it belongs to on the W3C page
> didn't give me
> > > >>>>>> any information. All I found is that there have been a workshop
> on game
> > > >>>>>> communication where this was discussed and raised in some
> discussions.
> > > >>>>>>
> > > >>>>>> It's a WICG draft, which basically means no formal status..  We
> had a discussion
> > > >>>>>> session at TPAC last year, and I believe most people who'd be
> normally involved
> > > >>>>>> are aware of it, but my current understanding is that the
> editors of the W3C
> > > >>>>>> spec currently do not believe we have enough real-world
> implementation
> > > >>>>>> experience with the proposal to advance it further in the
> formal process.
> > > >>>>>>
> > > >>>>>> Having lived through the WebRTC / RTCWeb interactions it would
> good to know
> > > >>>>>> more how the interaction between the bodies are intended to
> work. Especially as
> > > >>>>>> changes to the API can have significant impact on what work
> needs to happen in
> > > >>>>>> the IETF.
> > > >>>>>>
> > > >>>>>> I mostly agree with Bernard here.  My plan was that the
> -overview doc would
> > > >>>>>> list all of the protocol requirements and API expectations,
> acting as
> > > >>>>>> integration point between W3C and IETF specs.
> > > >>>>>>
> > > >>>>>> The current API draft does not include any discussion of
> priority. However
> > > >>>>>> draft-vvv-webtrans-overview does mention priorities. As this
> API appears to
> > > >>>>>> support multiple parallel transmissions and transfers I think
> at a minimal a
> > > >>>>>> sender transport protocol scheduling or HTTP/3 priority  would
> be likely to be
> > > >>>>>> part of the work. I also have to ask if this is likely to
> attempted to be
> > > >>>>>> mapped also towards the network level, for example DSCPs? If
> any such work is
> > > >>>>>> expected and intended I think that needs to be raised.
> Otherwise I would assume
> > > >>>>>> that at most what this work will be to use the undefined APIs
> to HTTP/3 and
> > > >>>>>> QUIC to influence those protocol to perform stream priorities..
> > > >>>>>>
> > > >>>>>> This is mostly a gap in the API spec.  I've been meaning to
> write this up
> > > >>>>>> further, but there's a lot of text to write.
> > > >>>>>>
> > > >>>>>> Before I elaborate further, I would like to point out that
> there are two types
> > > >>>>>> of priorities here, and those are often confused:
> > > >>>>>> (1) Priorities that the application indicates to the transport
> layer for the
> > > >>>>>>    purpose of scheduling writes.
> > > >>>>>> (2) Priorities that are communicated to the peer on the wire as
> a hint....
> > > >>>>>>
> > > >>>>>> Most of the discussion in HTTPBIS and QUIC WGs was about #2.  I
> don't believe
> > > >>>>>> any of the proposed drafts cover that topic, and I'd rather
> wait for
> > > >>>>>> quic/httpbis to come up with a mechanism first.
> > > >>>>>>
> > > >>>>>> The priorities mentioned in -overview are of the #1 kind.
> Section 2.3 of
> > > >>>>>> draft-ietf-quic-transport-25 explicitly encourages
> implementations (that would
> > > >>>>>> include the proposed Web APIs) to provide those:
> > > >>>>>>
> > > >>>>>> """
> > > >>>>>> [QUIC] relies on receiving priority information from the
> application that uses
> > > >>>>>> QUIC.
> > > >>>>>>
> > > >>>>>> A QUIC implementation SHOULD provide ways in which an
> application can indicate
> > > >>>>>> the relative priority of streams. When deciding which streams
> to dedicate
> > > >>>>>> resources to, the implementation SHOULD use the information
> provided by the
> > > >>>>>> application.
> > > >>>>>> """
> > > >>>>>>
> > > >>>>>> Besides, I don't believe we can avoid defining a write
> scheduling mechanism in
> > > >>>>>> the API.  QUIC itself treats it as an implementation detail,
> but Web APIs
> > > >>>>>> generally try really hard to avoid implementation-defined
> behavior.  If
> > > >>>>>> every browser had a completely different write scheduling
> approach,
> > > >>>>>> that could make the job of writing performant cross-browser
> code really
> > > >>>>>> difficult.
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>>  Victor.
> > > >>>>>> --
> > > >>>>>> Webtransport mailing list
> > > >>>>>> [e-mail]
> > > >>>>>> https://www.ietf.org/mailman/listinfo/webtransport
> > > >>>>>
> > > >>>> --
> > > >>>> Webtransport mailing list
> > > >>>> [e-mail]
> > > >>>> https://www.ietf.org/mailman/listinfo/webtransport
> > > >>>
> > > >
> > > >
> > >
> >
> > --
> > Webtransport mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/webtransport
>
>