from:"Diego R. Lopez"

Re: [I2nsf] [IETF-115 I2NSF] Re-chartering Text and Slides

2022-11-07 Thread Diego R. Lopez

Hi,

Right. We support the re-chartering and are currently deploying I2NSF for
specific next-generation access services. Besides this, we believe the recently
proposed activity on secure routing and router security capabilities constitute
a path worth exploring, and I2NSF is an ideal place for that.

Be goode,

--
“Esta vez no fallaremos, Doctor Infierno”

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

e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>
Mobile: +34 682 051 091
-

On 7/11/22, 12:19, wrote:

Hi Linda,
Here is the Re-chartering Text and Slides for IETF-115 I2NSF Session.

I believe that Korea Telecom (KT), Telefonica, and China Mobile are willing
to support this re-chartering to deploy the I2NSF technology into their
networks.

Thanks.

Best Regards,
Paul
--
===
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
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<mailto:jaehoon.p...@gmail.com>
Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.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 confidential and privileged
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

Re: [I2nsf] Are people available for the I2NSF session to be held on Tuesday morning 9:30am-11:30? IETF 115 session swap for I2NSF

2022-11-05 Thread Diego R. Lopez

Hi Linda,

Not sure if I am still on time for this, but I’d really prefer to have the 
meeting on Tuesday. My flight back home is early on Friday, so this change 
would allow me to participate.

Be goode,

--
“Esta vez no fallaremos, Doctor Infierno”

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

e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>
Mobile: +34 682 051 091
-

On 28/10/22, 17:14,  wrote:

I2NSFers,

Our AD asks if we want to swap the I2NSF session in IETF115 to Tuesday 
9:30am-11:30m.

Are you all available?

Please let us know ASAP.

Linda


On 10/27/22, 4:27 PM, "Roman Danyliw"  wrote:

Hi!

I2NSF is currently schedule for the LAST session of IETF 115 on Friday.  I 
know that isn't a desirable time.  If I can pull it off, would it be acceptable 
to you for me to swap I2NSF into the Tuesday morning 0930 - 1130 slot (where 
JWP) is currently landed.

Let me know ASAP!

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 confidential and privileged 
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

Re: [I2nsf] Anyone interested in secure routing? Two new drafts for secure routing

2022-10-26 Thread Diego R. Lopez

Hi,

Do you intend to bring these drafts for discussion in the WG? From a first 
reading, I am under the impression that the document on atomic security 
functions might be connected with the capability model we discussed here, and 
with other related proposal we are currently analyzing.

Not that sure about the document on routing decisions, though it could become 
an interesting additional application of an extended security capability model.

Be goode,

--
“Esta vez no fallaremos, Doctor Infierno”

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

e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>
Mobile: +34 682 051 091
-

On 26/10/22, 09:19,  wrote:

Hi all,
We have some new ideas about secure routing, Secure routing is to meet the 
security transmission requirements of users and operators by taking the 
security capabilities of nodes as a factor in forming routing paths.
Here are two new drafts, one for the requirements of secure routing, the other 
for security atomic capabilities.

The cross field of security and routing, If you are interested in this topic, 
please let me know.

A new version of I-D, draft-chen-secure-routing-requirements-00.txt
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-chen-secure-routing-requirements-00.html

A new version of I-D, draft-chen-atomized-security-functions-00.txt
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-chen-atomized-security-functions-00.html

Best,
Meiling



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 confidential and privileged 
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

Re: [I2nsf] need more review and support to close the WGLC for draft-ietf-i2nsf-consumer-facing-interface-dm

2022-07-26 Thread Diego R. Lopez

Hi,

Regarding the level of detail, I think it is appropriate for allowing security 
vendors to build on it. My only concern could be the possibility of extending 
the model if more detail becomes required, but that comes with YANG factory 
settings…

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 26/7/22, 09:14, "I2nsf on behalf of Susan Hares" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
sha...@ndzh.com<mailto:sha...@ndzh.com>> wrote:

Paul - Thank you for your kind words!

WG members:

We should chat if you-all feel the same way as I do.  It is important for 
Roman, Yoav, and Linda to hear if you think we’ve got this level of detail 
right.  The customer facing interface data model is a new concept in creating 
something that a certain class of security vendors can build on.

Do you think we got it correctly?  I’m a co-author so – I’m biased.  This yang 
model could be a lot more detailed or less detailed.

Would it help to discuss specifics or have you heard enough?  Either way Roman, 
Yoav, and Linda need to hear about it.

Thanks!
Sue



From: Mr. Jaehoon Paul Jeong 
Sent: Tuesday, July 26, 2022 9:07 AM
To: Susan Hares 
Cc: Roman Danyliw ; Linda Dunbar ; 
Yoav Nir ; i2nsf@ietf.org; skku-iotlab-members 
; Mr. Jaehoon Paul Jeong 

Subject: Re: [I2nsf] need more review and support to close the WGLC for 
draft-ietf-i2nsf-consumer-facing-interface-dm


Sue,
Thanks for your thorough review and evaluation on the Consumer-Facing Interface 
YANG Data Model:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-22

As Sue said, the YANG module of this Consumer-Facing Interface data model has 
been proved
through many IETF I2NSF hackathon projects.
This time my SKKU team demonstrated the mature functionality of Security Policy 
Translator
over this Consumer-Facing Interface YANG data model.

- Slides of IETF-114 I2NSF Hackathon Project
  
https://github.com/IETF-Hackathon/ietf114-project-presentations/blob/main/IETF114-I2NSF-Hackathon-Project-20220724.pdf

- Github Repository of IETF-114 I2NSF Hackathon Project
  https://github.com/jaehoonpaul/i2nsf-framework/tree/master/Hackathon-114/react

- Demo Video Clip of IETF-114 I2NSF Hackathon Project
  https://www.youtube.com/watch?v=_y6xLtUXBzw

I believe that this draft is ready to move toward the IESG evaluation.

Thanks.

Best Regards,
Paul

On Tue, Jul 26, 2022 at 7:56 AM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Linda and I2NSF:

Review of draft-ietf-i2nsf-consumer-facing-inteface-dm.

Status: Ready to publish

Textual Comments:  The write-up for this data model has excellent clarity in 
the English text.
Review Question: Right level of detail?  Yes – Excellent choices on detail.

One of the questions from the Security Ads have asked about this model is 
whether the level of detail in this model is sufficient.  My review of this 
model is that it hits a good balance for a consumer-facing model.  The 
challenge in the customer-facing model is to provide enough information to 
handle the grouping of information into a common set of primitives.   This 
group appears to be at the right level of detail.

Most of the I2NSF enabled security devices are network security devices that 
have a combination of functions (routing, firewall, accounting) as part of 
network access and control.  These devices will be found on the edge of network 
provider or within enterprise networks.  If these devices are successful there, 
this technology could move toward data centers.  However, IMHO I do not thing 
that will be first.

The Yang module for the customer interface is a challenging creation because it 
must be specific enough to group the information but leave some flexibility to 
be tailored for different deployments.  From my experience in creating a 
routing/switch/firewall, this appears to have the right balance.

Yang module checks:  All my manual check on this Yang module did not find a 
problem.  I did not run it through automatic checks.

Note for AD:  Several of the original reviews for this module included reviews 
of the hackathon code with feedback.  I have been aware of the hackathon early 
results.  I believe several people gave early feedback based on the prototypes. 
  If you did not see list discussion, it was because the discussions occurred 
in review of prototype code.

I hope this helps.

Sue Hares



From: I2nsf mailto:i2nsf-boun...@ietf.org>> On Behalf 
Of Linda Dunbar
Sent: Tuesday, July 12, 2022 1:17 PM
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: [I2nsf] need more review and support to close the WGLC for 
draft-ietf-i2nsf-consumer-facing-interface-dm


I2NF WG,

draft-ietf-i2nsf-consumer-facing-interface-dm WGLC was inconclusive due to lack

Re: [I2nsf] need more review and support to close the WGLC for draft-ietf-i2nsf-consumer-facing-interface-dm

2022-07-25 Thread Diego R. Lopez

Hi Sue,

Good to know you’ll make it, and looking forward to seeing you again!

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 25/7/22, 15:35, "I2nsf on behalf of Susan Hares" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
sha...@ndzh.com<mailto:sha...@ndzh.com>> wrote:

Paul and Linda:

I apologize for my delayed response.  I needed to go be tested for COVID-19 
before traveling to IETF-114.  I tested negative so I am coming to IETF.

I will not be able to come to IETF until Tuesday evening.  I will be attending 
I2NSF remotely from the airport.  You do not need to save time on the agenda 
for me.  I’ll talk to Paul and Diego directly.

I will provide the full review by early morning on Tuesday.

Sue

From: Mr. Jaehoon Paul Jeong 
Sent: Friday, July 22, 2022 12:14 PM
To: Susan Hares 
Cc: Linda Dunbar ; Mr. Jaehoon Paul Jeong 
; i2nsf@ietf.org
Subject: Re: [I2nsf] need more review and support to close the WGLC for 
draft-ietf-i2nsf-consumer-facing-interface-dm


Hi Sue,
Do you have any comments on Consumer-Facing Interface YANG Data Model Draft?

Thanks.

Best Regards,
Paul

2022년 7월 15일 (금) 오후 5:17, Susan Hares 
mailto:sha...@ndzh.com>>님이 작성:
Linda:

Just to let you know, this review will into come until Monday.

I have been overwhelmed by my work with the IDR WG – so my plans for this week 
went out the window.

Sue

From: I2nsf mailto:i2nsf-boun...@ietf.org>> On Behalf 
Of Linda Dunbar
Sent: Tuesday, July 12, 2022 1:17 PM
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: [I2nsf] need more review and support to close the WGLC for 
draft-ietf-i2nsf-consumer-facing-interface-dm


I2NF WG,

draft-ietf-i2nsf-consumer-facing-interface-dm WGLC was inconclusive due to lack 
of support and some LC comments not properly addressed. There appeared to be 
limited reviews of the document during the WGLC
See the discussion history: [I2nsf] WGLC for 
draft-ietf-i2nsf-consumer-facing-interface-dm-16<https://mailarchive.ietf.org/arch/msg/i2nsf/MFOohjnJ9fbylLB9eyccMRhrp04/>

To proceed to publication more reviews and support from the WG for publication 
is needed.
We really appreciate more people reviewing the document, especially the people 
who are not the authors.

Thank you
Linda Dunbar
___
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf
--
===
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
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<mailto:jaehoon.p...@gmail.com>
Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.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 confidential and privileged 
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

Re: [I2nsf] IETF 114 I2NSF agenda uploaded

2022-07-21 Thread Diego R. Lopez

Hi,

I will be in Philadelphia as well, arriving this Friday evening and staying for 
the whole week. And happy to talk with you on the issue!

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 21/7/22, 01:07, "Susan Hares" mailto:sha...@ndzh.com>> 
wrote:

Paul:

Thank you for the generous offer.   Let me check with my co-authors.

Sue

From: Mr. Jaehoon Paul Jeong 
Sent: Wednesday, July 20, 2022 6:35 PM
To: Susan Hares 
Cc: Diego R. Lopez ; Linda Dunbar 
; Mr. Jaehoon Paul Jeong ; 
i2nsf@ietf.org; skku-iotlab-members 
Subject: Re: [I2nsf] IETF 114 I2NSF agenda uploaded


Sue,
I will attend the IETF 114 on site, so I will be available
for the meeting with your BGP authors.
Please let me know the time and place for our meeting.

Thanks.

Best Regards,
Paul

2022년 7월 21일 (목) 오전 7:23, Susan Hares 
mailto:sha...@ndzh.com>>님이 작성:
Paul and Diego:

Let me know if you have time to chat.  If you are attending IETF in person, we 
can chat in-person.  The 4 authors for the BGP will be at IETF-14 in person 
(Mahesh, Sue, Keyur, Jeff).

If you are not attending in person, we’ll set-up a teleconference (zoom, etc.. )

Linda – We may be able to take this off the agenda.

Sue

From: Diego R. Lopez 
mailto:diego.r.lo...@telefonica.com>>
Sent: Wednesday, July 20, 2022 11:48 AM
To: Mr. Jaehoon Paul Jeong 
mailto:jaehoon.p...@gmail.com>>; Susan Hares 
mailto:sha...@ndzh.com>>
Cc: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>; skku-iotlab-members 
mailto:skku-iotlab-memb...@googlegroups.com>>
Subject: Re: [I2nsf] IETF 114 I2NSF agenda uploaded


Hi,

I totally concur with Paul here. We have some experience in applying RFC 9061 
in different scenarios and would be more than happy to explore its 
applicability in this case as well.

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 20/7/22, 17:38, "I2nsf on behalf of Mr. Jaehoon Paul Jeong" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:

Hi Sue,
I have much interest in your proposed item.
I think the following RFC 9061 can be used for the IPsec interface for BGP over 
IPsec.

- RFC 9061: A YANG Data Model for IPsec Flow Protection Based on 
Software-Defined Networking (SDN)
https://datatracker.ietf.org/doc/html/rfc9061

We can regard BGP routers as NSFs, and we can run either IKE or IKE-less 
approach in RFC 9061.
We can also extend the approach in RFC 9061 so that it can accommodate BGP 
message exchanges
(e.g., AS-PATH and NEXT-HOP attributes).

I will investigate RFC 9061 more to see whether my comments are correct or not.

Thanks.

Best Regards,
Paul

On Wed, Jul 20, 2022 at 8:55 PM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Linda:

I apologize for being unclear.  We ran into a few problems with trying to 
complete the BGP Yang model in the area of IPsec links.   BGP runs over TCP 
over IPsec links in some scenarios.  When creating the modeling, it was unclear 
which Yang modules were targeted to support this feature.

What I need is advice from the I2NSF and the IPSECME on the place to ask for 
work additions to support BGP peers.

The scenario is between two BGP routers. The type of IPsec connections between 
BGP routers can be:

• within a trusted cloud (same administrative domain, same trust cloud),

• across a physically secure private link,

• across the open Internet (where attacks happen).

The key is we want to configure and monitor the IPsec link.

As BGP co-authors looked at this, I did not understand which group to ask help 
from.  I volunteered to  ask for help.

If you or anyone can point me to where to go without taking valuable WG time, 
it would be great.  If you need me to explain more on email, I’d be glad to.

Rather than just pose this question from the Mike-line, I thought I’d ask ahead 
of time.

Cheers, sue

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Tuesday, July 19, 2022 6:09 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: RE: IETF 114 I2NSF agenda uploaded


Sue,

Are you talking about IPsec between two trusted nodes?
Something different from the IPsecme WG?

Linda

From: Susan Hares mailto:sha...@ndzh.com>>
Sent: Tuesday, July 19, 2022 3:00 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: RE: IETF 114 I2NSF agenda upl

Re: [I2nsf] IETF 114 I2NSF agenda uploaded

2022-07-20 Thread Diego R. Lopez

Hi,

I totally concur with Paul here. We have some experience in applying RFC 9061 
in different scenarios and would be more than happy to explore its 
applicability in this case as well.

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 20/7/22, 17:38, "I2nsf on behalf of Mr. Jaehoon Paul Jeong" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:

Hi Sue,
I have much interest in your proposed item.
I think the following RFC 9061 can be used for the IPsec interface for BGP over 
IPsec.

- RFC 9061: A YANG Data Model for IPsec Flow Protection Based on 
Software-Defined Networking (SDN)
https://datatracker.ietf.org/doc/html/rfc9061

We can regard BGP routers as NSFs, and we can run either IKE or IKE-less 
approach in RFC 9061.
We can also extend the approach in RFC 9061 so that it can accommodate BGP 
message exchanges
(e.g., AS-PATH and NEXT-HOP attributes).

I will investigate RFC 9061 more to see whether my comments are correct or not.

Thanks.

Best Regards,
Paul

On Wed, Jul 20, 2022 at 8:55 PM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Linda:

I apologize for being unclear.  We ran into a few problems with trying to 
complete the BGP Yang model in the area of IPsec links.   BGP runs over TCP 
over IPsec links in some scenarios.  When creating the modeling, it was unclear 
which Yang modules were targeted to support this feature.

What I need is advice from the I2NSF and the IPSECME on the place to ask for 
work additions to support BGP peers.

The scenario is between two BGP routers. The type of IPsec connections between 
BGP routers can be:

· within a trusted cloud (same administrative domain, same trust cloud),

· across a physically secure private link,

· across the open Internet (where attacks happen).

The key is we want to configure and monitor the IPsec link.

As BGP co-authors looked at this, I did not understand which group to ask help 
from.  I volunteered to  ask for help.

If you or anyone can point me to where to go without taking valuable WG time, 
it would be great.  If you need me to explain more on email, I’d be glad to.

Rather than just pose this question from the Mike-line, I thought I’d ask ahead 
of time.

Cheers, sue

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Tuesday, July 19, 2022 6:09 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: RE: IETF 114 I2NSF agenda uploaded


Sue,

Are you talking about IPsec between two trusted nodes?
Something different from the IPsecme WG?

Linda

From: Susan Hares mailto:sha...@ndzh.com>>
Sent: Tuesday, July 19, 2022 3:00 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: RE: IETF 114 I2NSF agenda uploaded

Linda:

In the recharter discussion, is it appropriate to ask about specific items such 
as additions to ipsec work in I2NSF?
I do not have a draft for this work.

Sue

From: I2nsf mailto:i2nsf-boun...@ietf.org>> On Behalf 
Of Linda Dunbar
Sent: Tuesday, July 19, 2022 3:44 PM
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: [I2nsf] IETF 114 I2NSF agenda uploaded


I2NSF WG,

Here is the agenda for next week’s I2NSF session (Tuesday).

https://datatracker.ietf.org/doc/agenda-114-i2nsf/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fagenda-114-i2nsf%2F=05%7C01%7Clinda.dunbar%40futurewei.com%7C8b5d4da98b89456a579d08da69c1548c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637938576342441642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C=N040a56pN%2BLVElz5IOt4jddwoHRH1pKTpTkAPMhd%2BD4%3D=0>

Please let me know if I miss anything.

Thank you.
Linda
___
I2nsf mailing list
I2nsf@ietf.org<mailto: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 confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message

Re: [I2nsf] any topics to discuss at the I2NSF session in IETF114?

2022-07-18 Thread Diego R. Lopez

Hi Linda,

I think we should have a final discussion on the rechartering proposal and see 
whether this rechartering will happen. I guess you already had this in your 
list, but just in case…

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 18/7/22, 05:18, "I2nsf on behalf of Linda Dunbar" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> wrote:

Dear I2NSF participants,

I2NSF has a One hour slot on Tuesday (13:30-14:30 EST) during IETF114.
Please let us know if you have any topics to discuss during IETF114.

Thank you
Linda & Yoav



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 confidential and privileged 
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

Re: [I2nsf] I2NSF WG status update

2022-05-18 Thread Diego R. Lopez

Definitely agree with Paul on the session request! We have been discussing the
way to make a more focused proposal for the re-chartering…

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<mailto:diego.r.lo...@telefonica.com>
Mobile: +34 682 051 091
--

On 18/05/2022, 15:56, "I2nsf on behalf of Mr. Jaehoon Paul Jeong"
mailto:i2nsf-boun...@ietf.org> on behalf of
jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:

Hi Linda,
Thanks for the announcement of the updates for I2NSF WG.

draft-ietf-i2nsf-nsf-monitoring-data-model-18 is under "Approved-announcement
to be sent::AD Followup".
The approval announcement will be done today or tomorrow.

draft-ietf-i2nsf-registration-interface-dm-16 has the Document Shepherd Writeup
be ready:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/shepherdwriteup/

draft-ietf-i2nsf-consumer-facing-interface-dm-19 has been posted today and its
Shepherd Writeup will be posted
since Linda has the writeup to post.
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/

As you said, we need to continue the discussion on the mailing list
to make the objectives align with the expertise of the contributors.

I feel that we need a session at IETF 114 to finalize the proposal
to have a handful of WG items for the next step in I2NSF.

Thanks for your leadership and support for our WG work.

Best Regards,
Paul

On Wed, May 18, 2022 at 5:49 AM Linda Dunbar
mailto:linda.dun...@futurewei.com>> wrote:
I2NSF WG participants:

Yesterday I2NSF WG reached a big milestone with 2 RFCs being approved by IESG
for publication. Many thanks to the WG and authors for the tireless work in
addressing all the comments along the way. It has been a long process.

The IESG has approved the following document:
- 'I2NSF Capability YANG Data Model'
(draft-ietf-i2nsf-capability-data-model-31.txt) as Proposed Standard

The IESG has approved the following document:
- 'I2NSF Network Security Function-Facing Interface YANG Data Model'
(draft-ietf-i2nsf-nsf-facing-interface-dm-27.txt) as Proposed Standard

In addition, the draft-ietf-i2nsf-nsf-monitoring-data-model-18 has got enough
support from IESG review to move forward, now waiting for our AD Roman’s final
review.

The authors have requested WG LC for the following two I2NSF WG drafts:
draft-ietf-i2nsf-consumer-facing-interface-dm-18
draft-ietf-i2nsf-registration-interface-dm-16

I2NSF Chairs will complete the Shepherd review this week, request early review
from Ops/Sec Directorates, and issue the WGLC.

At IETF 113, we discussed re-chartering proposal. Some people felt that the
scope of work proposed is exceeding the expertise of the participants. We need
to continue the discussion on the mailing list to make the objectives align
with the expertise of the contributors.

Do people feel that we need a session at IETF114 to finalize the proposal?

Thanks, Linda
___
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] Request for Comments, Interest and Support in I2NSF Re-Chartering

2022-03-24 Thread Diego R. Lopez

Hi,

I think I have expressed my opinion several times, on the list and at the WG
meeting, but just for the record let me express my support for the
re-chartering. It is ambitious but, as I mentioned during the meeting, we plan
to base our work in many existing results, and I think it is achievable, and
interesting to us as network operators.

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<mailto:diego.r.lo...@telefonica.com>
Mobile: +34 682 051 091
--

On 24/03/2022, 08:39, "Mr. Jaehoon Paul Jeong"
mailto:jaehoon.p...@gmail.com>> wrote:

Hi I2NSF WG,
As you know, our I2NSF WG will discuss the I2NSF Re-Chartering
at IETF-113 I2NSF WG Session today.

I attach the text of the re-chartering as pdf and txt files.

Our five core I2NSF YANG data model drafts are almost completed.

1. Capability YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-27

2. NSF-Facing Interface YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-22

3. Monitoring Interface YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-16

4. Consumer-Facing Interface YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-17

5. Registration Interface YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-15

The three of them (i.e., 1, 2, and 3) got the feedback of the IESG and
the revisions have been sent to the IESG reviewers.

The remaining two (i.e., 4, 5) are well-synchronized with the others.
I will present the updates of them today's I2NSF WG.
I attach the slides for them for your easy checking.

Our AD Roman has concerns about the low energy of our I2NSF WG for the new
work items in the I2NSF Re-chartering.

Could you speak up your voice about your comments, interest, and support of our
I2NSF Re-Chartering?

See you online at IETF-113 I2NSF WG Session today.

Thanks.

Re: [I2nsf] Comments on re-chartering

2022-03-20 Thread Diego R. Lopez

Hi Roman,

Putting aside the most "philosophical" questions (though I strongly share 
Susan's view about the slow start of many of the YANG models), let me just 
share a reflection on the (I'd daresay evident) need for YANG modules related 
to security protocols. If the current proposed new charter for I2NSF is not 
appropriate to address need, would this imply that we should need a more 
radical re-chartering? Why would a different, new WG be required to deal with 
this goal?

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
Mobile:  +34 682 051 091
--

On 20/03/2022, 22:03, "I2nsf on behalf of Roman Danyliw" 
 wrote:

Hi Sue!

> -Original Message-
> From: I2nsf  On Behalf Of Susan Hares
> Sent: Sunday, March 20, 2022 3:12 PM
> To: Roman Danyliw ; i2nsf@ietf.org
> Subject: Re: [I2nsf] Comments on re-chartering
>
> Roman:
>
> May I ask a questions before answering your questions.

I don't have comprehensive data on any of these.  The datatracker likely 
has some of this information but it would take effort to extract.

> 1) How many security Yang models have been published?

My sense is that that the number of Yang models from the SEC area is low in 
in comparison to other areas.  Other areas do publish Yang modules on Sec 
related topics.

> 2) How long does it take Yang models approved in the security area?

I'm only tracking two data points -- I2NSF and RATS.  
https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/ was adopted 
by the RATS WG in January 2020 and reviewed by the IESG at the last 03/10/2022 
telechat.  If you count from the first individual draft -00, then the time 
starts at Jul 2018 (which was even before the first RATS BOF at IETF 103).

> 3) How many IETF yang models have been deployed?

I can't say.  For Yang module and most IETF work, there isn't a good sense 
of that answer in the aggregate.  My experience is that specific WGs have a 
better sense of implementations and adoption of their technologies.  Perhaps 
the I2NSF Yang module authors can give us a sense of adoption.

> 4) Does the small deployment for IETF yang models change the value of the
> model?

At the risk of getting philosophical, such a hypothetical question depends 
on your definition of value, who are the stakeholders, and desired payoff 
horizon this technology.

> The SEC-ADs sent this WG off to create Yang models.   Did you consider 
this
> in your review?

I definitely considered the existing I2NSF charter and the planned 
milestones before my review.

This WG was not so much sent off to create Yang models as, like every WG, 
approved with a specific scope, in this case making Yang models for a narrow 
scope.

> May I politely and respectfully suggest there are things about the 
standardizing
> Yang models that you have not asked about.
>
> The first stage of a yang model is joyous. You decide what goes in.   The
> second of getting a prototype yang model  implementation is hard work.  
The
> third stage of getting the model approved in the IETF environment is
> frustrating and painful.During the second and third stage, most WGs 
have
> trouble keeping up the energy - since it is all about the small details of
> Yang.

Help me understand how to read this progression as it relates to the I2NSF 
documents.  What didn't I ask?

> Tom Petch has been very helpful, but it is a long process to refactored
> structures in Yang.  Paul has done a tremendous job in both doing 
prototype
> implementations,  and working through the lengthy issues with the Yang
> models.   While completing those 5 models, Paul has run into many of the
> structural issues/debates inside Yang.

I couldn't agree with you more.  Paul and Tom have a done a tremendous and 
admirable job on the core I2NSF data models.

> Having struggle to incorporate yang models from IP-SEC into the BGP model
> (with my excellent co-authors),  may I suggest that even the IP-SEC models
> are just at the beginning from I2NSF.Maybe there are other IP-SEC Yang
> models outside of I2NSF.

The community would know better than me on what future work is needed to 
better manage security protocols, IPSec, or otherwise with Yang modules.  I 
don't see the I2NSF WG being the place to do that Yang work for security 
protocols in the general case.

Roman

> Sue
>
> -Original Message-
> From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Roman Danyliw
> Sent: Sunday, March 20, 2022 2:33 PM
> To: i2nsf@ietf.org
> Subject: [I2nsf]

Re: [I2nsf] Anyone will be coming to IETF 113?

2022-01-26 Thread Diego R. Lopez

Hi,

My current plans are to travel to Vienna, so I would be able to attend a F2F 
interim, but I totally understand the situation of those of you not able and/or 
willing to move, given the circumstances. I’d be more than happy to take part 
in a virtual interim.

As many of you know, I am working in a proposal for re-chartering the group, 
and I think we can discuss about it.

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 26/01/2022, 00:40, "Linda Dunbar" 
mailto:linda.dun...@futurewei.com>> wrote:

Looks like many of the proponents won’t be traveling to IETF 113. Since the 
IETF113 meeting slots are very limited due to hybrid meeting style, we can have 
a virtual interim meeting to discuss the initiatives.

Thanks, Linda & Yoav

From: yangpeng...@chinamobile.com 
Sent: Saturday, January 22, 2022 8:20 PM
To: Linda Dunbar ; i2nsf@ietf.org; Jaehoon (Paul) 
Jeong ; Diego R. Lopez 
Subject: Re: [I2nsf] Anyone will be coming to IETF 113?

Hi Linda，

I will attend the meeting online. I am revising the trust-enhanced-i2nsf draft 
for NSF-granularity remote attestation. We can discuss it then.


Penglin


From: Linda Dunbar<mailto:linda.dun...@futurewei.com>
Date: 2022-01-22 00:41
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>; Jaehoon (Paul) 
Jeong<mailto:paulje...@skku.edu>; 
yangpeng...@chinamobile.com<mailto:yangpeng...@chinamobile.com>; Diego R. 
Lopez<mailto:diego.r.lo...@telefonica.com>
Subject: [I2nsf] Anyone will be coming to IETF 113?
Paul, Diego, PengLin, and others,

You have proposed new work to I2NSF. Some of the content might have overlap 
with RATS WG. If you will be coming to IETF113, we can schedule an I2NSF 
session to discuss the work, the overlap and how to move forward the work.

Please let us know.

Linda



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

Re: [I2nsf] topic about draft-yang-i2nsf-trust-enhanced-i2nsf

2021-12-08 Thread Diego R. Lopez

Hi,

Many thanks for this. The integration of I2NSF with the recent results in the 
area of remote attestation is one of the aspects we wanted to consider in an 
I2NSF rechartering proposal we are finalizing and will share on the list soon. 
Actually, our ideas go along the following issues to improve the I2NSF approach 
to security function management:

  *   The automation of security management procedures, considering the 
integration with general automation and autonomic mechanisms, as defined by the 
OPS Area
  *   Mechanisms for guiding and verifying policy translation
  *   The implications for security management of recent developments:
 *   Remote attestation procedures
 *   Trusted and oblivious execution models
 *   Container-based virtualization approaches
 *   Quantum-safe crypto (PQC, QKD…)
 *   Distributed trust and execution infrastructures (along the work of 
DINRG and COINRG)
  *   An extended capability model, suitable for the above items

As you can imagine, we very much welcome this document and would be extremely 
interested in collaborating with you in developing it and the general approach 
to enhance trust in SFs managed through I2NSF.

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 02/12/2021, 04:46, "I2nsf on behalf of 
yangpeng...@chinamobile.com<mailto:yangpeng...@chinamobile.com>" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
yangpeng...@chinamobile.com<mailto:yangpeng...@chinamobile.com>> wrote:

Hi everyone,

This is Penglin Yang from China Mobile Research Institute.  Recently, we 
composed a document named  trust enhanced I2NSF and submitted to the I2NSF 
group. 
(https://datatracker.ietf.org/doc/draft-yang-i2nsf-trust-enhanced-i2nsf/) The 
motivation of this document is trying to use remote attestation technology to 
augment the security and to enhance the trustworthiness of NSF. In this 
document we illustrated the architecture of trsuted enhanced I2NSF and the 
relevant interfaces.

We sincerely welcome everyone to comment on this document. And if you are 
interested, we can work together to promote this idea to a better version.

BR
Penglin Yang
CMCC




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

Re: [I2nsf] Fwd: AUTH48 [AP]: RFC 9061 NOW AVAILABLE

2021-06-14 Thread Diego R. Lopez

Hi,

It looks reasonable to me, but I wonder whether in order to avoid the stacking 
of hyphenated qualifiers we could use:

A YANG Data Model for IPsec Flow Protection based on Software-Defined 
Networking (SDN)

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 14/06/2021, 09:24, "I2nsf on behalf of Rafa Marin-Lopez" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
r...@um.es<mailto:r...@um.es>> wrote:

Dear I2NSF WG members:

We have received a suggestion from the RFC editor about a possible change in 
the title:

Software-Defined Networking (SDN)-based IPsec Flow Protection —>

A YANG Data Model for Software-Defined Networking (SDN)-based IPsec Flow 
Protection

We think this is reasonable and it is inline with the document.

If you do not have any objection, we can apply this change. Any thoughts?

Best Regards.


Inicio del mensaje reenviado:

De: rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>
Asunto: Re: AUTH48 [AP]: RFC 9061 
 NOW AVAILABLE
Fecha: 10 de junio de 2021, 22:58:29 CEST
Para: r...@um.es<mailto:r...@um.es>, gab...@um.es<mailto:gab...@um.es>, 
fernando.perenig...@cud.upct.es<mailto:fernando.perenig...@cud.upct.es>
Cc: rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>, 
i2nsf-...@ietf.org<mailto:i2nsf-...@ietf.org>, 
i2nsf-cha...@ietf.org<mailto:i2nsf-cha...@ietf.org>, 
ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the 
following questions, which are also in the XML file.

1) 


2) 


3) 


4) 


5) 


6) 


7) 


8) 


9) 


10) 


11) 


Thank you.

RFC Editor/ap/jm

On 6/10/21 3:55 PM, rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org> 
wrote:

*IMPORTANT*

Updated 2021/06/10

RFC Author(s):
--

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.

Planning your review
-

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor
  that have been included in the XML file as comments marked as
  follows:

  

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors

  Please ensure that you review any changes submitted by your
  coauthors.  We assume that if you do not speak up that you
  agree to changes submitted by your coauthors.

*  Content

  Please review the full content of the document, as this cannot
  change once the RFC is published. Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of
  content are correctly tagged.  For example, ensure that 
  and  are set correctly.  See details at
  <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the
  formatted output, as generated from the markup in the XML file, is
  reasonable.  Please note that the TXT will have formatting
  limitations compared to the PDF and HTML.


Submitting changes
--

To submit changes, please reply to this email with one of the following,
using ‘REPLY ALL’ as all the parties CC’ed on this message need to see
your changes:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes.  Information about stream managers can be found in
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--

To approve your RFC for publication, please reply to this email s
tating that you approve this RFC for publication.  Please use ‘REPLY ALL’
as all the parties

Re: [I2nsf] I2NSF Re-chartering Text

2020-11-16 Thread Diego R. Lopez

 discussion in NETMOD and OPSAWG on event modeling*.
o A single document for remote attestation for I2NSF components, *based on the 
work of the RATS WG*.
o A single document for I2NSF on *container deployments*.

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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 16/11/2020, 10:52, "Diego R. Lopez" 
mailto:diego.r.lo...@telefonica.com>> wrote:

Hi,

The date does suit me reasonably. Thanks, Yoav!

I am not sure if I am counted as an author of the recharter proposal, but let 
me share with you a few suggested changes (highlighted in red and with asterisk 
around, in case you do not enjoy an HTML-enabled email reader:

Interface to Network Security Functions (I2NSF) provides security *function* 
vendors *users, and operators* with a standard framework and interfaces for 
cloud-based security services. I2NSF enables the enforcement of a high-level 
security policy, *expressed according to a user's perspective of the target 
network*. This security policy enforcement in I2NSF is a data-driven approach 
using NETCONF/YANG or RESTCONF/YANG, where a security policy is constructed 
*based on a YANG data model*.

The I2NSF framework consists of four components such as I2NSF User, Security 
Controller, Network Security Function (NSF), and Developer's Management System 
(DMS). The 2NSF User specifies a high-level security policy for a target 
network. The Security Controller *is aware of the capabilities of the attached 
NSFs, using them to build the security service(s) satisfying the policy 
expressed by the I2NSF User*. An NSF *provides a set of* specific security 
*capabilities* (e.g., firewalling, web filtering, packet inspection, 
DDOS-attack mitigation…), *applying* security policy rules. The DMS registers 
the capabilities of an NSF with the Security Controller.

The I2NSF framework has four interfaces such as Consumer-Facing Interface, 
NSF-Facing Interface, Registration Interface, and Monitoring Interface. 
Consumer-Facing Interface is used to deliver high-level security policies from 
the I2NSF User to the Security Controller. NSF-Facing Interface is used to 
deliver low-level security policies from the Security Controller to an NSF. The 
Registration Interface is used to register the capabilities of an NSF with the 
Security Controller. The Monitoring Interface is used to collect monitoring 
data from an NSF.

The goal of I2NSF is to define a set of software interfaces and data models of 
such interfaces for configuring, maintaining, and monitoring *NSFs in cloud 
environments, including NFV and edge deployments*. For security management 
automation in an autonomous security system, I2NSF needs to have a feedback 
control loop consisting of security policy configuration in an NSF, monitoring 
for an NSF, data analysis for NSF monitoring data, feedback delivery, and 
security policy augmentation/generation. For this security management 
automation, the I2NSF framework requires a new component to collect NSF 
monitoring data and analyze them, which is called I2NSF Analyzer. Also, the 
I2NSF framework needs a new interface to deliver feedback messages for security 
policy adjustment from I2NSF Analyzer to Security Controller.

I2NSF is vulnerable to inside and supply chain attacks since it trusts *NSF 
capability declarations as* provided by DMS, assuming that NSFs work 
*appropriately in all circumstances, as well as I2NSF User’s policy 
declarations and the actions of the Security Controller*. The registration of 
NSF capabilities, the *declaration* of a security policy from either the I2NSF 
User or *its enforcement by the* Security Controller, and the monitoring data 
from an NSF are assumed to be genuine and non-malicious. If one of such 
activities is malicious, the security system based on I2NSF may collapse. To 
prevent this malicious activity from happening in the I2NSF framework or detect 
the root of a security attack, all the activities in the I2NSF framework should 
be logged in either a centralized or decentralized (e.g., blockchain) way. 
Also, the *provenance and status* of the I2NSF components (i.e., I2NSF User, 
Security Controller, NSF, DMS, and I2NSF Analyzer) need to be verified by 
remote attestation.

Finally, the current YANG data models for the I2NSF interfaces *are designed on 
the basis of NSFs implemented as virtual machines, and therefore* they need to 
be redesigned for the case where I2NSF components are instantiated by 
containers.

The I2NSF working group's deliverables include:

o A single document for an extension of I2NSF framework for security management 
automation. This document will initially be produced for reference as a living 
list to track and record discussions: the working group may decide to not 
publish this documen

Re: [I2nsf] I2NSF Re-chartering Text

2020-11-16 Thread Diego R. Lopez

a 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<mailto:diego.r.lo...@telefonica.com>
Mobile:  +34 682 051 091
--

On 16/11/2020, 08:07, "Yoav Nir" 
mailto:ynir.i...@gmail.com>> wrote:

Does Thursday, December 3rd at 14:00 UTC work for everyone?

It’s 16:00 for me, 15:00 for much of Europe, 9:00 AM EST, 6:00 AM PST, and 
unfortunately, 23:00 in Seoul.

I’ll wait 24 hours before scheduling the meeting in case there are objections.

Yoav



On 16 Nov 2020, at 3:44, Mr. Jaehoon Paul Jeong 
mailto:jaehoon.p...@gmail.com>> wrote:

Hi Yoav,
I agree that we can schedule our online interim meeting on the week of the 29th 
/ first week of December.

Could you schedule such an interim meeting?

I believe that we can get more people to be engaged in the new I2NSF work items
other than the authors of the current I2NSF WG and individual drafts.
With those people, I hope our I2NSF WG can have more energy. :)

Thanks.

Best Regards,
Paul

On Mon, Nov 16, 2020 at 1:59 AM Yoav Nir 
mailto:ynir.i...@gmail.com>> wrote:
Hi, Paul

As Roman said in a separate email message, we can’t schedule a meeting during 
IETF week. It also requires two weeks notice, so it anyway can only be done on 
the week of the 29th / first week of December.

That’s not a bad thing: it will give people enough time to read the charter and 
form an opinion before coming to the meeting.

If and when we have this meeting, I think we need to get a good number (5 
maybe?) or people who are not authors and will commit to reviewing the proposed 
documents. I think it is very obvious that this working group has lost energy, 
and we wouldn’t want to take on more work unless there is a clear indication 
that there will be such energy going forward.

Yoav


On 15 Nov 2020, at 18:26, Mr. Jaehoon Paul Jeong 
mailto:jaehoon.p...@gmail.com>> wrote:

Hi Linda and Yoav,
Here is the text for I2NSF WG Re-chartering.
---
Charter for Working Group

Interface to Network Security Functions (I2NSF) provides security vendors with 
a standard framework and interfaces for cloud-based security services. I2NSF 
enables the enforcement of a high-level security policy of a user's perspective 
in a target network (e.g., cloud network and edge network). This security 
policy enforcement in I2NSF is a data-driven approach using NETCONF/YANG or 
RESTCONF/YANG where a security policy is constructed into an XML file based on 
a YANG data model.

The I2NSF framework consists of four components such as I2NSF User, Security 
Controller, Network Security Function (NSF), and Developer's Management System 
(DMS). I2NSF User specifies a high-level security policy for a target network 
(e.g., cloud network). Security Controller maintains the capability of an NSF 
and takes a security policy from I2NSF User for the enforcement of the 
corresponding security service. An NSF performs a specific security service 
(e.g., firewall, web filter, deep packet inspection, and DDOS-attack mitigator) 
according to a security policy rule. DMS registers the capability of an NSF 
with Security Controller.

The I2NSF framework has four interfaces such as Consumer-Facing Interface, 
NSF-Facing Interface, Registration Interface, and Monitoring Interface. 
Consumer-Facing Interface is used to deliver a high-level security policy from 
I2NSF User to Security Controller. NSF-Facing Interface is used to deliver a 
low-level security policy from Security Controller to an NSF. Registration 
Interface is used to register the capability of an NSF with Security 
Controller. Monitoring Interface is used to collect monitoring data from an NSF.

The goal of I2NSF is to define a set of software interfaces and data models of 
such interfaces for configuring, maintaining, and monitoring NSFs in Network 
Functions Virtualization (NFV) environments. For security management automation 
in an autonomous security system, I2NSF needs to have a feedback control loop 
consisting of security policy configuration in an NSF, monitoring for an NSF, 
data analysis for NSF monitoring data, feedback delivery, and security policy 
augmentation/generation. For this security management automation, the I2NSF 
framework requires a new component to collect NSF monitoring data and analyze 
them, which is called I2NSF Analyzer. Also, the I2NSF framework needs a new 
interface to deliver a feedback message for security policy adjustment from 
I2NSF Analyzer to Security Controller.

I2NSF is vulnerable to an inside attack and a supply chain attack since it 
trusts in NSFs provided by DMS, assuming that NSFs work for their security 
services appropriately. Also, I2NSF trusts in I2NSF User and Security 
Controller. The registration of an NSF's capability, the enforcement of a

Re: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)

2020-09-21 Thread Diego R. Lopez

Hi,

If I can shed a little bit more of light on the story, let me say the original 
capability model was based on a policy expression calculus suitable for 
manipulating high-level policy expressions, but not for a network management 
protocol. The data model evolved in parallel and, at a certain point, overtook 
the original information model. A couple of proposals for realignment were 
made, but they were reflected on the data model and not totally on the 
information model.

Given the historical context Sue mentions, the information model was implicitly 
withdrawn, having served its purpose of kickstarting the data model.

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/09/2020, 21:53, "I2nsf on behalf of Susan Hares"  wrote:

Eric:

Just a little bit of history - some of the past ADs suggested that 
informational models were optional.  Therefore, pushing forward with the 
information was difficult.

In this case, the information model was helpful in distilling the key 
components for a capability model.  If you wish additional history, please let 
me know.

Susan Hares

-Original Message-
From: Éric Vyncke via Datatracker [mailto:nore...@ietf.org]
Sent: Monday, September 21, 2020 5:19 AM
To: The IESG
Cc: draft-ietf-i2nsf-capability-data-mo...@ietf.org; i2nsf-cha...@ietf.org; 
i2nsf@ietf.org; Linda Dunbar; dunbar...@gmail.com
Subject: Éric Vyncke's Discuss on 
draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-i2nsf-capability-data-model-12: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/



--
DISCUSS:
--

Thank you for the work put into this document.

While I do appreciate that a data model (this document) is derived from an 
information model, I am concerned that the information model is an expired 
draft whereas I would expect the information model being published first. Else, 
what is the use of the information model ? What was the WG reasoning behind 
'putting the cart before the horses' ? My concern is that by publishing the 
YANG model, there is nearly no way to change the information model anymore.

Please find below a couple of non-blocking COMMENT points but also a couple 
of blocking DISCUSS points around IPv6. They should be easy to resolve. I would 
hate to have NSF having basic IPv6 capabilities that cannot be configured by 
using the YANG model of this document.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 4.1 --

It is quite common to apply conditions based on the whole IPv6 extension 
header chain (i.e., presence of destination option header or wrong order of the 
extension headers). Why is there no such capabilities in this YANG module ? The 
only one is 'identity ipv6-next-header' that applies only to the first 
extension header.

What is the difference between 'identity ipv6-protocol' and 'identity 
ipv6-next-header' ? There is no 'protocol' field in the IPv6 header.

While fragmented IPv4 packets are part of the conditions ('identity 
ipv4-fragment-flags'), there is no equivalent in IPv6.


--
COMMENT:
--

-- Section 4.1 --
May be am I misreading the YANG tree, but, I see no 'sctp-capability' in 
the set of 'condition-capabilities' (even is SCTP is not heavily used).

Is there a real reason to have two related containers ?
generic-nsf-capabilities and advanced-nsf-capabilities. Why not a single 
one ?

Unsure what is meant by 'range' in 'identity range-ipv*-address'. Usually, 
addresses are filtered/matched by using a prefix length and not a range (that 
is difficult to implement in hardware).

Is there a reason why ICMP(v6) codes are not part of the conditions ?




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




Este mensaje y sus

Re: [I2nsf] Side Meeting for I2NSF WG

2019-11-20 Thread Diego R. Lopez

Hi Paul,

Just to frame today’s discussion, let me remark I find especially interesting
points (3) and (4), that I believe can only happen within I2NSF. We can connect
(3) with the ECA discussions happening in OPSAWG and NMRG, and I see (4) as an
interesting opportunity for consolidating and achieving the full potential of
the capability model.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile: +34 682 051 091
--

On 21/11/2019, 11:02, "I2nsf on behalf of Mr. Jaehoon Paul Jeong"
mailto:i2nsf-boun...@ietf.org> on behalf of
jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:

Hi I2NSF WG,
There will be a side meeting for I2NSF WG's next steps from 6PM to 7PM today at
Bras Basah.
https://datatracker.ietf.org/meeting/106/floor-plan?room=bras-basah#raffles-city-convention-center

* Agenda for I2NSF Side Meeting
- I2NSF Hackathon Project Report (Jaehoon Paul Jeong, 5 min)
- I2NSF Data Model Drafts Update (Jaehoon Paul Jeong, 10 min)
. I2NSF Capability YANG Data Model
. I2NSF Consumer-Facing Interface YANG Data Model
. I2NSF Network Security Function-Facing Interface YANG Data Model
. I2NSF Registration Interface YANG Data Model
. I2NSF NSF Monitoring YANG Data Model
- Security Policy Translator Draft Update (Chaehong Chung, 5 min)
- Open Discussion: Possible Work Items for I2NSF Rechartering (30 min)

I will report the progress of data model drafts.
I would like to discuss the rechartering of I2NSF WG with you.

I suggest four work items as the 2nd phase I2NSF.
1. YANG data model of the interface between I2NSF Security Controller and SDN
Switch Controller
2. YANG data model of the interface between I2NSF Security Controller and SFC
Classifier
3. Configuration of Advanced Security Functions with I2NSF Security Controller
4. Policy Object for Interface to Network Security Functions (I2NSF)

Let me explain why each of them is important for I2NSF.

1. YANG data model of the interface between I2NSF Security Controller and SDN
Switch Controller
According to the I2NSF Applicability Draft and I2NSF Hackathon Project,
the SDN switches can perform simple packet filtering and the firewall NSF can
perform complicated packet filtering.
For this two separated packet filtering, the security policy about a traffic
flow should be delivered to an SDN Switch Controller.
For the delivery of a security policy to the SDN network, the interface between
the I2NSF Security Controller and
the SDN Switch Controller is needed.

2. YANG data model of the interface between I2NSF Security Controller and SFC
Classifier
According to the I2NSF Applicability Draft and I2NSF Hackathon Project,
a security policy (e.g., time-based web filtering) requires a Service Function
Chaining (SFC) such as
firewall and web filter.
For this SFC path specification of a security policy, a security about a
traffic flow should be delivered to an SFC Classifier.
For the delivery of a security policy to specify the service function path in
the SFC Classifier, the interface between
the I2NSF Security Controller and the SFC Classifier is needed.

3. Configuration of Advanced Security Functions with I2NSF Security Controller
(https://tools.ietf.org/html/draft-dong-i2nsf-asf-config-01)
With the current NSF-Facing Interface, we can configure basic security
functions, such as firewall, deep packet inspection, and
DDoS attack mitigator. For rich network security functions, the YANG data
model of advanced security services needs to be
developed.

4. Policy Object for Interface to Network Security Functions (I2NSF)
(https://tools.ietf.org/html/draft-xia-i2nsf-security-policy-object-01)
Policy objects for I2NSF security policy rules can provide the I2NSF system
with reusability for security policy construction
by defining essential attributes for each policy object. This will be useful
for security policy rule generation in the I2NSF system.

Welcome your feedback.

Thanks.

Best Regards,
Paul

Re: [I2nsf] WG scope follow-up

2019-07-30 Thread Diego R. Lopez

Hi,

I am not objecting to the work in the translating support techniques (what 
would be, in my opinion, the part of the work suitable to an IETF document), 
but to having it within a re-chartered I2NSF. I think those techniques should 
be general enough to constitute one of the essential aspects of the new work 
being considered for YANG, and therefore I’d like to see this activity directed 
there. You can count on my full support for that goal.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 28/07/2019, 16:08, "I2nsf on behalf of 양현식" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
yan...@dcn.ssu.ac.kr<mailto:yan...@dcn.ssu.ac.kr>> wrote:

+1
Hi. I am Hyunsik Yang. I joined I2NSF hackathon from IETF102 to IETF105  and I 
am an author of NFV draft.
I agree with Paul's opinion based on my experience of I2NSF Hackathon.
 In order to use I2NSF in a real environment, I think we should  provide a 
document for guidelines on how to use it in addition to the basic framework. 
Although the document couldn't reflect all use cases, I think we can provide a 
basic direction to user who use I2NSF Framework. Therefore,  security policy 
translator draft also can be a good guideline.
 In addition, from an implementation point of view, I think current interface 
is not enough since it only deal with internal interface. We also need to 
define additional interfaces or information model to use I2NSF in real world 
such as interface for VNFM and SFC controller. I knew that this is not part of 
the current I2NSF WG scope, but, if I2NSF WG is going to re-chartering phase, I 
think it is necessary to add those item to re-chartering.

2019. 7. 26. 오후 12:40, Mr. Jaehoon Paul Jeong 
mailto:jaehoon.p...@gmail.com>> 작성:

Hi Roman and I2NSF WG,
Though the system components of the I2NSF system (e.g., security policy 
translator) are not in the scope of
I2NSF WG, key components such as I2NSF User, Security Controller, and 
Developer's Management System (DMS)
need standard documents to let developers and operators grasp what information 
and parameters are required and
exchanged among those components.

Those documents can be published as Informational RFCs to provide the 
developers and operators with
the guidelines to build their own components interoperable with other 
components in the I2NSF system.

For an example, the security policy translation draft provides the audience 
with such guidelines
in terms of the design of implementation of their own security policy 
translator.
https://tools.ietf.org/html/draft-yang-i2nsf-security-policy-translation-04

To let the security policy translator perform security policy translation, it 
requires
the relationship between the consumer-facing interface and the nsf-facing 
interface data models.
This document explains such relationship (or mapping) between the two 
interfaces.
With the explicit representation of such a mapping, the developers need to 
figure it out.
It will be time-consuming and may mislead them.

It also explains what information (e.g., IP addresses of a user's devices and 
website URLs) should
be populated into the NSF database for security policy translation in the 
Security Controller.
This information needs to delivered from the I2NSF User to the Security 
Controller.
Assuming that the I2NSF User and the Security Controller are developed by two 
different operators and vendors,
an interface between them should be standardized for interoperability.
As said during today's WG session, this security policy translation draft will 
target at an Informational RFC.

For another example, the draft of I2NSF on NFV reference architecture provides 
the operators and
developers with the guidelines of how to build the I2NSF system on the NFV 
architecture.
https://tools.ietf.org/html/draft-yang-i2nsf-nfv-architecture-05

The draft explains the initial configuration procedure in NFV architecture.
When a proper NSF is not activated yet in the I2NSF system, the Security 
Controller
sends an NSF initiation request to the DMSs which has (or may have) the 
required NSF,
as shown in Figure 2 in the draft.
In this case, the DMS sends an NSF initiation request  to the VNF Manager 
(VNFM) using the Ve-Vnfm interface
that is an ETSI NFV interface. This DMS NSF initiation request should be 
specified by
the I2NSF system. This draft will describe the contents and format of the 
request in
the next revision. Thus, this will help the vendors and operators easily 
implement the I2NSF
in the NSF architecture.

During the last 9 I2NSF hackathon projects, my team recognized the necessity of
the drafts for the functionality and parameters of the I2NSF system components.
I believe that these drafts will acceler

Re: [I2nsf] WG scope follow-up

2019-07-25 Thread Diego R. Lopez

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

Re: [I2nsf] IPR Statements about I2NSF documents

2019-06-29 Thread Diego R. Lopez

Hi,

I have no objection to this new version of the statements.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 27/06/2019, 19:51, "I2nsf on behalf of Yoav Nir" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>> wrote:

Hi folks.

As you may have noticed, after some back-and-forth with the authors and their 
university, the IPR statements have been modified as follows:

OLD:
Reasonable and Non-Discriminatory License to All Implementers with Possible 
Royalty/Fee

NEW:
If this standard is adopted, Sungkyunkwan University (SKKU) will not assert any 
patents owned or controlled by SKKU against any party for making, using, 
selling, importing or offering for sale a product that implements the standard, 
provided, however that SKKU retains the right to assert its patents (including 
the right to claim past royalties) against any party that asserts a patent it 
owns or controls (either directly or indirectly) against SKKU or any of SKKU's 
affiliates or successors in title or against any products of SKKU or any 
products of any of SKKU's affiliates either alone or in combination with other 
products; and SKKU retains the right to assert its patents against any product 
or portion thereof that is not necessary for compliance with the standard. 
Royalty-bearing licenses will be available to anyone who prefers that option.


The new version is similar to the licensing terms in many IPR statements issued 
by other rights holders.  See for example https://datatracker.ietf.org/ipr/3591/

It is still up to the working group to decide if this is acceptable, and group 
members, especially those who raised objections previously, are encouraged to 
chime in.

We will raise this issue one more time at the meeting, just to make sure 
everyone has been heard from.

Thanks,

Linda & Yoav



On 6 Jun 2019, at 20:27, Yoav Nir 
mailto:ynir.i...@gmail.com>> wrote:

Hi

Yesterday we got 5 IPR statements ([1], [2], [3], [4], [5]) related to the 
following drafts respectively:
·
· draft-ietf-i2nsf-nsf-facing-interface-dm
· draft-ietf-i2nsf-nsf-monitoring-data-model
· draft-ietf-i2nsf-capability-data-model
· draft-ietf-i2nsf-registration-interface-dm
· draft-ietf-i2nsf-consumer-facing-interface-dm

All of these are WG documents, and one of them (the capability data model 
draft) is in WGLC.  See [6] and RFC 8179 for more information about IPR 
disclosures.

All the disclosures claim that the patents or patent applications mentioned may 
be necessary for implementation of the drafts. Neither the chairs nor anyone 
else in the IETF is considered competent to evaluate such claims or the 
validity of any patents, so I suggest that in this thread we avoid bringing 
this up. What may be concerning is that the licensing policy for these 
disclosures is "Reasonable and Non-Discriminatory License to All Implementers 
with Possible Royalty/Fee”, which makes such technologies problematic to many 
implementers, especially non-commercial ones.

To quote from section 7 of RFC 8179:

   In general, IETF working groups prefer technologies with no known IPR

   claims or, for technologies with claims against them, an offer of

   royalty-free licensing.  However, to solve a given technical problem,

   IETF working groups have the discretion to adopt a technology as to

   which IPR claims have been made if they feel that this technology is

   superior enough to alternatives with fewer IPR claims or free

   licensing to outweigh the potential cost of the licenses.


So this message is to start a discussion about how the I2NSF working group 
would like to handle this disclosure. Continuing as before and moving to 
publication is the default outcome of this discussion, but the WG is required 
to evaluate its position about these disclosures. This is what this thread is 
for.

Thanks,


Linda & Yoav

[1] https://datatracker.ietf.org/ipr/3553/
[2] https://datatracker.ietf.org/ipr/3557/
[3] https://datatracker.ietf.org/ipr/3556/
[4] https://datatracker.ietf.org/ipr/3555/
[5] https://datatracker.ietf.org/ipr/3554/
[6] https://www.ietf.org/standards/ipr/




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

Re: [I2nsf] IPR Statements about I2NSF documents

2019-06-08 Thread Diego R. Lopez

Hi,

Since I replied to this in another thread, let me remark again my position.

The terms stated in the claims concern me. If the claimer could change the 
terms into something similar to those in https://datatracker.ietf.org/ipr/2611/ 
that would clear my concerns.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 06/06/2019, 19:27, "I2nsf on behalf of Yoav Nir" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>> wrote:

Hi

Yesterday we got 5 IPR statements ([1], [2], [3], [4], [5]) related to the 
following drafts respectively:
·
· draft-ietf-i2nsf-nsf-facing-interface-dm
· draft-ietf-i2nsf-nsf-monitoring-data-model
· draft-ietf-i2nsf-capability-data-model
· draft-ietf-i2nsf-registration-interface-dm
· draft-ietf-i2nsf-consumer-facing-interface-dm

All of these are WG documents, and one of them (the capability data model 
draft) is in WGLC.  See [6] and RFC 8179 for more information about IPR 
disclosures.

All the disclosures claim that the patents or patent applications mentioned may 
be necessary for implementation of the drafts. Neither the chairs nor anyone 
else in the IETF is considered competent to evaluate such claims or the 
validity of any patents, so I suggest that in this thread we avoid bringing 
this up. What may be concerning is that the licensing policy for these 
disclosures is "Reasonable and Non-Discriminatory License to All Implementers 
with Possible Royalty/Fee”, which makes such technologies problematic to many 
implementers, especially non-commercial ones.

To quote from section 7 of RFC 8179:

   In general, IETF working groups prefer technologies with no known IPR

   claims or, for technologies with claims against them, an offer of

   royalty-free licensing.  However, to solve a given technical problem,

   IETF working groups have the discretion to adopt a technology as to

   which IPR claims have been made if they feel that this technology is

   superior enough to alternatives with fewer IPR claims or free

   licensing to outweigh the potential cost of the licenses.


So this message is to start a discussion about how the I2NSF working group 
would like to handle this disclosure. Continuing as before and moving to 
publication is the default outcome of this discussion, but the WG is required 
to evaluate its position about these disclosures. This is what this thread is 
for.

Thanks,


Linda & Yoav

[1] https://datatracker.ietf.org/ipr/3553/
[2] https://datatracker.ietf.org/ipr/3557/
[3] https://datatracker.ietf.org/ipr/3556/
[4] https://datatracker.ietf.org/ipr/3555/
[5] https://datatracker.ietf.org/ipr/3554/
[6] https://www.ietf.org/standards/ipr/



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

Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-capability-data-model

2019-06-08 Thread Diego R. Lopez

Hi,

I agree with Sue here. The current terms in 
https://datatracker.ietf.org/ipr/3556/  sound worrisome, as Paul noted as well. 
An approach like the one in https://datatracker.ietf.org/ipr/2611/ would 
certainly clear my concerns.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 07/06/2019, 23:51, "I2nsf on behalf of Susan Hares" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
sha...@ndzh.com<mailto:sha...@ndzh.com>> wrote:

As a co-author, I know of no other IPR other than IPR already disclosed.

None of my inputs to the capability data model draft had any IPR attached to it.

As to IPR on this draft, I would expect a more licensing statement such as 
included in the following IPR.
https://datatracker.ietf.org/ipr/2611/

The IPR terms rather than its existence is a challenge to me as I2NSF member 
and co-author.

Sue Hares

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, June 5, 2019 5:07 PM
To: i2nsf@ietf.org
Subject: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-capability-data-model

Hello Working Group,

This email starts a three weeks Working Group Last Call on  
draft-ietf-i2nsf-capability-data-model-04<https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-04>
  .
This poll runs until June 26, 2019.
   https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-04

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




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

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

2019-04-18 Thread Diego R. Lopez

Hi,

I am not aware of any IPRs related to this draft.

Together with one of my coauthors (Cataldo Basile), we are preparing an example 
to illustrate the use of the capability model, but this would be a sample not 
affecting by any means the technical content of the document, and therefore we 
don’t believe it should influence the WG last call. We will share the example 
as soon as it is available.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 18/04/2019, 03:49, "I2nsf on behalf of Xialiang (Frank, Network Standard & 
Patent Dept)" mailto:i2nsf-boun...@ietf.org> on behalf 
of frank.xiali...@huawei.com<mailto:frank.xiali...@huawei.com>> wrote:

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



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

Re: [I2nsf] I2NSF Hackathon Project

2019-03-23 Thread Diego R. Lopez

Hi Paul,

I’ll be at the hackathon (about to take the plane to Prague now…) and will look
for you. I have a couple of matters to discuss with you regarding the drafts
and a couple of questions on the software you are using.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile: +34 682 051 091
--

On 23/03/2019, 09:20, "I2nsf on behalf of Mr. Jaehoon Paul Jeong"
mailto:i2nsf-boun...@ietf.org> on behalf of
jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:

Hi I2NSF WG,
I am coordinating I2NSF Hackathon Project this IETF meeting, too.
If you have time, please join our hackathon project team this weekend.

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<mailto:jaehoon.p...@gmail.com>,
paulje...@skku.edu<mailto:paulje...@skku.edu>
Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

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.

[I2nsf] FW: New Version Notification for draft-pastor-i2nsf-nsf-remote-attestation-05.txt

2019-01-02 Thread Diego R. Lopez

Hi,

Just a refresh of this draft, in the hope the WG decides what to do with 
attestation in the coming months.

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 02/01/2019, 00:09, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-pastor-i2nsf-nsf-remote-attestation-05.txt
has been successfully submitted by Diego R. Lopez and posted to the
IETF repository.

Name:draft-pastor-i2nsf-nsf-remote-attestation
Revision:05
Title:Remote Attestation Procedures for Network Security Functions (NSFs) 
through the I2NSF Security Controller
Document date:2019-01-02
Group:Individual Submission
Pages:17
URL:
https://www.ietf.org/internet-drafts/draft-pastor-i2nsf-nsf-remote-attestation-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-pastor-i2nsf-nsf-remote-attestation/
Htmlized:   
https://tools.ietf.org/html/draft-pastor-i2nsf-nsf-remote-attestation-05
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-pastor-i2nsf-nsf-remote-attestation
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-pastor-i2nsf-nsf-remote-attestation-05

Abstract:
   This document describes the procedures a client can follow to assess
   the trust on an external NSF platform and its client-defined
   configuration through the I2NSF Security Controller.  The procedure
   to assess trustworthiness is based on a remote attestation of the
   platform and the NSFs running on it performed through a Trusted
   Platform Module (TPM) invoked by the Security Controller.




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.

The IETF Secretariat






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

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

2018-12-06 Thread Diego R. Lopez

Hi,

While I agree the matter addressed by the draft is quite relevant and we as a 
group need to consider a data model for monitoring, I am concerned about 
potential reinventions of the wheel, as this data model should be an extension 
of any other more general monitoring data model out there. So I think the query 
Linda initiated on is a wise move.

In summary, I support the adoption and I request it evolves into an incremental 
approach with respect any suitable general monitoring model.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 05/12/2018, 23:31, "I2nsf on behalf of Linda Dunbar" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

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 ; Yoav Nir 
Cc: i2nsf@ietf.org; skku_secu-brain_...@googlegroups.com; Sangwon Hyun 
; Mr. Jaehoon Paul Jeong 
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<mailto:jaehoon.p...@gmail.com>, 
paulje...@skku.edu<mailto:paulje...@skku.edu>
Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.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 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

Re: [I2nsf] Hi, I2NSF chairs. Request time slots for 2 data model drafts:

2018-11-03 Thread Diego R. Lopez

Hi,

Does draft-ietf-i2nsf-nsf-facing-interface-dm describe how extensions or 
additions should be made? In the first case, separate documents could make 
sense. If not, I’d prefer to see the whole model specified in a single document.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 01/11/2018, 10:18, "I2nsf on behalf of Panwei (William)" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
william.pan...@huawei.com<mailto:william.pan...@huawei.com>> wrote:

Hi Linda,

The draft-ietf-i2nsf-nsf-facing-interface-dm defines a ECA-way I2NSF Policy 
Rule data model, and its focus is the architecture of the NSF-Facing Interface..
Our drafts focus on some concrete functions and attributes, they are the 
additional enhancement and supplement to the 
draft-ietf-i2nsf-nsf-facing-interface-dm. For example, the 
draft-dong-i2nsf-asf-config is trying to define the configuration data model of 
some common advance security functions which are just part of the ACTION in 
draft-ietf-i2nsf-nsf-facing-interface-dm.
In addition, the data model of our drafts can be not only used for NSF, but 
also can be used as customer-facing interface.

So from our points of view, the focus between our drafts and 
draft-ietf-i2nsf-nsf-facing-interface-dm is different. And separating them may 
be the effective way to keep their work without affecting each other. The other 
enhancement with different focus of the draft can also be separated. Besides, 
if we merge our drafts into draft-ietf-i2nsf-nsf-facing-interface-dm, the size 
of the draft may be too large.

Best Regards
Wei Pan

发件人: Linda Dunbar
发送时间: 2018年11月1日 5:47
收件人: Xialiang (Frank, Network Integration Technology Research Dept) 
; Yoav Nir 
抄送: Linqiushi (Jessica, CSPL) ; Panwei (William) 
; i2nsf@ietf.org
主题: RE: Hi, I2NSF chairs. Request time slots for 2 data model drafts:

Frank,

Can you please explain why it is necessary to have additional two data model 
drafts? Instead of merging into draft-ietf-i2nsf-nsf-facing-interface-dm?
When you present to I2NSF WG session, can you please highlight how it is 
aligned with the draft-ietf-i2nsf-nsf-facing-interface-dm and the reasons for 
separating them.

Thank you.

Linda Dunbar

From: Xialiang (Frank, Network Integration Technology Research Dept)
Sent: Tuesday, October 23, 2018 9:24 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Yoav Nir mailto:ynir.i...@gmail..com>>
Cc: Linqiushi (Jessica, CSPL) 
mailto:linqiu...@huawei..com>>; Panwei (William) 
mailto:william.pan...@huawei.com>>
Subject: Hi, I2NSF chairs. Request time slots for 2 data model drafts:

Hi Linda and Yoav,
We have updated two individual drafts about the data model for I2NSF policy 
object and application layer security functions, which we’d like to request the 
time slots for presentation:
   Draft  presenter 
   time
draft-xia-i2nsf-sec-object-dm-01  Qiushi Lin   15 
minutes
draft-dong-i2nsf-asf-config-01   Wei Pan  
15 minutes

Thanks a lot!

B.R.
Frank



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
___

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-registration-interface-dm-00.txt

2018-10-22 Thread Diego R. Lopez

Hi Paul,

I think we agree in all aspects, but on the DMS concept and its connection with 
the Security Controller. In my view, a DMS will never be associated to VNFM (or 
anything else in the MANO stack) Let me try to illustrate this by means of the 
organizational roles involved: a SC would be typically run by a network 
provider or a its customer (Telefonica or, say, a bank Telefonica is providing 
network services), and a DMS would be typically run by a network equipment 
vendor (Huawei, Ericsson, F5…), and therefore it is quite unlikely the VNFM 
instances running in the network service providers are run by network equipment 
vendors.

In an NFV environment, the DMS requests through the registration interface will 
translate into events related with NSF onboarding. And the SC will use the 
registration interface to query the catalog of available NSFs and translate its 
decisions into requests to the MANO stack. So we could conclude the 
registration interface is the way for both the DMS and the SC interact with the 
NFV MANO stack, but by no means in an interactive, direct way. The shortcut you 
describe may be acceptable for demonstration purposes in a hackathon, but I do 
not see how this can match a real operational environment.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 21/10/2018, 23:01, "Mr. Jaehoon Paul Jeong" 
mailto:jaehoon.p...@gmail.com>> wrote:

Hi Diego,
Here are my answers inline.

On Sun, Oct 21, 2018 at 2:58 PM Diego R. Lopez 
mailto:diego.r.lo...@telefonica.com>> wrote:
Hi,

I've gone through the new version of the Registration Interface mode draft, 
that does look much better and integrated to me now, and I have a few comments, 
most of them on the procedures described for using the interface and the 
connection of Controller and the DMS:

1) First of all, related to terminology: Why do you define the term "NSF 
Profile"? Why not refer to the "Profile" definition in the terminology 
document? By referring just to "Profile" I think you can freely use "NSF 
Profile" later on...
 => That's a good suggestion. We will refer to the definition of "Profile" of 
the object of an NSF
  for the sake of "NSF Profile" in the revision -01.

2) The actions described in section 4 seems to imply a direct and dynamic 
communication between Controller and DMS, when what I foresee is something 
similar to the onboarding mechanisms in current software-based networks: The 
DMS uses the registration interface to provide and update the capabilities of 
those NSFs provided to the Controller, and the Controller makes the appropriate 
selection once it receives a request from a client, instantiating them from the 
repository. But by no means a direct dialog between Controller and DMS should 
be assumed, nor I think we should specify a dynamic instantiation mechanism in 
this document.
 => In the IETF-103 Hackathon project for I2NSF in OpenStack-Based NFV, DMS is 
