Subject: [pcp] pcp-base-23 posted

From: "Dan Wing" <[email-masked]>
Date: Fri, 10 Feb 2012 12:44:40 +0100

Version -23 was just posted.  This includes feedback from Jari's AD review,
Masataka Ohta, and tightening up some text suggested by co-authors.

Please review the changes.  Changes are summarized in Section B and copied
below.

Side-by-side differences between -22 and -23 are available at
  http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-23.txt

-d

B.1.  Changes from draft-ietf-pcp-base-22 to -23

   o  Instead of returning error NO_RESOURCES when requesting a MAP for
      all protocols or for all ports, return UNSUPP_PROTOCOL.

   o  Clarify that PEER-created mappings are treated as if it was
      implicit dynamic outbound mapping (Section 11.3).

   o  Point out that PEER-created mappings may be very short until bi-
      directional traffic is seen by the PCP-managed device.

   o  Clairification that an existing implicit mapping (created e.g., by
      TCP SYN) can become managed by a MAP request (Section 10.3.

   o  Clarified the ANNOUNCE Opcode is being defined in Section 13.1,
      and that the length of requests (as well as responses) is zero.

   o  Clarify that ANNOUNCE has Lifetime=0 for requests and responses.

   o  Clarify ANNOUNCE can be sent unicast by the client (to solicit a
      response), or can be multicasted (unsolicited) by the server.

   o  Allow ANNOUNCE to be sent unicast by the server, to accomodate
      case where PCP server fails but knows the IP address of a PCP
      client (e.g., web portal).

   o  Clarified ports used for unicast and multicast unsolicited
      ANNOUNCE.

   o  Tweaked NO_RESOURCES handling, to just disallow *new* mappings.

   o  State diagram is now non-normative, because it overly simplifies
      that implicit mappings become MAP (when they actually still retain
      their previous behavior when the MAP expires).

   o  In section Section 10.5, clarified that PEER cannot delete or
      shorten any lifetime, and that MAP can only shorten or delete
      lifetimes of MAP-created mappings.

   o  Clarified handling of MAP when mapping already exists (4 steps).

   o  2^32-1

   o  Randomize retry interval (1.5-2.5), and maximum retry interval is
      now 1024 seconds (was 15 minutes).

   o  Remove MUST be 0 for Reserved field when sending error responses
      for un-parseable message.

   o  Whenever PCP client includes Suggested IP Address (in MAP or
      PEER), the PCP server should try to fulfill that request, even if
      creating a mapping on that IP address means the internal host will
      have mappings on different IP addresses and ports.

   o  For NO_RESOURCES error, the PCP client can attempt to renew and
      attempt to delete mappings (as they can help shed load) -- it just
      can't try to create new ones.

   o  Removed the overly simplistic normative text regarding honoring
      Suggested External Address from Section 9 in favor of the text in
      Section 10.3 which has significantly more detail.