Description Option for the Port Control Protocol (PCP)
draft-ietf-pcp-description-option-05

[Ballot comment]
Thanks for addressing my issues. Here's what's left:

Section 2:

- I still believe that "The description text MUST NOT be null terminated" is probably wrong, but at least unnecessary. The document now says, "the description text is not null terminated", and puts the requirement on the receiver to do the right thing. This sounds like you're still requiring the sender to scan for the terminating null. But I don't think that anything bad will happen because of this.

Section 3, Paragraphs 4 & 5 try to put limits on the internal buffer sizes of the server, which is not appropriate. Please replace *both* paragraphs 4 & 5 with the following:

  Because of the UDP payload limit of 1100 octets, the Length of the
  Description 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.

[Ballot comment]
I have no objection to the publication of this document, but I do support:

1. Pete's (and Stephen's) points on the null character

2. Pete's Comments on implementation details in Section 3

3. Stephen's Comment on needing better/more privacy discussion related to the DESCRIPTION field

[Ballot comment]


- "o Etc." is not a good bullet in a PS

- "SHOULD NOT be used to leak privacy-related
information" is pretty lame really isn't it? Who do
you know that would set out to "leak privacy related
information"? Perhaps giving some better guidance,
e.g. say to not use customer IDs or names or PII or
addresses or locations, would be easy and worthwhile?

- On Pete's null terminated issue and the resulting
mail threads. I assume that the authors know that
mid-string null's have been used as part of deliberate
attacks against PKI? So there are security reasons as
well as interop reasons for not wanting nulls anywhere
within strings. Not worth a discuss, but maybe worth
a note.

[Ballot discuss]
This document needs some work:

Section 2:

- Please add something along the lines of, "The 'Reserved' field MUST be set to 0 and MUST be ignored by receiving implementations."

- Please add something like, "The 'Length' field contains the length, in octets, of the 'Description' field. It MUST NOT exceed 1016. (See section 3.)"

- I am utterly mystified by, "The description text MUST NOT be null terminated." If you wanted to say, "The description MUST NOT contain *any* null (U+0000) characters" because you don't want to confuse things that will accidentally treat the middle of the string as the terminator, I might get it. But if you're going to allow internal ones, I don't get why you care whether the description has a trailing null. If that's what the client wants, what does the server care?

[Ballot comment]
Section 3 gives a bunch of local implementation details as if they were spec requirements. You can't possibly require what the PCP server will do internally with this stuff.

Please rewrite the first four paragraphs with the following suggested text:

  The DESCRIPTION option is OPTIONAL for both PCP servers and PCP
  clients. This option (Code TBA, Figure 1) MAY be included in a PCP
  MAP/PEER request to associate a description with the requested
  mapping.

  A PCP server MAY ignore the DESCRIPTION option set to it by a PCP
  client. (It can either simply not support the option, or it can be
  configured to ignore it.) To signal that it has not accepted the
  option, a PCP server simply does not include the DESCRIPTION option
  in the response. If the PCP client does not receive a DESCRIPTION
  option in a response to a request enclosing a DESCRIPTION option,
  this means the PCP server does not support that option or it is
  configured to ignore it.

  If the DESCRIPTION option is not included in the PCP client request,
  the PCP server MUST NOT include the DESCRIPTION option in the
  associated response.

Paragraphs 5 & 6 try to put limits on the internal buffer sizes of the server, and give no indication of the reason for the length limits. Please rewrite as follows:

  Because of the UDP payload limit of 1100 octets, the Length of the
  Description 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.

Paragraphs 7 & 9 again try to specify internal behavior. Instead:

  If the PCP client request contains invalid DESCRIPTION options (e.g.,
  the content is not a legal UTF-8 string), the PCP server MUST ignore
  the request (i.e., MUST NOT return a DESCRIPTION option in the
  response).

[Paragraph 8 is fine]

  The PCP client uses empty DESCRIPTION option (i.e., Length set to 0)
  to erase the description text associated with a mapping.  To indicate
  that the PCP server has successfully cleared the description text
  associated with a mapping, the PCP server returns back the empty
  DESCRIPTION option in the response.

IESG/Authors/WG Chairs:

IANA has reviewed the current version draft-ietf-pcp-description-option-03.
Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has a question about the request made in the IANA Considerations
section of this document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document there is a single action which IANA must complete.

In the PCP Options subregistry of the Port Control Protocol (PCP) Parameters registry located at:

http://www.iana.org/assignments/pcp-parameters/

a single value from the optional-to-process range is to be registered as follows:

Name: DESCRIPTION
Reference: [ RFC-to-be ]

1) IANA Question: What entries should be added for DESCRIPTION in the following fields of the PCP Options registry as defined in RFC6887?

Purpose
Valid for Opcodes
Length
May Appear in
Maximum Occurances

2) IANA wants to point out the URL in the IANA Considerations section:

Please change the URL:

FROM:
http://www.iana.org/
  assignments/pcp-parameters/pcp-parameters.xml#option-rules

TO:
http://www.iana.org/assignments/pcp-parameters

This will ensure the URL will always work and point to the most current
version/extension.

IANA understands that this action is the only one required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PCP Description Option) to Proposed Standard


The IESG has received a request from the Port Control Protocol WG (pcp)
to consider the following document:
- 'PCP Description Option'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-02-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/ballot/


No IPR declarations have been submitted directly on this I-D.