implemented as an EM that has an interface (i.e., Ve-Vnfm Interface) with VNF 
Manager.
That is, the instantiation request from Security Controller to DMS will be 
delivered to VNF Manager by DMS .
 We will clarify this text based on our implementation in the revision.

3) The same happens with the process described in section 5. We should change 
this into a decoupled register-select-instantiate operation sequence. And, BTW, 
what do you mean by "a specific NSF required or *wasted* in the current 
system"? Wasted by whom and how?
 => The wasted NSF is an NSF that is not used by any traffic flows, yet is 
running as a VNF in the NFV environment. For the efficient resource management, 
we need to
  deinstantiate such an NSF.

 The appendix of Registration Interface Information Model Draft below 
clarifies the above my answers.
 Appendix A.  Lifecycle Management Mechanism in 
draft-hyun-i2nsf-registration-interface-im-06
 
https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-im-06#page-12

 According to your comments, the the instantiation and deinstantiation of 
an NSF will clarified in an Appendix rather than in a main section.

4) Following this, the instantiation and deinstantaiation operations described 
in 5.1 should not be used. What is more, I'd say they are out of the scope of 
this document, and while mechanisms for instance management could be generally 
mentioned, they should not be described in detail here.

 => Yes, as mentioned above, the instantiation and deinstantaiation operations 
will be described in an Appendix in the revision.

5) And a question on the access information described in section 5.3: should it 
not inc

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-registration-interface-dm-00.txt

2018-10-20 Thread Diego R. Lopez

Hi,

I've gone through the new version of the Registration Interface mode draft, 
that does look much better and integrated to me now, and I have a few comments, 
most of them on the procedures described for using the interface and the 
connection of Controller and the DMS:

1) First of all, related to terminology: Why do you define the term "NSF 
Profile"? Why not refer to the "Profile" definition in the terminology 
document? By referring just to "Profile" I think you can freely use "NSF 
Profile" later on...

2) The actions described in section 4 seems to imply a direct and dynamic 
communication between Controller and DMS, when what I foresee is something 
similar to the onboarding mechanisms in current software-based networks: The 
DMS uses the registration interface to provide and update the capabilities of 
those NSFs provided to the Controller, and the Controller makes the appropriate 
selection once it receives a request from a client, instantiating them from the 
repository. But by no means a direct dialog between Controller and DMS should 
be assumed, nor I think we should specify a dynamic instantiation mechanism in 
this document.

3) The same happens with the process described in section 5. We should change 
this into a decoupled register-select-instantiate operation sequence. And, BTW, 
what do you mean by "a specific NSF required or *wasted* in the current 
system"? Wasted by whom and how?

4) Following this, the instantiation and deinstantaiation operations described 
in 5.1 should not be used. What is more, I'd say they are out of the scope of 
this document, and while mechanisms for instance management could be generally 
mentioned, they should not be described in detail here.

5) And a question on the access information described in section 5.3: should it 
not include a reference to the mechanisms to secure the access, like 
encryption, reference to certificates or key repositories, etc. I am not asking 
for storing credentials, but at least to let the Controller know that IPsec 
using certificates approved by a particular CA should be used, for example.

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 20/10/2018, 22:10, "I2nsf on behalf of internet-dra...@ietf.org" 
 wrote:


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   : I2NSF Registration Interface Data Model
Authors : Sangwon Hyun
  Jaehoon Paul Jeong
  Taekyun Roh
  Sarang Wi
  Jung-Soo Park
Filename: draft-ietf-i2nsf-registration-interface-dm-00.txt
Pages   : 23
Date: 2018-10-20

Abstract:
   This document defines an information model and a YANG data model for
   Interface to Network Security Functions (I2NSF) Registration
   Interface between Security Controller and Developer's Management
   System (DMS).  The objective of these information and data models is
   to support NSF search, instantiation and registration according to
   required security capabilities via I2NSF Registration Interface.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-00

https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-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/

___
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 on

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

2018-09-12 Thread Diego R. Lopez

As an author, I am not aware of any IPR related to the I2NSF applicability 
draft.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 06/09/2018, 22:59, "Linda Dunbar" 
mailto:linda.dun...@huawei.com>> wrote:

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




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

Re: [I2nsf] WG Adoption call for I2NSF Registration Interface Data Model Draft

2018-09-12 Thread Diego R. Lopez

Hi,

I’ve gone through this draft and I support its adoption.

Let me remark I think it is a perfect example of how we should describe 
information and data models for all the I2NSF interfaces.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 11/09/2018, 22:56, "I2nsf on behalf of Linda Dunbar" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

I2NSF WG,

https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-dm-06  
represents one of the 3 interfaces identified by the i2nsf framework RFC8329. 
The authors have merged both Information model and the data model into one 
document.

The WG Chairs have determined that it makes sense to go for a WG adoption call 
on this document.
We are allowing 3 weeks for these calls, ending Oct 3.

Please respond with either support or objection to the WG adopting this 
document.

Please be aware adopting to WG only means that WG agrees it is a good direction 
to go, meaning it is now at WG’s hand to make the needed changes (instead of 
authors themselves. )

Thank you very much

Linda & Yoav

From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.p...@gmail.com]
Sent: Tuesday, September 11, 2018 11:25 AM
To: i2nsf@ietf.org
Cc: Linda Dunbar ; Yoav Nir ; 
SecCurator_Team ; Mr. Jaehoon Paul Jeong 

Subject: Request for WG Adoption on I2NSF Registration Interface Data Model 
Draft

Hi Linda and Yoav,
As we agreed on the merging of Information Model and Data Model Drafts
of I2NSF Registration Interface in the last IETF-102 Montreal Meeting,
our authors have merged these two drafts into one draft as below:

- I2NSF Registration Interface Data Model
  (draft-hyun-i2nsf-registration-interface-dm-06)
  https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-dm-06

Could you start the WG adoption call?

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<mailto:jaehoon.p...@gmail.com>, 
paulje...@skku.edu<mailto:paulje...@skku.edu>
Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.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 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

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

2018-07-21 Thread Diego R. Lopez

Hi Paul,

Where are the high-level YANG and low-level YANG defined? Probably, as you
suggest in the case of RFC8106, this could become implementation considerations
on one of the YANG definitions.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile: +34 682 051 091
--

On 21/07/2018, 18:42, "Mr. Jaehoon Paul Jeong"
mailto:jaehoon.p...@gmail.com>> wrote:

Hi Diego,
This draft is about the design and implementation of
I2NSF Security Policy Controller from a high-level YANG to a low-level YANG.

In my previous RFC about "IPv6 Router Advertisement Options for DNS
Configuration",
the implementation considerations are included for facilitating developers for
an easy implementation:
https://tools.ietf.org/html/rfc8106

As I mentioned in the previous email, we aim at an Informational RFC rather than
a Standard-track or experimental RFC.
IMHO, this policy translation is a key technology for I2NSF, so it will be
beneficial
to have an Informational RFC on the security policy translation.

Thanks.

Paul

On Sat, Jul 21, 2018 at 11:39 AM, Diego R. Lopez
mailto:diego.r.lo...@telefonica.com>> wrote:
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<mailto: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<mailto: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<mailto:jaehoon.p...@gmail.com>,

[I2nsf] Attestation side meeting

2018-07-18 Thread Diego R. Lopez

Hi,

As I mentioned during our meeting today, a few of us interested in remote 
attestation mechanisms and protocols will have a side meeting on Thursday after 
the IETF sessions. Here you go the space-time coordinates and some initial 
reflections to lure you into it:

At *7:15pm EDT (CT)*,
On *Thursday, July 19th*,
In room *Square Dorchester*,
which is here: 
https://datatracker.ietf.org/meeting/102/floor-plan#2nd-floor-convention-floor-2

Although it is a Bar BoF (great), it is now on-site (not so great), but
we will have a projector with HDMI (curious little detail, but interop
guys will know...), to enable remote call-in (thx Ned for supporting that).

We are planning to find (or create) an appropriate place for
remote attestation related work in the IETF with a Bar BoF as a first step.

Some context:

In essence, remote attestation procedures are a tool-set that is
intended to increase the confidence that an entity other entities
interact with is a trusted system.

Remote attestation typically is tied to a type of trust anchor or
shielded secret, which is - in a sense - a tad bit exotic in the scope
of protocols developed in the IETF as those exist and operate "inside
the box". In contrast, most IETF solutions operate "between boxes".
While remote attestation procedures require both parts in order to
provide a value, appropriate network protocols to convey corresponding
information between boxes are still very much work in progress.

The Plan:

To create appropriate protocols and architectures, unfortunately, is not
a trivial task. In order to find out how this "non-trivial" thing can be
talked about and how to do that constructively in the IETF, we would
like to invite you to a Bar BoF.

The minimum goal is to talk about what remote attestation means
(semantic), what parts of it would belong in the IETF (scope), how to
align existing work and how to provide a basis for future work
(solution). Even better, if we would be able to agree in some of these
areas and flock together.

Some references of the work in this space that is scattered all over the
IETF:

https://datatracker.ietf.org/doc/draft-pastor-i2nsf-nsf-remote-attestation/
https://datatracker.ietf.org/doc/draft-birkholz-i2nsf-tuda/
https://datatracker.ietf.org/doc/draft-mandyam-eat/
https://datatracker.ietf.org/doc/draft-mandyam-tokbind-attest/
https://datatracker.ietf.org/doc/draft-birkholz-reference-ra-interaction-model/
https://datatracker.ietf.org/doc/draft-birkholz-yang-basic-remote-attestation/
https://datatracker.ietf.org/doc/draft-birkholz-attestation-terminology/

There also is the r...@ietf.org<mailto:r...@ietf.org> list (as you can see in 
the email
header) and a place at github (https://github.com/ietf-rats).

All that said, we would welcome you to drop by and are looking forward
to a lively discussion.


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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--



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

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

2018-07-16 Thread Diego R. Lopez

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

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

2018-07-16 Thread Diego R. Lopez

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 Research Dept) 
; Xialiang (Frank, Network Integration Technology Research 
Dept) 
主题: New Version Notification for draft-dong-i2nsf-asf-config-00.txt


A new version of I-D, draft-dong-i2nsf-asf-config-00.txt
has been successfully submitted by Yue Dong and posted to the IETF 
repository.

Name:draft-dong-i2nsf-asf-config
Revision:00
Title:Configuration of Advanced Security Functions with I2NSF Security 
Controller
Document date:2018-06-30
Group:Individual Submission
Pages:29
URL:
https://www.ietf.org/internet-drafts/draft-dong-i2nsf-asf-config-00.txt
Status:

Re: [I2nsf] New Version Notification for draft-xia-i2nsf-sec-object-dm-00.txt

2018-07-11 Thread Diego R. Lopez

Hi,

The proposal sounds in principle reasonable, as a useful artifact to simplify 
policy expressions. My only concern is whether this could cause some distortion 
in the capability model: I don’t see any, but I’d like to know the opinion of 
the other capability model perpetrators (well, Aldo’s and John’s. I guess Frank 
would be in. agreement…)

And I’d propose to include this in the capability data model document.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 11/07/2018, 09:32, "I2nsf on behalf of Linqiushi (Jessica, CSPL)" 
mailto:i2nsf-boun...@ietf.org> on behalf of 
linqiu...@huawei.com<mailto:linqiu...@huawei.com>> wrote:

Hi all,

As we mentioned in draft-xia-i2nsf-sec-object-dm-00, attribute based policy 
rule configuration is repetitive when creating new policy rules and is hard to 
maintain consistency when making modification.
We propose to introduce the “object” concept in I2NSF policy rule to provide 
re-usability and simplicity, and define commonly used policy objects.
Taking address attribute as an example, address object and address group object 
are defined. The YANG tree structure of address object is as follows.
grouping addr-objects:
+--rw addr-object* [name]
+--rw name  address-set-name
+  ...
+--rw elements*  [elem-id]
+--rw elem-id uint16
+--rw (object-items)
+--: (ipv4)
|  ...
+--: (ipv6)
|  ...
+--: (mac)
|  ...
+--: (ipv4-range)
|  ...
+--: (ipv6-range)
...


For other policy objects, please review the draft: 
https://tools.ietf.org/html/draft-xia-i2nsf-sec-object-dm-00.



We want to solicit comments from I2NSF WG. Would the WG like to adopt “policy 
object” in I2NSF policy rule? Is an individual draft needed? Or just 
incorporating it into the existing drafts?

Thanks.


Best Regards,
Qiushi (Jessica) Lin

发件人: Linqiushi (Jessica, CSPL)
发送时间: 2018年7月2日 14:49
收件人: i2nsf@ietf.org
抄送: Xialiang (Frank, Network Integration Technology Research Dept) 

主题: FW: New Version Notification for draft-xia-i2nsf-sec-object-dm-00.txt


Dear all,



We just submitted a new draft on I2NSF policy object data model. Object based 
rule configuration provides reusability and is widely adopted in NSFs. This 
document defines several commonly used policy objects, e.g. address object, 
service object, etc.

Besides,  this data model draft is aligned with the previous information model 
draft. The policy objects are defined as groupings to be reused in different 
rules.



Your comments and suggestions are warmly welcome.



