Subject: [dnsext] draft-ietf-dnsext-dnssec-alg-allocation-02 downrefs

From: Alfred Hönes <[email-masked]>
Date: Wed, 27 Jan 2010 12:07:44 +0100 (MEZ)

Revisiting more closely the newly updated I-D,
    draft-ietf-dnsext-dnssec-alg-allocation-02
and the current state of the DNSSEC IANA registry,
I found a few non-(meta-)technical issues overlooked
in the past, where discussion focussed on the intended
policy change and its description.

In order to avoid delays later in the process, it might be
desirable to address the details given below in item (1)
and (2) now; item (3) recommends supplementary cleanup
operations for the IANA registry, based on item (2).

(1)  Copyright Notice

The current draft uses the pre-RFC5378 IPR clause.
That will certainly be challenged by the RFC Editor (which is
obliged to do so).  Since I see no reason to use that clause
(the entire draft is new), I suggest to drop the last paragraph
of the Copyright Notice now, in order to ensure a more smooth
progressing on the document later in the process.

(2)  Front matter, Normative Downrefs, etc.

The draft lists [RFC2535] and [RFC3755] as Normative Refs.
Both RFCs have been obsoleted by RFC 4033..4035.

Therefore, neither RFC 2535 nor RFC 3755 need to be formally
"Updated" by the draft -- they already are "Obsoleted".

Also, the Introduction of the draft could be understood
as if RFC 2535 (and maybe RFC 3755) still were the 'home'
of the IANA "DNS Security Algorithm Numbers" registry.

However, notwithstanding the wishy-washy IANA Considerations
(plus Appendix A) of RFC 4034, this registry has essentially
been re-parented to RFC 4034 by IANA.

The only place where the draft makes reference to [RFC2535] and
[RFC3755] is the Introduction.  This also indicates that these
references should be listed as Informative.
Furthermore, the text in the Introduction should be wordsmithed
a bit to better reflect the temporal relationship and the
current 'ownership' of the registry

Proposed changes:

a)  Section 1 -- Introduction

The draft says (full text in Section 1):

   [RFC2535] specifies that that IANA registry for DNS Security
   Algorithm Numbers be updated by IETF Standards Action only, with the
   exception of two values 253 and 254.  In essence, this means that for
   an algorithm to get its own entry in the registry, the algorithm must
   be defined in an RFC on the Standards Track as defined in [RFC2026].
   The requirement from RFC 2535 is repeated in [RFC3755] and [RFC4034].

   RFC 2535 allows algorithms that are not on the Standards Track to use
   private values 253 and 254 in signatures.  In each case, an
   unregistered private name must be included with each use of the
   algorithm in order to differentiate different algorithms that use the
   value.

I propose the following revised version (changes tagged):

                     v
|  [RFC2535] specified that that IANA registry for DNS Security
   Algorithm Numbers be updated by IETF Standards Action only, with the
   exception of two values 253 and 254.  In essence, this means that for
   an algorithm to get its own entry in the registry, the algorithm must
   be defined in an RFC on the Standards Track as defined in [RFC2026].
|  The requirement from RFC 2535 is repeated in [RFC3755] and then in
|  [RFC4034], the current owner of the registry.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^              ^^^^^^^^
       vvvv
|  RFC 4034 allows algorithms that are not on the Standards Track to use
   private values 253 and 254 in signatures.  In each case, an
   unregistered private name must be included with each use of the
   algorithm in order to differentiate different algorithms that use the
   value.

b)  Section 6 -- References

Demote entries [RFC2535] and [RFC3755] from Normative to Informative.

(3)  Supplementary IANA Considerations (Section 4)

Maybe the IANA 'sanitizing' actions described below can be achieved
via interaction of the chairs with IANA without changes of the draft.

a)
IANA still lists "[RFC3755]" as a second parent of the registry.

In order to avoid potential confusion on the satus of obsoleted RFCs,
I suggest that the draft advises IANA to drop that reference in the
registry heading (thus only listing "[RFC4034]" there).

b) Refs for Algo Numbers 253 and 254

IMO, the normative statement currently in force on these
'Private algorithms' code points is in Appendix A.1.1 of RFC 4034.
However, IANA still lists  "RFC3755][RFC2535]"  as the normative
references for these code points.

I suggest that IANA should be advised to either add [RFC4034]
to these references, or -- much better IMO -- replace these
references by "[RFC4034]" (doing so would remove the last
remaining refs to RFC 2535 from the IANA registry)..

In case a) and b) cannot be achieved without a document, here is
suggested text to be appended to Section 4):

|  IANA is asked to no longer indicate [RFC3755] as one of the
|  owners of the registry; [RFC4034] is the sole current owner.
|  Also, [RFC4034] should be listed as the Reference for Algorithm
|  Numbers 253 and 254 -- the precise current specification of these
|  code points can be found in Appendix A.1.1 of [RFC 4034].

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| 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]                     |
+------------------------+--------------------------------------------+

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Jan 2010 08:13:34 -0800

