[pcp] OFFLINE RE: draft-ietf-pcp-dhcp

[<[e-mail]>]

Ted, 

I really appreciate your help. 

As an editor of the document, I cannot change the encoding on my own and roll back to rfc1035 encoding we had in earlier versions of the document. I hope this thread will stimulate discussion and see more inputs. 

In the lack of any additional argument from the wg, I will abandon the utf-8 string encoding. 

Cheers,
Med

>-----Message d'origine-----
>De : BOUCADAIR Mohamed OLNC/OLN 
>Envoyé : jeudi 31 janvier 2013 15:04
>À : 'Ted Lemon'; [e-mail]
>Objet : RE: draft-ietf-pcp-dhcp
>
>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-enc
>oding-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
>>