Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (d

I'm not sure why this discussion has broken out on 
ietf(_at_)ietf(_dot_)org(_dot_)

Is it not better for iesg@ and dhcwg(_at_)?

On Wed, Sep 27, 2006 at 08:41:27AM -0700, Dave Crocker wrote:
> as John noted, the term "item" is not defined, so we don't know how many 
> labels (dns fields) are permitted.  This certainly encourages the 
> confusion between TLD and "organization base".
It's hard to disagree with the term 'item' being more vague than is
ideal.  To be clearest it should probaly say "having exactly one root
label (one domain name)" or similar.


I am, however, a little skeptical at how useful it is going to be
to define the term 'domain name suffix'.  I suspect the author of
this draft started by calling them 'zone suffixes' and was asked by
DNS people to switch to 'domain name' instead of 'zone' because
the principle concept of a 'zone name' is different from a 'domain'
(although they overlap and are sometimes equal).

That's judging by the history of edits of this document and others
it at one time referenced (which looks to be a bid to place the
suffix in RS/RA, calling it a 'zone suffix' at that time).


I think operators know what this term means intuitively.  We can
define what it means all we want, but they already know and don't
care what we think it means.  So it seems like a lot of work with
very little payout and a high degree of probability it will turn
into a windmill designed for tilting at.

Once standing upon that ground, one questions why there would be
any wonderment about the meaning of the word 'item' in this context,
where the term 'domain name suffix' is already well understood.


> I'm also a tad uncomfortable with the levels of indirection in the cited 
> reference.  The 3315 section really points to a section in 1035, modulo 
> prohibiting compressed form.  The cited section in 1035 defines a basic 
> syntax but then relies on a different section in 1035.  This all seems 
> likely to invite different interpretations.
Quite the opposite.  DHCP server software commonly refers to shared
code to process DHCP option contents.

So citing this section of RFC3315 is telling an implementor to
reuse that code.

Literally, when I read an option document for DHCPv6 that cites
this section of 3315, all I have to do is turn that into:

        { "option-name", "D", &dhcpv6_universe, CODE_NUM, 1 },

I don't even need to look up that section of 3315 nor the 1035
document.  This is just a "standard DHCPv6 domain name" format.


Note that if we take this stance, that every draft must redefine
the meaning or cite some new work that does so, then we should have
done that in RFC3319, RFC3646, RFC3898, and RFC4280.  Possibly the
DHCPv6 FQDN draft (still waiting for RFC assignment) as well, I can't
remember.

All of these used this method to define options of this format, to my
recent memory at least.  It is common DHC WG guidance to authors to
cite 3315 rather than reinventing.

DHCPv4 has taught us that, while clarity is important and we strive
for it, consistency is more important of these two.

It is better that one implementation treat all similarly formatted
options the same (poor) way, than for any implementation to treat
some options differently from others.

The former is easy for implementations to construct workarounds -
in single, reused-code ways.  The latter is a nightmare construct
of matrixes of option codes and special-case code.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email 
training(_at_)isc(_dot_)org(_dot_)
-- 
David W. Hankins        "If you don't do it right the first time,
Software Engineer               you'll just have to do it again."
Internet Systems Consortium, Inc.       -- Jack T. Hankins

pgpfDnfm3L5Jm.pgp
Description: PGP signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf