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 <adr...@olddog.co.uk> 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 <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>님이 > 작성: > > > > > > On Tue, Jul 25, 2023 at 11:45 PM Mr. Jaehoon Paul Jeong < > 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> 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 <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: paulje...@skku.edu, 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
