Subject: Re: [dnsext] draft-registry-fixes terms question

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Jun 2010 14:56:16 -0400

Dear colleagues,

On Tue, May 18, 2010 at 08:32:05AM -0400, Rose, Scott W. wrote:

> So a question posed to the working group about the terms.  Either:
> 
> 1. Define the terms in draft-registry-fixes as they are used in the doc (basically, copy the text from draft-ogud-iana-protocol-maintenance-words and place them in a separate section in this draft.
> 
> 2.  Use "SHOULD+" instead of DISCRETIONARY (and define it), MUST instead of MANDATORY and MUST NOT for OBSOLETE.  
> 
> 3. do nothing (assume that draft-ogud-iana-protocol-maintenance-words will advance).

This question hasn't garnered any responses.  I think we need to
resolve this before it is sent from the WG.  If nobody objects by
Friday, I will conclude that the answer is (1).  My grounds for this
is that those are the words that were in the text during WGLC, and my
impression is that most of the complaints about those words had to do
with their applicability outside this context, and not for their
utility in this particular instance.  If you disagree, now would be a
good time to say so.

A (speaking as document shepherd for this I-D).

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Jun 2010 12:35:40 -0700

At 2:56 PM -0400 6/7/10, Andrew Sullivan wrote:
>This question hasn't garnered any responses. 

In my case, it is because there was never a response to my earlier question on "what is this document talking about", so I can't say what kind of wording is needed. To recap:

The document says that "implementors need to know which algorithms need to be implemented, which are optional, and which are obsolete" and "implementors must read through all the documents in order to discover which algorithms are mandatory to implement and which are optional or no longer used". Nowhere in the current document does it say what it means by "mandatory".

In the IETF, a single RFC can make something mandatory for implementing the RFC. We have no concept of "mandatory for a protocol" or even "mandatory for a named group of documents" (the latter is accomplished only by making all the documents but one point to the other document for the mandatory parts).

The strong hint in this document is that it is trying to define "mandatory for DNSSEC". If so, the document has no place in the IETF. The IETF has tried repeatedly and failed repeatedly to define such a structure. This document is doing an end-run on the IETF lack-of-process in this area.

>I think we need to
>resolve this before it is sent from the WG. 

Fully agree.

>If nobody objects by
>Friday, I will conclude that the answer is (1). 

I object. Without defining "mandatory to what", all wording in this document is open to obvious misinterpretation.

>My grounds for this
>utility in this particular instance. 

That's one interpretation; another is that the context is not part of the IETF and yet is undefined.

>If you disagree, now would be a
>good time to say so.

See above. :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Jun 2010 17:05:45 -0400

On Mon, Jun 07, 2010 at 12:35:40PM -0700, Paul Hoffman wrote:
> 
> In the IETF, a single RFC can make something mandatory for
> implementing the RFC. We have no concept of "mandatory for a
> protocol" or even "mandatory for a named group of documents" (the
> latter is accomplished only by making all the documents but one
> point to the other document for the mandatory parts).

So isn't this innovation just an extension of that?  That is, instead
of making those other documents point to one document that has the
requirements levels in it, you point to one document that defines the
registry in which the requirements are set?  Why is that bad?

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Jun 2010 17:45:46 -0700

At 5:05 PM -0400 6/7/10, Andrew Sullivan wrote:
>So isn't this innovation just an extension of that? 

It attempts to silently, yes. It never says that is what it is doing, so we have to guess.

>That is, instead

Many of us think it would be good, but we lost that battle in the IETF long ago; see the "newtrk" effort for the gory details. Without the authors knowing it (except when I have brought it up), they have reopened the debate by saying, I think, "we should be able to call something DNSSEC and here is how the mandatory algorithms for that thing are defined". That is not acceptable in today's IETF, despite what many of us wanted.

Of course, if you want to have the food fight during IETF Last Call, and especially during IESG review, go ahead, but it will be Ugly. And it should be: why should DNSSEC be able to do this when, for example, SIP has not?

