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

It looks like Pete's DISCUSS point about the NUL termination is resolved; that works for me.

Thanks for addressing the OPS-DIR feedback.

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

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.

Agree with Stephen - should not leak privacy data is pretty lame

- "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.