Subject: update of wcard submitted

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Oct 2004 10:50:48 -0400

I managed to get around to an update of the wcard draft.  I made 
updates based on notes from Alex and Robert.  I didn't make all the 
updates, nor did I manage time to even reread the whole thing myself.

In a few days, or perhaps at the meeting, I'll send in any 
substantive questions based on the comments received.  In general, 
the comments were about wording and not concepts as were any 
reactions I had.  Mostly, I wanted to keep the draft "chatty" because 
this is supposed to be a clarificiation and not a "dry" specification 
(countering some recommendations from Robert).

I still don't consider the draft well-written, nor set in type.

I guess I do have one more headache - whether or not to discuss DS 
and NSEC types at the parent.  I kind of have one foot into that rat 
hole when speaking about the NS types.  I'm not sure if I should pull 
my foot out or dive in with the second foot.  If we're mentioning 
DNAME, why not DS and NSEC?  OTOH, if this document sticks with 1034 
topics, mayne all of DNAME is dropped.

I suppose it's debate over whether this is an strict update of 1034 
or is an update on the concept of (1034:) wildcards.

BTW - As far as comments form Phill Halem-Baker, this draft is only a 
clarification of the documented status quo.  This document's 
expansion into other forms of synthesis is not appropriate - if the 
desire is there, then a new draft is needed that will update other 
documents.  This document can't endorse the new efforts, it can hint 
at requirements for them.  If it comes across as prohibiting them 
(e.g., the*.example. does not pattern match), that's because the 
current specs also "prohibit" the expansion - but don't take this as 
a "rejection with prejudice."  (Meaning - not allowed now, but 
proposals are welcome.)

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

"Now under neu management"

--
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: Edward Lewis <[email-masked]>
Date: Tue, 26 Oct 2004 07:56:33 -0400

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