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
r...@extremenetworks.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
