Hi, Paul:
Thank for the update, I am still struggling about the relation between 
capability model and registration interface model.
First, the registration interface model imports ietf-i2nsf-capability and 
reuses some grouping defined in ietf-i2nsf-capability, this is not augmented 
model from ietf-i2nsf-capability. It is a new model which use some building 
block in some other existing models.

Augmented model should augment from ietf-i2nsf-capability with additional data 
nodes, e.g., here is IPv4 unicast routing management model which is augmented 
from ietf-routing

     augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {

       when "derived-from-or-self(../../rt:address-family, "

          + "'v4ur:ipv4-unicast')" {

         description

           "This augment is valid only for IPv4 unicast.";

       }
This gives you a sense what augmented model look like.

Second, Can ietf-i2nsf-capability module be used independent from 
ietf-i2nsf-registration-interface module? Is ietf-i2nsf-capability used in the 
same registration interface as  ietf-i2nsf-registration-interface module?

Third: I re-read section 4 of draft-ietf-i2nsf-registration-interface-dm, it 
said:
“

   The I2NSF registration interface is used by Security Controller and

   Developer's Management System (DMS) in I2NSF framework.  The

   following summarizes the operations done through the registration

   interface:



   1)  DMS registers NSFs and their capabilities to Security Controller

       via the registration interface.  DMS also uses the registration

       interface to update the capabilities of the NSFs registered

       previously.



   2)  In case that Security Controller fails to find some required

       capabilities from any registered NSF that can provide, Security

       Controller queries DMS about NSF(s) having the required

       capabilities via the registration interface.
”

I feel this registration interface is designed only for administrators to 
register NSF capability, In case that Security Controller fails to find some 
required

capabilities from any registered NSF that can provide, it can also auto detect 
required capabilities by itself from NSF, therefore simply define query RPC

to query capabilities from DMS seems not sufficient, unless you explicitly rule 
this auto detection out from this document.



-Qin
发件人: Mr. Jaehoon Paul Jeong [mailto:[email protected]]
发送时间: 2022年8月31日 19:14
收件人: Qin Wu <[email protected]>
抄送: [email protected]; Roman Danyliw <[email protected]>; Linda Dunbar 
<[email protected]>; Patrick Lingga <[email protected]>; 
skku-iotlab-members <[email protected]>; Mr. Jaehoon Paul 
Jeong <[email protected]>
主题: Re: [I2nsf] WGLC for draft-ietf-i2nsf-registration-dm-17

Hi Qin,
Here is the revision reflecting your detailed comments on the I2NSF 
Registration Interface:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-20

Patrick and I have revised this draft along with the attached revision letter.

Could you confirm whether this revision looks good to you or not?

Thanks.

Best Regards,
Paul



On Wed, Aug 24, 2022 at 6:42 PM Qin Wu 
<[email protected]<mailto:[email protected]>> wrote:
Hi, Paul:
Thank you for inviting me to review this draft.
I am a little confused about the relation of this draft with 
draft-ietf-i2nsf-capability-data-model
See quoted text in draft-ietf-i2nsf-capability-data-model
“
   This document provides an information model and the corresponding
   YANG data model [RFC6020][RFC7950] that defines the capabilities of
   NSFs to centrally manage the capabilities of those NSFs.  The NSFs
   can register their own capabilities into a Network Operator
   Management (Mgmt) System (i.e., Security Controller) with this YANG
   data model through the registration interface [RFC8329].

”
And quote text in draft-ietf-i2nsf-registration-dm
“
   This document describes an information model (see Section 4) and a
   YANG [RFC7950] data model (see Section 5) for the I2NSF Registration
   Interface [RFC8329] between the security controller and the
   developer's management system (DMS) to support NSF capability
   registration and query via the registration interface.

”
I am wondering which YANG data model is exchanged in the registration interface.
Shouldn’t YANG data model defined in draft-ietf-i2nsf-registration-dm augment 
the YANG model defined in
draft-ietf-i2nsf-capability-data-model.

In addition, I think registration interface seems not mandatory interface, 
security controller in some other case can
Learn capability NFV orchestrators, or NSF can expose dynamic capability to 
security controller.

Besides register NSF, I am wondering what other data or information can be 
registered? I assume there are a lot.
Therefore I would suggest to limit the scope of this registration interface, 
only focus NSF capability registration.
The title should reflect this.

For data model and information model definition, I think you should refer to 
RFC3444.
For NSF access information, I am wondering whether management protocol should 
also be part of access information.
Regarding performance capability, I assume it is related to software or 
hardware, or firmware specification,
Naming it as performance capability seems confusing to me.

-Qin
---------- 전달된 메일 ----------
보낸사람: Linda Dunbar 
<[email protected]<mailto:[email protected]>>
날짜: 2022년 6월 11일 (토) 오전 3:13
제목: [I2nsf] WGLC for draft-ietf-i2nsf-registration-dm-17
받는사람: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>>

Hello Working Group,

Many thanks to the authors of draft-ietf-i2nsf-registration-dm-17 to address 
all the comments from YANG Doctor review, SecDir review and OpsDIR review.

This email starts a three weeks Working Group Last Call on 
draft-ietf-i2nsf-registration-dm-17
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/

This poll runs until July 1, 2021.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this Document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.

If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

Thank you.

Linda

_______________________________________________
I2nsf mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2nsf
--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
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

Reply via email to