Hi Tom, I have reflected your comments on the revision below: https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-10
Please see my answers inline. On Mon, Aug 31, 2020 at 7:05 PM tom petch <[email protected]> wrote: > Paul > > Picking out two points and top posting them > > RFC790 was obsoleted in 1982 and the information that was in it is now > kept up-to-date as part of the IANA website so what I am saying is that > I expect that you will be asked to change the reference to refer to > that part of the IANA website. Yes, it is technically possible to > include a reference to RFC790 in an I-D but that does not mean it will > be allowed-) > => I replaced RRFC790 with the following IANA Website for Protocol Numbers: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > > On RFC8174, that is the current standard for defining the rules about > using MUST, MAY, SHALL and such like in capitals in an I-D so if you > want to use those words in capitals with the sense defined in RFC8174 > then you MUST(!) reference RFC8174. Looking more closely, I see no such > usage of these words in capitals in this I-D so you could remove the > section entirely but if you are REQUIRED to include such usage at a > later date, perhaps as a result of a review such as a security review, > then you will need to include the paragraph from RFC8174 and include > references to RFC2119 and RFC8174. So what you had in -08 was invalid > and what you have in -09 is invalid but as it stands you could remove > section 2 entirely. > => I removed Section 2 entirely. Thanks. Best Regards, Paul > > HTH > > Tom Petch > > ----- Original Message ----- > From: "Mr. Jaehoon Paul Jeong" <[email protected]> > Sent: Friday, August 28, 2020 7:19 PM > > > > Hi Tom, > > I have reflected your comments with the revised draft: > > https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-09 > > > > I put my answers inline below. > > > > On Thu, Aug 27, 2020 at 6:29 PM tom petch <[email protected]> > wrote: > > > > >> Looking at the YANG: > > >> > > >> RFC4443 is referenced and so must be in the I-D References > > > > => This RFC4443 is included in the Normative References. > > > > >> > > >> RFC790 is referenced but this is now online under IANA - you can > see the > > >> > > => This RFC790 is included in the Normative References with its URL. > > > > > > >> IANA reference in > > >> draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 > > >> but that I-D needs to add it to the I-D references as this one will > need > > >> to; I note that this announcement flags it as a downref but think > that > > >> that is misguided - it needs replacing. > > >> > > => Could you clarify this question? > > I put the reference to > draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 > > in the draft. > > > > >> > > >> IPsec is the correct spelling - there are some IPSec in YANG > > >> description clauses > > >> > > => IPsec is used instead of IPSec. > > > > >> > > >> Figure 8 > > >> 2. The location of the NSF is 221.159.112.140. > > >> This address does not appear in the XML, nor is it an address > reserved > > >> for use in documentation AFAICT; in fact, I cannot see any > ipaddress > > >> anywhere in this I-D > > >> > > => I put the following text for an actual IPv4 address for > documentation > > in Appendix 5: > > > > The IPv4 address of the NSF is assumed to be 192.0.2.11 > [RFC5737]. > > Also, the IPv6 address of the NSF is assumed to be > 2001:DB8:0:1::11 > > [RFC3849]. > > > > --- > > In addition, I added the XML examples of IPv6 as well as those of > IPv4 > > in Appendix A > > with Figure 5 and Figure 7. > > > > > > >> > > >> s.2 correctly cites RFC8174 but does not use the text prescribed > there. > > >> > > => I removed RFC8174 from the draft. > > > > >> > > >> ' identity system-event-capability' > > >> references system-alarm - system event would seem more apt. More > > >> generally, these references for identity could be more specific, > e.g > > >> identity access-violation > > >> could reference 'access-violation ' rather than the more generic > 'system > > >> event' > > >> > > >> => I tried to improve the descriptions of the events and alarms > above. > > > > Thanks for your valuable comments. > > > > Best Regards, > > Paul > > > > > > >> Tom Petch > > >> > > >> > > >> ----- Original Message ----- > > >> From: "The IESG" <[email protected]> > > >> To: "IETF-Announce" <[email protected]> > > >> Cc: <[email protected]>; <[email protected]>; > > >> <[email protected]>; > > >> <[email protected]>; "Linda Dunbar" <[email protected]> > > >> Sent: Tuesday, August 25, 2020 6:59 PM > > >> > > >>>> The IESG has received a request from the Interface to Network > Security > > >>>> Functions WG (i2nsf) to consider the following document: - 'I2NSF > > >> Capability > > >>>> YANG Data Model' > > >>>> <draft-ietf-i2nsf-capability-data-model-08.txt> as Proposed > Standard > > >>>> > > >>>> The IESG plans to make a decision in the next few weeks, and > solicits > > >> final > > >>>> comments on this action. Please send substantive comments to the > > >>>> [email protected] mailing lists by 2020-09-08. Exceptionally, > > >> comments may > > >>>> be sent to [email protected] instead. In either case, please retain > the > > >> beginning > > >>>> of the Subject line to allow automated sorting. > > >>>> > > >>>> Abstract > > >>>> > > >>>> > > >>>> This document defines a YANG data model for the capabilities > of > > >>>> various Network Security Functions (NSFs) in the Interface to > > >> Network > > >>>> Security Functions (I2NSF) framework to centrally manage the > > >>>> capabilities of the various NSFs. > > >>>> > > >>>> The file can be obtained via > > >>>> > > >> > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ > > >>>> > > >>>> > > >>>> The following IPR Declarations may be related to this I-D: > > >>>> > > >>>> https://datatracker.ietf.org/ipr/3556/ > > >>>> https://datatracker.ietf.org/ipr/3606/ > > >>>> > > >>>> The document contains these normative downward references. > > >>>> See RFC 3967 for additional information: > > >>>> rfc8329: Framework for Interface to Network Security > Functions > > >> (Informational - IETF stream) > > >>>> rfc8192: Interface to Network Security Functions (I2NSF): > Problem > > >> Statement and Use Cases (Informational - IETF stream) > > >>>> rfc790: Assigned numbers (Historic - Legacy stream) > > >>>> rfc3444: On the Difference between Information Models and > Data > > >> Models (Informational - IETF stream) > > >>>> draft-ietf-i2nsf-nsf-monitoring-data-model: I2NSF NSF > Monitoring > > >> YANG Data Model (None - IETF stream) > > >>>> > > > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor Department of Computer Science and Engineering > Sungkyunkwan University Office: +82-31-299-4957 Email: > [email protected], [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 Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected], [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
