Hi, Thank you Mohamed, I am ok with the clarifications and changes. Best, Meral
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Tuesday, October 13, 2015 11:32 PM > To: Meral Shirazipour > Cc: [email protected]; [email protected] > Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10 > > Hi Miral, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Meral Shirazipour [mailto:[email protected]] > > Envoyé : mardi 13 octobre 2015 18:31 > > À : BOUCADAIR Mohamed IMT/OLN > > Cc : [email protected]; [email protected] > > Objet : RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10 > > > > Hi, > > Many thanks for the clarifications. Please see inline. > > > > Best, > > Meral > > > > > -----Original Message----- > > > From: [email protected] > > > [mailto:[email protected]] > > > Sent: Tuesday, October 13, 2015 4:42 AM > > > To: Meral Shirazipour; [email protected]; > > > gen- [email protected] > > > 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:[email protected]] > > > > Envoyé : lundi 12 octobre 2015 07:49 À : > > > > [email protected]; [email protected] 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] > > [Med] Thank you for clarifying. The size of port ranges that are assigned to > PCP clients is deployment-specific. Operators will need to tune the maximum > size of the port sets to be assigned taking into account various inputs such > as: > optimize the use of the shared addresses, reduce the amount of pcp > messages, etc. Of course, efficiency will depend on the size of the assigned > port set and the actual usage from this set. This is exactly the same issue > with > setting a port quota. > > FWIW, below is provided a sample YANG excerpt to configure the port set > feature in a PCP server. > > grouping port-set-option { > description > "PORT_SET option."; > > leaf port-set-enable { > type boolean; > description > "Enable/disable PORT_SET option."; > } > > leaf default-port-set-size { > type uint16; > description > "Indicates the default size of a port set."; > } > > leaf maximum-port-set-size { > type uint16; > description > "Indicates the maximum size of a port set."; > } > } > > It is up to each operator to set those parameters. Traffic analyses are > likely to > help operators to set the appropriate values. > > The port-set draft does not need to deal with these aspects as those are > deployment-specific. > > > > > > > > > > > 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/minut > > > es -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. > > [Med] This will be added to the next revision of the draft. > > > > > > > > > > > -[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" ? > > > > [Med] Yes, that was the main issue raised at that time. After re-reading the > text, I think we can delete "There is intentionally no port set capability > discovery mechanism.", the rest of the paragraph is clear enough. > > > > > > > -[Page 16] , Ref. [RFC7596] should be revised-it still refers to > > > > the draft > > > > > > [Med] Thank you for catching this. This will be fixed. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
