Subject: Re: 2119bis

From: Donald Eastlake <[email-masked]>
Date: Thu, 1 Sep 2011 10:49:01 -0400

I do not believe there is any need to change RFC 2119.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Wed, Aug 31, 2011 at 9:28 AM, Scott O. Bradner <[email-masked]> wrote:
> I've been traveling so have not had a chance to do anything but watch
> the discussion on a RFC 2119 update.
>
> a few thoughts
>
> 1/ I am far from convinced that there is a need to update RFC 2119
>      there is a bug in the boilerplate (as has been mentioned)
>      and some people seem to have a hard time understanding what
>      (to me) seem like clear descriptions of (for example) MUST &
>      SHOULD - but the issues do not seem serious enough to warrant
>      replacing what is, basically, a simple dictionary & usage
>      constraint
>
> 2/ it seems like a very Bad Idea to move 2119 to historic- we move
>     RFCs to historic when no one uses them or when they are a Bad
>     Idea in light of updated technology - I do not think that makes
>     much sense in this case - in addition it makes the status of RFCs
>     that have a normative reference to a historic document a bit
>     funky - if an update is actually needed there is no reason that
>     I can come up with that it could not just be that -- an update
>
> 3/ I doubt that I'll ever catch up with Postel as the most referenced
>     RFC author so that is not a consideration (for me)
>
> I wrote RFC 2119 (most using text from RFC 1122) because people were
> using MUST without saying what they meant, an update, if people think
> that one is actually needed, will serve that purpose as well as 2119 has.
>
> When I posted the original ID it was pointed out that I should also
> address when such terms should be used (i.e. try to limit the use to
> where it actually made sense protocol-wise) - I tried to do that but
> that part may not have been as successful as it might have been - any
> update might try to be clearer in this area that RFC 2119 is.
>
> Scott
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 01 Sep 2011 08:10:22 -0700

> I do not believe there is any need to change RFC 2119.
...
> On Wed, Aug 31, 2011 at 9:28 AM, Scott O. Bradner<[email-masked]>  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

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Sep 2011 11:54:04 -0400

--On Thursday, September 01, 2011 08:10 -0700 Dave CROCKER
<[email-masked]> wrote:

>...
> 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/.

I agree completely.

Please apply this logic to draft-housley-two-maturity-levels, of
which you are a co-author.

     john

---

From: Bob Hinden <[email-masked]>
Date: Thu, 1 Sep 2011 13:57:04 -0700

> I do not believe there is any need to change RFC 2119.

+1

Bob

---

From: Michael StJohns <[email-masked]>
Date: Thu, 01 Sep 2011 19:41:28 -0400

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:

>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

---

From: Hector <[email-masked]>
Date: Thu, 01 Sep 2011 20:55:52 -0400

Michael StJohns wrote:

> 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.
> 
> "A DNSSEC aware recursive resolver SHOULD set the CD bit in an 
> upstream query UNLESS specifically configured by policy not to"
> 

Good points, but the subtleties are too wide spread to generalize, 
especially dealing with integrated protocols and now there are 
boundary layers related issues.

For example:

    DKIM MUST|SHOULD|MAY validate its input stream for illegal
    multiple 8222.From fields because this has been shown to cause
    a potential security exploit.

or you can pass the buck in the name of fast tracking PS to IS, cross 
the border with this concept:

    SMTP Receivers MUST|SHOULD|MUST check for valid RFC5322 input
    before feeding the stream to DKIM.

Some people view this as a boundary layer problem, others don't.

Some people (like me) see it a major security problem that negates 
DKIM goals hence from an Software Engineering, Black Box IN/OUT 
concept, believe DKIM has responsibility to validate its key input 
fields especially when DKIM already had a strong security related mandate:

     DKIM MUST hash-bind the 5322.FROM header to the signature.

And it is an RFC5322 violation to have two or more 5322.FROM fields.

But some believe its a boundary layer issue, don't believe its a 
responsibility for security-based protocol called DKIM to make sure 
there is no security violations in its blind input of RFC5322 data.

In this case, a SMTP server will probably do already, but can't 
guarantee this? I don't think so and even when it does, there are 
known illustrated cases where DKIM was used to bypass the SMTP RFC5322 
check and as a result a double 5322.FROM were possible where the fake 
5322.From was displayed to the user and DKIM signature was still valid 
by hashing the original, but now hidden, 5322.From field.

Go figure.

--
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Sep 2011 09:39:09 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector
> Sent: Thursday, September 01, 2011 5:56 PM
> To: Michael StJohns
> Cc: IETF Discussion
> Subject: Re: 2119bis
> 
> [...]

So this protracted (and, in my view, hijacked) sound-and-fury thread about concerns with interpretation of RFC2119 and the rough consensus process, and hints about an activist Area Director, is really just a platform to vent your frustration with a decision made in a working group where you were in the minority?

The issue to which you're referring closed months ago.  After a long battle, some compromise text was reached that included some of what you advocated, which during IESG evaluation drew a DISCUSS and it was rolled back before being approved for publication.  This is all recorded in the archives.

It really is time to move on.

---

From: Hector <[email-masked]>
Date: Fri, 02 Sep 2011 14:54:38 -0400

I take a offense to your blabbing which just puts people on the defensive.

The fact is, your are incorrect in your continue personalization. The 
topic includes examples of problems where this RFC2119Bis enforcement 
is being sort, which quite frankly, you have been very much been part 
of that push. I do understand why you want everyone to upgrade their 
software to meet your needs, but you seem to lack the understanding 
that you just can't do it the way you want to, hence why there are 
delays in your publication, and DKIM is still an accident waiting to 
happen.

Ciao