Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jun 2008 12:59:47 -0700

At Thu, 29 May 2008 07:51:02 -0500,
Mary Barnes wrote:
> 
> Hi Eric,
> 
> Thanks for you review and comments.  My responses are embedded below
> [MB]. 
> 
> Mary. 
> 
> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Saturday, May 24, 2008 9:01 PM
> To: [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Review of draft-ietf-geopriv-http-location-delivery-07
> 
> $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1
> 2008/05/24 15:03:19 ekr Exp $
> 
> TECHNICAL
> 
> 
> S 4.2.
>    which a Location Recipient (LR) can use to retrieve LI.  A location
>    URI provided by a LIS can be assumed to be globally-addressable; that
>    is, anyone in possession of the URI can access the LIS.  However,
>    this does not in any way suggest that the LIS is bound to reveal the
>    location associated with the location URI.  This issue is deemed out
> 
> I don't understand this point. anyone in possession of the URI can
> access the URI but the LIS isn't required to reveal it? Those seem kind
> of contradictory.
> 
> [MB] Your comment is similar to a point made by Ben Campbell's gen-art
> review.
> The text is unclear, in particular the "However," clause.  The changes
> agreed as a result of the gen-art thread 
> http://www.ietf.org/mail-archive/web/gen-art/current/msg02995.html
> are reflected below (also incorporating another issue Ben raised, as
> well, by adding a new paragraph to that section):
> 
> NEW:
>    However, this does not in any way suggest that the LIS 
>    indiscriminately reveals the location associated with the location
> URI.
>    The specific requirements associated with the dereference of the 
>    location are specified in [I-D.ietf-geopriv-lbyr-requirements]. 
>    The location dereference protocol details are out of scope of 
>    this document and are specified in 
>    [I-D.winterbottom-geopriv-location-deref]. 
> 
>    It should also be noted that while the lybr requirements document
>    specifies a requirement that a client SHOULD be able to cancel
>    location references, the protocol specified in this document
>    does not provide that functionality. The mechanism to
>    provide this support in the protocol requires explicit management
>    of Target state on the LIS. It is anticipated that extensions to HELD
>    may support that requirement. 
> 
> Does the revised text help to alleviate your concern?

Well, it alleviates my concern about the security question, but it
reinforces my concern about the completeness of this specification.
Unless I'm missing something, this is a major normative dependency
on draft-winterbottom-geopriv-location-deref? I'm not sure we can
assess this protocoal with that reference unbound.

>    It could also be useful for a VPN device to serve as a LIS for other
>    location configuration options such as Dynamic Host Configuration
>    Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint
>    Discovery (LLDP-MED) [27].  VPN devices that serve as a LIS may
>    acquire their own location using HELD.

Yes, I think this is an improvement.

> 
> S 5.1.
>    o  The HELD protocol must provide authentication, confidentiality and
>       protection against modification per Section 10.3.
> 
> Are you talking about HELD, which doesn't seem to have these features,
> or about the transport protocol? Also, authentication for who? Based on
> what model?
> 
> [MB] Per your subsequent response to Hannes on this point, I will change
> that bullet to read:
>     o  The HELD protocol REQUIRES that the underlying transport provide
> authentication, confidentiality and
>        protection against modification per Section 10.3.

Agreed.

> S 6.5.
> I'm having trouble keeping straight two kinds of URIs:
> 
> - URIs that a Device uses to get its own LI.
> - LbyR references that the LIS hands out.
> 
> This text seems to imply that an LIS can hand out a helds:
> URI. Is that *also* the URI that a Device derferences?
> 
> [MB] Yes, the helds: URI that a device receives in a locationResponse is
> the URI that a device would dereference. But, it's important to note
> that the LIS does not have to return a helds: URI - other URIs may also
> be used per the text in section 6.5. [/MB]

Hmm... Then I think this needs some explanation in the main text.

> S 6.5.1.
> 
>    A "locationURI" SHOULD NOT contain any information that could be used
>    to identify the Device or Target.  Thus, it is RECOMMENDED that the
>    "locationURI" element contain a public address for the LIS and an
>    anonymous identifier, such as a local identifier or unlinked
>    pseudonym.
> 
> 1. This seems like it should be clearer about what is desired.
>    In particular it's not just "identify" but also "link".
>    Also this needs to be clarified to indicate the implications
>    of idetntifiction by position.
> 
> 2. Shouldn't this be MUST strength?
> 
> [MB] This isn't a MUST strength because we had WG discussion/consensus
> that we can't mandate LIS behavior. We can make recommendations, but a
> LIS may not necessarily follow them.  I'm not entirely clear on your
> first point as far as "identification by position".  [/MB]

I mean that knowing where someone is with high enough resolution gives
a lot of information about their identity. For instance, if you know
that someone is at the AP associated with my house, it seems pretty
likely it's me.

> Does this say somewhere what "helds" actually means? I see the
> definitition of the URI, but it doesn't say what the underlying
> transport is, as far as I can tell. Given a "helds:" URI, what am I
> supposed to do with it?
> [MB] I will add something like the following to section 8. Also, we have
> discussion on the WG mailing list and we will be adding the basic held:
> URI schema, as well:
> http://www.ietf.org/mail-archive/web/geopriv/current/msg05567.html
> OLD: 
>    This section defines the schema for a helds: URI.
> NEW:
>    This section defines the schema for a helds: URI for TLS connections.

The concern I have is more fundamental. This section doesn't say 
that helds: uses HTTP at all? I assume this is the protocol
in S 9, but this doesn't say so, nor does the next section.

> S 9.
> OK and here's how I get confusied about the two types of URI,
> since this is an HTTP binding, but there's no corresponding
> URI.
> [MB] The thread above relates to this point and your next.
> On this specific point, we will be defining a held: URI along with the 
> helds: URI.  [/MB]
> 
> 
>    The implementation of HTTP as a transport mechanism MUST implement
>    TLS as described in [RFC2818].

I'm having a lot of trouble visualizing this. If you want to 
send a more complete section, I'll try to tell you if I think
this addresses my concerns.

> Is this MUST implement or MUST use? Don't the next two sentences
> imply MUST use?
> 
> [MB] Per the thread above, that text does need some clarification for
> consistency. It should be
>      MUST "implement" and not MUST "use", so I would propose the
> following change:
> OLD:
>    The implementation of HTTP as a transport mechanism MUST implement
>    TLS as described in [RFC2818].  TLS provides message integrity and
>    privacy between Device and LIS.  The LIS MUST use the server
>    authentication method described in [RFC2818]; the Device MUST fail a
>    request if server authentication fails, except in the event of an
>    emergency.
> NEW:
>    The implementation of HTTP as a transport mechanism MUST implement
>    TLS as described in [RFC2818].  TLS provides message integrity and
>    privacy between Device and LIS. 

privacy->confidentiality. Also, only if the right cipher suiotes
are used.

>    The LIS MUST implement the server
>    authentication method described in [RFC2818]. When TLS is used, 
>    the Device SHOULD fail a request if server authentication fails, 
>    except in the event of an emergency.
> 
> Does that address your concerns?

Why did this become a SHOULD when it was a MUST?

> [MB] Yep. [/MB]
> 
>    between Device and LIS.  The LIS MUST use the server
>    authentication method described in [RFC2818]; the Device MUST fail a
>    request if server authentication fails, except in the event of an
>    emergency.
> 
> This is incomplete, because 2818 assumes the presence of a URI to
> compare against. Where does that come from? 
> 
> How is client authentication supposed to work here?
> 
> [MB] Per Hannes response, the device (client) gets the URI of the LIS
> (server) using LIS discovery procedures.

Sure, but what are the contents of that URI? Where is it defined?

> S 10.3.
>    o  The network SHOULD have mechanisms that protect against IP address
>       spoofing, such as those defined in [RFC3704].
> 
> Is this WG really in a position to levy a SHOULD level requirement
> for network ingress filtering? Recall that this is really a global level
> technology. Or do you mean something else?
> 
> [MB] Per Richard's response on this thread, the IP address spoofing
> recommendation is due to HELD using the devices IP address as the
> identifier for the device. In this case it is important to have a
> recommendation for IP address spoofing. I think the paragraph prior to
> those bullets appropriately qualifies the context of that
> recommendation. 
> [/MB]

I can't say I really agree with this assertion about the qualification.
This still looks to me like a general levy on the access network.

-Ekr
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "TSG" <[email-masked]>
Date: Fri, 20 Jun 2008 19:07:52 -0800

FYI - the IETF IPR disclosure process doesn't work very well since GEOPRIV 
directly violates our patent - see IPR notice #201.

Todd Glassey
----- Original Message ----- 
From: "Eric Rescorla" <[email-masked]>
To: "Mary Barnes" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Friday, June 20, 2008 11:59 AM
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 21 Jun 2008 14:31:03 +0100

Hi Eric, folks,
  [renamed for this specific point, and CC list trimmed]

I am puzzled by this point in your review.
I suspect that other potential authors will be too.
To me, the last sentence is exactly right:
the SHOULD means "do this unless...",
and the last phrase covers the "unless".

I had read 2119 to mean that a MUST was unconditional
- do this or be non-complaint.
Do you believe that MUST can have an "unless" clause?
Doesn't this mean that any SHOULD with an explicit "unless" will
need to be changed into a MUST - could you expand on this, please?

all the best,
   Lawrence

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Jun 2008 10:31:32 -0700

At Sat, 21 Jun 2008 14:31:03 +0100,
> and the last phrase covers the "unless".

I'm not arguing about what intensity level this requirement
should be at. I'm pointing out that it changed and asking
why.

> - do this or be non-complaint.

Here's the relevant text from 2119:

    2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
       definition is an absolute prohibition of the specification.
    
    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

In other words, the difference between MUST and SHOULD is intensity
not conditionality.

So, if the spec read:
"You MUST do X unless Y", then an implementation which did not
do X was nonconformant unless Y obtained.

On the other hand, if the spec read:
"You SHOULD do X unless Y", then an implementation which did
not do X is still conformant even if Y does not obtain, though
the implementor is exhorted to do X unless they have some
other good reason and that Y is explicitly called out as such
a reason.

> Do you believe that MUST can have an "unless" clause?

Of course.

> need to be changed into a MUST - could you expand on this, please?

No, why would it?

-Ekr

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 21 Jun 2008 06:03:29 -0500

Hi Todd,

Can you be a bit more helpful?

There is no disclosure #201 on the IPR page -
https://datatracker.ietf.org/ipr/ that I can find.

A search for "earthlink" does not yield anything either.

Could you provide a link to the information and an explanation of what
GEOPRIV is actually doing that "violates" a patent?

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of TSG
Sent: Saturday, 21 June 2008 1:08 PM
To: Eric Rescorla; Mary Barnes
Cc: [email-masked];
[email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Review of
draft-ietf-geopriv-http-location-delivery-07

FYI - the IETF IPR disclosure process doesn't work very well since
GEOPRIV 
directly violates our patent - see IPR notice #201.

Todd Glassey
----- Original Message ----- 
From: "Eric Rescorla" <[email-masked]>
To: "Mary Barnes" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>;
<[email-masked]>; 
<[email-masked]>
Sent: Friday, June 20, 2008 11:59 AM
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Jun 2008 11:19:51 +0100

I think I'm essentially agreeing with Eric Rescorla here, but perhaps  
phrasing it differently may help.

> - do this or be non-complaint.

That's a reasonable assessment, given RFC 2119.

> Do you believe that MUST can have an "unless" clause?

I think that any MUST X unless Y can essentially be rephrased as one  
of "MUST (X or Y)", or "MUST (X or Y); SHOULD X". Lacking context on  
geopriv, it sounds like one of these (and it doesn't matter which).

> need to be changed into a MUST - could you expand on this, please?

Again, I lack context here, but if the intent is as above, then they  
may do.

A SHOULD X unless Y essentially means "SHOULD (X or Y)" - as Eric  
says, this is probably not what the intent is, although in the case  
of TLS authentication it might be a reasonable course of action. I  
have to admit that if I read a "SHOULD X unless Y", given the usual  
English meaning, I'd read it as the same as "MUST X unless Y", but  
Eric's quite correct in pointing out the difference.

A final point is that actually phrasing it as "MUST X or Y" is  
problematic since English lacks the possibility of parenthesis for  
precendence - hence a stronger binding, such as MUST X unless Y, is  
preferable.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Joe Abley <[email-masked]>
Date: Tue, 24 Jun 2008 14:51:59 -0400

> precendence - hence a stronger binding, such as MUST X unless Y, is  

Preferable to me would be to avoid such ambiguity altogether by  
breaking things down into simpler atoms ("If Y then MUST X; if !Y then  
MAY X", or whatever the context supports). More complex constructions  
seem certain to lead to confusion to native readers of English, never  
mind those whose more usual tongue is something else.

Joe

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 24 Jun 2008 23:28:50 +0200

Dave Cridland wrote:
 
> A SHOULD X unless Y essentially means "SHOULD (X or Y)"

I'd read it as "do X, but if you have a very good excuse
not doing X might do.  One known very good excuse is Y."

OTOH for a MUST X I'd want no qualifiers, MUST means "an
attempt to do not X can cause havoc."  

This is also about a readability, I had a serious case of
DEnglish some days ago, an article was tagged with a note:

"This article may contain no original research".  I read
this as "apparently there is no original research in this
article", which would be perfectly fine wrt the linked
guideline.  Only much later it occured to me that I got
the "may ... not ..." wrong.  

If Y is the *only* possible very good excuse your version
"MUST X or Y, SHOULD X" is clear.  But SHOULD X often has
an implicitly known very good excuse:  Any older software
written before the SHOULD X was approved.

 Frank

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Jun 2008 09:30:14 +0200

> need to be changed into a MUST - could you expand on this, please?

The difference is that with a SHOULD, the reader may come up with her  
own "unless".

Also note the difference between the two sides in a client-server  
protocol. I recently used SHOULD where I would have liked to use MUST  
but existing clients don't conform to the MUST so I used SHOULD to  
indicate that servers must support clients that don't have the feature.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Jun 2008 17:37:45 +0800

> not doing X might do.  One known very good excuse is Y."

That is more or less my definition of "should". I say something "must"  
be so when I can tell you an operational failure that would or could  
happen if it isn't. If I would like to say "must" but can think of a  
case in which it would not be appropriate I say "should", and am  
saying that if it is not so in someone's implementation they should be  
prepared to say what their reason was.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 Jun 2008 07:59:00 -0400

On 6/25/08 5:37 AM, Fred Baker allegedly wrote:
> case in which it would not be appropriate I say "should", and am saying 
> that if it is not so in someone's implementation they should be prepared 
> to say what their reason was.

... and draft authors should include explanations in their drafts of the 
reasons an implementor might legitimately have for not implementing the 
"should".  For example, an older operating system that does not support 
a new capability.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Jun 2008 08:24:22 -0400

--On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
<[email-masked]> wrote:

>> That is more or less my definition of "should". I say
>> something "must"  be so when I can tell you an operational
>> failure that would or could  happen if it isn't. If I would
>> like to say "must" but can think of a  case in which it would
>> not be appropriate I say "should", and am saying  that if it
>> is not so in someone's implementation they should be prepared 
> ... and draft authors should include explanations in their
> drafts of the reasons an implementor might legitimately have
> for not implementing the "should".  For example, an older
> operating system that does not support a new capability.

Scott,

In principle, sure.  But I note that you use a lower-case
"should" in the first sentence above and that, like the
incremental promotion of "these are available" to "MUST unless
you receive a dispensation", this could easily be turned into a
firm requirement by someone who was being zealous about
rule-making.

Do you really mean, e.g., 

	... where feasible and, in the author's judgment,
	appropriate, it is desirable to include explanations or
	illustrations of the exception cases in drafts that use
	SHOULD.

???

I've run into a number of situations over the years in which
there are known edge cases that prevent a MUST but where those
edge cases are rare and obscure enough that describing them
would require extensive text... text that might indirectly end
up providing guidance for bad behavior.   For those situations,
I'd prefer to see something like:

	In all of the common cases, the system SHOULD...

Rather than

   The system SHOULD do A
     unless Y, in which case B SHOULD be done
     unless Z, in which case C SHOULD be done

where each of X, Z, B, and C, might require a half-page
explanation.

That btw is part of the difficult with some of the discussion in
this thread.  The discussion has, as I've read it, concentrated
on

   SHOULD do A unless Y
and
   SHOULD do A but may do B

where it would often be useful to say

   SHOULD do A unless Y and then SHOULD do B

Note that the latter can often be rewritten as a MUST, e.g.,

	MUST do A unless condition Y occurs, in which case MUST
	do B
   
I believe that good sense and discretion are important here.  I
also believe that attempts to map case-by-case good sense into
rules generally gets us into trouble and that such efforts
should be examined carefully by the community.

In addition, as Frank has noted, negative statements and words
are often used quite differently than they are in English by
languages that are otherwise reasonably similar to English.
That calls for use of extreme care in use of negative statements
in conformance clauses, a subject on which I would hope the RFC
Editor (as well as authors and the IESG) would be very sensitive.

    john

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Jun 2008 20:46:13 +0800

I was about to write something like that to Scott; thanks for making  
it unnecessary.

My additional comment is that if there is some case I can think of  
that leads me to say "should", there might also be another that I  
didn't think of. Asking me to detail them all up front is IMHO asking  
too much. On the other hand, I wouldn't be at all bothered by being  
told that I had to justify a "must" - since in my mind it is something  
to be used when not doing the action has a predictable negative  
outcome, asking the author to say what that predictable negative  
outcome would be is reasonable.

My bottom line on a "should" is that if an implementer doesn't do what  
the specification says he "should", he should have a good reason and  
be prepared to explain it if questioned (for example by a customer or  
during an interoperability test). "I disagreed with the spec" is *not*  
a good reason, although it might be a good reason to implement it and  
provide a configuration knob that turned that functionality off,  
whatever it was.

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 Jun 2008 13:02:58 -0400

> would require extensive text.

My rule of thumb is: when you're writing the draft if something is not a 
MUST, ask yourself "why not?" and write down your answer.  You can be 
brief but make it clear that the SHOULD is a MUST with exceptions.

There's no way we should have strict process rules about this.  The IETF 
has enough rules as it is.  However, explanations of SHOULDs do make 
better standards.  The point is to give guidance to implementors.  I did 
an informal survey last year and found that some implementors treat 
every SHOULD as a MUST, but more of them just treat a SHOULD as a MAY, 
essentially to be ignored.  An explanation of the circumstances 
surrounding a SHOULD will lead to a lot more consistency in 
implementation.  Many SHOULDs in RFCs are because there are old 
implementations that need to be taken into account, or because some 
capability isn't widely possible yet but will be within the lifetime of 
the standard.  If a MUST becomes a SHOULD to take that into account, and 
you explain it, your chances of getting rid of non-MUST-capable 
implementations eventually goes up tremendously.  So, to reiterate, when 
you're writing the draft if something is not a MUST, ask yourself "why 
not?" and write down your answer.

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Jun 2008 13:37:38 -0400

--On Wednesday, 25 June, 2008 13:02 -0400 Scott Brim
<[email-masked]> wrote:

> My rule of thumb is: when you're writing the draft if
> something is not a MUST, ask yourself "why not?" and write
> down your answer.  You can be brief but make it clear that the
> SHOULD is a MUST with exceptions.
> 
> There's no way we should have strict process rules about this.
> The IETF has enough rules as it is.  However, explanations of
> SHOULDs do make better standards.  The point is to give
> guidance to implementors.  I did an informal survey last year
> and found that some implementors treat every SHOULD as a MUST,
> but more of them just treat a SHOULD as a MAY, essentially to
> be ignored.  An explanation of the circumstances surrounding a
> SHOULD will lead to a lot more consistency in implementation.
> Many SHOULDs in RFCs are because there are old implementations
> that need to be taken into account, or because some capability
> isn't widely possible yet but will be within the lifetime of
> the standard.  If a MUST becomes a SHOULD to take that into
> account, and you explain it, your chances of getting rid of
> non-MUST-capable implementations eventually goes up
> tremendously.  So, to reiterate, when you're writing the draft
> if something is not a MUST, ask yourself "why not?" and write
> down your answer.

Certainly we are in complete agreement about the principles
here.  We probably also agree about Fred's slightly different
take, which is thinking about whether a proposed MUST really
might have exception cases that we would prefer to keep within
the bounds of the standard.  My concern is about anything that
might get turned into another rule while various of us are
trying to concentrate on technical work and not, e.g., watching
every entry in the IESG's tracker logs.

More generally, thinking carefully about these conformance
statements is A Good Thing and should be encouraged whenever
possible.

   john

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 Jun 2008 14:01:56 -0400

On 6/25/08 1:37 PM, John C Klensin allegedly wrote:
> My concern is about anything that

Indeed.

> statements is A Good Thing and should be encouraged whenever

Indeed.

swb

---

From: Dean Willis <[email-masked]>
Date: Wed, 25 Jun 2008 13:09:25 -0500

On Jun 25, 2008, at 7:46 AM, Fred Baker wrote:

> didn't think of. Asking me to detail them all up front is IMHO  
> asking too much. On the other hand, I wouldn't be at all bothered by  
> being told that I had to justify a "must" - since in my mind it is  
> something to be used when not doing the action has a predictable  
> negative outcome, asking the author to say what that predictable  
> negative outcome would be is reasonable.
>
> My bottom line on a "should" is that if an implementer doesn't do  
> what the specification says he "should", he should have a good  
> reason and be prepared to explain it if questioned (for example by a  
> customer or during an interoperability test). "I disagreed with the  
> spec" is *not* a good reason, although it might be a good reason to  
> implement it and provide a configuration knob that turned that  
> functionality off, whatever it was.
>

I believe that in every instance that RFC 2119 language is used to  
state a requirement that there is either an implicit or explicit  
statement of consequences that are likely to occur if that requirement  
is violated. Further,  I believe that it is better to make those  
statements of consequence explicit, and that the severity of the  
consequences needs to support the severity of the requirements language.

We have a tendency to use RFC 2119 requirements language much too  
liberally. For example, it is frequently used in explication to show  
what happens, e.g. "To reach Bob, Alice MUST send him an INVITE  
request". There is of course a substantial difference between a  
description of what does happen, and a statement of requirement  
against which there are consequences if that requirement is not met. I  
believe that the clarity of our specifications and our ability to  
generate test plans against those specifications would greatly benefit  
from a concerted effort to reduce these spurious usages of RFC 2119  
requirements language.

The difference between an appropriately used  SHOULD and a MUST is one  
of severity of the consequences. MUST level requirements have the  
consequence that, if ignored, interoperability failure or other  
grievous harm is reasonably likely to occur. SHOULD level requirements  
have consequences of a different order; if the requirement is not met,  
some operational or functional benefit will not be achieved. MAY level  
requirements have consequences that are at the level of personal  
preference, esthetics, flavor, or style.

I try, but often fail, to convince authors to explicitly describe the  
consequences surrounding every RFC 2119 requirement, and to be frugal  
in the use of such requirements in their text. It is not to our  
advantage to  require a reader to be an expert in the subject to  
determine what the consequence of ignoring such a requirement may be,  
or we in effect require every reader of a specification to be an  
expert in the underlying art. Further, only clear statement of the  
consequences allow the reviewer of a draft to understand and make a  
judgement about the appropriateness of the strength with which a  
requirement is made.

While it is always true that there may exist rationale for a  
requirement that is not known to an author at the time of writing,  
failure to record any such rationale in a specifications seem to me to  
be a likely indicator that the specification has not been adequately  
thought through by the author, making it not yet ready for publication.

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Wed, 25 Jun 2008 16:50:58 -0500

fwiw -

I have, for many SIPits (a rather large interop event for SIP  
implementations) worked to get the people writing code from these  
documents to understand that MUST means MUST and SHOULD means MUST ... 
(very long pause)... unless you _really_ know that not following the  
SHOULD won't result in very bad things.

They typically respond with MUST means MUST unless they're sure they  
can get away without it most of the time, and that SHOULD means its in  
some future release that will get funding maybe someday. Some of that  
response is tongue-in-cheek - some of it isn't.

I see a strong trend for unadorned SHOULDs to remain unimplemented.  
SHOULDs that have a very clear, and explicitly called out even when  
they seem incredibly obvious, explanation of the bad things that can  
happen if you don't follow them get implemented.

So, at least for the documents I edit, I work really hard to explain  
the SHOULDs to help motivate the implementors to actually build things  
that conform to it.

RjS

On Jun 25, 2008, at 12:02 PM, Scott Brim wrote:

>> Do you really mean, e.g., 	... where feasible and, in the author's  
>> judgment,
> My rule of thumb is: when you're writing the draft if something is  
> not a MUST, ask yourself "why not?" and write down your answer.  You  
> can be brief but make it clear that the SHOULD is a MUST with  
> exceptions.
>
> There's no way we should have strict process rules about this.  The  
> IETF has enough rules as it is.  However, explanations of SHOULDs do  
> make better standards.  The point is to give guidance to  
> implementors.  I did an informal survey last year and found that  
> some implementors treat every SHOULD as a MUST, but more of them  
> just treat a SHOULD as a MAY, essentially to be ignored.  An  
> explanation of the circumstances surrounding a SHOULD will lead to a  
> lot more consistency in implementation.  Many SHOULDs in RFCs are  
> because there are old implementations that need to be taken into  
> account, or because some capability isn't widely possible yet but  
> will be within the lifetime of the standard.  If a MUST becomes a  
> SHOULD to take that into account, and you explain it, your chances  
> of getting rid of non-MUST-capable implementations eventually goes  
> up tremendously.  So, to reiterate, when you're writing the draft if  
> something is not a MUST, ask yourself "why not?" and write down your  
> answer.
>
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Jun 2008 11:44:29 -0700

> brief but make it clear that the SHOULD is a MUST with exceptions.

This gets to an essential issue with IETF specification writing, as well as 
suggesting some of the distinction between MUST and SHOULD.

(By the way, I hope folks are clear that IETF use of these words as normative 
does not depend upon the case that is used?)

1. MUST is required if interoperability will otherwise be broken.  The spec does 
not offer any leeway to implementors.  Including rationale might be nice, but is 
not required.

2. SHOULD is used when there is a strong consensus that the specification's 
utility is greatly enhanced by having the SHOULD get implemented, but the 
specification is acknowledging that careful judgment by an implementor can 
produce cases in which it is acceptable not to implement it.

   The fact that a SHOULD explicitly calls for judgment by an implementor 
invites two things that we probably are not very consistent about delivering in 
specifications:

    a) Why is it best to implement the SHOULD?  What is the nature of the 
benefit provided by the feature?  Often this is obvious, such as an additional 
and more powerful algorithm for a set of component security mechanisms.  Still, 
it makes sense to state this explicitly.

    b) What examples are there that would justify *not* implementing it?  For 
example, resource constraints, implementation simplicity, very tightly 
controlled execution environment?  Of course, the danger with listing examples 
is that folks might come to believe they are exhaustive...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave Cridland <[email-masked]>
Date: Wed, 25 Jun 2008 08:58:35 +0100

On Wed Jun 25 08:30:14 2008, Iljitsch van Beijnum wrote:
> protocol. I recently used SHOULD where I would have liked to use  
> MUST  but existing clients don't conform to the MUST so I used  
> SHOULD to  indicate that servers must support clients that don't  
> have the feature.

Yes, the problem being that older client implementations otherwise  
become cast into non-conformancy.

I think we should be biting the bullet and doing so, however -  
otherwise we risk having the old behaviour used in new  
implementations more than it would be otherwise. The primary reason  
for doing the behaviour you describe is a kind of political  
correctness, and introduces a political-SHOULD I'm not sure I care  
for.

A phrasing like:

Clients MUST send bar; however implementations based on an earlier  
revision of this specification are known to send foo, and therefore  
servers MUST accept foo without error.

both casts these old clients into the oblivion of non-conformancy,  
but also firmly establishes who to blame - ie, the specification and  
not the implementation.

Dave.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 27 Jun 2008 15:48:53 +0200

> correctness, and introduces a political-SHOULD I'm not sure I care  

This shows that it's very important to avoid the situation where there  
exist implementations of insufficiently mature specifications: once  
those implementations are out there, the protocols must virtually  
forever support them.

This is of course not compatible with "let's ship a 80% workable spec  
and hammer out what's missing in the next version" thinking that is  
not uncommon in the IETF.

-- 
The trouble with doing something right the first time is that nobody  
appreciates how difficult it was. - Walt West

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Jun 2008 09:27:41 -0700

Eric Gray wrote:
> This is NOT true.  These terms are explicitly defined in all capital letters
> to make it possible to distinguish when they are being used as normative and
> when they are not.

Sorry, no.  Please re-read rfc 2219.  Specifically:

      "These words are often capitalized."

The key word is "often" which means not always which means not required.

Computer science long ago made the mistake of imposing semantic difference on
case differences, which is distinct from other uses of case.  Absent explicit
specification of case sensitivity for the keywords, the rules of English writing
apply, I would think.

> In text that is not meant to be normative, the special terms should be
> avoided - even in lower case - but this can lead to exceptionally stilted use
> of the English language.

Not really.  Words like "can" and "ought" do the job nicely.

d/
-- 

   Dave Crocker

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 27 Jun 2008 12:49:48 -0500

Dave,

	See inline below...

--
Eric Gray
Principal Engineer
Ericsson  

> From: Dave Crocker [mailto:[email-masked]] 
> Sent: Friday, June 27, 2008 12:04 PM
> To: Eric Gray
> Cc: IETF Discussion
> Subject: SHOULD vs MUST case sensitivity
> Importance: High
> 
> 
> 
> Eric Gray wrote:
> >> (By the way, I hope folks are clear that IETF use of these words as
> >>  normative does not depend upon the case that is used?)
> > 
> > This is NOT true.  These terms are explicitly defined in 
> > all capital letters to make it possible to distinguish when 
> > they are being used as normative and when they are not.
> 
> 

I assume you meant to refer to RFC 2119, rather than 2219.

I specifically refer to usage, rather than RFC 2119.  We often
do that.  

You, for instance, recently co-authored an RFC that is a full
standard, uses lower case instances of these terms, and does 
not refer to RFC 2119 at all. RFC 5234/STD 68, I believe.

I suspect that this wording is an aspect of RFC 2119 that 
should be changed - and probably would have been were it not 
for the fact that capitalization has not always been used 
consistently and RFC 2119 is supposed to be a "Best Current 
Practices" RFC.

In English, "best current practices" cannot typically be used
to refer to what we wish to be true.

I strongly suspect that RFC 2219 should say "SHOULD be"
instead of "are often" - if for no other reason than to
encourage consistency.

> 
> Computer science long ago made the mistake of imposing 
> semantic difference on case differences, which is distinct
> from other uses of case.  Absent explicit specification of 
> case sensitivity for the keywords, the rules of English 
> writing apply, I would think.

Yeah, you're not that much older than I am.

However, in this case, people who actually include a section
that lists the RFC 2219 normative terms effectively DO make
an implicit specification of case sensitivity and - unless
the reader decides to read RFC 2219, the reader may not know 
otherwise.

The statement that "should" be contained in any RFC that is
intended to use the "requirements level" aspect of RFC 2119
terms is:

      'The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.'

There is nothing in this statement that indicates that these
terms are meant to be anything other than capitalized.

> 
> 
> > In text that is not meant to be normative, the special 
> > terms should be avoided - even in lower case - but this
> > can lead to exceptionally stilted use of the English 
> > language.
> 

Actually, no they do not.

As most of us know, "can" is NOT a synonym for "may" and 
(as most anyone who would be familar with the word ought
would know) "ought" is also a synonym for "zero."

If you decided to use the word "may" in a non-normative
sense - but wished to be consistent with Enlgish usage -
you would need to say something like "is allowed to."

That seems to me to be a fine example of "stilted" usage.

An example of a non-normative use of "should" is this:

 "The reader should already be aquainted with the contents
  of ..."

Assuming this statement is normative is absurd. Re-writing 
it to use "ought" makes it read "... reader ought to be ...
- which seems like another fine example of stilted English.

And a good example of when you might use the word "must"
in a non-normative sense is when describing something
that is unavoidable (e.g. - what goes up, must come down)
and describing such a thing "normatively" is also absurd.

Would you write "what goes up, would need to come down"?
Strictly speaking, inanimate objects (rocks, balls, etc.)
have no "needs" and many animate objects (kittens, puppies, 
etc.) would not necessarily feel any such need.

And, before you dismiss these as irrelevant examples, ask
yourself whether or not the statement "a message must have
a finite number of octets" is normative...

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Jun 2008 20:17:18 +0200

Dave Crocker wrote:
>> normative
> ...

Of course.

My understanding that everything in an RFC is normative, unless stated 
otherwise.

If this wouldn't be the case, how could something as important as STD66 
be written without a single RFC2119 keyword?

BR, Julian

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Jun 2008 14:19:57 -0400

> specification of case sensitivity for the keywords, the rules of 
For better or worse, in IETF we have often intentionally made a 
distinction between SHOULD and should, MUST and must, and so forth.  I 
don't think we should try to retroactively change the interpretation of 
existing RFCs that cite RFC 2119.

However, it strikes me that such distinctions might be lost when 
translating RFCs into languages that lack the notion of case, or for 
which upper cased words would not serve to convey a sense of emphasis or 
distinction.   So it might be the case that a future update to RFC 2119 
would include a section about translation of these keywords into other 
languages.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Jun 2008 09:03:46 -0700

d/
-- 

   Dave Crocker

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 27 Jun 2008 10:55:38 -0500

Dave,

> > My rule of thumb is: when you're writing the draft if something is
not a 
normative 
> does not depend upon the case that is used?)

This is NOT true.  These terms are explicitly defined in all
capital letters to make it possible to distinguish when they
are being used as normative and when they are not.

One of the things RFC authors need to be careful about is to
ensure that they do capitalize these terms consistently.

In text that is not meant to be normative, the special terms
should be avoided - even in lower case - but this can lead to
exceptionally stilted use of the English language.

--
Eric

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Jun 2008 16:23:47 -0700

d/
-- 

   Dave Crocker

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 27 Jun 2008 18:54:37 -0700 (PDT)

> The key word is "often" which means not always which means not required.

That quote is taken out of context.  Here is the full text:

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

I read this to mean that the words are often capitalized in many 
(pre-RFC 2119) documents.  I also read the following two statements 
to mean that the words will be capitalized when following the 
guidelnes in RFC 2119.

The common usage in the IETF is to capitalize the words when used 
with the meanings in Sections 1-5 of RFC 2119 and to use then in 
lower case when ordinary English usage is meant.  RFC 2119 itself 
follows this usage (see, e.g., Section 6, "Guidance in the use of 
these Imperatives").

//cmh

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 28 Jun 2008 22:57:28 +0200

On 28 jun 2008, at 3:54, C. M. Heard wrote:

> lower case when ordinary English usage is meant.

Are you saying that according to RFC 2119 "SHOULD" means something  
different than "should"?

In what universe does that make sense?

The way I see it, these words always meant what RFC 2119 says that  
mean or something very close. Their capitalization doesn't really tell  
the reader anything, but is a good tool in writing specs: if the word  
is capitalized, the author was aware of the fact that the word shapes  
the specification. If the word wasn't capitalized, the author MAY have  
been sloppy.

Please spend some time on any of the ops wg mailinglists. People who  
are obviously new to the IETF ask all kinds of questions about RFCs  
that SHOULD be completely obvious from the text but either the text is  
lacking or the questioner managed to overlook the part that addresses  
the question. Specifications need to be clear to the point of painful  
bluntness, ANY level of ambiguity is unacceptable. This includes  
working under the assumption that in the version read by implementers,  
the definitions section is missing.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 29 Jun 2008 16:46:26 -0700

Hi -

> From: "Iljitsch van Beijnum" <[email-masked]>
> To: "C. M. Heard" <[email-masked]>
> Cc: "IETF Discussion" <[email-masked]>
> Sent: Saturday, June 28, 2008 1:57 PM
> Subject: Re: SHOULD vs MUST case sensitivity
...
...

One in which when the photocopier's paper jam light goes, the 
operator SHOULD open the cover and remove any crumpled
pieces of paper, which should resolve the problem.

These are very distinct senses of the word - one indicating the
desirability of a course of action, the other indicating the likelihood
of a particular result.  Only for the former does any kind of "normative"
semantic make sense.

Randy

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Jun 2008 17:31:02 -0700

Randy Presuhn wrote:
> One in which when the photocopier's paper jam light goes, the operator SHOULD
>  open the cover and remove any crumpled pieces of paper, which should resolve
>  the problem.
> 
> These are very distinct senses of the word

Wow. I was not aware that the photocopier manual conformed to RFC 2119.

The most distinctive characteristic of the postings arguing in favor of imposing
case sensitivity in documents asserting RFC 2119 semantics is their spontaneous
invocation of relativity.

2119 specifies the meaning of these words... but not relative to whatever other,
particular interpretation that the posters wants to have held as higher
precedence.  And certainly not relative to the long-term reality that English
usage of case has no import on semantics.

Let's be clear.  No matter its own marginal choices for wording, the document's
introduction:

> In many standards track documents several words are used to signify the 
> requirements in the specification. These words are often capitalized. This 
> document defines these words as they should be interpreted in IETF documents.
>  Authors who follow these guidelines should incorporate this phrase near the 
> beginning of their document:

states that the words be used as defined.  Not as defined -- except according to
the whim of whoever is imposing additional meaning.

English is not case sensitive.  RFC 2119 does not specify case sensitivity.

Assertion that case sensitivity is relevant is, therefore, a matter of personal
whim.  On the average one SHOULD NOT use personal whim as a basis for
interpreting a technical specifications.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Jun 2008 17:31:34 -0700

d/

-- 

   Dave Crocker

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 29 Jun 2008 17:47:13 -0700

Hi -

> From: "Dave Crocker" <[email-masked]>
> To: "IETF Discussion" <[email-masked]>
> Sent: Sunday, June 29, 2008 5:31 PM
...
> English is not case sensitive.

Not so.  Case has long been used for emphasis in environments
lacking other typographical means, such as bolding, underlining,
or italicization.

>  RFC 2119 does not specify case sensitivity.

Agreed.  I was long of the opinion that capitalizing the magic words
when used in their specialized RFC 2119 senses was overkill.  Though I
still think it should not be necessary, I've seen enough cases where
people failed to correctly disambiguate, and thus conclude that authors
and editors SHOULD employ the case distinction.

Randy

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Jun 2008 20:45:57 -0400

Dave,

regardless of the original intent of 2119, your belief is inconsistent 
with longstanding IETF process.  you do not get to retroactively change 
the intent of RFCs that have gained consensus and approval.

Keith

Dave Crocker wrote:
>> interpreted in IETF documents.
>>  Authors who follow these guidelines should incorporate this phrase 
>> near the beginning of their document:
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Jun 2008 19:32:17 -0700

> lacking other typographical means, such as bolding, underlining,

Emphasis is not semantics.

Normative intent is semantic.

d/
-- 

   Dave Crocker

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 30 Jun 2008 08:52:09 -0500

Dave,

	Let's try to close this argument in a constructive way.

	We could argue the extent to which "Best Current Practice"
RFCs actually specify anything - rather than simply encouraging
a commonly accepted practice.  Based on that argument - and lots
of usage evidence (represented - among other things - by text 
you've quoted) - RFC 2119 appear to state that the terms in 
question are often capitalized.  And that supports a further
argument that RFC 2119 is suggesting this should be the case -
given that it is a common practice.

	We could also make the semantic argument that you've made
- i.e. - that capitalization is not essential to the semantics
that RFC 2119 encourages RFC authors to use.  It is certainly 
going to be the case that some RFCs will be published with the
intent for these terms to be normative, and where not every 
instance is in ALL-CAPS - and this should not mean necessarily
that these words are not meant to be taken as normative.

	However, there is abundant evidence to support argument
that prospective RFC authors should use the ALL-CAPS version of
these words - if for no other reason than because it removes any
possibility of doubt.  The evidence to support this is based at
least partly on current usage - such as a BCP like RFC 2119 is
meant to reflect.  It is also based at least in part on the the
arguments put forward in this thread.  And finally, it is based
at least in part on the common-sense proposition that anything
that adds clarity to a specification is generally a good thing.

	Hence I believe the one thing we should take away from
this discussion is that - while use of the ALL-CAPS version of
the requriements level terminology in RFC 2119 is probably not 
technically required to indicate the intended usage - it is a 
very good idea to do this.  Further, if we assume that is the
case (and I think reasonable people will agree that it is),
then continuing the argument about the semantics in this case
is merely a distraction from useful discussion and clarity in
the work we all want to be doing.

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Crocker
> Sent: Sunday, June 29, 2008 10:32 PM
> To: Randy Presuhn
> Cc: IETF Discussion

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 30 Jun 2008 09:08:42 -0500

Without reference to other points that have been made in this thread, it's 
also worth noting that Gen-ART reviewers have been challenging 2119-ish 
statements in drafts under review for several years, assuming that 
capitalization is significant, and discouraging upper-casing for emphasis.

It would be lovely to have the current practice written down clearly, so 
authors and editors aren't surprised when this happens (and we never have to 
revisit the topic).

Thanks,

Spencer

---

From: Ralph Droms <[email-masked]>
Date: Mon, 30 Jun 2008 10:11:26 -0400

Would a reasonable BCP for future docs looks something like:

   terms defined in RFC 2119 are to be capitalized for clarity;  
alternatives for RFC 2119 terms, such as "ought" and "can" are to be  
used in
   non-normative text to avoid confusion

- Ralph

On Jun 30, 2008, at Jun 30, 2008,10:08 AM, Spencer Dawkins wrote:

> Without reference to other points that have been made in this  
> thread, it's also worth noting that Gen-ART reviewers have been  
> challenging 2119-ish statements in drafts under review for several  
> years, assuming that capitalization is significant, and discouraging  
> upper-casing for emphasis.
>
> It would be lovely to have the current practice written down  
> clearly, so authors and editors aren't surprised when this happens  
> (and we never have to revisit the topic).
>
> Thanks,
>
> Spencer
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Jun 2008 07:27:22 -0700

>   non-normative text to avoid confusion

+1

Thanks.

d/
-- 

   Dave Crocker