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

[Eric Rescorla <[e-mail]>]

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.


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?

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