On 5/30/11 7:39 PM, SM wrote:
At 16:20 30-05-2011, Pete Resnick wrote:
So, here is my a proposed alternative:
1. Make the changes in (A). We still need to say how to make that
happen, and how to deal with the increased number of RFCs.
The annual review provides an alternative to deal with the increased
number of (non-historic) RFCs. A "no substantive objection" clause
might enable the removal of "drive-by" RFCs.
My concern was not the absolute number of RFCs. It is that, if we go
back to something like 2026 criteria for Proposed, we should expect a
bunch more revisions of RFCs (since we will find bugs that need to be
fixed), and that may put an awful lot of pressure on the RFC Editor.
Because the changes are likely to only be specific bug fixes and not
total rewrites, perhaps the RFC Editor might be OK with only checking
the new parts and not worrying about the old ones. But this is not
addressed at all in the current document and needs to be.
2.2(b)(iii) - I would prefer that this be amended to "All unused
'MUST' requirements will be changed to 'SHOULD' requirements." If
deployment is interoperable and a feature is unused, it means that
the feature was not actually REQUIRED for interoperability. I object
to this as it stands.
That's one way to deal with RFC 2119 creep. I'll go one step
further. If there is a significant number of implementations that do
not implement a SHOULD, the feature can be removed. The resulting
specification might be easier to implement once the amount of
requirements are reduced.
This to me is wordsmithing. The current text says that you remove the
ones that "greatly increase implementation complexity." You're
suggesting removing ones that "might" make it harder to implement. I
think there's probably a happy median in there someplace.
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Ietf mailing list