Subject: [dnsext] A contradiction in RFC 5155

From: "Roy Arends" <[email-masked]>
Date: Mon, 17 Nov 2008 16:57:47 -0600

Dear DNSEXT WG,

During an NSEC3 interoperability test we found a contradiction in RFC 
5155:

A NSEC3 record, that matches an Empty Non-Terminal, effectively has no 
type associated with it. This NSEC3 record has an empty type bit map. 
Section 3.2.1 contains the statement:

   Blocks with no types present MUST NOT be included.

However, the same section contains a regular expression:

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

The plus sign in the regular expression indicates that there is one or 
more of the preceding element. This means that there must be at least one 
window block. If this window block has no types, it contradicts with the 
first statement. Therefore, the correct text in RFC 5155 3.2.1 should be:

   Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*

I suggest we add this to dnssec-bis updates (
draft-ietf-dnsext-dnssec-bis-updates-07), and we get this one character 
error in RFC5155 ERRATA posted on the rfc-editors site. 

If the suggested change is not satisfactory, I want better text by 
November 26th. At that point I'll brief the RFC editor and ask the chairs 
and the dnssec-bis editors to add it to dnssec-bis updates.

With Kind Regards,

Roy Arends
Senior Researcher
Nominet UK

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Nov 2008 01:07:56 +0100

I support Roy's proposal.

[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Nov 2008 20:39:11 -0600

How about just submitting an errata to RFC 5155?

http://rfc-editor.org/how_to_report.html

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Mon, 17 Nov 2008 23:17:57 -0500

Roy is going to do that,
he is just asking for working group  to sign of the text of the errata.
To increase the chances that future implementors find this corrections the
WG chairs decided to both include the errata in the RFC-editors archive
and the living dnssec-bis-updates document.

         Olafur (for the chairs)

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Nov 2008 15:38:40 +1100

In message <[email-masked]>, Francis Dupont write
> [email-masked]
	I also concur with the fix.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 18 Nov 2008 15:22:48 -0200

> 	I also concur with the fix.

I also support Roy's proposal.

Fred

---

From: Edward Lewis <[email-masked]>
Date: Tue, 18 Nov 2008 11:36:59 -0600

>>How about just submitting an errata to RFC 5155?

As usual, I only read half of what Roy types so I 
missed the line about the "ERRATA."  I don't 
think adding the stuff to dnssecbis-updates is 
needed though. There are lots of errata levied on 
DNS documents already and we don't highlight them.

Other than that, the substance of Roy's change is fine, good, ack.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 18 Nov 2008 18:17:56 -0200

On Tue, Nov 18, 2008 at 11:36:59AM -0600, Edward Lewis wrote:
...
> DNS documents already and we don't highlight them.

... and read them too !

Fred

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Nov 2008 11:33:39 -0500 (EST)

[ Note: Post was moderated. ] 

This is something that should be found on the first implementation. How
is it that these kinds of bugs are just now being found?  This failure
represents a serious design flaw and evidences a lack of adequate
review, even within the definition of "Proposed Standard" status. From 
RFC 2026:

4.1.1  Proposed Standard

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.  However, the IESG may
   waive this requirement in order to allow a specification to advance
   to the Proposed Standard state when it is considered to be useful and
   necessary (and timely) even with known technical omissions.

Maybe the IESG should require more implementation and operational
experience with DNSSEC before going forward with poorly defined and
self-contradictory standards.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000