DHCP Options for the Port Control Protocol (PCP)
draft-ietf-pcp-dhcp-13

[Ballot comment]

Thanks for handling my discuss #1 and bringing the
other point to the attention of the WG.

------- OLD COMMENTS

- I agree with Brian's discuss point #2 about the
normative reference.

- section 1: I didn't get the meaning of the last
sentence here.

- section 3: The multiple lists thing seems over
complex to me but I guess the WG discussed that and
the DHC folks are presumably ok with it too.

- 3.2: Extracting an IPv4 address from an IPv4-mapped
(doesn't that need a ref?) IPv6 address seems quite
hacky. Might be good to a) say more about how to
do that in general and b) say why you need to
do it.

[Ballot discuss]

(Still working on this at -13)

(1) Which RFC 6887 threat models apply when this is
used? Don't you need to say and might that not affect
where this can be deployed securely?

(2) How can PCP authentication (based on the WG draft,
draft-ietf-pcp-authentication I assume?) make sense
with this use of DHCP? I guess that that can make
sense but I'm not getting it right now sorry. Can you
explain? (Note: its quite possible no change is
needed, just to explain the plan to a semi-ignorant
AD:-)

(3) How does a client know that the security identity
of one, some of all of the PCP server addresses
returned are the same or not? (You might cover this as
part of discuss point 2 above, not sure.)

[Ballot comment]
ipv6 mapped ipv4 addresses are a serious liability and I would vastly prefer to see those dropped as the mechanism for employing them is elided anyway. that said  iwill not block publication on that basis.

[Ballot comment]
I agree with Pete's DISCUSS.  Either the servers are functionally equivalent, in which case you don't need to distinguish between their addresses, or they're not, in which case you need to provide the client some way to tell which to use.  The document currently distinguishes between servers without telling the client how to pick one.

[Ballot discuss]
I've got issues with section 5 in general. On a particular point to explain:

  However, DHCP servers MUST NOT treat IP addresses
  returned from a single Fully Qualified Domain Name (FQDN) lookup as
  belonging to more than one PCP server.
 
That seems like completely bogus to me. It is *perfectly* reasonable for me to make a DNS record containing all of the A or AAAA records for all of my PCP servers, and then write my DHCP server to divide them up on the basis of subnet mask, where it will consider all addresses part of the same subnet as a single server, and each set of addresses from different subnets as different servers. You are making a protocol requirement that I set up my DNS configuration and DHCP configuration in a particular way, and that's not appropriate.

If this were a non-normative section, describing possible configuration choices, e.g., "A site could make different FQDNs for each PCP server, have the DHCP server configured with FQDNs, and treat the A or AAAA results from each FQDN as a separate server", I'd have no complaint. But this entire section presumes a bunch of undocumented out-of-band information (like, "The configuration for PCP servers in a DHCP server is done by FQDNs"), and then sticks requirements language next to the result of those presumptions.

[Ballot comment]
At the end of 3.1, add:

  To return more than one PCP server to the DHCPv6 client (as opposed
  to more than one address for a single PCP server), the DHCPv6 server
  returns multiple instances of OPTION_V6_PCP_SERVER.

The document seems to be defining a semantic difference between "one PCP server with multiple addresses" and "multiple PCP servers". I guess that's OK, but you never give an explanation of why a client would care about that distinction. What's the use case?

[Ballot discuss]

(1) Which RFC 6887 threat models apply when this is
used? Don't you need to say and might that not affect
where this can be deployed securely?

(2) How can PCP authentication (based on the WG draft,
draft-ietf-pcp-authentication I assume?) make sense
with this use of DHCP? I guess that that can make
sense but I'm not getting it right now sorry. Can you
explain? (Note: its quite possible no change is
needed, just to explain the plan to a semi-ignorant
AD:-)

(3) How does a client know that the security identity
of one, some of all of the PCP server addresses
returned are the same or not? (You might cover this as
part of discuss point 2 above, not sure.)

[Ballot comment]


- I agree with Brian's discuss point #2 about the
normative reference.

