Hi Med, On 18/06/18 08:10, mohamed.boucadair@xxxxxxxxxx wrote: > Hi Stephen, > > Thank you for the review. > > Please see inline. > > Cheers, Med > >> -----Message d'origine----- De : Stephen Farrell >> [mailto:stephen.farrell@xxxxxxxxx] Envoyé : dimanche 17 juin 2018 >> 22:07 À : secdir@xxxxxxxx Cc : >> draft-ietf-opsawg-nat-yang.all@xxxxxxxx; ietf@xxxxxxxx; >> opsawg@xxxxxxxx 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). Sure, I get the idea. I guess I'm not sure it's a good idea though, if not more fully specified. > > 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. Really? I'd have thought there was going to be some logging that was always on, e.g. to detect attacks. Or maybe you're not calling that logging? (I think that maybe also illustrates that as-is, this is currently not very well defined.) > 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 suspect that there'd also be a need for information about data retention duration and scope, for logging that is local to the NAT box. > >> 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. Well, mine is just a secdir review - you're not forced to do anything at all about it (unless some AD decides that you need to). But FWIW, yes, I do think it'd be better to drop that from this draft, and maybe consider working on some other interface to handle it better. Cheers, S. > >> 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. >
Attachment:
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
