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

[<[e-mail]>]

Hi Stephen,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[e-mail]]
> Envoyé : jeudi 22 octobre 2015 14:17
> À : The IESG
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Stephen Farrell's No Objection on draft-ietf-pcp-port-set-12:
> (with COMMENT)
> 
> 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?

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

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

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

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