Until you answer this, the WG cannot decide which type of words should be used in the draft to bring to IETF Last Call. More significantly, we cannot help IANA to know what to do for the registry, given that they won't know which RFCs do and don't affect the registry because a new RFC should not inherently part of "DNSSEC" just because the RFC says so.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Rose, Scott W." <[email-masked]>
Date: Tue, 8 Jun 2010 09:02:32 -0400

> It attempts to silently, yes. It never says that is what it is doing, so we have to guess.

Then text can be added to state that.  This doc's original attempt was to simply add a column to the IANA registry to guide implementors as to the current status of signing algorithms in DNSSEC.  Each status is in the RFC (well, some of them have it), so this was an attempt to collect it in the registry and add status for algorithms that were specified without one.

RFC 4034 started it (Section A.1, not the IANA recommendations though), but subsequent docs did a poor job of following up.  This doc adds new terms and would define previously used terms in order to give implementors as sense of the state of the art and a hint (best we can) of what a future doc might say about algorithm status.  

> Of course, if you want to have the food fight during IETF Last Call, and especially during IESG review, go ahead, but it will be Ugly. And it should be: why should DNSSEC be able to do this when, f…
Because they were smart enough to stop?  :)  If it gets shot down at last call, it gets shot down.  I'll stop working on it and do something productive.  

> Until you answer this, the WG cannot decide which type of words should be used in the draft to bring to IETF Last Call. More significantly, we cannot help IANA to know what to do for the registry,…
Would more text giving guidance for the authors of future drafts adding algorithms to DNSSEC help?  I would think anything seeking to update the IANA registry for Domain Name System (DNS) Security Algorithm Numbers would fall under this.  

Scott

> --VPN Consortium

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 Jun 2010 15:02:05 -0400

Hi,

On Tue, Jun 08, 2010 at 09:02:32AM -0400, Rose, Scott W. wrote:
> Then text can be added to state that.  This doc's original attempt
> was to simply add a column to the IANA registry to guide
> implementors as to the current status of signing algorithms in
> DNSSEC.  Each status is in the RFC (well, some of them have it), so
> this was an attempt to collect it in the registry and add status for
> algorithms that were specified without one.
> 
> RFC 4034 started it (Section A.1, not the IANA recommendations
> though), but subsequent docs did a poor job of following up.  This
> doc adds new terms and would define previously used terms in order
> to give implementors as sense of the state of the art and a hint
> (best we can) of what a future doc might say about algorithm status.

Off-list, Paul Hoffman went at my little brain until I think I
understood the problem he's worried about.  We do seem to have a
tricky procedural problem.  I'll attempt to summarize my
understanding; errors or doofus-indicating remarks are my fault and
not Paul's.

The basic problem comes down to the authority for what is written in
an IANA registry.  Normally, an IANA registry gets its data from an
RFC.  The registry relies on the RFC in order to specify what is and
is not mandatory, among other things.

The draft as it stands effectively pushes that authority _into_ the
registry itself, even though that isn't the intent.  I think the
reason for this is because we were trying to do two things at once:
add the indicator to the registry, and also clarify the status of the
different algorithms as we added the indicator.  But in so doing, we
remove the fundamental justification for the levels in the registry
(because some RFCs don't have such a requirement level built in).

Moreover, if another document on the standards track comes along and
updates the registry with a new mandatory-to-implement option, does
that mean that the day the registry changes, all the
formerly-DNSSEC-implementing DNS systems in the world are,
presto-change-o, no longer implementing "DNSSEC"?  This is the crux of
Paul's complaint that the IETF doesn't have "DNSSEC compliance", just
"conforms to this or that RFC".  Without such a list of RFCs being the
authoritative source of data, the RFC series loses its primacy in
determining conformance.  Instead, the registry becomes primary, but
the registry is not an archival series.

I think the right thing to do here is manifold.  

    - First, we need to solve the terminology problem for real.

    - Second, we need this document to update all the relevant RFCs in
    question, making this document authoritative for the requirements
    levels of all algorithms in the registry.

    - Third, the document needs to be altered to state that the
    contents of the registry for all algorithms that are OBSOLETE,
    DISCOURAGED, ENCOURAGED, and MANDATORY (or whatever terms we pick)
    is determined by this document or its successors.  This is a
    stronger statement of the intention behind the paragraph after the
    sample registry in section 2.2.  The basic idea is that new
    algorithm ids may be easy to get, but they're only optional
    algorithms.  If you want anything stronger, or to "downgrade" the
    status of an algorithm, you have to go through the full standards
    track procedure and you have to issue an update of this document.
    (The point of requiring an update of this document is that it
    still results in the desired goal of having one and only one place
    to look up the current registry rules.)

I believe that if we took that approach, it would address the
objection that this is newtrk by a different method.

Thoughts?

A

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jun 2010 15:31:41 -0400

>the registry is not an archival series.

When it comes to "solutioning" I see the RFC as a third tier player.

First tier is the RFP, the request for proposal.  This is where I 
expect to see the desired set of RFCs listed.  Many times the RFP 
issuer will list some RFCs and then have a "and please add what your 
service does above and beyond this."  Ultimately, after the who 
procurement process runs it's course, the contract takes over 
precedence.

Second tier is the registry, listing the protocol parameters that are 
in play.  It doesn't matter what the registry says regarding 
"mandatory to implement" because the RFP/contract trumps that.  But 
the registry is what points me to the needed documents to understand 
the protocol parameter values.

Third tier are the reference and definition documents.  The RFCs sit 
here.  They define the mechanisms, the approaches, and give the 
engineering rationale that drive designs.

There's no one-size fits all definition to DNS service.  If there 
were, the DNS component of an RFP and RFP response would be reduced 
to a page or paragraph.  As far as whether the registry should be the 
arbiter of the status of a protocol parameter, it doesn't matter 
much.  So long as I am able to identify the document defining what an 
RRTYPE of 40 means the registry has done it's job.  (40 is defined by 
[Eastlake] --  oops, bad example.)  Maybe I should have used 34 as 
the example.

PS - No offense to Donald...it's just that there should be a document 
that says that the SINK RR was tossed out with the bath water.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 Jun 2010 15:57:43 -0400

On Tue, Jun 08, 2010 at 03:31:41PM -0400, Edward Lewis wrote:

> or paragraph.  As far as whether the registry should be the arbiter of 
> the status of a protocol parameter, it doesn't matter much.  So long as I 
> am able to identify the document defining what an RRTYPE of 40 means the 
> registry has done it's job.  (40 is defined by [Eastlake] --  oops, bad 
> example.)  Maybe I should have used 34 as the example.

I probably wasn't clear enough, but I think you're describing the crux
of the problem.  Suppose that the registry says that RRTYPE NN is
MANDATORY, and your contract says that the contracting party needs to
conform to the registry.  So they contract with you, implement that,
and then the registry is updated to make RRTYPE NN to be DISCOURAGED.
Now what?  Are they conforming to your contract, or not?

