At 08:07 AM 7/19/2011, Ned Freed wrote:
This is one of the reasons why I prefer to see such restrictions lifted
in separate documents. Once the separate document (which can either be
one limited to removing the restriction or something more general) advances
the restriction can be removed from the original document without a reset.
One of the questions when advancing documents along the Standards
Track is whether it makes sense for such a move when there are
changes that may affect the document status. In this case, the
alternatives are:
(a) Have a Full Standard and a Proposed Standard document that
lifts the restriction
(b) Stick to the charter and work on the Full Standard document only.
(c) Work on the Proposed Standard document only given that there is general
agreement that the restriction should be lifted.
More generally, this is another case of the stuff that John has been talking
about on the IETF list: Our processes have not kept up with the complexity of
our present documents. Back when documents were, on average, much simpler, it
may have made sense to reset an entire document or group of documents to
proposed simply to make a tweak like this, but these days it's causing more
problems than it solves.
There can be some confusion in terms of which specification to
implement when alternative (a) is chosen. My take is that "the IETF
is aiming at long-term stability of the specification and you can
expect that the IETF won't change an implementation requirement
overnight". It's up to the implementer to determine whether to go
with the tweak or not. For all we know, the tweak may end up causing
problems or it may require fine tuning.
With alternatives (a) and (c), the work would have to be done outside
the working group. One of the paragraphs from the proposed WG
charter mentions that:
"However the WG might reach consensus that certain changes have to be
done in order to remove restrictions which were proven to be problematic
in the field, or which restrict evolution of the protocols."
The working group would not be allowed to work on alternative (c) if
its output is restricted to Full Standard documents
only. Alternative (a) is a viable approach if the working group is
to consider the complexity of the documents identified as work items.
Regards,
S. Moonesamy
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
