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" clause.
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" vs either
"A DNSSEC aware recursive resolver MUST set the CD bit in an upstream query"
or
"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 justification... :-)
Mike
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@xxxxxxxxxxx> wrote:
>...
>>>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/.
>
>d/
>--
>
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>_______________________________________________
>Ietf mailing list
>Ietf@xxxxxxxx
>https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf