Re: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-nat-yang-16: (with COMMENT)

[<[e-mail]>]

Re-, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : mardi 25 septembre 2018 23:35
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : The IESG; [e-mail]; Joe Clarke; opsawg-
> [e-mail]; [e-mail]
> Objet : Re: Benjamin Kaduk's No Objection on draft-ietf-opsawg-nat-yang-16:
> (with COMMENT)
> 
> On Tue, Sep 25, 2018 at 09:27:08PM +0000, [e-mail] wrote:
> > Hi Benjamin,
> >
> > Thank you for the comments.
> >
> > Please see inline.
> 
> Also inline.
> 
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Benjamin Kaduk [mailto:[e-mail]]
> > > Envoyé : mardi 25 septembre 2018 20:31
> > > À : The IESG
> > > Cc : [e-mail]; Joe Clarke; opsawg-
> [e-mail];
> > > [e-mail]; [e-mail]
> > > Objet : Benjamin Kaduk's No Objection on draft-ietf-opsawg-nat-yang-16:
> (with
> > > COMMENT)
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-opsawg-nat-yang-16: 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-opsawg-nat-yang/
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > >
> > > Thanks for the easy-to-read document!  I just have a few comments and
> > > potential nits
> > > I noticed.
> > >
> > > It was somewhat interesting to me that basically everything is config rw,
> > > including ports and
> > > addresses that would normally be assigned internally by the NAT, but I
> don't
> > > see this as
> > > problematic.
> >
> > [Med] This is a good point. Actually, we are using rw because the same
> structure is also used for static mappings. That is, the external port and IP
> address are also provided.
> 
> I had even internalized that, just somehow didn't make the connection.
> Thanks for setting me straight.
> 
> > >
> > > Section 2.1
> > >
> > >                               Considerations about instructing explicit
> > >    dynamic means (e.g., [RFC6887], [RFC6736], or [RFC8045]) are out of
> > >    scope.  [...]
> > >
> > > I'm having trouble parsing this; is it maybe "instructing by explicit
> > > dynamic means" or "explicit dynamic mappings"?
> >
> > [Med] Changed to "Considerations about instructing by explicit dynamic
> means". Thanks.
> >
> > >
> > > Section 3
> > >
> > > What's the relationship between hold-down-timeout and hold-down-max --
> that
> > > is, if the maximum number of ports in the pool gets hit, to the oldest
> > > ports in the pool get ejected even if they haven't timed out, or what
> > > happens?
> > >
> >
> > [Med] deallocated ports are added to the hold-down pool till a max is
> reached; ports are removed from that pool upon the expiry of the hold-down-
> timeout. New deallocated ports cannot be added if the pool reaches its max.
> 
> Okay, so if the hold-down pool is full and a mapping's expiration timer
> expires, does that port immediately become free to use

[Med] Yes.


, or does the mapping
> persist until there is space in the hold-down pool, or something else?
> 
> > > I don't expect this to need to be in the document, but I'm curious what
> the
> > > use case for the all-algs-enable leaf is.
> >
> > [Med] This is to allow to enable all "default" ALGs that are widely
> supported (FTP, RSTP, in particular). This is an optimization as each of the
> ALGs can be enabled separately.
> 
> Okay.  I guess I don't quite see how this implies the semantics that it
> overrides the per-ALG settings, but it's documented well enough that I
> don't object to it being this way.
> 
> Thanks!
> 
> -Benjamin
> 
> > >
> > > I may be confused, but is the ordering relationship between low-threshold
> > > and high-threshold correct?  From the description it would seem like we
> > > need low < high, but I'm reading the text as requiring low >= high.
> > > Also, the error-message for that "must" stanza talks about port numbers,
> > > not percentage thresholds.
> >
> > [Med] Good c	atch. You are completely right. Fixed.
> >
> > >
> > >         container connection-limits {
> > >           [...]
> > >           list limit-per-protocol {
> > >             [...]
> > >             leaf limit {
> > >               type uint32;
> > >               description
> > >                 "Rate-limit the number of protocol-specific mappings
> > >                  and sessions per instance.";
> > >
> > > This is a maximum, not a rate-limit, I think?
> >
> >  [Med] Yes. Fixed.
> >
> > >
> > > Section A.6
> > >
> > >    EAMs may be enabled jointly with statefull NAT64.  This example shows
> > >    a NAT64 function that supports static mappings:
> > >
> > > nit: "stateful"
> >
> > [Med] Fixed. Thanks
> > >
> >