Subject: RE: SHOULD vs MUST case sensitivity

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 1 Jul 2008 08:12:59 -0700

Looks good, but needs some smitthing.
 
I think that the sense that I would want is:
 
* Whenever the keywords are used they are to be considered normative
* Whenever the keywords are used they SHOULD be capitalized
* Editors SHOULD avoid use of normative keywords for non-normative language, even in drafts.

The reason for the last is that it is very common for folk to go through a doucument 'to make sure all the keywords are capitalized as they should be'. This is particularly so where older RFCs are being revised. A standards document should be robust in the face of search and replace changes to the text.
 
I would ideally like to see a normative keyword tag added to the XML2RFC markup to make it easy to construct tables of normative requirements as are required for interop testing and are beginning to appear in some specs.
 
So the marku would be something like:
 
<t>Normative keywords <normative key="should">Only use normative keywords to specify normative language</normative> only be used to specify normative language.</t>
 
And this would allow a table such as the following to be created:
 
NORMATIVE REQUIREMENTS
 
SHOULD
 
Section 2.1 p 3: Only use normative keywords to specify normative language

________________________________

From: [email-masked] on behalf of Ralph Droms
Sent: Mon 6/30/2008 10:11 AM
To: Spencer Dawkins
Cc: Randy Presuhn; IETF Discussion
Subject: Re: SHOULD vs MUST case sensitivity

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
>
>> 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
>>
>>> -----Original Message-----
>>> 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
>>> Subject: Re: SHOULD vs MUST case sensitivity
>>>
>>>
>>>
>>> Randy Presuhn wrote:
>>> >> 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.
>>>
>>>
>>> Emphasis is not semantics.
>>>
>>> Normative intent is semantic.
>>>
>>> d/
>>> --
>>>
>>>   Dave Crocker
>>>   Brandenburg InternetWorking
>>>   bbiw.net
>>> _______________________________________________
>>> Ietf mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ietf
>>>
>> _______________________________________________
>> Ietf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

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

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

---

From: John Levine <[email-masked]>
Date: 1 Jul 2008 15:40:10 -0000

>* Whenever the keywords are used they SHOULD be capitalized

Ahem:

* Whenever the keywords are used they MUST be capitalized

>language, even in drafts.

Yes, I agree.  I've done this in recent drafts that I've been working
on and found it to be quite effective.  Looking at each magic word and
thinking about whether it's telling the reader something important
about interoperating is good discipline, yet not terribly hard.

R's,
John

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 1 Jul 2008 09:49:54 -0700

In like mode, it would be nice if there was a series of guides that described how to go about specifying certain types of document such as we have for MIBs.
 
For example I would like there to be a document that described how to go about specifying a cryptographic algorithm for use in IETF protocols with instructions like:
 
* You must specify the cryptographic primitive it implements
* You MUST specify a canonical OID for identiyfing the algorithm
* You MUST specify a canonical URI for identifying the algorithm
* You MAY request assignment of protocol specific identifiers if the stated requirements for those protocols are met.
* You SHOULD specify test vectors
* You MAY include code that implements the algorithm
 
And so on.

From: John Levine [mailto:[email-masked]]
Sent: Tue 7/1/2008 11:40 AM
To: [email-masked]
Cc: Hallam-Baker, Phillip
Subject: Re: SHOULD vs MUST case sensitivity

Ahem:

R's,
John

---

From: John Leslie <[email-masked]>
Date: Tue, 1 Jul 2008 12:50:47 -0400

> * Whenever the keywords are used they MUST be capitalized

   I did an exercise today: I looked at the first item on Thursday's
IESG Agenda, and I counted "may".

   I found

-   6 occurances of upper-case "MAY",
-  40 occurances of mixed-case "May",
- 111 occurances of lower-case "may".

   I frankly can imagine no way to avoid occasional occurances of the
month "May" -- in this case the header of every page.

   At least four of the lower-case "may"s were in the boilerplate.

   I dread to think how many grammarians might expire during a primal
scream if we replaced over 100 "may"s with "can"s. ;^)

>>language, even in drafts.

   Perhaps they should -- but what do folks actually want to do about
documents like this?

   Those "May" months were probably added by automated software --
I hope nobody expects editors to end-run that! Likewise the boilerplate
"may"s...

   We certainly shouldn't be asking the RFC Editor to "fix" over 100
lower-case "may"s.

   Should the Area Director send this back to the Working Group?
Speak now (well, before Thursday morning) if you think so -- otherwise
the IESG is likely to approve this document which so blatantly ignores
the expressed wishes of this mailing-list.

   ;^)

--
John Leslie <[email-masked]>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 10 Jul 2008 14:04:38 -0500

Hi Eric,

I've snipped the thread to just include the issues (3 total) that I'm
uncertain as to whether they've been adequately addressed in the -08:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-del
ivery-08.txt

Thanks,
Mary. 

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Friday, June 20, 2008 3:00 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Eric Rescorla; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07

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

[MB] But, the identifier doesn't necessarily indicate who the "someone"
is. My contrarian example would be my kids are using my home network and
I'm in Dublin. How would you know who specifically this location might
be associated with?  I agree it certainly could.  There was a comment on
the list yesterday related to this:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05895.html
So, would changing the text to align with Martin's response be adequate,
something like the following:
OLD:
  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.

NEW:
  Thus, it is RECOMMENDED that the
  "locationURI" element contain an address that provides indirect access
to the LIS to  
  avoid inadvertently revealing a location that could be associated with
a Device. Also, an
  anonymous identifier is RECOMMENDED, such as a local identifier or
unlinked pseudonym. 
  
[/MB]

--snipped--

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

[MB] It wasn't clear to me what you were suggested we add in terms of
cipher suites.
Do you just want that general statement or were you thinking of specific
cipher suites that would be appropriate for this application? [/MB]

---snipped----

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

[MB] I'm not certain of the concern here.  Doesn't the "SHOULD" account
for networks that have other mechanisms, thus this isn't an across the
board levy.  Or is your concern that we don't have the should not
situations identified? [/MB]

-Ekr