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

[David Schinazi <[e-mail]>]

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

Your examples don't prevent other working groups from defining extensions.
The 6man charter is very clear on this point: it gives 6man the option to
provide input on IPv6 extensions defined in other WGs, it does not prevent
other WGs from defining IPv6 extensions. RPL (RFC 6550) is an example of
the ROLL WG defining an IPv6 extension.
RFC 5986 is an example of the GEOPRIV WG defining a DHCP option. On this
specific one, the DHC charter has an explicit custom definition of a DHCP
option vs a DHCP extension, but any extensions that WEBTRANS would produce
would be closer to options than to extensions in the DHC meaning of the
terms. And the QUIC WG has an existing charter that does not prevent work
on QUIC extensions in other WGs.
Could you elaborate on why you want to prevent the WEBTRANS WG from
producing extensions? I think I'm misunderstanding the motivation here.

David



> 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 <
>> [e-mail]> 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
>>
>>