[I2nsf] 答复: WGLC and IPR poll for draft-ietf-i2nsf-nsf-facing-interface-dm-08

[Xialiang (Frank, Network Standard & Patent Dept)]

Hi WG,
I support the WGLC of this draft, which is one of the very basic output of this 
working group.

Thanks!

B.R.
Frank

[cid:image002.png@01D5B1A5.7627AED0]

This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2019年12月4日 6:23
收件人: i2nsf@ietf.org
抄送: Yoav Nir 
主题: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-nsf-facing-interface-dm-08


Hello Working Group,

Many thanks to the authors of draft-ietf-i2nsf-nsf-facing-interface-dm to 
address all the comments from YANG Doctor review.

This email starts a three weeks Working Group Last Call on 
draft-ietf-i2nsf-nsf-facing-interface-dm-08
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/

This poll runs until Jan 6, 2020 (considering many people taking Christmas to 
New Year off).

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this Document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.

If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

Thank you.

Linda & Yoav
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] WG scope follow-up

[Xialiang (Frank, Network Standard & Patent Dept)]

+1



--
夏靓 Frank
Mobile: 
+86-13913840549/+86-18651800549
Email: frank.xiali...@huawei.com
发件人：Diego R. Lopez 
收件人：Roman Danyliw ;i2nsf@ietf.org 
时间：2019-07-25 16:57:18
主 题：Re: [I2nsf] WG scope follow-up

Hi Roman,

I'd not go for a re-chartering unless other work items on security management 
(and related to the I2NSF model) are identified. I'd say the WG has been 
successful in achieving its original goals, and results like this, while 
valuable, should be directed to another initiative, like the current 
YANG-NextGen being discussed. A similar case would be some work on attestation, 
that was somehow at the origin of RATS, and probably will end there.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 25/07/2019, 16:45, "I2nsf on behalf of Roman Danyliw" 
 wrote:

Hello!

During today's F2F meeting, we discussed the need to check the charter 
scope of the work proposed in draft-yang-i2nsf-security-policy-translation.  
Making no value judgement on the utility of the work, in my review of the 
current charter, this class of work is not in scope.  The current charter 
doesn't currently cover standardization activity inside the NSF/DMS/controller.

If the WG wants to re-charter, by all means, let's have that conversation.

Roman


___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf





Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

[Xialiang (Frank, Network Standard & Patent Dept)]

Hi Gabi,
I think the latest update about the wrapping IPSec model in I2NSF-NSF-Facing 
interface model reflects and addresses the issue raised in last IETF meeting in 
Prague, see:
https://datatracker.ietf.org/meeting/104/materials/slides-104-i2nsf-model-convergence-proposal-00

In summary, it tries to keep the I2NSF capability data model as the basic and 
only one entry point for all the specific capability model (i.e., IPSec, IDS, 
etc.) consistently, while ensure independent configuration model for each 
specific model.
We think this is a good proposal and are addressing it.

B.R.
Frank

夏靓 （Frank Xia）
IP安全标准专家  -  数据通信标准专利部
华为技术有限公司
Tel : +86 25 56624539  /  139138 40549
Email : frank.xiali...@huawei.com
[cid:image001.png@01D50972.8E28D4E0]

This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Mr. Jaehoon Paul Jeong
发送时间: 2019年5月11日 21:59
收件人: Gabriel Lopez 
抄送: i2nsf@ietf.org; skku_secu-brain_...@googlegroups.com; Linda Dunbar 
; Fernando Pereñíguez García 
; Yoav Nir ; Rafa Marin 
Lopez ; Mr. Jaehoon Paul Jeong 
主题: Re: [I2nsf] WGLC and IPR poll for 
draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

Hi Gabriel,
Yes, I think the current ipsec-ietf-ike and ipsec-ietf-ikeless without change 
will be fine to our I2NSF interfaces
after I discuss with my student, Jinyong.

Our Registration Interface with capability data model will register into 
Security Controller
whether an NSF can support ipsec or not, and also in the case of the support of 
ipsec
whether an NSF can support ike or ikeless.

The NSF-Facing will do the same thing for an NSF rather than the actual 
configuration of ipsec stuff.
I assume that the detailed ipsec configuration will be done by your ipsec 
modules.

Thanks.

Best Regards,
Paul

On Fri, May 10, 2019 at 5:37 PM Gabriel Lopez 
mailto:gab...@um.es>> wrote:
Hi Paul.

The ipsec-ietf-ike and ipsec-ietf-ikeless modules are standalone modules that 
can be used in the facing interface. We do not understand why do you need to 
include them in the nsf-facing interface data model.

The idea of having a data model with all the security services a nfs can 
support is not practical and can turns into a huge complex model. Do you have 
in mind to include also configuration groupings for TLS, SSH, IDS, ACLs, etc.?

Best regards, Gabi.


El 9 may 2019, a las 23:09, Mr. Jaehoon Paul Jeong 
mailto:jaehoon.p...@gmail.com>> escribió:

Hi Gabriel,
we need to make ipsec-ike and ipsec-ikeless be grouping type so that your ipsec 
module can be imported by our data modules for two ipsec cases.
The container type cannot be imported by other data modules.

Thanks.

Best Regards,
Paul


2019년 5월 10일 (금) 오전 1:43, Gabriel Lopez mailto:gab...@um.es>>님이 
작성:
Hi Paul.

Could you explain what is the purpose of this change?

Best regards, Gabi.


El 9 may 2019, a las 16:02, Mr. Jaehoon Paul Jeong 
mailto:jaehoon.p...@gmail.com>> escribió:

Hi Authors: Rafa, Gabriel, and Fernando,

I have a request to let your authors revise i2nsf ipsec draft
(draft-ietf-i2nsf-sdn-ipsec-flow-protection-04)
in order to conform to our i2nsf interface data models.
For your YANG data module to be used in our NSF-Facing Interface data model 
through import,
your YANG data module needs some modification as follows.

### Original Code #
container ikev2 {
   .
}

container ietf-ipsec {
   
}

### Modified Code #

grouping ipsec-ike {
   ...
}

grouping ipsec-ikeless {
   ...
}

container ikev2 {
 description "Configure the IKEv2 software";
 uses ipsec-ike;
}

container ietf-ipsec {
 description "IPsec configuration";
 uses ipsec-ikeless;
}

With your modification, my SKKU team will modify our YANG data models
to accommodate your ipsec data model.

If you have any questions, please let me know.

Thank you.

Best Regards,
Paul

On Wed, Apr 17, 2019 at 11:54 PM Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
Hello Working Group,

This email starts a four weeks Working Group Last Call on 
draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.
This poll runs until May 15, 2019.

Authors: please update the draft per the comments and suggestions from YANG 
Doctors.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 

[I2nsf] 答复: WGLC and IPR poll for draft-ietf-i2nsf-capability-04

[Xialiang (Frank, Network Standard & Patent Dept)]

Hi all,
As one of the co-authors of this document, I am not aware any IPRs related with 
it.

I agree that this draft is stable enough for the WGLC request.
Thanks!

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2019年4月17日 22:51
收件人: i2nsf@ietf.org
主题: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-capability-04


Hello Working Group,

This email starts a three weeks Working Group Last Call on 
draft-ietf-i2nsf-capability-04.
This poll runs until May 8, 2019.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.

If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.


Thank you.

Yoav & Linda
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: 答复: [IPsec] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

[Xialiang (Frank, Network Standard & Patent Dept)]

Hi Robert,
Thanks for further clarification, it helps for me.
Again, I think the key point is not the original use case, but the function 
gaps each draft can fill in.

B.R.
Frank

发件人: Robert Raszuk [mailto:rras...@gmail.com]
发送时间: 2019年4月2日 16:32
收件人: Xialiang (Frank, Network Standard & Patent Dept) 

抄送: Hu, Jun (Nokia - US/Mountain View) ; Fernando Pereñíguez 
García ; Linda Dunbar 
; Roman Danyliw ; idr wg 
; stephane.litkow...@orange.com; i2nsf@ietf.org; 
idr-cha...@ietf.org; Gabriel López Millán ; Yoav Nir 
; Alvaro Retana ; ip...@ietf.org 
WG ; Benjamin Kaduk ; Rafa Marin Lopez 
; Paul Wouters 
主题: Re: [I2nsf] 答复: [IPsec] using BGP signaling to achieve IPsec Tunnel 
configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's 
Controller facilitated IPsec configuration

Hi Frank,

This draft does not talk about distributing any security related parameters. 
Maybe the name is a bit confusing as for some it means to be IPSec related.

We have discussed the draft in Prague and agreed to also extend it with other 
types of secure encap.

I have not discussed it with other authors but perhaps a much proper name and 
clearly less controversial would be:
draft-hujun-idr-encrypted-transport-autodiscovery or draft-hujun-idr-eta (for 
short) or something along those lines to reflect what this work is really about 
and how it differs from other proposals.

Thx,
R.




On Tue, Apr 2, 2019 at 3:52 AM Xialiang (Frank, Network Standard & Patent Dept) 
mailto:frank.xiali...@huawei.com>> wrote:
Hi Jun,
My personal view is no matter which use cases (SDN-based or BGP-based) you are 
for, the basic goal is to configure/distribute the IPSec parameters between the 
associated peers, for next step IKEv2 session negotiation. That is why all 
these related drafts should be aligned in certain way.

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org>] 代表 
Hu, Jun (Nokia - US/Mountain View)
发送时间: 2019年4月2日 6:22
收件人: Fernando Pereñíguez García 
mailto:fernando.perenig...@cud.upct.es>>; 
Linda Dunbar mailto:linda.dun...@huawei.com>>
抄送: Roman Danyliw mailto:r...@cert.org>>; idr wg 
mailto:i...@ietf.org>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>; 
idr-cha...@ietf.org<mailto:idr-cha...@ietf.org>; Gabriel López Millán 
mailto:gab...@um.es>>; Yoav Nir 
mailto:ynir.i...@gmail.com>>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>; 
ip...@ietf.org<mailto:ip...@ietf.org> WG 
mailto:ip...@ietf.org>>; Benjamin Kaduk 
mailto:ka...@mit.edu>>; Rafa Marin Lopez 
mailto:r...@um.es>>; Paul Wouters 
mailto:p...@nohats.ca>>
主题: Re: [I2nsf] [IPsec] using BGP signaling to achieve IPsec Tunnel 
configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's 
Controller facilitated IPsec configuration

Again, Linda, as discussed with you multiple times, my draft is really about 
extending current 
draft-ietf-idr-tunnel-encaps<https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/>
 to cover IPsec tunnel and other encryption tunnel like DTLS in next revsion 
(based on the feedback I got from Prague);
My draft is not intended to address SDN for IPsec use case and it does not 
require a central controller, and there are use cases where a central 
controller is not needed or can’t be used, my draft is intended for those cases;

So I really don’t see any conflict here

From: IPsec mailto:ipsec-boun...@ietf.org>> On Behalf 
Of Fernando Pere?íguez García
Sent: Monday, April 1, 2019 3:05 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>
Cc: Roman Danyliw mailto:r...@cert.org>>; idr wg 
mailto:i...@ietf.org>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>; 
idr-cha...@ietf.org<mailto:idr-cha...@ietf.org>; Gabriel López Millán 
mailto:gab...@um.es>>; Yoav Nir 
mailto:ynir.i...@gmail.com>>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>; 
ip...@ietf.org<mailto:ip...@ietf.org> WG 
mailto:ip...@ietf.org>>; Benjamin Kaduk 
mailto:ka...@mit.edu>>; Rafa Marin Lopez 
mailto:r...@um.es>>; Paul Wouters 
mailto:p...@nohats.ca>>
Subject: Re: [IPsec] using BGP signaling to achieve IPsec Tunnel configuration 
(draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller 
facilitated IPsec configuration

Hi Linda,

We have revised draft-hujun-idr-bgp-ipsec and, to the best of our 
understanding, we do not see any conflict with our draft being discussed in 
I2NSF. The IPsec attributes configured through BGP are only the peer’s tunnel 
address and local/remote subnet prefixes (that are used for the traffic 
selectors).  The rest of the IPsec configuration (AH/ESP, cryptographic 
algorithms, keys, etc.) are obtained via a “color mapping”, which is somet

[I2nsf] 答复: [IPsec] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

[Xialiang (Frank, Network Standard & Patent Dept)]

Hi Jun,
My personal view is no matter which use cases (SDN-based or BGP-based) you are 
for, the basic goal is to configure/distribute the IPSec parameters between the 
associated peers, for next step IKEv2 session negotiation. That is why all 
these related drafts should be aligned in certain way.

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Hu, Jun (Nokia - US/Mountain View)
发送时间: 2019年4月2日 6:22
收件人: Fernando Pereñíguez García ; Linda Dunbar 

抄送: Roman Danyliw ; idr wg ; 
stephane.litkow...@orange.com; i2nsf@ietf.org; idr-cha...@ietf.org; Gabriel 
López Millán ; Yoav Nir ; Alvaro Retana 
; ip...@ietf.org WG ; Benjamin Kaduk 
; Rafa Marin Lopez ; Paul Wouters 
主题: Re: [I2nsf] [IPsec] using BGP signaling to achieve IPsec Tunnel 
configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's 
Controller facilitated IPsec configuration

Again, Linda, as discussed with you multiple times, my draft is really about 
extending current 
draft-ietf-idr-tunnel-encaps
 to cover IPsec tunnel and other encryption tunnel like DTLS in next revsion 
(based on the feedback I got from Prague);
My draft is not intended to address SDN for IPsec use case and it does not 
require a central controller, and there are use cases where a central 
controller is not needed or can’t be used, my draft is intended for those cases;

So I really don’t see any conflict here

From: IPsec mailto:ipsec-boun...@ietf.org>> On Behalf 
Of Fernando Pere?íguez García
Sent: Monday, April 1, 2019 3:05 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>
Cc: Roman Danyliw mailto:r...@cert.org>>; idr wg 
mailto:i...@ietf.org>>; 
stephane.litkow...@orange.com; 
i2nsf@ietf.org; 
idr-cha...@ietf.org; Gabriel López Millán 
mailto:gab...@um.es>>; Yoav Nir 
mailto:ynir.i...@gmail.com>>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>; 
ip...@ietf.org WG 
mailto:ip...@ietf.org>>; Benjamin Kaduk 
mailto:ka...@mit.edu>>; Rafa Marin Lopez 
mailto:r...@um.es>>; Paul Wouters 
mailto:p...@nohats.ca>>
Subject: Re: [IPsec] using BGP signaling to achieve IPsec Tunnel configuration 
(draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller 
facilitated IPsec configuration

Hi Linda,

We have revised draft-hujun-idr-bgp-ipsec and, to the best of our 
understanding, we do not see any conflict with our draft being discussed in 
I2NSF. The IPsec attributes configured through BGP are only the peer’s tunnel 
address and local/remote subnet prefixes (that are used for the traffic 
selectors).  The rest of the IPsec configuration (AH/ESP, cryptographic 
algorithms, keys, etc.) are obtained via a “color mapping”, which is something 
not covered by the draft since it assumes routers are somehow pre-provisioned 
with this information.

Thus, we do not see this draft is also facing the task of formalizing the 
complete configuration of an IPsec device. We appreciate any clarification in 
case we are wrong.

Best regards,
Fernando..

El jue., 28 mar. 2019 a las 16:01, Linda Dunbar 
(mailto:linda.dun...@huawei.com>>) escribió:

Just to reiterate the concerns and issues I raised during IDR Thurs session 
discussion on using BGP signaling to achieve IPsec Tunnel configuration 
(draft-hujun-idr-bgp-ipsec).
Copy I2NSF WG because there is similar discussion for over a year.
Copy IPsecme WG as the group has many experts on the IPsec configuration.


1.  I2NSF WG has an on-going discussion on Controller facilitated IPsec 
configuration which has been discussed for over a year.  Even though the 
I2NSF’s  IPsec Configuration is between Controller and devices, whereas the BGP 
signaling IPsec Configuration proposed by draft-hujun-idr-bgp-ipsec is between 
peers, the configuration parameters to the devices are for the same purpose, 
therefore, should be aligned to avoid future conflicts to the industry.



2.  When using IPsec Tunnel between two peers, usually they are separated 
by untrusted domain. If Router “A” is allowed to  gets the IPsec tunnel 
configurations from peers across untrusted domain (instead of the today’s 
practice of from administrators), then many issues come up, for example:



How can a router “A” trust the Traffic Selection policy from a remote peer B? 
If the router “A” already has its Traffic Selection policy configured for a 
specific IPsec tunnel, but different from the Traffic Selection policy from 
remote peer B, which policy should Route A enforce for the IPsec Tunnel?  If 
the router “A” doesn’t have Traffic Selection policy specified, there are two 
remote nodes B & C signaling the “A” with different Traffic Selection policy, 
what should A do?



3.  RFC5566 only specifies a simple indication of IPsec Encap, but doesn’t 
do any of the IPsec configuration portion.



As indicated by BESS WG chair, there are multiple drafts 

[I2nsf] 答复: Call for WG Adoption on NSF Monitoring Draft

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi Linda,
I support adoption of this draft (as co-author).  I do not know of any IPR 
related to this draft.

Thanks!

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2018年12月6日 6:32
收件人: i2nsf@ietf.org
主题: [I2nsf] Call for WG Adoption on NSF Monitoring Draft

This is the start of a two weeks call for input on the WG adoption of the 
document: 
https://tools.ietf.org/html/draft-hong-i2nsf-nsf-monitoring-data-model-06

Thanks for the authors of the two I2NSF Monitoring drafts taking actions of 
merging the content.
We need more of those actions. As of now we have 8 WG drafts. We need to finish 
them next few months.

Bear in mind that WG adoption doesn’t mean the draft is ready, only means that 
WG will work together on the draft (instead of individuals).

Please provide feedback to the list/chairs if you believe that this document 
should be adopted as a WG document.

Thanks,

Linda & Yoav


From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.p...@gmail.com]
Sent: Thursday, November 15, 2018 6:35 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Yoav Nir mailto:ynir.i...@gmail.com>>
Cc: i2nsf@ietf.org; 
skku_secu-brain_...@googlegroups.com;
 Sangwon Hyun mailto:swhyu...@gmail.com>>; Mr. Jaehoon Paul 
Jeong mailto:jaehoon.p...@gmail.com>>
Subject: Request for WG Adoption Call on NSF Monitoring Draft

Hi Linda and Yoav,
As we discussed the last Bangkok meeting,
I have merged the two drafts of Information Model and Data Model
for NSF Monitoring into a new draft called 
draft-hong-i2nsf-nsf-monitoring-data-model-06:

- Two Information and Data Model Drafts
 . draft-zhang-i2nsf-info-model-monitoring-07
 . draft-hong-i2nsf-nsf-monitoring-data-model-05

- A Merged Data Model Draft
 . draft-hong-i2nsf-nsf-monitoring-data-model-06
 . https://tools.ietf.org/html/draft-hong-i2nsf-nsf-monitoring-data-model-06

The NSF monitoring is very important to manage the I2NSF security service system
in a reliable and scalable fashion.

Could you start a WG adoption call for this draft?

Thanks.

Best Regards,
Paul
--
===
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.p...@gmail.com, 
paulje...@skku.edu
Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: Start the WGLC for draft-ietf-i2nsf-applicability

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi all,
I support. And sorry for the delay feedback!

It is a good and useful document for readers to understand how to use I2NSF 
protocol and models in NFV or other environments on various NSFs.

Thanks for the good work!

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2018年9月7日 5:00
收件人: i2nsf@ietf.org; draft-ietf-i2nsf-applicabil...@ietf.org
主题: [I2nsf] Start the WGLC for draft-ietf-i2nsf-applicability

Working Group,

The authors of the following Working Group draft have requested Working Group 
Last Call on the following document:

https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/

“Applicability” is one of the milestones for I2NSF WG.

Given the overlap of functionality, WGLC will conclude for the bundle 
simultaneously.

Authors, please positively acknowledge whether or not you know about any IPR 
for your documents.  Progression of the document will not be done without that 
statement.

Last call will complete on Sept 21.


Yoav & Linda

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: Request for Comments on I2NSF Security Policy Translation

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi,
I share the same concern with Diego. Although it’s a good example of how to 
translate the YANG models, but it’s just one of the possible system 
implementations, thus not suitable to be a specification.

My suggestion is you can consider to include its key contents into the I2NSF 
applicability draft.

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Diego R. Lopez
发送时间: 2018年7月21日 23:39
收件人: Mr. Jaehoon Paul Jeong ; i2nsf@ietf.org
抄送: SecCurator_Team 
主题: Re: [I2nsf] Request for Comments on I2NSF Security Policy Translation

Hi Paul,

This is a rather interesting draft and I’d encourage you to continue and report 
your work in policy translation, as it constitutes one of the essential matters 
the I2NSF Controller has to deal with.

But I am afraid I don’t see this document progressing in the standards track 
(even as an experimental one), as the particular techniques for implementing 
the translation do not seem a proper subject for standardization. The only 
place I could see room for it in would be as part of the applicability draft, 
and I am not sure about it… What do others think?

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 21/07/2018, 12:01, "I2nsf on behalf of Mr. Jaehoon Paul Jeong" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
jaehoon.p...@gmail.com> wrote:

Hi I2NSF WG,

I would like to introduce our draft on I2NSF Security Policy Translation:
- Draft
  https://tools.ietf.org/html/draft-yang-i2nsf-security-policy-translation-01

- Slides
  
https://datatracker.ietf.org/meeting/102/materials/slides-102-i2nsf-security-policy-translation-00

This draft gives I2NSF developers the guidelines for the design and 
implementation
of I2NSF Security Controller.
One important functionality of the Security Controller is to automatically 
translate
an I2NSF User's high-level policy to a low-level policy for NSFs.

In the past of our I2NSF Hackathon projects, we made an XSLT-stylesheet-based 
translator.
But this translator has two limitations, such as static capability-and-NSF 
mapping construction
and inefficient maintenance on such a mapping.

The first limitation is the difficult high-level policy construction.
By the XSLT-stylesheet approach, I2NSF User MUST manually selects target NSFs 
to execute
the required security capabilities.
This means that I2NSF User needs to know each NSF's capabilities, so it is 
difficult for
I2NSF User to construct a high-level security policy without the detailed 
knowledge on NSFs.

The second limitation is an inefficient maintenance on the policy translator.
If the data models on I2NSF NSF-facing Interface requires some updates,
the XSLT stylesheet and XML files need to be updated.
On the other hand, our new approach  provides I2NSF User with an efficient
maintenance.

To solve these two limitations, our draft proposes an automata-based policy 
translator.
This translator consists of three components, such as Extractor, Data 
Converter, and Generator.

First, when a high-level policy is delivered from I2NSF User to Security 
Controller,
Translator extracts data about the policy at Extractor, and then converts it at 
Data Converter
for NSF(s). Also, Data Converter can select proper NSFs automatically.
Finally, Generator generates low-level policies of target NSFs based on the 
data from Data Converter.

I believe that this draft is valuable for IP2NSF WG adoption
to facilitate the development and deployment of I2NSF in the real world.

Please read this draft and give our authors your valuable comments.
We aim at making this proposal as an Informational RFC.

Thanks.

Best Regards,
Paul & Jinhyuk
--
===
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.p...@gmail.com, 
paulje...@skku.edu
Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader 

[I2nsf] 答复: How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi all,
I don’t have the clear observation of how popular the IKEv2 is supported by 
most of the OS, my straight thought is something without IKEv2 for simplicity, 
light weight implementation and cost saving has its feasibility now and in the 
future.

The other point we should consider is the performance improvement by skipping 
the IKEv2 negotiation and DH calculation. Take a large scale network as the 
example, it will take a long time for multiple peers to set up the SAs with one 
peer by IKEv2 and DH key exchange, since one peer has the cpu/memory up-limit 
to constrain the maximal number of IKEv2 sessions at the same time. But, by 
replacing the IKEv2 and DH with the key calculation (by peer itself, or by 
controller) and key distribution (through the controller), the total time for 
creating SAs among a large number of peers can be decreased dramatically and 
keep under certain time.

Of course, the SDN-based IPSec SAs management solution should be based on the 
basic assumption that the controller and the management plane links are all 
well protected.

The SA session key can be calculated by the controller and distributed to every 
peers in a communication group, or can be calculated by the peer itself and 
distributed to the required peers through the controller, or can be DH 
exchanged through controller. All the three ways have their respective pros and 
cons. More study and discussion will be helpful.

Finally, I believe we do need a new way (e.g., the sdn-based way) to deal with 
the IPSec SAs management, especially for the large number of IPSec SAs. And we 
already have good progress on the right direction.

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Yoav Nir
发送时间: 2018年7月17日 12:44
收件人: Linda Dunbar 
抄送: IPsecME WG ; i2nsf@ietf.org
主题: Re: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection 
@I2NSF

[no hats]

I’m not convinced by the necessity of either this or “Case 2”.

IKEv2 is supported by all operating systems, including every Linux distribution 
and phone OS since iPhone 2. It’s ubiquitous and isn’t hard. Given that, I’m 
not convinced we need to take care of nodes that do not support IKEv2. There 
just aren’t any such nodes in the NSF world. If we were talking about smart 
objects, then we could find such nodes, but not NSFs.

IKE performs two functions:

  *   Authenticate the peers to one another
  *   Exchange keys.

If I understand your proposal correctly, you would like to keep the peers 
exchanging keys (although not directly), but not authenticating. This kind of 
makes sense because the SDN controls identities and credentials. There is no 
meaningful authentication except to verify the credentials provided to the peer 
by the controller.

So I think the proposal makes sense, but I don’t see it as necessary.

Yoav
(again, no hats)


On 17 Jul 2018, at 6:16, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:

There are two cases proposed by  SDN controlled IPsec Flow Protection:
-Case 1 is SDN controller only sending down the IPsec configuration 
attributes to End points, and End Points supports the IKEs and SA maintenance.
-Case 2 is end points not supporting IKEv2. SDN controller manage all 
the SA Key computation and distribute to all end nodes. We had an interim 
meeting discussing this. (see the attached Meeting minutes).

Question to IPsecme WG: How about something in between?
-Assume that SDN controller maintain TLS (or DTLS) to all end points 
for distributing the IPsec configuration attributes (same as Case 1 above).
-Instead of using IKEv2 for two end points (E1 & E2) to establish 
secure channel first for SA negotiation purpose, E1 can utilize the secure 
channel between E1 <-> SDN-Controller <->E2 to negotiate SA with E2 and 
responsible for its own SA computation.
-E1 still compute SA and maintain SAD. Only utilize the secure 
channel through the SDN controller to exchange SA.

This method not only doesn’t require the SDN controller to keep all the SAD for 
all nodes, but also simplify large SD-WAN deployment with large number of IPsec 
tunnels among many end points.

Any opinion? Issues?

Linda Dunbar


From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
Sent: Monday, July 16, 2018 3:11 PM
To: IPsecME WG mailto:ip...@ietf.org>>
Subject: [IPsec] IPsec Flow Protection @I2NSF

Hi.

I’d like to draw you attention to the agenda of the I2NSF working group: 
https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00

The I2NSF working group will meet on Wednesday after lunch. On the agenda, 
there is this item which may be of interest to IPsec folks:


13:45-14:00 IPsec Flow Protection (15 min): Rafa Marín-López
In case you haven’t been following, the IPsec flow draft was adopted by I2NSF. 
The authors are making progress, including open source implementations.

One issue that may come up in the discussion (either at I2NSF or here) is that 
other drafts about controlling 

[I2nsf] 答复: 答复: 转发: New Version Notification for draft-dong-i2nsf-asf-config-00.txt

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi Diego,
We got your point, which makes sense.
We will consider how to make the security capability to be abstract and general 
enough, and independent with any particular kind of device. Although it's not 
so straightforward to achieve, it is indeed the right direction.

Thanks!

B.R.
Frank

-邮件原件-
发件人: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com] 
发送时间: 2018年7月16日 21:54
收件人: Xialiang (Frank, Network Integration Technology Research Dept) 
; Dongyue (Yue, Network Integration Technology 
Research Dept) ; i2nsf@ietf.org
主题: Re: 答复: [I2nsf] 转发: New Version Notification for 
draft-dong-i2nsf-asf-config-00.txt

