Subject: [pcp] WG last call on draft-ietf-pcp-dhcp-02

From: Dave Thaler <[email-masked]>
Date: Fri, 30 Mar 2012 14:53:28 +0000

This email initiates a last call on draft-ietf-pcp-dhcp-02.
This call will last for three weeks (due to various people
traveling the week after IETF) to conclude Friday
April 20.

Please send comments to the list, even if it's just to 
say you found no issues and you support publication.

I'd consider the document done once there's at least
5 reviewers who say it's ready for publication, and
any issues raised have been addressed.

Thanks,
-Dave

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 30 Mar 2012 17:49:08 +0200

support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: vrijdag 30 maart 2012 16:53
To: [email-masked]
Subject: [pcp] WG last call on draft-ietf-pcp-dhcp-02

Thanks,
-Dave

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 30 Mar 2012 19:11:24 +0200

I have read draft-ietf-pcp-dhcp-02.  I support specification of a DHCP option to configure hosts with the name(s) of their PCP Server(s), but I think there are any issues with this document that need to be addressed before publication.  My detailed comments are included below, but I'll start with a couple of general comments.

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.

---

From: "Yuchi Chen" <[email-masked]>
Date: Sun, 1 Apr 2012 14:11:16 +0800

Dear Wasserman,

I've read draft-ietf-pcp-dhcp-02. I do agree with your comment that this draft spends so many words 
on what should not be described in the draft which just specifies an option of DHCP, like the behavior
of PCP servers. Such clarification can be made in a draft titled with text like 'Considerations of DHCP 
options for the PCP'. Actually, I do agree with most part of what you said. However, I'm not so sure
if the statements in the abstract and introduction of the draft should be modified as you mentioned. 
Since getting the addresses, not just the names of PCP servers is the main objective of PCP clients,
and since providing the method for PCP clients to get PCP servers' names via DHCP is the purpose 
of the draft, I don't think it's appropriate to say that 'This document specifies DHCP (IPv4 and IPv6) 
options to configure hosts with Port Control Protocol (PCP) Server names.' in the abstract, or that 
'This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options to provision a list of PCP 
Server [I-D.ietf-pcp-base] names.' in the introduction. IMO, the current abstract and introduction of
the draft is ok, and it might be better if more details about the acquirement of addresses of PCP servers
is provided in the section 5 or elsewhere.

Best Regards!

Yuchi Chen

From: Margaret Wasserman
Date: 2012-03-31 01:11
To: Dave Thaler
CC: [email-masked]
Subject: Re: [pcp] WG last call on draft-ietf-pcp-dhcp-02

Margaret

Detailed Comments:

OLD:

NEW: 

OLD:

NEW:

To address this issue:

(6) Section 6: