Subject: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00)

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 7 May 2013 13:02:23 +0000

This email communicates the start of a Working Group Last Call for the
following draft:

Title  : PCP Description Option
URL    : http://tools.ietf.org/html/draft-ietf-pcp-description-option-00
Authors: M. Boucadair et al.

The WGLC ends May 21st.

If this draft is important to your implementation or architecture, now is
the last chance to provide comments and request changes. Silence means you
agree with everything in it.

Beyond general comments, we also need official reviewers for the draft. If
you are willing to volunteer, please send an email.

Regards,

Reinaldo

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 10 May 2013 03:04:49 +0000

Hi,

I finish implementing the description option and would like to provide
some feedback.

- I suggest that the description string have a suggested MAX length.
Otherwise each client and server might have a different thresholds. And if
memory is not a premium it makes for safer programming since you can have
a fixed array and easier parsing.  Basically follow the fact that URI,
URLs, Headers, etc have a maximum length. My suggestion is 128 bytes.

- I like that the server can truncate the description to the maximum
supported length because it reduces back and forth between client and
server (good). But I wonder if an error should be returned as well.
Developers would need to compare length of sent/received options to see if
everything was okay. Not sure they will do that or having a self-contained
bit indicating truncation by server would be better.

- The document does not talk about updating the description. A client can
decide that the current description is not good enough and decide to
change it. 

- Why a description can not have '0'length? In my code it followed
naturally as a way to erase the current description. Instead of creating
million mappings to test functionality I was adding description, erasing,
adding, modifying of the same mapping.

Thanks,

Reinaldo

On 5/7/13 10:02 AM, "Reinaldo Penno (repenno)" <[email-masked]> wrote:

>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 13 May 2013 09:44:58 +0000

Hi Reinaldo,

Few comments

[1] The PCP Client SHOULD avoid including the DESCRIPTION Option in any subsequent request to that PCP Server.

Comment> what if the server is upgraded later and starts supporting DESCRIPTION ?

[2] If the description text carried in the DESCRIPTION Option is null terminated, the exact description text,
   including Null characters, MUST be returned by the PCP Server.

Comment> This conflicts with the previous sentence that client SHOULD not include Null characters.

[3] 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

comment> Please clarify recording; Is the PCP server supposed to store the text in the DESCRIPTION option in its memory and for what purpose ?
you may want to clarify that it cannot be used for auditing because the client could lie, for example say that the mapping is for FTP server but create the mappings for SIP server

[4] Security considerations discussed in [I-D.ietf-pcp-base] must be
   considered.

comment> If this information is not going to change the PCP client/server state and is only used as hint for debugging purpose; How are the PCP security considerations applicable to this option ?

[5] In addition, administrators of PCP Servers SHOULD configure a maximum description length which does not lead to exhaust
   storage resources in the PCP Server.

comment> Description length should also not exceed 1100 octets.

[6] May appear in: both request and response

Comment> you may want to change that to "May appear in: request.  May appear in response only if it appeared in the associated request."

[7] For Security considerations - you may want to add that since PCP messages are not encrypted; The Description option should not leak any privacy information like User X using this for a SIP call to User Y.

--Tiru.

> -----Original Message-----
> From: Reinaldo Penno (repenno)
> Sent: Friday, May 10, 2013 8:35 AM
> To: [email-masked]
> Subject: Re: [pcp] WGLC on PCP Description Option
> (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00)
> 
> Hi,
>

---

From: <[email-masked]>
Date: Mon, 13 May 2013 14:17:47 +0200

Hi Reinaldo,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Reinaldo Penno (repenno)
>Envoyé : vendredi 10 mai 2013 05:05
>À : [email-masked]
>Objet : Re: [pcp] WGLC on PCP Description Option
[Med] Makes sense. I made this change in Section 3:

OLD: 
The maximum length SHOULD be configurable in the PCP Server.

NEW:
The maximum length SHOULD be configurable in the PCP Server. The suggested maximum length is 128 bytes.

>bit indicating truncation by server would be better.

[Med] I don't think there is a value in returning an explicit error when the field is truncated. The client can deduce this by comparing the length of the field as sent in the request vs. the one in a received response.

>decide that the current description is not good enough and decide to
[Med] We can add the following to Section 3:

NEW:
   To update the description text of a mapping maintained by a PCP
   Server, the PCP Client constructs a MAP request which includes a
   DESCRIPTION Option carrying the new description text.  The PCP Client
   follows the behavior discussed in Section 11.2.1 of [RFC6887] to set
   the fields of this MAP request.  Upon receipt of the MAP request, the
   PCP Server proceeds to the same operations to validate a MAP request
   refreshing an existing mapping.  In addition, the PCP Server replaces
   the old description text with the new one included in the DESCRIPTION
   Option.

>adding, modifying of the same mapping.
[Med] Good point. I removed that sentence and replaced it with the following:

   The PCP Client uses empty DESCRIPTION Option (i.e., Length set to 0)
   to erase the description text associated with a mapping.  Upon
   receipt of an empty DESCRIPTION Option, the PCP Server MUST clear the
   description text associated with a mapping it maintains.

---

From: <[email-masked]>
Date: Mon, 13 May 2013 14:36:30 +0200

Hi Tiru,

Thanks for the review.

Please see inline.
Cheers,
Med

>Tirumaleswar Reddy (tireddy)
>Envoyé : lundi 13 mai 2013 11:45
>À : Reinaldo Penno (repenno); [email-masked]
[Med] The purpose of that text is to not overload the server with useless operations. This behavior can be updated to allow including a the DESCRIPTION Option if the PCP Client reboots.

