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

From: <[email-masked]>
Date: Thu, 3 May 2012 13:51:02 +0200

Dear all,

A new version integrating almost all the comments from Margaret is now online: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-03

A diff can be seen here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-dhcp-03.txt.

Below more detailed answers.

Cheers,
Med

>-----Message d'origine-----
>De : pcp issue tracker [mailto:[email-masked]] 
>Envoyé : lundi 2 avril 2012 21:55
>À : [email-masked]; [email-masked]
>Cc : [email-masked]
>Objet : [pcp] #58: DHCP option issues from Margaret Wasserman
>
>#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.

Med: Done.

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

Med: Done.

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

Med: see http://trac.tools.ietf.org/wg/pcp/trac/ticket/59.

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

Med: The section has been removed.

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

Med: The text has been updated to specify an option may include several names; each name is treated as separte PCP Server. Examples are provided to illustrate the procedure. 

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

Med: Removed.

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

Med: The text has been updated to indicate several names can be included.

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

Med: Removed.

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

Med: Done.

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

Med: TTL was replaced with "validity lifetime" and cache with "local name resolution 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.

Med: Updated to be sync with 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.

Med: The issue is more about potential conflict when receiving PCP option in both DHCPv4 and DHCPv6. This section has been introduced to handle a comment received during early review of the document. I maintained this section.

>
>-- 
>----------------------------------------+----------------------
>------------
> 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/>
>
>