Subject: [dnsext] Proposed fixes for draft-registry-fixes

From: "Rose, Scott W." <[email-masked]>
Date: Thu, 17 Jun 2010 10:30:03 -0400

Based on the comments on the mailing list regarding draft-registry-fixes regarding terminology, and Section 2.2, the following changes are proposed.  Right now, this is what will appear in -05 version of the draft (not posted yet):

1.  The draft now updates [RFC2536],
   [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and
   draft-dnssec-gost (RFC TBD).  The IANA considerations section is also updated accordingly.

2.  Terminology section (terms in -04 used to indicate status):

      MANDATORY: Implementations MUST support this algorithm to be
      considered currently inter-operable.

      DISCRETIONARY: Implementation MAY support this algorithm.  The
      presence or lack thereof this algorithm MUST NOT be used to judge
      standards compliance.

      ENCOURAGED: Implementations SHOULD support this algorithm, but
      like DISCRETIONARY, lack of support MUST NOT be used to judge
      standards compliance.  This term is also used to hint of a
      possible status change in the future to MANDATORY.

      OBSOLETE: New implementations SHOULD NOT support this algorithm.

Comment:  "DISCRETIONARY" or "OPTIONAL"?  I have no strong feelings.  OPTIONAL is already used in the documents so I would like the change.

3.  New section 2.3:
2.3.  Specifying New Algorithms and Updating Status of Existing Entries

   The requirement status for all new algorithms specified using the
   process in [I-D.ietf-dnsext-dnssec-alg-allocation] MUST be
   DISCRETIONARY by default.  Only a Standards Track document may change
   the status of any new or existing registry entry.  Such a document
   would necessarily update this document.

Comment:  Ok, I'm not too thrilled with having the MUST there, suggestions?  

Scott

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Jun 2010 08:43:17 -0700

>Based on the comments on the mailing list regarding draft-registry-fixes regarding terminology, and Section 2.2, the following changes are proposed.  Right now, this is what will appear in -05 versi…

Did you update the pre-draft to say what "implementations" means? That is, one of the important changes that we discussed is that you need to be clear that "implementations" means "implementations of this document", not "implementations in general". This is also extremely important for the IANA Considerations section.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Jun 2010 12:07:16 -0400

>    draft-dnssec-gost (RFC TBD).  The IANA considerations section is also updated accordingly.

Good.

>       considered currently inter-operable.

See Paul's comment on this.  I'm not exactly sure how to make the text
clearer that it's "implementations conforming to this document", since
the document can hardly specify conformance to some other document.

>       presence or lack thereof this algorithm MUST NOT be used to judge

The "judge standards compliance" here and in the next one probably
ought to say instead "to determine conformance with this document" (or
"compliance" if you like).

>  Comment: "DISCRETIONARY" or "OPTIONAL"?  I have no strong feelings.
> OPTIONAL is already used in the documents so I would like the
> change.

I have no objection to OPTIONAL.  

I presume there's no definition of DISCOURAGED because we don't have
any right now?

> Comment:  Ok, I'm not too thrilled with having the MUST there, suggestions?  

It needs to be MUST (or I guess I should say it MUST be MUST).  Also
drop the "by default".  There is no way for any algorithm to get
specified under [I-D.ietf-dnsext-dnssec-alg-allocation] and be
anything other than optional because to make it REQUIRED would entail
updating one of the documents that the present draft is updating.  I
find your text a little awkward, however.  How's this:

     [I-D.ietf-dnsext-dnssec-alg-allocation] provides a procedure for
     obtaining an algorithm number for new algorithms.  Algorithms
     entered into the registry using that procedure are always
     OPTIONAL.

     Adding an algorithm to the registry with any status other than
     OPTIONAL SHALL entail an update of this document, in order to
     specify new contents for the registry.

     Altering the status of any algorithm in the registry SHALL entail
     an update of this document, in order to specify new contents of
     the registry.

?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Rose, Scott W." <[email-masked]>
Date: Thu, 17 Jun 2010 13:13:53 -0400

> the document can hardly specify conformance to some other document.

Forgot that - It will go before the other terminology:

"In the definitions below, 'implementation' refers to components (e.g. validators, signers, etc.) seeking to conform to this document."

> "compliance" if you like).
Will fix.

