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

From: Simon Perreault <[email-masked]>
Date: Mon, 25 Feb 2013 19:48:31 +0100

WG,

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.

Please have a look!

Thanks,
Simon

-------- Message original --------
Sujet: New Version Notification for draft-tsou-pcp-natcoord-10.txt
Date : Mon, 25 Feb 2013 10:35:36 -0800
De : [email-masked]
Pour : [email-masked]
Copie à : [email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked]

A new version of I-D, draft-tsou-pcp-natcoord-10.txt
has been successfully submitted by Simon Perreault and posted to the
IETF repository.

Filename:	 draft-tsou-pcp-natcoord
Revision:	 10
Title:		 Port Control Protocol (PCP) Extension for Port Set Allocation
Creation date:	 2013-02-22
Group:		 Individual Submission
Number of pages: 10
URL: 
http://www.ietf.org/internet-drafts/draft-tsou-pcp-natcoord-10.txt
Status:          http://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord
Htmlized:        http://tools.ietf.org/html/draft-tsou-pcp-natcoord-10
Diff:            http://www.ietf.org/rfcdiff?url2=draft-tsou-pcp-natcoord-10

Abstract:
    This document defines an extension to PCP allowing clients to
    manipulate sets of ports as a whole.  This is accomplished by a new
    MAP option: PORT_SET.

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Mon, 25 Feb 2013 19:55:12 +0100

> - Simplified a lot. The draft is now much shorter and hopefully easier

s/WGLC/call for adoption/g

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Feb 2013 14:25:07 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Monday, February 25, 2013 10:55 AM
> To: [email-masked]
> Subject: Re: [pcp] Fwd: New Version Notification for draft-tsou-pcp-
> natcoord-10.txt
> 

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

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

---

From: <[email-masked]>
Date: Wed, 27 Feb 2013 07:45:17 +0100

Hi Dan,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Dan Wing
>Envoyé : mardi 26 février 2013 23:25
>À : 'Simon Perreault'
>Cc : [email-masked]
>Objet : Re: [pcp] Fwd: New Version Notification for 
>draft-tsou-pcp-natcoord-10.txt
>
>> > - Addresses more directly the additional use cases 
>identified during
>> WGLC.

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

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

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

>clarity and exactly how the server reacts in those edge conditions.

Med: Noted. 

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

>clarified, too (or simply removed).

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

>code would have to handle anyway if the PORT_SET cannot be 

Med: Works for me.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Feb 2013 11:28:41 +0100

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

Just to be clear, this would increase the option length to 3 bytes, right?

Should we increase it to 4 for padding's sake?

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

Well, it is clear that PORT_SET size of 1 is of little usefulness, but 
it can make sense if you just focus on the semantics. The are the same 
as a PORT_SET-less MAP request.

Usually having two ways of saying the same thing is bad(TM). I'm curious 
as to why Dan thinks it should still be allowed.

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

Also assuming internal port=5000, I think we need more than an example. 
There's undefined behaviour here.

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

I don't understand either. An example would be nice.

>> code would have to handle anyway if the PORT_SET cannot be

Me too.

Simon

---

From: <[email-masked]>
Date: Wed, 27 Feb 2013 11:48:39 +0100

Hi Simon,

Please see inline.
Cheers,
Med 

>De : Simon Perreault [mailto:[email-masked]] 
>Envoyé : mercredi 27 février 2013 11:29
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Dan Wing; [email-masked]

Med: 3 is just fine. 

>Should we increase it to 4 for padding's sake?

Med: Padding will be needed but it is not needed to be reflected in the option length. 

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

Med: Yes, we can be tolerant or strict. What if this point is defined as a configuration option to Section 5: the server should be configured to ignore an option with port_set_size=1 or return an error message + default behaviour is to return an error message?

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 27 Feb 2013 11:20:16 +0000

Please see inline.

On 2/27/13 5:48 AM, "[email-masked]"
<[email-masked]> wrote:

>Med: Yes, we can be tolerant or strict. What if this point is defined as
>a configuration option to Section 5: the server should be configured to
>ignore an option with port_set_size=1 or return an error message +
>default behaviour is to return an error message?

Unless there is a use case that requires a size to be 1, it doesn¹t make
sense to allow 1 as an allowed value. I am not aware of any such use case.
Let's see if Dan has one.

Senthil