Re: Re-chartering for extension work

[Mark Nottingham <[e-mail]>]

Igor,

> On 12 Dec 2019, at 12:14 pm, Lubashev, Igor <[e-mail]> wrote:
> 
> Mark,
>  
> How would the WG operate with the proposed charter?  If there is a proposed extension work that is not already named in the charter, it is out-of-scope and cannot be adopted (and hence a Call for Adoption cannot be made).  But updating the charter would require naming the proposed extension that has not, yet, been adopted.  Would we be replacing a Call for Adoption with a Call for Charter Update?  This seems to invite a confusion in the process.

Luckily, we haven't yet automated WG processes to that degree yet; we're working with the AD to make sure that our charter is updated at the correct time.
>  
> I understand that we want to protect our ability to deliver QUIC v1 ASAP.  Would it work to state explicitly in the charter that QUIC v1 (and HTTP binding) work will always have a priority over extensions in allocating WG meeting time at IETF meetings and interims?

I don't think it's necessary to micro-manage the Chairs' work in the charter to that degree, but if the AD feels otherwise, they can reflect this in the update.

Cheers,

>  
> 	• Igor
>  
> On Wed, Dec 100 at 2019 5:36 PM, Jana Iyengar <[e-mail]> wrote:
> Mark,
>  
> I'm supportive of changing the language in the charter. 
>  
> When we wrote the charter, the intent was to preclude work that might have interfered with getting the important work of the core protocol done, and the things we could think of at the time were partial reliability and FEC. That's clearly an incomplete list, as we can see with the extensions that are being proposed.
>  
> I am supportive of the new language you propose.
>  
> That said, I'd like to tease something out.. If I understand this correctly, the charter as it is allows for at least one of the currently proposed extensions to be adopted -- the version negotiation extension. Under the proposed language, we couldn't have adopted this extension since it wouldn't have been on a list of extensions. The rest of the charter talks about focus areas, not about specific documents and extensibility mechanisms. The proposed text lists extensions, which means that any extensions, even minor ones, will require a recharter. This is a tightening of the charter, which I support.
>  
> If my understanding is correct, I would hope that we remain open to rechartering as and when the wg agrees on adoption of new extensions.
>  
> - jana
>  
> On Wed, Dec 11, 2019 at 1:38 PM Mark Nottingham <[e-mail]> wrote:
> 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://www.mnot.net/
> 

--
Mark Nottingham   https://www.mnot.net/