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

[Meral Shirazipour <[e-mail]>]

Hi,
  Thank you.

Best,
Meral

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Wednesday, October 14, 2015 10:27 PM
> To: Meral Shirazipour
> Cc: [e-mail]; [e-mail]
> Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> Hi Meral,
> 
> Thank you again for your review.
> 
> FWIW, the changes you requested have been included in the new revision
> available at: https://tools.ietf.org/html/draft-ietf-pcp-port-set-11
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-port-set-11
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Meral Shirazipour [mailto:[e-mail]]
> > Envoyé : mercredi 14 octobre 2015 17:41 À : BOUCADAIR Mohamed
> IMT/OLN
> > Cc : [e-mail]; [e-mail]
> > Objet : RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> >
> > Hi,
> >   Thank you Mohamed, I am ok with the clarifications and changes.
> >
> > Best,
> > Meral
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > Sent: Tuesday, October 13, 2015 11:32 PM
> > > To: Meral Shirazipour
> > > Cc: [e-mail]; [e-mail]
> > > 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:[e-mail]]
> > > > Envoyé : mardi 13 octobre 2015 18:31 À : BOUCADAIR Mohamed
> IMT/OLN
> > > > Cc : [e-mail]; [e-mail]
> > > > 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: [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]
> > >
> > > [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.