The numbering is problematic for many reasons, people have difficulty keeping
two sets of numeric identifiers straight. If you want me to refer to something
other than RFC-822 you have to give me something more memorable to both myself
and the audience I am attempting to communicate to.
STD23 does not do it for me
If you want to introduce an alternative identifier that people are likely to
use use something of the form IETF-SMTP-2008
This has the additional advantage of reminding folk when a protocol standard
has maybe continued for too long without a maintenance session. It also creates
added incentive to deploy new protocols.
Consumers don't know what IPv6 is or why they might want it. But an ISP
offering an Internet connection supporting IETF-IP-2008 is probably going to be
somewhat more successful than one that only offers IETF-IP-1981.
Marketechture,
________________________________
From: Brian E Carpenter
[mailto:brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com]
Sent: Thu 06/12/2007 3:18 PM
To: John C Klensin
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Revising full standards
John,
On 2007-12-07 05:20, John C Klensin wrote:
Hi. I had intended to bring this up at the plenary last night
but, since I had not raised it on the list and was tired,
decided not to.
Our standards process (RFC2026 and updates) more or less assumes
that documents progress from idea -> I-D -> Proposed -> Draft ->
Full. Ignore, for now, the question of how much we use all of
that (and why we don't do so often enough). When the rules
associated with that progression are applied to an update to a
full standard -- a protocol that is widely deployed, tested by
much use and independent implementations-- things get a little
strange. For example:
* 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.
* It is not quite clear what implementation reports and
interoperability testing mean. Presuming that the
original spec doesn't count and the update is completely
new would be a major triumph of procedure over good
sense. But...
There are other issues but, in the interest of keeping this note
short, I'll leave them for another time.
So, three questions:
(1) Does the community think this is a problem worth solving?
If the answer is "no", then trying to write up a proposal is
clearly a waste of time.
Yes. I think the STD numbering issue is extremely confusing to
outside users of our standards. I hadn't noticed the interop
testing hiccup, but that's also a valid concren.
(2) Assuming a draft and mailing list are created, are people
willing to review and contribute? Do we need to start thinking
in terms of a WG for this issue alone? (Experience with NEWTRK
suggests to me that a WG with a broader charter would be a bad
idea.)
I'm willing. I think it could be done without a WG if the focus
is kept very narrow. Without wanting to get into solutionism,
let me note that the STD numbering issue is mentioned in
draft-carpenter-rfc2026-changes-01.
Brian
(3) Would the IESG be inclined to look on a proposal -- either a
request to Last Call a draft document or a WG request, depending
on (2)-- with favor? If the answer is, as it was with some
NEWTRK work (which, incidentally, would have eliminated this
problem), "we would rather you didn't pursue that", then I don't
believe this is a rock that we should start pushing uphill.
john
Disclaimer: rfc2821bis, now in last call, would clearly have
benefited from some changes along this line and thinking about
issues associated with it definitely got me motivated to think
about the problem. But it is already in Last Call, so any
changes that are made to the procedures will not affect its
processing in any way (although they might ultimately effect how
it, 821, 2821, and STD10 are identified).
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf