Re: Re-chartering for extension work

[David Schinazi <[e-mail]>]

On Thu, Dec 12, 2019 at 3:19 PM Mark Nottingham <[e-mail]> wrote:

> > On 13 Dec 2019, at 7:50 am, David Schinazi <[e-mail]>
> wrote:
> >
> > In general, I'm very supportive of rechartering to allow these new
> extensions.
> >
> > I'd prefer to have the charter just allow all extensions, and then use
> the WG call for adoption consensus process to decide whether extensions are
> in-scope at a given moment in time or not. But if the chairs/ADs think that
> is too broad I can live with only opening up for specific topics.
> >
> > One important problem though, is in the DATAGRAM case, the topic of flow
> identifiers. Earlier, draft-pauly-quic-datagram-03 contained flow
> identifiers. Based on community feedback, the authors removed them from
> -04, and moved them to a separate draft-schinazi-quic-h3-datagram. I'll
> admit that draft-schinazi-quic-h3-datagram is still very immature, but with
> the new charter, I want to make sure we don't end up in a state where we
> can discuss draft-pauly-quic-datagram but not
> draft-schinazi-quic-h3-datagram. Some folks feel strongly that flow
> identifiers should exist, and if we tell them that they're not in scope of
> the WG they might be sad.
>
> It's good to know about these requirements, and of course once the
> document is adopted, we can discuss issues against it. However, if you want
> to discuss datagrams in HTTP/3, we need to have a discussion about whether
> it'd be more appropriate to do that in this WG or in the HTTP WG --
> remembering that once HTTP/3 ships, it takes over maintenance of that spec.
>

Thanks, that makes sense to me. Happy to take
draft-schinazi-quic-h3-datagram to HTTPBIS (or will it be HTTPTER ?). Just
wanted to make sure that discussing it in context
of draft-pauly-quic-datagram is OK.

David


