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

[<[e-mail]>]

Hi Ted,

Thank you Ted for detailing your concerns. This is the purpose of this thread and this is why I cced you. 

Mandating the server to resolve the name and return an IP-Address is a deployment option but this is not a valid option for some providers. I already discussed this in http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-03. We had a long discussion in dhc mailing list, no need to replay that discussion here.

Instead of opening the endless discussion IP address vs. FQDN, I really hope to scope this discussion to the encoding options of a name: the working achieved a consensus to encode a name as a string and not over specify the option to be DNS-specific (see http://www.ietf.org/mail-archive/web/pcp/current/msg01776.html).

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la 
>part de Ted Lemon
>Envoyé : jeudi 31 janvier 2013 14:42
>À : [e-mail]
>Objet : Re: [pcp] draft-ietf-pcp-dhcp
>Importance : Haute
>
>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.
>
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp
>