> I presume there's no definition of DISCOURAGED because we don't have
Basically - yes.  Plus I don't know if DISCOURAGED will be used that much.  If it requires one standards track doc to move an entry to DISCOURAGED, then another to move it again to OBSOLETE, it seems to be a lot of churn.

>     an update of this document, in order to specify new contents of
Better, but for the last paragraph:

Altering the status of any algorithm in the registry SHALL entail an update of this document in order to change the contents of the registry.

(minor wording, but it isn't adding new content, but changing existing stuff).  

Scott

---

From: Florian Weimer <[email-masked]>
Date: Thu, 24 Jun 2010 09:07:07 +0000

>       considered currently inter-operable.

Not "compliant with this specification"?  (You can't define
interoperability in a standard.)

> OPTIONAL is already used in the documents so I would like the

Isn't the official set of adjectives REQUIRED, OPTIONAL and
RECOMMENDED, anyway?

> Comment:  Ok, I'm not too thrilled with having the MUST there, suggestions?  

I wonder what the reasons are behind putting those attributes in the
IANA registry.  Implementations cannot claim compliance with the
registry in general, only with specific RFCs (or versions of the
registry in certain points of time).  The requirement not to use MUST
in RFCs for new algorithms means that you can be compliant with the
RFC without actually implementing the algorithm, which is just
bizarre.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: "Rose, Scott W." <[email-masked]>
Date: Thu, 24 Jun 2010 09:51:42 -0400

> interoperability in a standard.)
Noted prior, changing to:

	MANDATORY:  Implementations MUST support this algorithm to be 
	considered conforming to this document.

> Isn't the official set of adjectives REQUIRED, OPTIONAL and
Could go with the 2119 defs and use REQUIRED and OPTIONAL, but there isn't anything that syncs with ENCOURAGED.  "RECOMMENDED" comes close, but there's a need to give a hint about future path (the RFC 2119 def of RECOMMENDED doesn't have this, so we can't assume it will be implied).  

The terms were originally from draft-ogud-iana-protocol-maintenance-words

