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>
<mailto: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
<mailto: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>