Best Regards,

Qiushi (Jessica) Lin



-邮件原件-
发件人: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
[mailto:internet-dra...@ietf.org]
发送时间: 2018年7月2日 14:46
收件人: Linqiushi (Jessica, CSPL) 
mailto:linqiu...@huawei.com>>; Xialiang (Frank, Network 
Integration Technology Research Dept) 
mailto:frank.xiali...@huawei.com>>; Linqiushi 
(Jessica, CSPL) mailto:linqiu...@huawei.com>>; Xialiang 
(Frank, Network Integration Technology Research Dept) 
mailto:frank.xiali...@huawei.com>>
主题: New Version Notification for draft-xia-i2nsf-sec-object-dm-00.txt





A new version of I-D, draft-xia-i2nsf-sec-object-dm-00.txt

has been successfully submitted by Qiushi Lin and posted to the IETF repository.



Name: draft-xia-i2nsf-sec-object-dm

Revision:  00

Title:I2NSF Security Policy Object YANG Data Model

Document date:  2018-07-01

Group: Individual Submission

Pages:  41

URL:
https://www.ietf.org/internet-drafts/draft-xia-i2nsf-sec-object-dm-00.txt

Status: https://datatracker.ietf.org/doc/draft-xia-i2nsf-sec-object-dm/

Htmlized:   https://tools.ietf.org/html/draft-xia-i2nsf-sec-object-dm-00

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-xia-i2nsf-sec-object-dm





Abstract:

   This document describes a set of policy objects which are reusable

   and can be referenced by variable I2NSF policy rules.  And the YANG

   data models of these policy objects are provided.









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.



The IETF Secretariat





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

Re: [I2nsf] WG Adoption call for draft-hares-i2nsf-capability-data-model-07

2018-04-13 Thread Diego R. Lopez

Hi,

I believe that the document is a good base for future WG work. You know I 
support the idea of a restructuring of these deliverables by merging them in a 
few clusters, but in any case this docu,ent constitutes one important part of 
what have to be the deliverables of the group in terms of data models.

I support the adoption.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--
On 07/04/2018, 00:21, "I2nsf on behalf of Linda Dunbar" 
<i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org> on behalf of 
linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:


The authors of I2NSF capability YANG Data Model 
https://datatracker.ietf.org/doc/draft-hares-i2nsf-capability-data-model/ have 
requested working group adoption of this draft.  The Capability data model is 
one of the deliverables of I2NSF WG, which is used by Registration interface 
and NSF interface.

Please bear in mind that WG Adoption doesn’t mean that the draft current 
content is ready, WG Adoption only means that it is a good basis for a working 
group to work on..

While all feedback is helpful, comments pro or con with explanations are much 
more helpful than just "yes please" or "no thank you".

Thank you.

Linda & Yoav




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

Re: [I2nsf] IETF 101 I2NSF session meeting minutes have been posted

2018-04-10 Thread Diego R. Lopez

Hi Paul,

I referred to https://tools.ietf.org/html/draft-yang-i2nsf-nfv-architecture-01

The other one should become part of a general document on attestation, once the
group decides to address it…

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile: +34 682 051 091
--
On 10/04/2018, 10:54, "Mr. Jaehoon Paul Jeong"
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:

Hi Linda,
Thanks for this minutes.

Diego,
I have a question about your comments on I2NSF Applicability Document:

-
09:45—9:50 I2NSF Applicability WG document, updates and next steps: Jaehoon
Paul Jeong
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/
Describe how to deploy the I2NSF policies

Diego: should we combine Applicability with SFC steering and NFV cases, is it
necessary?

Paul: I2NSF triggered traffic steering might need another year to implement,

Diego: Before publishing, I would like to see it is converged with others.

Linda: good suggestion.
-

Which draft do you mean by NFV cases below?

https://tools.ietf.org/html/draft-yang-i2nsf-nfv-architecture-01
or
https://tools.ietf.org/html/draft-rein-remote-attestation-nfv-use-cases-00

Please let me know.

Thanks.

Best Regards,
Paul

On Sat, Apr 7, 2018 at 2:41 AM, Linda Dunbar
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:
https://datatracker.ietf.org/meeting/101/materials/minutes-101-i2nsf-00

If you see anything missing, please let us know .

Linda & Yoav

___
I2nsf mailing list
I2nsf@ietf.org<mailto: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<mailto:jaehoon.p...@gmail.com>,
paulje...@skku.edu<mailto:paulje...@skku.edu>
Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

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

2018-03-13 Thread Diego R. Lopez

Hi all,

I’d daresay a general discussion on how we progress with attestation matters in 
the WG (or even the IETF at large) would be rather interesting. We could use 
the introduction to this document to start such a discussion…

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--
On 13/03/2018, 10:22, "I2nsf on behalf of Xialiang (Frank, Network Integration 
Technology Research Dept)" 
<i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org> on behalf of 
frank.xiali...@huawei.com<mailto:frank.xiali...@huawei.com>> wrote:

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



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

Re: [I2nsf] Request for WG Adoption Call for Consumer-Facing Interface Information Model Draft

2018-03-13 Thread Diego R. Lopez

Hi,

My understanding was that we were not going to have pairs of IM/DM documents
for each interface, but one single capability document acting as the “master
IM” (including the reference model for what we called the capability algebra),
and DM documents that would include some analysis on the information modelling
and/or requirements as introductory material.

So I’d strongly encourage the merging of
draft-kumar-i2nsf-client-facing-interface-im into the already adopted DM
document, rather than adopting it.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile: +34 682 051 091
--
On 06/03/2018, 17:48, "I2nsf on behalf of Mr. Jaehoon Paul Jeong"
<i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org> on behalf of
jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:

Dear I2NSF WG Chairs,

Could I ask for a WG adoption call for our consumer-facing interface
information model draft below?
https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing-interface-im-05

As you know, the YANG data model draft of this consumer-facing interface
information model has been adopted as a WG document recently:
https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-00

This information model is well-synchronized with the above YANG data model.

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<mailto:jaehoon.p...@gmail.com>,
paulje...@skku.edu<mailto:paulje...@skku.edu>
Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

Re: [I2nsf] Is "remote attestation" applicable to TEEP (Trusted Execution environment to allow secure updates) or SUIT (Software Update for Internet of things)?

2017-12-19 Thread Diego R. Lopez

Hi Linda,

Trying to catch up with highly delayed emails. In principle, the techniques 
applicable for TEEP (and probably SUIT, not sure about the details in this 
case) should be the same related to remote attestation. This is one of the 
reasons why Henk and yours friendly are advocating for a list (and probably a 
WG) focused on it.

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<mailto:diego.r.lo...@telefonica.com>
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--
On 07/12/2017, 17:29, "Linda Dunbar" 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

Antonio, Diego, and Adrian

IETF 100 has those two BOFs:

· TEEP: Trusted Execution Environment to allow secure updates

· SUIT: Software Update for Internet of Things (current scope limited 
to firmware updates)
There are Considerable interest from Microsoft (including Dave Thaler as 
co-chair for both BoFs).


Is "remote attestation" applicable to TEEP or SUIT?

Linda



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

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

2017-09-19 Thread Diego R. Lopez

With all due apologies for the delay, caused by the clash of the adoption call, 
and my holidays (and the subsequent e-mail recovery process) I support the 
adoption as an author.

I believe this document is the core element to define the I2NSF IM, and we 
should structure it around it. I am maturing a proposal to do so, and foster IM 
and DM development, to be shared on the list soon.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

On 19/9/2017, 09:04 , "John Strassner" <john.sc.strass...@huawei.com> wrote:

I also support the adoption.

Regards,
John

-Original Message-
From: Aldo Basile [mailto:cataldo.bas...@polito.it]
Sent: Monday, September 18, 2017 11:54 PM
To: Linda Dunbar <linda.dun...@huawei.com>; 'i2nsf@ietf.org' 
<I2nsf@ietf.org>
Cc: draft-xibassnez-i2nsf-capabil...@ietf.org; Yoav Nir 
<ynir.i...@gmail.com>
Subject: Re: WG Adoption call for draft-xibassnez-i2nsf-capability-02

I support the adoption.

Regards,
Aldo

On 02/08/2017 22:15, Linda Dunbar wrote:
> 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.
>
> **
>

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

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

2017-09-19 Thread Diego R. Lopez

I support the adoption and agree with Med in the need for an applicability
statement.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

On 9/8/2017, 08:34 ,
"mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>"
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> wrote:

Hi Linda, all,

I support.

That’s said, the current content and structure of the document need to be
adjusted to reflect an applicability statement. FWIW, some comments and
suggestions are available at:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-jeong-i2nsf-applicability-01-rev%20Med.doc

Cheers,
Med

De : I2nsf [mailto:i2nsf-boun...@ietf.org] De la part de Linda Dunbar
Envoyé : mercredi 2 août 2017 22:27
À : 'i2nsf@ietf.org'
Cc : draft-jeong-i2nsf-applicabil...@ietf.org; Yoav Nir
Objet : [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] FW: New Version Notification for draft-pastor-i2nsf-nsf-remote-attestation-02.txt

2017-09-13 Thread Diego R. Lopez

Hi,

I have just update the references, with the intention to keep the draft alive, 
as I think attestation is one of the important issues we have to address, one 
way or another.

This said, I know I have been not very active in the group during the past 
months (many other urgent assignments), but I plan to get back with a couple of 
proposals I briefly sketched in Prague soon.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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


On 13/9/2017, 16:51 , "internet-dra...@ietf.org" <internet-dra...@ietf.org> 
wrote:


A new version of I-D, draft-pastor-i2nsf-nsf-remote-attestation-02.txt
has been successfully submitted by Diego R. Lopez and posted to the
IETF repository.

Name:draft-pastor-i2nsf-nsf-remote-attestation
Revision:02
Title:Remote Attestation Procedures for Network Security Functions (NSFs) 
through the I2NSF Security Controller
Document date:2017-09-13
Group:Individual Submission
Pages:16
URL:
https://www.ietf.org/internet-drafts/draft-pastor-i2nsf-nsf-remote-attestation-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-pastor-i2nsf-nsf-remote-attestation/
Htmlized:   
https://tools.ietf.org/html/draft-pastor-i2nsf-nsf-remote-attestation-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-pastor-i2nsf-nsf-remote-attestation-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-pastor-i2nsf-nsf-remote-attestation-02

Abstract:
   This document describes the procedures a client can follow to assess
   the trust on an external NSF platform and its client-defined
   configuration through the I2NSF Security Controller.  The procedure
   to assess trustworthiness is based on a remote attestation of the
   platform and the NSFs running on it performed through a Trusted
   Platform Module (TPM) invoked by the Security Controller.




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.

The IETF Secretariat






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

Re: [I2nsf] Location (Hotel Lobby Level: Istanbul room) for getting together Tuesday 8:30am - 9:30am to discuss consistency issue of multiple drafts on Information & data models:

2017-07-17 Thread Diego R. Lopez

 I2NSF information and data models for both 
Client/Consumer facing and NSF facing interfaces.
So we are going to form a design team to work on it.

If you are interested in participate, please click on this doodle poll: 
https://doodle.com/poll/4ryrcw3993fbf7ca

For people not in Prague, we can set up a Webex for you to call in.

Thank you very much for the contribution.

Linda & Adrian


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



--
regards,
John
___
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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




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

Re: [I2nsf] Does "draft-xibassnez-i2nsf-capability" also specify the information model to NSF?

2017-07-16 Thread Diego R. Lopez

"capability". And =
"proto=20
>> !=3D tcp" would be a concrete condition for a security rules.
>>=20
>> Can you explain how to draw the link from the draft's abstract to the=20=

>> sections in the draft?
>>=20
>> Thank you very much.
>>=20
>> Linda
>>=20
>> p.s. is it appropriate to add a note stating that conventional =
security=20
>> devices deployed, such as FW, may consists of multiple "Functions"?
>>=20
>=20
>=20

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/ <http://people.tid.es/diego.lopez/>

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


--Apple-Mail=_C3B9062D-559E-4C84-BCC3-0B49169B81F1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8

Hi Linda,As far as I can tell, both (and may be other interfaces as =
well): The available capabilities would be declared through the =
Registration Interface, and invoked through the NSF-facing one=E2=80=A6

Re: [I2nsf] Questions to draft-jeong-i2nsf-applicability-00

2017-07-12 Thread Diego R. Lopez

Hi Linda,


On 13 Jul 2017, at 24:46 , Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

Paul, Sangwon, Tae-Jin, Sue, and Diego,

Thank you for putting this draft together, which is one of the deliverable of 
I2NSF charter.

Questions:

Page 3 last bullet: What is “SDN switch”?  What is “network-based firewall”? in 
the following context:
SDN can work as a network-based firewall system through a standard
interface between an SDN switch and a firewall function as a
vitual network function (VNF)

Do you mean Controller, Switch, and virtual network function can be combined 
together to filter traffic to achieve the function of “firewall”?

Here we would be talking of the combination of a SDN-enabled switch and a SDN 
application (running on a SDN controller) that is a VNF.


Section 5.1: Firewall: Centralized Firewall System
The wording is so close to the “centralized physical FW” where all traffic hair 
pinned through the “Centralized physical FW” to be filtered before going out or 
into network.
Your described scenario is more like “switch – FW” combined together to achieve 
packet filtering, where only some packets are sent to FW, vs. the traditional 
centralized physical FW requiring all packets to traverse the FW.

Correct?

This is how I see it. You are somehow “pushing” part of the FW functionality 
down to the switch…

Be goode,


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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




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

Re: [I2nsf] Framework Draft, section 6.2

2017-07-05 Thread Diego R. Lopez

I fully agree with this, John. It is important we avoid mixing concepts in both 
domains.

Be goode,

On 3 Jul 2017, at 03:26 , John Strassner 
<straz...@gmail.com<mailto:straz...@gmail.com>> wrote:

Section 6.2 says:

   o  When multiple instantiations of one single NSF appear as one
  single entity to the Security Controller, the policy provisioning
  has to be sent to the NSF Manager, which in turn disseminates the
  polices to the corresponding instantiations of the NSF, as shown
  in Figure 2 below.


I have no idea what an "NSF Manager" is. It is not defined in the
Terminology draft. The closest term in the terminology draft is
"I2NSF Management System".

However, for some reason, this reminds me of the VNFM in ETSI NFV.
If that is true, then I2NSF Management System is NOT the same thing.

I think that "NSF Manager" could be an EMS, as well as other types of
management engines. It is NOT the "I2NSF Management system".
However, I don't know what to call it, so I made the following
temporary hack:

   o  When multiple instantiations of one single NSF appear as one
  single entity to the Security Controller, the Security Controller
  may need to either get assistance from other entities in the
  I2NSF Management System, and/or delegate the provisioning of the
  multiple instantiations of the (single) NSF to other entities in
  the I2NSF Management System. This is shown in Figure 2 below.



--
regards,
John
___
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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




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

Re: [I2nsf] Chairs

2017-06-19 Thread Diego R. Lopez

Hi Kathleen,

Given how relevant I2NSF is for some of our projects, and that Adrian and Linda 
seem to have already done the really hard work, I’d be happy to step forward. 
Though there is the issue I am not 100% sure I’ll make it to Prague yet…

Be goode,

On 19 Jun 2017, at 21:04 , Kathleen Moriarty 
<kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.i...@gmail.com>> 
wrote:

Hello,

Adrian will be stepping down as chair after Prague.  First. I'd like
to thank him for his service, helping to get I2NSF off to a good start
with Linda.  I really do appreciate your work helping to provide
structure and driving toward milestone completion targets.

If anyone is interested in volunteering as co-chair, please send a
message expressing your interest.  Our plan will be to assign a chair
prior to Prague, have 3 chairs in Prague, and then Adrian will step
down.  This should give us a nice smooth transition.

Thank you.

--

Best regards,
Kathleen

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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




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] Fwd: New Version Notification for draft-ietf-i2nsf-framework-05.txt

2017-05-02 Thread Diego R. Lopez

Hi,

This is an updated version, most focused on trimming references, to avoid 
expiration while we address terminology issues and we decide on the 
informational nature of the document before going for last call.

Be goode,


Begin forwarded message:

A new version of I-D, draft-ietf-i2nsf-framework-05.txt
has been successfully submitted by Diego R. Lopez and posted to the
IETF repository.

Name: draft-ietf-i2nsf-framework
Revision: 05
Title: Framework for Interface to Network Security Functions
Document date: 2017-05-03
Group: i2nsf
Pages: 22
URL:
https://www.ietf.org/internet-drafts/draft-ietf-i2nsf-framework-05.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/
Htmlized:   https://tools.ietf.org/html/draft-ietf-i2nsf-framework-05
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-framework-05
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-framework-05

Abstract:
  This document describes the framework for the Interface to Network
  Security Functions (I2NSF), and defines a reference model (including
  major functional components) for I2NSF.  Network security functions
  (NSFs) are packet-processing engines that inspect and optionally
  modify packets traversing networks, either directly or in the context
  of sessions in which the packet is associated.

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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




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] Fwd: New Version Notification for draft-pastor-i2nsf-nsf-remote-attestation-00.txt

2017-01-06 Thread Diego R. Lopez

Hi,

Just back from the Christmas break, my first task in my I2NSF todo list was 
updating the attestation draft, just to avoid expiration. So far it only has a 
few updated references with respect to draft-pastor-i2nsf-vnsf-attestation-03. 
More to come, on this drafts and others…

Be goode,


> Begin forwarded message:
> 
> From: <internet-dra...@ietf.org>
> Subject: New Version Notification for 
> draft-pastor-i2nsf-nsf-remote-attestation-00.txt
> Date: 7 January 2017 at 01:11:52.000 GMT+1
> To: "Adrian L. Shaw" <a...@hpe.com>, Diego Lopez 
> <diego.r.lo...@telefonica.com>, Antonio Pastor 
> <antonio.pastorpera...@telefonica.com>, Adrian Shaw <a...@hpe.com>, "Diego R. 
> Lopez" <diego.r.lo...@telefonica.com>
> 
> 
> A new version of I-D, draft-pastor-i2nsf-nsf-remote-attestation-00.txt
> has been successfully submitted by Diego R. Lopez and posted to the
> IETF repository.
> 
> Name: draft-pastor-i2nsf-nsf-remote-attestation
> Revision: 00
> Title:Remote Attestation Procedures for Network Security 
> Functions (NSFs) through the I2NSF Security Controller
> Document date:2017-01-06
> Group:Individual Submission
> Pages:16
> URL:
> https://www.ietf.org/internet-drafts/draft-pastor-i2nsf-nsf-remote-attestation-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pastor-i2nsf-nsf-remote-attestation/
> Htmlized:   
> https://tools.ietf.org/html/draft-pastor-i2nsf-nsf-remote-attestation-00
> 
> 
> Abstract:
>   This document describes the procedures a client can follow to assess
>   the trust on an external NSF platform and its client-defined
>   configuration through the I2NSF Security Controller.  The procedure
>   to assess trustworthiness is based on a remote attestation of the
>   platform and the NSFs running on it performed through a Trusted
>   Platform Module (TPM) invoked by the Security Controller.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

[I2nsf] FW: On the I2NSF attestation draft

2016-11-13 Thread Diego R. Lopez

Hi,

Following a direct indication of our chairs, here you go an update of the 
attestation draft I first shared with them:


I am afraid I have had no time to incorporate the pending updates for the I2NSF 
attestation draft, and therefore we are going to miss the cut-off date. I don’t 
think this is a problem, as I see difficult to have time to discuss it in 
detail at the Seoul meeting. I will take care of it once the current rush for 
the 5G European call is over, and come with a proposal on how to align it with 
other requirements documents in the future.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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


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

Re: [I2nsf] Call for WG adoption of draft-xibassnez-i2nsf-capability

2016-11-11 Thread Diego R. Lopez

Hi,

I support adoption (as co-author)

Be goode,

On 2 Nov 2016, at 20:31 , Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

Dear WG:

This email serves as a call for WG adoption of draft-xibassnez-i2nsf-capability 
as a WG document. Considering people will be traveling to Seoul for IETF 97 and 
the Thanksgiving holiday afterwards, the call for adoption will run for 3.5 
weeks ending Nov 28, 2016.

draft-xibassnez-i2nsf-capability-00 actually is the -07 version of 
draft-xia-i2nsf-capability-interface-IM, draft name change as the result of the 
progress of I2NSF terminology and merge with
draft-baspez-i2nsf-capabilities<https://datatracker.ietf.org/doc/draft-baspez-i2nsf-capabilities/>

Please note that this is a call for adoption, and not a last call for content 
of the document. Adopting a WG document simply means that the WG will focus its 
efforts on that particular draft going forward, and use that document for 
resolving open issues and documenting the WG’s decisions.

Please indicate whether you support adoption for not, and if not why. Issues 
you have with the current document itself can also be raised, but they should 
be raised in the context of what should be changed in the document going 
forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that applies 
to this draft, in line with the IPR disclosure obligations for WG participants 
(see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a 
document author please respond to this email (to the chairs) whether or not you 
are aware of any relevant IPR
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/


Thank you,

Linda & Adrian



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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] Will you provide more details on the Rules' Information model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

2016-11-11 Thread Diego R. Lopez

inal Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar
Sent: 2016年10月31日 12:14
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Cc: Adrian Farrel <afar...@juniper.net<mailto:afar...@juniper.net>>; Linda 
Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Subject: [I2nsf] FW: New Version Notification for 
draft-kumar-i2nsf-client-facing-interface-im-00.txt

We posted a new draft that captures an information model for the client-facing 
interfaces based on “draft-ietf-i2nsf-client-facing-interface-req”.
This is an initial version, we plan to update this as we evolve based on new 
requirements and information.

Thanks & Regards,
Rakesh and other co-authors.

On 10/31/16, 10:08 AM, 
"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote:

A new version of I-D, draft-kumar-i2nsf-client-facing-interface-im-00.txt
has been successfully submitted by Rakesh Kumar and posted to the
IETF repository.

Name:   draft-kumar-i2nsf-client-facing-interface-im
Revision:   00
Title:  Information model for Client-Facing Interface to 
Security Controller
Document date:  2016-10-31
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/internet-drafts/draft-kumar-i2nsf-client-facing-interface-im-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-facing-interface-im/
Htmlized:   
https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing-interface-im-00

Abstract:
   This document defines information model for the client-facing
   interface to security controller based on the requirements identfied
   in the [I-D.kumar-i2nsf-client-facing-interface-req].  The
   information model defines various managed objects and the
   relationship among these objects needed to build the client
   interfaces.

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<http://tools.ietf.org/>.

The IETF Secretariat

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

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] RFC or not RFC in I2NSF?

2016-11-03 Thread Diego R. Lopez

Hi,

I support the proposal.

We will need to have a similar decision about the attestation draft, though I 
think we the WG can wait till we the authors provide the next version and make 
a concrete recommendation to be discussed…

Be goode,

On 2 Nov 2016, at 19:42 , Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

Hi,

We have a charter action and milestone to decide whether to publish our work as
RFCs or not. The milestone reads:

WG decides whether to progress adopted drafts for publication as RFCs (use
cases,
framework, information model, and examination of existing secure communication
mechanisms)

We had some (light) conversations on the list and arrived at the following
position, I think. This is your chance to scream if you disagree - otherwise,
this is the email of record documenting our plan.

use cases
draft-ietf-i2nsf-problem-and-use-cases
Pursue publication

framework
draft-ietf-i2nsf-framework
Pursue publication

information model
Not yet clear, but some feeling that we should publish.
Pending adoption and more work.

gap analysis for protocols
draft-ietf-i2nsf-gap-analysis
Do not publish
Keep draft alive for as long as it is useful, then archive

requirements for protocol extensions
Covered as part of draft-ietf-i2nsf-client-facing-interface-req-00
Pursue publication

examination of existing secure communication mechanisms
Aim to add this to  draft-ietf-i2nsf-client-facing-interface-req-00
Pursue publication

terminology
draft-ietf-i2nsf-terminology
Pursue publication

Cheers,
Adrian

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] with regarding to WG adoption for the revised draft-kumar-i2nsf-client-facing-interface-req-01.txt

2016-10-22 Thread Diego R. Lopez

to the features and capabilities 
supported in NSFs") doesn't make sense to me. If I was defining either an API 
or a language for I2NSF, I would choose nouns and verbs based upon a set of 
expected capabilities. Referring to DDoS as "foo" does no one any good.
 *   Fourth bullet ("Agnostic to the network function type...) is unclear; 
is "routing" or "forwarding" an agnostic term?

DRL> I wonder whether using a term other than “agnostic” could make things 
clearer in these points. In my understanding we could substitute the 
problematic clauses by:
* “Not depending on particular topology properties or on the actual NSF 
location in the network”
* “Not requiring the exact knowledge of the concrete features and capabilities 
supported in the deployed NSFs”
* “Independent of the nature of the function that will apply the expressed 
policies”

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] [Id-event] An I-D just for your information

2016-10-22 Thread Diego R. Lopez

Hi Phil,

Can you provide a link for the SET profiles? Just looking for “set” gives a 
horribly unmanageable list of references…

Thanks,

On 14 Oct 2016, at 15:24 , Phil Hunt 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

Adrian,

So where this might fit together is that SET simply profiles JWT so that an 
event can be expressed in secureable JSON format. We define only a set of 
attributes necessary to validate and secure events, but pretty much leave the 
data of the event up to “profiling” specifications that build on it.

A number of us ended up bringing this together because there was a number of 
independent efforts to express very different events doing almost the same 
thing.

From my quick scan, one of the options would be that these events could be 
expressed as a profile of SET.

I plan to do the same for SCIM, as does RISC, etc.  The OpenID Logout specs 
already use SET.


Phil

@independentid
www.independentid.com<http://www.independentid.com/>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>





On Oct 14, 2016, at 7:33 AM, Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

Hi,

Just wanted to flag
https://datatracker.ietf.org/doc/draft-zhang-i2nsf-info-model-monitoring/ in the
context of the Security Event BoF/WG.

Not sure where this sits with the Security Event work, but I2NSF seems to see
the draft as fairly important.

Cheers,
Adrian

___
Id-event mailing list
id-ev...@ietf.org<mailto:id-ev...@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] Info models and draft-zhang-i2nsf-info-model-monitoring

2016-10-22 Thread Diego R. Lopez

Hi Adrian,

Agree: it is a useful tool but should not be a separate publication. The only 
reason for publishing the information model could be to do so in the same 
document as the data model, as rationale supporting it, and even giving the 
opportunity for alternate data models using other data representations (TOSCA, 
for example, very much in fashion in cloudspace).

Be goode,

On 14 Oct 2016, at 11:54 , Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

Thanks, all, for the useful comments about this document.

It seems clear that there is support for developing this work and producing a
data model for monitoring.

Two points:

1. As noted by Sue, there is a BoF/WG planned for IETF-98 on "Security Events".
I suggest you go to that. I will also make sure the AD is aware of the potential
overlap/interaction.

2. It seems reasonable to me that producing an information model (such as in
draft-zhang-i2nsf-info-model-monitoring) is a useful step toward producing a
data model. I have no objection to using a structured approach. However, my
question about "publication" could be phrased as follows:
- Suppose we decide we want a data model for monitoring
- Suppose we use draft-zhang-i2nsf-info-model-monitoring to guide
  our work on that data model
- Suppose that we push ahead with the data model quite soon so
  that it starts to catch up with the info model
If all of those things apply, why would we need to publish an RFC that captures
the information model given that we will be publishing a data model shortly
afterwards?
Presumably, once the data model is published, no one will ever read the
information model.
So the information model would be a valuable document working document in which
the WG would capture its thoughts and consensus, but would be discarded once the
work to make the data model was complete.

Or am I wrong?

Thanks,
Adrian

-Original Message-
From: Susan Hares [mailto:sha...@ndzh.com]
Sent: 13 October 2016 14:49
To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: RE: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring

Adrian:

Why: Monitoring is a key component to I2NSF for monitoring NSF devices.
Monitoring is not the same as NSF devices sending notifications - which is a
push from the NSF devices.  Monitoring may encompasses specific requests to
the device.   Monitoring is different than the DOTS - "help me" cry from a
device under attack.
While I see the security ADs are proposing Security event, it is important
that the I2NSF create monitoring concepts that work with all of the
functions (e.g. querying capabilities, sending/receiving notification, and
events).

Data model versus Information model:  Since we do not seem to have a clear
idea of what the data model should be, it is important to create the
informational models.

The content of the draft is a good first step.

Sue Hares



-Original Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, October 11, 2016 5:22 PM
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring

Working Group,

Linda and I would like to hear some more from you about
draft-zhang-i2nsf-info-model-monitoring.

Is it something you think we should be working on?
Should we have a separate YANG module for it or fold it into other modules?
If we produce a YANG module, do we still need to publish the information
model?

And, most important, what do you think of the content of the draft?

Thanks,
Adrian

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

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] Thinking about what to do with draft-ietf-i2nsf-gap-analysis

2016-10-22 Thread Diego R. Lopez

Hi Adrian,

I tend to agree with you on this. Just let me note that some material of the 
gap analysis could be incorporated somewhere else, in the documents that 
reference it and are going to follow the path to RFC. I’d like the authors of 
those documents consider the possibility if we finally agree to go as you 
suggest.

Be goode,

On 11 Oct 2016, at 23:19 , Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

Hi I2NSF,

Our charter says...

The I2NSF working group's deliverables include:

o A single document covering use cases, problem statement, and gap
  analysis document. This document will initially be produced for reference
  as a living list to track and record discussions: the working group may
  decide to not publish this document as an RFC.

We split this work into draft-ietf-i2nsf-problem-and-use-cases  and
draft-ietf-i2nsf-gap-analysis.

It looks to me that the Problem Statement and Use Cases document is something
that the WG wants to push to RFC (please correct me if I'm wrong), but I am less
certain about the Gap Analysis.

While the Gap Analysis is good work and has definitely helped us understand our
direction, I don't see a lot of value in publishing it as an RFC. My proposal
is, therefore, to keep it alive as a WG draft while it is useful reference
material, and then to let it expire. Expired drafts still remain available in
the IETF Tools repository, so it would not be lost forever.

What do you all think?
Does someone have a strong reason to publish it as an RFC?

Thanks,
Adrian (per pro Linda)

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] Comments/questions about draft-ietf-i2nsf-framework-03.txt

2016-10-22 Thread Diego R. Lopez

Hi Gabi,

With the due apologies for the delay in replying (due to a period dedicated to 
project calls, you know how it is…) let me try to address your comments inline 
below.

On 6 Oct 2016, at 12:52 , Gabriel Lopez <gab...@um.es<mailto:gab...@um.es>> 
wrote:


- “This draft proposes that a capability interface to NSFs can be developed on 
a flow-based paradigm….”
- What about the other three interfaces: registration, monitoring and 
notification?

DRL> We have to align the text with the recent agreements on the different 
interfaces and their naming. At the moment of the writing of that paragraph 
“capability” was a synonym of “NSF-facing”.

- Section 3.3 talks about the “Registration Interface” communicating the 
Security Controller and the Developer’s Mngt systems, and Section 3.2.1 also 
talks about “Registration Interface” but now referring to the communication 
between the Security Controller and the NSF.
- Interface’s name should be change here.

DRL> Indeed. See above

- Section 4. The terms “client” should be clarified here to avoid ambiguity.

DRL> Noted

- Section 7.1.
-In the last example, the text says:
- An Event can be "the client has passed AAA process"; → the term client should 
also be clarified, do you mean “end user”, “endpoint”?
- I like the example based on IPsec, but I think the example could be something 
like (just suggesting):
• Event: “traffic type X detected”
• Condition: “from domain-A to domain-B”
• Action: “Establish an IPsec tunnel”

DRL> Thanks for the suggestion. I’ll work on it

- In general, sometimes IPS/IDP examples are used, sometimes IPsec ones, 
sometimes Firewalls o DDoS, but they are not related from one section to 
another. I suggest to make use of one or two running examples across the whole 
document.

DRL> Good point. I’d say the reason comes from the fact that the current 
document combines contributions from several others. I’ll go through it trying 
to align examples, or justifying the use of a different one in a particular 
section.

- Section 8
- This sentence “It is very possible that the underlay network (or provider 
network) does not have the capability or resource to enforce the flow security 
policies requested by the overlay network (or enterprise network)” is quite 
confusing.
- The association between underlay/provider and overlay/enterprise is not 
described.

DRL> I think the association is clear, as an implicit one backed by common 
practice, but if you can you suggest a better wording it would be welcome.

- Section 9.
- Section 9.1
-In this section Firewalls, IPS and IDS are described but it seems more a 
closed list rather than examples. I think it should be clarified. BTW, security 
gateways (IPsec) may be included in the list of “commonly deployed NSF”.

DRL> Noted

- Section 9 is labelled “Registration consideration” but talks about “traffic 
characterization”
- What “Registration” means here? capability registration? security services? 
and why it is related with traffic characterization should be described.

DRL> The section is intended to consider the aspects related to public 
registries, typically run by IANA. You are right this is not clear in the text. 
I will update the introduction to this section.

