"zone" is not a DNS name semantic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]