Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.

[heather flanagan <[e-mail]>]

> On Jul 3, 2019, at 1:34 PM, Joel M. Halpern <[e-mail]> wrote:
> 
> Let me phrase it differently, with a similar point to Keith's
> 
> An IETF working group can say "we think this has the right content, but we are not yet handing it to the AD because ..."
> That is a form of stability
> It is NOT a promise not to change the content before RFC publication.
> As an example, I as co-chair thought the NSH spec was very stable, and then a technical issue was raised that required an incompatible change. It was still a working group document.  We made the change.

> 
> Further, a working group can not label a draft in a way that suggests that there is IETF consensus in support of the document.  That is not its purview.  And is believe the implication that Keith is concerned about.

Entirely agree.

> 
> I do not expect that either Heather or Warren were looking at the later interpretation.  But I can see how someone reading the email could reasonably be concerned about such over-ambition.
> And your response that working groups can publish whatever they want is at best misleading.  It is true that the content of I-Ds is up to the working group.  The labeling of them is NOT up to the working group.
> (We do, consciously, deliberately, and to significant advantage, make all our works-in-progress visible to the world.  They are labelled as such.)

One of the things that attracts me to this idea of marking specific I-Ds as stable is the possibility that the material in the I-D will be more throughly tested BEFORE it gets to the RFC Editor for publication. I see it as, potentially, a way to improve the quality of what’s published in the RFC Series. 

If it means that the technical quality of the specifications published in the RFC Series improves, then that’s an idea I’d like to talk about to see if it has enough benefits to outweigh the risks of trying it out. So, that said, I’m hoping the side meeting makes sure we’ve identified the risks well enough to know what we’re up against.

-Heather

> 
> Yours,
> Joel
> 
> PS: I am not sure what the general benefit of marking an I-D as 'stable" would be.  We still would not want it normatively cited.  I tried to construct the most positive such label in teh example above.  I may or may not have time to join the side-meeting.
> 
> On 7/3/19 4:23 PM, Richard Barnes wrote:
>> On Wed, Jul 3, 2019 at 4:18 PM Keith Moore <[e-mail] <mailto:[e-mail]>> wrote:
>>    On 7/3/19 4:15 PM, Richard Barnes wrote:
>>> 
>>>    On Wed, Jul 3, 2019 at 4:10 PM Keith Moore
>>>    <[e-mail] <mailto:[e-mail]>>
>>>    wrote:
>>> 
>>>        On 7/3/19 4:04 PM, Warren Kumari wrote:
>>> 
>>>        > Hi there all,
>>>        >
>>>        > TL;DR: Being able to mark a specific version of an *Internet
>>>        Draft* as
>>>        > “stable” would often be useful. By encoding information in
>>>        the name
>>>        > (stable-foo-bar-00) we can do this.
>>>        >
>>>        > Heather and I will be holding a side meeting at IETF 105 to
>>>        discuss
>>>        > the idea and get feedback.
>>>        > When: Tue, July 23, 3:00pm – 4:30pm
>>>        > Where: C2 (21st Floor)
>>> 
>>>        It seems to me that this would defeat the entire purpose of
>>>        Internet-Drafts and serve to circumvent the IETF process. There
>>>        should be no expectation of stability until a document has
>>>        reached
>>>        IETF-wide consensus.
>>> 
>>> 
>>>    Why is it necessary to conjoin those two things?
>>    Because a working group does not have the authority to make such
>>    decisions on its own.   To the extent that it would be desirable to
>>    invest such authority in some body for some specific purpose, a
>>    working group is the wrong kind of body to do that.   The norms
>>    around IETF WG operation aren't the right ones for such a body.
>> Doesn't have the authority to publish stable specifications?  Obviously, a WG can't publish something and claim it has consensus or is an RFC.  But WGs already have the ability to publish stable docs, by publishing them on github or on IPFS.  This is just about making them easier to find and reference.
>> I think maybe you're over-inflating the significance of this proposal.
>> --Richard
>