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 <john-ietf@xxxxxxx> 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 > <erik.wilde@xxxxxxxx> 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. > > > >