- section 1: I didn't get the meaning of the last
sentence here.

- section 3: The multiple lists thing seems over
complex to me but I guess the WG discussed that and
the DHC folks are presumably ok with it too.

- 3.2: Extracting an IPv4 address from an IPv4-mapped
(doesn't that need a ref?) IPv6 address seems quite
hacky. Might be good to a) say more about how to
do that in general and b) say why you need to
do it.

[Ballot discuss]
I have no objection to the publication of this document, but I have two points I would like to discuss.

1. Sections 3 & 4 do not have any guidance on error checking that should be done on the provided addresses.  RFC 6887 does not explicitly state it, but it infers that the PCP server address is not a multicast address.  If that is true, this document should provide that error checking guidance.

2. Sections 6 & 7 don't seem to fit with the goal of this document (defining the DHCP option formats).  Those sections simply point to pcp-server-selection, which would need to be read anyways when building a PCP client.  Can you point me to the discussion where those sections were deemed necessary for this document?  And if these sections remain, it would appear that pcp-server-selection would need to be a normative reference.

[Ballot comment]
The first para of the Introduction says

  This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options
  that can be used to provision PCP server [RFC6887] IP addresses.

Of course, you mean that the addresses are stable and are provided as
information to the clients. You don't mean that the addresses are
provisioned into the server.

The Abstract has this a bit better, and I suggest you say something
like...

  This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options
  that can be used to inform PCP clients of PCP server [RFC6887] IP
  addresses.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pcp-dhcp-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Option Codes registry in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) page at

http://www.iana.org/assignments/dhcpv6-parameters/

a new option code is to be registered as follows:

Value: [ TBD-at-registration ]
Description: OPTION_PCP_SERVER
Reference: [ RFC-to-be ]

Second, in the BOOTP Vendor Extensions and DHCP Options registry in the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters page at

http://www.iana.org/assignments/bootp-dhcp-parameters/

a new option code is to be registered as follows:

Tag: [ TBD-at-Registration ]
Name: OPTION_PCP_SERVER
Data length:
Meaning:
Reference: [ RFC-to-be ]

IANA Question --> The DHCPv4 Option Code registry provides for entries of "Data Length" and "Meaning." What would the authors like to have registered in those fields for the new option code : OPTION_PCP_SERVER?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DHCP Options for the Port Control Protocol (PCP)) to Proposed Standard


The IESG has received a request from the Port Control Protocol WG (pcp)
to consider the following document:
- 'DHCP Options for the Port Control Protocol (PCP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-04-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies DHCP (IPv4 and IPv6) options to configure
  hosts with Port Control Protocol (PCP) Server IP addresses.  The use
  of DHCPv4 or DHCPv6 depends on the PCP deployment scenario.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?

Proposed Standard


    Why is this the proper type of RFC?

This specifies an option for configuring a standards track protocol,
and the WG charter we have consensus on has a milestone for standards track
PCP server discovery.


    Is this type of RFC indicated in the title page header?

Yes.


