Subject: Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

From: RJ Atkinson <[email-masked]>
Date: Sat, 12 Sep 2009 07:20:33 -0400

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.

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."

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.

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".

   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.

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.

Yours,

Ran Atkinson
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Sep 2009 07:05:24 -0700

RJ Atkinson wrote:
...
>   on non-IETF-track documents.

+1

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 14 Sep 2009 10:13:05 -0400

On  14 Sep 2009, at 10:00, Polk, William T. wrote:
> 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.

It is interesting to better understand your perspective.

I would have read the "current text" in a nearly inverted meaning:
   providing "authority to deal with someone trying to make an
   'end run' around the IETF in some area of current IETF effort",
   by requesting the RFC-Editor to add an IESG note in such a case,
   but not requiring the IESG to do so.

To me, the most relevant datum is that we have more than 15 years
of operational experience with the current setup, and zero actual  
problems.

[...stuff deleted here...]

> 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,

This parenthetical bit just above is confusing, and (at least to me)
non-obvious.

Why would someone who can read sufficiently well to understand
the content of an RFC have trouble distinguishing between the
"Status of this Memo" texts AND also have trouble understanding
the RFC's "Category" field ?

> 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?")

I'm glad that you agree that seems to be the (most of the)
community's perspective.

[...stuff deleted here...]

> [I wouldn't assume that anyone speaks for the IESG on this topic,  
> especially
> me!  This represents my personal views only.]

Fair enough.

Thanks for the explanations.  At a minimum, I think I understand
your perspective much better.

Yours,

Ran Atkinson
[email-masked]

---

From: "Polk, William T." <[email-masked]>
Date: Mon, 14 Sep 2009 10:00:15 -0400

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...

> across as very confused or incompletely informed.

Both of which may be true... but I'll give it another shot anyway.

>         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.

>    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?")

>    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.

>    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.

>    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.

> [email-masked]

Thanks,

Tim

> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Polk, William T." <[email-masked]>
Date: Mon, 14 Sep 2009 11:18:15 -0400

>    but not requiring the IESG to do so.

It is a fair observation... The word "responsibility" doesn't appear, so
that is just the way I interpret it.  Since this option is reserved for
"exceptional" cases, I guess I think the IESG would have an obligation to
address the issue, but that may be an AD-specific reading.

> of operational experience with the current setup, and zero actual

If we are lucky, this a painful exercise to establish process that will not
need to be tested in practice.  I certainly hope that is the case.

> the RFC's "Category" field ?

It's not that the reader can't, it's that they *won't*.  I don't believe
readers always read the boilerplate, and I don't think many readers bother
to research the difference between the categories.  I find even long time
members of the IETF Community can debate whether a particular document
should be PS vs. BCP vs. Informational for a long time, so I am sure that
the nuances will be lost on the casual reader.

However, my limited expectations of the reader are irrelevant beyond
confirming my pessimistic nature.  I think the test we should apply is for
people that will read and understand the boilerplate.  (Otherwise, they
wouldn't see the IESG note anyway!)

+1

Tim