Re: [I2nsf] I2NSF Drafts for Independent Submission Stream

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Ok.  I await your submissions.

Eliot

On 31.07.23 18:48, Mr. Jaehoon Paul Jeong wrote:
> 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]>
>                     <mailto:[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]
>                     <mailto:[e-mail]>, [e-mail]
>                     Personal Homepage:
>                     http://iotlab.skku.edu/people-jaehoon-jeong.php
>                     <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>