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 PROTECTED]> 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 protected]
https://www1.ietf.org/mailman/listinfo/techspec



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

Reply via email to