>Comment> This conflicts with the previous sentence that client SHOULD not
[Med] That text is to accommodate poor implementations and avoid errors.

>comment> Please clarify recording; Is the PCP server supposed to store the
>text in the DESCRIPTION option in its memory and for what purpose ?
>you may want to clarify that it cannot be used for auditing because the
>client could lie, for example say that the mapping is for FTP server but
>create the mappings for SIP server
[Med] There is already this sentence in the document:

" Issues related to the usage of this field for troubleshooting or for any further usage are out of scope of this document. "

>comment> If this information is not going to change the PCP client/server
>state and is only used as hint for debugging purpose; How are the PCP
>security considerations applicable to this option ?
[Med] this spec does not change the base security threat analysis as discussed in rfc6887. I updated the text as follows:

OLD:
Security considerations discussed in [I-D.ietf-pcp-base] must be considered.

NEW:
PCP-related security considerations are discussed in [RFC6887].

>
>[5] In addition, administrators of PCP Servers SHOULD configure a maximum
>description length which does not lead to exhaust
[Med] The maximum length depends on other fields and options to be included in the same pcp request. The 1100 is a limit already discussed in the base spec. 

>Comment> you may want to change that to "May appear in: request.  May
>appear in response only if it appeared in the associated request."
[Med] Done.

>
>[7] For Security considerations - you may want to add that since PCP
>messages are not encrypted; The Description option should not leak any
>privacy information like User X using this for a SIP call to User Y.
[Med] I added this sentence:

   If the PCP Client and the PCP Server are not under the same
   administrative entity, the DESCRIPTION Option SHOULD NOT be used to
   leak privacy-related information (for example, see Section 3.2 of
   [RFC6462]).

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 13 May 2013 15:18:46 +0000

Hi Med,

Please see inline

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, May 13, 2013 6:07 PM
> To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); [email-masked]
> Subject: RE: [pcp] WGLC on PCP Description Option
> [Med] The purpose of that text is to not overload the server with useless
> operations. This behavior can be updated to allow including a the DESCRIPTION
> Option if the PCP Client reboots.

or the PCP client may want to try using DESCRIPTION option after it is notified that PCP server has re-booted using ANNOUNCE.

> " Issues related to the usage of this field for troubleshooting or for any
> further usage are out of scope of this document. "
> 
> >
> [Med] this spec does not change the base security threat analysis as discussed
> in rfc6887. I updated the text as follows:
> 
> OLD:
> [Med] The maximum length depends on other fields and options to be included in
> the same pcp request. The 1100 is a limit already discussed in the base spec.

You may want to point to that section, I guess this is the first option to be of variable length.

>    leak privacy-related information (for example, see Section 3.2 of

I am not sure, Is the PCP client aware if the PCP server is in the same administrative domain ?

--Tiru.

---

From: <[email-masked]>
Date: Mon, 13 May 2013 17:52:56 +0200

Re-,

Please see inline.

>De : Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
>Envoyé : lundi 13 mai 2013 17:19
>À : BOUCADAIR Mohamed OLNC/OLN; Reinaldo Penno (repenno); [email-masked]
>Objet : RE: [pcp] WGLC on PCP Description Option
>or the PCP client may want to try using DESCRIPTION option after it is
>notified that PCP server has re-booted using ANNOUNCE.
[Med] What about this change:

OLD:
The PCP Client SHOULD avoid including the DESCRIPTION Option in any subsequent request to that PCP Server.

NEW:
The PCP Client SHOULD avoid including the DESCRIPTION Option in any subsequent request to that PCP Server; this behavior is disabled if the PCP Client reboots or the PCP Client detects the PCP Server has rebooted.

>> >Comment> This conflicts with the previous sentence that client SHOULD
>not
>> >include Null characters.
[Med] I added, this sentence: 

"The configured maximum length MUST NOT exceed 1100 octets (see Section 7 of [RFC6887]).

>I am not sure, Is the PCP client aware if the PCP server is in the same
[Med] this can be by configuration or if the client and the server are on the same network realm. 

>> >> Otherwise each client and server might have a different thresholds.
>And
>> >if
>> >> Developers would need to compare length of sent/received options to
>see
>> >if
>> >> >If this draft is important to your implementation or architecture,
>now
>> >is
>> >> >the last chance to provide comments and request changes. Silence
>means
>> >you
>> >> >Beyond general comments, we also need official reviewers for the
>draft.
>> >If

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 13 May 2013 16:07:14 +0000

Hi Med,

Please see inline.

> Sent: Monday, May 13, 2013 9:23 PM
> The PCP Client SHOULD avoid including the DESCRIPTION Option in any subsequent
> request to that PCP Server; this behavior is disabled if the PCP Client
> reboots or the PCP Client detects the PCP Server has rebooted.
> 
> >
> >>
> >> >

Agreed, PCP client based on authentication or configuration can identify if the PCP server is in the same domain or not.

All the changes you have proposed look good. 

Best Regards,
--Tiru.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 14 May 2013 00:20:44 +0000

My comments are now in the marked up copy at
http://research.microsoft.com/~dthaler/draft-ietf-pcp-description-option-00.pdf

-Dave

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno (repenno)
> Sent: Tuesday, May 7, 2013 6:02 AM
> To: [email-masked]
> Subject: [pcp] WGLC on PCP Description Option
> If this draft is important to your implementation or architecture, now is the
> last chance to provide comments and request changes. Silence means you