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

[Ted Lemon <[e-mail]>]

On Jan 31, 2013, at 9:04 AM, [e-mail] 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.