Re: nsec++

[gson@nominum.com (Andreas Gustafsson)]

Some comments on draft-ietf-dnsext-nsec-rdata-00.txt:

> Blocks is presented in increasing numerical order.

Should be "The blocks are...".

> Owner names of RRsets not authoritative for the given zone (such as
> glue records) MUST NOT be listed in the Next Domain Name unless at
> least one authoritative RRset exists at the same owner name.
> [...]
> zone MUST NOT generate an NSEC RR for any domain name that only
> holds glue records.

These statements are outside the scope of the draft.  The restrictions
described here are not properties of the "DNSSEC NSEC RDATA Format"
but of the DNSSEC protocol; they should be (and presumably already
are) stated in the base DNSSEC protocol specification.

> The Type Bit Map field is represented either as a sequence of RR type
> mnemonics or as a sequence of unsigned decimal integers denoting the
> RR type codes.

I strongly suggest either allowing mixing of mnemonics and integers,
or dropping the integers completely in favor of the TYPE# notation.

The current requirement that the list has to be either all mnemonics
or all integers serves no clear purpose and makes things needlessly
hard on implementations.  Suppose you are printing an NSEC record and
have already printed a couple of mnemonics, and then you come across
an unknown RR type - what should you do, go back and change the
mnemonics you already printed to integers just to satisfy this
requirement?
-- 
Andreas Gustafsson, gson@nominum.com

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