Subject: Re: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07

From: Samuel Weiler <[email-masked]>
Date: Wed, 15 Jun 2005 11:12:21 -0400 (EDT)

I'm glad I finally overcame my apprehensions about tackling this
document.

This doc is important, and I have very few issues with its technical
content, but I think it needs some better intro/summary text in order
to be read by the people who need it and perhaps a more uniform
discussion of what does and doesn't work in order to be more useful
for reference.  In particular, the first couple of pages need a
summary of the main things we expect implementers to miss, and we need
a roadmap to the doc.  That roadmap might suggest reading sections 3
and 4 first, then going back to the painful details in section 2.

To me, the most useful parts were 1.3, 2.2.1, and section 4.  Section
3 was a mixed bag.  I'd really like to see 3 and 4 tightened up, and
the items in 4 made more uniform and unambiguous.  You may even want
to reorder the doc, pulling the above-listed sections higher up and
pushing details down.

Here are some specific suggestions, starting from the back of the doc
(since I found it to be the most valuable).  Minor textual stuff has
been sent to Ed privately.  I do think these issues are worth delaying
the doc for.  I'm also worried that we haven't given enough
consideration to sections 4.6 and 4.7 (wildcard DS and NSEC RRs).

4.3 (CNAME)

Go ahead and put details here -- make all of these subparts of 4 tell
the reader the same things: whether it makes sense to publish such
RR's, whether they cause synthesis, and whether something weird
happens.  Go ahead and say them here, even if another section goes
into greater detail.

-----------

4.4  (DNAME)

Although verbose, this section is extremely clear -- it says what not
to do, tells you why, and keeps repeating the mantra that this idea is
stupid.  I really like it.

----

4.5  (SRV)

This is not clear to me.  Can we just say "this SRV record, since ...,
does not cause anything to be synthesized"?  Again, say "you can
publish it, but it won't do what you're thinking".  Possibly write
about what would happen to *_tcp_.example., which might actually be
useful.

----

4.6  (DS)

Meaningless and harmless, yes, but does it synthesize things?
Generally, I would think so.  But it's worth pointing out that a DS
should normally only appear at a parent side zone cut, and refer back
to the NS discussion.

-------

4.7  (NSEC)

This is more the kind of description I was looking for, but I'm not
sure it's correct.  Does "query exactly matches the record" mean that
QTYPE matches?  If so, say that.

And I'm not sure about the non-dangerous bit, either.  This needs a
little more thought.

-----

4.9  (empty non-terminals)

Add an example?  I don't follow this on a first read.

---------------

3.3.3

I got lost here, too -- I really want (I know I'm dreaming) something
as simple as "wildcard CNAMEs work".  Sadly, even 4.3 doesn't just
come out and say something brief and understandable.  I want something
brief and understandable.  For instance, for SOA's "yes, you can have
a wildcard domain name owning an SOA, but it can't be used as a source
of synthesis (or, even better, it doesn't lead to synthesis)"

-------

3.3.1

I didn't follow this section on this reading (much like 1.2) -- maybe
I'll be able to say more next time.  In general, though, Section 3
needs to do the same thing I'm suggesting for section 4 and the doc
as a whole -- it needs an intro/summary in very plain language.
Precise is good, too, but add a summary in plainer language.

------

Section 2.3

I'm wondering if there should be other cases included here, too.
(Dynamic update messages, etc.)

-----

Section 2.1.3

  "A wild card domain name can have subdomains."  this is also unclear
to the casual reader -- can you have a zone cut at a wildcard label or
not?  Clarify here, referring to the relevant section (4.2) later.

------

Section 1.2 is where I started getting lost in the details.  I suggest
moving it somewhere else or even removing it.  If it moves to section
2, add a warning at the end of section 1 and tell folks about the good
things come in the later sections.  In any case, move it below the
definition of the #-convention.

Speaking of the #-convention, I think it's ugly.  Perhaps ask the RFC
Editor now if they have a preference for what to use?

----

Section 1

As before, can we put a few gotchas here and some other reasons to
read the whole thing?  Maybe pulling the list from 1.3 higher up and
adding a couple of examples?

--
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: Wed, 15 Jun 2005 11:52:09 -0400

>I'm glad I finally overcame my apprehensions about tackling this

I wish I could overcome my apprehensions about the document as well.

>and 4 first, then going back to the painful details in section 2.

I find it difficult to provide "a summary of" what "we expect 
implementers to miss" especially as this is a supplemental document 
and not introducing a new idea.

>to reorder the doc, pulling the above-listed sections higher up and

1.3 is a roadmap, 2.2.1 are examples, and I consider (as editor) 
section 4 to be the least important part of the document.  The 
document is about the commentary on RFC 1034 - in the spirit of 
clarifying it - so section 3 is the heart of the effort.  Section 4 
is "how the rubber meets the road" so to speak.

>consideration to sections 4.6 and 4.7 (wildcard DS and NSEC RRs).

Now's the time to consider them (DS and NSEC).

Keep in mind that this is not meant to be a tutorial on wild cards 
for the benefit of implementers nor for the benefit of operators. 
The goal of the document is to fill in gaps in the description of RFC 
1034.  The goal of IETF documents is to be clear enough that diverse 
sets of readers can arrive at interoperable understandings. 
Interoperable understandings does not mean "do it the same way."

This document has already been in the making for sometime.  Please 
make comments now that are complete.  I want to move on from editing 
this, there are other things to do.  There's something to be said for 
"if it were really important, it would have come up in time."

I'm not going to address the remainder of the comment.  I invite 
other members of the WG to do so - I'm just editing.

I will add this - the style of the document is to dive into details 
of the "science" and then back out to the impacts on records.  This 
is not the only style for a technical document.  If I were writing 
this as a "marketing the idea" I would put the features and 
conclusions first, followed by successive detail justifying the 
previous point.  But that isn't the purpose of the document, the 
purpose is to bolster RFC 1034.

As far as uneven detail, yes, the document has that, but this is not 
a standalone document.  The lack of clarity evident in the original 
varies, this document is filling in.   The document is not a great 
literary work - partly because it has taken so long to get to where 
it is.

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

If you knew what I was thinking, you'd understand what I was saying.