Re: nsec++

[Josh Littlefield <joshl@cisco.com>]

Jakob Schlyter wrote:

> my initial version of the draft respecifying the rdata format for nsec has
> been submitted to the drafts editor and can also be found at the following
> address:
>
>   http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-00.txt
>
>
> please send comments to namedroppers,

I assume this will be folded into the dnssec-records draft, and this 
draft will die.  Assuming this is roughly to replace section 4 of that 
document, I think we've lost some good text about the composition of the 
bitmap(s).  From 4.1.2:

   Each bit in the Type Bit Map field corresponds to an RR type.  Bit 1
   corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),
   and so forth. If a bit is set to 1, it indicates that an RRset of
   that type is present for the NSEC RR's owner name. If a bit is set to
   0, it indicates that no RRset of that type present for the NSEC RR's
   owner name.

That is, you've added description of block numbering and bitmap length, 
but lost all description of bitmap construction, and substituted a 
reference to RFC2535.  Moreover, the notion of "window blocks" is never 
explicitly described as corresponding to the upper 8 bits of an RR typecode.

I'd recommend changing para. 2 of 2.1.2, as follows:

   The RR type space is split into 256 window blocks, each
   representing the low-order 8 bits of the 16-bit RR type space.
   Each block that has at least one active RR type is encoded using a
   single octet window number (from 0 to 255), a single octet bitmap
   length (from 1 to 32) indicating the number of octets used for the
   window block's bitmap, and up to 32 octets (256 bits) of bitmap.

   Blocks are present in the NSEC RR data in increasing numerical
   order.

      "|" denotes concatenation

      Type Bit Map(s) Field =
                   ( Window Block # | Bitmap Length | Bitmap ) +

   Each bitmap encodes the low-order 8 bits of RR types within the
   window block, in network bit order.  The first bit is bit 0.  For
   window block 0, bit 1 corresponds to RR type 1 (A), bit 2
   corresponds to RR type 2 (NS), and so forth.  For window block 1,
   bit 1 corresponds to RR type 257, bit 2 to RR type 258.  If a bit is
   set to 1, it indicates that an RRset of that type is present for the
   NSEC RR's owner name.  If a bit is set to 0, it indicates that no
   RRset of that type is present for the NSEC RR's owner name.

   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.

   Blocks with no types present MUST NOT be included.  Trailing zero
   octets in the bitmap MUST be omitted.  The length of each block's
   bitmap is determined by the type code with the largest numerical
   value, within that block, among the set of RR types present at the
   NSEC RR's owner name.  Trailing zero octets not specified MUST be
   interpretted as zero octets.

This paragraph:

   A zone MUST NOT generate an NSEC RR for any domain name that only
   holds glue records.

Doesn't seem to belong the section describing the type bitmap field.  It 
belongs in Section 2.  It is not related to "wire-format", but to when 
an NSEC RR should exist.

Additional comments:

   - If the TYPE# notation can be used for unknown RR types in a 
symbolic list of RR types, then this should be explicitly mentioned. 
Otherwise, the presense of one unknown type would force the entire set 
to be printed using decimal notation.

   - An example of the actual binary data (octet by octet) for an NSEC 
RR using at least two non-sequential "window blocks" would be useful.

--
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
joshl@cisco.com                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: same               Boxborough, MA  01719-2205


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