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: [email-masked]
Date: Mon, 25 Oct 2004 20:39:17 +0000

doing a document recovery intervention and this came up.... :)

	Internet Experiment Note 116 -  Internet Name Server
	August 1979 - Jon Postel

	has an extensive treatment of wildcards.   If you wnat a copy
	I'll be happy to post it.  Granted, this predates the DNS...

--bill

---

From: Roy Badami <[email-masked]>
Date: Mon, 25 Oct 2004 22:02:03 +0100

bmanning> 	has an extensive treatment of wildcards.  If you wnat
    bmanning> a copy I'll be happy to post it.  Granted, this predates
    bmanning> the DNS...

Many IEN's (including this one) are available on RFC Editor's FTP
site:

ftp://ftp.rfc-editor.org/in-notes/ien/ien116.txt

	-roy

---

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Oct 2004 18:57:34 -0400

>	I'll be happy to post it.  Granted, this predates the DNS...

To quote a friend, Bill, "Don't *make* me hurt you!"

---

From: Alex Bligh <[email-masked]>
Date: Tue, 26 Oct 2004 12:14:06 +0100

Ed,

--On 25 October 2004 10:50 -0400 Edward Lewis <[email-masked]> wrote:

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

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).

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.

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").

Alex

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Oct 2004 07:56:33 -0400

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

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

>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

---

From: Robert Elz <[email-masked]>
Date: Tue, 26 Oct 2004 21:09:53 +0700

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

  | 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 haven't had a chance to read the new one yet (and am not currently
connected, so I can't even fetch it - didn't know it existed till I saw
this message) - but this I suspect means that we differ over what
"clarification" means.

I take it to indicate a tightly written doc which is very precise, and
makes absolutely clear any doubtful aspects of the specification being
clarified.

I would contrast that to an "explanation" which would be just fine as a
chatty doc - where the purpose is to explain why the world is the way it
is, so people understand the reasoning.

While the latter is a fine thing to have, it isn't what I think is really
needed here - that is, it isn't the crucial requirement.

  | I guess I do have one more headache - whether or not to discuss DS 
  | and NSEC types at the parent.

Is there anything about them, given their normal processing (that is,
as they are currently specified to be processed) that in any way differs
from, or complicates, the wildcard clarification?   I wouldn't have
expected so - sire they (well, DS particularly) are "different" when
it comes to normal DNS message processing, but I wouldn't have thought
that they'd affect the wildcard processing in any very peculiar way.

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

It needs to be a clarification of the DNS as it is defined.  But it is
just a clarification, not a re-specification of everything (it isn't DNS').

kre

ps: [email-masked] said:
   | Internet Experiment Note 116 -  Internet Name Server
   | 	August 1979 - Jon Postel
   | 	has an extensive treatment of wildcards. 

I don't have a copy of the IEN's on my laptop either, so I can't go read
that (again - I'm sure I have in the past) - but I'd use care making any
use or reference at all to pre-1034 DNS related stuff, other than perhaps
to explain the historical environment (which I don't think is appropriate
in a clarifications doc).   Even 882/883 are quite different than 1034/5
when it comes to wildcards - this is an area that was changed during DNS
development.