Re: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT)

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

--On Tuesday, August 1, 2017 18:05 -0500 Adam Roach
<[e-mail]> wrote:

> On 8/1/17 5:29 PM, John C Klensin wrote:
>> 
>>> Major comment:
>>> 
>>> Section 3 has suggested changes for RFC3188 for the next time
>>> it is revised. It's not clear, outside of institutional
>>> knowledge (which is a very fragile construct) how the
>>> indicated changes are going to be properly remembered when
>>> such revision takes place. Is there a good reason this
>>> document doesn't simply update RFC3188 by indicating an
>>> updated template directly? If this doesn't make sense, I
>>> would think that we need at least an erratum associated with
>>> RFC3188 that indicates the nature of update that needs to be
>>> performed.

>> The problem is this.  RFC 3188 was never an IETF WG document.
>> It will be replaced by a new RFC, most likely in the
>> Independent Stream unless you are one of your colleagues are
>> interested in sponsoring it as an Informational individual
>> submission.
> 
> Have you asked?

Not yet.  Figured it would be better to have a posted I-D first.

>> Juha
>> and I have been working intermittently on a draft; the hold-up
>> right now is mostly me, for which I apologize but I have been
>> tied up with other IETF-related work that seemed to be more
>> pressing.  There are twp reasons why an updated template is
>> not directly referenced: it isn't ready due to evolution in
>> NBNs and it seemed inappropriate for the WG to make promises
>> about what would be in it.  FWIW, the specific things that
>> this draft calls out have already been incorporated in the
>> working draft for 3188bis.
> 
> The fact that a document revision is actually underway does
> assuage my concern for the most part. Could you cite the
> 3188bis document as a work in progress? I think it would be
> useful for consumers of this document to know that a revision
> is actively in progress, and to have a document name to look
> for.

We had such a reference or something like it in an earlier
draft.  Barry asked us to take it out on the grounds that the WG
should not be making promises about a document that was not part
of its work program.  That made sense to me, so we removed it.
But I don't feel at all strongly about it so, if you, Barry and
others want such a placeholder reference, I'm happy with that.
 
>>> Minor comments:
>>> 
>>> The draft header indicates that this document obsoletes
>>> RFC3044 and RFC3187, but the abstract doesn't mention this,
>>> which it should.
>> Disagree.  Those are informational documents, not standards
>> track ones, the abstract correctly reflects what the document
>> does, and the relationships are carefully explained in Section
>> 2.  Cluttering up the abstract by putting in those RFC numbers
>> seems neither desirable nor appropriate and this should
>> reasonably be an editorial matter under the control of the RFC
>> Editor, not something specified by the IESG.
> 
> Rather than engaging on the broader topic of indicating
> Obsoletes and Updates in the abstract in general, I'll point
> out that *this* document is paired with a request to
> reclassify 3044 and 3187 as Historic. There is long-standing
> IESG guidance on this topic
> <https://www.ietf.org/iesg/statement/designating-rfcs-as-histo
> ric-2011-06-27.html>, which includes the provision "If authors
> wish to change the status of RFCs that are in the obsoletes
> header to Historic, then the authors must include an explicit
> statement for the RFC editor to do so; *preferably in the
> abstract and introduction*."

There is an explicit statement in the Introduction.  It does not
use the word "Historic" (that is in Section 2).  If you believe
the document would be improved by changing the relevant sentence
in the Introduction to say "Obsoletes the separate RFCs and
makes them Historic...", that change is easily made (and,
frankly, should be have long before this, but no one caught it).
I believe there are documents where there is good reason to
include RFC numbers in the abstract but this is not one of them.
I also note that RFC Editor rules against putting citation
anchors in abstracts causes every such included RFC number to
violate your preferred citation rule because those numbers not
only do not have citation numbers but are the first textual
references to those numbers in the document.   If "preferably"
is turning in "mandatory", we need to have two discussions, one
about the authority boundary between the IESG and the RFC Editor
and the other about where in RFC 2026 and its updates the IESG
is given authority to make policy by issuing statements rather
than determining and reflecting IETF community consensus.

> You may, of course, choose to ignore this officially stated
> IESG preference, but doing so would unnecessarily go against
> convention.

See above.  I am not ignoring it.  I have carefully considered
it and concluded that it is inappropriate for the abstract in
this case, a conclusion with which no one in the WG has
expressed disagreement.  As to "go[ing] against convention", I
believe that a careful survey of documents since that statement
was issued would not show that the "preference" has been
consistently enough followed to constitute normal behavior, nor
that this is a "preference" that the RFC Editor is enforcing.
If this were really close to a firm rule, I would expect the RFC
Editor to "correct" every deviation during their editorial
process, allowing any issues to be sorted out on AUTH48, just as
they enforce, e.g., references without citations.

