ietf
[Top] [All Lists]

Re: 2119bis

2011-09-01 18:42:21
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(_at_)harvard(_dot_)edu> 
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>