>progressing on the document later in the process.

I am leaving this as-is until after IESG evaluation because the headers and boilerplates keep changing. For the RFC, I'm happy to use whatever is current then.

>"Updated" by the draft -- they already are "Obsoleted".

That is irrelevant: you can update an obsoleted RFC if need be. In this case, those two RFCs are still listed in the IANA registry.

>of the IANA "DNS Security Algorithm Numbers" registry.

That's how IANA lists them, yes.

>been re-parented to RFC 4034 by IANA.

You may find it wishy-washy; I don't want this draft blocked by such discussion.

>references should be listed as Informative.

As long as they are normative in the IANA registry that is being updated, the are normative.

>current 'ownership' of the registry

If others agree during IETF Last Call that this is worthwhile, I'm happy to do so. Otherwise, I prefer to have the document move forwards as the WG agreed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 27 Jan 2010 18:31:06 +0100 (MEZ)

Paul,
thanks for your quick respons.

Paul Hoffman wrote:

> At 12:07 PM +0100 1/27/10, Alfred Hönes wrote:
> I am leaving this as-is until after IESG evaluation because the
> headers and boilerplates keep changing. For the RFC, I'm happy
> to use whatever is current then.

I thought it'd be only a matter of a PI parameter in the xml
(ipr="full5378", currently)   :-)
I also already have seen anecdotal evidence of the IESG challenging
the pre-5378 clause, but I do not insist on this change now!

> That is irrelevant: you can update an obsoleted RFC if need be.

So is there 'need' ?
Does anybody still need the bulk of RFC 2535 ?
The only potentially interesting thing in RFC 2535 is SIG(0),
but that's out of scope of this draft.
My personal preference always has been to avoid potential
confusion and to not draw people's attention to obsoleted
documents they better should not read and implement now.

> In this case, those two RFCs are still listed in the IANA registry.
>

AFAICS, RFC 2535 is no more listed as the "owner" of the registry,
since quite a while.  As I had pointed out, it is still listed as a
ref. for algorithm numbers 253 and 254 (only).

> You may find it wishy-washy;

You might prefer "unusual".  Never mind!

Explanation:
  The RFC 4034 IANA Considerations essentially describe the state
  of the registry _before_ the publication of that RFC.
  The requested changes are not made very explicit, but essentially
  all covered, by Appendix A.
  That does not correspond to the RFC 5226 expectations (I purposely
  avoid "requirements"), and those of its predecessor in force at the
  time of publication of the DNSSECbis documents.

> I don't want this draft blocked by such discussion.

I don't want to see it blocked either.
But I don't see any need or reason for such discussion.  As stated
once more above, IANA already lists RFC 4034 as a parent of the
registry.  My remark was a statement of fact, not a change request.

> updated, the are normative.

So at least RFC 2535 isn't any more.  :-)

IMHO, there's no need to "implement or understand" RFC 2535 and
RFC 3755 in order to "implement" this document.  RFC 4034 suffices.
So the water mark for Normative is clearly missed.

I have been tought by one AD recently that "normative in an IANA
registry" is no reason to treat the ref. as normative for a document
that changes the policy of suche registry or adds such registry
entries.  However, opinions vary, admittedly.

Maybe the IESG can (and most likely, will) contribute DISCUSSes
to this topic.   :-(

> If others agree during IETF Last Call that this is worthwhile,
> I'm happy to do so. Otherwise, I prefer to have the document
> move forwards as the WG agreed.

I do not oppose to move on now and consider these changes later,
e.g. after IETF LC, or when the IESG comes up with similar ideas.

My basic idea was that doing that _now_ might make the overall
process more straight and smooth, and faster.

Thus, I leave it to the WG and the chairs to decide which way
is more likely to save efforts in the longer term.

> --VPN Consortium

Kind regards,
  Alfred.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Jan 2010 10:52:50 -0800

>the pre-5378 clause, but I do not insist on this change now!

So, if you know that the current tools don't support this change, why are you asking for it in this WG?

>> That is irrelevant: you can update an obsoleted RFC if need be.

No, but it is accurate to do so.

>documents they better should not read and implement now.

That makes sense, but so does updating documents whose policies are being changed.

>ref. for algorithm numbers 253 and 254 (only).

And understanding those two are *very important* to this document.

>registry.  My remark was a statement of fact, not a change request.

My apologies: it sounded like a change request.

>So the water mark for Normative is clearly missed.

That's one watermark. Another is that if a document is being updated, it is normative.

>entries.  However, opinions vary, admittedly.

Yes.

>Maybe the IESG can (and most likely, will) contribute DISCUSSes

No.

>e.g. after IETF LC, or when the IESG comes up with similar ideas.

During IETF LC is fine, and it lets the IESG weigh in on some of the assumptions you make.

--Paul Hoffman, Director
--VPN Consortium