From: Brian E Carpenter [mailto:brian.e.carpenter@xxxxxxxxx]
Sent: Thu 06/12/2007 3:18 PM
To: John C Klensin
Cc: ietf@xxxxxxxx
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@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf