Re: [pcp] Fwd: New Version Notification for draft-tsou-pcp-natcoord-10.txt

Hi Dan,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la 
>part de Dan Wing
>Envoyé : mardi 26 février 2013 23:25
>À : 'Simon Perreault'
>Cc : pcp@ietf.org
>Objet : Re: [pcp] Fwd: New Version Notification for 
>draft-tsou-pcp-natcoord-10.txt
>
>> -----Original Message-----
>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
>> Simon Perreault
>> Sent: Monday, February 25, 2013 10:55 AM
>> To: pcp@ietf.org
>> Subject: Re: [pcp] Fwd: New Version Notification for draft-tsou-pcp-
>> natcoord-10.txt
>> 
>> Le 2013-02-25 19:48, Simon Perreault a écrit :
>> 
>> > This is a complete rewrite based on WGLC comments.
>> >
>> > - What we propose is now a MAP option (instead of a brand 
>new opcode).
>> > - Completely new background and motivation text.
>> > - Addresses more directly the additional use cases 
>identified during
>> WGLC.
>> > - Simplified a lot. The draft is now much shorter and 
>hopefully easier
>> > to understand.
>> 
>> s/WGLC/call for adoption/g
>
>I like what is proposed now and it seems to fit better into 
>PCP.  Thanks
>for the changes.
>
>
>A few issues and comments:
>
>1. The "P" bit comes from pcp-base's reserved range.  That bit is not 
>assignable to an option (layering violation).

Med: Ok to move the parity bit to the option data field.

>
>2. Eventually will need a discussion of the interaction of 
>that "P" bit 
>with draft-boucadair-pcp-rtp-rtcp, or can one draft subsume the other 
>draft?  What happens if a request contains both options, and how does
>the "P" bit interact with the draft-boucadair-pcp-rtp-rtcp option?

Med: draft-boucadair-pcp-rtp-rtcp is abandoned in favor of this unified approach proposed in the new version.

>
>3. natcoord-10 says "If the Port Set Size is zero or one, a 
>MALFORMED_OPTION error is returned."  Disallowing a port set size of 
>one seems overly restrictive, especially when later in the same 
>section there is allowance that if the server cannot fulfill the 
>requested port set size, the server maps one port.  I agree a port
>set size of 0 is nonsensical.

Med: It does not make sense to include a PORT_SET to ask for one single port. The text you are referring to is when the port set size > 1. 

>
>4. The paragraph starting with "If the PREFER_FAILURE option is absent"
>and the paragraph below it, could benefit from editing to enhance their
>clarity and exactly how the server reacts in those edge conditions.

Med: Noted. 

>
>5. "If a mapping already exists and the PORT_SET option can be honored"
>could also benefit from some editing to aid clarity.  For 
>example, let's
>say a single port is mapped (internal port = 5000), and then PORT_
>SET is used with internal port=6000.  It needs to be clearer 
>what happens
>there -- is the new request 'honored' by destroying the previous 
>mapping and creating this new one, or is only a single port mapped or
>something else?  Related, need a discussion in the document of what 
>happens if PORT_SET is used and a subsequent PCP request adjusts 
>the lifetime of a single port within that port set.

Med: I guess you want to say PORT_SET with internal port=5000, no? An example may be added to the text to aid clarity.

>
>6. In Section 4.3, Port Set Renewal and Deletion, it is unclear how
>PORT_SET changes the behavior for the Assigned External IP Address
>versus what is already in 
>http://tools.ietf.org/html/draft-ietf-pcp-base-29#page-32.  If the
>change is intentional, it should be highlighted clearer in natcoord;
>if it is re-stating what is already in pcp-base, that should be
>clarified, too (or simply removed).

Med: Can you explicit what changes are you referring to? Thanks.

>
>7. I think the PORT_SET option should be in the non-mandatory
>to process range.  Because the fall back (for when the server 
>doesn't understand PORT_SET) is exactly in line with what existing 
>code would have to handle anyway if the PORT_SET cannot be 
>fulfilled.

Med: Works for me.

>
>-d
>
>> Simon
>> --
>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> STUN/TURN server               --> http://numb.viagenie.ca
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp
>