ietf
[Top] [All Lists]

Re: Revising full standards

2007-12-10 13:25:05


--On Monday, December 10, 2007 11:16 AM -0800 Bob Braden <braden(_at_)ISI(_dot_)EDU> wrote:



        * The RFC Editor discovers that the community doesn't
        quite know what to do with the STD number: It can't be
        reassigned to the new document because it is at
        Proposed.  I shouldn't be left on the original
        document because it really isn't our latest and best
        thinking on the subject.  And it shouldn't be
        withdrawn because that leads to silly states in
        documents that have been written to call on "STD 999"
        precisely because those numbers were expected to
        refer to current specs.

As I told you at IETF, I believe we can temporarily patch this
problem by adding information to
http://www.rfc-editor.org/rfcxx00.html#STDbySTD; entries like:

RFC#: (none) STD#: 10    SMTP  Simple Mail Transfer Protocol
[Was RFC 821,
                                        obsoleted by RFC 2821
(Proposed Standard)]
RFC#: (none) STD#: 10    SMTP Service Extensions [Was RFC 1869,
                                        obsoleted by RFC 2821
(Proposed Standard)]
RFC#: (none) STD#: 10     Mail routing and the domain system
[Was RFC 974,
                                        obsoleted by RFC 2821
(Proposed Standard)]

But this might help newbies, but it would only be a patch.

It is only a patch. If you do it, it is not clear to me what the STD number (still) accomplishes.

The proposals (from others) to go to IETF-foo-2010 types of names solves one problem, but does not solve the problem of needing a _stable_ reference to the current state of a standard, nor the problem of assignment of designators to Proposed and Draft Standards. It, too, almost certainly requires an update to RFC 2026.

I see two fairly simple ways out of this. I also see opportunities for a whole series of better solutions, but any of them would require some serious writing and discussion. IETF-mnemonic-date is included in that list because dates would need either resolution to days or a suffix and we'd have to decide whether normative errata changed the dates.

The simple ways:

(1) Decide that STD numbers raise too many complex issues and just drop them, despite the desire for a standard reference.

(2) Assign STD numbers to Proposed Standards, retaining them through the process and permitting the STD number to shift to a Proposed Standard that replaces a Full one. Note that I proposed essentially that in draft-ietf-newtrk-docid-00, but it followed ISDs down the NEWTRK hole.

More complex ways include completely different identifier models (see above), pulling ISDs out of the trash bin, pulling "rfc sets" out of the trash bin, or trying to patch the various indexes to simulate one or the other of the latter two.

And, to be a little more explicit than my earlier note was, I think the entire discussion is a waste of time until the IESG spends a few minutes deciding what sorts of proposal they would take seriously enough to process. I'm unlikely to spend more time on this until they do.

    john



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>