Re: update of wcard submitted

[Edward Lewis <Ed.Lewis@neustar.biz>]

At 7:14 -0400 10/26/04, Alex Bligh wrote:

> You made it pretty clear in the draft you were NOT intending to update
> (read: 'obselete') RFC 1034. If you were trying to do this, I think
> the draft is too chatty etc. I proposed a pile of changes which I backed
> out when I realized what you were trying to do (or thought I had).

The history of the draft is about 18 months long.  Originally it was 
to figure out what was meant by RFC 1034 and how this impacted RFC 
2535.  Then it became an attempt to add strictness to the language 
without modifications (i.e., add MUST, SHOULD).

At one time there was a highly mathematical proof backing the 
assertions made about authenticated denial - contributed by Bob 
Halley.

At some point (IETF in SF, March 2003) the document became a WG item. 
At about this time we stripped out all references to DNSSEC and went 
back to just clarifying RFC 1034, with formal language.

The change to the CNAME processing in part 'c' came as a result of WG 
discussion in summer 2003 (surrounding the Vienna IETF).  When the 
document was individual, I was not about to make any non-wording 
changes.  But since the group asked for the change (and I was now an 
editor, not an author), the change is in.

From Summer 2003-Summer 2004 I was tied up with other duties.  In 
returning to the task at hand, during the recent discussions it has 
dawned on me to remove the MUST/SHOULD requirements and return to an 
engineering document (as opposed to a specification) - in the same 
frame of mind of RFC 1034/RFC 1035.  I was convinced of this by the 
comments from Robert Elz - pointing out that adding strict rules at 
this point may introduce hidden problems with implementations that 
may have correctly interpreted passages in RFC 1034, albeit in 
original ways.

> What I *thought* you were trying to do was issue a clarifying document
> detailing how wildcards should work in RFC1034. It is not designed
> (as far as I can see) to be a change of protocol to 1034 (or only
> the minimum change necessary to disambiguate it). Therefore I see
> no reason which you shouldn't add DS etc. to the draft, and make
> it clear for DNSSECbis etc.

The WG ought to talk then about the impacts of NSEC and DS at a 
source of synthesis.  With the upcoming meeting, maybe that could be 
done in person as well as on the list.

> If you were trying to update RFC1034, I'd think differently (i.e.
> I'd drop the word update entirely and use the word "clarify").

Hmmm.  The only part(s) of the wcard draft that "overwrite" RFC 1034 
is the addition of "CNAME chasing" in part 'c' and the general 
discussion/terminology work.  Only the former has real impact on 
implementation, the latter is for the benefit of net bureaucrats.

I hate to haggle over document politics, its like teaching 
implementers to sing.   It doesn't work and it annoys the 
implementers.  (;))  I'd just say that this document clarifies and 
updates 1034 - clarifies wording and updates one step in the 
algorithm, in the vein of the DNAME standard.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar

"Now under neu management"

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