--On Wednesday, 27 September, 2006 09:52 -0700 "David W.
Hankins" <David_Hankins@xxxxxxx> wrote:
> I'm not sure why this discussion has broken out on
> ietf@xxxxxxxxx
> Is it not better for iesg@ and dhcwg@?
Because Last Call announcements invite such discussion. Some
people tend to go to ietf@xxxxxxxx with any Last Call comments.
Others of us tend to go to this list only when more general
principles are involved than the details of a particular
specification. This proposal seems to be (quite reasonably,
IMO) bringing out both groups, partially because of a feeling
that the DHC WG has failed in its review responsibility by
letting a specification with this many undefined terms and
concepts reach IETF Last Call.
> 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).
Any clear and precise definition would be satisfactory. I don't
believe that anyone would be quibbling on this list about
whether one style of definition was better than another if only
there were one that was unambiguous to all readers, regardless
of how much DNS and/or DHCP implementation experience they had.
> 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.
David, I've been pretty close to some operators. I've also been
very close to applications design and implementation, as has
Dave. Neither of us are sure what this is for, much less what
some of the words mean, which is pretty damning.
It the intention of the specification is that it cannot be read
except by those who are already experienced with DHCP options
and their implementation, that would probably be ok too. But
then it needs to say that and tell newcomers what to read.
Otherwise, you don't have a standard, just a memo to the
in-group.
> 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.
But it is not "well understood". In deference to Matt, I
wouldn't blame Verisign (and haven't), but there is definitely a
use in the domain name marketing community that is exclusively a
TLD and there is apparently a use --largely undocumented in the
IETF community as far as I know -- that is the "non-hostname"
part of the name. When there is ambiguity about what a name
means, especially if it is used for two different things, then
one either avoids the term or defines it locally to the
document. That isn't much to ask for, I think.
>> 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.
>...
Let's assume that we accept that much. We still have two
problems. The first is that of the "levels of indirection" to
which Dave and I have referred. It isn't a request to define
the label format from scratch in each document, as you seem to
imply. It is just a question as to whether referencing a
section of 3315 (without a section number) which references a
section of 1035, which sort of references another section of
1035 is the best way to do this. That is arguably a criticism
of 3315, not of this document, but there are two reasonable ways
to "fix" this and, . One is to just skip the reference to 3315
and go to 1035 on the theory that 3315 isn't adding value. The
other is that 3315 should have provided a crisp and compact
definition for use in DHCP and then noted, informatively, how it
is built on particular options from 1035.
The second is that, starting from my application bias, when I
look at a DHCP option, I'm not too concerned about the
relatively small number of people who implement DHCP servers.
I'm concerned about the somewhat larger number of people who
implement DHCP client software and, more important, the _much_
larger number of people who implement applications that retrieve
the values that DHCP returns and try to use them. Those folks
may (and often do) use only a single DHCP option. They need to
know exactly what it means, what the values are, and what it
returns. And what you, as a server implementer, already know
or can take advantage of is of absolutely no use to them.
That difference in perspective gets us onto one of the IETF's
slippery slopes which is important to understand but that still
doesn't impact this document. Suppose I'm implementing a DHCP
client for the hypothetical "OS Z" operating system. If, at the
request of an application, I request this particular option and
get an answer, nothing prevents me from defining my interface to
the application (an API or whatever) so that I get back a domain
name in "DHCP" format (lengths and labels) but hand the
application a dot-separated ASCII string. Then the client needs
to know about my API and not about the protocol. Still, we
know that (1) that doesn't happen very often, maybe not as often
as it should and (2) it makes it even more important that what
the DHCP client is going to get to the server be specified
without ambiguity.
> 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.
>...
Sure. But see above about clients and applications. Server
implementers are not the only users of this sort of
specification. I also agree with Dave's comment about the
difference between specification/standard and implementation and
note, in the DNS cases especially, how many problems have been
caused by "the implementation is the standard" assumptions.
> 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.
Not the point or the requirement. See above.
>...
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf