The changes described in your other note (copied after your text to
preserve context) are reasonable in the abstract. However, the devil is
in the details.
As I understand it, the reason for calling the extra note "exceptional"
is that the IESG has in the past sometimes used that note to place far
more pejorative language than you suggest, in places that it really does
not belong. That can turn a reasoanble publicaiton request into a
political fight.
In fact, in most cases where there is a published RFC on the same topic,
the RFC Editor has demonstrated an expectation that the author will
define accurately and clearly the relationship of their work to the
existing published work. So it is not at all clear to me that the case
you site is even particularly important.
My inclination would be to stick with the "OLD" wording.
Yours,
Joel
Jari Arkko wrote:
And to start off the comments, I wanted tell my personal opinion about
this.
First, I have not been extremely happy with either the h&b or the
3932bis document, as some people who have been reading the various lists
may gather. However, I think they were already good enough to be shipped
before the changes to 3932bis. (And indeed, h&b has been shipped by the
IAB.) And I can't get that excited about debates regarding the role of
the various boilerplate texts, because I suspect that the only people
reading them are the ones who are going to respond to this thread :-)
I do think though that additional information at the level of "This RFC
describes FOO. A standardized version of FOO can be found from RFC
NNNN." is useful. I think -07 version of the 3932bis is an improvement
over the previous one, and should be approved.
Jari
(From Jari's earlier message...)
The relevant changes from the previous version of the draft are in
Section 1.1:
OLD:
The IAB and the RFC Editor have made updates to the formatting of the
title page for all RFCs [N3]. With these changes, the upper left hand
corner of the title page indicates the stream that produced the RFC.
This label eliminates the need for a mandatory IESG note on all
Independent Submission and IRTF Stream documents.
NEW:
The IAB and the RFC Editor have made updates to the formatting of the
title page for all RFCs [N3]. With these changes, the upper left hand
corner of the title page indicates the stream that produced the RFC.
This label replaces some of the information that was previously provided
in mandatory IESG notes on non-IETF-stream documents. The IESG may
choose to add an IESG note to an Independent Submission or IRTF Stream
document that explains the specific relationship, if any, to IETF work.
and Section 3:
OLD:
Generally, the RFC headers and boilerplate clearly describe the
relationship of the document to the IETF standards process [N3]. In
exceptional cases, when the relationship of the document to the IETF
standards process might be unclear, the IESG response may be accompanied
by a clarifying IESG note and a request that the RFC Editor include the
IESG note in the document if the document is published.
NEW:
The RFC headers and boilerplate is intended to describe the relationship
of the document to the IETF standards process [N3]. In addition the IESG
may request that the RFC Editor include the IESG note to clarify the
relationship of the document to the IETF standards process, such as
pointers to related IETF RFCs.
A more detailed diff is available at
http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf