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

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

--On Wednesday, August 2, 2017 16:01 -0700 Ben Campbell
<[e-mail]> wrote:

>...
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html for
> more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found
> here:
> https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-tran
> sition/
> 
> 
> 
> --------------------------------------------------------------
> -------- COMMENT:
> --------------------------------------------------------------
> 
> I have a different take on Adam's discuss point. I don't think
> its appropriate for this draft to both obsolete 3044 and 3187
> and make them historical. This draft doesn't replace them.

First of all, you are absolutely right.  This document doesn't
"obsolete" (note that a verb only in IETf-speak) either 3044 or
3187.   That doesn't mean that they are anything but obsolete,
but what gets them into that state is the combination of:

 * Changes, by ISO, in the underlying standards for the
	relevant identifiers.
	
 * The language in RFC 8141 that makes the templates
	normative for definition of URN namespaces rather than,
	e.g., RFCs that describe those namespaces.
	
 * The submission, by the namespace registrants/ managers
	for ISSN and ISSN, of templates to IANA as specified by
	RFC 8141 and the acceptance and recording by IANA of
	those templates for those namespaces.

The reason for moving the existing namespace description and
registration document to Historic is to prevent confusion about
what constitutes the current spec.  I (and I think the WG)
thought it would be less confusing to identify them as obsolete
and create the usual forward pointers to a document that
explained what was going on even if that document doesn't do any
"obsoleting".  If the IESG believes that 3044 and 3187 should be
Historic but not obsolete, go for it.  However, before doing so,
note that state would not make any entry in the RFC Index
pointing to an explanation, possibly leaving readers with the
impression that the URN namespaces for ISSN and ISBN had simply
be discontinued.

To me, there are two fundamental problems underlying this
discussion, both independent of my specific concerns with Adam's
DISCUSS and the associated logic, which I will address
separately.

The first is that it has become increasingly clear in the last
few years that, while the "Obsolete" and "Historic" categories
are adequate for many obvious cases, they are only vaguely
defined, with a number of problematic edge cases.  Based on
exchanges on the IETF list that are not directly related to this
draft, the IESG is aware of those issues, but, at least as far
as I know, has not made a serious attempt (such as trying to
initiate a WG with appropriate focus) to get them resolved,
introduce additional categories or guidance, etc.  Given that
situation. getting into a situation in which advancement of
document is questioned because of some particular theory about
the definition of "Obsoletes" seems to me to be of questionable
appropriateness.   YMMD, of course.

Second, and in my opinion more important, the WG discussed and
understood the relationships involved here.  It concluded that a
"transition" document of this type was appropriate to provide an
explanation of the relationship between namespaces created/
registered under RFC 2141 and either 2611 or 3406 and those
created under what is now 8141.  Making sure that there was no
ambiguity about the status of 3044 and 3187 (and, eventually,
3188) and new, 8141-compatible templates was an important
objective, and the decision to identify the earlier documents as
obsolete and historic was part of that.  

Over the last few decades, when I've been asked how the IETF is
different from most traditional standards bodies, one of the
answers I give most often is that we usually figure out what the
right thing is to do to get the results we want and them do it
rather than getting wrapped around assorted procedural and
make-work axles.   It seems to me that, in the absence of a
better set of categories and definitions, "the right thing for
the users and readers" is exactly what the WG was trying to do
here.  If the IESG has a better approach to recommend, that is
fine with me.  But, so far, it seems to me that your suggestions
(and Adam's) add work and would either make things more complex
or less clear.

> And
> since IANA may have to deal with a mix of old and new
> templates for some transition period, it doesn't remove the
> need for them.

Whoops!   I either don't understand what you are saying above or
it indicates one or more series editorial or explanatory
problems in this I-D, RFC 8141, or both.  For any given
namespace, there is only one template at any given time and IANA
has only one such template registered.  There is no transition
in IANA's scope and no need (or opportunity) for IANA to deal
with an old template and a new one at the same time for any
given namespace.    I assume that a template (again for a
particular namespace) could discuss transitions from an earlier
form, but that would be an intra-namespace issue, not anything
IANA needs to deal with or even be aware of.  The sense in which
IANA needs to deal with both old and new templates is that there
are namespaces defined under RFC 2611 or 3406 for which new
templates have not yet been provides (and may never be), but
that isn't a transition topic that IANA has to manage either
(and the procedures for having some older registrations
conforming to the old template and mechanisms and some
conforming to the new ones was carefully sorted out with IANA as
part of RFC 8141, so, if there is an issue, it isn't with this
document.

RFC 3044 and 3187 because inconsistent with the underlying
standards when those standard were published.  That doesn't make
them obsolete in the IETF sense, but it does make them a little
questionable as specs because it isn't completely clear whether
they consider the newer ISO specs normative or are still
dependent on specs ISO considers "replaced" and/or "withdrawn"
(categories that overlap with our "obsolete" and "historic" but
are definitely not the same as either).  They became obsolete by
any reasonable criterion when IANA replaced information based on
them, and references to them, in the registry by information and
references associated with the new templates.    However, as I
reminded Adam, an IANA registration cannot obsolete an RFCs,
some something was needed, preferably something that leaves
tracks.  Hence those aspects of this document even if it pushes
the usual boundaries of our practices in the interest of clarity
and good sense.

> Instead, I think it would make more sense for this draft to
> just change their status to historical, but not obsolete them.

But they _are_ obsolete.  The respective registration agencies
have specified new templates for the namespaces, the new
namespace rules are forward-compatible with the older ones, the
new templates reference the current standards which the old RFCs
do not, etc.  So I don't see what possible purpose, other than
promotion of confusion, could be served by treating the old
definitions of still current (or not-obsolete, if that is
different).

> And also mention that in the abstract :-) .

See separate note. 

    john