Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt

From: Mans Nilsson <[email-masked]>
Date: Sun, 1 Jun 2003 12:51:40 +0200

Subject: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Date: Thu, May 29, 2003 at 12:17:16PM -0700 Quoting Randy Bush ([email-masked]):
> this initiates a two week wg last call on
> 
>     draft-ietf-dnsext-dnssec-2535typecode-change-01.txt
> 
> and, should it be info or ps?  i suspect the latter as it modifies
> a ps document, but i could be wrong.

Good document. PS. 

Regards, 
-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

Are we live or on tape?

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 2 Jun 2003 09:52:15 +0200

> a ps document, but i could be wrong.

Let's get rolling baby...

Full Support, proposed std.

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Roy Arends <[email-masked]>
Date: Mon, 2 Jun 2003 10:56:41 +0200 (CEST)

> a ps document, but i could be wrong.

I do not disagree with the chosen path since I don't want more delays.
Though I still think this is radical, and not a "minor" update to the
protocol.

As for the spec, one minor, very minor suggestion:

    4. IANA Considerations

       This document updates the IANA registry for DNS Resource Record
       Types by assigning types 46, 47, and 48 to the DNSKEY, RRSIG, and
       NSEC RRs, respectively.

I'd like to see the type 48 as the DNSKEY type. The NSEC type code map
consists of octets, and bit48=1 introduces a new octet. If bit 48
corresponds to DNSKEY, and not NSEC, we save an octet during transport
when DNSKEY is not present. But this is a _very_ local optimization.

Roy

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 2 Jun 2003 23:11:53 +0200 (CEST)

> a ps document, but i could be wrong.

I support this document and I think it should be published as proposed
standard.

	jakob

---

From: Sam Weiler <[email-masked]>
Date: Mon, 9 Jun 2003 12:25:07 -0400 (EDT)

Should the type code roll exclude SIG(0), leaving type 24 for SIG(0)
use only?  The current draft implies that SIG(0) changes too, but I've
heard rumors of a desire to asign SIG(0) its own type code, and
leaving it type 24 might accomplish that.

Gating questions: are enough people using SIG(0) that breaking it
would set back the protocol?  Are there any technical issues with
leaving it as is (an unrolled type 24 SIG) but rolling SIG for
everything else?

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Mon, 9 Jun 2003 18:35:23 -0400 (EDT)

Another series of clarifications, this time re: the relationship of
this document to draft-ietf-dnsext-unknown-rrs-05.txt

Proposals:

1) Compression of domain names in RRSIGs and NSECs is prohibited.
(The same update the unknown-rrs is making.)

2) DNSSEC canonical form and ordering: do the embedded domain names in
NSECs and RRSIGs get downcased?  I propose that they do -- if you
understand DNSSEC, you can handle special processing for the new
types.

3) Equality comparison.  Here I'm not sure what to do.  It looks like
a case-sensitive comparison, as would be done for any unknown RR, is
appropriate, but I'd like more guidance.

-- Sam

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 09 Jun 2003 23:30:37 -0400

>leaving it type 24 might accomplish that.

I personally think this is a good thing, SIG(0) had almost nothing to do
with SIG(n) than the record format. Separating them is IMHO a good thing.
If you change your draft to leave SIG(0) at 24 then there is no need for
the other draft.

>leaving it as is (an unrolled type 24 SIG) but rolling SIG for

my guess is that right now SIG(0) is in more common use than DNSSEC :-)
and there is no reason to break something that works.

         Olafur

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 09 Jun 2003 23:25:46 -0400

>(The same update the unknown-rrs is making.)
YES, YES, YES (did I mention that I hate RFC1035 name compression).

>understand DNSSEC, you can handle special processing for the new

No, they should NOT get down cased, the ONLY reason for DNSSEC down casing,
is the fact that name compression looses case.
This goes into the category, no-new-special cases.
For existing code this change causes little bit more changes in code
than just copy the old code. For new code this simplifies things a lot.

>appropriate, but I'd like more guidance.

See above, name compression is the reason for all these special cases.
NSEC is a machine generated singleton so there is only one choice for
order.
RRSIG is machine generated and as a RRSIG is never[*] calculated over
it order does not really matter, in any case given that the
signers name starts in octet 18 is quite unlikely that the signers
name is a tie breaker, and in any case the singers name should be the
same in all the RRSIG in a set.

[*] SIG(0) and TSIG are an exception, but in both cases the
signature is over a message on the wire, and the order in
each RRset does not matter.

         Olafur