Hi Ran, I have specific responses in-line, but I'll start with a summary of sorts for less patient readers. IMHO, the current text places a responsibility on the IESG to deal with "exceptional circumstances" but fails to provide the tools to execute that responsibility. After 27 years in government, I have a lot of experience with assignment of responsibility without authority, and none of it was positive. I completely accept the community's consensus that IESG notes should be reserved for the egregious cases, if any should emerge, but I would like to see a process for achieving that goal where *necessary*. Making notes mandatory is one possible mechanism, although others might be preferable. I personally support the position outlined in Jari's 9/13/09 email... On 9/12/09 7:20 AM, "RJ Atkinson" <rja@xxxxxxxxxxxxxxxxxxx> wrote: > Earlier, Tim Polk wrote (in part): > % And are we really helping anyone by not clarifying the > % relationship between the document and other RFCs? > % > % Shouldn't we provide this information as a > % service to the reader? > > Tim, > > I like you, but your reasoning on this topic comes > across as very confused or incompletely informed. > Both of which may be true... but I'll give it another shot anyway. > The information you discuss is ALREADY available and > HAS BEEN available for well over a DECADE now. > > To be frank, the status is also very very clear to anyone > who actually glances at any modern RFC. > > 1) Each modern RFC has a "Category" field in the header > on the first page. This dates back at least to RFC-1517, > which was published in September 1993 -- 16 years ago. > > 2) Separately, and for redundancy, the "Status of This Memo" > field has made that information available in less > abbreviated form. > > To pick two arbitrary examples from ~15 years ago that > illustrate both that the markings are QUITE CLEAR at even > a quick glance AND that these markings go back MANY years > now: > > A) RFC-1704 "On Internet Authentication" > <http://www.rfc-editor.org/rfc/rfc1704.txt> > 1) "Category: Informational" (top left corner) > 2) "Status of this Memo" says in entirety: > "This document provides information for the Internet > community. This memo does not specify an Internet > standard of any kind. Distribution of this memo > is unlimited." > > B) RFC-1626 "IP MTU for use over ATM AAL5" > <http://www.rfc-editor.org/rfc/rfc1626.txt> > 1) "Category: Standards Track" (top left corner) > 2) "Status of this Memo" says in entirety: > "This document specifies an Internet standards track > protocol for the Internet community, and requests > discussion and suggestions for improvements. Please > refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. > Distribution of this memo is unlimited." > I don't know think that this is a core issue, since it is addressed in the headers and boilerplates document, but I don't think Category and Status of Memo provide all the information needed. Even assuming the reader looks at the boilerplate and understands provided information, there is a difference in my mind between an informational (or experimental) RFC that comes from the IETF process or the IRTF process than one that is an independent submission. It is information the reader might want to factor into any implementation or deployment decisions, but is not available. > 3) As I understand things, and on this I might be a bit > out-dated as to the current state of things, there is > a concrete proposal to also add to each RFC (starting > in the near future and continuing forward) the specific > "Document Stream" (i.e. IETF, IRTF, IAB, Independent > Submission) via which a particular RFC was published. > > I have no objection to that addition. I don't think that > it is really necessary, given (1) and (2) above, but it > seems to make some folks more comfortable and I don't > immediately see any harm in that addition. > I actually think this is a very good addition, precisely because I believe (1) and (2) are insufficient. If the reader reads and understands the boilerplate, we have the 98% solution. (I personally have my doubts about reading and understanding the boilerplate, but I believe that is the criteria the community would have the IESG apply: "Assuming the reader understands the headers and boilerplate, is a note really needed?") > > ANALYSIS: > Noel's recent note pointing to Donald Eastlake's note > is an accurate summary of the situation. We have substantial > actual operational experience indicating that IESG notes > are handled appropriately by the RFC Editor team. There > is zero evidence of a problem. So there is no reasonable > cause to make IESG notes on non-IETF-track documents > mandatory. > > Separately, The IESG lacks authority over the overall > RFC publication process -- our process documents say that > the RFC-Editor reports to the IAB, not the IESG. This > was done *precisely* because it has always been true > that many RFCs are not produced via the IETF processes. > > The RFC process dates back to 1969 -- 40 years ago. > The IETF wasn't itself formed until the middle 1980s. > > Lastly, the RFC Editor and IAB have responsibilities to > the entire "Internet community", whilst the IESG has more > narrow responsibilities for IETF Standards activities. > The "IETF Community" is a proper subset of the larger > "Internet Community". A number of folks aren't active > in IETF work, but are active in IRTF work or are otherwise > important parts of the broader "Internet Community". I recognize the importance of the other streams, but I freely admit that the IETF stream is the most important to me. That certainly colors my views. I do believe that there is an even higher bar for putting a note on a irtf document than an independent submission, since the irtf has its own guidelines and procedures tuned to meeting its selected mission of research. > > For this reason, even if there were IETF consensus of a > problem (and frankly, there seems to be smooth consensus > amongst non-IESG members that there is NOT a problem), > that would be the wrong yard-stick to use for changing > processes applicable to non-IETF-track documents. Again, > this is why RFC publication is an IAB responsibility > instead of an IESG responsibility, and why our process > documents say that the RFC Editor reports to the IAB. > > BOTTOM LINE: > There seems to be clear consensus amongst folks outside > the IESG that (1) there is no current problem and (2) > no process change is warranted to make IESG notes mandatory > on non-IETF-track documents. > I am going to defer to Jari's viewpoint on the consensus in yesterday's email (Subject "path forward with RFC 3932bis"). He is the sponsoring AD. > REQUEST: > I would urge the IESG to formally abandon the advocacy > to change this aspect of our processes, and to say that > this has been abandoned on the IETF discussion list. > [I wouldn't assume that anyone speaks for the IESG on this topic, especially me! This represents my personal views only.] I think that the compromise position outlined in Jari's message is far better than making IESG notes mandatory. It protects the independence of the RFC Editor, provides the IESG with reasonable tools in the exceptional case, and leaves the ultimate authority with the IAB. I hope that position will gain traction and resolve the issue. > Yours, > > Ran Atkinson > rja@xxxxxxxxxxxxxxxxxxx > Thanks, Tim > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf