[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nsec++
> 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."
Other comments:
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}
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).
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.
-Peter
--
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/>
- Follow-Ups:
- Re: nsec++
- From: Jakob Schlyter <jakob@rfc.se>
- Re: nsec++
- From: gson@nominum.com (Andreas Gustafsson)