Subject: [pcp] Stephen Farrell's No Objection on draft-ietf-pcp-port-set-12: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 22 Oct 2015 05:17:07 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-pcp-port-set-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pcp-port-set/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 4, last sentence: I didn't get why this MUST NOT was
needed. I've no clue if it'd be obvious to a PCP implementer
or not though. 4.2 does say though, maybe consider moving the
note up?

- 4.1: size == 0xffff has gotta be operationally dangerous,
I'm surprised you don't have a bunch of caveats on it's use.
Shouldn't you have at least some guidance in 4.2 for that as
well? 6.1 and section 7 cover this though I guess. 

- 4.2: Is there a possible troublesome case where the client
asks for parity and gets that but gets fewer ports than
requested? E.g. if client wants 6 with parity and only gets 5,
then the client might not be able to use that as it really
needs 3 pairs of ports. Did you consider saying that a server
has to return an even number of ports if parity is requested?
(Or would that make sense?, I'm not sure:-)

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Oct 2015 08:23:54 -0400

> well? 6.1 and section 7 cover this though I guess.

I thought about that too, but decided it's covered by the text that
says the number of ports actually given will be limited.  0xffff is
just saying, "Give me as many as you're willing to give in one go,"
which seemed fine to me.

Barry

---

From: <[email-masked]>
Date: Thu, 22 Oct 2015 12:39:03 +0000

Hi Stephen,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : jeudi 22 octobre 2015 14:17
> À : The IESG
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Stephen Farrell's No Objection on draft-ietf-pcp-port-set-12:
> (with COMMENT)
> 

[Med] That sentence was removed as per the comment from Ben.

> well? 6.1 and section 7 cover this though I guess.

[Med] I don't see what can be added more than the discussion about the port quota that is already covered in 6.1 and 7. The PCP logic is that it is always up to the server to decide, but still clients may express their preferences. No guarantee those preferences will be honored by the server.

> (Or would that make sense?, I'm not sure:-)
[Med] The decision about what to return to the server depends on the policies configured to the server and the ports usage of a client. A server that supports port parity and port set assignment will honor a request as far as the port quota is not exceeded. I don't see a valid argument to require the server to always return an even number of ports if parity is requested.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Oct 2015 13:42:26 +0100

Hiya,

(The rest is fine, I've just a question on this)

On 22/10/15 13:39, [email-masked] wrote:
> [Med] The decision about what to return to the server depends on the
> policies configured to the server and the ports usage of a client. A
> server that supports port parity and port set assignment will honor a
> request as far as the port quota is not exceeded. I don't see a valid
> argument to require the server to always return an even number of
> ports if parity is requested.

Maybe I'm understanding it wrong, but if one of the reasons to
set the parity bit in the request is that the client will only
find an even set of ports useful then a server that returns an
odd set of ports will be a tiny bit inefficient at least. It's
not a big deal at all, but am I right in that?

S.

---

From: <[email-masked]>
Date: Thu, 22 Oct 2015 13:00:59 +0000

Re-,

You are right. This ** may ** be  inefficient....like it is also inefficient that a PCP server assigns a port of 20 ports while the clients asked only for 2. This is really a matter of policy to be configured to the PCP server. 

For example, a SIP UA that asks for 4 ports (2 for audio, and 2 for video) but gets only 3 from the server, may reissue another request to get two contiguous ports with parity preservation from the server. 
* If the port quota is not exceeded, the server will return two ports (this means one port won't be used). 
* If the port quota is exceeded, no port will be returned. In such case, the third port can be used for media stream (but the companion RTCP ports won't be available). 

Cheers,
Med

> Envoyé : jeudi 22 octobre 2015 14:42
> À : BOUCADAIR Mohamed IMT/OLN; The IESG
> Cc : [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Objet : Re: Stephen Farrell's No Objection on draft-ietf-pcp-port-set-12:
> (with COMMENT)
> 
> 
> Hiya,
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 22 Oct 2015 13:35:38 +0000

Precisely.