Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pcp-port-set-10

[<[e-mail]>]

Dear Meral,

Many thanks for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Meral Shirazipour [mailto:[e-mail]]
> Envoyé : lundi 12 octobre 2015 07:49
> À : [e-mail]; [e-mail]
> Objet : Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
> 
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> Document: draft-ietf-pcp-port-set-10
> Reviewer: Meral Shirazipour
> Review Date: 2015-10-10
> IETF LC End Date:  2015-10-14
> IESG Telechat date: NA
> 
> 
> Summary:
> This draft is ready to be published as Standards Track RFC but I have some
> comments.
> 
> 
> Major issues:
> N/A
> 
> Minor issues:
> -[Page 7], Section 4.1, "If the PCP Client does not know the exact number
> of ports its requires, it MAY then set the Port Set Size to 0xffff,
> indicating that it is willing to accept as many ports as the PCP server
> can offer."
> Question/clarification to add: Mention if there a mechanism where the
> server will know which of the mapped ports are going to be used by the
> client? and which mappings can be discarded/reused in a subsequent
> request.
> 

[Med] I'm not sure to get your point, especially the link with the sentence you quoted. But fwiw policies about granted port ranges (size), ports to be excluded from assignment, etc. are implementation-specific. These are similar to the behavior of the PCP server assigning single port numbers (RFC6887). If the question is about renewal and/or port overlap, the behavior is called out in Section 4.4.  

> 
> Nits/editorial comments:
> -[Page 6], "In particular, the PREFER_FAILURE option MUST NOT be present
> in a request that contains a PORT_SET option.".
> Suggestion: Please add a sentence after this one suggesting why
> PREFER_FAILURE option MUST NOT be used. It was not clear to me until I
> read the rest of the draft...although I am still not sure why this
> behavior is to be a MUST NOT.

[Med] PREFER_FAILURE was specifically designed for the interworking with UPnP IGD:1 (RF6970). The rationale why it should not be used by other PCP clients (than the iwf) is discussed in Section 13.2 of RFC6887. The language in this draft is stronger than RFC6887, though. The decision about the language to use was made in an interim meeting (see the minutes at: http://www.ietf.org/proceedings/interim/2014/08/26/pcp/minutes/minutes-interim-2014-pcp-1). We can add the following sentence. 

NEW:
As a reminder PREFER_FAILURE was specifically designed for the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) [RF6970]. The reasons for not recommending the use of PREFER_FAILURE are discussed in Section 13.2 of [RFC6887].

> 
> -[Page 8], Section 4.3, "There is intentionally no port set capability
> discovery mechanism.".
> What is the intention?

[Med] This sentence is there to explicitly call out that this specification does not define a mean to discover whether the PCP server support the port set capability. As a generic comment, the working group felt it is early to define a mechanism to retrieve the capabilities of the PCP server (and the PCP-controlled device): see the minutes available here: http://www.ietf.org/proceedings/85/minutes/minutes-85-pcp (search for draft-boucadair-pcp-capability).

 I could not find anything on the list discussion.
> It would be good to clarify this to make this section puroposeful.
> 

[Med] This section was added to address the comment recorded in the minutes: http://www.ietf.org/proceedings/88/minutes/minutes-88-pcp. See the changes here: https://www.ietf.org/rfcdiff?url1=draft-ietf-pcp-port-set-04&url2=draft-ietf-pcp-port-set-05   

> -[Page 16] ,  Ref. [RFC7596] should be revised-it still refers to the
> draft

[Med] Thank you for catching this. This will be fixed.