Subject: Re: [Techspec] New requirement for early permanent ID allocation

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Mar 2006 09:40:51 +0100

I think we're at risk of confusing two identifiers:
RFC 9999 and STD 999.

As I've just said on the newtrk list, I think John is on the
right track for STD 999 type identifiers. But I took this
requirement to refer to RFC 9999 type identifiers. As Humpty
Dumpty would explain better than me, they're different.

    Bria

John C Klensin wrote:
> On  23 February, 2006 10:04 -0500, I wrote (text deleted from
> the earlier note marked with "[...]")...
> 
> ------- Earlier note ----------
> 
> Two (separable) comments/issues and an aside...
> 
> --On Wednesday, 22 February, 2006 17:18 -0600 "Stephen Hayes
> (TX/EUS)" <[email-masked]> wrote:
> 
> 
>>Early permanent ID allocation is not something currently done
>>in the IETF.  Although there is already a potential
>>requirement to do this, implementing it will imply yet another
>>new potential requirement on the technical publisher.
>>
>>o Potential Req-INDEX-7 - When an permanent ID is allocated
>>early, the technical publisher must provide a disclaimer and
>>pointer in the index to resolve searches on that permanent ID.
>>The post approval version of the draft must be stored until
>>the document is published since it could expire before
>>publication.
> 
> 
> [...]
> 
> The relevance of the Identifier, how it is assigned, etc., is a
> current NEWTRK work item, embedded significantly in the "ISD"
> work and somewhat so in the "SRD" work.  Both would provide
> alternate models to needing more disclaimers that, based on
> historical experience, would probably be generally ignored.
> Until and unless NEWTRK is terminated and a plausible
> disposition made of its outstanding tasks, it seems
> inappropriate to me for this non-chartered effort to reach
> conclusions in this area other than, possibly, to make
> recommendations to NEWTRK.
> 
> [...]
> 
> 
>>It is also recommended that the technical publisher retains
>>control of the allocation of permanent identifiers.  This is
>>especially true when multiple organizations (IESG, IAB, IRTF)
>>share a single identifier sequence.  One way that this might
>>work is for the IESG to request "publication" or "publication
>>with early allocation"
> 
> 
> Please separate this into a separate issue.  To the extent to
> which we are going to maintain multiple sets of numbers, some of
> which apply to subsets of the others, the standards-track
> reference ID (currently STD, but its assignment only to Full
> Standards is another NEWTRK issue) and other reference IDs
> should arguably be controlled directly by some IASA-associated
> entity or contractor that is different from the technical
> publisher.  I understand this effort to be defining a "technical
> publisher" role.  If that role is to be one of a publisher,
> rather than having broader standards-management functions, then
> we had better be _very_ careful about what the IDs are and who
> assigns them.
> 
> And, again, who assigns the identifier is a very different issue
> from when  that identifier is assigned.
> 
> [...]
> 
> --- End of earlier note ----
> 
> In the interest of stimulating discussion where it belongs, I
> have just queued an I-D titled "Identifying Standards Track
> Documents",
> draft-ietf-newtrk-docid-00.txt, that addresses these issues and
> provides for assignment of stable identifiers for
> standards-track documents not later than the Protocol Action for
> Proposed Standard.  Because this is a simple issue and a simple
> proposal, the I-D violates what most consider to be my usual
> practice: exclusive of front and back matter, it is
> significantly under four pages long.
> 
> I have written the proposal up as a change, not a process
> experiment.  It occurs to me that, were a different Standards
> Identifier prefix chosen, it could be structured as a process
> experiment if people wanted to do that.  I'll leave that for
> discussion in NEWTRK or elsewhere (and this comment will be more
> clear after one reads the draft).
> 
>      john
> 
> 
> _______________________________________________
> Techspec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/techspec
> 

_______________________________________________
Techspec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/techspec

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Mar 2006 08:34:45 -0500

> Dumpty would explain better than me, they're different.

I have made a leap here, which I clearly should have been more
explicit about.  My apologies.

Explanation: I'm trying to look at Techspec through a "figure
out what the problem is and then how to solve it" perspective
rather that a "how to tune what we are doing now" one.  We've
been repeatedly encouraged to do that.   So I read the
description of this issue/ requirement, saw what "permanent
IDs", especially early ones, were for, and got "these are
identifiers of the _standards_, not identifiers of the
documents".

Now, if one wants to identify the standards, then the right
target is, IMO, offspring-of-STD and not a serial document
number (which the RFC 9999 numbers ultimately are).  And it
appears to me that we need those stable standards-reference
numbers (or standardized acronyms, or whatever we use -- another
newtrk topic) regardless of what we do about the multi-step
standards model, i.e.,

	* If we keep the present system, we need to get stable
	standards-references assigned at Proposed (or earlier)
	because few things go to Internet Standard and those
	that do take a long time.
	
	* If we drop the number of maturity levels to two or
	one, we will still need a way to assign stable
	standards-reference numbers because of publication lag
	(even if it is short) and because we revise standards.
	
	* And, if we develop a way to fast-track Internet
	Standards on the basis of market acceptance, there is
	still a significant lag time while that market
	acceptance and experience develops and we therefore
	still need standards-reference numbers early on.

For the purposes of any of those references, especially by other
groups, assignment of serial document numbers is (or should be)
largely irrelevant.   The fact that we have been using them as
standards-identifiers and are talking about assigning them early
is, to me, more a sign that our standards-identifier system
--i.e., the STD numbers-- is broken and needs to be fixed, not
that we need to devise a new system for serial document numbers.

      john

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Mar 2006 10:24:09 -0800

At 8:34 AM -0500 3/1/06, John C Klensin wrote:
>So I read the

Another way to say this is that we are required to have a naming 
system for documents, and are required to have a naming system for 
standards. Documents that are not standards will have a name only in 
the first, while documents that are standards will have a name in 
both.

 From the Techspec perspective, there is not a requirement for how the 
naming system for standards is organized, nor when the names in the 
naming system for standards are allocated.

IESGers: do the external bodies who want permanent identifiers need 
all of the identifiers that will be associated with the document (the 
document naming system *and* the standards naming system), or just a 
document identifier?

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Mar 2006 14:30:25 -0500

--On Wednesday, 01 March, 2006 10:24 -0800 Paul Hoffman
<[email-masked]> wrote:

> Another way to say this is that we are required to have a
> naming system for documents, and are required to have a naming
> system for standards. Documents that are not standards will
> have a name only in the first, while documents that are
> standards will have a name in both.

That description makes me vaguely uncomfortable for some reason,
but I don't find anything in it with which I disagree.

>  From the Techspec perspective, there is not a requirement for
> how the naming system for standards is organized, nor when the
> names in the naming system for standards are allocated.

Agreed.  That is why I suggested in an earlier note that this
was a Newtrk issue.
 
> IESGers: do the external bodies who want permanent identifiers
> need all of the identifiers that will be associated with the
> document (the document naming system *and* the standards
> naming system), or just a document identifier?

Having been in the liaison loop to one or two of them, here is
where I think we get hung up.   What we have effectively told
them is that there is no standards-identifier until very late in
the process (years or never) and, consequently, if they need
something to reference for standards they have under
development, it is the document identifier.  In the current
system, that would be the case even if 2026 were being followed
scrupulously and every Proposed Standard that we were not going
to discard was published at Internet Standard within 10 to 11
months.   The result is that they are asking for document
identifiers.  I suggest that is profoundly broken and that the
solution is not earlier assignment, or other juggling, of
document identifiers.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Mar 2006 11:53:57 +0100

> <[email-masked]> wrote:
...
> solution is not earlier assignment, or other juggling, of

As Stephen wrote, what they *use* is the RFC number. I think that's
because we've trained them that RFCs never change, so they are excellent
stable references (much better than some things we refer to very
loosely sometimes, such as "ASN.1" or "Unicode", whatever they may be.)

What they may well want is STD-999.ps, but we haven't ever offered
them that. (This terminology refers to draft-ietf-newtrk-docid).

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Mar 2006 11:52:04 +0100

John, I find myself in complete agreement with you.

In the techspec context, I think the basic requirement
remains that the publisher follows IETF instructions on
how to assign identifiers, and assigns them as early
in the processing of a document as the IETF requests.

And we should note for clarity that identifiers may come
in multiple types, exactly as you say.

I think that for defining contractual requirements on
the publisher, that is sufficient.

    Brian