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

[Keith Moore <[e-mail]>]

On 7/3/19 6:18 PM, Warren Kumari wrote:
>
>
> On Wed, Jul 3, 2019 at 1:34 PM Joel M. Halpern <[e-mail] 
> <mailto:[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.
>
>
> Exactly.

Sure, that happens.  But we really don't want the public to think that 
the document is stable until it really is.

This is a longstanding problem in IETF - people implement things before 
they're ready, and this leads to incompatibilities and other operational 
difficulties.    It used to be clear that you didn't deploy 
implementations based on Proposed Standard, but people did anyway.   
IESG tried to keep up the quality by imposing more careful scrutiny, and 
people pushed back on that.  Now people want to justify deploying 
implementations based on Internet-Drafts.   Well, it's hard to stop them 
from doing so, but it certainly doesn't serve IETF's goal of promoting 
interoperability.

>
>
>     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.
>
>
> Yes, it is in no way appropriate to claim / imply that the document 
> has IETF consensus, any more than it is appropriate to claim that an 
> ID does. If this idea were to go ahead, we could adapt it to have 
> (more prominent, with asterisks and similar!) boilerplate to clarify 
> that this is only what the WG currently thinks, and isn’t an IETF 
> consensus, or an rfc or anything else...

Just to play devil's advocate (see, I can see multiple sides of a 
situation): if I intend to implement a WG's proposal, I would really 
like to have an idea when I could start implementing (NOT deploying) 
with some confidence that an implementation of the final version would 
be at worst a small change from an implementation of the current 
version.   What I'd like to avoid is implementing a proposal only to 
have to rip it up and start over later because some significant changes 
were agreed to.   But I'm not sure how a WG can know when it's at that 
point, especially in the absence of significant review from the wider 
community.   WGs work too much in silos as it is.

I think this is a fundamental problem with our process - we should be 
able to get increasing /community-wide/ confidence in a proposal as it 
matures, and right now we're just not set up to do that.

>
>     PS: I am not sure what the general benefit of marking an I-D as
>     'stable"
>     would be. 
>
>
> Primary, if you are external to the IETF, and want to get a “snapshot” 
> of what the WG has agreed to on a draft.

In practice, the WG doesn't come to agreement until its own Last Call.   
But the status of a draft is already available on the tracker page.   
IMO the LAST thing we need is to convey misleading impressions to those 
external to the IETF, and the potential for misinterpretation and 
deliberate misleading would be huge if such an indication were provided 
in the document ID.

> As an example, I was recently working on a draft where people started 
> implementing bits which were still very much under discussion - this 
> hurt the draft because it made it hard to change. I made some proposed 
> edits to this section anyway to get WG feedback... and implementers 
> suddenly changed to this...
> After a few rounds of “hey, we are changing this again” implementers 
> got annoyed, the WG got annoyed, and I got annoyed.

Well, sure, but was there any way to know "this version is finally 
stable" at the time that it happened?   I have often thought I had a 
document that was ready to pass Last Call only to find out otherwise.

> I would have liked to be able to easily signal “if you want to 
> implement, this version is mostly sane. It’s obviously still subject 
> to change, but at least more than the authors think it’s reasonable.” 
> versus “this version has many bits which we don’t have WG agreement 
> on: we put them in so they can be reviewed. Please wait till we agree 
> that it isn’t filled with craziness before implementing, etc.”

Fine.  Put that in the Abstract and/or the Introduction.   Don't try to 
formally codify it.

Keith