Re: [apps-discuss] Requirement for "obsoletes" in Abstracts

[John C Klensin <[e-mail]>]

--On Sunday, February 05, 2012 22:48 +0100 Julian Reschke
<[e-mail]> wrote:

>> 3. The rationale for the rules should be provided.
> 
> +1
> 
> I can see that it's useful for the RFC Editor to be able to
> easily find out what changes to the RFC Editor database are
> required. Maybe just introduce something similar to the "IANA
> Considerations"?

Julian,

I think it would help this discussion if we avoided conflating
too many issues.  But, fwiw, there isn't a lot of information in
the database or information needed to construct/ update it.
Unless that changes, 100% of the information that is needed for
"obsoletes" is contained in the "updates" header at the top of
the page.   As Barry pointed out, if the "updates" header is
there an almost-content-free sentence in the abstract that says
"this updates that" is pretty close to 100% useless.

FWIW, and generalizing a bit from an earlier comment, I think it
would be worthwhile for the community and the IESG to explore
types of information that are really useful in the review and
publication process, including updating databases of various
sorts but that fall somewhere on the spectrum between "useless"
and "actively confusing" in the long term.    If the IESG wants
some additional information in a specific form in I-Ds to help
with reviews, I think  that is fine.  Similarly, I think putting
the entire desired contents of a new (and potentially large)
registry as part of instructions to IANA is useful.  But either
should be carried into an RFC is an open question and, while I
think there are lots of edge cases and places where careful
consideration is going to be necessary, a translation of Dave's
comment into a "will this be useful in 20 years or just a
distraction" criterion seems quite useful to me.

So, just as I'd like to see any suggestions about "updates"
sentences in an I-D Abstract either dropped entirely or having
that text dropped before RFC publication, I'd much rather see
the published version of "IANA Considerations" (where it is
included at all) reduced to a summary description of what IANA
was asked to do and did, with a pointer to the registry if
appropriate, rather than the listing of code points and
descriptions that might be entirely reasonable in an
I-D/proposal.

My guess is that a thoughtful examination of what we are doing
to and with the RFC Series (IETF Stream and more generally)
might yield more examples of the underlying principle that
implies.

   john