(changing subject line because this is really a separate topic)

--On Friday, February 03, 2012 22:52 -0800 Ned Freed
<ned.freed@mrochek.com> wrote:

>...
>> In Abstract, it must be mentioned that the document obsoletes
>> RFC 4288.
> 
> A stupid rule in my opinion, but a rule nevertheless. I forgot
> to add it but will do so in the next revision.

Actually, as co-author, I want to strongly resist this change
and therefore that putative rule (I claim that, independent of
its substantive properties, it is invalid; see below).   I have
three separate reasons, any one of which would, IMO, justify
saying "no".   

Rant follows.

(1) Abstracts are supposed to be about the content and function
of the document and are supposed to be as minimal as possible
while still covering the actual substance.  Except in unusual
cases, which this is not, mentioning the history and
relationships of a document in the Abstract is not substantively
important to someone who is simply looking at it to find the
present state of things, as would be the case with this once it
is published.   Worse, except for RFCs that are much better
known by their numbers than by their titles (there aren't many;
RFC 822 comes to mind as an example), good practice requires
citations on first use to explain what the number refers to.
But the RFC Editor's practice (and almost every style manual for
professional publications in the world) prohibits citations from
Abstracts -- they are supposed to stand on their own. Things
might be different if the sole purpose of a document were to
obsolete or reclassify another one, but that does not apply in
this case.  

That may be a very long way of saying "stupid rule".

(2) Determination of what should be required or permitted in
Abstracts in published RFCs has always been an RFC Editor
matter, not something the IESG can change, any more than they
can unilaterally change page header or footer formats.  Note
that we already have a header on the first page (almost always
the same pages as the abstract since we fixed the "boilerplate
first" problem), so, stylistically, there is a "how much
overkill is needed" question.  FWIW, I don't have any problem
with the IESG imposing an "explain what this updates and why"
requirement on the body of a document, although I believe even
then that they ought to have a discussion with the RFC Editor
about placement (e.g., Introduction versus separate section or
subsection).  

I believe that the "Status of Document" section of IETF Stream
RFCs basically belongs to the IETF and IESG, so, if the IESG
wants some particular "obsoletes XXX" text there, I might still
think it was stupid, but I wouldn't consider it nearly as
inappropriate as imposing requirements on the abstract.   In
addition, I think the IESG, subject to community review, can
impose whatever requirements they think necessary on I-Ds to get
effective review of documents.  I think the rule requiring that
all IETF Stream I-Ds contain an "IANA Considerations" section
that can be removed on publication is ill-advised and have seen
a number of problems that can be attributed to the rule itself.
But, if the IESG, after careful deliberation, is convinced that
it is helpful to the review and consensus process, I'm ok with
it and will conform without saying much of anything.   The same
principle might apply here: if the IESG wants to say, e.g., that
obsoleting or reclassification relationships should be reflected
in an extra paragraph of the Abstract that is removed on
publication and hence not subject to the RFC Editor's rules
about length and content, I'll mutter into my beard, but will
comply.

(3) Although they can make suggestions and determine their own
practices, the IESG doesn't get to invent and make binding rules
for the community.  The Tools Team may incorporate what they
consider reasonable practices into checking tools (I'm strongly
in favor of that, actually), but that doesn't make those
practices binding on the community either.  In both cases, the
difference between "strong suggestion" and "requirement" has
always been community consensus.  That hasn't occurred here --
there has been no document for which community discussion has
occurred and consensus sought.  What we have is 

 (i) a statement in Section 3(1)(D) of the I-D checklist
	http://www.ietf.org/id-info/checklist.html (a fine
	document if taken as strong suggestions)
 (ii) a check in the the I-D nits tool.
 (iii) a few statements, e.g., in the checklist itself
	and the Shepherd template that effectively make the
	above normative.

There has not been an explicit consensus call on this
requirement in on any of the above contexts.

In the interest of efficiency, I'm even ok if the IESG sets
requirements and puts them into effect immediately, issuing
formal consensus calls only later or if there are objections
from the community.  Well, I'm objecting, I have objected in the
past, and, while the the IESG hasn't issued a consensus call,
they have published Standards Track documents in the IETF Stream
that do not contain "obsoleting" information in the abstract. 

And, again, even if the IESG asked for community consensus and
got it, it isn't clear that they can impose requirements on the
content of abstracts without the concurrence of the RFC Editor.

   john-the-grump