If you associate a capability action (let's say collect-attack-evidence-enable) 
with a particular kind of device (as part of the antivirus branch) I would not 
be able to declare or use that particular capability unless the provider has 
stated the function is an antivirus, and therefore consider all the other 
capabilities for the antivirus. What is more, this prevents to have a common 
semantics for something like collect-attack-evidence-enable if you have to 
declare it under other branches. My understanding is that we have to deal with 
flat enumeration of capabilities, but I might be completely mistaken from the 
beginning...

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 16/07/2018, 08:55, "Xialiang (Frank, Network Integration Technology 
Research Dept)"  wrote:

Hi Diego,
Thanks for your quick comments. In general, we agree with you that they 
should be as the various capabilities to be applied.
But could you please clarify more about what is the difference to be as 
capability model vs yang grouping model definition?

Thanks!

B.R.
Frank

-邮件原件-
发件人: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com]
发送时间: 2018年7月16日 20:00
收件人: Dongyue (Yue, Network Integration Technology Research Dept) 
; i2nsf@ietf.org
    抄送: Xialiang (Frank, Network Integration Technology Research Dept) 

主题: Re: [I2nsf] 转发: New Version Notification for 
draft-dong-i2nsf-asf-config-00.txt

Hi,

My general comment to these definitions (and others that may come) is that 
we should try to deal with them in terms of capabilities, and not in terms of 
groupings associated to current (virtual or physical) devices. As an example, 
rather than thinking of "antivirus", I'd propose to think about "content 
analysis" or "content scanning" capabilities.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 16/07/2018, 07:02, "I2nsf on behalf of Dongyue (Yue, Network Integration 
Technology Research Dept)"  wrote:

Dear all,

The action part of the NSF-facing data model listed many security 
function actions, such as antivirus, ips, ids, and etc, that will be applid on 
traffic flow when the event and condition clauses are satisfied. However, I 
think it only list the corresponding names. And each type of the secuity 
function action (i.e. ips, antivirus, etc.) should have many selective profiles 
that could be executed. Therefore, we proposed a draft, 
draf-dong-i2nsf-asf-config-00, that specifies the configuration detail for each 
of the security function profile settings. And the NSF-facing data model is 
able to reference these profiles.

This -00 version of draft only contains the antivirus, ips, and 
anti-ddos profiles.

* Antivirus: The following figure shows the top-level tree diagram for 
antivirus profile settings. Each profile contains the configuration data for 
detection methods, detection configurations, signature exceptions, application 
exceptions, and the white lists configruations.

+--rw antivirus
   +--rw antivirus-enable
   +--rw profiles
  +--rw profile *  [name]
  +--rw name
  +--rw description
  +--rw collect-attack-evidence-enable
  +--rw sandbox-detection-enable
  +--rw heuristic-detection-enable
  +--rw detect*  [protocol]
  |  . . .
  +--rw exception-application* [application-name]
  |  . . .
  +--rw exception-signature*  [signature-id]
  |  . . .
  +--rw white-list
 . . .

* IPS: The following figure shows the top-level tree diagram for IPS 
profile settings. Each profile contains the configuratio

[I2nsf] 答复: 转发: New Version Notification for draft-dong-i2nsf-asf-config-00.txt

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi Diego,
Thanks for your quick comments. In general, we agree with you that they should 
be as the various capabilities to be applied.
But could you please clarify more about what is the difference to be as 
capability model vs yang grouping model definition?

Thanks!

B.R.
Frank

-邮件原件-
发件人: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com] 
发送时间: 2018年7月16日 20:00
收件人: Dongyue (Yue, Network Integration Technology Research Dept) 
; i2nsf@ietf.org
抄送: Xialiang (Frank, Network Integration Technology Research Dept) 

主题: Re: [I2nsf] 转发: New Version Notification for 
draft-dong-i2nsf-asf-config-00.txt

Hi,

My general comment to these definitions (and others that may come) is that we 
should try to deal with them in terms of capabilities, and not in terms of 
groupings associated to current (virtual or physical) devices. As an example, 
rather than thinking of "antivirus", I'd propose to think about "content 
analysis" or "content scanning" capabilities.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 16/07/2018, 07:02, "I2nsf on behalf of Dongyue (Yue, Network Integration 
Technology Research Dept)"  wrote:

Dear all,

The action part of the NSF-facing data model listed many security function 
actions, such as antivirus, ips, ids, and etc, that will be applid on traffic 
flow when the event and condition clauses are satisfied. However, I think it 
only list the corresponding names. And each type of the secuity function action 
(i.e. ips, antivirus, etc.) should have many selective profiles that could be 
executed. Therefore, we proposed a draft, draf-dong-i2nsf-asf-config-00, that 
specifies the configuration detail for each of the security function profile 
settings. And the NSF-facing data model is able to reference these profiles.

This -00 version of draft only contains the antivirus, ips, and anti-ddos 
profiles.

* Antivirus: The following figure shows the top-level tree diagram for 
antivirus profile settings. Each profile contains the configuration data for 
detection methods, detection configurations, signature exceptions, application 
exceptions, and the white lists configruations.

+--rw antivirus
   +--rw antivirus-enable
   +--rw profiles
  +--rw profile *  [name]
  +--rw name
  +--rw description
  +--rw collect-attack-evidence-enable
  +--rw sandbox-detection-enable
  +--rw heuristic-detection-enable
  +--rw detect*  [protocol]
  |  . . .
  +--rw exception-application* [application-name]
  |  . . .
  +--rw exception-signature*  [signature-id]
  |  . . .
  +--rw white-list
 . . .

* IPS: The following figure shows the top-level tree diagram for IPS 
profile settings. Each profile contains the configuration data for signature 
sets, signature exceptions, and protocol control.

+--rw ips-config
   +--rw ips-enable
   +--rw profiles
  +--rw profile*  [name]
  +  . . .
  +--rw domain-filter
  |  . . .
  +--rw signature-sets
  |  . . .
  +--rw exception-signatures
  |  . . .
  +--rw protocol-control
 +--rw dns-check
 | . . .
 +--rw http-check
   . . .

* Anti-ddos: The anti-ddos part contains the configruation of the alter 
rate and/or maximum speed/bandwidth to trigger the prevention functions for 
each type of DDoS attacks.

For more details, please review the draft: 
https://tools.ietf.org/html/draft-dong-i2nsf-asf-config-00

We would like to obatain comments from i2nsf WG. Is this draft valuable as 
an individual draft and will the NSF-facing data model reference these profiles?
We will appreciate all the comments from I2NSF WG.

Best Regards,
Yue

-邮件原件-
发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Dongyue (Yue, Network 
Integration Technology Research Dept)
发送时间: 2018年6月30日 15:11
收件人: i2nsf@ietf.org
抄送: Xialiang (Frank, Network Integration Technology Research Dept) 

主题: [I2nsf] 转发: New Version Notification for 
draft-dong-i2nsf-asf-config-00.txt

Dear All,

We have submitted a new draft about the nsf-facing interface data model for 
configuration of some advanced security functions including antivirus, 
antiddos, and ips. We will appreciate all comments.

Best Regards,
Yue

-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
发送时间: 2018年6月30日 15:06
收件人: Dongyue (Yue, Network Integration Technology Rese

[I2nsf] One comment on draft-ietf-i2nsf-sdn-ipsec-flow-protection-02:

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi authors,
In Section 5.2.1, to avoid exposure of other nodes once one node is 
compromised, key materials for each pair must be different and irreversible, 
this may cause performance issue with controller with large network during 
initial setup and rekey.

So, to distribute some of the SA key calculation to each device while still 
avoiding negotiation latency, the other options is that controller can send 
common key material to all NSFs, then NSF calculates actual SA key using the 
common key and known local, peer info. This way, both peers can generate Tx SA 
and Rx SA without negotiating with each other, also, the keys will be unique 
for each tunnel.

Will you consider this option?

Thanks!

B.R.
Frank
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 转发: I-D Action: draft-ietf-i2nsf-client-facing-interface-req-05.txt

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi all,
It is a new version of client-facing interface requirements, please review it 
and give your comments.

Many thanks!

B.R.
Frank

-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2018年5月28日 10:10
收件人: i-d-annou...@ietf.org
抄送: i2nsf@ietf.org
主题: I-D Action: draft-ietf-i2nsf-client-facing-interface-req-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions WG of 
the IETF.

Title   : Requirements for Client-Facing Interface to Security 
Controller
Authors : Rakesh Kumar
  Anil Lohiya
  Dave Qi
  Nabil Bitar
  Senad Palislamovic
  Liang Xia
Filename: draft-ietf-i2nsf-client-facing-interface-req-05.txt
Pages   : 24
Date: 2018-05-27

Abstract:
   This document captures requirements for Client-Facing interface to
   the Security Controller as defined by [RFC8327].  The interface is
   expressed using objects and constructs understood by Security Admin
   as opposed to vendor or device specific expressions associated with
   individual product and feature.  This document identifies a broad set
   of requirements needed to express Security Policies based on User-
   constructs which are well understood by the User Community.  This
   gives ability to decouple policy definition from policy enforcement
   on a specific security functional element, be it a physical or
   virtual.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-facing-interface-req-05


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] Hi, Linda and Yoav. A slot request for a new individual draft -- draft-rein-remote-attestation-nfv-use-cases-00:

[Xialiang (Frank, Network Integration Technology Research Dept)]

Hi Linda, Yoav,
We have an individual draft introducing the use cases for NSF's remote 
attestation mainly in NFV scenario.

I think it is currently in the working/discussion scope of I2NSF WG, like other 
2 drafts: draft-pastor-i2nsf-nsf-remote-attestation and 
draft-birkholz-i2nsf-tuda.

Can we request for a time slot of 10 minutes to present it and get comments 
from the group:

https://tools.ietf.org/html/draft-rein-remote-attestation-nfv-use-cases-00
(10 minutes)
presented by Frank Xia


Thanks a lot!

B.R.
Frank
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: Need a scribe (taking minutes) for Tues I2NSF WG session

[Xialiang (Frank)]

+1

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Susan Hares
发送时间: 2017年11月13日 18:12
收件人: Linda Dunbar ; i2nsf@ietf.org
主题: Re: [I2nsf] Need a scribe (taking minutes) for Tues I2NSF WG session

Linda:

I will take notes on etherpad.

Sue Hares

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, November 13, 2017 4:02 AM
To: i2nsf@ietf.org
Subject: [I2nsf] Need a scribe (taking minutes) for Tues I2NSF WG session


We need volunteers to take minutes for Tues I2NSF WG session. Greatly 
appreciate your time and contributions.

Thank you very much.

Linda & Yoav

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] Request for time slot://答复: IETF100 I2NSF WG Call for topics

[Xialiang (Frank)]

Hi I2NSF chairs,
We request 10 minutes time slot to present the 
draft-kumar-i2nsf-client-facing-interface-im-04.

Thanks!

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2017年10月31日 23:27
收件人: i2nsf@ietf.org; Yoav Nir
抄送: Kathleen Moriarty
主题: [I2nsf] IETF100 I2NSF WG Call for topics

I2NSF Participants:

We will be meeting at Tuesday afternoon 15:50-17:50 for 2 hours.

Our main objective of the meeting is to make progress of the Information models 
and data models for Consumer & NSF facing interfaces. With base information 
model draft 
draft-ietf-i2nsf-capability-00
 already adopted as WG draft, hopefully we can reach consensus for data models.

If you want to present at the IETF 100 I2NSF WG session, please send your 
proposed topic.

If you need to present remotely, please let us know as soon as possible.

Linda & Yoav

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: WG Adoption closed for draft-xibassnez-i2nsf-capability-02

[Xialiang (Frank)]

Hi chairs,
Ok, we will submit a new version soon.

Thanks!

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2017年9月28日 6:33
收件人: 'i2nsf@ietf.org'
抄送: draft-xibassnez-i2nsf-capabil...@ietf.org; Yoav Nir
主题: [I2nsf] WG Adoption closed for draft-xibassnez-i2nsf-capability-02

The WG Adoption call for 
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/ has lasted 
longer than the 2 weeks as many people were in summer vacation.

We believe that we got sufficient support for the draft. The 
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/ is now 
adopted to I2NSF WG draft.

Authors: please upload a new version with the title changed to 
draft-ietf-i2nsf-capability.

Thank you very much,

Linda & Yoav



From: Linda Dunbar
Sent: Wednesday, August 02, 2017 3:15 PM
To: 'i2nsf@ietf.org' >
Cc: 
draft-xibassnez-i2nsf-capabil...@ietf.org;
 Yoav Nir >
Subject: WG Adoption call for draft-xibassnez-i2nsf-capability-02

I2NSF participants,

As I2NSF has completed the WGLC for the I2NSF Framework draft, the WG is ready 
to work on the information model and data model for both Consumer Facing and 
NSF Facing Interfaces.

We will first start the 2 weeks WG Adoption Call of  
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/

Please remember WG Adoption only means that the entire WG can contribute to the 
content of the draft.

Thanks,
Linda & Yoav.


___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: WG Adoption call for draft-xibassnez-i2nsf-capability-02

[Xialiang (Frank)]

Support.

As the author of this draft, I am not aware any IPR of it.

Thanks!

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2017年8月3日 4:16
收件人: 'i2nsf@ietf.org'
抄送: draft-xibassnez-i2nsf-capabil...@ietf.org; Yoav Nir
主题: [I2nsf] WG Adoption call for draft-xibassnez-i2nsf-capability-02

I2NSF participants,

As I2NSF has completed the WGLC for the I2NSF Framework draft, the WG is ready 
to work on the information model and data model for both Consumer Facing and 
NSF Facing Interfaces.

We will first start the 2 weeks WG Adoption Call of  
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/

Please remember WG Adoption only means that the entire WG can contribute to the 
content of the draft.

Thanks,
Linda & Yoav.


___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: WG Adoption call for draft-jeong-i2nsf-applicability-01

[Xialiang (Frank)]

Support adoption of this draft, which is a useful document to clarify the 
application of I2NSF protocol and IM/DM in different typical scenarios for NSF 
security policy management.

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2017年8月3日 4:27
收件人: 'i2nsf@ietf.org'
抄送: draft-jeong-i2nsf-applicabil...@ietf.org; Yoav Nir
主题: [I2nsf] WG Adoption call for draft-jeong-i2nsf-applicability-01


I2NSF participants,

As adopting applicability statements as WG Document is one of the deliverables 
for I2NSF WG, we will start the 2 weeks WG Adoption Call for  
https://datatracker.ietf.org/doc/draft-jeong-i2nsf-applicability/

Please remember WG Adoption only means that the entire WG can contribute to the 
content of the draft.

Thanks,
Linda & Yoav.


___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] On Information Models [Was: need some work to improve the consistency of I2NSF Information and data model: maybe a design team?]

[Xialiang (Frank)]

Hi all,
By following the principle of unified information model design, why not 
consider to have 2 individual drafts for each I2NSF interfaces? It’s logically 
reasonable and can avoid the draft being too long to read.

My 2 cents.

B.R.
Frank

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of John Strassner
Sent: Monday, July 17, 2017 7:54 PM
To: Adrian Farrel; John Strassner
Cc: i2nsf@ietf.org; Linda Dunbar
Subject: Re: [I2nsf] On Information Models [Was: need some work to improve the 
consistency of I2NSF Information and data model: maybe a design team?]

Hi Adrian,

I personally feel that information in RFC3444 is not as accurate as what is in 
our set of drafts.

Regarding the "one vs many information models", the argument is simple. One of 
the purposes of an information model is to define concepts of use to the 
managed environment. This is done using classes (to define generic concepts), 
attributes (to define salient characteristics of a class), and relationships 
(to define how one class is related to, or interacts with, other classes).