Cheers,
>
> >
> > Because of this, I think the new charter should discuss topics as
> opposed to specific draft names (which is what I assume Mark meant by [
> adopted extensions ] )
> >
> > David
> >
> > On Thu, Dec 12, 2019 at 8:15 AM Lubashev, Igor <[e-mail]>
> wrote:
> > Mark,
> >
> > Speaking of lossbits, the work has been discussed at several meetings
> and there was a significant show of willingness of work on lossbits at the
> mic line in Singapore, on the condition that the work is (a) a negotiated
> extension, (b) the use of the bits is strictly specified, and (c) it is not
> blocking for QUIC v1.
> >
> > We were planning to present the draft of lossbits as a negotiated
> extension in Zurich, but given that the time for the inclusion in the
> Charter is now, we can get the draft out next week.  Given the prior
> discussion and expressed willingness of at least a part of the WG to work
> on this, would you include that extension draft in the WG adoption call
> prior to the charter update?  (As usual, adoption != publication, which is
> subject to the deliberations of the WG, including a positive
> privacy/security analysis.)
> >
> > - Igor
> >
> >
> > > On Thu, Dec 12, 2019 at 4:52 AM, Roni Even (A) <[e-mail]>
> wrote:
> > >
> > > Hi
> > > This clarifies the proposed charter and the priority of the V1
> document  but
> > > as for future extensions the text from the meeting notes says
> > >
> > > "Mnot: If you do think you have an extension which is generic enough,
> we
> > > will reserve time for it during the quiet for disucssion on the list.
> For this, we
> > > will need a charter change for that, but we've been talking to the ADs
> about
> > > that, and we'll put a proposal out for comment."
> > >
> > > How is this reflected in the charter, which extensions will be
> considered
> > > "generic enough" and appear by name in it. There are three extensions
> for
> > > adoption and they look generic enough more (version negotiation,
> > > datagrams)   or less (LBs), so why not lossbit, for example or any
> other from
> > > the related I-Ds that are "generic enough". The problem in my view is
> that if
> > > all these drafts are not in the proposed charter, they cannot be
> discussed at
> > > all during the "quiet" .  I would prefer to allow in the charter and
> decide if to
> > > create a milestone.
> > >
> > > Roni
> > >
> > > > -----Original Message-----
> > > > From: Magnus Westerlund [mailto:[e-mail]]
> > > > Sent: Thursday, December 12, 2019 11:08 AM
> > > > To: Roni Even (A); [e-mail]
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: Re-chartering for extension work
> > > >
> > > > Hi,
> > > >
> > > > I want to give my input as AD into this process. We are intentionally
> > > > keeping this rechartering very narrow in scope and do not intended to
> > > > open up for general extension adoption in the WG at this moment. The
> > > > extensions currently on call for adoption is selected set which
> > > > appears important, tractable and with clear scope. However, the
> > > > primary focus will remain on finishing the core specification of
> > > > version 1 of QUIC. The chairs have my full confidence in managing the
> > > > process and are communicating with us ADs regularly.
> > > >
> > > > As Mark stated before discussion of future extensions can occurr if
> > > > time permits, we will also consider other ways of enabling the
> > > > discussion like a QUIC dispatch session. However, as v1 finish we
> will
> > > > take a new look at the QUIC WG charter and do a more thourgh
> recharter
> > > > at that stage. That discussion will then happen in the context of the
> > > > discussion that will have occurred between now and then. However,
> > > > starting v2, how to handle both bigger and smaller extensions to the
> > > > protocol and any additional guidance documents needed will clearly
> > > > need changes to the charter.
> > > >
> > > > I hope that clarifies the road forward.
> > > >
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> > > >
> > > > On Thu, 2019-12-12 at 07:41 +0000, Roni Even (A) wrote:
> > > > > Hi Mark,
> > > > > I know that it was discussed in tsvarea session. I noticed that are
> > > > > currently
> > > > > 19 individual drafts in QUIC. I am not sure that all of them should
> > > > > be
> > > > adopted
> > > > > as chartered work in QUIC. My view is that the WG should at least
> > > > > say so
> > > > and
> > > > > propose to the authors to take it to a named WG ( probably need
> > > > recommendation
> > > > > from the Ads) instead of keeping them alive in the QUIC as related
> IDs.
> > > > > Currently the authors can ask to add these documents to the charter
> > > > > based
> > > > on
> > > > > the proposed charter change
> > > > >
> > > > > " The Working Group may consider other extension work, but adopting
> > > > further
> > > > > extensions requires updating this charter."
> > > > >
> > > > > This is like a new call for adoption process, instead for asking
> for
> > > > > adoption the question will be call for re-charter.
> > > > >
> > > > > Roni
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Mark Nottingham [mailto:[e-mail]]
> > > > > > Sent: Thursday, December 12, 2019 9:15 AM
> > > > > > To: Roni Even (A)
> > > > > > Cc: IETF QUIC WG; Lars Eggert
> > > > > > Subject: Re: Re-chartering for extension work
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On 12 Dec 2019, at 6:13 pm, Roni Even (A) <
> [e-mail]>
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > HI Mark,
> > > > > > > I looked at your response to Jana, I do not have a better text
> > > > > > > suggestion
> > > > > >
> > > > > > but I think that adding specific extensions can be discussed by
> > > > > > asking the WG to create a new milestone. Yet I understand that
> the
> > > > > > charter should be
> > > > clear
> > > > > > about what is in scope for the WG. I think that maybe the charter
> > > > > > should also say that the WG can direct proposal for new work to
> > > > > > another WG (sort of dispatch for QUIC).
> > > > > >
> > > > > > That's been discussed (at the Transport Area meeting in
> > > > > > Singapore); we might try an experiment where we do something like
> > > > > > that in Vancouver,
> > > > but
> > > > > > it's not clear that *this* WG should be the locus of
> > > > > > quic-dispatchy things quite yet.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > >
> > > > > > > One other thing, I think that when asking for adoption of a
> > > > > > > document
> > > > you
> > > > > >
> > > > > > are asking to create a milestone and adopt the document as the
> > > > > > initial document to address the milestone.
> > > > > > > Sorry for sounding like someone whose focus is on the process
> > > > > > > and not
> > > > the
> > > > > >
> > > > > > content.
> > > > > > >
> > > > > > > Roni
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Mark Nottingham [mailto:[e-mail]]
> > > > > > > > Sent: Thursday, December 12, 2019 9:00 AM
> > > > > > > > To: Roni Even (A)
> > > > > > > > Cc: IETF QUIC WG; Lars Eggert
> > > > > > > > Subject: Re: Re-chartering for extension work
> > > > > > > >
> > > > > > > > Hi Roni,
> > > > > > > >
> > > > > > > > See my response to Jana regarding naming of extensions.
> > > > > > > >
> > > > > > > > Regarding milestones - yes, we'll do that when the rest of
> the
> > > > > > > > changes go through. Thanks for the reminder.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > >
> > > > > > > >
> > > > > > > > > On 12 Dec 2019, at 5:49 pm, Roni Even (A)
> > > > <[e-mail]>
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Mark,
> > > > > > > > > I am not sure why you need to name extensions in the
> > > > > > > > > charter. I think that
> > > > > > > >
> > > > > > > > the extension work in the charter should be general and the
> > > > > > > > discussion about specific ones would be about creating a new
> > > > milestone..
> > > > > > > > >
> > > > > > > > > BTW: maybe it will be good to update the milestones
> > > > > > > > >
> > > > > > > > > Roni Even
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: QUIC [mailto:[e-mail]] On Behalf Of
> > > > > > > > > > Mark Nottingham
> > > > > > > > > > Sent: Wednesday, December 11, 2019 11:38 PM
> > > > > > > > > > To: IETF QUIC WG
> > > > > > > > > > Cc: Lars Eggert
> > > > > > > > > > Subject: Re-chartering for extension work
> > > > > > > > > >
> > > > > > > > > > We've just put out Calls for Adoption for extensions to
> > > > > > > > > > QUICv1, as we believe that the group has some capacity to
> > > > > > > > > > discuss them as it finishes work on the core protocol.
> > > > > > > > > >
> > > > > > > > > > However, our charter [1] precludes work on at least some
> > > > extensions.
> > > > > > > > > > The specific text in question is:
> > > > > > > > > >
> > > > > > > > > > """
> > > > > > > > > > Extensions that will support partial reliability, and
> > > > > > > > > > negotiation and use of Forward Error Correction schemes,
> > > > > > > > > > are out of scope in this version of the working group
> charter.
> > > > > > > > > > """
> > > > > > > > > >
> > > > > > > > > > *If* we do decide we'd like to adopt, we'll need to
> update
> > > > > > > > > > it to something
> > > > > > > > > > like:
> > > > > > > > > >
> > > > > > > > > > """
> > > > > > > > > > Additionally, the Working Group will deliver [ adopted
> > > > > > > > > > extensions
> > > > ].
> > > > > > > > > > The Working Group may consider other extension work, but
> > > > adopting
> > > > > > > > > > further extensions requires updating this charter.
> > > > > > > > > > """
> > > > > > > > > >
> > > > > > > > > > Please take a look and discuss any concerns; we'll be
> > > > > > > > > > asking our ADs for such a modification (with appropriate
> > > > > > > > > > changes to the list of extensions adopted) once our
> Calls for
> > > Adoption complete.
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > >
> > > > > > > > > > 1. https://datatracker.ietf.org/wg/quic/about/
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Mark Nottingham
> > > > > > > > > > https://protect2.fireeye.com/v1/url?k=2f5948b0-73cb45af-
> > > > 2f59082b-0cc47ad93db4-7b6490019ba3569f&q=1&e=4eadb99e-52e4-49b3-
> > > > adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > > > > > > >
> > > > > > > > --
> > > > > > > > Mark Nottingham
> > > > > > > > https://protect2.fireeye.com/v1/url?k=bc29a42a-e0bba935-
> > > > bc29e4b1-0cc47ad93db4-eaf17369ba9839a7&q=1&e=4eadb99e-52e4-49b3-
> > > > adef-683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > > > > >
> > > > > > --
> > > > > > Mark Nottingham
> > > > > >
> https://protect2.fireeye.com/v1/url?k=21be3936-7d2c3429-21be79ad-
> > > > 0cc47ad93db4-613c07cadcb96094&q=1&e=4eadb99e-52e4-49b3-adef-
> > > > 683bb7f58fea&u=https%3A%2F%2Fwww.mnot.net%2F
> > > > >
> > > > >
> > > > --
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>