Thanks Paul – if we can’t use the existing ACL definitions, it would be good to understand why they don’t work. Thanks, Acee
From: "Mr. Jaehoon Paul Jeong" <[email protected]> Date: Tuesday, July 30, 2019 at 3:00 AM To: Acee Lindem <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, YANG Doctors <[email protected]>, "[email protected]" <[email protected]>, "Jingyong (Tim) Kim" <[email protected]>, "Mr. Jaehoon Paul Jeong" <[email protected]> Subject: Re: [I2nsf] YANG Doctors Working Group Last Call Review for draft-ietf-i2nsf-nsf-facing-interface-dm-06 Hi Acee, I will let the module prologue in the next revised draft match the suggested template in RFC 8407. I will leverage the existing IETF modiles for packet match specification and date/time specification in the next revision. When the revision is done, I will let you know. Thanks. Best Regards, Paul On Tue, Jul 30, 2019 at 12:51 AM Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: Hi Paul, The module prologue still doesn’t match the suggested template in RFC 8407 - https://tools.ietf.org/html/rfc8407#appendix-B. Additionally, you didn’t take my suggestion to leverage existing IETF models for packet match specification - https://datatracker.ietf.org/doc/rfc8519/ and date/time specification - https://www.rfc-editor.org/rfc/rfc8177.txt. Did you look at these? Thanks, Acee From: "Mr. Jaehoon Paul Jeong" <[email protected]<mailto:[email protected]>> Date: Thursday, July 25, 2019 at 10:10 AM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, YANG Doctors <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [I2nsf] YANG Doctors Working Group Last Call Review for draft-ietf-i2nsf-nsf-facing-interface-dm-06 Hi Acee, Here is the revision letter for the revised draft, reflecting your comments along with the revised draft: https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-07 The following things have not been addressed yet due to the time limitation. - The leveraging of the definitions in RFC 8519 for packet matching. - The factoring of common types and identities into a common I2NSF types module. These two will be reflected in the next revision. If you have further comments and questions, please let me know. Thanks. Best Regards, Paul On Sat, Jun 22, 2019 at 2:03 PM Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: I have reviewed this document as part of the YANG doctors directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other early review comments. Document: draft-ietf-i2nsf-nsf-facing-interface-dm-06 Reviewer: Acee Lindem Review Date: June 22, 2019 Review Type: Working Group Last Call Intended Status: Standards Track Summary: Needs to go back to Working Group for rework and another WGLC Modules: "[email protected]" Tech Summary: The model defines different types of I2NSF security policy. Each is comprised of an event, a condition, and an action. There is significant overlap with other IETF models. Within I2NSF, there is repetition of definitions which needs to go into a common I2NSF types module. Additionally, the data descriptions were were done quickly and never reviewed or edited. I believe it needs to go back to the working group for another revision and working group last call. . Major Comments: 1. Why don't you leverage the definitions in RFC 8519 for packet matching? We don't need all this defined again. 2. Date and time are defined in RFC 6991. Why don't those suffice? 3. Refer to the intervals as "time-intervals" rather than "time-zones". The term "time-zone" has a completely different connotation. 4. What the "acl-number"? Also, ACLs are named (RFC 8519). Also, why define all the packet matching and then reference an ACL. 5. The descriptions are very awkwardly worded and in many cases simply repeat the data node or identify description without hyphens. I started trying to fix this but it was too much. I'll pass for on for some examples. There are enough co-authors and contributors that one would expect much better. 6. There is overlap of definitions with the I2NSF capabilities draft. The common types and identities should be factored into a common I2NSF types module. 7. The "Security Considerations" in section 8 do not conform to the recommended template in https://trac.ietf.org/trac/ops/wiki/yang-security- guidelines> Minor Comments: 1. Section 3.1 should reference RFC8340 rather than attempting to include tree diagram formatting semantics. 2. "iiprfn" is a poor choice for default model prefix - I suggest "nsfintf". It is only one character longer and actually is expands to something meaningful. 3. RFC 2460 is obsoleted by RFC 8200. 4. RFC 791 is the wrong reference for IPv4 TOS. It should be RFC 1394. 5. What is the IGRP protocol? I'm familiar with EIGRP but not IGRP. 6. What is the skip protocol? Is this about skipping the check? If so, why is it needed. 7. Reference for IPv6 ICMP should be RFC 2463. 8. Why do you include Photuris definitions? Nobody uses this. 9. Note that all the keys for all 'config true' lists must be unique so your specification in the description as well as 'mandatory true' are redundant for the 'rules' list. This mistake is in other lists as well. 10. What is 'during' time? 11. What is a "security-grp"? Is this a security-group? 12. The module prologue doesn't match the example in Appendix B of RFC 8407. 13. There needs to be a good definition of absolute and periodic time in the descriptions. 14. The References do not include all the RFCs referenced by YANG model reference statements. Nits: Will send diff to authors and i2nsf chairs as example of review that should be done on YANG documents prior to sending to YANG doctors. Thanks, Acee _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php> -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