Now imagine that there are multiple information models that do this in 
different ways. This is not tenable. It is equivalent to someone trying to 
translate a foreign language using multiple dictionaries that have different 
definitions.

I have absolutely no objection to building multiple I-Ds that define different 
aspects of our work. However, they must relate to each other. Right now, we 
have multiple information model I-Ds that use various levels of specificity, 
and do not relate to each other. That is my objection.


regards,
John

On Mon, Jul 17, 2017 at 2:50 AM, Adrian Farrel 
> wrote:
Taking John's three points separately (and in reverse order)

3) Yes, traceability back from DM to IM is very valuable and is a strong should 
for the WG because the WG has decided that IMs are a deliverable.

2) I think we should lean very heavily on RFC3444 for our definition of IM and 
DM. This might not be consistent with every view of those terms, but it is what 
the IETF has consensus on and absent any changes across the OPS area, we should 
stick with it.

I am sure that the current documents can be improved to be clearer on what 
information is "in the model" and to separate out other interface-specific 
requirements, but that is "work in progress".

1) Consistency across models is important. As is coherence across the whole of 
the I2NSF space. And there will clearly be mapping of information at one 
interface to information at another interface. But I don't quite understand the 
"one IM versus many IMs" discussion. Arguably we could say that the whole 
universe has a single IM, but I think we can also agree that it is convenient 
to break out pieces so that our scope a field of vision is limited. The attempt 
here is to partition the IM into "information modules" that describe the 
information at each interface, and it is convenient to place these pieces 
(modules) in separate documents.

Does any of that help?

Adrian

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On 
Behalf Of John Strassner
Sent: 16 July 2017 18:36
To: Linda Dunbar; John Strassner
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] need some work to improve the consistency of I2NSF 
Information and data model: maybe a design team?

I cannot attend Prague due to family health issues.

That being said, I agree with Linda. I see three major problems:

   1) There should be one, and only one, information model.
a) It is great to have multiple contributions, but those contributions 
MUST be written to enhance the existing model, not propose a new one
   2) In general, some of the info models are not really **models** per se, but 
rather, requirements for models.
   3) In general, I cannot trace data model work back to the info model work.
   a) This is especially true for drafts that are trying to use or define 
policies

I propose that draft-xibassnez is used for our info model. This means that the 
other info model drafts SHOULD be restructured to add to that draft.

I propose that we wait on further data model draft definition until some people 
(I will help) on the design team can formulate guidelines and perhaps examples 
to properly derive data models from our info model.

regards,
John

On Fri, Jul 14, 2017 at 9:27 AM, Linda Dunbar 
> wrote:
Thanks to many people contributions. We now have many drafts on the information 
model and data model for I2NSF:

Information model:
draft-xibassnez-i2nsf-capability-02
draft-zhang-i2nsf-info-model-monitoring-04
draft-hyun-i2nsf-registration-interface-im-02
draft-kumar-i2nsf-client-facing-interface-im-03
draft-xia-i2nsf-security-policy-object-01

Data Model:
draft-hares-i2nsf-capability-data-model-03
draft-jeong-i2nsf-consumer-facing-interface-dm-02

Re: [I2nsf] Need volunteer for minutes taker for I2NSF WG session Tuesday 1:30pm -3:30pm

[Xialiang (Frank)]

I can do it, count me in.
--
夏靓 Frank
M:+86-13913840549/+86-18651800549
E:frank.xiali...@huawei.com
产品与解决方案-网络融合技术研究部
Products & Solutions-Network Integration Technology Research Dept
发件人：Linda Dunbar
收件人：i2nsf,
时间：2017-07-17 12:16:20
主题:[I2nsf] Need volunteer for minutes taker for I2NSF WG session Tuesday 1:30pm 
-3:30pm

We need volunteers for taking minutes of the I2NSF WG session. Please let us 
know if you can. Your effort is greatly appreciated!

Thank you very much.

Linda & Adrian
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] 答复: relationship between draft-hares-i2nsf-capability-data-model-03 & draft-kim-i2nsf-nsf-facing-interface-data-model-02? (was RE: Request for Timeslots in I2NSF WG Meeting

[Xialiang (Frank)]

Hi Paul,
Thanks for your clear clarification. I share the same idea with you.
Actually, in the latest draft-xibassnez-i2nsf-capability, we have separated 
capability and security policy information model distinctly.

So, my further question is what is the relationship between the capability DM 
draft and registration interface DM?

Thanks!

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Mr. Jaehoon Paul Jeong
发送时间: 2017年7月10日 23:21
收件人: Linda Dunbar
抄送: i2nsf@ietf.org; Adrian Farrel; skku_secu-brain_...@googlegroups.com
主题: Re: [I2nsf] relationship between draft-hares-i2nsf-capability-data-model-03 
& draft-kim-i2nsf-nsf-facing-interface-data-model-02? (was RE: Request for 
Timeslots in I2NSF WG Meeting

Hi Linda,
Here is the clarification between NSF-facing interface YANG data model and 
Capability YANG data model.

NSF-facing YANG data model is used to configure the rules of a policy into NSFs.
This YANG data model is a standard interface for Security Controller to 
manipulate NSFs
developed by various vendors.

Capability YANG data model is used to retrieve capability information of an NSF.
For example, after an NSF for network security control (i.e., firewall) 
inspects a packet and
needs an additional security function such as deep packet inspection (DPI),
it can ask Security Controller the location of such an additional security 
function and
the corresponding IT resources with the Capability YANG data model.

In summary, Capability YANG data model is used to query the capability 
information of
a requested NSF and NSF-facing YANG data model is used to configure the rules of
a policy (e.g., add/delete/update/read) based on an ECA paradigm.

Thus, since these two models have different purposes, I think that we need to 
have two YANG drafts.

Thanks.

Best Regards,
Paul

On Sat, Jul 8, 2017 at 8:24 AM, Linda Dunbar 
> wrote:
Paul and Sue:

You requested slots for both draft-hares-i2nsf-capability-data-model-03 & 
draft-kim-i2nsf-nsf-facing-interface-data-model-02.

The abstract of draft-kim-i2nsf-nsf-facing-interface-data-model-02 stated that 
the draft defines the data model for network security functions), such as 
network security control, content security control, and attack mitigation 
control,..

The draft-hares-i2nsf-capability-data-model-03 has specified the High-Level 
YANG for Network Security Control, Content Security Control and Attack 
Mitigation Control.

How are those two drafts related?  I have a vague memory that those two drafts 
are to be merged, are they?

Thank you very much,

Linda


From: Mr. Jaehoon Paul Jeong 
[mailto:jaehoon.p...@gmail.com]
Sent: Thursday, July 06, 2017 7:54 AM
To: Linda Dunbar >; 
Adrian Farrel >
Cc: i2nsf@ietf.org; 
skku_secu-brain_...@googlegroups.com
Subject: Request for Timeslots in I2NSF WG Meeting

Hi Linda and Adrian,
I would like to ask the timeslots for our 7 drafts as follows:

draft-hares-i2nsf-capability-data-model-03
- Presenter: Sue Hares
- Time: 10 min

draft-kim-i2nsf-nsf-facing-interface-data-model-02
- Presenter: Jaehoon Paul Jeong
- Time: 10 min

draft-jeong-i2nsf-consumer-facing-interface-dm-02
- Presenter: Jaehoon Paul Jeong
- Time: 10 min

draft-jeong-i2nsf-applicability-00
- Presenter: Jaehoon Paul Jeong
- Time: 15 min

draft-hyun-i2nsf-nsf-triggered-steering-03
- Presenter: Sangwon Hyun
- Time: 10 min

draft-hyun-i2nsf-registration-interface-im-02
draft-hyun-i2nsf-registration-interface-dm-01
- Presenter: Sangwon Hyun
- Time: 10 min

Thanks.

Best Regards,
Paul
--
===
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.p...@gmail.com, 
paulje...@skku.edu
Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf



--
===
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.p...@gmail.com, 
paulje...@skku.edu
Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] comments about I2NSF framework draft://答复: Progress with draft-ietf-i2nsf-framework-05

[Xialiang (Frank)]

Hi Adrian, I2NSFers,
I reviewed the latest draft again and thinks it's in a very good shape now. So, 
it can be a foundation for all the other drafts.

Of course, I also have some comments about it as below:
1. nits: P18 " Table 1: Subject Capability Index " should change to " Table 1: 
Packet Content Matching Capability Index ",  P19, " Table 2: Object Capability 
Index " should change to " Table 2: context matching Capability Index ";
2. Section 11 of Security Considerations: this section is a little bit simple 
without considering the possible threats like: unauthenticated connections 
between users and controller, and between controller and NSFs, DoS attacks from 
malicious users or NSFs, etc;
3. question: should section 7.3 move to the I2NSF gap analysis draft?
4. I think remote attestation function should be described as a part into the 
whole I2NSF framework;
5. Section 3.2, by my understanding, notification is just part of the monitor 
functions, such as: syslog, netconf. Is it necessary to divide them into two 
interfaces?