I plan to update the draft during the coming days, trying to address your 
comments and suggestions, as well as others. Stay tuned.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] questions about draft-kim-i2nsf-security-management-architecture-01

2016-10-22 Thread Diego R. Lopez

Hi Paul,

While I find agreeable that your draft could be merged with another one (or
other ones) in order to consolidate the documents to be produced by I2NSF, I am
not 100% sure it should be the framework draft. Looking at the proposals you
make in your draft I see it more aligned with what the drafts dealing with the
client-facing interface are considering than with the general framework. In
particular,
draft-kumar-i2nsf-client-facing-interface-req-01<https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-facing-interface-req/>
has a section(3.3) that discusses management deployment models, and I am under
the impression this architecture you propose could be seen as a refinement of
those models.

Be goode,

On 21 Oct 2016, at 02:54 , Mr. Jaehoon Paul Jeong
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:

Hi Linda,
Are you agreeing at merging our draft
(draft-kim-i2nsf-security-management-architecture-02)
into draft-ietf-i2nsf-framework-03?

Thanks.

Best Regards,
Paul

On Fri, Oct 7, 2016 at 5:32 AM, Mr. Jaehoon Paul Jeong
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>> wrote:
Hi Linda,
As a coauthor of this draft, I will answer your questions inline below.

On Wed, Oct 5, 2016 at 1:34 PM, Linda Dunbar
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:
Hyoungshick, et al,

How would you position your draft-kim-i2nsf-security-management-architecture-01
with regard to the I2NSF framework draft? I find there are a lot of duplicated
content to the I2nsf framework draft.

[Paul] We would like to merge our draft into the i2nsf framework draft
because our draft has one depth more detailed architecture.
This detailed architecture will be helpful to implement the i2nsf framework.

There are some differences, such as the following: Are you trying to define
how “security policy” is structured?

[Paul] Our architecture allows an NSF to update a low-level policy and apply
it to the related high-level policy
via the control path of Security Controller and Policy Collector (renamed
Event Collector in version 02) in Figure 1
of our version 02:
https://tools.ietf.org/html/draft-kim-i2nsf-security-management-architecture-02

For example, if an NSF of firewall detects a new DoS-attack host, it reports
the updated blacklist having
the IP address of such a host to Application Logic in I2NSF Client via
Security Controller and Event Collector.
Application Logic asks Policy Updater to disseminate the updated blacklist to
the security controllers
under the administration of the same I2NSF Client.

Will the “High Level security management” eventually lead to Client Facing
Policy data models?

[Paul] Yes, as explained above, the High-level security management leads to
update and handle Client facing policy
data models.

Do you plan to define interfaces between all those components depicted in
Figure 1? The interfaces between some of those components are not really in
the I2NSF WG current charter, such as “Security Policy Manager” <-> “NSF
Capability Manager”, or the interface between “Application Logic” <-> “Policy
Updater”.

[Paul] Yes, we have a plan to define such interfaces.

Are those components in your current implementation? Is it like an “example of
one implementation”?

[Paul] Though those components are not fully implemented yet in our
implementation, my team at SKKU
will make implement those components in a later version.

Thanks for your clarification questions.

Best Regards,
Paul

Thanks, Linda

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] Definition for "Consumer" in I2NSF terminology , in the context of "Client Facing Interface"

2016-10-17 Thread Diego R. Lopez

And what about “tenant or “user" rather than “customer”?

Be goode,

On 17 Oct 2016, at 22:28 , Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

John,

Maybe we should call it “customer-facing-interface” instead of 
“consumer-facing-interface”?

Linda

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, October 17, 2016 3:23 PM
To: John Strassner <straz...@gmail.com<mailto:straz...@gmail.com>>
Cc: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: [I2nsf] Definition for "Consumer" in I2NSF terminology , in the 
context of "Client Facing Interface"

John,

There are two types of interface described in I2NSF framework:
-one is NSF facing interface, over which  rules  or policies can be 
expressed based on ports/IP addresses for packets traversing through a NSF;
-another is the interface for Clients, users, tenants, to express/query 
rules that are expressed in users own ID, address domains, etc. Commonly called 
“Client facing interface”.

You have suggested to use “Consumer facing Interface”. But the definition of 
“Consumer” in I2NSF Terminology -01, doesn’t really reflect the idea of rules 
being expressed from the perspective of clients or users.

If we use this terminology, “Consumer” interface can also face NSFs as well.

  Consumer:  A Consumer is a Role that is assigned to an I2NSF
  Component that can receive information from another I2NSF
  Component.  See also:  Provider, Role.


Can you clarify ?

Thanks, Linda
___
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] Process discussion on draft-kumar-i2nsf-client-facing-interface-req-00

2016-10-03 Thread Diego R. Lopez

nswers to these questions.
You may find the slides used in WG chair training to be helpful 
https://www.ietf.org/edu/documents/IETF78-WGchairs-Adrian-Farrel.pdf

I would add one more important point:
When an I-D is a WG I-D, the WG controls the content. The editors are obliged 
to address issues raised by the WG (either updating the document or rejecting 
raised concerns) under the principle of consensus.
When an I-D is an individual I-D, the authors can include or exclude whatever 
they like.
Thus, when a WG wants to work on a topic my view is that it is good to get the 
document into the care of the WG as soon as possible.


But I will leave further discussion of progressing this document under the care 
of my co-chair.

Cheers,
Adrian

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] could you please address comments from Diego Lopez on draft-kumar-i2nsf-client-facing-interface-req-00 and revise the draft accordingly?

2016-09-30 Thread Diego R. Lopez

Hi,

I will be happy to look at this new revision and consider it for adoption. In 
the meantime, I find the current -00 not mature enough.

Be goode,

On 29 Sep 2016, at 01:30 , Rakesh Kumar 
<rkku...@juniper.net<mailto:rkku...@juniper.net>> wrote:

Hi Linda,

I have communicated earlier through private channel to folks who provided 
comments that we would create a new revision but I am still waiting on inputs 
from couple of other folks. I wanted to combine all the comments into one 
update, avoid unnecessary cycles and save time.

Thanks & Regards,
Rakesh

From: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Date: Wednesday, September 28, 2016 at 2:23 PM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>
Cc: "i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>
Subject: could you please address comments from Diego Lopez on 
draft-kumar-i2nsf-client-facing-interface-req-00 and revise the draft 
accordingly?

Rakesh,

Searching through the mailing list achieve, I find the comments from Diego 
Lopez on your draft hasn’t been addressed nor reflect in your draft. Can you 
address them and revise the draft accordingly?

Thank you very much.

Linda


https://mailarchive.ietf.org/arch/search/?email_list=i2nsf_from=diego.r.lopez%40telefonica.com



Re: [I2nsf] New Version Notification for 
draft-kumar-i2nsf-client-facing-interface-req-00.txt

"Diego R. Lopez" 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>> Tue, 09 
August 2016 17:37 UTCShow 
header<https://mailarchive.ietf.org/arch/msg/i2nsf/nKbb546VyxO7fOD46Pf3QKf5G5s>

Return-Path: <diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>
X-Original-To: i2...@ietfa.amsl.com<mailto:i2...@ietfa.amsl.com>
Delivered-To: i2...@ietfa.amsl.com<mailto:i2...@ietfa.amsl.com>
Received: from localhost (localhost [127.0.0.1]) by 
ietfa.amsl.com<http://ietfa.amsl.com/> (Postfix) with ESMTP id 9B85E12D1C2 for 
<i2...@ietfa.amsl.com<mailto:i2...@ietfa.amsl.com>>; Tue, 9 Aug 2016 10:37:32 
-0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com<http://amsl.com/>
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 
RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org<http://mail.ietf.org/> ([4.31.198.44]) by 
localhost (ietfa.amsl.com<http://ietfa.amsl.com/> [127.0.0.1]) (amavisd-new, 
port 10024) with ESMTP id 5G-Tb8kz3Zbe for 
<i2...@ietfa.amsl.com<mailto:i2...@ietfa.amsl.com>>; Tue, 9 Aug 2016 10:37:29 
-0700 (PDT)
Received: from smtptc.telefonica.com<http://smtptc.telefonica.com/> 
(smtptc.telefonica.com<http://smtptc.telefonica.com/> [195.76.34.108]) (using 
TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate 
requested) by ietfa.amsl.com<http://ietfa.amsl.com/> (Postfix) with ESMTPS id 
9CC3412D128 for <i2nsf@ietf.org<mailto:i2nsf@ietf.org>>; Tue, 9 Aug 2016 
10:37:27 -0700 (PDT)
Received: from smtptc.telefonica.com<http://smtptc.telefonica.com/> 
(tgtim3c01.telefonica.com<http://tgtim3c01.telefonica.com/> [127.0.0.1]) by 
IMSVA (Postfix) with ESMTP id 756C04610C6; Tue, 9 Aug 2016 19:37:25 +0200 (CEST)
Received: from ESTGVMSP113.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using 
TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP113", Issuer 
"ESTGVMSP113" (not verified)) by 
smtptc.telefonica.com<http://smtptc.telefonica.com/> (Postfix) with ESMTPS id 
5CA494610C0; Tue, 9 Aug 2016 19:37:25 +0200 (CEST)
Received: from 
EUR01-HE1-obe.outbound.protection.outlook.com<http://eur01-he1-obe.outbound.protection.outlook.com/>
 (10.92.5.139) by tls.telefonica.com<http://tls.telefonica.com/> (10.92.6.55) 
with Microsoft SMTP Server (TLS) id 14.3.266.1; Tue, 9 Aug 2016 19:37:24 +0200
Received: from 
DB6PR0601MB2167.eurprd06.prod.outlook.com<http://db6pr0601mb2167.eurprd06.prod.outlook.com/>
 (10.168.57.26) by 
DB6PR0601MB2167.eurprd06.prod.outlook.com<http://db6pr0601mb2167.eurprd06.prod.outlook.com/>(10.168.57.26)
 with Microsoft SMTP Server (version=TLS1_2, 
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 9 Aug 
2016 17:36:22 +
Received: from 
DB6PR0601MB2167.eurprd06.prod.outlook.com<http://db6pr0601mb2167.eurprd06.prod.outlook.com/>
 ([10.168.57.26]) by 
DB6PR0601MB2167.eurprd06.prod.outlook.com<http://db6pr0601mb2167.eurprd06.prod.outlook.com/>([10.168.57.26])
 with mapi id 15.01.0549.025; Tue, 9 Aug 2016 17:36:22 +
From: "Diego R. Lopez" 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com&g

Re: [I2nsf] Call for WG adoption of draft-kumar-i2nsf-client-facing-interface-req

2016-09-27 Thread Diego R. Lopez

Hi,

Im my view, the -00 version is not mature enough to be adopted. Adopting a -00 
is rather unusual for good reasons: before WG adoption drafts usually need to 
gather comments and increase the consensus they can reach within the community.

In particular, I would have liked to see a -01 version addressing the comments 
I originally shared on the list at the beginning of August.

Be goode,


On 21 Sep 2016, at 19:54 , Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

Dear WG:

This email serves as a call for WG adoption of 
draft-kumar-i2nsf-client-facing-interface-req as a WG document. The call for 
adoption will run for 2 weeks ending Oct 5, 2016.
The requirement document is one of the key deliverables specified by the  I2NSF 
charter.

Please note that this is a call for adoption, and not a last call for content 
of the document. Adopting a WG document simply means that the WG will focus its 
efforts on that particular draft going forward, and use that document for 
resolving open issues and documenting the WG’s decisions.

Please indicate whether you support adoption for not, and if not why. Issues 
you have with the current document itself can also be raised, but they should 
be raised in the context of what should be changed in the document going 
forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that applies 
to this draft, in line with the IPR disclosure obligations for WG participants 
(see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a 
document author please respond to this email (to the chairs) whether or not you 
are aware of any relevant IPR
https://tools.ietf.org/id/draft-kumar-i2nsf-client-facing-interface-req-00.txt


Authors: there are some editorial changes needed to comply with the I2NSF 
terminologies that the WG has agreed, in particular:
-Abstract: needs to change the starting sentence to “This document 
provides a framework and requirement ….”
-Change all reference of “North Bound Interface” to “Client/consumer 
facing interface”.

Thank you,

Linda & Adrian

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

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

Re: [I2nsf] what is the "client" to I2NSF controller? (was RE: Should we call "South Bound Interface" for the interface between "controller <-> NSF", and "North Bound Interface" for the interface betw

2016-06-30 Thread Diego R. Lopez

lity layer”.


Agree. So let's get rid of Capability **layer**. It isn't a layer, because...

...wait for it...

...Capabilities could be used to describe NSF functions as well as Controller 
functions. Thus, there is no "layer" in the classical definition of the term 
"layer".


Therefore, we are asking people to state which of  the following options should 
be used:


1.  Use “Client Facing Interface” for "Client <-> controller"; and “NSF 
Facing Interface” for "controller <-> NSF",

2.  Use “Controller North Bound Interface” for "Client <-> controller"; and 
“Controller South Bound Interface” for “controller <-> NSF", or

Or you can provide a better option.


I choose option 3. :-)

The problem with "Client-Facing Interface" is that I'm not sure what a "Client" 
is in NSF.
NSF-Facing Interface is OK; my problem is, why are we introducing Yet Another 
Term?

The problem with Northbound and Southbound is that there is no clear "north" 
and "south" here. Look at all of the projects that propose various data models 
at both the device interface level AND the network management application 
layer. So tell me, which is "south" here? :-)

Now, as for option 3, I'm thinking about it. However, I do think that you have 
spotted an important inconsistency, so let's take time to fix it and not rush 
into rash decisions.


best regards,
John



On Thu, Jun 23, 2016 at 3:31 PM, Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

I2NSF WG:



Need your opinion for a good name to represent “Client Facing Interface” and 
“NSF Facing Interface” of the I2NSF reference model:
  +-+
  |  I2NSF Client   |
  | E.g. Overlay Network Mgnt, Enterprise network Mgnt  |
  |  another network domain’s mgnt, etc.|
  +--+--+
 |
 |  Client Facing Interface
 |
   +-+---+
   |Network Operator mgmt|   +-+
   | Security Controller | < - > | Developer’s |
   +--+--+  Registration | Mgnt System |
  |  Interface   +-+
  |
  | NSF Facing Interface
  |
   +--++
   |   |
   |   |
   +---+--+ +--+ +--+   +--+---+
   + NSF-1+ --- + NSF-n+ +NSF-1 + - +NSF-m +  . . .
   +--+ +--+ +--+   +--+

   Vendor A   Vendor B





During the I2NSF early stage (before the WG was created), "capability 
interface" was used to represent the interface between controller <-> NSF, and 
"service interface" was used to represent the interface between the Client <-> 
controller.



As many people use the terminologies loosely, the "Capability Interface" being 
interchangeably used with "Capability Layer", and "Service Interface" being 
interchangeably used with "Service Layer".



The I2NSF Terminology Draft has defined the "Capability Layer" (independent of 
which interface to the controller) for exposing the capability of a domain 
(over Client Facing   Interface), or for exposing the capability of a NSF (over 
the NSF Facing Interface).

By this definition, ECA Policy’s "Event" capability can be discovered 
independently from the "Condition" capability, or "Action" capability.


Therefore, continue using the  “Capability Interface” can cause more confusion 
in the future as its sound is too close to the “Capability layer”.

Therefore, we are asking people to state which of  the following options should 
be used:


1.  Use “Client Facing Interface” for "Client <-> controller"; and “NSF 
Facing Interface” for "controller <-> NSF",

2.  Use “Controller North Bound Interface” for "Client <-> controller"; and 
“Controller South Bound Interface” for “controller <-> NSF", or

Or you can provide a better option.

Thanks, Linda



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



--
regards,
John



--
regards,
John
___
I2nsf mailing list
I2nsf@ietf.org<m

Re: [I2nsf] Starting to think about an agenda for I2NSF in Berlin

2016-06-23 Thread Diego R. Lopez

Hi,

Though I have not been able to update the attestation draft (and the framework 
one in accordance) I am reasonably sure I will be able to do so before the 
cut-off date, so I’d ask for 5-10 minutes to talk about these updates, under 
requirements and protocols,.

Be goode,

On 20 Jun 2016, at 19:00 , Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

Hi working group,

Linda and I have been thinking about the agenda for Berlin. We think that we
should continue to focus on our charter and deliverables doing what is necessary
to advance our milestones. Broadly we could split our 2 hours as:

30 minutes status of WG and progress of WG documents
30 minutes requirements for and selection of protocols (and security
considerations)
30 minutes information model discussion
30 minutes other drafts and discussions

We'd like to hear your proposals for things that need to be discussed in these
categories so that we can start to put a detailed agenda together.

Thanks,
Adrian and Linda



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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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




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

68 matches

Mail list logo