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

[Eric Rescorla <[e-mail]>]

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
> > >>>
> > >
> > >
> >
>
>