> In terms of RFC Editor policy: while the RFC Style Guide does
> not explicitly require obsoleted RFCs to be listed in the
> abstract, I find it rather telling that it does, itself, do
> so. This is quite possibly because RFC Abstracts (according to
> said style guide) are required to give a "concise and
> comprehensive overview of the purpose and contents of the
> entire document," and some substantial portion of the purpose
> of *this* document is obsoleting existing RFCs -- thus failing
> the "comprehensive" portion of that requirement. So while it
> may well be outside my purview as a member of the IESG to
> require you to fix this defect, it seems quite probable that
> you'll have this conversation again with a member of the RPC
> in a short while.

The "comprehensive" part of that requirement is arguably a poor
choice of words (I will get an erratum filed later today), but
the paragraph that follows (RFC 7322, Section 4.3) makes this
perfectly clear (at least to me) that the Abstract is a matter
of professional and editorial judgment, not something that
should become long or confusing in the interest of covering all
aspects of the document completely.   The paragraph after that,
requiring that the Abstract be complete in itself, prohibits
citations, implying that people should not have to look at other
documents to understand the abstract.  However, a statement such
as "This document makes RFC 3044 Historic" is a citation (even
though it doesn't have an explicit anchor) and conveys no
information unless one knows what 3044 refers to (see below
about well-known numbers).

Again, I believe this is an editorial judgment call.   I believe
that, had I been editing the Style Guide, I would have included
the number of the previous one in the abstract and, since that
preference was announced and despite my misgivings about
citations in abstracts, I have generally included the numbers
when a new document completely replaces an old one (or more than
one) and/or when the previous spec is widely known by its
number.  However, those criteria identify both of the issues
that have caused me to make a different judgment in this case:

(1) Unless the previous document was widely known by its number,
as distinct from being known by a name or not being well-known
at all, I dislike, as an editorial matter, including RFC numbers
in abstracts without explanations.  The reason is closely linked
to the RFC Editor decision to not allow citation anchors in
abstracts (a decision that is supported by some, but not all,
more generally used style manuals).   If the goal of an abstract
is to provide information to the casual reader about what the
document is about, "clarifies the status of relevant older RFCs"
(or even "clarifies the status of relevant older RFCs. including
making the ones describing the ISBN and ISSN URNs historic", a
change I'd happily make if you felt it would improve things)
does that and fulfills  a reasonable interpretation of the
"comprehensive" requirement without folding the entire document
into the abstract (which might be required by another
interpretation of "comprehensive").  

(2) Under most circumstances in which one document replaces (and
obsoletes) another, the new document contains all of the
information in the old one and/or explains what it changes.  If
that type of relationship and explanation is present, there is a
strong argument for reflecting that (number or not) in the
abstract as part of being "comprehensive".    However, in this
case, the substantive replacements for the substantive parts of
RFCs 3044 and 3187 are not in the text in this document.  This
document describes the changes in general terms, but the
replacement specifications are the new templates.  Specifically,
I disagree with your conclusion that "some substantial portion
of the purpose of *this* document is obsoleting existing RFCs":
a substantial portion of the document explains why the templates
make the existing RFCs de facto obsolete, but the only sense in
which it obsoletes them is a narrow procedural one on which it
does not spend much text.  Noting that there is no procedure for
an IANA registration to obsolete an RFC, when we assumed that
this document would be published before those templates were
agreed-to and posted, there was some convoluted text in earlier
versions of this I-D about not obsoleting 3044 and 3187 until
the new templates were registered, text that presumably would
have made this conversation even more "interesting".

Situations in which a new document obsoletes all or part of an
older one as part of, e.g., defining a new strategy have always
been problematic in the IETF, with, e.g., frequent problems
about references, sometimes normative, to sections of the older
document that were not addressed anywhere.  In large measure,
this document was produced to avoid that problem for the
relevant URN namespaces, a goal I hope the IESG would welcome.

I note for purposes of comparison that RFC 8141 obsoletes RFCs
2141 and 3406 in the more traditional sense.  The new
specification covers all of the same ground as the older ones
and there is no substantively-interesting text in the older ones
that is not replaced or repeated by text in the new one.  In
addition, 2141 and 3406 are fairly widely known by their
numbers.   And the older documents are listed by number in the
abstract.

The above suggests another alternative, one that I would
recommend if the current preference of the IESG is to make more
work for the community and itself in the interest of favoring
form over function.  This document could be divided into two
parts, one of which would be a simple explanation of the changes
and relationships, that wouldn't obsolete anything (although it
would provide the motivation for doing so), and that could be
published as Informational.  The other would be a very short,
standards-track document that would obsolete the ISSN (3044) and
ISBN (3187) RFCs and make them Historic, reference the first one
and the templates informatively, contain the RFC numbers in the
abstract because that would be its main purpose, etc.   We
didn't do that because we believed it would be more confusing
for users, in part because we don't have a good way to link such
documents together and reflect current status (another decision
of a long-gone IESG), but it was a conscious decision.  Of
course, splitting things up at this point would require new
I-Ds, probably a new WG review/ LC, a pair of IETF Last Calls,
and then new IESG actions.    But, again, if that is what the
IESG, it its wisdom, wants and how the IESG believes the
community can best spend its time, I'm willing to break the
document apart so that it is possible.

regards,
    john