B.R.
Frank

-邮件原件-
发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Adrian Farrel
发送时间: 2017年5月19日 1:49
收件人: i2nsf@ietf.org
主题: [I2nsf] Progress with draft-ietf-i2nsf-framework-05

Hi WG,

I am about to do a document shepherd review prior to starting a WG last call. 
In conversation with Linda just now I think I spotted a few areas where I am 
going to make chunky suggestions for additional text, but overall the document 
looks sound.

If you care deeply about this work and haven't looked at the framework for a 
while, now would be a good time. Don't wait for WG last call.

Thanks,
Adrian



___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] comments to draft-xiabassnez-i2nsf-capability-01

[Xialiang (Frank)]

Hi Linda,
Thanks for your good comments here. As one of the co-authors, I try to give my 
replies as inline, more complements are anticipated from the other co-authors.

From: Linda Dunbar
Sent: Saturday, March 25, 2017 4:46 PM
To: John Strassner; Xialiang (Frank); Diego R. Lopez; i2nsf@ietf.org; Aldo 
Basile
Subject: comments to draft-xiabassnez-i2nsf-capability-01

John, Frank, Diego, and Aldo:

Thank you very much for the revision of the 
draft-xiabassnez-i2nsf-capability-01. I think the draft is structured really 
well, and describes a really good methodology for defining NSF capabilities. 
Very good work!

A few minor comments:
3.4.1 Network Security Capabilities
I think the section is mainly describing the Security Capabilities for traffic 
or flows traversing the network. I would think that "Network Security" is 
broader, which covers how to secure access to network elements as well, or 
encryption of links, management of secure keys, etc.
[Frank]: the line we draw between Network Security Capability and Content 
Security Capability is the network layer: the former is used for layer 1~4, the 
latter is used for layer 5~7, although there are some minor co-existence for 
them in layer 4. But basically, there two types of security capability can be 
divided by this mean clearly. So, my question is if we need a formal definition 
for them in the terminology draft?

3.4.2 Content Security Capabilities
Your draft stated that "Content Security" is at application layer. Can you give 
some examples? Is it about some specified content (such as URL, video, or 
something else) can't be accessed by some users?
How is "content" represented? Is it by an "Address"? Specific URL? Or special 
ID?

Should also reference the Section 4.3 which has more description.
[Frank]: see my above clarification. In layer 4~7, the content is represented 
no more by "Address", but by application layer metadata, such as: URL, file 
name, regular expressions of content, etc.
Figure 3 (Page 19):
are all those types of Rule (AuthenticationECAPolicyRule, 
AccoutingECAPolicyRule, ..) matched with the categories of "capabilities" 
described in Section 3.4?
Or all the "capabilities" listed under Section 3.4 are under the 
"SecurityECAPolicyRule"?

Figure 5 (Page 24):

The "event" in Figure 4 ( Page 22) are further classified as "user security 
event", "device security event", "system security event", and "Time security 
event".
But the "Condition" in Figure 5 are classified differently. What are the 
correlations between them? Is "UserSecurityCondition" mapped to 
"UserSecurityEvent"? how about the rest?
[Frank]: they are different and orthogonal. Event is "significant occurrences 
the NSF is able to react to", which is something happened to trigger the 
security policy's execution. But Condition is used during the process of 
security policy's execution to determine which actions will be applied.

What is the difference between "Packet Security Condition" and "Packet Payload 
Security condition"?
[Frank]: the former is for the packet header matching, the latter is for the 
packet payload matching.
Figure 6 (page 25):
Can "Apply Profile Action" apply to both "Ingress Action" and "Egress Action"?
[Frank]: both for each direction and both directions.

Thank you very much for putting together a good document to describe such 
complex subject very clearly.

Linda

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] questions to draft-xia-i2nsf-security-policy-object-00

[Xialiang (Frank)]

Hi Linda,
Please see my response inline:

From: Linda Dunbar
Sent: Saturday, March 25, 2017 4:46 PM
To: Xialiang (Frank); Linqiushi (Jessica, SCC)
Cc: i2nsf@ietf.org
Subject: questions to draft-xia-i2nsf-security-policy-object-00

Frank and QiuShi,

Is it possible add some examples on using those objects in a policy? Showing 
how those objects make policy description easier?
[Frank]: good point, we will update it in next version.

Use "Application Object" as an example, can you list some possible values for 
the "applicationCategory attribute"?  and demonstrate how those values are used?
[Frank]: see the following examples, and of course, will reflect them in the 
next version draft:

Application Object
|
+---applicationName
|
+---applicationCategorye.g., general, network application
|
+---applicationSubCategorye.g., search engine, electronic commerce
|
+---applicationTransmissionModele.g., client/server, peer-to-peer
|
+---applicationLabel  e.g., database, http-based
|
+---applicationRiskLevele.g., 5 risk levels





Is it valuable to include a recommended policy profile when those applications 
are located in different places? e.g. when those applications are migrated to a 
3rd party cloud dc, what are the recommended security policies to be applied to 
them?
[Frank]: I think these contents are valuable to clarify their usefulness. We 
will consider how to achieve this goal, maybe an appendix for it is appropriate.

B.R.
Frank

Thank you very much.

Linda


___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] I-D Action: draft-xibassnez-i2nsf-capability-00.txt

[Xialiang (Frank)]

Hi all,
Since draft-xibassnez-i2nsf-capability-00 actually is the -07 version of 
draft-xia-i2nsf-capability-interface-IM, and we believe this draft has 
specified the I2NSF capability information model all needed clearly, as well as 
solving all the related comments and inconsistence issues. At this stage, we 
request the WG to consider if it can be accepted as the WG draft for further 
improvement to be a solid base for other data model related drafts.

Thanks!

B.R.
Frank

> -Original Message-
> From: Xialiang (Frank)
> Sent: Tuesday, November 01, 2016 12:41 AM
> To: i2nsf@ietf.org
> Subject: FW: I-D Action: draft-xibassnez-i2nsf-capability-00.txt
> 
> Hi all,
> The update of draft-xia-i2nsf-capability-interface-IM-06 has been submit just
> now. According to previous discussion, we rename the draft to
> draft-xibassnez-i2nsf-capability-00.
> 
> This draft is a combination of draft-xia-i2nsf-capability-interface-IM-06 and
> draft-baspez-i2nsf-capabilities-00 with a consistent way.
> Please review it and give your comments, thanks!
> 
> B.R.
> Frank
> 
> -Original Message-
> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Tuesday, November 01, 2016 12:28 AM
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-xibassnez-i2nsf-capability-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title   : Information Model of NSFs Capabilities
> Authors : Liang Xia
>   John Strassner
>   DaCheng Zhang
>   Kepeng Li
>   Cataldo Basile
>   Antonio Lioy
>   Diego R. Lopez
>   Edward Lopez
>   Nicolas BOUTHORS
>   Luyuan Fang
>   Filename: draft-xibassnez-i2nsf-capability-00.txt
>   Pages   : 62
>   Date: 2016-10-31
> 
> Abstract:
>This draft aims at defining the concept of capability. Capabilities
>are data that unambiguously characterize NSFs (Network Security
>Functions). Their correct definition will ease all the management
>and automation that can be. Moreover, it allows the definition of
>Interfaces to manage NSFs.
> 
>This draft is the first trial to merge two previous existing drafts
>on NSFs capabilities [I-D.draft-baspez-i2nsf-capabilities-00] and on
>the capability interface [I-D.draft-xia-i2nsf-capability-interface-
>im-06]. Further work will be needed to homogenize all the concepts
>and incorporate the feedback that will result after its publication.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-xibassnez-i2nsf-capability-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] FW: I-D Action: draft-xibassnez-i2nsf-capability-00.txt

[Xialiang (Frank)]

Hi all,
The update of draft-xia-i2nsf-capability-interface-IM-06 has been submit just 
now. According to previous discussion, we rename the draft to 
draft-xibassnez-i2nsf-capability-00.

This draft is a combination of draft-xia-i2nsf-capability-interface-IM-06 and 
draft-baspez-i2nsf-capabilities-00 with a consistent way.
Please review it and give your comments, thanks!

B.R.
Frank

-Original Message-
From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, November 01, 2016 12:28 AM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-xibassnez-i2nsf-capability-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Information Model of NSFs Capabilities
Authors : Liang Xia
  John Strassner
  DaCheng Zhang
  Kepeng Li
  Cataldo Basile
  Antonio Lioy
  Diego R. Lopez
  Edward Lopez
  Nicolas BOUTHORS
  Luyuan Fang
Filename: draft-xibassnez-i2nsf-capability-00.txt
Pages   : 62
Date: 2016-10-31

