Protocol Action: 'PCP Description Option' to Proposed Standard (draft-ietf-pcp-description-option-05.txt)

The IESG <> Wed, 26 February 2014 18:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8C0391A0802; Wed, 26 Feb 2014 10:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OtF6ttXbERki; Wed, 26 Feb 2014 10:43:54 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (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 <>
To: IETF-Announce <>
Subject: Protocol Action: 'PCP Description Option' to Proposed Standard (draft-ietf-pcp-description-option-05.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Wed, 26 Feb 2014 10:43:47 -0800
Cc: pcp mailing list <>, pcp chair <>, RFC Editor <>
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

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 

  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

  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)


  Document Shepherd: Dave Thaler <>
  Responsible Area Director: Ted Lemon <>

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.

  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.