David W. Hankins wrote:
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 zones are an administrative construct, not a user-visible naming
construct.
Stated differently:
Domain names are a registration space for globally unique names. The
DNS server network provides a query mechanism relating to those names.
Zones are relevant to the query network, not the registration service.
So, zones do not have semantic relevance to the user-level Domain Name
model.
Hence there is nothing in the DHCP option that necessarily pertains to a
zone boundary.
I think operators know what this term means intuitively. We can
The discussion on this list has made clear that there are a number of
entirely reasonable -- but quite different -- intuitive interpretations.
That the specification permits this ambiguity is a perfect
demonstration of its deficiency.
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.
Even with a good understanding of the term "suffix" the term "item"
remains ambiguous. I share John Klensin's concern about this.
So at base what we have is a specification that makes assumptions about
the interpretation of key terms. A specifications must not do that. It
must define them. Define = specify.
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.
>
Oh. So there is a specification for existing DHCP mechanism(s) that use
this construct? What part of DHCP is that? And why does the current
specification not provide that DHCP context? Absent that reference, how
can you know that the capability is already present in a DHCP server.
My concern is that you are confusing software implementation with
protocol specification, since they can be quite different.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf