Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-registry-fixes-06

From: Alfred Hönes <[email-masked]>
Date: Wed, 1 Dec 2010 13:49:11 +0100 (MEZ)

Paul,
you have presented a modified registry table for the draft
under consideration.
  <http://www.IETF.ORG/mail-archive/web/dnsext/current/msg10121.html>

> ...
>
> Please let me know if you think I have succeeded in keeping
> the ideas from -06 but making them clearer.

IMO, that's true.
Standards terminologists might however prefer "Compliance with" over
"Conformance to" in such cases -- in SMIv2 language, this draft could
be regarded as a COMPLIANCE statement (recorded in the table column)
that implementations can claim to conform to.
So maybe this change of term could earn bonus points with the OPS ADs
in the IESG.  :-)

Someone had raised concerns about not filling in the new column
for algorithms that are considered "DISCRETIONARY" or "OPTIONAL".

IMO, it makes sense to stay with the current style (that you have
preserved), i.e. to only add entries in the newly added column where
the document expresses a standing-out viewpoint.  This should help to
visually focus implementors on the important statements of this memo.

Maybe, for completeness, a footnote could be added to the table
that says:  

   Table rows where the Conformance column is not filled in are left
   to the discretion of implementors, i.e. they are strictly OPTIONAL.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Dec 2010 07:48:08 -0800

>> the ideas from -06 but making them clearer.

Thanks. What do others think?

>So maybe this change of term could earn bonus points with the OPS ADs

This is a distinction without a difference. There are no solid definitions for either term, but there *is* a difference from "status".

>visually focus implementors on the important statements of this memo.

Andrew tells me that I was the one wanting to fill in that column a few months ago, but after a discussion with him, I don't remember my logic. I, too, prefer the blank entries that Scott used and I copy here.

>   to the discretion of implementors, i.e. they are strictly OPTIONAL.

But that's not true. For example:
 12      GOST R          GOST-ECC   Y     *                   [RFC5933]
         34.10-2001                                         
For an implmenter who wants to implement GOST-ECC, it is not "optional". It is only optional for those who want to only implement from RFC TBD1. There is no reason to make this confusing point in the IANA registry, I believe.

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Dec 2010 13:32:14 -0500

>Thanks. What do others think?

Since you asked...

I think the compliance column is useless.  I've stayed away from this 
debate until now because I can't think of any reason to support 
putting any such recommendations in the registry.

To me it is like having a registry that says 10.1.1.0/24 belongs to 
Bill's Bait and Sushi and 10.1.2.0/24 belongs to Ralph's Bait and 
sushi - and then adding reputations to that.

   Address Block     Owner                  Worth doing business with
   10.1.1.0/24       Bill's Bait and Sushi  Untrustworthy
   10.1.2.0/24       Ralphs' Bait and Sushi Paid his promotional fee

Implementors build code for different reasons.  What's required for 
one situation might be unwise in another.  Implementors should be 
free to pick their own constituency.  No one is forced to implement 
DNSSEC, or NOTIFY, for that matter.

If you want to develop an RFC that gives a profile of what 
constitutes a general purpose implementation, that's where it is 
appropriate to say what is needed for such a beast.

If you want to opine on the goodness of cryptographic algorithms, I'm 
sure there  is an appropriate soap box somewhere.

The DNS RR type registry doesn't do this - it doesn't say what types 
are required.  There are a few marked as experimental or obsolete, 
but that hasn't been kept up, a sign it's not that useful.  (Are A 
records as important to an implementation as KX records?  The answer 
isn't in the registry, but we all know the answer - as far as we 
[personally] care.)

I think the column is a bad idea, goes against what a registry is 
meant to do, will just become something that fails to be maintained, 
and result in more confusion amongst new(bie) implementors that do 
not follow the IETF daily.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 1 Dec 2010 14:19:31 -0500

I understand the argument, but I don't think it applies here.  This doc doesn't seek to force anything, just gives a set of requirements if an implementor wants to claim conformance to "DNSSEC". 

Implementors writing code to meet a specific purpose may or may not care about compliance, and that's fine as long as those using the code don't care either.  They may not even care about RFC's or registries at all.  However, operators and admins have requirements too, and don't use custom code but want/expect compliance to some definition of a protocol. 

The doc also explicitly states that this is not an effort to put value judgements on cryptographic algorithms, only which ones should be implemented to claim conformance.  

As for the final point, yes I agree that this must be maintained somehow or else it will become dated and stale - that's what is happening now. 

Scott

> not follow the IETF daily.

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Dec 2010 14:41:14 -0500

At 14:19 -0500 12/1/10, Rose, Scott W. wrote:
>I understand the argument, but I don't think it applies here.  This doc
>doesn't seek to force anything, just gives a set of requirements if an
>implementor wants to claim conformance to "DNSSEC".

To clarify the theme of my objection, a registry is the wrong place 
to document conformance criteria.  Conformance belongs in profile 
documents and documents that act as contracts, memoranda of 
understanding, rules and regulations.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Dec 2010 16:15:23 -0500

On Wed, Dec 01, 2010 at 02:19:31PM -0500, Rose, Scott W. wrote:
> I understand the argument, but I don't think it applies here.  This
> doc doesn't seek to force anything, just gives a set of requirements
> if an implementor wants to claim conformance to "DNSSEC".

Speaking both personally and with my chair hat on, I disagree with the
above characterization, and were it true I don't think this WG would
be in a position to add such a column to the registry.  We can't, and
Ed is right about why: registries cannot be the source of any
authority to which one can comply.  They're not immutable documents
like RFCs, so there's no way to conform to them (because the reference
isn't stable).  Moreover, there is no such thing as "conformance to
DNSSEC", because DNSSEC is defined in a set of RFCs.

What the registry _is_ supposed to be is a useful tool for
implementers and contract writers.  Implementers can look in a
registry and know what they need to implement; the details of that
implementation are supposed to be pointed to by the registry.
Similarly, a contract writer can look in the registry and see what
things are needed for the compliance checklist (again, possibly
following the RFC references from the registry in order to provide
detail and stable references for the contract).

The problem with the DNSSEC algorithm registry as it stands is that it
doesn't actually provide that.  You can't tell, from looking at the
registry, which things are needed for which sort of interoperation.
This is harmful to both implementers and contract writers.

So the goal of the current approach is in fact to give quick, easy to
find guidance to those two constituencies, the main users of such a
registry.  Assuming the current document were to become an RFC, then
the stable reference for the implementation levels for these
algorithms would in fact be _this_ document, although the details of
how to do the implementation will remain in the RFCs that actually
specify the algorithms and their use in DNSSEC.  (This is, by the way,
one of the reasons I like Paul Hoffman's suggestion about how to
recast the table so much: it makes this distinction clear.)  When
we're done, contract writers will be able to specify implementation of
RFC TBD1, and implementers will be able to say that they have
implemented RFC TBD1, and everyone will know exactly what algorithms
are guaranteed to be in the implementations in question.

> The doc also explicitly states that this is not an effort to put
> value judgements on cryptographic algorithms, only which ones should
> be implemented to claim conformance.

And that conformance, of course, would be _with this document_, not
some other document.

> As for the final point, yes I agree that this must be maintained
> somehow or else it will become dated and stale - that's what is
> happening now.

That's actually why there is the rule that to add anything to the
contentious column, you have to replace the whole registry.  At the
moment of such replacement, the new RFC becomes wholly authoritative
for all those entries in the column, and this document becomes wholly
obsoleted.  That's also why it's important not to have an entry like
"OPTIONAL" in the registry for new algorithms: that approach is the
maintenance problem that Ed is mentioning.  So this little
bureaucratic trick is, as it happens, a way to enforce registry
maintenance: want a new "required" or "recommended" algorithm in the
sense that the registry has such a notation?  Then do your registry
maintenance and obsolete this document.  Otherwise, you don't get it.
Of course, the new algorithm can be "required" in order to conform to
the specification in the RFC that specifies that new algorithm: that's
trivially true.

I hope this makes clearer what the point of this effort is.  Ed, does
it to you?

A

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