[pcp] Protocol Action: 'PCP Description Option' to Proposed Standard (draft-ietf-pcp-description-option-05.txt)
The IESG <iesg-secretary@ietf.org> Wed, 26 February 2014 18:43 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0391A0802; Wed, 26 Feb 2014 10:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtF6ttXbERki; Wed, 26 Feb 2014 10:43:54 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 190A41A0732; Wed, 26 Feb 2014 10:43:47 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140226184347.14989.14128.idtracker@ietfa.amsl.com>
Date: Wed, 26 Feb 2014 10:43:47 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/voueZ1llu4KQCskkLXBFV36PQZU
Cc: pcp mailing list <pcp@ietf.org>, pcp chair <pcp-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [pcp] Protocol Action: 'PCP Description Option' to Proposed Standard (draft-ietf-pcp-description-option-05.txt)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 26 Feb 2014 18:43:58 -0000
The IESG has approved the following document: - 'PCP Description Option' (draft-ietf-pcp-description-option-05.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/ Technical Summary This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. 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? Nothing controversial. Document Quality It is expected that any implementation of RFC 6970 (PCP/UPnP-IGD interop) would want this extension. One known implementation is reported in http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-2.1. Other than the document editor, the following people reviewed the document during WGLC and all concluded the document had no substantive issues: 1) Dave Thaler (document shepherd, WG co-chair) 2) Tiru Reddy 3) Simon Perreault 4) Paul Selkirk 5) Reinaldo Penno (WG co-chair, co-author) Personnel Document Shepherd: Dave Thaler <dthaler@microsoft.com> Responsible Area Director: Ted Lemon <ted.lemon@nominum.com> RFC Editor Note: Please replace paragraphs 4 and 5 of section three with the following new text. OLD (in -05): Because of the UDP payload limit of 1100 octets [RFC6887], the configured maximum length MUST NOT exceed 1016 octets. The suggested maximum length is 128 octets. If a PCP client includes a DESCRIPTION option with a length exceeding the maximum length supported by the PCP server, only the portion of the Description field fitting that maximum length is stored by the PCP server and returned to the PCP client in the response. If the PCP server receives a DESCRIPTION option having a length which does not exceed the maximum value configured, the PCP server MUST record the complete sequence of the description text and MUST send back to the PCP client the same DESCRIPTION option as the one included in the request. NEW: A PCP server SHOULD be able to store at least 128 bytes for a description. When the PCP server receives a DESCRIPTION option, it first stores the value of the received Description field, truncating it if it cannot store the entire value. The server MUST then send the stored value back to the PCP client in the DESCRIPTION option in the response.