> RFC without actually implementing the algorithm, which is just
The document does not state that the goal is to make the registry authoritative, the document (RFC) would be (and any updating doc).  The goal of the column is to put the status of each algorithm (based on the relevant RFC) so implementors don't have to search through RFC's and DNSSEC history (since some RFC's that specify algorithms do not give their status) to find out what algorithms should be included, what the future direction might be, and which algorithms are falling out of favor.  

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Jun 2010 08:55:24 -0700

>The terms were originally from draft-ogud-iana-protocol-maintenance-words

There are at least two ways to go here:

- Use the official word "SHOULD" with an in-line augmentation

- Define a new word-meaning pair

The first way would be a lot clearer to most implementers. For example, the text can say "SHOULD implement because it is expected that this will become a MUST-level requirement in the future".

In the Security Area, we have experimented with defining this as "SHOULD+" (with a related "MUST-" which means "MUST implement now, but it is expected this will be downgraded in the future"). These definitions were only somewhat popular. IETF regulars understood them well, but other developers were confused.

>The document does not state that the goal is to make the registry authoritative, the document (RFC) would be (and any updating doc).  The goal of the column is to put the status of each algorithm (b…

In essence, this document proposes adding a column to the IANA registry with the normative levels from this document. The result is that an implementer would see a column with MUST and SHOULD and so on.

What happens if a different standards-track document adds another column with different values? Will the implementer be better off or worse off? (Yes, that's an obviously leading question.)

Instead of adding such a column to the registry, it might be more helpful to have the registry list standards track RFCs that are collections of normative levels. In the best situation, that list lists exactly one RFC  (this one). If in the future there is a reason to have two different standards track RFCs listed, the developer could easily read each of them and make a judgement about which RFC they want to follow, if any.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian Dickson <[email-masked]>
Date: Thu, 24 Jun 2010 13:56:54 -0300

On Thu, Jun 24, 2010 at 12:55 PM, Paul Hoffman <[email-masked]>wrote:

> >Could go with the 2119 defs and use REQUIRED and OPTIONAL, but there isn't
> anything that syncs with ENCOURAGED.  "RECOMMENDED" comes close, but there's
> a need to give a hint about future path (the RFC 2119 def of RECOMMENDED
> doesn't have this, so we can't assume it will be implied).
> >
> The first way would be a lot clearer to most implementers. For example, the
> text can say "SHOULD implement because it is expected that this will become
> a MUST-level requirement in the future".
>
>
What about associating the word-to-use (and optionally its meaning if a new
word-meaning pair are used), with the document status?

It's a bit self-referential, but allows the document to essentially
self-modify as the standard progresses along the standards track, without
actually changing any of the text itself, only the current reading of the
text.

The challenge is in making the text readable, and yet having the definition
both clear and sufficiently generic so as to be usable in any such document.

In the abstract, it would be "metaterm(term,state)", where "term" would be
the generic form (or eventual form, once full standard state is reached),
and "state" is a way of representing the current document state (draft,
proposed, full standard), and the "metaterm" function combines the two
inputs with suitable syntactic sugar.

Candidates for metaterm might be, for example:
${term}_\$${shortstate} (for example, "MUST_$SS" )
${term}[${shortstate}] (for example, "MUST[SS] )
${term}%${shortstate} (for example, "MUST%SS" )

This then needs "definemetaterm(term, state, @term_state_list)" which
produces an instantiated list of metaterm definitions, for each metaterm
used.
Each document would need to include in a definitions section, with table(s)
(the "definemetaterm" output(s)), that would look like:

metaterm(term,state) is defined as follows:
${shortstate1}  REALTERM1
${shortstate2}  REALTERM2
...

For example:

MUST[SS] is defined as follows:
SS     MUST[SS]
--     --------
DS    SHOULD
PS    MUST
STD  MUST

(and so on, for each term that might want to change as the standard
"matures".)

This could even be done as a normal 2-d table, with the x-axis being
metaterms, and y-axis being document state, and cells being per-state terms.

It's a bit more explicit, and certainly unambiguous, and fits nicely into
tables such as the one we're thinking of for IANA.

Thoughts?

Brian

> In the Security Area, we have experimented with defining this as "SHOULD+"
> (with a related "MUST-" which means "MUST implement now, but it is expected
> this will be downgraded in the future"). These definitions were only
> somewhat popular. IETF regulars understood them well, but other developers
> were confused.
>
> >The document does not state that the goal is to make the registry
> authoritative, the document (RFC) would be (and any updating doc).  The goal
> of the column is to put the status of each algorithm (based on the relevant
> RFC) so implementors don't have to search through RFC's and DNSSEC history
> (since some RFC's that specify algorithms do not give their status) to find
> out what algorithms should be included, what the future direction might be,
> and which algorithms are falling out of favor.
>
> In essence, this document proposes adding a column to the IANA registry
> with the normative levels from this document. The result is that an
> implementer would see a column with MUST and SHOULD and so on.
>
> What happens if a different standards-track document adds another column
> with different values? Will the implementer be better off or worse off?
> (Yes, that's an obviously leading question.)
>
> Instead of adding such a column to the registry, it might be more helpful
> to have the registry list standards track RFCs that are collections of
> normative levels. In the best situation, that list lists exactly one RFC
>  (this one). If in the future there is a reason to have two different
> standards track RFCs listed, the developer could easily read each of them
> and make a judgement about which RFC they want to follow, if any.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>

---

From: "Rose, Scott W." <[email-masked]>
Date: Thu, 24 Jun 2010 14:46:46 -0400

> In the Security Area, we have experimented with defining this as "SHOULD+" (with a related "MUST-" which means "MUST implement now, but it is expected this will be downgraded in the future"). These…

That's the driving force behind draft-ogud-iana-protocol-maintance-words (or was, anyway).  

> Instead of adding such a column to the registry, it might be more helpful to have the registry list standards track RFCs that are collections of normative levels. In the best situation, that list l…

Ok - not opposed to that.  The reasoning behind a column was to have the registry sync with the DS RR Type Digest Algorithm registry.   

One question:  Should there be 3 or 4 lists?  I can see the MUST list, an OPTIONAL list an OBSOLETE list, but should there be a RECOMMENDED/ENCOURAGED/SHOULD+ list?  

Scott