Subject: draft-hoffman-additional-key-words-00.txt

From: John C Klensin <[email-masked]>
Date: Tue, 15 Jan 2008 13:43:56 -0500

This document doesn't identify a mailing list for discussion, so
I guess it goes here.

The abstract says...
> Some document authors want to express requirement levels using
> the traditional definitions of "MUST" and "SHOULD" from RFC
> 2119, but also want to express that there is an expectation
> that later versions of the document may change those
> requirements.  For example, they may want to express "this
> SHOULD be implemented now, but we expect that this will become
> a MUST requirement in a future update to this standard".
> This document defines three new keywords, "MUST-", "SHOULD+",
> and "SHOULD-" to facilitate such definitions.

This is repeated in more detail in Section 1.

Hmm.  How about 

"MAY-" to denote "you can do this if you like, but we
	really don't like it and may (sic) prohibit it in the
	future if we can find a good excuse.
	
"MAY+-" to denote "we aren't sure about this yet, but are
	likely to either require or prohibit it in the future".
	
"SHOULD+-" to denote "this is either a pretty good idea
	or a pretty bad one.  Once we get some experience, it
	will turn into either SHOULD or SHOULD NOT (or maybe
	MUST or MUST NOT)

Translation: this seems like an interesting idea, but the
concepts are, IMO, probably much better expressed in nuanced
text rather than in cute codes.   A different version of the
same thinking would suggest that any document needing these
extended keywords is not ready for standardization and should be
published as Experimental and left there until the community
makes up its collective mind.

    john

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Jan 2008 18:51:23 +0000

>makes up its collective mind.
I find Paul's definitions quite useful for cases like migration from 
older ciphers/hash functions to new ones.
USEFOR WG also had at least one use case for SHOULD+.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Jan 2008 11:23:43 -0800

At 1:43 PM -0500 1/15/08, John C Klensin wrote:
>text rather than in cute codes.

This document does not prohibit, or even suggest against, individual 
documents coming up with their own terms, nuanced or not.

>A different version of the

It seems that you didn't read the whole document; RFC 4307 already 
uses these terms. My experience with talking to IKEv2 implementers 
(mostly OEMs at this point) is that they understood exactly what was 
meant and were able to act accordingly when choosing what to put in 
their implementations.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jan 2008 11:10:51 +1300

The careful approach needed for phasing crypto algorithms
in and out may justify such terminology. However, I think
there is experience that careless use, in particular of
SHOULD+, which has crept into some non-IETF documents such
as procurement specifications, has great potential for
confusion.  What is a vendor who decides not to implement
a SHOULD supposed to do about a SHOULD+? If we really want
to make these terms available to any specification writer,
I'd want to see more explanatory text of when they're
appropriate and when they're inappropriate, and how
an implementor should interpret them.

The concept supplements not only RFC 2119 but also the
discussion of "requirement levels" in RFC 2026 section 3.3.
I think that should be mentioned.

We also need to know how they are to be interpreted
when evaluating a PS for promotion to DS. (Probably there
is no difference from the regular terms, but it needs
to be stated).

Another thing that's missing is the additional
boilerplate need in order to cite these terms (i.e.
an updated version of the boilerplate specified
in RFC 2119).

   Brian

On 2008-01-16 08:23, Paul Hoffman wrote:
> It seems that you didn't read the whole document; RFC 4307 already uses
> these terms. My experience with talking to IKEv2 implementers (mostly
> OEMs at this point) is that they understood exactly what was meant and
> were able to act accordingly when choosing what to put in their
> implementations.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 18 Jan 2008 09:02:17 -0500

>meant and were able to act accordingly when choosing what to put in 

I think this addition of 2119 words is quite useful.
More and more of our work shifts from protocol definition to
protocol maintenance these extra keywords give working groups a way 
to indicate to
developers/purchasers/planners/operators/regulators[1]
what the requirements for the protocol are going to be in the next few years.

More and more of the software we deal with is now released in multi 
year cycles
followed by multi year deployment lag. Further more number of 
protocols are embedded
in hardware devices that are frequently not updated during the 
device's lifetime,
think the router in homes.

Question: the use of +/- in the context of "? NOT", is that going
to be written as "SHOULD+ NOT" or "SHOULD NOT+" ?
I have no feeling on the topic just think it should be documented.

I support this document and what it is trying to accomplish.

         Olafur
PS: [1] Even though most of the people in the IETF are implementors or
lobbyists the documents get used by a large group that is absent
from the IETF and due to their roles would contribute nothing
even if they attended.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Jan 2008 12:55:44 -0800

>an implementor should interpret them.

Yes, that sounds reasonable. I'll prepare an appendix with some 
discussion on this.

>I think that should be mentioned.

That section of RFC 2026 talks about Applicability Statements. Does 
that really apply here? I think that the new terms only apply to TSs, 
not ASs.

>is no difference from the regular terms, but it needs

Good point, added.

>an updated version of the boilerplate specified

Good catch.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jan 2008 10:04:38 +1300

Paul,

> At 11:10 AM +1300 1/16/08, Brian E Carpenter wrote:

...
> That section of RFC 2026 talks about Applicability Statements. Does that
> really apply here? I think that the new terms only apply to TSs, not ASs.

Well, I've been looking at that aspect of 2026 quite closely
while working on draft-carpenter-rfc2026-changes, and I think it's
a bit confused. The only place in 2026 where requirement levels for
individual features is discussed is in the description of ASs, but
we normally define the requirement levels in TSs. So I think 2026
is inconsistent with reality there. Anyway, adding this reference
to your draft is a matter of taste.

   Brian