ietf
[Top] [All Lists]

Re: Obsoletes/Updates in the abstract (Was: Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07)

2012-09-21 16:17:06


--On Friday, September 21, 2012 15:25 -0500 Ben Campbell
<ben(_at_)estacado(_dot_)net> wrote:

It's certainly useful to some folks. Necessary? (*Shrug*) Not
enough wasted bits for me to care one way or the other.


As a Gen-ART reviewer, I called it out for exactly the reasons
Pete mentions, and care about the same amount :-) But putting
it there seems to hurt nothing, and maybe help just a little
bit in some cases.

Ben,

An observation as an individual rather than in any EAI capacity:

The scholarly publication and information science fields have
generally-accepted criteria for abstracts.  The devil is in the
details, of course, but, in general,  structural comments or
comments about relationships to earlier works are included only
if they are essential to understanding what the current document
is about.   I note that this comment is consistent with Dave
Crocker's earlier one, although I'd go a bit further.

There is an additional issue, which is that the RFC Editor
normally requires that citations of RFCs be treated as citations
and referenced but, consistent with those generally-accepted
practices, prohibits citations from abstracts.  Ending up with
"this obsoletes RFC NNNN" in an abstract sneaks by that
combination of rules, but borders on the unprofessional.

There are documents for which "this obsoletes that" really does
belong in the abstract because it is essential for understanding
the role of the document but in almost all cases, "that" won't
be an RFC reference but a topical one.  As an example in the RFC
series that might mean that the abstract for RFC 5378 might more
reasonably have said "This memo is effective XXXX and supercedes
all policies about rights in contributions prior to that date".

To the extent to which the issue is metadata information in
announcements, let's fix the announcement templates, not
introduce kludges to get around them.   The argument that there
is some other information that people might want to know that
doesn't appear when the abstract alone is posted is, by
contrast, completely bogus: people might want to know the date
of publication, the author's names, etc., but no one has
suggested that they be included in the abstract.

On the other hand, I'm a strong advocate of requiring text in
the document -- in the Introduction or a specially-identified
section-- that describes the relationship of the current
document to anything it updates, obsoletes, modifies,
criticizes, or is otherwise directly related to.  That is
important explanation, not a few words in the abstract that
partially identify a relationship without even hinting about
what it is about substantively.

FWIW, I believe this is ultimately an RFC Style issue and that
the community should expect guidance on it from the RFC Editor.  

Finally, as I have previously pointed out to the IESG, the
"requirement" for that sentence in the abstract made it into
IDnits without anything resembling a consensus call or
consultation of the RFC Editor.  While I'd rather see the
substantive issue addressed and have tried to do so above, we do
have rules about community consensus before requirements are
imposed and this hasn't made that test as a requirement.  If the
nits checker wanted to say "are you sure that the relationship
between this document and any predecessors are not significant
enough to justify inclusion in the abstract" I think that would
be fine, especially if it also generated a question of "are you
sure that the relationship between this document and any
predecessors are significant enough to justify putting text in
the abstract (and possibly cluttering it)" when the citation
does appear.  But, as a requirement, it is basically bogus
absent either a style requirement from the RFC Editor or a
consensus call.

   john