In the case of an RFC, the reference is stable.  If you want the
vendor to replace RFC MMMM with its successor, RFC MMMM+X, your
contract has to say that.  But the registry is only a stable reference
in the sense that it's the same name for the _current_ values: the
name stays the same but the data changes.  So the pressure to put
requirements levels in RFCs and not registries (as the "authority
source") comes from wanting an archival series, in which the data and
the name both remain stable once they're set.  

A

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

---

From: Alex Bligh <[email-masked]>
Date: Tue, 08 Jun 2010 21:16:56 +0100

> the name both remain stable once they're set.

Right, so RFCs should (according to the above argument) not contain
forward links, i.e. they should not say "X MUST comply with the
registry as it is at any future date", but "X MUST comply with
the registry as it is now" or "X MUST comply with [dump of
registry]". The registry is a compilation of all the changes
to it detailed by prior RFCs.

I think I agree with that.

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 Jun 2010 16:33:46 -0400

> to it detailed by prior RFCs.

I'm doing a stupendously bad job at explaining this.  I don't think
it's possible to make a normative requirement on the state of the
registry at a given timestamp, because there's no archive of registry
states.

What I am suggesting is that we summarize all the requirements for
every algorithm in one document.  The obvious one to pick is the
document we've been working on.  That document _also_ alters the
registry to add a column that describes the requirement level for the
algorithm, so if you're an implementer today you can go, look in the
registry, and see what the various levels are.  All rows in the
registry (at the point when we do this) refer to the
eventually-published RFC that this document becomes.

The document further states that adding any algorithm with the
requirement level DISCRETIONARY (or whatever words we use for this
status, which is basically that it's optional) can do so by following
the rules in [draft-ietf-dnsext-dnssec-alg-allocation, coming soon to
an RFC repository near you].  Adding any algorithm with any other
status, or modifying any algorithm's status in any way, requires an
update of this document.  That's a standards action.  The new document
then updates the registry.

This achieves almost all the goals we wanted.  It makes (or continues
to make) getting an assignment for optional algorithms easy.  It makes
the registry effective in informing an implementer what s/he needs to
do.  It centralises in one place all the required, deprecated,
&c. algorithms.  It allows us to put "the next algorithm to use"
clearly in line.  It allows us to deprecate algorithms in a clear and
comprehensible way.  And it does not try to sneak some new authority
for the registry in through the back door, instead requiring every
change of the right sort to be a standards action.

Make sense? 

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Jun 2010 13:53:28 -0700

>to it detailed by prior RFCs.

This has the arrow pointing the wrong way. The RFC says:
- Implementations conforming to this document MUST implement A, B, and C
- Implementations conforming to this document SHOULD implement D and E
- Implementations conforming to this document SHOULD NOT implement F and G
- The Foo registry at IANA is to be updated to match the rules given in this document

That is, the Foo registry mirrors the latest RFC, and only the latest RFC.

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jun 2010 17:08:12 -0400

>Now what?  Are they conforming to your contract, or not?

You have to be "dynamic" then, if that's what the contract calls for.

To wander off-topic for the list, I've seen this in places unrelated 
to DNS operations.  There was a time when we used custom solutions to 
operate spacecraft and wound up supporting obsolete hardware well 
past the demise of the manufacturer.  This spurred the adoption of 
off-the-shelf components and then the adoption of open source 
packages.  Soon there after we had to learn the term "technology 
refresh" and say good bye to the "waterfall model."

But, to answer the on-topic question, I'd rather the registry be just 
a registry: that is a mapping of object (protocol parameter) to an 
entity (document).  I'd prefer then that the document explain the 
rationale behind the parameter and describe, without bias the 
tradeoffs of implementing it or not.  Overtime the entity (document) 
could be changed, because the RFC series does not feature revision 
numbers.  (There is an errata mechanism.)

My original answer rattled on for a while.  The world of contacting 
is complex and more or less ultimately irrelevant to the question.

I would push for keeping the registry simple and the RFCs as 
definitions.  Let outside forces decide what's commonplace and what's 
to be avoided.

RFC 3935 has this:
       Standard: As used here, the term describes a specification of a
       protocol, system behaviour or procedure that has a unique
       identifier, and where the IETF has agreed that "if you want to do
       this thing, this is the description of how to do it".  It does not
       imply any attempt by the IETF to mandate its use, or any attempt
       to police its usage - only that "if you say that you are doing
       this according to this standard, do it this way".  The benefit of
       a standard to the Internet is in interoperability - that multiple
       products implementing a standard are able to work together in
       order to deliver valuable functions to the Internet's users.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 08 Jun 2010 23:26:32 +0100

--On 8 June 2010 16:33:46 -0400 Andrew Sullivan <[email-masked]> wrote:

> I'm doing a stupendously bad job at explaining this.

I may be doing a stupendously bad job in understanding you (I
plead tiredness)

>  I don't think

Right. But an RFCxxxx that refers to the registry's content or structure
must necessarily referring to it at the time of that RFCxxxx, not
any future date (i.e. if either content or structure are modified
by RFCyyyy where yyyy>xxxx, any given implementation's compliance
with RFCxxxx should remain unaltered if we want RFC like behaviour).

So whilst we don't have an archive of registry states per say, we
can (and I think must) construct the state by compositing all
previous changes to the registry (assuming the registry doesn't
contain a change log).

This is a general comment about how I thought IANA registries work,
not a specific comment about DNS.

> eventually-published RFC that this document becomes.

I suppose my question is this. Let us suppose we do what you say, and
this is published as RFCnnnn. Does RFCnnnn say something along the
lines of:
" * The [server] MUST implement those algorithms marked MANDATORY
    in column X of the algorithm registry
  * The [server] SHOULD implement those algorithms marked DESIRABLE
    in column X of the algorithm registry
  (and so on)". (*)

If it does do this, then we have a potential issue. Suppose
at the date of this RFCnnnn, the Rhubarb algorithm is MANDATORY but
the Gooseberry algorithm has not yet been invented. A vendor
then produces code which implements Rhubarb, but not Gooseberry.
Time passes, and by standards action RFCrrrr is introduced, where
rrrr>nnnn. RFCrrrr by standards action modifies the registry
(and updates RFCnnnn or whatever), to make Gooseberry MANDATORY
and Rhubard DEPRECATED. Obviously the vendor's implementation
is not compliant with RFCrrrr. However, this would appear to
change whether it is compliant with RFCnnnn. The way most RFCs
behave as far as I could tell is the vendor's software in
perpetuity is RFCnnnn compliant but not RFCrrrr compliant.
However, now (assuming the text at '*' is read to mean
'at the time the of reading' as opposed to 'at the time of
writing), it ceases to become RFCnnnn compliant. If it means
'at the time of writing' you have to reverse engineer the
previous state of the registry, to determine that when
RFCnnnn was written Gooseberry was not in the registry and
Rhubarb was manadatory. That's easy in this case as RFCnnnn
defined the registry, but what about for RFCpppp which
is somewhere between?

I have a feeling I must be being very thick here and should
get some sleep.

> Make sense?

Partially :-)

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jun 2010 09:06:05 -0400

Now I see the disconnect.

>    in column X of the algorithm registry

No, that's not how it works.  RFCnnnn says

    * Algorithms A and B are MANDATORY.  A server MUST implement those
      algorithms.  A client MUST be capable of using them.

    * Algorithms D and E are ENCOURAGED.  A server SHOULD implement
      those algorithms.  A client SHOULD be capable of using them.
      These algorithms are expected to become MANDATORY in future.

    * Algorithms G and H are DISCOURAGED.  A server MAY decline to
      support them.  A client SHOULD NOT use them.  These algorithms
      are expected to become OBSOLETE in future.

    * Algorithm Z is OBSOLETE.  A server SHOULD NOT support it.  A
      client SHOULD NOT be capable of using it.

    * IANA is requested to update The DNS Security Algorithm Number
      subregistry with the above values.  

When you're ready to change G and H to OBSOLETE, you create a new
RFCrrrr that obsoletes RFCnnnn.

> perpetuity is RFCnnnn compliant but not RFCrrrr compliant.

Exactly right.  And that's why we can't put the authority in the
registry, but must put the authoritative definition in some RFC.

A

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

---

From: Alex Bligh <[email-masked]>
Date: Wed, 09 Jun 2010 14:24:59 +0100

> registry, but must put the authoritative definition in some RFC.

+1 - thanks for explaining to the hard of understanding.

-- 
Alex Bligh