Subject: editorial comments on draft-iab-dns-choices-02.txt

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jun 2005 15:19:00 -0400 (EDT)

Since these are mostly comments on the text of the doc, not the idea
it's pushing, I'm starting yet another thread.

Overview:

I agree with this document's recommendation, but, as is evident from
the discussion on this list, it needs to be rewritten so as to be more
compelling.

Both for that reason and to make it easier to read, I'd like to see
this document tightened up substantially, perhaps by adding more
structure to the summary of choices.  A grid cross-referencing
techniques to known benefits/problems might be particularly handy.  It
could also use some more compelling text on how easy it is to get
typecodes (or how easy it should be, given that no one has tested the
'specification required' assignments).

Specific comments (written before the above summary, so they may be
redundant):

Section 1, paragraph 5:

I'm finding this paragraph confusing, particularly:

   "...an analysis should be made as to
   whether having (for example) A record and SSH key information in
   different zones is a problem, and if it is, whether the owner for
   the records by design must be the same for both records."

I tend to read "owner" as "owner name", and having the same "owner
name" in two zones is inviting trouble (see RFC3658 and the
discussions that led to it).  Perhaps you meant something else.

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

Section 2

Citing 2929 for the query packet format just seems wrong.  Yes, it's
in 2929, but 2929 is otherwise pretty irrelevant.  How about dropping
the 2929 reference?

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

Section 3.1, last paragraph

Rewrite for grammar.  You might also want to summarize, with one
sentence in this last paragraph, why subtyping is bad -- make it
easier for someone skimming the doc to at least extract a clear
disrecommendation.

-----------

Section 3.2

The section (and maybe the one before) would improve with a clearer
structure -- tell the reader what you're going to tell them: "Another
inferior way to store new data...."

Move the mention of wildcard-clarify up to just after "...leftmost
token in the domain name." and tell folks why wildcards may surprise
them:

The below "this implies" confuses me:

   .... This RR type can either be a record type
   that can store arbitrary data or a new RR type.  This implies that
   some other selection mechanism has to be applied as well, such as
   ability to distinguish between the records in an RR set given they
   have the same RR type (see also draft-ietf-dnsext-wcard-clarify
   [wcardclarify] regarding use of wildcards and DNS).

You first mention a choice (generic RR or new RR) and then say this
implies a selection mechanism -- does a new RR type imply a selection
mechanism?  And to the extent you're talking about selection, how
about a reference to the previous section?

The last bit of this section, re: things being in different zones, may
confuse readers.  Consider including examples or at least "it's
possible for the prefixed name to be a delegation point, which would
put the special RR (or generic RR) in the child zone"

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

Section 3.3

Again, tell the reader clearly, up front and at the end, that this
method is inferior.

Again, consider a cite in the 2nd paragraph to 3.1

The last paragraph doesn't tell me what the IAB thinks of 2163.  It's
an example, but is it "this is okay"?  Maybe move this up into the
description as an example (of the bad thing), and then add a read
closing paragraph briefly warning people off of this method.

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

Section 3.4

Again, tell the reader clearly, up front and at the end, that this
method is inferior.

Again, consider a cite in the last paragraph to 3.1

Also add that resolvers would need hints to find the new class, making
it not globally accessible.

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

Section 3.5

This section doesn't parallel the others in Section 3, which disturbs
me as a reader.  Either have the others include this sort of breakdown
(who has to grok what) or restructure this one.

Again, there's little intro or conclusion in this section.  Make it
easier to skim, please.

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

Section 4

   "Using one of the naming modifications discussed in Section 3.2 and
   Section 3.3 would address the subtyping problem,..."

Maybe I misunderstood what 3.2 and 3.3 were saying when they talked
about another selection mechanism being needed.  This sounds like an
internal inconsistency, whether it is or not.

This section is amazingly long -- I suspect it could be tightened up
pretty easily.

In the paragraph mentioning 2929, consider telling folks why this
should make them happy in a little more detail: "getting a new type
code assignment does not require the delay of RFC publication -- 2929
set aside part of the type code space as "Specification Required"",
and consider repeating and citing the current definition of
"specification required".

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

Section 5

I find having two "conclusion" sections confusing and distracting --
rename Section 4, please.

-- Sam

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