Re: [apps-discuss] Requirement for "obsoletes" in Abstracts (was: Re: I-D Action: draft-ietf-appsawg-media-type-regs-00.txt)

[Ned Freed <[e-mail]>]

Initial response: *gulp*

I obviously don't feel nearly as strongly about this as John does, although I
completely agree with everything he says. So I'm going to defer to him entirely
on this point. I won't add anything to the document at the present time and
we'll see how it goes.

And with that, I actually think it's time to post -01. It should be out
in a few minutes.

				Ned

> --On Friday, February 03, 2012 22:52 -0800 Ned Freed
> <[e-mail]> 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

> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss