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

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Ted Lemon
> Sent: Thursday, January 31, 2013 6:49 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [pcp] draft-ietf-pcp-dhcp
> 
> 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.

Above I believe you're referring to draft-boucadair-dhc-address-name-encoding-03.
A use case is presented in draft-ietf-pcp-dhcp-05 Appendix A.

Within the WG, we do care about what draft-ietf-pcp-dhcp ought to do,
think we're blocked any more general consensus regarding
draft-boucadair-dhc-address-name-encoding.

> 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

Noted above, in Appendix A in draft-ietf-pcp-dhcp.

> the default should be to just use an IP address, and let the DHCP server do
> the name resolution.

That's fully supported in the current draft-ietf-pcp-dhcp mechanism
(the IP address gets encoded as a string literal).   But regardless of the encoding
Mechanism, I do agree that it would be good to saying that the *default* should
be to use an IP address.

> 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.

There is no such dependency.   That's what the DHCP Class Id option (60)
is used for in general (i.e. to provide different answers to different classes
of client) and could be similarly used for this option in heterogeneous 
environments.   

http://www.windowsitpro.com/article/dhcp2/dhcp-user-class-and-vendor-class-options-7983
is an example of an article talking about this over 12 years ago.

I would agree though that the draft contains no such discussion and it ought to.

-Dave