Subject: [pcp] #58: DHCP option issues from Margaret Wasserman

From: "pcp issue tracker" <[email-masked]>
Date: Mon, 02 Apr 2012 19:55:11 -0000

#58: DHCP option issues from Margaret Wasserman

 This document _way_ oversteps what should be defined in a DHCP option,
 proscribing quite a bit of operational behaviour of the PCP server
 including:  how to handle multiple  PCP servers, how to handle
 retransmissions, etc.  More than half of the information in this document
 does not belong here.

 Also, there is a lengthy discussion in this document of whether to use IP
 Addresses or Names, and I don't understand any of that.  There are a
 number of DHCP options that contain server lists, and those servers can be
 represented by either IP addresses or names.  For an example of a good
 DHCP option definition along those lines, please see the NTP DHCP Option
 (RFC 5908).  IMO, it would be much better to produce a PCP Server DHCP
 Option based on the NTP DHCP Option than to do it as described in this
 document.

 Margaret

 ================================

 Detailed Comments:

 (1) The Abstract:  The text in the abstract does not match the document
 (addresses vs. names).

 To resolve this issue I would suggest:

 OLD:

 This document specifies DHCP (IPv4 and IPv6) options to configure hosts
 with Port Control Protocol (PCP) Server addresses.

 NEW:

 This document specifies DHCP (IPv4 and IPv6) options to configure hosts
 with Port Control Protocol (PCP) Server names.

 (2) Introduction:  This option does not provide anything about
 "reachability information", it provisions a list of PCP Servers on a host.
 The DHCP server won't know anything about whether those Servers are
 reachable at any given time, or from any given place on the network, so it
 can't convey that information.

 To resolve this issue I would suggest:

 OLD:

 This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options which
 can be used to provision PCP Server [I-D.ietf-pcp-base] reachability
 information; more precisely it defines DHCP options to convey a name (as
 per Section 3.1 of [RFC1035]) of PCP Server(s).

 NEW:

 This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options to
 provision a list of PCP Server [I-D.ietf-pcp-base] names.

 (3) Section 3: Configuration of a list of servrtd is quite common, and it
 does not require a lengthy rationale, nor is it valuable to invent a new
 way to to do it.  This section describes an operational model that is not
 pertinent to many uses of PCP, and I am concerned that by describing this
 model, we could give the impression that the IETF is condoning, or even
 encouraging, the type of "organization" described.  I am not sure why we
 would want to do that.  Also, since we are moving the DS-Lite stuff out of
 the Base Spec, discussing "the DS-Lite Use Case" for PCP as we do here
 would require a reference to the new spec, and I don't think one should be
 needed in a DHCP option that is useful for all use cases.

 To resolve this issue, I would suggest:

 Remove section 3.  Rework the option to accept a list of names or IP
 Addresses, like the NTP Server option (RFC 5908).

 (4) Section 4:  There are a number of problems with this section.

 (4a) It is possible to return more than one PCP Server name in the list,
 and it is possible that there will be more than one PCP controlled device
 on a hosts outbound path.  So, the first statement in this section is
 simplistic...  Is the applicability of this option constrained to cases
 were there is only one PCP-controlled device serving as a gateway to a
 leaf network?  If so, you should say that somewhere in here.  If not, I
 think you need to say something else.

 (4b) What is "any terminal belonging to the same realm"?  "Terminal" and
 "realm" aren't words that apply in a typical IP networking case, and it is
 unclear what is meant here.

 (4c) What is a CP Router?  Do you mean a customer-premise router?  If so,
 you need to expand the acronym the first time you use it...  Also,
 Customer Premise Equipment (CPE) is more commonly used in the IETF, I
 think.  If this option is used to configure a router, is it assumed that
 the router will pass this information on to its internal hosts?  Or that
 it will serve as a PCP proxy for them?

 (4d) "Customers" will experience "service troubles" and their "service(s)
 won't be delivered appropriately" is a bit obscure....

 I also wonder why this section exists in this document at all, since it
 seems more like general advice on how to deal with a situation where a PCP
 Server isn't co-resident with the device it controls than anything having
 to do with the DHCP option...  Also, it isn't really necessary to tell
 someone that if they misconfigure their hosts, they won't work.

 To address these four problems, I suggest that you remove section 4.

 (5) Section 5:  This section doesn't make sense to me, as written.  You
 have described two operational models, but IMO they muddle together the
 notion of receiving a list of PCP Servers (i.e. multiple names), and a
 list of IP addresses in a DNS response (i.e. multiple IP Addresses
 corresponding to the name).

 IMO, you need to make a decision here...    Do you want to treat each IP
 Address returned from name resolution as a separate PCP Server?  Or do you
 want to treat each PCP Server name provisioned by DHCP as a separate
 server.  It appears that you use the latter (one name, on server) in
 section 5.1 and the former (one address, one server) in section 5.2.  This
 doesn't make any sense to me.

 I *think* what you want to do is to allow multiple DHCP Server names to
 indicate multiple servers that should be used in parallel (to cover the
 case where a site is multi-homed), and that you want clients to use each
 set of IP addresses as alternate ways to reach each of those servers, but
 that is not what this section says.

 Also, why do you describe a PCP retransmission algorithm here in the DHCP
 spec?

 All you want to do in the DHCP spec is describe how a node gets its
 configuration information through DHCP.  You don't want to describe how
 PCP works.  The PCP base spec needs to describe how PCP works included
 what its expected configuration looks like, while remaining neutral on
 whether that configuration is obtained via manual configuration, DHC or
 other means.

 To address this issue:

 Construct a DHCP Option that can be used to indicate whether the PCP
 Servers in the PCP Server list should be tried in sequence if the prior
 servers are unavailable, or whether they should all be used in parallel.
 If a more complicated construct is needed, describe what it is, and I will
 help you understand how to represent that in a DHCP option.

 DO NOT descrive how the PCP Client will work in this option.  How does a
 PCP Client use multiple servers if they are configured statically?  Or if
 there are multiple default routers in the default router list.  All of
 this operational mode stuff belongs in the PCP base document, not in an
 DHCP option.

 (6) Section 6:

 (6a) The DS-Lite example isn't helpful here.

 (6b) Also, this option only allows you to configure one DNS name, which
 doesn't match all of section 5.

 (6c) This document should not tell you how to configure your DNS server.

 (6d) When you want to configure a server list, it is typical to include
 the server list in one option (as in NTP) not to send multiple options as
 seems to be described in this draft.

 (6e)  I don't even know what to say about the "local cache" of resolved
 addresses...  Include what TTL?  What cache?

 To address this issue I would suggest:

 Remove the DS-Lite example.

 Move to an option like the NTP DHCP Option in RFC 5908, perhaps with a
 flag to indicate whether the servers should be used as a redundancy list,
 or as a list of servers to be used in parallel (see my suggestion for
 section 5.

 Remove the mention of how to configure a DNS server.

 Substantially rework the client behaviour section.

 (7) Section 7 has many of the same issues described in section 6.

 (8) There is no link between using DHCPv4 or DHCPv6 and DNS in terms of
 what IP version will be returned in a name lookup, and I don't see why you
 would want to imply that there is.

-- 
----------------------------------------+----------------------------------
 Reporter:  Margaret Wasserman <mrw@…>  |      Owner:  draft-ietf-pcp-
     Type:  defect                      |  dhcp@…
 Priority:  major                       |     Status:  new
Component:  dhcp                        |  Milestone:
 Severity:  -                           |    Version:
                                        |   Keywords:
----------------------------------------+----------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/58>
pcp <http://tools.ietf.org/pcp/>