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

Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> · Wed, 3 Jul 2019 19:21:26 -0400



    On 7/3/19 6:18 PM, Warren Kumari wrote:

    
          On Wed, Jul 3, 2019 at 1:34
            PM Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> 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