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-policy-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 <jaehoon.p...@gmail.com> Sent: 27 July 2023 06:05 To: Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com>; Adrian Farrel <adr...@olddog.co.uk>; Linda Dunbar <linda.dun...@futurewei.com> Cc: Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org>; Roman Danyliw <r...@cert.org>; i2nsf@ietf.org; opsawg-cha...@ietf.org; sec-...@ietf.org; secdispa...@ietf.org; Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com> 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 <rifaat.s.i...@gmail.com <mailto:rifaat.s.i...@gmail.com> >님이 작성: On Tue, Jul 25, 2023 at 11:45 PM Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com <mailto:jaehoon.p...@gmail.com> > 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) <rfc-...@rfc-editor.org <mailto:rfc-...@rfc-editor.org> > 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 <mailto:jaehoon.p...@gmail.com> <jaehoon.p...@gmail.com> 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: +82-31-299-4957 Email: <mailto:paulje...@skku.edu> paulje...@skku.edu, jaehoon.p...@gmail.com <mailto:jaehoon.p...@gmail.com> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
