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

From: <[email-masked]>
Date: Thu, 31 Jan 2013 14:00:31 +0100

Dear all,

As agreed in the last IETF meeting, I contacted Ted in Atlanta to check with him what is the recommended approach to encode multiple strings included in the same dhcp option. As a reminder, -05 assumes a space character is used as separator. Ted prefers the use of length-encoded string. I updated the text accordingly. I also updated the text to recall the consensus of the wg and explain why RFC1035-encoding was abandoned in favor of UTF-8 string encoding (the main reason is to not restrict it to DNS as other resolution libraries can be supported). The new revised text includes also changes to resolve the comments received in the WGLC. 

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. That's my personal opinion but as an editor of the document, I need more input for the WG on how to proceed given the comment raised from Ted: 

(1) maintain the current design which is aligned with the wg consensus

(2) roll-back to the RFC1035-encoding we had in -00, -01, 02-  and -03 rev of the draft and explain what to do for trailing dot when an IP address literal is included.

Thanks in advance. 

Cheers,
Med

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 Jan 2013 13:41:36 +0000

On Jan 31, 2013, at 8:00 AM, [email-masked] 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.

---

From: <[email-masked]>
Date: Thu, 31 Jan 2013 15:04:28 +0100

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 : [email-masked] [mailto:[email-masked]] De la 
>part de Ted Lemon
>Envoyé : jeudi 31 janvier 2013 14:42
>À : [email-masked]
>Objet : Re: [pcp] draft-ietf-pcp-dhcp
>Importance : Haute
>
>> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp
>

---

From: <[email-masked]>
Date: Thu, 31 Jan 2013 15:08:23 +0100

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

>De : BOUCADAIR Mohamed OLNC/OLN 
>Envoyé : jeudi 31 janvier 2013 15:04
>À : 'Ted Lemon'; [email-masked]
>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 
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 Jan 2013 14:48:30 +0000

On Jan 31, 2013, at 9:04 AM, [email-masked] wrote:
> 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 inhttp://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.

You discuss this, but nobody has yet presented a valid use case.   No valid use case is presented in your document, unless you agree that the use case is the split DNS use case.   In the discussion you cite, no motivating use case is given—it's just taken as read that this is going to be represented as a string.

My motivation here is to try to help you to get the document into a state where it will pass muster in the DHC working group.   At the moment, it will not pass muster.   So despite the discussion that you cite, I think we really need to reopen the issue of what the motivating use case is for this divergence from standard practice.

If there is a motivating use case, that's great—let's figure out how to address it.   But until such a use case has been explicitly stated (maybe it was stated in some discussion that you summarized, but left out of the summary?) I think the default should be to just use an IP address, and let the DHCP server do the name resolution.

I will point out that in the discussion you summarized, one motivation for not saying "FQDN" is that different name service infrastructures might be used.   If that is indeed a motivating use case, this argues _strongly_ for sending an IP address, and letting the DHCP server do the name service lookup.   Otherwise you are depending on all the nodes on your network to be able to support whatever name service infrastructure you intend to use; I don't think this is realistic.