Abstract:
   This draft aims at defining the concept of capability. Capabilities
   are data that unambiguously characterize NSFs (Network Security
   Functions). Their correct definition will ease all the management
   and automation that can be. Moreover, it allows the definition of
   Interfaces to manage NSFs.

   This draft is the first trial to merge two previous existing drafts
   on NSFs capabilities [I-D.draft-baspez-i2nsf-capabilities-00] and on
   the capability interface [I-D.draft-xia-i2nsf-capability-interface-
   im-06]. Further work will be needed to homogenize all the concepts
   and incorporate the feedback that will result after its publication.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-xibassnez-i2nsf-capability-00


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00

[Xialiang (Frank)]

Hi all,
Firstly, I fully support John’s argument that we should avoid using the 
“northbound/southbound” concept here, since they are recursive and cannot be 
specific.
Secondly, I like the idea from Rakesh of a clear classification for the I2NSF 
NSF-Facing interface, I think his current naming is ok, but we can maybe find 
more better names. In addition, I think “capability interface” and “programming 
interface” are also applied to the I2NSF Consumer-Facing Interface.

Thanks!

B.R.
Frank

发件人: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com]
发送时间: 2016年7月2日 15:40
收件人: John Strassner
抄送: Rakesh Kumar; Natale, Bob; Susan Hares; John Strassner; I2NSF@ietf.org; 
Xialiang (Frank); Dacheng Zhang; Linda Dunbar
主题: Re: [I2nsf] questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

On 2 Jul 2016, at 03:36 , John Strassner 
<john.sc.strass...@huawei.com<mailto:john.sc.strass...@huawei.com>> wrote:

Based on my understanding of “Capability Layer” as defined in the I2NSF, is the 
 controller southbound interface.  it is the interface from controller to 
Network Security Function (NSF/vNSF). Is that ok if we define southbound 
interface as set of interfaces with categorization along the functional line?
...


No, both Diego and I have argued that "northbound" and "southbound" should not 
be used.
Please look at the mail thread. In addition, a Controller can announce its 
capabilities, just
like an NSF can.



And I wholeheartedly support this idea of recursion. It is an essential part of 
any approach to a network functional moel.

Be goode,





regards,
John


From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar
Sent: Friday, July 01, 2016 4:06 PM
To: Natale, Bob; Susan Hares; DIEGO LOPEZ GARCIA; John Strassner
Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank); Rakesh Kumar; 
Dacheng Zhang; Linda Dunbar
Subject: Re: [I2nsf] questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

Based on my understanding of “Capability Layer” as defined in the I2NSF, is the 
 controller southbound interface.  it is the interface from controller to 
Network Security Function (NSF/vNSF).

Is that ok if we define southbound interface as set of interfaces with 
categorization along the functional line? Something like as following.

I2NSF Southbound Interfaces


  1.  Capability Interface: Interface to discover NSF/vNSF capability so that 
controller can determine whether a NSF is capable of enforcing a given policy. 
This could be either a query interface (controller queries from a NSF for 
specific functionality) or a report interface where each NSF sends its 
supported capabilities such as feature, scale, performance. The NSF state is 
not changed by this interface.
  2.  Programming Interface (or some other better name):  Interface used by 
controller to program a specific NSF to enforce a security policy. This might 
change the state of NSF if successful.
  3.  Notification Interface:  Interface used to send notification 
(event/alarm) by NSF to controller (if registered for). The controller may 
directly take an action based on the event. This is a report and registry 
interface. This does not change the state of NSF.
  4.  Telemetry Interface: Interface to get telemetry information from NSF. 
This could be query or report/registry interface. This does not change the 
state of NSF.

Any thoughts ?

Regards,
Rakesh

From: I2nsf <i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org>> on behalf 
of "Natale, Bob" <rnat...@mitre.org<mailto:rnat...@mitre.org>>
Date: Wednesday, June 29, 2016 at 9:38 PM
To: Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>, DIEGO LOPEZ GARCIA 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>, John 
Strassner <straz...@gmail.com<mailto:straz...@gmail.com>>
Cc: "I2NSF@ietf.org<mailto:I2NSF@ietf.org>" 
<I2NSF@ietf.org<mailto:I2NSF@ietf.org>>, "Xialiang (Frank)" 
<frank.xiali...@huawei.com<mailto:frank.xiali...@huawei.com>>, Dacheng Zhang 
<dacheng@alibaba-inc.com<mailto:dacheng@alibaba-inc.com>>, Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Subject: Re: [I2nsf] questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

I would have gone with John’s first definition of the Capability Layer below. 
It is not a case of reusing the defined term in the definition. The “Capability 
Layer” is a distinct concept from “Capability” and, as John’s first definition 
says, consists of “the set of capabilities” and remembering that “Capability” 
is already defined as “a set of features”.

Avanti,
BobN

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Wednesday, June 22, 2016 4:42 PM
To: DIEGO LOPEZ GARCIA 
<diego.r.lo...@telefonica.com<ma

[I2nsf] 答复: questions about some terminologies defined by draft-ietf-i2nsf-terminology-00

[Xialiang (Frank)]

Hi John,
My comments inline:

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 John Strassner
发送时间: 2016年6月19日 13:02
收件人: Linda Dunbar; John Strassner
抄送: I2NSF@ietf.org; Dacheng Zhang; DIEGO LOPEZ GARCIA 
(diego.r.lo...@telefonica.com); Susan Hares
主题: Re: [I2nsf] questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

Hi Linda,

these are two different questions:

> My thinking maybe too simplistic.
> I picture a “Controller” having two ports,
>  one port connecting to clients ..., interface from this port is “Service 
> layer interface”
> another port connecting to NSFs, the interface from this port is “capability 
> layer interface”.

I think this could be a bit ambiguous.

When I think of "southbound interface", I think of a programming interface. The 
Capability Layer Interface is not a pure programming interface; rather, it is 
an interface that advertises the set of functions available. It does not define 
how to program those functions.
[Frank]: About the programming interface, I think the capability interface does 
have this ability. The capability interface can program what security 
capabilities should be enabled and how they are used by 
“Event-Condition-Action” (ECA) modeling. In summary, we try to acquire a 
balance between making the controller to have the largest and most fine-grain 
control over NSFs and hiding the implementation details that cannot be 
standardized.

> What extra meaning does it carry with the wording “abstraction Layer” ?

from my last note, I posited that we did not have an abstraction **layer** - 
indeed, I'm not sure I know what that means. Rather, we have a **set of 
abstractions** (which are, of course, the capabilities, which represent a 
(sub)set of all possible features in the NSFs in a vendor-neutral way).

Here is the text of the last note; Diego and Dacheng liked the second of my 
proposed definitions.
[Frank]: For the following definitions, I personally think the first definition 
is more consistent, but I don’t oppose the second one if most of us think it’s 
better.


On 16 Jun 2016, at 15:05 , John Strassner 
> wrote:

Hi Dacheng,

I agree that "I2NSF system" is not well defined. Your definition is better, but 
it should apply for all NSFs (not 'the NSF'). In addition, the Capability Layer 
is not an abstraction layer, it a simply a collection of abstractions (the 
capabilities). So how about:

Capability Layer:  Defines the set of capabilities available to the 
Controller for the set of NSFs that the Controller manages.

or

Capability Layer:  Defines the set of features available to the Controller 
for the set of NSFs that the Controller manages.


On Fri, Jun 17, 2016 at 6:10 PM, Linda Dunbar 
> wrote:
John,

My thinking maybe too simplistic.
I picture a “Controller” having two ports,

-one port connecting to clients (which can be another domain controller 
or Overlay network controller), interface from this port is “Service layer 
interface”

-another port connecting to NSFs, the interface from this port is 
“capability layer interface”.

So I thought that the Service Layer interface is the North Bound interface to 
the Controller, the capability interface is the south bound to the controller.

What extra meaning does it carry with the wording “abstraction Layer” ?
Capability Layer: Defines an abstraction layer that exposes a set of {features 
that are available from a managed entity} of the I2NSF system.
Thank you.

Linda

From: John Strassner [mailto:straz...@gmail.com]
Sent: Thursday, June 16, 2016 12:58 AM
To: Linda Dunbar; John Strassner
Cc: Susan Hares; DIEGO LOPEZ GARCIA 
(diego.r.lo...@telefonica.com); 
I2NSF@ietf.org
Subject: Re: questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

HI Linda,

I don't see the conflict in the two definitions. If I substitute the first 
(within braces) into the second, I get:

Capability Layer: Defines an abstraction layer that exposes a set of {features 
that are available from a managed entity} of the I2NSF system.

When I look at the Charter's Capability Layer, I think we're still OK - the 
Charter "...specifies how to control and monitor NSFs at a functional 
level...", and Capabilities (the features that are available) are essential for 
planning how to control and monitor NSFs.

Features (i.e., capabilities) are independent of interface (northbound or 
southbound). Would you like us to add that point to the terminology I-D?

best regards,
John


On Wed, Jun 15, 2016 at 8:40 AM, Linda Dunbar 
> wrote:
Dear Authors:

The term “Capability Layer” defined by the “draft-ietf-i2nsf-terminology-00” 
carries different  meaning than the “Capability Layer” used by the I2NSF 
charter.