Re: nsec++

[Jakob Schlyter <jakob@rfc.se>]

On Wed, 3 Dec 2003, Peter Koch wrote:

> > i.e., one type of sequence OR another type of sequence. if it allowed
> > mixing, it would probably say:
> >
> > "The Type Bit Map field is represented as a sequence of RR type mnemonics
> > or unsigned decimal integers denoting the RR type codes."
>
> For the sake of consistency with RFC 3597 I'd use the TYPEnnn convention
> and don't see any reason not to allow "mixed" format.
>
> "The Type Bit Map field is represented as a sequence of RR type mnemonics.
>  When the mnemonic is not known, the TYPE representation as of section 5
>  of [RFC 3597] MUST be used, otherwise it MAY {SHOULD NOT} be used."

I agree, but do not think we need that last part. suggestion:

     The List of Type Bit Map(s) Field is represented as a sequence of
     RR type mnemonics.  When the mnemonic is not known, the TYPE
     representation as described in RFC 3597 (section 5) MUST be used.


> 2.0
>      The NSEC RR is class independent.
>
>    -> The NSEC RR RDATA format is class independent and defined for all
>       classes.
>      {The RR or the contents of the RR really is class dependent}

updated.


> 2.1.1
>
>    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.
>
> Isn't this already covered by the reference to canonical sort order?
> Anyway, owner names or RRSets are not "authoritative for" the zone
> but are "in" the zone (or not). Section 4 of AXFR clarify, which still hasn't
> made it to RFC, has some wording about this.
>
> If a discussion is appropriate here, the "empty non-leaf node" problem
> could be solved, too. (short: NSEC may point to siblings, children or
> parents, but not to nephews).

as this text was copied from draft-ietf-dnsext-dnssec-records-05.txt, I'd
like comments on this from the editors of that draft before changing
anything.


> 2.1.2
>
>    Bits representing pseudo-RR types MUST be set to 0, since they do not
>    appear in zone data.  If encountered, they must be ignored upon
>    reading.
>
> The term "pseudo-RR" needs a definition. Again stealing from 3597 I'd say:
>
>    Bits representing Meta-TYPEs or QTYPEs as specified in [RFC 2929]
>    (section 3.1) or within the range reserved for assignment only to
>    QTYPEs and Meta-TYPEs MUST be set to 0 ...
>
> This may also change the maximum length calculation a bit (although 2929
> doesn't explicitly say that the TYPE reservation is valid for classes
> other than IN), which could be provided in an appendix.

new text included.


	jakob

--
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/>