[pcp] draft-ietf-pcp-base-00

"Dan Wing" <dwing@cisco.com> Fri, 03 December 2010 22:23 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: pcp@core3.amsl.com
Delivered-To: pcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0EA43A69B2 for <pcp@core3.amsl.com>; Fri, 3 Dec 2010 14:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.253
X-Spam-Level:
X-Spam-Status: No, score=-110.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oefe3kDv+6UN for <pcp@core3.amsl.com>; Fri, 3 Dec 2010 14:23:43 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 989793A677D for <pcp@ietf.org>; Fri, 3 Dec 2010 14:23:43 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApQFAEb9+EyrR7Ht/2dsb2JhbACVDoEkjHJxp3ubG4VIBIRe
X-IronPort-AV: E=Sophos;i="4.59,295,1288569600"; d="scan'208";a="297090764"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 03 Dec 2010 22:24:58 +0000
Received: from dwingWS ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB3MOwGN006023 for <pcp@ietf.org>; Fri, 3 Dec 2010 22:24:58 GMT
From: Dan Wing <dwing@cisco.com>
To: pcp@ietf.org
Date: Fri, 03 Dec 2010 14:24:57 -0800
Message-ID: <231b01cb9338$eb12f190$c138d4b0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuTOOrStIgMJHFHR++pmA/wtAfgKw==
Content-Language: en-us
Subject: [pcp] draft-ietf-pcp-base-00
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2010 22:23:44 -0000

I just posted draft-ietf-pcp-base-00, 
http://tools.ietf.org/html/draft-ietf-pcp-base-00,
which has very small changes from draft-wing-pcp-base-01,
such as removing most text discussing using same port as
NAT-PMP (I didn't fix all occurrences), 

Side-by-side diffs between them are at:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-wing-pcp-
base-01.txt&url2=http://tools.ietf.org/id/draft-ietf-pcp-base-00.txt
or http://tinyurl.com/2byejy3


Changes I intend to make for -01 include the following, which are
my understanding of the consensus from the face-to-face meeting
at IETF79, mostly from my presentation at 
http://www.ietf.org/proceedings/79/slides/pcp-2.pdf and chair's
presentation at http://www.ietf.org/proceedings/79/slides/pcp-4.pdf

If there are suggestions / objections / comments to the above, please
share them now.  

  * 'mandatory' semantic.  I plan to define a PCP option which
    requires the server to map to the requested-external-port (but not
    IP address?), or else return an error.  This is primarily to
    optimize server operation when some device within the subscriber's
    network is interworking from UPnP IGD to PCP.

  * ICMP, for the associated flow, will be opened as a side-effect of
    using PCP to permit inbound TCP/UDP.

  * defer firewall until later, or to a separate document.  (I would
    like to discuss this on the list.)

  * If PCP lifetime expires while there is still inside->outside data,
    the mapping is not abruptly terminated.  Instead, it continues to
    live on.  This is part of the "a PCP mapping is identical to a
    normal mapping" philosophy.

  * multihoming is deferred to later, or to another document

  * will not add support to request multiple ports

  * Add EVEN_PLUS_ONE functionality, primarily for RTP+RTCP. This will
    be done with a PCP option ("IE"; see below for reasons why I am
    considering renaming "IE" to "Option").

  * PCP server discovery:  I don't recall a meaningful consensus.  We
    should discuss on the list.

  * PCP encapsulation for DS-Lite (over IPv6 versus over UDP): I don't
    recall a meaningful consensus.  We should discuss on the list.


non-technical editing:
  * incorporate feedback (against draft-wing-pcp-base-01) received
    from Francis Dupont, Dave Thaler, and Mohamed Boucadair.

  * solidifying request/response behavior for client and server, to
    more clearly separate the behavior from the currently-defined
    OpCodes.  This will make it clearer how new OpCodes can be
    defined, and help client and server implementations not get
    tied into the operation of the currently-defined OpCodes.

  * rename IE (Informational Elements) to Options.  This is because
    they are not purely informational -- they change behavior.  DHCP,
    IP, and TCP all use "options", so this term seems a reasonably 
    generic and also well-understood.

-d