Re: Revising full standards

[Brian E Carpenter <brian.e.carpenter at gmail.com>]

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

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf