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

From: Ben Campbell <[email-masked]>
Date: Wed, 02 Aug 2017 16:01:29 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-urnbis-ns-reg-transition-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

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-transition/

----------------------------------------------------------------------
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. 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.

Instead, I think it would make more sense for this draft to just change their
status to historical, but not obsolete them. And also mention that in the
abstract :-) .

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Aug 2017 20:39:34 -0400

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

>...
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html for
> more information about IESG DISCUSS and COMMENT positions.
> 
> 
> --------------------------------------------------------------
> -------- 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 Aug 2017 19:40:52 -0600

A small comment on one point...

> --On Wednesday, August 2, 2017 16:01 -0700 Ben Campbell

<snip/>

> part of RFC 8141, so, if there is an issue, it isn't with this

With my RFC 8141 co-author hat on, I concur. There is no transition
period in general, and there is no transition period for any particular
namespace because if the registration is updated (e.g., from version 1
to version 2) then the old registration is immediately outdated as soon
as the new registration is placed in the registry by IANA. IMHO this is
clearly spelled out in RFC 8141 (and RFC 3406 before that).

Peter

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Aug 2017 21:14:46 -0500

> On Aug 2, 2017, at 7:39 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

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).

> 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

You will note I did not ballot DISCUSS. Nothing in my comment blocks advancement unless the authors and/or sponsoring AD decides it should.

> part of RFC 8141, so, if there is an issue, it isn't with this

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 :-)

> definitions of still current (or not-obsolete, if that is

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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Aug 2017 21:15:43 -0500

> On Aug 2, 2017, at 8:40 PM, Peter Saint-Andre <[email-masked]> wrote:
> 

Yes, that was a mistake on my part (see my response to John). In my defense, I’ve reviewed a lot of documents over the past couple of days and my brain was tired :-)

Ben.

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Aug 2017 23:35:21 -0400

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
<[email-masked]> wrote:

>>> 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.
>> 
>> "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:
>> 
>> 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).
> 
> 
>> 
>> discussion, both independent of my specific concerns with
>> Adam's DISCUSS and the associated logic, which I will address
>> separately.
>> 
>> 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
>> 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.
> 
> 
> 
>> 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
>> Whoops!   I either don't understand what you are saying above
>> or it indicates one or more series editorial or explanatory
>> 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 :-)
> 
>> 
>> 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.
>> 
>> 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.
> 
>