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

[Meral Shirazipour <[e-mail]>]

Hi,
  Many thanks for the clarifications. Please see inline.

Best,
Meral

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, October 13, 2015 4:42 AM
> To: Meral Shirazipour; [e-mail]; gen-
> [e-mail]
> Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> 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.
>

[MSh] Sorry I was a bit unclear here. I was wondering what happens if the client asks with 0xffff, receives e.g. 100 ports but only uses 20 of them. What happens to the rest? Would they be unused until the next renewal? If so efficiency is not affected?
[please also see the thread reply by Simon]

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

[MSh] That looks great, thank you.

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

[MSh] Thank you for the pointers, so if I understand correctly the reason is "because they cause unnecessary failures" ? 


> > -[Page 16] ,  Ref. [RFC7596] should be revised-it still refers to the
> > draft
> 
> [Med] Thank you for catching this. This will be fixed.