Hi Dave -
Mostly I think 2119 works well. But there are some interesting places where I
believe it doesn't and the interpretation of "SHOULD" is smack dab in the
middle of those places.
There are at least two different classes of things where "SHOULD" can be
applied: behavior and feature.
The feature "SHOULD" tends to have less to quibble about - "An SMTP server
SHOULD implement DKIM and 8BITMIME" - and tends not so much to need an "UNLESS"
The behavior "SHOULD" absent a description of the "UNLESS" clause tends to
have a bit more downside:
"A DNSSEC aware recursive resolver SHOULD set the CD bit in an upstream query"
"A DNSSEC aware recursive resolver MUST set the CD bit in an upstream
"A DNSSEC aware recursive resolver SHOULD set the CD bit in an upstream
query UNLESS specifically configured by policy not to"
That's just an example I'm particularly aware of (and the specific language has
a few more clauses).
I wouldn't suggest that 2119 become historical - there are way too many
documents dependent upon it. But we've cycled the IPR boiler plate numerous
times and required that new documents update to new standards. Having a
replacement for 2119 specifically include a discussion of an "UNLESS" clause
associated with "SHOULD" and replacing the pointer in new documents may
actually improve the quality of our documents.
And I can't believe you said "and this is the way we've always done it" as
At 11:10 AM 9/1/2011, Dave CROCKER wrote:
On 9/1/2011 7:49 AM, Donald Eastlake wrote:
I do not believe there is any need to change RFC 2119.
On Wed, Aug 31, 2011 at 9:28 AM, Scott O. Bradner<sob(_at_)harvard(_dot_)edu>
1/ I am far from convinced that there is a need to update RFC 2119
Predictably, the draft has prompted quite a few postings that seem to be
intent on re-inventing a core portion of the IETF documentation mechanism.
Folks should remember that this is a system that has been functioning quite
well for some decades and I am not aware of any recent emergencies that
justify starting over or making major changes.
The policy when seeking to change an established, essential, well-running
systems is to make as /few/ changes as possible, not as /many/...
Ideally, this means making no changes at all, of course. That is, any
proposal for a change MUST explain why the change is /essential/.
Ietf mailing list
Ietf mailing list