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

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?

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.

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.

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.

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

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.

-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