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

[<[e-mail]>]

Hi Benjamin, 

Thank you for the comments. 

Please see 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; [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.  

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

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

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