ietf
[Top] [All Lists]

Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)

2006-09-27 14:38:05



On Wednesday, September 27, 2006 08:49:19 AM -0400 John C Klensin 
<john-ietf(_at_)jck(_dot_)com> wrote:

Sure. But that isn't what the term means in common (non-IETF)
practice and the document is quite specific that the return
value contain exactly one label (er, "item") with no provision
at all for two.

Except it doesn't say "label"; that's your interpretation.  I grant it is 
an entirely reasonable interpretation, and in fact the alternate 
interpretation that was suggested is not one that would have occurred to me.

        Well for this option to encode a TLD it would have to
        encode 2 label.

        As for "domain name suffix" while I can't remember seeing
        a formal definition.  In the DNS world it is any domain
        name appended to a unqualified or partially qualified domain
        name to create a fully qualified domain name.

        Now the DNS RFC's always talk about both wire and presentation
        formats.  The option itself is a domain name in uncompress
        DNS wire format.
 
IMO, this document should be rejected, and should stay rejected
until the authors clean up their terminology, explain how the
capability is intended to be used, and then explain why the
Internet needs it.   Once it reaches that point, a Last Call
review will make sense

I agree.  As it stands, this document refers to DNS concepts using terms 
other than those normally used, and in particular the term "domain suffix", 
while not having any formal meaning I am aware of, has at least one 
commonly-used meaning which is different than that apparently intended by 
the authors.

In short, I believe this document currently lacks the precision appropriate 
for an IETF specification.


, but I would suggest that the proposal
should still be rejected unless the return value can be an
all-but-hostname FQDN, not a single-label "suffix".

I agree with this also, given that the latter seems fairly useless. 
Fortunately, I suspect the document authors also agree, and are simply 
using poor terminology to say what they mean.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email training(_at_)isc(_dot_)org(_dot_)
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews(_at_)isc(_dot_)org

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

<Prev in Thread] Current Thread [Next in Thread>