Re: [I2nsf] I2NSF Drafts for Independent Submission Stream

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Adrian,
Thank you very much for your detailed review on the three drafts.

According to your comments, I will submit the following two drafts to the
ISE after polishing them up:
- draft-jeong-i2nsf-security-management-automation
- draft-lingga-i2nsf-analytics-interface-dm

Thanks.

Best Regards,
Paul

On Sun, Jul 30, 2023 at 9:15 AM Adrian Farrel <[e-mail]> wrote:

> Hi,
>
>
>
> [Reduced circulation a bit]
>
>
>
> This email is primarily for the ISE to help them understand how the
> documents may be positioned. The document authors may want to chime in, but
> I am not trying to have a discussion.
>
>
>
> I read all three of these documents on the plane today. I did not give as
> much review as they need, but I aimed to get enough of a view that we can
> work out the next steps.
>
>
>
> I note that none of the documents was adopted by I2NSF, although some of
> them have been around for a long time and revised often. From this, I
> deduce that either the work was judged out of scope of he working group or
> there was insufficient support from the working group.
>
>
>
> All three drafts need a lot of polish. This is the sort of assistance that
> working group review normally provides. Before they could be presented for
> publication they need work to make them more readable and clear: authors
> often look for an interested party who has good language skills and can
> help make the documents clear. Note that we cannot leave that sort of work
> to the late stage reviewers or the RFC Editor because:
>
>    1. It is unfair to ask people to give up their time to perform
>    technical reviews and then expect them to spend extra effort as language
>    editors.
>    2. The RFC Editor cannot perform technical edits and if the make a
>    large number of language edits, there is a high likelihood that they will
>    break some technical description
>
>
>
> *draft-yang-i2nsf-security-po**licy-translation* is not an easy ready. I
> think it is substantially “upside down” in that it discusses the details
> before presenting the architecture that gives the context for the details.
>
>
>
> The document advertises itself as providing “guidelines” but is positioned
> as Standards Track, which is inconsistent with a document that defines no
> on-wire behaviours.
>
>
>
> RFC 8329 shows the high level I2NSF architecture and names the main functional unit the Network Operator Management System. This document appears to name the same component as the Security Controller (a name introduced in draft-pastor-i2nsf-nsf-remote-attestation?). But the external interfaces are the same (CFI and NFI) so we can probably assume they are identical.
>
>
>
> The main thrust of this document is to describe how there is an important functional component within the Security Controller, and it describes how that component is broken into a number of subcomponents. The document goes on to define YANG models that are used on the interfaces between those subcomponents.
>
>
>
> It seems to me that the “guidelines” in this document are no more than advice to an implementer about how to build their software. The advice may be good or otherwise (I am not going to make an assessment), but I don’t think it has standardisation merit. This is because the document is essentially an implementation guide for people who need help working out the processing that should be done in an I2NSF system. I think, however, that the CFI and NFI are well-defined and that **any** implementation that maps between those interfaces would be acceptable. We do not need to show people how to make good implementations, and we should allow scope for them to make better or worse implementations as they choose.
>
>
>
> My conclusion, therefore, is that while this document falls into the category of “related to IETF work”:
>
> 1.       There is no value in bringing it to SecDispatch because it is not a document the IETF would publish
>
> 2.       The AD has already indicated that he would not AD-sponsor this document
>
> 3.       There is no working group into which this work falls
>
> 4.       This document would be better published as a journal article describing the architecture of Sungkyunkwan University implementation, and should not be published on the Independent Stream (the ISE can, of course, make their own decision)
>
>
>
> *draft-jeong-i2nsf-security-management-automation *is in much better shape both technically and with its use of language.
>
>
>
> Sections 1, 2, and 3 seem reasonable, although the material is presented across the three sections in a strange way, and would benefit from re-ordering so that related pieces are kept together (for example, Figure 1 is in section 2 – the terminology section – but the explanation of the terms used in the figure are found in section 3).
>
>
>
> The components shown in Figure 1 seem reasonable potential distinct components that could be implemented by different people and so would need standard interfaces.
>
>
>
> Section 4 seems to be a repeat of the internal functional architecture of the Security Controller as defined in draft-yang-i2nsf-security-policy-translation. I don’t see why this section is present in this document as it describes internals that do not need to be exposed in the architecture.
>
>
>
> If slimmed down with the removal of section 4, this document is a candidate for publication (it would be <8 pages of content). It falls into the category of “related to IETF work” and is sufficiently general to avoid being associated with any individual implementation.
>
>
>
> My conclusion, therefore, is that this document could be published as an RFC:
>
> 1.       Showing this document to SecDispatch might bring additional reviews, but I do not believe they have anywhere to which to dispatch it:
>
> a.       The AD has already indicated that he would not AD-sponsor this document
>
> b.       There is no working group into which this work falls
>
> 2.       This document could be published on the Independent Stream (the ISE can, of course, make their own decision), but would need to include some explanation of why it is not IETF work and how it is of value to the reader
>
>
>
> *draft-lingga-i2nsf-analytics-interface-dm* describes an interface introduced in draft-jeong-i2nsf-security-management-automation. Its publication, therefore, is entirely dependent on the publication of draft-jeong-i2nsf-security-management-automation.
>
>
>
> In defining a YANG model, the document requests codepoint assignments from registries governed as “Specification Required” with review by Designated Experts. The registries talk about being for things “used within IETF protocols” and it is not clear to me whether assignments may be made for non-IETF documents if the involved protocols **are** IETF protocols. The Designated Expert should be consulted.
>
>
>
> The model defined is intended to work on an external interface between components that may be separately located and might be implemented by different sources. This is a valid reason to define a model, but the question must arise as to whether anyone intends to implement this model (and the architecture in draft-jeong-i2nsf-security-management-automation) for actual deployment. This makes a difference between the document being a general definition of a YANG model, and “Sungkyunkwan University and ETRI’s YANG model”.
>
>
>
> I have not reviewed the YANG and I believe that detailed and careful YANG review is needed before the publication of any new model.
>
>
>
> My conclusion, therefore, is that this document could be published as an RFC:
>
> 1.       It is related to IETF work, although only if draft-jeong-i2nsf-security-management-automation is published
>
> 2.       Showing this document to SecDispatch might bring additional reviews, but I do not believe they have anywhere to which to dispatch it:
>
> a.       The AD has already indicated that he would not AD-sponsor this document
>
> b.       There is no working group into which this work falls
>
> 3.       Significant review of the YANG is needed
>
> 4.       Approval by the IANA Designated Experts should be gained before spending any reviewer time
>
> 5.       This document could be published on the Independent Stream (the ISE can, of course, make their own decision), but would need to include some explanation of whether it is specific to known implementations or more generally applicable.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Mr. Jaehoon Paul Jeong <[e-mail]>
> *Sent:* 27 July 2023 06:05
> *To:* Rifaat Shekh-Yusef <[e-mail]>; Adrian Farrel <
> [e-mail]>; Linda Dunbar <[e-mail]>
> *Cc:* Independent Submissions Editor (Eliot Lear) <[e-mail]>;
> Roman Danyliw <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Mr. Jaehoon Paul Jeong <
> [e-mail]>
> *Subject:* Re: I2NSF Drafts for Independent Submission Stream
>
>
>
> Hi Rifaat,
>
> Okay, SecDispatch WG seems like a good place.
>
> How can I take action to let the following three I2NSF drafts be reviewed
> by SecDispatch WG?
>
>
>
> ---
> - Security Management Automation of Cloud-Based Security Services in I2NSF
> Framework
> . URL:
> https://datatracker.ietf.org/doc/draft-jeong-i2nsf-security-management-automation/
> . Summary: This draft proposes an extension of the I2NSF framework for
> closed-loop
>   security control in Intent-Based Networking (IBN). It suggests a new
> component called
>   I2NSF Analyzer and a new interface called Analytics Interface.
> . Purpose: Informational RFC
>
> - I2NSF Analytics Interface YANG Data Model
> . URL:
> https://datatracker.ietf.org/doc/draft-lingga-i2nsf-analytics-interface-dm/
> . Summary: This draft proposes an Analytics Interface YANG Data Model to
> deliver either
>   policy reconfiguration or feedback information from I2NSF Analyzer to
> Security
>   Controller.
> . Purpose: Experimental RFC
>
> - Guidelines for Security Policy Translation in Interface to Network
> Security Functions
> . URL:
> https://datatracker.ietf.org/doc/draft-yang-i2nsf-security-policy-translation/
> . Summary: This draft proposes the guidelines for security policy
> translation
>    in the I2NSF framework, that is, the translation from a high-level
> security policy
>    to the corresponding low-level security policy. It focuses on the
> mapping between
>    Consumer-Facing Interface and Network Security Function (NSF)-Facing
> Interface.
>
> . Purpose:  Standards Track RFC
> ---
>
>
>
> Adrian and Linda,
>
> If you have another opinion, please let us know.
>
>
>
> Thanks.
>
>
>
> Best Regards,
>
> Paul
>
>
>
> 2023년 7월 26일 (수) 오전 3:22, Rifaat Shekh-Yusef <[e-mail]>님이
> 작성:
>
>
>
>
>
> On Tue, Jul 25, 2023 at 11:45 PM Mr. Jaehoon Paul Jeong <
> [e-mail]> wrote:
>
> Hi Eliot,
>
> I answer your comments and questions inline below.
>
>
>
> On Tue, Jul 25, 2023 at 1:35 AM Independent Submissions Editor (Eliot
> Lear) <[e-mail]> wrote:
>
> Hi Paul and thanks for contacting me, and thanks Adrian.  Before we
> proceed further, it may be desirable to either SECDISPATCH
>
> or present to OPSAREA these works back into the IETF.
>
> Has that been discussed?
>
>  => These three I2NSF drafts were discussed in the I2NSF WG in the past.
>
>    However, since their topics were out of scope of the I2NSF WG, they
> could not
>    be adopted by the I2NSF WG.
>    Even though I tried to proceed with the standardization of those drafts
>    through the rechartering of the I2NSF WG, the rechartering was declined
> by
>    Roman Danyliw, who is a SEC AD, due to the low energy of the I2NSF WG.
>    Roman also declined to shepherd them as an AD sponsor in the case of
>    Independent Submission Stream due to some reasons announced to the
> I2NSF WG.
>    By this background, I think that the discussion in SECDISPATCH may not
> be
>    appropriable for these drafts.
>
>
>
>
> I do not think that these are reasons for not to go to SecDispatch.
>
> That's the role of SecDispatch WG; to discuss and suggest a way forward
> for work that has no obvious home.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
>
>
>
>
>    OPSAWG may be appropriable for these drafts since they are related to
>    operations and management for the closed-loop security control by the
> I2NSF
>    framework.
>    However, many active WG documents are handled and overloaded by OPSAWG,
>    I am afraid that these drafts cannot be discussed and handled by
> OPSAWG.
>
> A working group closure on its own should not preclude further IETF work.
>
> Also, you may wish to present this work to iotops if you have not already
> done so.
>
> => Thanks for your encouragement on these drafts.
>    IOTOPS handles the issues related to IoT devices, so these drafts
>    may not be interesting to IOTOPS because these I2NSF drafts are related
> to
>    the virtualized security functions for cloud-based security service
> systems.
>
>
>
>    I believe that Adrian will be able to suggest a good way for these
> drafts after his review on
>    these drafts after this IETF 117.
>
>
>
>    I CC Roman Danyliw who was the responsible AD of the I2NSF WG since he
> may give
>
>    us his more opinions.
>
>    Thanks.
>
>    Best Regards,
>    Paul
>
>
>
>
>
> Eliot (ISE)
>
> On 25 Jul 2023, at 09:33, Mr. Jaehoon Paul Jeong <[e-mail]>
> <[e-mail]> wrote:
>
>
>
> Hi Adrian,
>
> As I told you yesterday,
>
> I2NSF WG has finished all the chartered work items including the five YANG
> data model drafts recently,
>
> and it is concluded now:
>
> https://datatracker.ietf.org/wg/i2nsf/about/
>
>
>
> However, to deploy the I2NSF framework and interfaces in the industry,
>
> the following three drafts will be quite useful:
>
>
>
> - Security Management Automation of Cloud-Based Security Services in I2NSF
> Framework
> . URL:
> https://datatracker.ietf.org/doc/draft-jeong-i2nsf-security-management-automation/
> . Summary: This draft proposes an extension of the I2NSF framework for
> closed-loop
>   security control in Intent-Based Networking (IBN). It suggests a new
> component called
>   I2NSF Analyzer and a new interface called Analytics Interface.
> . Purpose: Informational RFC
>
> - I2NSF Analytics Interface YANG Data Model
> . URL:
> https://datatracker.ietf.org/doc/draft-lingga-i2nsf-analytics-interface-dm/
> . Summary: This draft proposes an Analytics Interface YANG Data Model to
> deliver either
>   policy reconfiguration or feedback information from I2NSF Analyzer to
> Security
>   Controller.
> . Purpose: Experimental RFC
>
> - Guidelines for Security Policy Translation in Interface to Network
> Security Functions
> . URL:
> https://datatracker.ietf.org/doc/draft-yang-i2nsf-security-policy-translation/
> . Summary: This draft proposes the guidelines for security policy
> translation
>    in the I2NSF framework, that is, the translation from a high-level
> security policy
>    to the corresponding low-level security policy. It focuses on the
> mapping between
>    Consumer-Facing Interface and Network Security Function (NSF)-Facing
> Interface.
>
> The basic concepts of these works are proved through the I2NSF Hackathon
> Projects.
> The open-source I2NSF hackathon project is located at the Github:
> https://github.com/jaehoonpaul/i2nsf-framework
>
> I would like to submit those three drafts to the IETF independent
> submission stream this week:
>
> https://www.rfc-editor.org/about/independent/
>
> If you have comments on this matter, please let us know.
>
>
>
> I CC Eliot Lear who is the Independent Submissions Editor (ISE) in the
> IETF.
>
>
> Thanks for your support.
>
> Best Regards,
> Paul
>
> --
>
> ===========================
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Associate Professor
>
> Department of Computer Science and Engineering
>
> Sungkyunkwan University
> Office: [phone]
> Email: [e-mail], [e-mail]
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>
>
>
>