Subject: [pcp] pcp-base-06 submitted

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Feb 2011 17:41:08 -0800

As editor, I believe all the open issues are now resolved.  So, this is
really the time for everyone to read the document and see if you agree.  If
possible, please refer to the tracker Issue number.  All issues (including
closed) are visible at http://trac.tools.ietf.org/wg/pcp/trac/report/6.  The
ones marked 'enhancement' are being solved in other documents.

Document available at:
  http://tools.ietf.org/html/draft-ietf-pcp-base-06, and click on PDF at the
top for an easy way to print it.

Diffs from -05 available at:
  http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-06.txt
and summarized below and also in document's Appendix.

-d

-----

   o  DS-Lite: consensus was encapsulation mode.  Included a suggestion
      that the B4 will need to proxy PCP-to-PCP and UPnP-to-PCP.

   o  defined THIRD_PARTY option to work with the PEER OpCode, too.
      This meant moving it to its own section, and having both MAP and
      PEER OpCodes reference that common section.

   o  used "target" instead of "internal", in the hopes that clarifies
      internal address used by PCP itself (for sending its packets)
      versus the address for MAPpings.

   o  Options are now required to be ordered in requests, and ordering
      has to be validated by the server.  Intent is to ease server
      processing of mandatory-to-implement options.

   o  Swapped Option values for the mandatory- and optional-to-process
      Options, so we can have a simple lowest..highest ordering.

   o  added MISORDERED_OPTIONS error.

   o  re-ordered some error messages to cause MALFORMED_REQUEST (which
      is PCP's most general error response) to be error 1, instead of
      buried in the middle of the error numbers.

   o  clarified that, after successfully using a PCP server, that PCP
      server is declared to be non-responsive after 5 failed
      retransmissions.

   o  tightened up text (which was inaccurate) about how long general
      PCP processing is to delay when receiving an error and if it
      should honor OpCode-specific error lifetime.  Useful for MAP
      errors which have an error lifetime.  (This all feels awkward to
      have only some errors with a lifetime.)

   o  Added better discussion of multiple interfaces, including
      highlighting WiFi+Ethernet.  Added discussion of using IPv6
      Privacy Addresses and RFC1918 as source addresses for PCP
      requests.  This should finish the section on multi-interface
      issues.

   o  added some text about why server might send SERVER_OVERLOADED, or
      might simply discard packets.

   o  Dis-allow internal-port=0, which means we dis-allow using PCP as a
      DMZ-like function.  Instead, ports have to be mapped individually.

   o  Text describing server's processing of PEER is tightened up.

   o  Server's processing of PEER now says it is implementation-specific
      if a PCP server continues to allow the mapping to exist after a
      PEER message.  Client's processing of PEER says that if client
      wants mapping to continue to exist, client has to continue to send
      recurring PEER messages.