(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The
    approval announcement contains the following sections:

    Technical Summary:

    Relevant content can frequently be found in the abstract and/or
    introduction of the document. If not, this may be an indication that
    there are deficiencies in the abstract or introduction.

This document specifies DHCP (IPv4 and IPv6) options to configure
hosts with Port Control Protocol (PCP) Server IP addresses.  The use
of DHCPv4 or DHCPv6 depends on the PCP deployment scenario.


    Working Group Summary:

    Was there anything in WG process that is worth noting? For example, was
    there controversy about particular points or were there decisions where
    the consensus was particularly rough?

There was controversy around the use of IP address vs hostnames vs
strings passed to getaddrinfo (which could be hostname or IP literal).
The WG eventually achieved rough consensus on the IP address mechanism
recommended by Ted Lemon, referencing [I-D.ietf-dhc-topo-conf] informatively
for discussion on how various scenarios can still be solved using that
mechanism.


    Document Quality:

    Are there existing implementations of the protocol? Have a significant
    number of vendors indicated their plan to implement the specification?

One implementation is documented at
http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-2.9

Other implementations are expected.


    Are there any reviewers that merit special mention as having done a
    thorough review, e.g., one that resulted in important changes or a
    conclusion that the document had no substantive issues? If there was a
    MIB Doctor, Media Type or other expert review, what was its course
    (briefly)? In the case of a Media Type review, on what date was the
    request posted?

Ted Lemon performed DHCP review and raised issues with the previous approach
(strings passed to getaddrinfo).  A significant discussion ensued which
resulted in Ted authoring draft-ietf-dhc-topo-conf for WGs and documents
to reference.  That document was presented to the PCP WG, which then got
consensus on the final approach (IP addresses, and referencing that draft
for discussion of operational guidance).


    Personnel:

    Who is the Document Shepherd?

Dave Thaler

    Who is the Responsible Area Director?

Ted Lemon


(3) Briefly describe the review of this document that was performed by the
    Document Shepherd. If this version of the document is not ready for
    publication, please explain why the document is being forwarded to the
    IESG.

The document shepherd checked ID-nits, reviewed the document for
clarity and completeness, verified all open issues were addressed,
and consensus exists on the document.


(4) Does the document Shepherd have any concerns about the depth or breadth
    of the reviews that have been performed?

No concerns.


(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA, DNS,
    DHCP, XML, or internationalization? If so, describe the review that
    took place.

The review has gone through multiple DHCP expert reviews, first by Bernie Volz
and then more recently by Ted Lemon. The reason the document took so long
was in fact due to the multiple reviews that ended up changing the consensus
of the WG as a result, with corresponding doc updates.


(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or the
    IESG should be aware of? For example, perhaps he or she is uncomfortable
    with certain parts of the document, or has concerns whether there really
    is a need for it. In any event, if the WG has discussed those issues
    and has indicated that it still wishes to advance the document, detail
    those concerns here.

No concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79
    have already been filed. If not, explain why?

Yes.


(8) Has an IPR disclosure been filed that references this document? If so,
    summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures filed.


(9) How solid is the WG consensus behind this document? Does it represent
    the strong concurrence of a few individuals, with others being silent,
    or does the WG as a whole understand and agree with it?

The WG as a whole understands and generally agrees with it. There were
dissenting opinions, but the WG did achieve consensus.


(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in separate
    email messages to the Responsible Area Director. (It should be in a
    separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
    Checklist). Boilerplate checks are not enough; this check needs to be
    thorough.


  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.

This is a false warning, it complains about the "a1.a2.a3.a4" notation
being used to refer to the four bytes of an IPv4 address.


  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (November 05, 2013) is 119 days in the past.  Is this
    intentional?

These are intentional.


  -- No information found for draft-ietf-dhc-topo-conf - is the name correct?

Seems to be a tools issue as the name and reference are correct.


  == Outdated reference: A later version (-02) exists of
    draft-ietf-pcp-server-selection-01

This informative reference is normal based on the date, and will be
automatically handled as part of the publication process.


(12) Describe how the document meets any required formal review criteria,
    such as the MIB Doctor, media type, and URI type reviews.

No formal reviews beyond the DHCP expert review that occurred.


(13) Have all references within this document been identified as either
    normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such normative
    references exist, what is the plan for their completion?

All normative references are to published RFCs.


(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

Normative references are to
RFC 2119 = BCP
RFC 2131 = Draft Standard
RFC 2132 = Draft Standard
RFC 3315 = Proposed Standard
RFC 4291 = Draft Standard
RFC 6887 = Proposed Standard


(16) Will publication of this document change the status of any existing
    RFCs? Are those RFCs listed on the title page header, listed in the
    abstract, and discussed in the introduction? If the RFCs are not
    listed in the Abstract and Introduction, explain why, and point to
    the part of the document where the relationship of this document to
    the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

No status changes.


(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all protocol extensions that the document
    makes are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).

The document shepherd's earlier review resulted in the present IANA
considerations section. No new registries are creted, and existing registries
referenced are clearly identified.


(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

None.


(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

There are no such formal language sections.