Protocol Action: 'DNSSEC NSEC RDATA Format' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Wed, 02 June 2004 04:44 UTC

Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24369 for <ietf-announce-archive@ietf.org>; Wed, 2 Jun 2004 00:44:27 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVNc4-0000F4-Fa for ietf-announce-archive@ietf.org; Wed, 02 Jun 2004 00:44:28 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVNZ6-0006fH-00 for ietf-announce-archive@ietf.org; Wed, 02 Jun 2004 00:41:24 -0400
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVNXY-00060X-00; Wed, 02 Jun 2004 00:39:48 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVN60-0003UL-0b; Wed, 02 Jun 2004 00:11:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVGD6-0007P6-Uk for ietf-announce@megatron.ietf.org; Tue, 01 Jun 2004 16:50:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23633 for <ietf-announce@ietf.org>; Tue, 1 Jun 2004 16:50:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVGD5-0004G6-Jk for ietf-announce@ietf.org; Tue, 01 Jun 2004 16:50:11 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVGCA-0003in-00 for ietf-announce@ietf.org; Tue, 01 Jun 2004 16:49:15 -0400
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVGAM-0002MS-00; Tue, 01 Jun 2004 16:47:22 -0400
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BVFun-0005rq-Dl; Tue, 01 Jun 2004 16:31:17 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Message-Id: <E1BVFun-0005rq-Dl@megatron.ietf.org>
Date: Tue, 01 Jun 2004 16:31:17 -0400
X-Mailman-Approved-At: Tue, 01 Jun 2004 18:05:15 -0400
Cc: dnsext mailing list <namedroppers@ops.ietf.org>, Internet Architecture Board <iab@iab.org>, dnsext chair <okolkman@ripe.net>, dnsext chair <ogud@ogud.com>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'DNSSEC NSEC RDATA Format' to Proposed Standard
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60

The IESG has approved the following document:

- 'DNSSEC NSEC RDATA Format '
   <draft-ietf-dnsext-nsec-rdata-06.txt> as a Proposed Standard

This document is the product of the DNS Extensions Working Group. 

The IESG contact persons are Thomas Narten and Margaret Wasserman.

Technical Summary

The NSEC RR is based on the NXT RR as described in RFC 2535, and is
similar except for the name and typecode. The RDATA format for the NXT
RR has the limitation in that the RDATA could only carry information
about the existence of the first 127 types. RFC 2535 did reserve a bit
to specify an extension mechanism, but the mechanism was never
actually defined.

In order to avoid the need to develop an extension mechanism into a
deployed base of DNSSEC aware servers and resolvers once the first 127
type codes are allocated, this document redefines the wire format of
the "Type Bit Map" field in the NSEC RDATA to cover the full RR type
space.  The new format of the type bitmap is easy to implement, can
cover the full range of type codes, is economical in the common case
and has a maximum encoding size of approximately 8.5 kilobytes.
Efficient searching of the type bitmap for presence of a type had a
lower priority.

Working Group Summary

The format was chosen from 6 different candidates that were presented
to the working group. There is consensus on the chosen representation.
 

Protocol Quality

There are 3 independent implementations of this format. One
implementation provides both a server and a client, 1 implementation
only a server and 1 implementation only a client. These interoperate.

This document has been reviewed for the IESG by Thomas Narten.


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce