Re: [secdir] Secdir last call review of draft-ietf-opsawg-nat-yang-14

[<[e-mail]>]

Hi Stephen, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[e-mail]]
> Envoyé : dimanche 17 juin 2018 22:07
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; [e-mail]
> Objet : Secdir last call review of draft-ietf-opsawg-nat-yang-14
> 
> Reviewer: Stephen Farrell
> Review result: Has Issues
> 
> I see one major issue:
> 
> 2.1: Logging in NATs and esp. CGNs is clearly sensitive in various ways. I
> think it'd be ok if logging was really out of scope, however, there is a
> logging-enable feature, I think under-specified,  (on page 63) so the
> statement
> in 2.1 seems contradictory to me - if logging is out of scope why is
> logging-enable a flag?.  Presumably if logging-enable transitions from F->T
> then you turn on (some undefined kind of) logging. 

[Med] The intent is not to define the exact set of logging information (e.g., Section 4 of RFC6888), the protocol to use (e.g., RFC8158 or draft-ietf-behave-syslog-nat-logging), etc... but to allow for disabling/enabling such feature (when supported by an implementation). 

If this transitions from
> T->F then what is the implementer supposed to do?

[Med] This transition will have an effect to disable ANY logging feature supported by an implementation. The transition for F to T is more problematic as it requires additional information to be available (e.g., logging server IP address and port, credentials, ...). The document assumes that data is provisioned using other specific modules (syslog, ipfix, etc.).

 I think that illustrates
> the
> under-specification here. The simplest thing might be to really make logging
> out of scope here by deleting the logging-enable thing entirely. (I can
> imagine
> that reaching consensus on a logging control interface would be non-trivial,

[Med] There is already RFC 8158.

> hence the suggestion to really put it out of scope rather than try specify it
> fully.)
> 

[Med] If, with the above clarification, you maintain your comment, then I don't have any objection to remove that optional feature from the module. Please advise. 

> Just one nit:
> 
> The abstract could do with a bit of re-wording as it reads awkwardly.  I'd
> say
> maybe just delete the 1st sentence.
> 

[Med] OK.