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

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

Ben,

(top post and I hope brief)

Thanks.  Glad we are back in synch on the "obsolete" part.  I
think (and, IIR, the WG thought) that historic would be
appropriate because those documents are part of the history of
URNs and those particular namespaces.  If the IESG concludes
differently, I'm unlikely to lose much sleep over it.

I thought this had been discussed recently (in some form) on the
IETF list, but one problem with treating "obsolete" as "don't
read this" is that we've got documents floating around that are
very much alive and active (IIR, even a few full standards) that
contain normative references to material in "obsolete" documents
that has not been copied into the successors of those documents.
In some cases, that has occurred because the newer documents are
not replacement-type updates of the same general protocol spec
but are, instead, a new spec that makes the older one obsolete
and irrelevant... except for the things that depend on the older
one.  This may be a problem of not enough granularity in the
categories.  Or, if the last WG that I remember trying to
consider it was right, we need to junk the whole "obsoletes"
(and probably "historic" and maybe "updates") business and start
doing relationship summary documents and/or applicability
statements that can describe what is going on rather than
reducing things to a handful (or fewer) of categories.

I have been thinking about those issues for rather a long time
and would be happy to be part of an effort to sort them out if
the IESG ever wants to do so, but hope we can deal with the
general issue when the time is right rather than trying to
construct policy around one, already somewhat unusual, document.

best,
    john


--On Wednesday, August 2, 2017 21:14 -0500 Ben Campbell
<[e-mail]> wrote:

> 
>> On Aug 2, 2017, at 7:39 PM, John C Klensin <[e-mail]>
>> wrote:
>> 
>> 
>> 
>> --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-tr
>>> an 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.
> 
> Since I wrote that comment, I've found examples of other
> RFCs that declared previous RFCs obsolete, without containing
> the "replacement" material. I personally find that
> confusing, since I have always interpreted the "Obsoleted
> by" tag on an RFC to mean "don't read this, read
> that.". But I guess it's not insane for the "that" in
> that sentence to redirect to somewhere else. In this case, I
> was thinking "obsolete" didn't make sense due to a
> misreading of the IANA considerations. (details below.)
> 
> I even found an example that did that and also made the target
> RFC historic. But I am still confused over what that means.
> (more below).
> 
> 
>> 
>> 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.
> 
> I agree the categories are vague, so the best we can do is
> think in terms of common usage. I tend to think of an
> "obsolete" RFC is one that people should not need to read,
> and that we might even delete or replace with a tombstone if
> not for the fact we treat RFCs as immutable.
> 
> On the other hand, I think of "historical" to mean that
> the RFC is no longer in use for its original purpose, but may
> be of historical interest of instructive for other reasons.
> 
> Making an RFC both at the same time confuses me, because those
> definitions seem contradictory. I recognize other people may
> have different definitions.
> 
> So the bottom line is, you've convinced me "obsolete" is
> appropriate, but I'm now less convinced about
> "historical".
> 
> 
>>  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.
>> 
> 
> You will note I did not ballot DISCUSS. Nothing in my comment
> blocks advancement unless the authors and/or sponsoring AD
> decides it should.
> 
> 
> 
>> 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.
> 
> Apoligies, this was a misread if the IANA considerations on my
> part. I incorrectly conflated the statements there that IANA
> would have both old and new templates to mean old and new
> templates for the obsoleted RFCs. On reflection, that's
> clearly nonsensical, and I realized that over dinner even
> before I got back online and saw your email :-)
> 
>> 
>> 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).
>> 
> 
> To summarize: I am convinced that they are obsolete. I have a
> mild objection to also calling them historic, but I'm not
> going to stand on that.
> 
> Ben.
> 
> 
>>> And also mention that in the abstract :-) .
>> 
>> See separate note. 
>> 
>>    john
>> 
>