Subject: [pcp] pcp-base-09 posted

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Apr 2011 22:00:24 -0700

pcp-base-09 has been posted.  Document is at
<http://tools.ietf.org/html/draft-ietf-pcp-base-09>.  Side by side
differences from -08 is at
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-09.txt

-d

-----

B.1. Changes from draft-ietf-pcp-base-08 to -09

   o  Clarified in PEER OpCode introduction (Section 9) that they can
      also create mappings (as well as query and set existing mappings).

   o  More clearly explained how PEER can re-create an implicit dynamic
      mapping, for purposes of rebuilding state to maintain an existing
      session (e.g., long-lived TCP connection to a server).

   o  Added Suggested External IP Address to the PEER OpCodes, to allow
      more robust rebuilding of connections.  Added related text to the
      PEER server processing section.

   o  Removed text encouraging PCP server to statefully remember its
      mappings from Section 11.2.1, as it didn't belong there.  Text in
      Section 13.4 already encourages persistent storage.

   o  More clearly discussed how PEER is used to re-establish TCP
      mapping state.  Moved it to a new section, as well (it is now
      Section 7.3).

   o  MAP errors now copy the Requested IP Address (and port) fields to
      Assigned IP Address (and port), to allow PCP client to distinguish
      among many outstanding requests when using PREFER_FAILURE.

   o  Mapping theft can also be mitigated by ensuring hosts can't re-use
      same IP address or port after state loss.

   o  the UNPROCESSED option is renumbered to 0 (zero), which ensures no
      other option will be given 0 and be unable to be expressed by the
      UNPROCESSED option (due to its 0 padding).

   o  created new Implementation Considerations section (Section 11)
      which discusses non-normative things that might be useful to
      implementors.  Some new text is in here, and the Failure Scenarios
      text (Section 11.2) has been moved to here.

   o  Tweaked wording of non-EIM NATs in Section 11.1 to clarify the
      problem occurs both inside->outside and outside->inside.

   o  removed "Interference by Other Applications on Same Host" section
      from security considerations.

   o  fixed zero/non-zero text in Section 8.6.

   o  removed duplicate text saying MAP is allowed to delete an implicit
      dynamic mapping.  It is still allowed to do that, but it didn't
      need to be said twice in the same paragraph.

   o  Renamed error from UNAUTH_TARGET_ADDRESS to
      UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS.

   o  for FILTER option, removed unnecessary detail on how FILTER would
      be bad for PEER, as it is only allowed for MAP anyway.

   o  In Security Considerations, explain that PEER can create a mapping
      which makes its security considerations the same as MAP.