Re: [pcp] draft-ietf-pcp-dhcp

[Ted Lemon <[e-mail]>]

On Jan 31, 2013, at 8:00 AM, [e-mail] wrote:
> Even if -06 is ready for submission, I preferred to not submit it before checking with the WG how to resolve an issue raised by Ted. Ted (as a chair of dhc) thinks the use of UTF-8 string encoding is a bad design because it is difficult to validate the option. I already answered to that objection as DNS itself does not put any restriction on labels except a label must not be more than 63 characters.

This completely misrepresents the concern I expressed.   First of all, DNS _wire format_ allows any value in any field, but DNS _representation format_ is not clearly defined anywhere, and there are complexities, particularly since you want to be able to parse both FQDNs and IP addresses out of the same string representation, and since you have to support internationalized domain names.

Of course, there are implementations of library routines that take a user-supplied string and parse an FQDN or IP address out of it—it's not rocket science.   But there is no clear specification; no BNF we can follow to determine which strings are valid and which aren't.   More to the point, though, this is not how other DHCP options with similar use cases have been done.   Inventing new formats to represent the same data complicates implementations, and we'd prefer to avoid it.   The DHC working group has a fairly clear consensus that there are preferred ways to do it, which we have attempted to communicate.   We asked Med to articulate a use case that motivates this particular solution over the preferred solutions, and he did not articulate an actual use case.

We also asked Med to explain why it was necessary to use an FQDN rather than having the DHCP server derive an IP address from an FQDN in its configuration, and the only answer I could get was that there might be some situation where there'd be a split DNS configuration, and the correct answer would be available to the DHCP client and not the DHCP server.   In general I'm a bit of a purist, and have trouble with the idea that an IETF protocol should bend over backwards to accommodate this use case.   I also wonder if the working group really considers this a serious use case.

In general, the way that DHCP handles this problem is that the DHCP server administrator configures an FQDN on the DHCP server.   When a request comes in, the DHCP server does a DNS lookup, resolving the FQDN  into one or more IP addresses.   These addresses are then sent to the client.   This relieves the client of the need to do the FQDN lookup itself, which is generally considered desirable since some consumers of DHCP service are fairly low-level devices, like boot proms, which don't have their own resolvers.   This solution addresses every use case Med presented except the split DNS use case.   In the split DNS use case, a wire-encoded FQDN is adequate; there is no need to invent a new encoding.

So I'd really appreciate it if the PCP working group would at least consider stopping trying to cram config file strings into DHCP packets, and follow the recommendations of the DHC working group as to how to represent addresses.

I think that's the place to start—if somebody has a strong requirement that is not satisfied by the usual practice, that requirement should be stated explicitly.   It should be the case that current practice does not satisfy that requirement; not merely that there is a personal preference for going against current practice.