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

From: <[email-masked]>
Date: Mon, 2 Apr 2012 10:33:24 +0200

Dear Margaret

Thank you for the review.

Please see inline.

Cheers,
Med
________________________________________
De : [email-masked] [[email-masked]] de la part de Margaret Wasserman [[email-masked]]
Date d'envoi : vendredi 30 mars 2012 19:11
À : Dave Thaler
Cc : [email-masked]
Objet : Re: [pcp] WG last call on draft-ietf-pcp-dhcp-02

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.

Med: This section has been added as requested by D. Thaler. A text has been proposed for integration in -02. Please see the mailing list archives.

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. 

Med: We had that discussion last year in PCP and Softwire. If I remember well R. Droms suggested documenting this would be useful. 

 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.

Med: We added that discussion section to explain the rationale behind the choice of defining a name option instead of the IP Address.
We had a lengthy discussion about this issue; please refer to http://www.ietf.org/mail-archive/web/dhcwg/current/msg11297.html for example or Softwire ML archives (search for draft-ietf-softwire-ds-lite-tunnel-option-05). DHC WG and IESG were against defining two options to convey the same information. First version of draft-*-pcp-dhcp defines both IP Address and Name but as a conclusion to those discussion we maintained the Name Option.

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

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

(3) Section 3: Configuration of a list of servers is quite common, and it does not require a lengthy rationale, nor is it valuable to invent a new way 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 above. DHC WG is against defining two options for provisioning the same information. Please refer to the discussion we had about this point in the PCP and Softwires mailing list Archives.

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

Med: this section says: discovered PCP server must control devices which will be in the data path of packets destined/sourced from the requesting host. Could you be more explicit and precise the concern you have with that text?

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

Med: What about "any terminal connected to a Customer Premise Equipment (CPE)"? 

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

Med: Changed "CP Router" to "Customer Premise Equipment (CPE)". 

