Re: I-D Action: draft-wilde-updating-rfcs-00.txt

["Scott O. Bradner" <[e-mail]>]

see, for example, https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd/

Scott (network WG chair)


> On Dec 11, 2016, at 2:22 PM, John C Klensin <[e-mail]> wrote:
> 
> Erik,
> 
> Sorry for the delay in responding. Let me try a very high-level
> summary of the implications of what I, at least, consider the
> most important history of the problem you are trying to bite off
> a piece of (others will have other histories).  First, it isn't
> easy.  Even if one just ignores the various flavors of
> Informational documents, the right documentation rules for
> single-stage processes (e.g., BCPs) are inevitably different
> from those for two (and previously three)-stage technical
> standards track ones.  That problem is further complicated by
> the fact that we use BCPs, and occasionally technical standards,
> for what are really procedural or policy statement documents.
> Second, there is a complexity tradeoff.  Today, for normative
> documents, we have BCP documents and 2 1/2 levels of standards
> track  one (depending on what one thinks Experimental is).  
> 
> The issues of updating and categories are also inevitably
> complicated by the nearly-orthogonal one of interrelated and
> interdependent documents, some developed at different times and
> by different groups and often with non-obvious overlaps.
> 
> We tried to take all of this on some years ago in a WG called
> "NEWTRK".  It was not successful.  In particular (and trying to
> state this as neutrally as I can manage), the WG concluded that
> we needed a new type of Standards Track document that would talk
> about status and relationships among documents, rather than
> being one or more technical specification itself.  At least some
> of what you seem to be proposing would go into those
> standards-description documents and not the technical
> specifications themselves.  In addition, at least some of us
> believe that the relevant documents would be living documents
> with change histories rather than the inherently-static (at
> least per-document) RFC series.  
> 
> WIthout revisiting the argument and various opinions about
> motivations, the IESG concluded that the idea was just too
> complicated and/or inappropriate and the idea when nowhere.  In
> retrospect, they might have been right.  Or not.  Either way,
> the experience left many of us reluctant to start nibbling at
> the issues again unless there was a comprehensive plan that the
> IETF was willing to sing off on.
> 
> However, I do believe that it is unrealistic to believe one can
> take on inter-document relationships without at least reviewing
> the issues that the NEWTRK WG examined and the options it
> considered.
> 
> best,
>    john
> 
> 
> 
> --On Wednesday, December 07, 2016 21:52 -0800 Erik Wilde
> <[e-mail]> wrote:
> 
>> hello john.
>> 
>> On 2016-09-15 09:37, John C Klensin wrote:
>>> Independent of where it is discussed (as
>>> long as it is on a public list), this I-D would be, at least
>>> IMO, a much more satisfactory basis for discussion if it
>>> demonstrated more convincingly that the author was aware of
>>> those earlier discussions and had considered them, rather than
>>> assuming (or appearing to assume) that no one had thought
>>> about these topics.
>> 
>> it was not my intention to ignore or belittle previous
>> discussions. it just occurred to me as a frequent reader of
>> RFCs that there is a large variation in quality how updates
>> are documented. the idea was that some simple documentation
>> guidelines might help to improve that, without necessarily
>> being hard definitions on what exactly updates are, and how
>> exactly they have to be documented.
>> 
>> i'd be more than happy to include these earlier discussions,
>> but i am afraid if that involves going through a long list of
>> mail archives, this simply is beyond the time commitment i can
>> reasonably make. i'd be more than happy to have somebody
>> co-authoring and filling in those gaps, but that of course
>> assumes that somebody else would be willing to put in the
>> effort of writing up this history.
>> 
>> thanks and cheers,
>> 
>> dret.
> 
> 
> 
>