From: Mr. Jaehoon Paul Jeong <[email protected]> Sent: 29 September 2021 02:45
Hi Tom, the co-authors and I will review your comments and revise our draft according to your comments. <tp> Paul I have had it pointed out to me that ports have a dynamic range that is never allocated and so is suitable for use in documentation starting at 49152 so I suggest that you use that instead of 3000. Tom Petch Best Regards, Paul On Tue, Sep 28, 2021 at 7:59 PM tom petch <[email protected]<mailto:[email protected]>> wrote: From: I2nsf <[email protected]<mailto:[email protected]>> on behalf of [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: 15 September 2021 17:28 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to Network Security Functions WG of the IETF. Title : I2NSF Registration Interface YANG Data Model Authors : Sangwon Hyun Jaehoon Paul Jeong Taekyun Roh Sarang Wi Jung-Soo Park Filename : draft-ietf-i2nsf-registration-interface-dm-12.txt Pages : 46 Date : 2021-09-15 <tp> I am confused about 'name'. This appears in the Information model in s.4.1 as 'NSF name' but I cannot see that in the YANG. The YANG has capability-name in two places once described as 'Unique name of this NSF's capability', the other as 'Unique name of this registered NSF'. So how is an instance of an NSF identified? When you create a name, you create a namespace and I see it as good practice to say something about that namespace, about its reach, the need for uniqueness and so on, like 'The name MUST be unique within ...'. s.2 NMDA could so with a reference to RFC8342. s.5.2 When you import an IETF module you must use the prefix that the module itself specifies; for capability that is nsfcap. This also appears in the examples. The examples use a port of 3000. This port number is registered with IANA for HBCI. I do not know what HBCI is; do you? Tom Petch Abstract: This document defines an information model and a YANG data model for Registration Interface between Security Controller and Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF) framework to register Network Security Functions (NSF) of the DMS with the Security Controller. The objective of these information and data models is to support NSF capability registration and query via I2NSF Registration Interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-registration-interface-dm-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