(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: This section is non-normative. I can remove this section if there is no objection.

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

Med: There is no decision to make here: both parallel and sequential modes are valid models. A PCP Client may contact all receives PCP Servers or only one single server in the same time. This is deployment-specific. 

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.

Med: The current text assumes each name option is treated as separate PCP Server.

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?

Med: The base spec does not only cover the case where only ONE PCP Server is configured. This text specifies the behaviour to follow when a list of IP addresses are configured. 

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.  

Med: PCP Server Address Selection is out of scope of base spec.

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.

Med: FYI, we added this section -02 to handle a comment received from D. Thaler. I don't have an objection to remove the discussion about PCP Server Selection from this document. I'm fine with both. 

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.

Med: I can remove it.

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

Med: Yes but several OPTION_PCP_SERVER may be returned; see the discussion in Section 6.2. 

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

Med: This is only a "MAY". 

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

Med: The issue with names is that a cache of resolved address(es) will be maintained by a resolver. If the operator changes the IP address of the PCP server, the name resolution will always return the OLD IP address. A timer to flush the resolved IP address(es) must be used.

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.

Med: FWIW, this section has been added to address a comment from T. Mrugalski. What hurts in that section?

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Apr 2012 06:24:09 -0400

So, I'll note that recently a working group I chaired tried to represent
a server as a name not an IP address.
The DHCP working group objected strongly enough that we had to revert to
IP address based specification.
I'd expect the same issue to happen here.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 2 Apr 2012 06:34:50 -0400

> I'd expect the same issue to happen here.

Recent, widely-used DHCP Server options I'm aware of, like the NTP Server Option, allow you to send either a FQDN or an IP address in the same option format.  I think that's still the best choice, as it allows maximum flexibility for the administrator at little cost in terms of option complexity/length.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Apr 2012 07:26:20 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> On Apr 2, 2012, at 6:24 AM, Sam Hartman wrote:
    >> So, I'll note that recently a working group I chaired tried to
    >> represent a server as a name not an IP address.  The DHCP working
    >> group objected strongly enough that we had to revert to IP
    >> address based specification.  I'd expect the same issue to happen
    >> here.

    Margaret> Recent, widely-used DHCP Server options I'm aware of, like
    Margaret> the NTP Server Option, allow you to send either a FQDN or
    Margaret> an IP address in the same option format.  I think that's
    Margaret> still the best choice, as it allows maximum flexibility
    Margaret> for the administrator at little cost in terms of option
    Margaret> complexity/length.

I agree it's the best choice.
I wish Kerberos had not gotten pushback to trying to do this and
definitely think we should move forward with FQDN/IP address if we are
permitted to do so.

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 13:27:23 +0200

Re-,

I was one of the those advocating for defining both an IP Address and Name (see http://tools.ietf.org/html/draft-bpw-pcp-dhcp-00). We had a similar issue in RFC6334, DHC WG objected defining both an IP Address and a Name Option (there was also a DISCUSS from the IESG)(please refer to softwire archives ~October 2010).

The same reasons to select the Name option in RFC6334 apply here; I'm not expecting DHC WG and IESG change their position in less than 6 months.

Cheers,
Med  

>-----Message d'origine-----
>De : Margaret Wasserman [mailto:[email-masked]] 
>Envoyé : lundi 2 avril 2012 12:35
>À : Sam Hartman
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
>Objet : Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02
>
>
>Recent, widely-used DHCP Server options I'm aware of, like the 
>NTP Server Option, allow you to send either a FQDN or an IP 
>address in the same option format.  I think that's still the 
>best choice, as it allows maximum flexibility for the 
>administrator at little cost in terms of option complexity/length.
>
>Margaret
>
>
>

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 13:31:43 +0200

Dear Sam,

We defined both IP Address and FQDN Option in http://tools.ietf.org/html/draft-bpw-pcp-dhcp-00 but we removed the IP Address and based on the experience we had with RFC6334. 

Saying that, the Name option as defined in draft-ietf-pcp-dhcp allows to convey address literals. Below an excerpt from the draft:

   o  Name is a domain name (as per Section 3.1 of [RFC1035]) that
      contains one or more labels.  In particular, a PCP name may be
      structured as DNS qualified name or be composed of strings such as
      can be passed to getaddrinfo (Section 6.1 of [RFC3493]), including
      address literals, etc.

Cheers,
Med 

>De : Sam Hartman [mailto:[email-masked]] 
>Envoyé : lundi 2 avril 2012 13:26
>À : Margaret Wasserman

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 2 Apr 2012 17:56:14 -0400

Hi Med,

>      can be passed to getaddrinfo (Section 6.1 of [RFC3493]), including

I can live with this answer -- that the name is a string that may contain address literals.  

If this is the way we want to go, though there are still some places in the document that need to be cleaned up to be consistent with this.

Margaret

---

From: Dave Thaler <[email-masked]>
Date: Mon, 2 Apr 2012 22:23:17 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Margaret Wasserman
> Sent: Monday, April 02, 2012 2:56 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02
> 
> Hi Med,
> 
> > We defined both IP Address and FQDN Option in
> http://tools.ietf.org/html/draft-bpw-pcp-dhcp-00 but we removed the IP
> Address and based on the experience we had with RFC6334.
> >
> > Saying that, the Name option as defined in draft-ietf-pcp-dhcp allows to
> convey address literals. Below an excerpt from the draft:
> >

Yes, WG consensus was already that the name is a string that can be
passed to APIs such as getaddrinfo, etc.  That means it can be an IP literal,
or an FQDN, or even a non-fully-qualified domain name (though I'm not
sure why you'd want to do that, only that no code is expected to be able
to filter out such things, and it would just work).

I filed an issue in the closed state to track the previous WG consensus on this.

-Dave

> 
> If this is the way we want to go, though there are still some places in the
> document that need to be cleaned up to be consistent with this.
> 
> Margaret
> 
>

---

From: <[email-masked]>
Date: Tue, 3 Apr 2012 08:15:50 +0200

Dear Margaret,

There are only two occurrences of FQDN in Section 3 which is non-normative. I can change them to Name.

Thanks.

Cheers,
Med

>Envoyé : lundi 2 avril 2012 23:56
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Sam Hartman; [email-masked]
>http://tools.ietf.org/html/draft-bpw-pcp-dhcp-00 but we 
>removed the IP Address and based on the experience we had with 
>RFC6334. 
>> 
>> Saying that, the Name option as defined in 
>draft-ietf-pcp-dhcp allows to convey address literals. Below 
>an excerpt from the draft:
>> 
>If this is the way we want to go, though there are still some 
>places in the document that need to be cleaned up to be 
>consistent with this.
>
>Margaret
>
>
>