Re: [I2nsf] WG scope follow-up

[John Strassner]

+1

regards,
John

On Thu, Jul 25, 2019 at 2:08 PM Xialiang (Frank, Network Standard & Patent
Dept)  wrote:

> +1
>
>
>
> --
> 夏靓 Frank
> Mobile: +86-13913840549/+86-18651800549
> Email: frank.xiali...@huawei.com
> *发件人：*Diego R. Lopez 
> *收件人：*Roman Danyliw ;i2nsf@ietf.org 
> *时间：*2019-07-25 16:57:18
> *主 题：*Re: [I2nsf] WG scope follow-up
>
> Hi Roman,
>
> I'd not go for a re-chartering unless other work items on security
> management (and related to the I2NSF model) are identified. I'd say the WG
> has been successful in achieving its original goals, and results like this,
> while valuable, should be directed to another initiative, like the current
> YANG-NextGen being discussed. A similar case would be some work on
> attestation, that was somehow at the origin of RATS, and probably will end
> there.
>
> Be goode,
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> https://www.linkedin.com/in/dr2lopez/
>
> e-mail: diego.r.lo...@telefonica.com
> Tel: +34 913 129 041
> Mobile:  +34 682 051 091
> --
>
> On 25/07/2019, 16:45, "I2nsf on behalf of Roman Danyliw" <
> i2nsf-boun...@ietf.org on behalf of r...@cert.org> wrote:
>
> Hello!
>
> During today's F2F meeting, we discussed the need to check the charter
> scope of the work proposed in
> draft-yang-i2nsf-security-policy-translation.  Making no value judgement on
> the utility of the work, in my review of the current charter, this class of
> work is not in scope.  The current charter doesn't currently cover
> standardization activity inside the NSF/DMS/controller.
>
> If the WG wants to re-charter, by all means, let's have that
> conversation.
>
> Roman
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>
>
> 
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>


-- 
regards,
John
___
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

[John Strassner]

I am not aware of any IPR related to this draft

Regards,
John

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Diego R. Lopez
Sent: Thursday, April 18, 2019 11:46 AM
To: Linda Dunbar ; i2nsf@ietf.org
Subject: Re: [I2nsf] 答复: WGLC and IPR poll for draft-ietf-i2nsf-capability-04

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
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> 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] what does the term "Policy Domain" commonly refer to? (was RE: WG Adoption call for https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-facing-interface-dm-04

[John Strassner]

Yes,

I am objecting to a tenant owning a policy. That is backwards. Policies are
owned by Administrative Domains.

Yes, an organization could be an Administrative Domain. More likely, an
Organization has multiple groups (OUs in the X.500/LDAP world, departments
in English) that are each Administrative Domains. In this situation,
policies are hierarchical (higher controls lower, lower cannot conflict
with higher). So each Administrative Domain applies its set of policies (if
any) to a tent (typically a person or OU).

regards,
John

On Tue, Feb 13, 2018 at 3:31 PM, Linda Dunbar <linda.dun...@huawei.com>
wrote:

> John,
>
>
>
> Do you mean the term “Admin-Domain” can be used to represent a group of
> Tenants? For example: “Admin Domain” can be a company, and each Tenant can
> be a department within the company?  One “Admin Domain” has many “Tenants”?
>
>
>
> Thank you.
>
>
>
> Linda
>
>
>
>
>
>
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Monday, February 12, 2018 5:22 PM
> *To:* Linda Dunbar <linda.dun...@huawei.com>
> *Cc:* i2nsf@ietf.org
> *Subject:* Re: [I2nsf] what does the term "Policy Domain" commonly refer
> to? (was RE: WG Adoption call for https://tools.ietf.org/html/
> draft-jeong-i2nsf-consumer-facing-interface-dm-04
>
>
>
> It is hard to tell due to lack of specificity, but likely it is NOT a
> correct use of the term.
>
> The relationship is backwards - a tenant does NOT control policies.
> Rather, an
>
> admin domain (i.e., a policy domain) control policies, and tenants exist
> in an
>
> admin domain.
>
>
>
> This is what I meant in my brief comment.
>
>
>
> regards,
>
> John
>
>
>
> On Mon, Feb 12, 2018 at 9:05 AM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
> John,
>
>
>
> Thank you very much for the interpretation of “Policy Domain”.
>
>
>
> Based on the reply from Paul, the term “Policy Domain” in their draft is
> about a “Family (or a group) of Tenants”.
>
> Is it a proper to use “Policy domain” as a term referring to the domain
> applying to a family or a group of tenants? Say a group of Departments
> (tenants) belonging under one organization?
>
>
>
> If not, can you suggest a better term?
>
>
>
> Thank you.
>
>
>
> Linda
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Thursday, February 08, 2018 6:08 PM
> *To:* Linda Dunbar <linda.dun...@huawei.com>
> *Cc:* i2nsf@ietf.org
> *Subject:* Re: [I2nsf] what does the term "Policy Domain" commonly refer
> to? (was RE: WG Adoption call for https://tools.ietf.org/html/
> draft-jeong-i2nsf-consumer-facing-interface-dm-04
>
>
>
> A "Policy Domain" is an administrative domain in which a set of Policies
> are used to ensure that managed entities in that domain behave in a desired
> manner. Policies can be used for configuration, monitoring, access control,
> and other behavior.
>
>
>
> Note that this is a standard term in the academic literature.
>
>
>
>
>
> regards,
>
> John
>
>
>
> On Thu, Feb 8, 2018 at 2:59 PM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
> John,
>
>
>
> Since you are the policy expert, what does “Policy Domain” commonly refer
> to?
>
> Can “Policy domain” be one policy applying to a set of tenants? Or one
> policy applying to a set of geographic regions? Or Policy domain being a
> set of policies?
>
>
>
> Thank you.
>
> Linda
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Tuesday, February 06, 2018 5:47 PM
> *To:* Linda Dunbar <linda.dun...@huawei.com>
> *Cc:* i2nsf@ietf.org
> *Subject:* Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/
> draft-jeong-i2nsf-consumer-facing-interface-dm-04
>
>
>
> IMHO, the purpose of a WG adopting a draft is to acknowledge that the
> draft is a good starting point for the work that WG wants to accomplish. To
> be perfectly clear, I am NOT objecting on the completeness of the document.
> Rather, I am objecting on the technical correctness of the starting point.
>
>
> I do NOT feel that the proposed documents represent a good starting point.
> Ignoring things that can be easily fixed (e.g., grammar), there are a host
> of problems, such as:
>
>- what, exactly, is this draft trying to do? I thought I would see YANG
> for policy rules sent over the Consumer-Facing Interface.
>  Instead, I see the name of the interface, whose first element is
> multi-tenancy, that also contains policies? Policies do not care
>  about multi-tenancy. The

Re: [I2nsf] what does the term "Policy Domain" commonly refer to? (was RE: WG Adoption call for https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-facing-interface-dm-04

[John Strassner]

A "Policy Domain" is an administrative domain in which a set of Policies
are used to ensure that managed entities in that domain behave in a desired
manner. Policies can be used for configuration, monitoring, access control,
and other behavior.

Note that this is a standard term in the academic literature.


regards,
John

On Thu, Feb 8, 2018 at 2:59 PM, Linda Dunbar <linda.dun...@huawei.com>
wrote:

> John,
>
>
>
> Since you are the policy expert, what does “Policy Domain” commonly refer
> to?
>
> Can “Policy domain” be one policy applying to a set of tenants? Or one
> policy applying to a set of geographic regions? Or Policy domain being a
> set of policies?
>
>
>
> Thank you.
>
> Linda
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Tuesday, February 06, 2018 5:47 PM
> *To:* Linda Dunbar <linda.dun...@huawei.com>
> *Cc:* i2nsf@ietf.org
> *Subject:* Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/
> draft-jeong-i2nsf-consumer-facing-interface-dm-04
>
>
>
> IMHO, the purpose of a WG adopting a draft is to acknowledge that the
> draft is a good starting point for the work that WG wants to accomplish. To
> be perfectly clear, I am NOT objecting on the completeness of the document.
> Rather, I am objecting on the technical correctness of the starting point.
>
>
> I do NOT feel that the proposed documents represent a good starting point.
> Ignoring things that can be easily fixed (e.g., grammar), there are a host
> of problems, such as:
>
>- what, exactly, is this draft trying to do? I thought I would see YANG
> for policy rules sent over the Consumer-Facing Interface.
>  Instead, I see the name of the interface, whose first element is
> multi-tenancy, that also contains policies? Policies do not care
>  about multi-tenancy. They do care about domains. The organization of
> the YANG is incorrect.
>
>- sec 4: in the ieft-i2nsf-cf-interface module
>
>   - why is multi-tenancy at the top of the tree? Shouldn't a DOMAIN
> be able to have multiple tenants?
>
>   - why does a domain have an authentication-method? First, multiple
> such methods should be able to be used. Second, how would a domain know
> what an authentication method even is?
>
>   - why is tenant a sibling of domain, and not a child?
>
>   - why is domain a leaf within policy-tenant? This should be a
> reference, and why doesn't domain have a reference to policy-tenant?
>
>   - policy roles have nothing to do with multi-tenancy - why are they
> here?
>
>
>
>  I could go on, but even the above means that the rest of the YANG will be
> wrong.
>
>
>
> Therefore, the document is NOT a good starting point, and will NOT
> accelerate the path to getting a good RFC.
>
>
>
> regards,
>
> John
>
>
>
> On Fri, Jan 26, 2018 at 3:23 PM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
>
>
>
>
> The authors of I2NSF Consumer-Facing Interface YANG Data Model
>
> https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-
> facing-interface-dm-04
>
>
>
> Have requested working group adoption of this draft.
>
>
>
> 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
>
>
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>
>
>
> --
>
> regards,
>
> John
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>


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

Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04

[John Strassner]

IMHO, the purpose of a WG adopting a draft is to acknowledge that the draft
is a good starting point for the work that WG wants to accomplish. To be
perfectly clear, I am NOT objecting on the completeness of the document.
Rather, I am objecting on the technical correctness of the starting point.

I do NOT feel that the proposed documents represent a good starting point.
Ignoring things that can be easily fixed (e.g., grammar), there are a host
of problems, such as:

   - sec 4: it is unclear what is meant by "Objectives", see below
  - sec 4.1 does NOT define what an I2NSF SecurityPolicyRule is, or
what its objective is
  - secs 4.2 and 4.3 do provide definitions of events and conditions
(though their grammar needs improvement)
  - sec 4.4 provides a superficial definition of an action that needs
tightening up

The above are troublesome, as all definitions are clearly defined in the
terminology draft. For a long time now... :-( And I really don't understand
why this section is labeled "Objectives". Objectives of what? An event? of
the data model? something else?

   - sec 5.1:  I don't understand the design of the YANG module at all
 - the ietf-i2nsf-nsf-facing-interface module appears to describe a
policy rule, but is given the name of an interface. In addition, why
does generic-nsf
contain a policy (i2nsf-security-policy)? Put another way, the name of the
module is the name of an interface, but doesn't describe an interface, and
more importantly,
NSFs do NOT contain policy rules - they are sent policy rules by
the policy engine
 - Worse, why are the event, condition, and action containers NOT
inside the policy rule?
   - Same problem for figures 5.2-5.4, plus other problems (e.g., why is
the resolution strategy NOT a part of the policy???)
   - the design of the condition clause is not scalable. In an OO design,
one does NOT simply list a hundred attributes in a class. We decided that
the YANG module would be designed in an OO style.
   - same problem for the action clause

Given the above, the rest of the YANG will be wrong.

Therefore, the document is NOT a good starting point, and will NOT
accelerate the path to getting a good RFC.

regards,
John

On Fri, Jan 26, 2018 at 3:21 PM, Linda Dunbar 
wrote:

>
>
> The authors of I2NSF Network Security Functions-Facing Interface YANG Data
> Model
>
> https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-
> interface-data-model-04
>
>
>
> Have requested working group adoption of this draft.
>
>
>
> 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
>
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>


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

Re: [I2nsf] updates on the capability models

[John Strassner]

;cataldo.bas...@polito.it>
wrote:

> Hi John,
>
> answers in-line...
>
> In short, I agree on all points, I have a concern on ResolutionStrategy to
> be metadata, and confirm we need further discussions to continue the design
> on the points that have been marked as open issues by John.
>
>
> On 03/01/2018 16:11, John Strassner wrote:
>
>> Sorry for the delay in replying.
>>
>> First, Aldo is correct – the decorator pattern is used to both increase
>>
>> extensibility and to avoid object explosion (by having to enumerate each
>>
>> different function as a separate object).
>>
>> Second, I wouldn’t call the NSF-facing model a “superset” of the
>> capability
>>
>> model. Every concept that is in the NSF-facing model SHOULD be derived
>> from
>>
>> the Capability model (if that isn’t possible, then we need to extend the
>>
>> Capability model). This is very important – if this is not true, then
>> other
>>
>> data models that are NOT YANG models will not be interoperable with our
>>
>> YANG data model. Note that this doesn’t mean that a data model just
>> selects
>>
>> objects from the info model! Rather, it selects **concepts**, and then
>>
>> refines those concepts. For example, if the info model defines the concept
>>
>> of an operator, then a data model is free to define new types of
>> operators.
>>
>> In this example, if the operator was a class, the new operator types would
>>
>> be subclasses of the operator class.
>>
>> Now suppose that the info model did not define an operator class. Clearly,
>>
>> imperative policy rules need operators. The data model would have to
>> define
>>
>> an operator class – but where would it define it from? Let’s say it
>> chooses
>>
>> to define it from I2NSFPolicy (an obviously bad choice). If another data
>>
>> model (say, one using relational calculus) defines an operator from a
>>
>> different class (say, metadata, an equally bad choice), now you have
>> different
>>
>> semantics attached to the notion of an operator, since they are subclassed
>>
>> from different places. Say goodbye to interoperability.
>>
>> The above simple example is one reason why the different data models need
>> to
>>
>> be properly derived from the info model.
>>
>
>
> Insisting on deriving data models from info models in the proper way will
> never be enough, in my opinion.
> I agree I used superset in the improper way. In all cases, I meant a
> correct data model instance of an information model.
>
>
>
>> Your third question (about the long list of attributes) is subject to
>> opinion.
>>
>> I personally dislike classes with long list of attributes. Such a design
>> begs
>>
>> the question, “is this attribute really **only** applicable to this one
>> class?”
>>
>> For example, take an address. It is common to have separate classes for
>> IPv4
>>
>> and IPv6, since the structure of the address is fundamentally different.
>> Of
>>
>> course, MAC addresses are different from both, so as a simple example,
>> instead
>>
>> of listing a set of attributes that partially describe any one of these 3
>> types
>>
>> of addresses, why not have a NetworkAddress class, with 3 subclasses? This
>>
>> enables us to properly describe the semantics of the components of an
>> address,
>>
>> as well as relate other entities (e.g., a DHCP server) to those types of
>>
>> addresses that need it.
>>
>
> Agreed.
>
> [omissis]
>
>
>> New Concepts from the PDF File
>>
>> Packets and Protocols
>>
>> I don’t like Packets being defined as a type of metadata. The reasoning is
>>
>> Similar as that for not subclassing events, conditions, and actions from
>>
>> metadata. This also applies to Protocols.
>>
>
> I see packets mainly as aggregations of PolicyTargets, for our
> policy-based management purposes.
>
>
>> StateInfo
>>
>> This is harder. One could argue that state information describes (and
>>
>> prescribes) the behavior of an object. One could also argue that state is
>>
>> very important (note that state is handled separately in YANG), and as
>> such,
>>
>> should be its own distinct object. I typically model state as a separate
>>
>> object, because it simplifies the understanding of behavioral
>> specifications
>>
>> (e.g., a state could b

Re: [I2nsf] updates on the capability models

[John Strassner]

Hi Linda,

Please see inline.

Regards,
John

From: Linda Dunbar
Sent: Wednesday, January 03, 2018 10:27 AM
To: John Strassner <john.sc.strass...@huawei.com>; Aldo Basile 
<cataldo.bas...@polito.it>; John Strassner <straz...@gmail.com>
Cc: i2nsf@ietf.org
Subject: RE: [I2nsf] updates on the capability models

John,

Thank you very much for the detailed explanation. Took me awhile to carefully 
reading through your writing. Felt like reading a college class assignment.

Sorry, I wrote this on the plane trip to Shenzhen. I am a tenured professor, 
but that was not my intent. ☺


Are you going to update the capability draft accordingly?

I will wait for feedback from at least the Capability draft co-authors, and 
then lead the editing of this draft.


You stated to have separate “I2NSFSecurityPolicyRule and I2NSFDecoratorRule”. 
Do users (e.g. Controller or Admin who issue the policy rules) have to be aware 
which one to use?

NO!
The power of the decorator pattern is to provide a single interface to the 
“base class” (in this case, I2NSFSecurityPolicyRule). The client is blissfully 
unaware of whether additional objects wrap the base class. :-)


Are the “event”, “condition” and “action” part of I2NSFPolicyComponent?

YES! Remember, an I2NSFPolicyRule aggregates an event clause, a condition 
clause, and an action clause. Conceptually, think of an I2NSFPolicyRule as 
aggregating one or more I2NSFPolicyComponents.


What are the examples of sibling class to I2NSFEvent, I2NSFCondition, and 
I2NSFAction?  Can you add the examples to the updated draft? To make it easier 
for people to comprehend.

Any object that is a part of an I2NSFPolicyRule (except for I2NSFMetadata) can 
be a PolicyComponent (i.e., a sibling class). For example, take a look at 
Figure 13 of the SUPA draft. Event, Condition, and Action are the fundamental 
components of an ECA policy rule, but each of these can be optionally 
constructed from other objects. For example, a Boolean clause takes the form of 
{variable, operator, value} (e.g., numAlarms > 5). One could either use an 
atomic Event (or Condition in this example), or use individual objects (e.g., a 
PolicyVariable, a PolicyOperator, and a PolicyValue) to make up the Boolean 
clause.

I will add examples to the draft.


Can you also add some examples of “I2NSFMetadata class” in the updated draft?

Sure


Thank you very much.

Linda

From: John Strassner
Sent: Wednesday, January 03, 2018 9:11 AM
To: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>; 
Aldo Basile <cataldo.bas...@polito.it<mailto:cataldo.bas...@polito.it>>; John 
Strassner <john.sc.strass...@huawei.com<mailto:john.sc.strass...@huawei.com>>; 
John Strassner <straz...@gmail.com<mailto:straz...@gmail.com>>
Cc: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: RE: [I2nsf] updates on the capability models

Sorry for the delay in replying.

First, Aldo is correct – the decorator pattern is used to both increase
extensibility and to avoid object explosion (by having to enumerate each
different function as a separate object).

Second, I wouldn’t call the NSF-facing model a “superset” of the capability
model. Every concept that is in the NSF-facing model SHOULD be derived from
the Capability model (if that isn’t possible, then we need to extend the
Capability model). This is very important – if this is not true, then other
data models that are NOT YANG models will not be interoperable with our
YANG data model. Note that this doesn’t mean that a data model just selects
objects from the info model! Rather, it selects **concepts**, and then
refines those concepts. For example, if the info model defines the concept
of an operator, then a data model is free to define new types of operators.
In this example, if the operator was a class, the new operator types would
be subclasses of the operator class.

Now suppose that the info model did not define an operator class. Clearly,
imperative policy rules need operators. The data model would have to define
an operator class – but where would it define it from? Let’s say it chooses
to define it from I2NSFPolicy (an obviously bad choice). If another data
model (say, one using relational calculus) defines an operator from a
different class (say, metadata, an equally bad choice), now you have different
semantics attached to the notion of an operator, since they are subclassed
from different places. Say goodbye to interoperability.

The above simple example is one reason why the different data models need to
be properly derived from the info model.

Your third question (about the long list of attributes) is subject to opinion.
I personally dislike classes with long list of attributes. Such a design begs
the question, “is this attribute really **only** applicable to this one class?”
For example, take an address. It is common to have separate classes for IPv4
and IPv6, since the structure of the address i

Re: [I2nsf] updates on the capability models

[John Strassner]

 argue that state information describes (and
prescribes) the behavior of an object. One could also argue that state is
very important (note that state is handled separately in YANG), and as such,
should be its own distinct object. I typically model state as a separate
object, because it simplifies the understanding of behavioral specifications
(e.g., a state could be a set of attributes that need to be manipulated
Together). We should talk more about this before making a decision.


ConditionTarget
In the SUPA and MEF work, we defined a separate class called PolicyTarget.
The semantics of this date back to DEN-ng (defined in 2000), and build on
Sloman’s work in the late 90s, and are well established. It simplifies
understanding what a Policy Rule is working on and affecting – this is
especially true for imperative policies. I would recommend keeping
this approach and removing ConditionTarget.

If we do this, then PolicyTarget should inherit from the I2NSFPolicyRule
Class.

A possibly mitigating factor is the presence of the 2 associations (called
decidesBased and appliesOn in the PDF). I’m not sure what the purpose of
these associations are, so this may change the reasoning I gave.


Operation and OperationSet
The SUPA work defined a class called PolicyTerm (which is a type of
policy component decorator). PolicyTerm then defined three subclasses,
called PolicyVariable, PolicyOperator, and PolicyValue. The advantage
of this approach is that the information model can itself be used to
define a canonical type of expression in the form of a tuple:
  {variable, operator, value}

The disadvantage is more objects. However, in SUPA, as well as in the
MEF and DEN-ng efforts, the goal was model-driven engineering (i.e., the
model was both the design and the implementation). As such, reuse was
very important.

Since Events MUST have a type of operator (in order to form a Boolean
Clause), and since Actions MAY need operators, it seems appropriate to
generalize the notion of an operation, but make it accessible for events,
conditions, and actions. Hence, more discussion is needed here.


ResolutionStrategy
I agree that this is a class. However, I would subclass it from
I2NSFMetadata, not from SecurityCapability. This is because the
ResolutionStrategy is optional, and because it is used to prescribe
The behavior of the Policy Rule.


ClauseEvaluation
Sorry, I don’t understand what this is.


SecurityTemplate
This is a good idea!


SecurityCapability, DescribedBySecurityCapabilityDetail, NSF
I would change this design.

An NSF MAY be described by 0 or more SecurityCapabilities. Hence,
there should be an aggregation from NSF to SecurityCapability. Since
there can be many types of NSF that have many different types of
SecurityCapabilities, DescribedBySecurityCapabilityDetail should be
an association class. This yields the following design:

+-+0..n  0..n++
| |/ \  HasSecurityCapability||
| NSF | A --++ SecurityCapability |
| |\ /  ^||
+-+ |++
|
  +-+---+
  | HasSecurityCapabilityDetail |
  + +

This enables the HasSecurityCapabilityDetail association class to either
be the target of a Policy Rule (to define which SecurityCapabilities of
this NSF are visible and can be used – in other words, the Policy pattern)
and/or be associated with a SecurityTemplate.


Best regards,
John

From: John Strassner [mailto:straz...@gmail.com]
Sent: Tuesday, January 02, 2018 10:11 AM
To: John Strassner <john.sc.strass...@huawei.com>
Subject: Fwd: [I2nsf] updates on the capability models


-- Forwarded message --
From: Cataldo Basile <cataldo.bas...@polito.it<mailto:cataldo.bas...@polito.it>>
Date: Mon, Dec 4, 2017 at 1:50 AM
Subject: Re: [I2nsf] updates on the capability models
To: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Cc: "i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>


Dear Linda,

I may be wrong, but I remember that we discussed a change in the capability 
model to avoid sub-classing as a way to obtain different types of conditions, 
action, events, etc.

The new model, now under John's review, implements the decorator pattern, thus 
avoid sub-classing as conditions, action, events become instances (that can be 
easily generated, and also used dynamically at run-time and many other 
advantages).

Then, the NSF facing data model will probably be a superset of the capability 
model, obtained by extending it with concepts that are specific of NSF facing 
interface.

After having restructured the capability model we can discuss how this impacts 
the NSF facing data model.

Regards,
Aldo


On 30/11

Re: [I2nsf] Secdir telechat review of draft-ietf-i2nsf-framework-08

[John Strassner]

Dear Daniel,

thank you for performing this review. The following changes will be
implemented in version 9 of this I-D, to be released on Monday 11/13.
In particular,


Change the last paragraph in section 4,
from:
   The above threats may be mitigated by requiring the use of an AAA
   framework for all users to access the I2NSF environment. This could
   be further enhanced by requiring attestation to be used to detect
   changes to the I2NSF environment by authorized parties.

to:
   The use of authentication, authorization, accounting, and audit
   mechanisms is recommended for all users and applications to access
   the I2NSF environment. This can be further enhanced by requiring
   attestation to be used to detect changes to the I2NSF environment
   by authorized parties. The characteristics of these procedures will
   define the level of assurance of the I2NSF environment.

Change section 6.1
from:
6.1.  Network Connecting I2NSF Users and the I2NSF Controller

   ...
   Upon successful authentication, a trusted connection between the
   user and the I2NSF Controller (or an endpoint designated by it) will
   be established.  All traffic to and from the NSF environment ...

to:
6.1. Network Connecting I2NSF Users and the I2NSF Controller

   ...
   Upon successful authentication, a trusted connection between the
   user and the I2NSF Controller (or an endpoint designated by it) will
   be established. This means that a direct, physical point-to-point
   connection, with physical access restricted according to access
   control, must be used. All traffic to and from the NSF environment...

Change 6.2:
from:
6.2.  Network Connecting the I2NSF Controller and NSFs
   ...

to:
6.2.  Network Connecting the I2NSF Controller and NSFs

   ...
   Therefore, the transport mechanism used to carry the control messages
   and monitoring information should provide reliable message delivery.
   TCP is the obvious current choice, but others such as Multipath TCP
   (MPTCP) and the Stream Control Transmission Protocol (SCTP) would
   be applicable as well.  Latency requirements for control message delivery
   must also be evaluated.
   ...
   I2NSF needs to rely on the use of standard I2NSF interfaces to
   properly verify peer identities (e.g., through an AAA framework).
   The implementations of identity management functions, as well as
   the AAA framework, are out of scope for I2NSF.

to:
   ...
   Therefore, the transport mechanism used to carry management data and
   information must be secure. It does not have to be a reliable
   transport; rather, a transport-independent reliable messaging
   mechanism is required, where communication can be performed reliably
   (e.g., by establishing end-to-end communication sessions and by
   introducing explicit acknowledgement of messages into the
   communication flow). Latency requirements for control message
   delivery must also be evaluated. Note that monitoring does not
   require reliable transport.
   ...
   The network connection between the I2NSF Controller and NSFs will
   use the trusted connection mechanisms described in section 6.1.
   Following these mechanisms, the connections need to rely on the use
   of properly verified peer identities (e.g., through an AAA
   framework). The implementations of identity management functions, as
   well as the AAA framework, are out of scope for I2NSF.

In addition, please see other changes to this thread (yesterday and this
morning, local time Singapore)

best regards,
John

On Tue, Oct 24, 2017 at 3:48 PM, Daniel Franke  wrote:

> Reviewer: Daniel Franke
> Review result: Not Ready
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments
> were written primarily for the benefit of the security area directors.
> Document
> editors and WG chairs should treat these comments just like any other last
> call
> comments.
>
> This document is too broad and too vague for any reasonable security
> review to
> be possible. It expresses a desire to define a framework which satisfies
> certain requirements and use cases, but does not actually define anything
> concrete. At its most specific, the document gives parametricity
> constraints
> that future definitions must satisfy, such as being agnostic to network
> topology. This doesn't give me much to go on.
>
> The security considerations section is brief, calling out the need for
> access
> control and for protecting the confidentiality and integrity of data.
> Again,
> with so few specifics, there's not much more to be said.
>
> I do not think it is useful to anyone to publish this document as an RFC,
> not
> even an informational one. It is perfectly fine, when specifying an
> intricate
> suite of protocols, to have a separate document that gives a broad
> architectural overview of them all without delving into the specifics
> necessary
> for 

Re: [I2nsf] Suresh Krishnan's No Objection on draft-ietf-i2nsf-framework-08: (with COMMENT)

[John Strassner]

Dear Suresh,

thank you for performing this review. All of your issues will be addressed
in version 9 of this I-D, to be released on Monday 11/13. In particular,
the addr field in .table 1 is removed, since it is redundant with the source
and destination address fields. Sorry about that!

Other drafts that are currently in progress may extend these (e.g., match
on prefix); the intent here is to define a minimum set of fields to match
for interoperability.


best regards,
John

On Thu, Oct 26, 2017 at 7:05 AM, Suresh Krishnan  wrote:

> Suresh Krishnan has entered the following ballot position for
> draft-ietf-i2nsf-framework-08: No Objection
>
> 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-framework/
>
>
>
> --
> COMMENT:
> --
>
> I am not sure what the "addr" field in the Packet Content Matching
> Capability
> Index for IPv6 means (i.e. what protocol field it corresponds to) and I
> think
> it should be clarified.
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>



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

Re: [I2nsf] Alvaro Retana's No Objection on draft-ietf-i2nsf-framework-08: (with COMMENT)

[John Strassner]

Dear Alvaro,

thank you for performing this review. All of your issues will be addressed
in version 9 of this I-D, to be released on Monday 11/13. In particular,


I’m not sure what is the intent with rfc5575 (Dissemination of Flow
Specification Rules) is in 9.2.  I’m confused because the reference is
Normative, but the text sounds as if FlowSpec was an example:

We changed the boiplerplate to RFC8174, so the reference is now
informative.


Also, the tables present categories that go beyond what FlowSpec covers.
Where
does the other information come from?  Is there work that can reused there?
What about IPFIX (that seems more appropriate than FlowSpec)?

References to IPFIX work and the IANA IPFIX Registry has been added


best regards,
John

On Wed, Oct 25, 2017 at 2:04 PM, Alvaro Retana 
wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-i2nsf-framework-08: No Objection
>
> 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-framework/
>
>
>
> --
> COMMENT:
> --
>
> As Alissa mentioned in her Ballot, the long-term archival value of this
> draft
> is not clear to me either.
>
> There are some places where it is not clear what the intent of the
> document is
> wrt the references; are they examples, recommendations or do they
> represent a
> stronger pillar in the i2nsf work.  Just to highlight one of them:
>
> I’m not sure what is the intent with rfc5575 (Dissemination of Flow
> Specification Rules) is in 9.2.  I’m confused because the reference is
> Normative, but the text sounds as if FlowSpec was an example:
>
>9.2.  Registration Categories
>
>Developers can register their NSFs using Packet Content Match
>categories.  The IDR (Inter-Domain Routing) Flow Specification
>[RFC5575] has specified 12 different packet header matching types.
>More packet content matching types have been proposed in the IDR WG.
>I2NSF should re-use the packet matching types being specified as much
>as possible.  More matching types might be added for Flow-based NSFS.
>Tables 1-4 below list the applicable packet content categories that
>can be potentially used as packet matching types by Flow-based NSFs:
>
> Also, the tables present categories that go beyond what FlowSpec covers.
> Where
> does the other information come from?  Is there work that can reused there?
> What about IPFIX (that seems more appropriate than FlowSpec)?
>
> To be clear, I like very much the fact that the text advocates for reuse.
> It
> is just not clear what the expectation is with regards to rfc5575 or other
> proposed work in the idr WG.  Is the expectation that the matching types be
> used in i2nsf systems?  What about other related extensions that may be
> developed in idr, are there specific requirements or considerations that
> the
> idr WG should take into account?  From the archive, it looks like idr
> hasn’t
> reviewed (or been notified of) this document…
>
> Note that if the mention of rfc5575 is just an example, then I think some
> of
> the text could be made clearer (and the reference should be Informative).
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>



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

Re: [I2nsf] Alissa Cooper's No Objection on draft-ietf-i2nsf-framework-08: (with COMMENT)

[John Strassner]

Dear Alissa,

thank you for performing this review. All of your issues will be addressed
in version 9 of this I-D, to be released on Monday 11/13. In particular,

(1) I think there are some errors in Table 1, or perhaps there are just
formatting issues that have me confused.
It looks like TCP, SCTP, DCCP, UDP, and HTTP are listed under Layer 3.

FIXED


I can't tell if there is meant to be a
difference between header fields separated by slashes versus those
separated on
different lines.

There isn't, not sure how that got there. FIXED


There seems to be an extra column in front of the HTTP fields
-- what does that signify?

It signifies a formatting error. :-) FIXED


Why is TRAM profile in particular included as an
example here?

TRAM included work on authentication and authorization problems for TURN
and STUN in particular. That being said, I have no objection to removing
this row in the table; please advise.


(2) Tables 2-4 also seem to be specified in a significant amount of detail,
given that context and actions themselves are defined in detail in a
different
individual draft. This makes it hard to understand the implications of some
of
the fields. E.g., the "GPS coords" field -- whose GPS coords does this refer
to? It seems like the fields in these tables either need to be explained
more,
or they should be removed.

The following note was added:

Note: These fields are used to provide context information for I2NSF
  Policy Rules to make decisions on how to handle traffic. For
  example, GPS coordinates define the location of the traffic that
  is entering and exiting an I2NSF system; this enables the
  developer to apply different rules for ingress and egress
  traffic handling.


(3) I'm not going to stand in the way of publication but it's not clear to
me
why this document needs to be an RFC. Much of the content seems like a
generic
narrative that describes how NSFs could work but doesn't really lay out any
concrete constraints about how they should work that would lead to greater
interoperability.

It is meant to be a reference model, not a BCP or implementation guidelines.
That being said, we would welcome suggestions to provide additional
clarifying text.


best regards,
John

On Wed, Oct 25, 2017 at 1:48 PM, Alissa Cooper  wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-i2nsf-framework-08: No Objection
>
> 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-framework/
>
>
>
> --
> COMMENT:
> --
>
> (1) I think there are some errors in Table 1, or perhaps there are just
> formatting issues that have me confused. It looks like TCP, SCTP, DCCP,
> UDP,
> and HTTP are listed under Layer 3. I can't tell if there is meant to be a
> difference between header fields separated by slashes versus those
> separated on
> different lines. There seems to be an extra column in front of the HTTP
> fields
> -- what does that signify? Why is TRAM profile in particular included as an
> example here?
>
> (2) Tables 2-4 also seem to be specified in a significant amount of detail,
> given that context and actions themselves are defined in detail in a
> different
> individual draft. This makes it hard to understand the implications of
> some of
> the fields. E.g., the "GPS coords" field -- whose GPS coords does this
> refer
> to? It seems like the fields in these tables either need to be explained
> more,
> or they should be removed.
>
> (3) I'm not going to stand in the way of publication but it's not clear to
> me
> why this document needs to be an RFC. Much of the content seems like a
> generic
> narrative that describes how NSFs could work but doesn't really lay out any
> concrete constraints about how they should work that would lead to greater
> interoperability.
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>



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

Re: [I2nsf] Ben Campbell's No Objection on draft-ietf-i2nsf-framework-08: (with COMMENT)

[John Strassner]

Dear Ben,

thank you for performing this review. All of your issues will be addressed
in version 9 of this I-D, to be released on Monday 11/13.

Please note that I will change RFC2119 boilerplate to RFC8174
boilerplate. Specifically:

old text:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   Note:  as this is an informational document, no RFC-2119 key words
   are used.

new text:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Note:  as this is an informational document, no normative [RFC2119]
   [RFC8174] key words are used.


Dear Kathleen,

thank you for providing clarification and direction for addressing Ben's
comments. In particular,

the old bullet was:
   o  Closed environments, where there is only one administrative
  domain.  Less restrictive access control and simpler validation
  can be used inside the domain because of the protected nature of
  a closed environment.

the new bullet will be

   o  Closed environments, where there is only one administrative
  domain.  Such environments provide a more **isolated**
  environment, but still communicate over the same set of I2NSF
  interfaces present in open environments (see above). Hence, the
  security control and access requirements for closed environments
  are the same as those for open environments.


regards,
John

On Tue, Oct 24, 2017 at 8:18 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

>
>
> Sent from my iPhone
>
> > On Oct 24, 2017, at 11:08 PM, Ben Campbell  wrote:
> >
> > Ben Campbell has entered the following ballot position for
> > draft-ietf-i2nsf-framework-08: No Objection
> >
> > 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-framework/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > -2: If no 2119 keywords are used, please remove the boilerplate. But if
> you do
> > need to keep it, please use the updated boilerplate from 8174, since
> there are
> > a number of lower case versions of 2119 keywords.
> >
>
> Thanks, I have been catching this, but must have missed it in this draft.
>
> > -6.2: first bullet: I am always worried about text advising that "closed
> > environments" have lower security requirements. That has proven false so
> many
> > times we really shouldn't be encouraging it. This is especially
> worrisome since
> > the first paragraph of section 11 talks about the importance of
> "trustworthy,
> > robust, and fully secured access".
>
> Yes, good catch.  Was 'isolated' the intent here?  If so, that's fine to
> assume a higher level of trust, but unlikely to be using I2NSF.
>
> Thanks,
> Kathleen
> >
> >
> > ___
> > I2nsf mailing list
> > I2nsf@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2nsf
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>



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

Re: [I2nsf] Mirja Kühlewind's Discuss on draft-ietf-i2nsf-framework-08: (with DISCUSS)

[John Strassner]

Dear Mirja, Adrial, and Kathleen,

thank you for performing this review, and the discussions that followed.
I hope that the following addresses the issues that you have raised.
This content will be published in version 9 of this I-D, to be released on
Monday 11/13.

POINT #1
1) The first one should be easy to address:
"Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the
   Stream Control Transmission Protocol (SCTP) will need to be evaluated
   for applicability. "

This sentence is not correct; MPTP and SCTP do not provide any redundancy
mechanisms; they simply just provide a reliable transport as TCP does.
Therefore I would just remove this sentence here.

DONE


Further, on this paragraph, it is not clear to me why you say that reliable
transport is needed. Especially for some monitoring purposes, unreliable
transport might be acceptable as well. Or do you think that all
communication
for security systems have always to be reliable? I don't think this document
discusses things in detail enough to make such an assessment.

I believe that we need reliable transport for critical management-based
operations, but NOT for other mechanisms (e.g., monitoring). The following
text is proposed:

   Therefore, the transport mechanism used to carry management data and
   information must be secure. It does not have to be a reliable
   transport; rather, a transport-independent reliable messaging
   mechanism is required, where communication can be performed reliably
   (e.g., by establishing end-to-end communication sessions and by
   introducing explicit acknowledgement of messages into the
   communication flow). Latency requirements for control message
   delivery must also be evaluated. Note that monitoring does not
   reliable transport.


POINT 2
2a - Adrian's suggested text is implemented, but all normative language
(in UPPER CASE) is changed to informative language (in lower case)
since we are now using RFC8174 boilerplate.

2b - end of section 4:
"The above threats may be mitigated by requiring the use of an AAA
   framework for all users to access the I2NSF environment. This could
   be further enhanced by requiring attestation to be used to detect
   changes to the I2NSF environment by authorized parties.“

That is the present text; what would you suggest to strengthen it?



2c - sec 6.1:
„ Given the role of the I2NSF
   Controller, a mutual authentication of users and the I2NSF
   Controller may be required.“
Why not „is required“?

DONE



2c - And I’m also uncertain about this part in sec 6.2:
"The network connection between the I2NSF Controller and NSFs can
   rely either on:

   o  Closed environments, where there is only one administrative
  domain.  Less restrictive access control and simpler validation
  can be used inside the domain because of the protected nature of
  a closed environment.“

This text was changed to:

   o  Closed environments, where there is only one administrative
  domain.  Such environments provide a more **isolated**
  environment, but still communicate over the same set of I2NSF
  interfaces present in open environments (see above). Hence, the
  security control and access requirements for closed environments
  are the same as those for open environments.


best regards,
John

On Mon, Oct 23, 2017 at 8:15 AM, Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:

> Hi Adrian,
>
> see below.
>
> > Am 23.10.2017 um 17:00 schrieb Adrian Farrel :
> >
> > 
> >
> > Trying to extract actions for the authors from this interesting
> Discussion. I think that the first point is closed with Mirja still
> surprised, but no action needed.
>
> Yes...
>
> > The second point needs reinforcement of the need for strong security in
> the management (not control) plane used in the architecture: in particular,
> that the messages that configure network security functions must,
> themselves, else the security functions are vulnerable and so the whole
> network at risk.
> >
> > Section 11 currently reads...
> >
> > 11.  Security Considerations
> >
> >   NSF control and monitoring demand trustworthy, robust, and fully
> >   secured access.  Therefore, proper secure communication channels
> >   have to be carefully specified for carrying the controlling and
> >   monitoring information between the NSFs and their management
> >   entity or entities. This has been discussed in Section 4.
> >
> >   This framework is intended for enterprise users, with or without
> >   cloud service offerings. Privacy of users should be provided by
> >   using existing standard mechanisms, such as encryption;
> >   anonymization of data should also be done (if possible depending
> >   on the transport used). Such mechanisms require confidentiality
> >   and integrity.
> >
> > ... I suggest that this is enhanced to read...
> >
> > 11.  Security Considerations
> >
> >   The configuration, control, and monitoring of NSFs provide access to
> >   and 

Re: [I2nsf] Mirja Kühlewind's Discuss on draft-ietf-i2nsf-framework-08: (with DISCUSS)

[John Strassner]

Dear Mirja and Kathleen,

thank you for performing this review and the subsequent discussion.
The first set of issues will be addressed in a subsequent email, which
includes additional comments from Adrian.

The second issue concerning the lack of authentication will be handled
by adding a paragraph to sections 3, as follows:

   In general, all I2NSF interfaces should require at least mutual
   authentication and authorization for their use. Other security and
   privacy considerations are specified in Section 11.

These issues will be addressed in version 9 of this I-D, to be released
on Monday 11/13.


regards,
John

On Mon, Oct 16, 2017 at 11:22 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hi Mirja,
>
> Thanks for your review.  The first seems simple enough, but I'll leave
> that to the editors, shepherd and WG.
>
> On Mon, Oct 16, 2017 at 11:45 AM, Mirja Kühlewind 
> wrote:
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-i2nsf-framework-08: 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-framework/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > I have two points below:
> >
> > 1) The first one should be easy to address:
> > "Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the
> >Stream Control Transmission Protocol (SCTP) will need to be evaluated
> >for applicability. "
> > This sentence is not correct; MPTP and SCTP do not provide any redundancy
> > mechanisms; they simply just provide a reliable transport as TCP does.
> > Therefore I would just remove this sentence here.
> >
> > Further, on this paragraph, it is not clear to me why you say that
> reliable
> > transport is needed. Especially for some monitoring purposes, unreliable
> > transport might be acceptable as well. Or do you think that all
> communication
> > for security systems have always to be reliable? I don't think this
> document
> > discusses things in detail enough to make such an assessment.
> >
> > 2) This second is a very high level concern and I'm not sure if balloting
> > discuss on this is the right thing to do but I definitely would like to
> get
> > some feedback from the group to better understand this document before
> > publication:
> >
> > This document seem not very security specific to me. To say this in a
> somehow
> > sloppy way: I have the feeling that if you would just remove the word
> > "security" everywhere in the text, it would still be the same document. I
> > checked the charter and the charter is also not very concrete about what
> to
> > expect, besides motivating the needed interfaces with the need for
> in-network
> > security function. However, if there is nothing security specific about
> this,
> > what's the difference to the usually control plane architecture as
> usually
> > deployed with the use of NETCONF? And I am actually wondering if this is
> the
> > right wg to write such a document.
>
> I think right as you were becoming an AD as this work was in process
> of being chartered, so there may be a gap in knowledge.  This WG is a
> cross area WG between routing and security.  Many of the people in the
> WG are from the routing area.  Since the devices they were most
> concerned in provisioning were security devices (per the customers
> that helped bring the work to the IETF), the IESG decided to put this
> in the Security area.  Yes, the mechanisms are purposefully reusing
> existing technologies to accomplish the tasks, but all of the tasks
> are interacting with security provisioning services or security
> appliances.  An example of a draft that was just adopted is one that
> includes a YANG module to provision IPsec.  The security focus is
> important in that example (as well as others) since mistakes with
> provisioning of IPsec tunnels could have a large impact.  AN advantage
> of having this work as a cross area group in the Security area is that
> it not only caught the attention of the IPSecMe WG, but they had a
> joint interim call to improve the work and the go forward plan will
> involve assistance from people contributing to the IPSecME WG.
>
> I think this one is likely just a gap in background knowledge.
>
> >
> > Further, I would at least have expected that this framework mandates for
> high
> > control plan security given we are talking about the configuration and
> > deployment of security function. However, it 

Re: [I2nsf] Genart telechat review of draft-ietf-i2nsf-framework-08

[John Strassner]

Dear Stewart,

thank you for performing this review. All of your issues will be addressed
in version 9 of this I-D, to be released on Monday 11/13. In particular:

  1. The issue over including an RFC2119 boilerplate:


  2.  s/obtain/obtain
  DONE

  3.  Registration Categories including IPFIX
  DONE (references added to both IPFIX as well as IANA IPFIX Registry info)
  Specifically, the following text was added:

   IPFIX data [IPFIX-D] defines IP flow information and mechanisms to
   transmit such information. This includes flow attributes as well as
   information about the metering and exporting processes is also
   included. Such contain may be stored in a IPFIX registry [IPFIX-R].
   As such, IPFIX information should be considered for defining
   categories of registration information.


best regards,
John

On Sun, Oct 15, 2017 at 5:45 AM, Stewart Bryant 
wrote:

> Reviewer: Stewart Bryant
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-i2nsf-framework-08
> Reviewer: Stewart Bryant
> Review Date: 2017-10-15
> IETF LC End Date: 2017-10-25
> IESG Telechat date: 2017-10-26
>
> Summary: This is a well written document. There are a couple of things the
> authors need to look at, but it is ready to be published
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>
> The authors should consider whether the 2119 boilerplate is really needed
> as no
> RFC2119 keywords are used (something they point out to the reader) ==
>
>a query-based interface is used by the the I2NSF Management
>System to obatin information, whereas a report-based interface
> SB Typo - obtain
> =
>
> 9.2.  Registration Categories
>
> SB> I would think that anything in the IPFIX registry was a candidate for
> such
> categories, after all IPFIX is designed and used  to monitor flows, often
> for
> security reasons.
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>



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

Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model Drafts

[John Strassner]

Hi Paul,

thanks for your kind note. I am happy to work closely with you and your
team.

The "object-oriented" YANG approach is currently being used by Ericsson and
parts of Huawei - others are looking at it. I do NOT think that it is
required that I2NSF use it (though of course I would like to see us use
it), and you are absolutely right - the WG needs to decide which approach
to use.

If we decide to use the traditional approach, then there are some elements
from the OO approach (e.g., identities defined in groupings) that I think
we should add to the traditional approach.

I believe that there is good work within draft-kumar, but we:
   1) need to treat it as a requirements for adding to our info model work
(we do not want competing info models!), and
   2) translate the requirements into an OO info model approach.

I hope that you and part of your team will go to Singapore - if you are,
please let me know and let's set up some side meetings to explore the above
further.

best regards,
John


On Fri, Nov 3, 2017 at 9:26 PM, Mr. Jaehoon Paul Jeong <
jaehoon.p...@gmail.com> wrote:

> John,
>
> For draft-kumar for consumer-facing interface information model, you can
> give the authors
> further constructive suggestions because you did good job in I2NSF
> capability information model.
> IMHO, the current draft-kumar is good for at least firewall and web-filter
> through the implementation experiences of my SKKU team at the last three
> IETF hackathons.
> So I believe that draft-kumar can be a good starting point for
> consumer-facing interface.
>
> For the data models, as you mentioned, we authors followed the legacy YANG
> models.
> The object-oriented data model such as SUPA will be a good candidate.
> As the WG becomes to have a consensus to use which YANG model between
> the legacy YANG model and the object-oriented YANG model,
> we authors of the data models will be able to work smoothly according to
> the decision.
>
> Actually, my SKKU team have already been considering how to use the
> concept of the object-oriented features
> for YANG data models.
> For the NSF-facing interface data model, we can modify our data model such
> that the common variables used by
> Event, Condition, and Action clauses will be made into objects and be
> shared by them through aggregation.
>
> If you know other object-oriented YANG models other than the SUPA data
> model,
> please let us know them to refer to them.
>
> Thanks for your considerate analysis and contribution to our I2NSF WG.
>
> Best Regards,
> Paul
>
> On Thu, Nov 2, 2017 at 2:08 PM, John Strassner <
> john.sc.strass...@huawei.com> wrote:
>
>> Hi Paul,
>>
>>
>>
>> First, I attended that same call.
>>
>>
>>
>> Second, my worry is that draft-kumar is not ready. It is not an
>> information model; rather, it is (at best) requirements that could be
>> turned into an information model. In addition, it needs to be integrated
>> with the existing capability draft. Note that it is absolutely essential
>> that we only have a single information model. Having multiple information
>> models is akin to having multiple dictionaries; what inevitably happens is
>> that the same concept is defined in multiple conflicting ways. I suggest
>> that this document be examined in more detail to determine how best to
>> proceed. I have already talked to Frank about that.
>>
>>
>>
>> Third, we need to think about how we want to author data models. You have
>> adopted a perfectly reasonable style, which is similar to how many YANG
>> models are built. This is not object-oriented. However, the info model is
>> in fact object-oriented, and so the question arises: do we follow existing
>> style, or do we try and build YANG modules that are more object-oriented. I
>> personally vote for the latter (see the SUPA data models for an example),
>> but this should be decided by the WG. Until that is decided, I suggest that
>> any data model is not ready for adoption.
>>
>>
>>
>> Regards,
>>
>> John
>>
>>
>>
>> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *Mr. Jaehoon
>> Paul Jeong
>> *Sent:* Tuesday, October 31, 2017 6:14 PM
>> *To:* John Strassner <straz...@gmail.com>
>> *Cc:* i2nsf@ietf.org; SecCurator_Team <skku_secu-brain_all@googlegro
>> ups.com>; Yoav Nir <ynir.i...@gmail.com>; Linda Dunbar <
>> linda.dun...@huawei.com>
>> *Subject:* Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model
>> Drafts
>>
>>
>>
>> Hi John,
>>
>> You are right. :-)
>>
>>
>>
>> Actually, t

Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model Drafts

[John Strassner]

Thanks Linda. I do not agree with 3444, as it is informational, and relies
on 3198 for a real definition. I don't really see the point of 3444.

My point was that if you are going to call something an info model, then it
should describe objects, hopefully in an object-oriented way. What I see is
a confusion between what is an object, what is an attribute, and what is a
relationship. That confusion must be cleared up before we can consider WG
adoption.

best regards,
John

On Thu, Nov 2, 2017 at 2:17 PM, Linda Dunbar <linda.dun...@huawei.com>
wrote:

> John,
>
>
>
> Thank you very much for identifying some of the issues of the IM draft.
> Agree with you that we need to resolve the conflicts with the “capability
> I-D”. I hope we can make some progress in IETF100.
>
>
>
> Per RFC 3444, the information model can be loosely defined, as long as it
> lays out the needed information elements. I understand not everyone agree
> with RFC3444. But before changes to RFC3444 is made, we should allow people
> to name their draft based on RFC3444.
>
>
>
> Once become WG draft, the WG can contribute and make it correct.
>
>
>
> Linda
>
>
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Thursday, November 02, 2017 3:09 PM
> *To:* Yoav Nir <ynir.i...@gmail.com>; John Strassner <straz...@gmail.com>
> *Cc:* John Strassner <john.sc.strass...@huawei.com>; Mr. Jaehoon Paul
> Jeong <jaehoon.p...@gmail.com>; i2nsf@ietf.org; Linda Dunbar <
> linda.dun...@huawei.com>
> *Subject:* Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model
> Drafts
>
>
>
> Hi Yoav,
>
>
>
> I understand the adoption practice :-)
>
>
>
> What I don't understand is why draft-kumar is titled "Information Model
> for Consumer-Facing Interface", as it is not an information model.
>
>
>
> In addition, this draft conflicts with the capability I-D, which has
> already been adopted. For example, the very first object that is described
> is a Policy object, which "represents a mechanism to express a Security
> Policy by Security Admin (i.e., I2NSF User) using Consumer-Facing interface
> toward Security Controller; the policy would be enforced on an NSF." This
> object conflicts with the SecurityECAPolicyRule object defined in the
> capability draft.
>
>
> Especially because there is a normative requirement in the next line of
> the kumar draft ("The Policy object SHALL have following information").
>
>
>
> Now, if I look at this object, I can make the following comments:
>
>   - The information specified is a mixture of attributes and relationships
> to other objects, but the actual format and syntax is not specified
>
>   - Name and descriptions SHOULD NOT be defined in this spec: they are
> inherited from external specs as defined in the Capability draft
>
>   - Multi-tenancy SHOULD NOT be defined as an attribute! This appears to
> be a set of relationships to other objects
>
>   - End-Group SHOULD NOT be defined as an attribute, appears to be
> relationships to other objects, and has problems in its definition
>
>   - Threat-Feed SHOULD NOT be defined as an attribute, appears to be
> relationships to other objects, and has problems in its definition
>
>   - Telemetry Data SHOULD NOT be a "field"
>
>   - Rules (see below)
>
>   - Owner (see below)
>
>
>
> What really bothers me is the "Rules" field. This is completely
> contradictory to the capability draft. Please re-examine it.
>
>
>
> So, if you are asking if I support WG adoption, then the answer is NO.
> However, my point was that this draft, besides not being organized as an
> information model, is in too incomplete a state to start working on - all I
> have is questions.
>
>
>
> regards,
>
> john
>
>
>
>
>
> On Thu, Nov 2, 2017 at 11:39 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
>
> Hi, John
>
>
>
> On 2 Nov 2017, at 7:08, John Strassner <john.sc.strass...@huawei.com>
> wrote:
>
>
>
> 
>
>
>
> Second, my worry is that draft-kumar is not ready. It is not an
> information model; rather, it is (at best) requirements that could be
> turned into an information model. In addition, it needs to be integrated
> with the existing capability draft. Note that it is absolutely essential
> that we only have a single information model. Having multiple information
> models is akin to having multiple dictionaries; what inevitably happens is
> that the same concept is defined in multiple conflicting ways. I suggest
> that this document be examined in more detail to determine how best to
> proceed. I hav

Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model Drafts

[John Strassner]

Hi Paul,

First, I attended that same call.

Second, my worry is that draft-kumar is not ready. It is not an information 
model; rather, it is (at best) requirements that could be turned into an 
information model. In addition, it needs to be integrated with the existing 
capability draft. Note that it is absolutely essential that we only have a 
single information model. Having multiple information models is akin to having 
multiple dictionaries; what inevitably happens is that the same concept is 
defined in multiple conflicting ways. I suggest that this document be examined 
in more detail to determine how best to proceed. I have already talked to Frank 
about that.

Third, we need to think about how we want to author data models. You have 
adopted a perfectly reasonable style, which is similar to how many YANG models 
are built. This is not object-oriented. However, the info model is in fact 
object-oriented, and so the question arises: do we follow existing style, or do 
we try and build YANG modules that are more object-oriented. I personally vote 
for the latter (see the SUPA data models for an example), but this should be 
decided by the WG. Until that is decided, I suggest that any data model is not 
ready for adoption.

Regards,
John

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Tuesday, October 31, 2017 6:14 PM
To: John Strassner <straz...@gmail.com>
Cc: i2nsf@ietf.org; SecCurator_Team <skku_secu-brain_...@googlegroups.com>; 
Yoav Nir <ynir.i...@gmail.com>; Linda Dunbar <linda.dun...@huawei.com>
Subject: Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model Drafts

Hi John,
You are right. :-)

Actually, the authors of IM and DM documents for the client-facing interface
had a teleconference with Linda last September (9/27/2017).
We discussed how to correct the IM and how to synchronize these two IM and DM 
documents.

I joined the IM document as a co-author to synchronize them.

The current DM has the ECA policy model, but I need to modify something to 
synchronize them completely.
I think this synchronization is not a big deal because our IM is not so 
complicated and our DM is structured to
accommodate the IM.
During the WG adoption call, I will make these two IM and DM documents 
completely synchronized.

Thanks for your good suggestion.

Best Regards,
Paul


On Wed, Nov 1, 2017 at 2:26 AM, John Strassner 
<straz...@gmail.com<mailto:straz...@gmail.com>> wrote:
Wouldn't it be ore prudent to first have the design team meet to discuss 
alignment issues, and then proceed from the results of that?

regards,
John

On Tue, Oct 31, 2017 at 9:22 AM, Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:
Paul,

Got your request.

For I2NSF Consumer-Facing Interface YANG Data Model, I think it is better to be 
called together with
draft-kumar-i2nsf-client-facing-interface-im-04. Do you think 
draft-kumar-i2nsf-client-facing-interface-im-04 is ready?

Linda


From: Mr. Jaehoon Paul Jeong 
[mailto:jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>]
Sent: Monday, October 30, 2017 8:24 PM
To: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>; 
Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>
Cc: i2nsf@ietf.org<mailto:i2nsf@ietf.org>; SecCurator_Team 
<skku_secu-brain_...@googlegroups.com<mailto:skku_secu-brain_...@googlegroups.com>>;
 Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>>
Subject: Request for WG Adoption Call for I2NSF Data Model Drafts

Dear Linda and Yoav,
Could you start the WG adoption call for the following three data model drafts?

1. I2NSF Capability YANG Data Model
(draft-hares-i2nsf-capability-data-model-05 )
https://tools.ietf.org/html/draft-hares-i2nsf-capability-data-model-05

2. I2NSF Network Security Functions-Facing Interface YANG Data Model
(draft-kim-i2nsf-nsf-facing-interface-data-model-04)
https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04

3. I2NSF Consumer-Facing Interface YANG Data Model
(draft-jeong-i2nsf-consumer-facing-interface-dm-04)
https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-facing-interface-dm-04

We address all the discussions last meetings for the synchronization between
the information models and data models.

Thanks for your coordination.

Best Regards,
Paul
--
===
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957<tel:+82%2031-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>

___
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@iet

Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model Drafts

[John Strassner]

Wouldn't it be ore prudent to first have the design team meet to discuss
alignment issues, and then proceed from the results of that?

regards,
John

On Tue, Oct 31, 2017 at 9:22 AM, Linda Dunbar 
wrote:

> Paul,
>
>
>
> Got your request.
>
>
>
> For I2NSF Consumer-Facing Interface YANG Data Model, I think it is better
> to be called together with
>
> draft-kumar-i2nsf-client-facing-interface-im-04. Do you think
> draft-kumar-i2nsf-client-facing-interface-im-04 is ready?
>
>
>
> Linda
>
>
>
>
>
> *From:* Mr. Jaehoon Paul Jeong [mailto:jaehoon.p...@gmail.com]
> *Sent:* Monday, October 30, 2017 8:24 PM
> *To:* Linda Dunbar ; Yoav Nir <
> ynir.i...@gmail.com>
> *Cc:* i2nsf@ietf.org; SecCurator_Team  googlegroups.com>; Mr. Jaehoon Paul Jeong 
> *Subject:* Request for WG Adoption Call for I2NSF Data Model Drafts
>
>
>
> Dear Linda and Yoav,
>
> Could you start the WG adoption call for the following three data model
> drafts?
>
>
>
> 1. I2NSF Capability YANG Data Model
>
> (draft-hares-i2nsf-capability-data-model-05 )
>
> https://tools.ietf.org/html/draft-hares-i2nsf-capability-data-model-05
>
>
>
> 2. I2NSF Network Security Functions-Facing Interface YANG Data Model
>
> (draft-kim-i2nsf-nsf-facing-interface-data-model-04)
>
> https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-
> interface-data-model-04
>
>
>
> 3. I2NSF Consumer-Facing Interface YANG Data Model
>
> (draft-jeong-i2nsf-consumer-facing-interface-dm-04)
>
> https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-
> facing-interface-dm-04
>
>
>
> We address all the discussions last meetings for the synchronization
> between
>
> the information models and data models.
>
>
>
> Thanks for your coordination.
>
>
>
> Best Regards,
>
> Paul
>
> --
>
> ===
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software
> Sungkyunkwan University
> Office: +82-31-299-4957 <+82%2031-299-4957>
> Email: jaehoon.p...@gmail.com, paulje...@skku.edu
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> 
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>


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

Re: [I2nsf] AD review of draft-ietf-i2nsf-framework

[John Strassner]

Hi Kathleen,

thank you for your comments, and sorry for the delay. I have
addressed all of them, and tried to remove other examples
of home user usage. I added a brief privacy statement to
the security section.

best regards,
John

On Tue, Oct 10, 2017 at 1:13 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hello,
>
> I had placed this on the telechat in a little over 2 weeks.  If there
> is no response and update today, I will have to move it until after
> Singapore as the IETF last call takes 2 weeks and I'd like a couple of
> days after that completes prior to the telechat.  Please let me know
> the status so I can adjust telechat dates or start the IETF last call.
>
> Thank you,
> Kathleen
>
> On Mon, Oct 2, 2017 at 4:59 PM, Kathleen Moriarty
>  wrote:
> > Hello,
> >
> > Thank you for your work on this document!  I know it underwent many
> > revisions and it can be difficult to merge text pulling together ideas
> > from numerous contributors.  The draft is well written and easy to
> > understand, thank you for all your hard work, it shows!
> >
> > Now to a few comments I'd like to see if we can clear up before
> > starting last call.
> >
> > Section 5 begins with the following text:
> >
> >An important concept underlying this framework is the fact that
> >attackers do not have standards as to how to attack networks, so it
> >is equally important to not constrain NSF developers to offering a
> >limited set of security functions.  In other words, the introduction
> >of I2NSF standards should not make it easier for attackers to
> >compromise the network.
> >
> > I think the first sentence could be safely dropped and the second
> > sentence altered to something like the following:
> >
> >A basic tenet in the introduction
> >of I2NSF standards is that he standards should not make it easier
> > for attackers to
> >compromise the network.
> >
> > You may get comments on the following point, also in section 5:
> >
> >o  Be seen as endorsing a best common practice for the implementation
> >   of NSFs
> >
> > But, I am not going to suggest a change yet.  I could see further
> > explanation being needed for the text.
> >
> > Section 7.1
> >
> > I'd suggest using a different example for the time constraints, a
> > business one would be better.  The one listed for a home user could
> > have the reader jump to censorship concerns if this is targeted to
> > home users.  How about an ERP system is allowed to be accessed from
> > the corporate network only during business hours for a high privileged
> > class of users?  Outside of the times could indicate an attack and
> > you'd want that access approved if there was an extenuating
> > circumstance.
> >
> > Do you plan to allow for rule setting to be extended to home users?  I
> > think that will raise concern as I thought scope was limited to
> > enterprises with cloud service offerings.
> >
> > Section 8:
> > s/I2NSF system can explose/I2NSF system can expose/
> >
> > Section 11.
> >
> > Since this is the framework, the security considerations are fine, but
> > you do need to add a privacy considerations section. I can see a few
> > possible privacy concerns and there may be more that I am missing.
> >
> > Privacy of end users with the reporting options.  If all of the fields
> > described in section 10 could be used in reports, you have a lot of
> > interesting tracking information that is now easily accessible with
> > quick reports.  The ability to leave out identifying information will
> > be important as will having ways to protect that data at rest as well
> > as in transit.
> >
> > I2NSF could also be used in targeted ways toward individuals in attack
> > scenarios, both an invasion of privacy and a security consideration
> > for the attack possibilities.  If home use is not out-of-scope, you'll
> > have real issues here and it will be really hard to tackle the
> > security and privacy concerns.
> >
> > The I2NSF user information could be sensitive too - meaning the person
> > doing provisioning.  What protects their account information (I think
> > you have this covered), you may want to state it for privacy reasons.
> >
> > Thanks!
> > --
> >
> > Best regards,
> > Kathleen
>
>
>
> --
>
> Best regards,
> Kathleen
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>



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

Re: [I2nsf] AD review of draft-ietf-i2nsf-framework

[John Strassner]

Hi Kathleen,

I will do the edits that you request, and try and submit later this
afternoon.

best regards,
John

On Tue, Oct 10, 2017 at 1:13 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hello,
>
> I had placed this on the telechat in a little over 2 weeks.  If there
> is no response and update today, I will have to move it until after
> Singapore as the IETF last call takes 2 weeks and I'd like a couple of
> days after that completes prior to the telechat.  Please let me know
> the status so I can adjust telechat dates or start the IETF last call.
>
> Thank you,
> Kathleen
>
> On Mon, Oct 2, 2017 at 4:59 PM, Kathleen Moriarty
>  wrote:
> > Hello,
> >
> > Thank you for your work on this document!  I know it underwent many
> > revisions and it can be difficult to merge text pulling together ideas
> > from numerous contributors.  The draft is well written and easy to
> > understand, thank you for all your hard work, it shows!
> >
> > Now to a few comments I'd like to see if we can clear up before
> > starting last call.
> >
> > Section 5 begins with the following text:
> >
> >An important concept underlying this framework is the fact that
> >attackers do not have standards as to how to attack networks, so it
> >is equally important to not constrain NSF developers to offering a
> >limited set of security functions.  In other words, the introduction
> >of I2NSF standards should not make it easier for attackers to
> >compromise the network.
> >
> > I think the first sentence could be safely dropped and the second
> > sentence altered to something like the following:
> >
> >A basic tenet in the introduction
> >of I2NSF standards is that he standards should not make it easier
> > for attackers to
> >compromise the network.
> >
> > You may get comments on the following point, also in section 5:
> >
> >o  Be seen as endorsing a best common practice for the implementation
> >   of NSFs
> >
> > But, I am not going to suggest a change yet.  I could see further
> > explanation being needed for the text.
> >
> > Section 7.1
> >
> > I'd suggest using a different example for the time constraints, a
> > business one would be better.  The one listed for a home user could
> > have the reader jump to censorship concerns if this is targeted to
> > home users.  How about an ERP system is allowed to be accessed from
> > the corporate network only during business hours for a high privileged
> > class of users?  Outside of the times could indicate an attack and
> > you'd want that access approved if there was an extenuating
> > circumstance.
> >
> > Do you plan to allow for rule setting to be extended to home users?  I
> > think that will raise concern as I thought scope was limited to
> > enterprises with cloud service offerings.
> >
> > Section 8:
> > s/I2NSF system can explose/I2NSF system can expose/
> >
> > Section 11.
> >
> > Since this is the framework, the security considerations are fine, but
> > you do need to add a privacy considerations section. I can see a few
> > possible privacy concerns and there may be more that I am missing.
> >
> > Privacy of end users with the reporting options.  If all of the fields
> > described in section 10 could be used in reports, you have a lot of
> > interesting tracking information that is now easily accessible with
> > quick reports.  The ability to leave out identifying information will
> > be important as will having ways to protect that data at rest as well
> > as in transit.
> >
> > I2NSF could also be used in targeted ways toward individuals in attack
> > scenarios, both an invasion of privacy and a security consideration
> > for the attack possibilities.  If home use is not out-of-scope, you'll
> > have real issues here and it will be really hard to tackle the
> > security and privacy concerns.
> >
> > The I2NSF user information could be sensitive too - meaning the person
> > doing provisioning.  What protects their account information (I think
> > you have this covered), you may want to state it for privacy reasons.
> >
> > Thanks!
> > --
> >
> > Best regards,
> > Kathleen
>
>
>
> --
>
> Best regards,
> Kathleen
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>



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

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

[John Strassner]

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 ; 'i2nsf@ietf.org' 
Cc: draft-xibassnez-i2nsf-capabil...@ietf.org; Yoav Nir 
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.
> 
> **
> 


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

Re: [I2nsf] Is there any objection of merging the content from draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft?

[John Strassner]

I disagree that creating a bis document for terminology changes is a good
approach. This means that we are creating a bis document for content that
is not inherently part of the framework document!

John

On Thu, Aug 3, 2017 at 5:24 AM, Susan Hares <sha...@ndzh.com> wrote:

> Yoav and Adrian:
>
> I agree with you that split the terminology is not a good way to go.  As a
> solution to Yoav's problem, may I suggest the following:
>
> 1) publish the terminology information in the framework document,
> 2) Keep a WG draft for terms that change - this can create a bis document
> for the framework document when we have completed all the rest of the work,
>
> Cheerily,
> Sue hares
>
> -Original Message-
> From: Yoav Nir [mailto:ynir.i...@gmail.com]
> Sent: Thursday, August 3, 2017 7:27 AM
> To: adr...@olddog.co.uk
> Cc: 'i2nsf@ietf.org'; draft-ietf-i2nsf-terminol...@ietf.org; 'Kathleen
> Moriarty'
> Subject: Re: [I2nsf] Is there any objection of merging the content from
> draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft?
>
> Hi, Adrian.
>
> I tend to agree that splitting the terminology around to several small
> documents is not a good way to go.
>
> I think it should be OK to move the contents into the framework draft,
> perhaps as an appendix, with an appropriate paragraph saying that the
> terminology in this section is meant for the entire document set of I2NSF
> and some of the terms are not used in this (the framework) document.
>
> There is one potential issue with doing it this way. We intend to get the
> framework document published soonish. So if we add the terminology there,
> it gets published in an RFC and gets "set in stone". While it's always
> possible to add new terms afterwards, it gets messy to change the meaning
> of existing terms already defined in the RFC.
>
> Are we willing to accept this risk/constraint of future work?
>
> Yoav
>
> On Thu, 2017-08-03 at 11:18 +0100, Adrian Farrel wrote:
> > FWIW, some context.
> >
> > As we started to advance a number of I2NSF document we ran into a few
> problems:
> > - Different documents used different terms for similar or identical
> > concepts
> > - Different documents used the same terms to mean different things
> > - Different documents attempted to define the same terms, but actually
> introduced
> >discrepancies in the definitions
> > - Documents started to acquire circular normative dependencies on each
> > other
> > - Documents made best efforts to duplicate definition text but were not
> kept
> >up-to-date and in synch
> >
> > The terminology document was introduced as a way to provide one single
> point of reference for all terms and to ensure consistency.
> >
> > Of course, I don't mind what solution to this purely non-technical
> > issue is used so long as it adequately addresses all of the needs. And
> > if the IESG has cycles to burn to work out how to publish terminology
> > definitions without causing ambiguity or confusion, then it is fine
> > with me that they do that (it will keep them from doing harm in the
> > technical areas where they might not have the expertise to do the
> > right thing :-)
> >
> > But there are three concerns that I have:
> >
> > 1. Moving *some* of the definitions from the terminology draft to
> another draft will leave behind other terms. That is to say, not all the
> terms currently in the terminology draft are currently used in just one
> other draft. So there will be an annoying and messy period of working out
> where the terms need to be moved to. Alternatively, the whole of the
> terminology draft should be subsumed into some other foundational document
> notwithstanding that that other document does not use those terms - that
> sounds easy, but I bet there will be review comments that say "delete this
> term because it is not used in this document."
> >
> > 2. When new drafts are written there needs to be a central place to go
> to find the right term to use to prevent invention of new terms or
> re-invention of existing terms.
> >
> > 3. When a WG or document authors find themselves doing "whatever is
> necessary to get a document published" they are making pointless
> concessions to the arbitrary rules of Discusses placed on them by the IESG
> which risks over-running community consensus. That is, of course, a
> socio-political matter, and I don't expect the WG to engage on it, but
> individuals who care about the IETF might want to think it through.
> >
> > I'm not really working on this stuff anymore, so this email really is
> only for context and to 

Re: [I2nsf] Is there any objection of merging the content from draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft?

[John Strassner]

I expressed some minor concerns before, and will do so again.


* What is the reasoning against publishing an INFORMATIONAL RFC for 
terminology?

* Many of the terms in the current terminology draft are not used in 
the framework draft

o   This is because the terminology draft was originally conceived to work for 
many diverse subject areas

o   The framework draft will not cover some of these diverse subjects in 
detail, and hence, does not need those terms; including them will make the 
reading awkward at best

* Thus, I would recommend

o   We keep the current terminology draft until these other subject areas 
mature and have WG-adopted drafts (a possible alternative is putting them on 
the wiki; I am not a big fan of wikis)

o   We move the appropriate terms into appropriate drafts

?  Note: this will cause duplication of terms - yet another reason to keep the 
terminology draft

Regards,
John

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, August 02, 2017 10:31 AM
To: 'i2nsf@ietf.org' ; draft-ietf-i2nsf-framew...@ietf.org; 
draft-ietf-i2nsf-terminol...@ietf.org
Cc: 'Kathleen Moriarty' ; Yoav Nir 

Subject: [I2nsf] Is there any objection of merging the content from 
draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft?

I2NSF participants:

During the IETF99 I2NSF Session, our AD Kathleen said that the current IESG 
doesn't like to have RFC for Terminology only drafts. So we should consider 
merging the content of Terminology with other drafts. I2NSF framework draft 
would be a nature place to have the terminologies.

If you have any objections or concerns of merging the content from 
draft-ietf-i2nsf-terminology to draft-ietf-i2nsf-framework draft, please 
express them to the I2NSF mailing list.

Thanks, Linda & Yoav.

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

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

[John Strassner]

Hi Adrian,

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

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

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

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


regards,
John

On Mon, Jul 17, 2017 at 2:50 AM, Adrian Farrel <adr...@olddog.co.uk> wrote:

> Taking John's three points separately (and in reverse order)
>
>
>
> 3) Yes, traceability back from DM to IM is very valuable and is a strong
> should for the WG because the WG has decided that IMs are a deliverable.
>
>
>
> 2) I think we should lean very heavily on RFC3444 for our definition of IM
> and DM. This might not be consistent with every view of those terms, but it
> is what the IETF has consensus on and absent any changes across the OPS
> area, we should stick with it.
>
>
>
> I am sure that the current documents can be improved to be clearer on what
> information is "in the model" and to separate out other interface-specific
> requirements, but that is "work in progress".
>
>
>
> 1) Consistency across models is important. As is coherence across the
> whole of the I2NSF space. And there will clearly be mapping of information
> at one interface to information at another interface. But I don't quite
> understand the "one IM versus many IMs" discussion. Arguably we could say
> that the whole universe has a single IM, but I think we can also agree that
> it is convenient to break out pieces so that our scope a field of vision is
> limited. The attempt here is to partition the IM into "information modules"
> that describe the information at each interface, and it is convenient to
> place these pieces (modules) in separate documents.
>
>
>
> Does any of that help?
>
>
>
> Adrian
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *John
> Strassner
> *Sent:* 16 July 2017 18:36
> *To:* Linda Dunbar; John Strassner
> *Cc:* i2nsf@ietf.org
> *Subject:* Re: [I2nsf] need some work to improve the consistency of I2NSF
> Information and data model: maybe a design team?
>
>
>
> I cannot attend Prague due to family health issues.
>
>
>
> That being said, I agree with Linda. I see three major problems:
>
>
>
>1) There should be one, and only one, information model.
>
> a) It is great to have multiple contributions, but those
> contributions MUST be written to enhance the existing model, not propose a
> new one
>
>2) In general, some of the info models are not really **models** per
> se, but rather, requirements for models.
>
>3) In general, I cannot trace data model work back to the info model
> work.
>
>a) This is especially true for drafts that are trying to use or
> define policies
>
>
>
> I propose that draft-xibassnez is used for our info model. This means that
> the other info model drafts SHOULD be restructured to add to that draft.
>
>
>
> I propose that we wait on further data model draft definition until some
> people (I will help) on the design team can formulate guidelines and
> perhaps examples to properly derive data models from our info model.
>
>
>
> regards,
>
> John
>
>
>
> On Fri, Jul 14, 2017 at 9:27 AM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
> Thanks to many people contributions. We now have many drafts on the
> information model and data model for I2NSF:
>
>
>
> Information model:
>
> draft-xibassnez-i2nsf-capability-02
>
> draft-zhang-i2nsf-info-model-monitoring-04
>
> draft-hyun-i2nsf-registration-interface-im-02
>
> draft-kumar-i2nsf-client-facing-interface-im-03
>
> draft-xia-i2nsf-security-policy-object-01
>
>
>
> Data Model:
>
> draft-hares-i2nsf-capability-data-model-03
>
> draft-jeong-i2nsf-consumer-facing-interface-dm-02
>
> draft-kim-i2nsf-nsf-facing-interface-data-model-02
>
> draft-hyun-i2nsf-regis

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

[John Strassner]

Wow.

I have NEVER said that "my" (and it is NOT just mine!) model is
architecturally perfect. I am offended by that statement. Am I the ONLY
author on this draft?

Rather than denigrate the efforts of the team that is building the model,
it would be much more helpful to provide specifics. For example, what
specifically is "too hard to understand"? How are we supposed to fix
something given only vague comments like this?

I also object to your statement "Feedback from product groups are that your
model are difficult to understand." I have worked with people inside and
**outside** of Huawei on understanding and implementing the model. None
have said that it is "too difficult to understand".

I have no idea what "something that fits the market, and provides easy
reading by users" actually means. Saying that the YANG is "readable" is a
matter of opinion. I note that, for example, there is no ability of the
current YANG models to provide reflection or introspection. That impacts
usability.

Providing insults and no alternative suggestions is not helpful.

On Mon, Jul 17, 2017 at 1:52 AM, Susan Hares <sha...@ndzh.com> wrote:

> John:
>
>
>
> Let me propose something different.  There are 2 priorities:
>
>
>
> 1)  Priority 1 – something that fits the market, and provides easy
> reading by users
>
> 2)  Priority 2 – something that is architecturally clean
>
>
>
> I understand you feel your base model is architecturally perfect.
> Feedback from product groups are that your model are difficult to
> understand.   The models from the teams that have worked on the hackathon
> have been understood and worked on by the teams.
>
>
>
> We should work toward both. An attitude that says “my model’s perfect”
> does not align with the yang model’s readably .
>
>
>
> Just my 2 cents.
>
>
>
> Sue Hares
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *John
> Strassner
> *Sent:* Sunday, July 16, 2017 1:36 PM
> *To:* Linda Dunbar; John Strassner
> *Cc:* i2nsf@ietf.org
> *Subject:* Re: [I2nsf] need some work to improve the consistency of I2NSF
> Information and data model: maybe a design team?
>
>
>
> I cannot attend Prague due to family health issues.
>
>
>
> That being said, I agree with Linda. I see three major problems:
>
>
>
>1) There should be one, and only one, information model.
>
> a) It is great to have multiple contributions, but those
> contributions MUST be written to enhance the existing model, not propose a
> new one
>
>2) In general, some of the info models are not really **models** per
> se, but rather, requirements for models.
>
>3) In general, I cannot trace data model work back to the info model
> work.
>
>a) This is especially true for drafts that are trying to use or
> define policies
>
>
>
> I propose that draft-xibassnez is used for our info model. This means that
> the other info model drafts SHOULD be restructured to add to that draft.
>
>
>
> I propose that we wait on further data model draft definition until some
> people (I will help) on the design team can formulate guidelines and
> perhaps examples to properly derive data models from our info model.
>
>
>
> regards,
>
> John
>
>
>
> On Fri, Jul 14, 2017 at 9:27 AM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
> Thanks to many people contributions. We now have many drafts on the
> information model and data model for I2NSF:
>
>
>
> Information model:
>
> draft-xibassnez-i2nsf-capability-02
>
> draft-zhang-i2nsf-info-model-monitoring-04
>
> draft-hyun-i2nsf-registration-interface-im-02
>
> draft-kumar-i2nsf-client-facing-interface-im-03
>
> draft-xia-i2nsf-security-policy-object-01
>
>
>
> Data Model:
>
> draft-hares-i2nsf-capability-data-model-03
>
> draft-jeong-i2nsf-consumer-facing-interface-dm-02
>
> draft-kim-i2nsf-nsf-facing-interface-data-model-02
>
> draft-hyun-i2nsf-registration-interface-dm-01
>
>
>
>
>
> But the problem is that they are not all consistent.  Extra work is needed
> to improve the consistency for 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
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>
>
>
> --
>
> regards,
>
> John
>



-- 
regards,
John
___
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?

[John Strassner]

The concept of a Capability is INDEPENDENT of consumer or producer. Hence,
a Capability:

   - MUST first be registered using the I2NSF Registration Interface
(before any other actions can take place)
   - SHOULD be able to be requested over the I2NSF Client-Facing Interface
   - MUST be able to be invoked using the I2NSF NSF-Facing Interface

For example, why couldn't a consumer say "I need a Foo Capability"? How
else would they express that, if not over the I2NSF Client-Facing Interface?

best regards,
John

On Sun, Jul 16, 2017 at 3:34 PM, Diego R. Lopez <
diego.r.lo...@telefonica.com> wrote:

>
> --Apple-Mail=_C3B9062D-559E-4C84-BCC3-0B49169B81F1
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
> 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
>
> Be goode,
>
> > On 8 Jul 2017, at 01:27 , Linda Dunbar  > wrote:
> >=20
> > Aldo,=20
> >=20
> > Thank you very much for the explanation. I just want to confirm if the =
> information models specified by the draft-xibassnez-i2nsf-capability are =
> intended for NSF facing interface,  the Registration facing interface, =
> or both?
> >=20
> > Thanks, Linda
> >=20
> > -Original Message-
> > From: Aldo Basile [mailto:cataldo.bas...@polito.it =
> ]=20
> > Sent: Thursday, July 06, 2017 5:22 PM
> > To: Linda Dunbar  >; =
> draft-xibassnez-i2nsf-capabil...@ietf.org =
> ; i2nsf@ietf.org =
> 
> > Subject: Re: Does "draft-xibassnez-i2nsf-capability" also specify the =
> information model to NSF?
> >=20
> > Dear Linda,
> >=20
> > as written in the abstract, the draft describes what a NSF can do in=20=
>
> > terms of (security) policy enforcement.
> >=20
> > There are two aspects to consider to see the link between
> capabilities=20=
>
> > and policies, which is very stressed in the draft.
> >=20
> > One is the analysis.
> > Security experts, admins, etc. understand what a NSF can do by =
> analysing=20
> > its (security policy) language.
> > That is, a NSF can do what can be:
> > 1) explicitly configured with a policy composed of a set of policy =
> rules=20
> > + a set of properties to define the ambiguous situations (default =
> action=20
> > or multiple matching rules);
> > 2) implicitly enabled with some high-level function (e.g., a checkbox=20=
>
> > 'enable anti-virus').
> > We have built the model based on the analysis of tens of security=20
> > controls, by categorizing and giving semantics to the different
> policy=20=
>
> > language fields, constraints, properties, etc.
> >=20
> > Then there is the synthesis (and validation).
> > Knowing the capability associated to a NSF we also know the kind of=20
> > policies we can specify on that NSF. That is, the capability
> describes=20=
>
> > the potentiality of a NSF, which will be exploited in a specific =
> policy=20
> > (model driven?).
> > The draft proposes examples that prove that the capability model can=20=
>
> > describe real security controls.
> >=20
> > Indeed, capabilities and policies are two aspects of the same thing.
> >=20
> > As written in the draft, (and presented by John at the last I2NSF=20
> > meeting), there are more elegant ways to describe capabilities that
> do=20=
>
> > not require subclassing and complex class hierarchy. These models are=20=
>
> > more abstract but the capability-policy dichotomy is more evident.=20
> > However, we preferred to have a very concrete initial model.
> >=20
> > Then, 'packet 'filter is a generic label for devices that have the=20
> > capability to filter packets based on IP, ports, and protocol ID (and=20=
>
> > will actually filter something based on a policy composed of rules =
> with=20
> > conditions on these fields).
> > 'proto !=3D tcp'  is a valid condition for a NSF owning the capability =
> to=20
> > use conditions on the protocol ID field.
> >=20
> > Finally, with this very granular model of capabilities, there is not=20=
>
> > need to specify when a NSF owns more functions, as they will be all=20
> > summarized by its capability.
> >=20
> >=20
> > Hope this long explanation clarifies a bit the purpose of the draft =
> and=20
> > why several sections were devoted to describing policies and policy =
> rules.
> >=20
> >=20
> > Regards,
> > Aldo
> >=20
> > Thank you very much for posting the revised
> >> draft-xibassnez-i2nsf-capability-02.The draft provides a very=20
> >> comprehensive description on how to construct rules (or security=20
> >> policies) to NSFs.
> >>=20
> >> The Abstract stated:
> >>=20
> >> /"This document defines the concept of an NSF (Network Security/
> >>=20
> >> /Function) Capability, as well 

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

[John Strassner]

> Capability YANG data model is used to retrieve capability information of
> an NSF.

This is not quite correct.

Capabilities are used to express functions that can be performed. An NSF
may have multiple Capabilities. Capabilities are first **registered** using
the Registration Interface. I would have expected this model to do that.

> Capability YANG data model is used to query the capability information of
> a requested NSF and NSF-facing YANG data model is used to configure
> the rules of a policy

I find this confusing. Any YANG module should be able to get and set
information. Assuming that "query" means "get" here, I see no reason to
have a separate YANG module for that.

I do, however, see a need for a separate YANG module for
**registering** the capability information.

Note: please be careful in your wording (i.e., "model" vs. "module").

regards,
John

On Mon, Jul 10, 2017 at 8:20 AM, Mr. Jaehoon Paul Jeong <
jaehoon.p...@gmail.com> wrote:

> Hi Linda,
> Here is the clarification between NSF-facing interface YANG data model and
> Capability YANG data model.
>
> NSF-facing YANG data model is used to configure the rules of a policy into
> NSFs.
> This YANG data model is a standard interface for Security Controller to
> manipulate NSFs
> developed by various vendors.
>
> Capability YANG data model is used to retrieve capability information of
> an NSF.
> For example, after an NSF for network security control (i.e., firewall)
> inspects a packet and
> needs an additional security function such as deep packet inspection
> (DPI),
> it can ask Security Controller the location of such an additional security
> function and
> the corresponding IT resources with the Capability YANG data model.
>
> In summary, Capability YANG data model is used to query the capability
> information of
> a requested NSF and NSF-facing YANG data model is used to configure the
> rules of
> a policy (e.g., add/delete/update/read) based on an ECA paradigm.
>
> Thus, since these two models have different purposes, I think that we need
> to have two YANG drafts.
>
> Thanks.
>
> Best Regards,
> Paul
>
> On Sat, Jul 8, 2017 at 8:24 AM, Linda Dunbar 
> wrote:
>
>> Paul and Sue:
>>
>>
>>
>> You requested slots for both draft-hares-i2nsf-capability-data-model-03 &
>> draft-kim-i2nsf-nsf-facing-interface-data-model-02.
>>
>>
>>
>> The abstract of draft-kim-i2nsf-nsf-facing-interface-data-model-02
>> stated that the draft defines the data model for network security
>> functions), such as network security control, content security control, and
>> attack mitigation control,..
>>
>>
>>
>> The draft-hares-i2nsf-capability-data-model-03 has specified the
>> High-Level YANG for Network Security Control, Content Security Control and
>> Attack Mitigation Control.
>>
>>
>>
>> How are those two drafts related?  I have a vague memory that those two
>> drafts are to be merged, are they?
>>
>>
>>
>> Thank you very much,
>>
>>
>>
>> Linda
>>
>>
>>
>>
>>
>> *From:* Mr. Jaehoon Paul Jeong [mailto:jaehoon.p...@gmail.com]
>> *Sent:* Thursday, July 06, 2017 7:54 AM
>> *To:* Linda Dunbar ; Adrian Farrel <
>> adr...@olddog.co.uk>
>> *Cc:* i2nsf@ietf.org; skku_secu-brain_...@googlegroups.com
>> *Subject:* Request for Timeslots in I2NSF WG Meeting
>>
>>
>>
>> Hi Linda and Adrian,
>>
>> I would like to ask the timeslots for our 7 drafts as follows:
>>
>>
>>
>> draft-hares-i2nsf-capability-data-model-03
>>
>> - Presenter: Sue Hares
>>
>> - Time: 10 min
>>
>>
>>
>> draft-kim-i2nsf-nsf-facing-interface-data-model-02
>>
>> - Presenter: Jaehoon Paul Jeong
>>
>> - Time: 10 min
>>
>>
>>
>> draft-jeong-i2nsf-consumer-facing-interface-dm-02
>>
>> - Presenter: Jaehoon Paul Jeong
>>
>> - Time: 10 min
>>
>>
>>
>> draft-jeong-i2nsf-applicability-00
>>
>> - Presenter: Jaehoon Paul Jeong
>>
>> - Time: 15 min
>>
>>
>>
>> draft-hyun-i2nsf-nsf-triggered-steering-03
>>
>> - Presenter: Sangwon Hyun
>>
>> - Time: 10 min
>>
>>
>>
>> draft-hyun-i2nsf-registration-interface-im-02
>>
>> draft-hyun-i2nsf-registration-interface-dm-01
>>
>> - Presenter: Sangwon Hyun
>>
>> - Time: 10 min
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Best Regards,
>>
>> Paul
>>
>> --
>>
>> ===
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Assistant Professor
>> Department of Software
>> Sungkyunkwan University
>> Office: +82-31-299-4957 <+82%2031-299-4957>
>> Email: jaehoon.p...@gmail.com, paulje...@skku.edu
>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>> 
>>
>> ___
>> I2nsf mailing list
>> I2nsf@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>>
>
>
> --
> ===
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software
> Sungkyunkwan University
> Office: +82-31-299-4957 <+82%2031-299-4957>
> Email: jaehoon.p...@gmail.com, paulje...@skku.edu
> Personal Homepage: 

Re: [I2nsf] SKKU Comments on Framework Draft

[John Strassner]

That is exactly my point. The vast majority of controllers are not limited
to performing **just** security functions.
I left text in that said "security controller" to elicit more opinions.

regards,
John

On Mon, Jul 3, 2017 at 2:54 PM, Linda Dunbar <linda.dun...@huawei.com>
wrote:

> To many people’s mind, a  generic “Controller” can include other functions
> currently not in the scope of the I2NSF charter, like controlling the
> “routes”, “routing protocols”, “devices”, etc.
>
>
>
> How to restrict the scope of the “Controller” if we don’t use “I2NSF
> Controller” in documents?
>
>
>
> Linda
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *John
> Strassner
> *Sent:* Sunday, July 02, 2017 10:50 PM
> *To:* i2nsf@ietf.org; John Strassner <straz...@gmail.com>
> *Subject:* [I2nsf] SKKU Comments on Framework Draft
>
>
>
> Here is my proposed resolution:
>
>
>
> The following terms need to be unified in the whole text.
> OLD: I2NSF Controller (or controller)
> NEW: Security Controller
>
> OLD: Customer-Facing Interface
> NEW: Consumer-Facing Interface
>
> 
>
> The terminology document defines "Controller". We want to stay aligned
> with SACM, and SACM also uses Controller. The term "Security Controller"
> implies a dedicated function that only does security; such entities are
> being replaced by "Controllers".  I propose to change I2NSF Controller to
> Controller, and reference the terminology document on first use.
>
> 
>
>
>
> The following phrase in Section 6.1 is not clear:
> ... as described in [I-D.pastor-i2nsf-nsf-remote-attestation],
> with the only possible exception of the application of the lowest
> levels of assurance, in which case the user MUST be made aware of
> this circumstance.
>
> What are the lowest levels of assurance?
>
> 
>
> Described in section 4.1 of the remote-attestation draft. I changed as
> follows:
>
>
>
> The only
>possible exception is when the required level of assurance is lower,
>(see Section 4.1 of [I-D.pastor-i2nsf-remote-attestation], in which
>case the user must be made aware of this circumstance.
>
> 
>
>
>
> In Section 7.1, the following example of ECA policy needs to be corrected
> by swapping the phrases of Event and Condition because User belongs to
> Event
> and Traffic type belongs to Condition in ECA paradigm:
> OLD:
> An Event can be "traffic of type X detected"
> A Condition can be a "user identifier is Z" and/or "traffic from
> domain-A to domain-B"
>
> NEW:
> An Event can be a "user identifier is Z"
> A Condition can be "traffic of type X detected" and/or "traffic from
> domain-A to domain-B"
>
> 
>
> I disagree. No action will be taken.
>
>
>
> An event is defined as a significant occurrence in time. The given event
> (traffic of type X detected) is a significant occurrence in time (e.g., a
> packet arrival). It is incorrect to say that just because a user is
> referenced, it must be an event.
>
>
>
> Similarly, a condition is defined as something that can be compared with a
> known value. There is no reason why a user-identifier cannot be compared
> with a known value. Furthermore, why is a user-identifier a "significant
> occurrence in time"?
>
>
>
> Please reread the terminology draft definitions.
>
> 
>
>
>
> In Section 9.1, attack mitigation needs to be added as follows:
> o An attack mitigator detects DDoS attacks (e.g., DNS reflection
> attack and TCP SYNC flood) and Single-packet attacks (e.g.,
> IP sweep, port scanning, ping of death, and oversized ICMP).
>
> 
>
> Yes, it could be added, but so could 100 other things. This section is
> simply trying to explain, at a high conceptual level, different types of
> flows. Attack mitigation is typically included as part of a higher level
> package, not as a stand-alone function. Finally, you provided a limited
> description (which is part of the problem of including it). Hence, no
> action will be taken.
> 
>
>
>
>
> Some acronyms need to be expanded:
> OLD: SYSLOG
> NEW: Security Issues in Network Event Logging (SYSLOG)
>
> 
>
> Syslog was defined as SYStem Log. I have no idea what your expansion is
> (SINEL?).
>
> Rejected.
>
> 
>
> OLD: DOTS
> NEW: DDoS Open Threat Signaling (DOTS)
> 
>
> fixed in Section 3.2, does not appear here
>
> 
>
>
> OLD: IDR
> NEW: Inter-Domain Routing (IDR)
>
> 
>
> This is in Section 9.2.
>
> OLD: PCP
> NEW: Port Control Protocol (PCP)
>
> OLD: TRAM
> NEW: TURN Revised and Modernized (TRAM)
> 
>
> OK on the two above
>
> 
>
> --
>
> regards,
>
> John
>



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

[I2nsf] Framework Draft, section 6.2

[John Strassner]

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
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] Framework Draft Comments From Adrian

[John Strassner]

Hi Adrian,

thanks for the thorough review. Your comments are addressed below. Please
note that I can NOT find reviews of this draft by Christian and Med. I did
search the archive. I found comments on the terminology draft from
Christian.

regards,
John

ALL comments were accepted, except as noted below.


In 2.2, the term used in
is "I2NSF Consumer"

I suggest you write
   Consumer: Equivalent to "I2NSF Consumer"


This should be I2NSF Consumer according to the terminology draft, so I made
that change throughout this document.


---

I'm struggling a little with 

3.3.  Registration Interface

   NSFs provided by different vendors may have different capabilities.
   In order to automate the process of utilizing multiple types of
   security functions provided by different vendors, it is necessary to
   have an interface for vendors to define the capabilities of their
   NSFs.  This Interface Group is called the Registration Interface
   Group.

   An NSF's capabilities can either be pre-configured or retrieved
   dynamically through the Registration Interface Group.  If a new
   function that is exposed to the consumer is added to an NSF, then
   those capabilities SHOULD be notified to security controllers via the
   Registration Interface Group.

There is definitely an ambiguity about this. Is the section talking
about the "Registration Interface Group"? What are the component
interfaces in this group?


Terminology defines an Interface Group, but not a Registration Interface
Group. I have changed this to "I2NSF Registration Interface".
Here is the rewritten paragraph:
3.3.  I2NSF Registration Interface
   NSFs provided by different vendors may have different capabilities.
   In order to automate the process of utilizing multiple types of
   security functions provided by different vendors, it is necessary to
   have a dedicated interface for vendors to define the capabilities of
   (i.e., register) their NSFs.  This Interface is called the
   I2NSF Registration Interface.
   An NSF's capabilities can either be pre-configured or retrieved
   dynamically through the I2NSF Registration Interface.  If a new
   function that is exposed to the consumer is added to an NSF, then
   those capabilities should be notified to security controllers via the
   I2NSF Registration Interface.

---

6.1.  Network Connecting I2NSF Users and I2NSF Controller

   [TBD: should we add the Remote Attestation to this section?]

I think you have added remote attestation and can remove this note.


Not yet - see earlier note. Since there are at least two different
approaches to remote attestation in the IETF, I think the WG still needs to
decide what to do here. I see no reason why we can't push this framework
draft forward and then have the remote attestation work (which still isn't
even a WG draft) add on and augment later. Hence, no action has yet been
taken.


---

6.2

   The network connection between the Security Controller and NSFs can
   rely either on:

Should you be making clear that in the open environment anything from a
few up to all of the NSFs can be hosted in external administrative
domains.  Thus "closed" is very tightly defined, and "open" is anything
that is not completely closed.


Here is the rewrite:
   o  Open environments, where one or more NSFs can be hosted in one or
  more external administrative domains that are reached via secure
  external network connections.  This requires more restrictive
  security control to be placed over the I2NSF interface.  The
  information over the I2NSF interfaces shall be exchanged used
  trusted channels as described in the previous section.

   When running in an open environment, I2NSF needs to rely on
   interfaces to properly verify peer identities (e.g., through an AAA
   framework).  The implementations of identity management functions,
   as well as the AAA framework, are out of scope for I2NSF.


---

I can't help thinking that section 9.2 is way too detailed for this
document. I don't think there is anything wrong in what it says, but it
looks more like an information model for a specific capability exchange
than something that belongs in a general framework.

Can you see whether there is a different document that this belongs in?


This COULD be folded into the Capability Interface document, and then this
(the Framework) document could reference the Capability interface document.
However, that document is not yet accepted by the WG. So, would you like me
to:

   1) leave as is, so the Framework document can proceed to last call, or
   2) move this entire section to the Capability document, or
   3) do something other than 1) or 2)?



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

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

[John Strassner]

Here is my proposed resolution to these points:

1. nits: P18 " Table 1: Subject Capability Index " should change to " Table
1: Packet Content Matching Capability Index ",  P19, " Table 2: Object
Capability Index " should change to " Table 2: context matching Capability
Index ";
[Rakesh]  Makes sense to me. We should take this.

Done. Also fixed captions of Tables 3 and 4. :-)



2. Section 11 of Security Considerations: this section is a little bit
simple without considering the possible threats like: unauthenticated
connections between users and controller, and between controller and NSFs,
DoS attacks from malicious users or NSFs, etc;
[Rakesh] In my opinion, this is just a framework document. Any specific of
security considerations (such as you pointed out) should go into each
individual drafts covering client, regigttration and NSF interfaces.  If
you think it would help, we could add something like this to the section 11.

I agree with Frank. I think we should add text before we go to last call.
Let's discuss in Prague. No action for now (but am still going through
comments).



3. question: should section 7.3 move to the I2NSF gap analysis draft?
[Rakesh] I don’t have very strong opinion one way or other but it gives
some context to other sections. It is good to have.

I think it should stay here. No action taken.



4. I think remote attestation function should be described as a part into
the whole I2NSF framework;
[Rakesh] I agree with you.

Disagree. There is major work to be done in remote attestation. We have at
least two different approaches that will (hopefully) be merged in the near
future. This would delay the last call of this document by...pick a date..6
months minimum imho.

I don't see why remote attestation cannot reference and augment this draft.
No action taken.



5. Section 3.2, by my understanding, notification is just part of the
monitor functions, such as: syslog, netconf. Is it necessary to divide them
into two interfaces?
[Rakesh] In larger scheme of things, everything can be combined into one
but it is good to show differentiation since each set serve different
purpose and may require different operational characterstics.

I do not read the text this way. First, it describes THREE, not two,
interfaces. Second, none of the three categories are mentioned again in the
entire document. I read this as explanatory text to help the reader develop
a better conceptual understanding of the document.
No action taken.



regards,
John

On Thu, May 25, 2017 at 1:15 PM, Rakesh Kumar  wrote:

> Hi Frank,
>
> Thanks for your review and support. We will make changes to the draft
> based on your comments and any other comments we receive in next few days.
> Please see my take on your comments below.
>
> Thanks
> Rakesh
>
> On 5/21/17, 8:32 PM, "I2nsf on behalf of Xialiang (Frank)" <
> i2nsf-boun...@ietf.org on behalf of frank.xiali...@huawei.com> wrote:
>
> Hi Adrian, I2NSFers,
> I reviewed the latest draft again and thinks it's in a very good shape
> now. So, it can be a foundation for all the other drafts.
>
> Of course, I also have some comments about it as below:
> 1. nits: P18 " Table 1: Subject Capability Index " should change to "
> Table 1: Packet Content Matching Capability Index ",  P19, " Table 2:
> Object Capability Index " should change to " Table 2: context matching
> Capability Index ";
> [Rakesh]  Makes sense to me. We should take this.
>
> 2. Section 11 of Security Considerations: this section is a little bit
> simple without considering the possible threats like: unauthenticated
> connections between users and controller, and between controller and NSFs,
> DoS attacks from malicious users or NSFs, etc;
> [Rakesh] In my opinion, this is just a framework document. Any specific of
> security considerations (such as you pointed out) should go into each
> individual drafts covering client, regigttration and NSF interfaces.  If
> you think it would help, we could add something like this to the section 11.
>
> 3. question: should section 7.3 move to the I2NSF gap analysis draft?
> [Rakesh] I don’t have very strong opinion one way or other but it gives
> some context to other sections. It is good to have.
>
> 4. I think remote attestation function should be described as a part into
> the whole I2NSF framework;
> [Rakesh] I agree with you.
>
> 5. Section 3.2, by my understanding, notification is just part of the
> monitor functions, such as: syslog, netconf. Is it necessary to divide them
> into two interfaces?
> [Rakesh] In larger scheme of things, everything can be combined into one
> but it is good to show differentiation since each set serve different
> purpose and may require different operational characterstics.
>
>
> B.R.
> Frank
>
> -邮件原件-
> 发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Adrian Farrel
> 发送时间: 2017年5月19日 1:49
> 收件人: i2nsf@ietf.org
> 主题: [I2nsf] Progress with draft-ietf-i2nsf-framework-05
>
> Hi WG,
>
> I am about to do a document 

Re: [I2nsf] Chairs

[John Strassner]

Hi Kathleen,

I support Diego becoming a co-chair. He has excellent working knowledge of the 
drafts and issues, and more importantly, can help direct the WG in achieving 
its goals.

Best regards,
John

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Diego R. Lopez
Sent: Monday, June 19, 2017 4:03 PM
To: Kathleen Moriarty 
Cc: i2nsf@ietf.org;  
; Eric Rescorla 
Subject: Re: [I2nsf] Chairs

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 
> 
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
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] Should the draft-xibassnez-i2nsf-capability-01 be characterized as "Information model"? or something else?

[John Strassner]

Hi Linda,

this is an **information model** draft. Note that Figure 1 shows how this
draft is used with external models, such as SUPA. Figures 2-6 describe
Network Security, while Figures 7 and 8 define the Security Capability and
Content Capability models, and FIgure 9 shows an Attack Mitigation
Capability model.

Capabilities are registered on the Registration Interface, and negotiated
and used on the NSF-facing interface.

regards,
John



On Thu, May 18, 2017 at 12:09 PM, Linda Dunbar 
wrote:

> John, Frank, Diego and Aldo,
>
>
>
> It seems to me that the draft-xibassnez-i2nsf-capability-01 covers the
> I2NSF rule structure.  In your view, should the 
> draft-xibassnez-i2nsf-capability
> be characterized as the information model?
>
> If it is characterized as the information model, are they exchanged over
> the NSF facing interface? Or over the registration interface (identified in
> the Framework draft)?
>
>
>
> Thanks, Linda
>
>
>



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

Re: [I2nsf] Will definitions related to "Attestation" to be added to I2NSF terminology draft? and the survey msg?

[John Strassner]

Hi Linda,

I will start on these in the middle of next week. I am happy to coordinate
the editing as usual; however, attestation will need input from Henk and
Diego.

regards,
John

On Thu, May 18, 2017 at 8:25 AM, Linda Dunbar 
wrote:

> John, Sue, Diego, Frank, and Henk,
>
>
>
> During the I2NSF terminology discussion at I2NSF WG session in IETF98,
> there were some discussions on if terminologies related to Attestation need
> to be added to the terminology draft. Want to ask if there is any plan to
> add them.
>
> The IETF 98 meeting notes also have the following:
>
>
>
> - Need to explore metadata more (its use in netmod is not aligned with
> that of other SDOs)
>
> - Need to explore Events
>
>   - should we differentiate between event types (e.g., alarms vs.
> threshold crossings) or assume that all are equal?
>
>   - how robust a definition is needed?
>
> - Would like to see if terminology can help mismatch between info and data
> models
>
>
>
> AI: start list email threads on the list of issues presented
>
>
>
> Just checking if those issues will be addressed.
>
>
>
> Thanks, Linda
>
>
>



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

[I2nsf] Request a slot to present draft-i2nsf-xibassnez... and the Terminology draft

[John Strassner]

Dear chairs,

I would like to request two presentation slots for our upcoming meeting in
Chicago:

   1) a 10 minute update for the Terminology draft (new draft to be sent
soon)
   2) a 20 minute update for the Capability Info Model draft

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

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

[John Strassner]

+1

regards,
John

On Fri, Nov 11, 2016 at 3:28 AM, Diego R. Lopez <
diego.r.lo...@telefonica.com> wrote:

> Hi,
>
> I support adoption (as co-author)
>
> Be goode,
>
> On 2 Nov 2016, at 20:31 , Linda Dunbar  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
> 
> 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
> 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
>
>


-- 
regards,
John
___
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?

[John Strassner]

I agree with Diego.

As a manager of networks, I have used ECA for both. I’m currently experimenting 
with declarative policies for both. I do NOT think that this is a “new” type of 
policy rule or statement. In fact, I’m not sure that we even need a blank 
condition clause for the first type.

I would suggest:

1.   Please provide an example (even in English) of the specific rules that 
you envision, as your description is too high-level to tease out any hidden 
details, and

2.   Please read the SUPA info model draft

Regards,
John

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Diego R. Lopez
Sent: Friday, November 11, 2016 3:28 AM
To: Rakesh Kumar 
Cc: i2nsf@ietf.org; Adrian Farrel ; Linda Dunbar 

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

Hi,

I am afraid we have a language gap here, Rakesh. In my view, you are talking of 
two kind of rules that can be expressed with an ECA model, only that those in 
the first class would have an empty (or wildcard or default) condition 
expression that will make them applicable whenever a certain event happens. As 
you said, we need some brainstorming to bridge these language gaps.

Be goode,

On 2 Nov 2016, at 17:15 , Rakesh Kumar 
> wrote:

Hi Linda,

One more thing regarding how a policy/rule is to be enforced. We see two 
distinct requirements:

1.   Static security posture --> The security admin determines what 
security policies need to be enforced in their network based on their business 
needs (access policies such as who can access what) and/or regulatory 
compliance (HIPPA, FISA). These policies usually stay in the network unless 
manually removed. In my experience, majority of security policies fall under 
this category.
2.   Dynamic  security posture --> Some of the policies may be created but 
not always enforced. A security admin may want to increase or decrease its 
security posture based on an event. The event could be a time-based or threat 
based. For example, a policy is enforced only during weekend or a policy is 
enforced only when a DDoS event is detected.

I don’t have any name for first one but the second one is ECA (Event Condition 
Action). We wanted to take both of them for interfaces to be meaningful in real 
security world. I hope this clarifies our thinking. We can add a section in our 
draft to put similar text there if you think that would be helpful.

Thanks & Regards,
Rakesh


From: I2nsf > on behalf 
of Rakesh Kumar >
Date: Tuesday, November 1, 2016 at 11:56 AM
To: Linda Dunbar >, 
"i2nsf@ietf.org" >
Cc: Adrian Farrel >
Subject: Re: [I2nsf] Will you provide more details on the Rules' Information 
model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Hi Linda,

Thanks a lot for the review.

One of the biggest challenges in the security world today is that, it is too 
complex with each vendor having their own set of features and functionality 
exposed in a very proprietary manner.  We have to simplify this with I2NSF 
client-facing interface so that a security admin can express their business 
needs without having to worry about the complexity.

It is very important that security requirements be expressed by security admin 
with simple rules. But it is easier said than done, this is one of the most 
complex problem as how to make rules simple but at the same time able to 
capture wide variety of use-cases in different environment.

The work done so far in this draft is just the beginning and we should brain 
storm and see how to make it more complete. I will look at the link you have 
sent and see how to leverage from there. Even if we develop very generic rules, 
we still need to define some basic constructs which would be used to build a 
policy. We have taken a step in that direction, but this is just a start and 
work will continue with ideas from folks in this WG.


Regards,
Rakesh

From: Linda Dunbar >
Date: Tuesday, November 1, 2016 at 10:55 AM
To: Rakesh Kumar >, 
"i2nsf@ietf.org" >
Cc: Adrian Farrel >
Subject: RE: [I2nsf] Will you provide more details on the Rules' Information 
model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Rakesh,

By the way, the I2NSF framework has specified to use ECA (Event Condition 
Action) to describe “Rules”.

Re: [I2nsf] IETF-97 I2NSF agenda revised

[John Strassner]

Sue, could you do the terminology as well? It is short, I'll even do slides
for you - I can't go due to a family health problem.

thanks,
John

On Thu, Nov 3, 2016 at 8:46 AM, Susan Hares  wrote:

> Linda:
>
>
>
> May I tentatively get a time slot for the Problem statement and use case?
>   5 minutes or less would be fine.
>
>
>
> Sue Hares
>
>
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *Linda Dunbar
> *Sent:* Thursday, November 3, 2016 11:33 AM
> *To:* 'i2nsf@ietf.org'
> *Subject:* Re: [I2nsf] IETF-97 I2NSF agenda revised
>
>
>
> Thanks to people pointing out some missing items. The I2NSF agenda has
> been revised.
>
>
>
> https://datatracker.ietf.org/meeting/97/agenda/i2nsf/
>
>
>
> If you requested agenda time and don't see yourself there, or if you need
> to make a correction, please let the chairs know.
>
>
>
> Thanks,
>
>
>
> Linda & Adrian
>
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>


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

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-terminology-02.txt

[John Strassner]

Hi Daniel,

Thanks for the comments, please see inline.

Best,
John

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Daniel Migault
Sent: Wednesday, November 02, 2016 3:20 AM
To: i2nsf@ietf.org
Subject: Re: [I2nsf] I-D Action: draft-ietf-i2nsf-terminology-02.txt

Please consider responding to this email rather than the previous one. -- Too 
many CCs.
Yours,
Daniel

On Wed, Nov 2, 2016 at 6:16 AM, Daniel Migault 
<daniel.miga...@ericsson.com<mailto:daniel.miga...@ericsson.com>> wrote:
Hi,
I reviewed the document. Please find my comments below.
Yours,
Daniel


   Metadata:  Data that provides information about other data.

MGLT: This is actually how metadata is defined. However, it might be usefull to 
provide an example, or conplete the definition.

How about if we add an example? As you say, this is a complete and concise 
definition of metadata; I would prefer if the definitions are kept concise, and 
are augmented with examples.

I an also wondering if I2NSF only defines metadata associated to YANG models. 
If so woudl it be relevant to mention RFC7952 ?

This is a good point.

The examples do not seem to ilustrate what metadata is, instead they mention 
protocols that use YANG for which metadta is defined.
  Examples include IETF network management protocols (e.g.  NETCONF,
  RESTCONF, IPFIX) or IETF routing interfaces (I2RS).  The I2NSF
  security interface may utilize Metadata to describe and/or
  prescribe characteristics and behavior of the YANG data models.

You are correct. I propose replacing the existing example with the following:
Metadata may be used to describe and/or prescribe the characteristics
and behavior of the data that the metadata applies to. Metadata is NOT
limited to metadata as defined in YANG models [RFC7952]; rather,
metadata ca be used to augment the modeling of any I2NSF model
element. Examples include:
  - version information of an I2NSF Capability, I2NSF Component,
 I2NSF Policy, or other function or object of an I2NSF system
   - descriptive information, such as best current practices or other
 usage information, that describe the use or operation of an
 I2NSF Component
   - prescriptive information, such as algorithms or commands, that
 define how an I2NSF Component should be used


   Network Security Function (NSF):  Software that provides a set of
  security-related services.  Examples include detecting unwanted
  activity and blocking or mitigating the effect of such unwanted
  activity in order to fulfil service requirements.  The NSF can
  also help in supporting communication stream integrity and
  confidentiality.

MGLT: It is not clear to me the relation between function and service. My 
understanding is that service may involve multiple functions. But I believe it 
would be helpful to position these two concepts - at least in this definition.


Good point. How about:
   Network Security Function (NSF):  Software that provides a set of
  security-related services. An NSF represents the software as a
  functional block. An NSF functional block may contain one or
  more security-related services. Examples include detecting unwanted
  activity and blocking or mitigating the effect of such unwanted
  activity in order to fulfil service requirements.  The NSF can
  also help in supporting communication stream integrity and
  confidentiality.


   Producer:  A Producer is a Role that is assigned to an I2NSF
  Component that can send information and/or commands to another
  I2NSF Component.  See also: Consumer, Role.

MGLT: Is Producer equivalent to provider ? If so maybe that would hepl to use a 
single designation.


I assume you mean I2NSF Provider Interface? Or are you worried that people will 
equate Provider to Producer?
Generically, Providers supply services, but are NOT a functional block in an 
I2NSF system. Rather, they are actors that use an I2NSF system. In contrast, a 
Producer is a functional block in an I2NSF system that supplies information, 
resources, or services for consumption by other I2NSF Components.
We could add the fact that a Producer is a type of I2NSF Component, whereas a 
Provider is not.
We could also define a functional block. ☺


On Sun, Oct 23, 2016 at 9:44 PM, 
<internet-dra...@ietf.org<mailto: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 of the 
IETF.

Title   : Interface to Network Security Functions (I2NSF) 
Terminology
Authors : Susan Hares
      John Strassner
  Diego R. Lopez
  Liang Xia
  Henk Birkholz
Filename: draft-ietf-i2nsf-terminology-02.txt
Pages   : 13
Date: 2016-10-23

Abstract:
   Thi

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

[John Strassner]

I agree with your recommendations.

Regards,
John

-Original Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, November 02, 2016 11:42 AM
To: i2nsf@ietf.org
Cc: 'Kathleen Moriarty' 
Subject: [I2nsf] RFC or not RFC in I2NSF?

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
https://www.ietf.org/mailman/listinfo/i2nsf

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

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

[John Strassner]

Hi all,

The main reason for publishing an information model is to support multiple
data models that are derived from it.

I realize that the IETF is worried mainly about YANG data models. That is
perfectly well and good. However, security controllers will need to
interface with compute, storage, and other systems that have poor (if any)
YANG coverage. As soon as I go into a data center or a cloud, YANG is
simply not used for compute and storage solutions.

This means that we can either ignore that, and build a silo, or take it
into account, or not.

   If we choose to ignore, there is no reason to publish the info model.
   If we choose not to ignore, and want to support other data models, then
we SHOULD publish the info model as well. Even if we only have 1 data model
now.

Hence, I personally would prefer two publications - one for the info model,
and one for the YANG data model.


best,
John


On Sat, Oct 22, 2016 at 4:29 AM, Diego R. Lopez <
diego.r.lo...@telefonica.com> wrote:

> 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  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; 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
> 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
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>
> ___
> 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

[John Strassner]

I agree as well.

regards,
John

On Mon, Oct 24, 2016 at 4:13 AM, Adrian Farrel  wrote:

> Hi Bob, Diego, all,
>
>
>
> This sounds like a plan to me.
>
>
>
> As for other docs making references, so long as those references are
> Informative and not Normative, it's fine. If, on the other hand, you find
> yourself relying on something (i.e., Normative reference) you will probably
> want to lift the text into your own document.
>
>
>
> Thanks,
>
> Adrian
>
>
>
> *From:* Robert Moskowitz [mailto:r...@labs.htt-consult.com]
> *Sent:* 23 October 2016 02:17
> *To:* Diego R. Lopez; adr...@olddog.co.uk
> *Cc:* i2nsf@ietf.org; draft-ietf-i2nsf-gap-analy...@ietf.org
> *Subject:* Re: [I2nsf] Thinking about what to do with
> draft-ietf-i2nsf-gap-analysis
>
>
>
> I think we should keep the gap analysis current with what ever gaps still
> are present.  Maybe move addressed gaps to a 'handled' section of the
> draft.  This way we have a history of what the gap analysis drove to
> completion.  Once all gaps are handled THEN we let it expire.
>
>
>
> Bob
>
>
>
> On 10/22/2016 07:16 AM, Diego R. Lopez wrote:
>
> 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  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
> 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
> --
>
>
>
>
>
> --
> Robert Moskowitz
> Owner
> HTT Consulting
> C:  248-219-2059
> F:  248-968-2824
> E:  r...@labs.htt-consult.com
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>


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

[I2nsf] I2NSF Terminology Update

[John Strassner]

As promised, a new version is now posted, specifically for helping to align
the framework draft.

Changelog:

Pages 3-4
   Rewrote Section 2
Page 4
   Removed Capability Interface
   Changed and expanded definition of Consumer
Page 6
  Added Flow
Page 9
   Added Interface Group

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

Re: [I2nsf] Need two different names: One for the Set of rules with Users/tenants oriented attributes; another for Set of rules that are applied to NSFs (i.e. port/addresses based).

[John Strassner]

Hi Linda,

the original question was about the **Capability Interface**. I'm not sure
that this is what you are talking about, so let me be explicit.

The original architecture had four interfaces:

   1) Consumer-Facing Interface (a.k.a., Client-Facing Interface)
   2) NSF-Facing Interface
   3) Capability Interface
   4) Registration Interface

I **like** these four interfaces, because they each serve different
purposes (ref: Single Responsibility Principle, among others, in software
architecture).

Now it appears that you are no longer talking about the Capability
Interface; rather, you want to change the definition of Consumer to clarify
that it is acting between end-users of the I2NSF system and the controller.
Assuming that this is correct, how about the following modification:

   Consumer:  A Consumer is a Role that is assigned to an I2NSF
  Component that represents the needs of a user of I2NSF services.
  A consumer can send/receive information to/from another I2NSF
  Component (e.g., for defining and monitoring security policies
  for the Consumer's specific flows through an I2NSF
  administrative domain).  See also:  Provider, Role.

regards,
John

On Wed, Oct 19, 2016 at 8:18 AM, Linda Dunbar <linda.dun...@huawei.com>
wrote:

> John,
>
>
>
> All we need is to have two different names to differentiate
>
> -Set of rules with Users/tenants oriented attributes
>
> -Set of rules that are applied to NSFs (i.e. port/addresses
> based).
>
>
>
> Consumer facing and NSF facing would be good, but with the definition for
> “Consumer” in the terminology draft , “consumer” can also mean controller
> consuming NSFs (i.e. the NSF facing interface).  If we use the “consumer
> facing interface”, can you modify the definition for “consumer”?
>
>
>
>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.
>
>
>
>
>
> Thanks, Linda
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Wednesday, October 19, 2016 2:10 AM
> *To:* Linda Dunbar <linda.dun...@huawei.com>; John Strassner <
> straz...@gmail.com>
> *Subject:* Re: you could be correct, but we are dealing with a group of
> people who commonly interpret "Interface" as "port"
>
>
>
> I'm confused.
>
>
>
> There is no argument about Consumer-Facing and NSF-Facing Interfaces.
>
> Do you want two different names for the Capability Interface, one for
> Consumer-Facing and one for NSF-Facing Interfaces? Or do you want something
> else?
>
>
>
> I am troubled that the list is silent.
>
>
>
> regards,
>
> John
>
>
>
> On Tue, Oct 18, 2016 at 6:27 PM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
> John,
>
>
>
> You can be correct. But the Interim meeting, most people expressed the
> desire of using “interface” to mean the “port” on the controller: one port
> facing user (i.e. the User/client facing interface), another port facing
> NSFs (NSF-Facing interface).
>
>
>
> Sept 13 meeting minutes:
>
> Final agreement: We
>
>
>
> Two interfaces
>
> - Consumer/Client Facing Interface
>
> - NSF Facing Interface
>
> Within these we have "sets of operations"
>
> One of these sets is the "Capabilities set of operations"
>
>
>
>
>
>
>
> At the time I didn’t realize that “consumer” also applicable to
> “Controller” consuming the NSFs. That is why I want to use a different
> term.
>
>
>
> All we need is to have two different names to differentiate
>
> -Set of rules with Users/tenants oriented attributes
>
> -Set of rules that are applied to NSFs (i.e. port/addresses
> based).
>
>
>
>
>
> Let’s use have two names and move forward.
>
>
>
> Can you give me a call?
>
>
>
> Thanks, Linda
>
>
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Tuesday, October 18, 2016 2:19 PM
> *To:* i2nsf@ietf.org
> *Cc:* Linda Dunbar <linda.dun...@huawei.com>; Adrian Farrel <
> adr...@olddog.co.uk>; John Strassner <straz...@gmail.com>
> *Subject:* The (in)famous Capability Interface
>
>
>
> Hi all,
>
>
>
> recently, a number of questions have been raised about the Capability
> Interface. There are two sources of confusion:
>
>
>
>1) What, exactly, is an "interface"? Can we use a different word
> instead of interface?
>
>2) Why do we need another interface (or similar word)?
>
>
>
> Clarifying the first issue.
>
> A

[I2nsf] The (in)famous Capability Interface

[John Strassner]

Hi all,

recently, a number of questions have been raised about the Capability
Interface. There are two sources of confusion:

   1) What, exactly, is an "interface"? Can we use a different word instead
of interface?
   2) Why do we need another interface (or similar word)?

Clarifying the first issue.
A number of people have stated that to them, an "interface" is synonymous
with "communication". This is NOT what was meant when this I-D was written.
Indeed, the definition of Interface, from that I-D, is as follows:

   Interface:  A set of operations one object knows it can invoke on,
  and expose to, another object.  It is a subset of all operations
  that a given object implements.  The same object may have multiple
  types of interfaces to serve different purposes.  An example of
  multiple interfaces can be seen by considering the interfaces
  include a firewall uses; these include:
 *  multiple interfaces for data packets to traverse through,
 *  an interface for a controller to impose policy, or retrieve
the results of execution of a policy rule.
  See also: Consumer Interface, I2NSF Interface, Provider Interface

Note that the above definition implies a **shared boundary** across which
two entities send and/or receive data. In other words, what's important is
the set of standard operations that can be invoked, and **not** the fact
that this is a form of communication.

Clarifying the second issue.
The reason that a separate interface for exchanging capability information
was proposed is to minimize the attack surface. The capability interface is
for exchanging **all** capabilities, so that two entities may negotiate and
agree on what set of capabilities will actually be used. Clearly, this is
different than operation on either the consumer-facing or NSF-facing
interfaces, since those interfaces are constrained to using **only** the
set of capabilities that have been agreed upon to use. This follows the
well-known Principle of Least Privilege (i.e., in a particular abstraction,
every function must be able to access **only** the information and
resources that are necessary for the legitimate purpose of that function.

Exposing the set of **all** capabilities over a widely used interface (like
the consumer- or NSF-facing interfaces) is a **bad idea**. It risks an
attacker understanding the complete set of capabilities of the system.
Furthermore, from a software componentization point-of-view, there is a
significant difference between exposing and negotiating between the set of
all capabilities (which is the purpose of the Capability Interface) and
simply using a selected set of capabilities (which is the purpose of the
consumer-facing or NSF-facing interfaces).

I hope this clarifies these two issues. I'll wait a couple of days before
issuing the next update to the Terminology Draft.

best regards,
John

-- 
regards,
John
___
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"

[John Strassner]

Well, no it wouldn’t.

Please see my earlier email with respect to client-facing interface. I don’t 
like “client”, it has the wrong connotations for modern software.
A consumer is an entity that is using something (data, services, etc.) that is 
given to it. Which is exactly what this interface is doing.
Tenant has other connotations, and we have not yet designed the framework to be 
truly multi-tenant.
Customer is not appropriate for other reasons (is an agent a customer?).

We had already decided on this before, why is it being brought up again?


Regards,
John

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, October 17, 2016 2:50 PM
To: Diego R. Lopez <diego.r.lo...@telefonica.com>
Cc: i2nsf@ietf.org; John Strassner <straz...@gmail.com>
Subject: Re: [I2nsf] Definition for "Consumer" in I2NSF terminology , in the 
context of "Client Facing Interface"

The I2NSF framework currently uses “client-facing –interface”.
Either “Tenant-facing-interface” or “User-facing-interface” would be equivalent.

Linda
From: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com]
Sent: Monday, October 17, 2016 4:36 PM
To: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Cc: John Strassner <straz...@gmail.com<mailto:straz...@gmail.com>>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Subject: Re: [I2nsf] Definition for "Consumer" in I2NSF terminology , in the 
context of "Client Facing Interface"

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<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] Call for WG adoption of draft-kumar-i2nsf-client-facing-interface-req

[John Strassner]

I think that this draft has good, promising work in it. However, I do
not think that it is ready, at this moment in time, for WG adoption.
Here are some specific points focused on just the Abstract that I
think the authors should work on to improve this draft:

DRAFT:
   This document provides a framework ...

I am missing how this framework relates to the framework draft;
this needs to be covered.


DRAFT:
   ...and information model for the definition of northbound
   interfaces for a security controller.

I could not find an information model in this draft. While I don't
expect a detailed model at this stage, I don't even see proposed
classes or the beginning of a class hierarchy.


DRAFT
   The interfaces are based on user-intent instead of vendor-specific
   or device-centric approaches...

There are too many subjects that are attempted to be covered!
User-intent is a subject by itself - a big one. There isn't even a
definition in I2NSF of this term, let alone in the industry . I would
strongly recommend that this be moved into a separate draft.


DRAFT
   The document identifies the
   common interfaces needed to enforce the user-intent based policies
   onto network security functions (NSFs) irrespective of how those
   functions are realized.

How can you define a set of interfaces when there is no definition of
user-intent based policies? I'm not even sure what a "user-intent
based policy is",



best regards,
John

On Wed, Sep 21, 2016 at 10:54 AM, Linda Dunbar 
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
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>


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

Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model

[John Strassner]

Hi Sue,

That's a great observation Sue. Let's work together and propose a
combination to the rest of the group.

best regards,
John

On Tue, Sep 13, 2016 at 11:32 AM, Susan Hares <sha...@ndzh.com> wrote:

> Annika:
>
>
>
> It is good to have both the RFC4949 definition and the link to existing
> reductions of that definition (ietf-netmod-acl-model, SUPA, and I2RS
> filter-based RIB drafts).  However, I need advice from John on how he’d
> like to see that combination work.
>
>
>
> Sue
>
>
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *Annika
> Sparkles
> *Sent:* Tuesday, September 13, 2016 1:51 PM
> *To:* John Strassner
> *Cc:* Rakesh Kumar; DIEGO LOPEZ GARCIA; i2nsf@ietf.org; Linda Dunbar;
> Xialiang (Frank); elopez.i...@nym.hush.com; Susan Hares
> *Subject:* Re: [I2nsf] I2NSF Terminology's definition on "ACL" is
> different from ietf-netmod-acl-model
>
>
>
> "an ACL is first and foremost a mechanism to select something "
>
>
>
> nodding.
>
>
>
> If I'm derailing this discussion away from the larger discussion happening
> around ACL's then I'm fine letting this go, but I would just like to say
> that I really like how you describe network ACL's here.
>
>
>
> On Tue, Sep 13, 2016 at 11:49 AM, John Strassner <straz...@gmail.com>
> wrote:
>
> Hi Annika,
>
>
>
> That's a fair description. There is the academic part (including a set of
> conferences from the 90s!) from which a set of more powerful generic access
> control models (e.g., RBAC, ABAC, and others) were developed, and then
> there is the networking usage. However, imho, the key point in the
> networking usage is that an ACL is first and foremost a mechanism to select
> something - what you do with it (forward, drop, etc) depends on what you do
> AFTER the traffic is selected.
>
>
>
> regards,
>
> John
>
>
>
> On Tue, Sep 13, 2016 at 9:41 AM, Annika Sparkles <
> annika.g.spark...@gmail.com> wrote:
>
> Through my years of network engineering I started out thinking of ACL as
> "block packets at a port level" and then morphed into "a type match filter
> to accomplish various tasks across multiple planes" as I implemented them
> more and more in different networking applications. (COPP, QoS, BGP, WAN
> Acceleration, PFR and so on and so forth).
>
>
>
> On Tue, Sep 13, 2016 at 8:27 AM, <elopez.i...@nym.hush.com> wrote:
>
> The observation that these are examples of permission falls more in line
> with RFC-4949's concept of a mechanism of access control, as compared to
> the ACL Model's traffic filtering definition.  As I've noted, I prefer the
> RFC-4949 definition, and see the ACL Model definition as referring to a
> specific implementation of ACL
>
>
>
> On 9/13/2016 at 3:23 AM, "John Strassner" <straz...@gmail.com> wrote:
>
> Hi Rakesh,
>
>
>
> I disagree. The three examples you cited are all examples of a permission
> to do something.
>
>
>
> regards,
>
> John
>
>
>
> On Mon, Sep 12, 2016 at 10:00 PM, Rakesh Kumar <rkku...@juniper.net>
> wrote:
>
> Hi Linda,
>
>
>
> As evident (https://en.wikipedia.org/wiki/Access_control_list), the ACL
> has different meaning to different folks (IT, Network). John rightly
> pointed out that originally it meant some kind of permission but networking
> industry adopted this to associate with packet filtering as you pointed out.
>
>
>
> History aside, the ACL have evolved dramatically over the years for
> various reasons:
>
> · Vendor want to give admin control over operational state of the
> networking device (override protocols or control plane)
>
> · SDN controller use ACL to configure operational state instead
> of running control plane
>
> · Feature (forwarding/Security/QoS/Monitoring)
> innovation/differentiations by vendors
>
>
>
> In my opinion, ACL can be lot more than filtering or permission (of course
> each vendor has different capability) but I am not sure what is our (I2NSF)
> specific goal behind this discussion.
>
>
>
> Do we just make sure that definition is same across all IETF work no
> matter how outdated?
>
> Do we want to make sure that it aligns with where the networking industry
> is?
>
> Do we want to make sure that it aligns with the security work we are doing
> in I2NSF?
>
>
>
> Thanks & Regards,
>
> Rakesh
>
>
>
>
>
> *From: *I2nsf <i2nsf-boun...@ietf.org> on behalf of John Strassner <
> straz...@gmail.com>
> *Date: *Monday, September 12, 2016 at 5:31 PM
> *To: *Linda Dunbar

Re: [I2nsf] Terminology discussion #2: "capability" & "capability interface"

[John Strassner]

Awesome, thanks Sue!

regards,
John

On Tue, Sep 13, 2016 at 11:29 AM, Susan Hares <sha...@ndzh.com> wrote:

> John:
>
>
>
> For discussion at the interim:
>
> +1 to John’s belief we agreed upon customer facing rather than client.
>
> +1 to John’s concept of specifying separate action that use/manipulate
> capabilities from monitoring functions.
>
>
>
> My comment is practical and design-based.
>
> Practical: The monitoring and telemetry information is undergoing
> substantial growth in the IETF standardization, and the industry. It is
> important to let the capabilities grow separately.
>
> Design based: These are orthogonal functions.  Why should we mix them?
>
>
>
> Sue
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *John
> Strassner
> *Sent:* Monday, September 12, 2016 8:48 PM
> *To:* Linda Dunbar; John Strassner
> *Cc:* i2nsf@ietf.org; Diego R. Lopez
> *Subject:* Re: [I2nsf] Terminology discussion #2: "capability" &
> "capability interface"
>
>
>
> Hi Linda,
>
>
>
>
>
> From the Terminology I-D:
>
>
>
> Client-Facing Interface:  See Consumer-Facing Interface.
>   See also:  Interface, NSF-Facing Interface.
>
>
>
> Consumer-Facing Interface:  An Interface dedicated to communication
>   with Consumers of NSF data and Services. This is typically
>   defined per I2NSF administrative domain.  See also: Interface,
>   NSF-Facing Interface.
>
>
>
>NSF-Facing Interface:  An Interface dedicated to communication with
>   a set of NSFs. This is typically defined per I2NSF administrative
>   domain. See also:  Interface, Consumer-Facing Interface.
>
>
>
> Therefore,
>
>
>
>1) I'll bring this up in tomorrow's telecom, but I was pretty sure we
> had
>
>previously decided to use **consumer**, not **client**
>
>2) The point of having a separate Capability Interface is to separate
>
> actions involving using and manipulating capabilities from other
>
> actions, such as monitoring. This is because capabilities are
>
> mechanisms that reflect all or part of the functionality of NSFs.
>
> As such, they are the building blocks for configuration and
>
> monitoring; this seemed to me to warrant a separate interface
>
> for security reasons.
>
>
>
> best regards,
>
> John
>
>
>
> On Mon, Sep 12, 2016 at 10:27 AM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
> As the I2NSF Terminology has defined two types of the “capability”:
>
> -the “capability” from NSFs and
>
> -the “capability” from controller (i.e. as the response to
> Client’s inquiry).
>
>
>
> I find it not necessary to have the “capability interface” as we already
> have Client Facing interface and NSF facing interface.
>
>
>
>Capability:  Defines a set of features that are available from a
>
>   managed entity (see also I2NSF Capability). Examples of "managed
>
>   entities" are NSFs and Controllers, where NSF Capabilities and
>
>   Controller Capabilities define functionality of an NSF and about
>
>   Controller, respectively. These functions may, but do not have
>
>   to, be used. All Capabilities are announced through the
>
>   Registration Interface.
>
>
>
> *Linda*
>
>
>
>
>
>
> --
>
> regards,
>
> John
>



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

Re: [I2nsf] Why do we have "negotiation" for the "Control Plane"

[John Strassner]

Hi Rakesh,

please see my reply. What Linda meant is that the Overlay and Underlay
Controllers would offer a set of capabilities, then offer alternatives, and
continue until they agree on a mutually acceptable set of capabilities.
This is simply a more specific version of my generic example.

However, when you write:."In my opinion, I2NSF defines the management plane
(controller interfaces) for NSF". this conflates two very different
concepts. Please see the definitions of each that are in the current
Terminology I-D.

regards,
John

On Mon, Sep 12, 2016 at 9:25 PM, Rakesh Kumar  wrote:

> Hi Linda,
>
>
>
> The example you mentioned below seem like a capability discovery and an
> appropriate action taken based on that.  A negotiation is different in my
> opinion, for example IPSEC peers negotiate hashing and encryption algorithm
> to establish a secured connection.
>
>
>
> Even before we go into this question, we have to clarify I2NSF control
> plane. In my opinion, I2NSF defines the management plane (controller
> interfaces) for NSF. The control plane and data plane of NSF should be out
> of scope for I2NSF (Look at draft https://datatracker.ietf.org/
> doc/draft-ietf-i2nsf-framework).
>
>
>
> The NSF control plane and data plane, is for each VNF/PNF vendor to define
> and as long as NSF provides I2NSF management interface (NSF-facing
> interface), it should be sufficient.
>
>
>
> Thanks & Regards,
>
> Rakesh
>
>
>
> *From: *Linda Dunbar 
> *Date: *Monday, September 12, 2016 at 12:59 PM
> *To: *Rakesh Kumar 
> *Cc: *"i2nsf@ietf.org" 
> *Subject: *Why do we have "negotiation" for the "Control Plane"
>
>
>
> Rakesh,
>
>
>
> Here is a use case to address your following  question: Cloud (Overlay)
> Network needs the underlay network to enforce Rule A & B  Not sure of
> the capability of the underlay network, the Overlay Network can send an
> inquiry to the underlay network asking if it supports Rule A  The
> underlay network may respond with “Only Rule A”. Then the Overlay network
> can only send “Rule A” to be enforced by the Underlay network.
>
>
>
>
>
> Control Plane:  In the context of I2NSF, the Control Plane is an
>
>   architectural Component that provides common control functions
>
>   to all I2NSF Components, including some or all of the following:
>
>   authentication, authorization, accounting, auditing, and
>
>   Capability discovery and negotiation.
>
>
>
> [Rakesh & Anil] Why do we have “negotiation” ? What are we trying to
> negotiate?
>
>
>
>
>
> *Cheers, *
>
> *Linda*
>
>
>
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>


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

Re: [I2nsf] Why do we have "negotiation" for the "Control Plane"

[John Strassner]

An even simpler and broader example is when two groups want to agree on a
particular function:

   - the function is a capability
   - negotiation is the process of agreeing to the final function used by
both groups

regards,
John

On Mon, Sep 12, 2016 at 12:59 PM, Linda Dunbar 
wrote:

> Rakesh,
>
>
>
> Here is a use case to address your following  question: Cloud (Overlay)
> Network needs the underlay network to enforce Rule A & B  Not sure of
> the capability of the underlay network, the Overlay Network can send an
> inquiry to the underlay network asking if it supports Rule A  The
> underlay network may respond with “Only Rule A”. Then the Overlay network
> can only send “Rule A” to be enforced by the Underlay network.
>
>
>
>
>
> Control Plane:  In the context of I2NSF, the Control Plane is an
>
>   architectural Component that provides common control functions
>
>   to all I2NSF Components, including some or all of the following:
>
>   authentication, authorization, accounting, auditing, and
>
>   Capability discovery and negotiation.
>
>
>
> [Rakesh & Anil] Why do we have “negotiation” ? What are we trying to
> negotiate?
>
>
>
>
>
> *Cheers, *
>
> *Linda*
>
>
>
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>


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

Re: [I2nsf] Terminology discussion #2: "capability" & "capability interface"

[John Strassner]

Hi Linda,


>From the Terminology I-D:

Client-Facing Interface:  See Consumer-Facing Interface.
  See also:  Interface, NSF-Facing Interface.

Consumer-Facing Interface:  An Interface dedicated to communication
  with Consumers of NSF data and Services. This is typically
  defined per I2NSF administrative domain.  See also: Interface,
  NSF-Facing Interface.

   NSF-Facing Interface:  An Interface dedicated to communication with
  a set of NSFs. This is typically defined per I2NSF administrative
  domain. See also:  Interface, Consumer-Facing Interface.

Therefore,

   1) I'll bring this up in tomorrow's telecom, but I was pretty sure we had
   previously decided to use **consumer**, not **client**
   2) The point of having a separate Capability Interface is to separate
actions involving using and manipulating capabilities from other
actions, such as monitoring. This is because capabilities are
mechanisms that reflect all or part of the functionality of NSFs.
As such, they are the building blocks for configuration and
monitoring; this seemed to me to warrant a separate interface
for security reasons.

best regards,
John

On Mon, Sep 12, 2016 at 10:27 AM, Linda Dunbar 
wrote:

> As the I2NSF Terminology has defined two types of the “capability”:
>
> -the “capability” from NSFs and
>
> -the “capability” from controller (i.e. as the response to
> Client’s inquiry).
>
>
>
> I find it not necessary to have the “capability interface” as we already
> have Client Facing interface and NSF facing interface.
>
>
>
>Capability:  Defines a set of features that are available from a
>
>   managed entity (see also I2NSF Capability). Examples of "managed
>
>   entities" are NSFs and Controllers, where NSF Capabilities and
>
>   Controller Capabilities define functionality of an NSF and about
>
>   Controller, respectively. These functions may, but do not have
>
>   to, be used. All Capabilities are announced through the
>
>   Registration Interface.
>
>
>
> *Linda*
>
>
>



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

Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model

[John Strassner]

Thanks Bob, completely agree.

Fundamentally, "filter" implies "remove" (at least in English). ACLs are
permissions. Removing something (or forwarding, or whatever) is simply an
action dictated by the permission.

regards,
John

On Mon, Sep 12, 2016 at 10:27 AM, Natale, Bob <rnat...@mitre.org> wrote:

> Hi Linda,
>
>
>
> It seems to me that the RFC4949 definition is more general and that
> ietf-netmod-acl-model defines one compatible specific variation. Some of
> the specifics of that definition might not apply in all cases.
>
>
>
> In fact, I am somewhat surprised that the latter document did not,
> evidently, reference RFC4949 … at least for a baseline definition. True,
> it’s a bit dated, but I think that mostly affects concepts and constructs
> introduced since its publication … the widespread use of ACLs predates
> RFC4949 by a lot.
>
>
>
> For reference, the fairly recent CNSSI 4009, *Committee on National
> Security Systems (CNSS) Glossary* (Apr 6, 2015) also uses a more general
> definition:
>
> access control list (ACL)
>
> A list of permissions associated with an object. The list specifies who or
> what is allowed to access the object and what operations are allowed to be
> performed on the object.
>
>
>
> Avanti,
>
> BobN
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *Linda Dunbar
> *Sent:* Monday, September 12, 2016 1:07 PM
> *To:* John Strassner <straz...@gmail.com>; Susan Hares <sha...@ndzh.com>;
> i2nsf@ietf.org
> *Subject:* [I2nsf] I2NSF Terminology's definition on "ACL" is different
> from ietf-netmod-acl-model
>
>
>
> John, et al,
>
>
>
> The “ietf-netmod-acl-model” has “ACL” defined as:
>
> An ACL is an ordered set of rules that is used to filter traffic on a
>
> networking device. Each rule is represented by an Access Control
>
> Entry (ACE).
>
>
>
> The “draft-ietf-i2nsf-terminology-01” has ACL as:
>
>
>
> ACL (Acess Control List):  This is a mechanism that implements
>
>   access control for a system resource by enumerating the system
>
>   entities that are permitted to access the resource and stating,
>
>   either implicitly or explicitly, the access modes granted to each
>
>   entity [RFC4949]. A YANG description is defined in
>
>   [I-D.ietf-netmod-acl-model].
>
>
>
>
>
>
>
> Can we make I2NSF’s ACL definition consistent with the
> ““ietf-netmod-acl-model”?
>
>
>
> Thanks,
>
> Linda
>



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

Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model

[John Strassner]

Hi Linda,

My vote is NO.

With all due respect, RFC4949 predates the acl model by almost 7 years.
Furthermore, ACLs may or may not **filter** traffic. The roots of ACLs go
much farther back (at least to 1997 that I can find) and, fundamentally,
are permissions. A permission is not the same as filtering. Finally, we
would then have to define ACEs, and not all ACL models have ACEs.

regards,
John

On Mon, Sep 12, 2016 at 10:06 AM, Linda Dunbar 
wrote:

> John, et al,
>
>
>
> The “ietf-netmod-acl-model” has “ACL” defined as:
>
> An ACL is an ordered set of rules that is used to filter traffic on a
>
> networking device. Each rule is represented by an Access Control
>
> Entry (ACE).
>
>
>
> The “draft-ietf-i2nsf-terminology-01” has ACL as:
>
>
>
> ACL (Acess Control List):  This is a mechanism that implements
>
>   access control for a system resource by enumerating the system
>
>   entities that are permitted to access the resource and stating,
>
>   either implicitly or explicitly, the access modes granted to each
>
>   entity [RFC4949]. A YANG description is defined in
>
>   [I-D.ietf-netmod-acl-model].
>
>
>
>
>
>
>
> Can we make I2NSF’s ACL definition consistent with the
> ““ietf-netmod-acl-model”?
>
>
>
> Thanks,
>
> Linda
>



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

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

[John Strassner]

Hi Rakesh,

please see inline...

regards,
John

From: Rakesh Kumar [mailto:rkku...@juniper.net]
Sent: Friday, July 08, 2016 11:57 AM
To: Xialiang (Frank); Diego R. Lopez; John Strassner
Cc: Natale, Bob; Susan Hares; John Strassner; i2nsf@ietf.org; Dacheng Zhang; 
Linda Dunbar; Rakesh Kumar
Subject: Re: [I2nsf] questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

Hi Frank,

Thanks for the comments.

IMHO, it would be great if our terminology

  1.  Align well with other work in the industry (I am pretty sure there are 
other service orchestration system/controller in the standard bodies  and open 
source).

What does a security terminology draft have to do with orchestration? While 
there might be some overlap
in some terms, many orchestration systems do not consider security at the level 
of detail that we need.
We have already identified terminology that we do not want to reuse (e.g., 
"northbound" and "southbound").
Finally, I personally think that it would be better to align with other 
security WGs in the IETF (e.g., sacm)
and THEN expand to outside of IETF security WGs.
If you disagree, it would be helpful for you to send a specific example of 
terminology from another SDO or
other open source project that you are worried about.

  2.  Communicates clearly the intention of these interface  on  terminology we 
choose.

This implies that the definition of these terms is incorrect. Please review the 
latest draft (-01) and
provide concrete suggestions to fix.

  3.  The end-customer/consumer find these interfaces intuitive. The 
end-customer could be

 *   An uber-controller that uses I2NSF defined security controller to 
provision security policies
 *   A GUI system used by admin to provision security policies
 *   OSS/BSS system from service provider
 *   Thirty party APP written on top of I2NSF controller

Or an end-user. However, my point is that the terminology document will not 
define interfaces;
it will only provide documentation on terms that interfaces use. Is there a 
specific point here
for the terminology document to address?


It would be great to discuss various options discussed so far in this group and 
see which ones are the most appropriate.

Once we agree on top level, it would be great to create 
classification/categories for these interfaces on either side of the controller 
so that  our work/drafts communicate clearly, the specific area[s] targeted.

I just sent this classification to start a wider discussion. I  look towards 
the group and help from chairs to see how to carry it forward and whether to 
fold this into existing draft or not.

It would be great if we bring this up in Berlin.

Thanks & Regards,
Rakesh

From: "Xialiang (Frank)" 
<frank.xiali...@huawei.com<mailto:frank.xiali...@huawei.com>>
Date: Sunday, July 3, 2016 at 7:39 PM
To: "Diego R. Lopez" 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>, John 
Strassner <john.sc.strass...@huawei.com<mailto:john.sc.strass...@huawei.com>>
Cc: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>, "Natale, 
Bob" <rnat...@mitre.org<mailto:rnat...@mitre.org>>, Susan Hares 
<sha...@ndzh.com<mailto:sha...@ndzh.com>>, John Strassner 
<straz...@gmail.com<mailto:straz...@gmail.com>>, 
"i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>, Dacheng Zhang 
<dacheng@alibaba-inc.com<mailto:dacheng@alibaba-inc.com>>, Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Subject: Re: [I2nsf] questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

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

Thanks!

B.R.
Frank

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

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

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

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

[John Strassner]

I will try and help Jianjie update the UAGP draft.
Diego, I'm happy to help with your attestation draft if you need it.

best regards,
John

On Thu, Jun 23, 2016 at 1:33 PM, Diego R. Lopez <
diego.r.lo...@telefonica.com> wrote:

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


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

Re: [I2nsf] Should we call "South Bound Interface" for the interface between "controller <-> NSF", and "North Bound Interface" for the interface between "Client <-> controller"?

[John Strassner]

Hi,

I think it is better to have crisp and clear terminology, and make the
changes now, rather than wait and end up with ambiguous or confusing
documents.

While your clarifications are helpful, I don't think that they address my
concerns, and they definitely don't address Diego's concerns (which I
wholeheartedly agree with). Furthermore, I don't see what absolute
coordinates (north vs. south) really buys you. What if you have stacked
controllers (e.g., a controller that is managing multiple controllers)?
Finally, what if you don't have a controller, but some other entity?

best regards,
John

On Sun, Jun 26, 2016 at 3:41 AM, Loa Andersson <l...@pi.nu> wrote:

> Folks,
>
> I think this comment would have been fine, and I guess I supported it if
> it would have been here two years ago. As it is now I think there are to
> much water under the bridges, and actually to many documents involved.
> We have a common usage of "North Bound" or "Northbound" and South Bound"
> or Southbound". The pain in changing is much greater than the gain.
>
> However, I would support adding text to the terminology section like
> this:
>
> North Bound Interface - the interface between the client and the
> controller
>
> South Bound Interface - the interface between the controller and the NSF
>
> /Loa
>
> On 2016-06-26 04:02, John Strassner wrote:
>
>> Hi Linda,
>>
>> 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. 
>>
>> 
>> The term "capability interface" doesn't bother me. However, I don't
>> think that we are using it to its full potential - see below.
>>
>> The term "client interface" does bother me, because
>> 1) to me, it implies a client-server architecture (or a 3-tier
>> architecture on a stretch), and I don't understand why we should be
>> limited to that
>> 2) what is the client? To me, a client is a host. Aren't we talking
>> about the application here? The examples in your figure are arguably
>> SERVERS,
>> not CLIENTS. :-)
>> >
>> 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". 
>>
>> 
>> Warning, this is probably just me, but...
>>
>> ...I do NOT like "layers", because abstractions should work for
>> everything, not just sometimes. Look at our "layers" - we repeatedly
>> violate the true notion of a layer (e.g., MPLS). Look at all of the
>> "inter-layer" compatibility problems we've had over the years. Why do we
>> need to use layers in I2NSF? I would strongly argue to use "interface";
>> if that is not acceptable, then choose a different term (e.g., planes)
>> that does not have the traditional limitations of layers.
>> 
>>
>> 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.
>>
>> 
>> Sorry, I disagree.
>>
>> Events, conditions, and actions are NOT capabilities. Capabilities are
>> defined in the Capabilities Draft as:
>>
>> Capabilities are functions that NSFs can perform. This interface
>> is used to advertise, select, and activate capabilities of selected
>> NSFs in a vendor-independent manner.
>>
>> Put another way, Capabilities are used to define functions that MAY be
>> used. There is no guarantee that they will be actually used.
>> Furthermore, Events, Conditions, and Actions are used to construct an
>> ECA policy rule. Events, Conditions, and Actions are types of Boolean
>> statements (at least in ECA rules) and have nothing to do with
>> Capabilities.
>>
>> While you MAY be able to relate a rule to Capabilities, they are two
>> completely separate things.
>> 
>>
>> Therefore, continue using the  “Capability Interface” can cause more
>> confusion in the future as its

Re: [I2nsf] Should we call "South Bound Interface" for the interface between "controller <-> NSF", and "North Bound Interface" for the interface between "Client <-> controller"?

[John Strassner]

Hi Linda,

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.


The term "capability interface" doesn't bother me. However, I don't think
that we are using it to its full potential - see below.

The term "client interface" does bother me, because
1) to me, it implies a client-server architecture (or a 3-tier
architecture on a stretch), and I don't understand why we should be limited
to that
2) what is the client? To me, a client is a host. Aren't we talking
about the application here? The examples in your figure are arguably
SERVERS,
not CLIENTS. :-)

Warning, this is probably just me, but...

...I do NOT like "layers", because abstractions should work for everything,
not just sometimes. Look at our "layers" - we repeatedly violate the true
notion of a layer (e.g., MPLS). Look at all of the "inter-layer"
compatibility problems we've had over the years. Why do we need to use
layers in I2NSF? I would strongly argue to use "interface"; if that is not
acceptable, then choose a different term (e.g., planes) that does not have
the traditional limitations of layers.


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.


Sorry, I disagree.

Events, conditions, and actions are NOT capabilities. Capabilities are
defined in the Capabilities Draft as:

Capabilities are functions that NSFs can perform. This interface
is used to advertise, select, and activate capabilities of selected
NSFs in a vendor-independent manner.

Put another way, Capabilities are used to define functions that MAY be
used. There is no guarantee that they will be actually used. Furthermore,
Events, Conditions, and Actions are used to construct an ECA policy rule.
Events, Conditions, and Actions are types of Boolean statements (at least
in ECA rules) and have nothing to do with Capabilities.

While you MAY be able to relate a rule to Capabilities, they are two
completely separate things.


Therefore, continue using the  “Capability Interface” can cause more
confusion in the future as its sound is too close to the “Capability
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 
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 |
>
>   |  

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

[John Strassner]

Hi Rajasekhar,

the Capability Interface is used to announce the set of functions that are
available. We haven't specified further details yet, though I assume that
such functions would be limited to a common administrative domain. In that
sense, Firewall, Anti-Virus, IDP, and others would be available.

However, I do not think that the Capability Interface should be overloaded
and turned into a programming interface. Precedence exists in, for example,
OMA and other systems, where there are separate capability and programming
interfaces. We should do the same in I2NSF.

best regards,
John

On Mon, Jun 20, 2016 at 10:58 PM, Ganduri, Rajasekhar <
rajasekhargand...@my.unt.edu> wrote:

> Hi John,
>
>
> Thanks for the note about the capability layer. I understand your point
> and I feel that abstraction may be more precise than abstraction layer. In
> your second definition of "Capability Layer", what can be the "set of
> features available to the Controller", for eg., in IDS or Firewall. I
> visualized the capability interface as the commanding interface which gives
> a set of instructions to the NSFs on what to do and receives feedback from
> the NSFs once the set of instructions are implemented.
>
>
> Regards,
>
> Rajasekhar
> --
> *From:* John Strassner <straz...@gmail.com>
> *Sent:* Sunday, June 19, 2016 10:17:42 PM
> *To:* Ganduri, Rajasekhar
> *Cc:* Linda Dunbar; I2NSF@ietf.org; DIEGO LOPEZ GARCIA (
> diego.r.lo...@telefonica.com); Susan Hares
> *Subject:* Re: [I2nsf] questions about some terminologies defined by
> draft-ietf-i2nsf-terminology-00
>
> Hi Rajasekhar,
>
> please see my last reply to Linda.
>
> For me, I don't think that an abstraction **layer** makes sense. A layer
> should be used to abstract a common set of functionality - otherwise, you
> have a set of abstractions of different functions that mean different
> things.
>
> best regards,
> John
>
>
>
> On Sat, Jun 18, 2016 at 12:07 AM, Ganduri, Rajasekhar <
> rajasekhargand...@my.unt.edu> wrote:
>
>> Hey,
>>
>>
>> I am a novice in I2NSF IETF group and its capabilities but I am a regular
>> follower of the current activities of I2NSF. According to my understanding,
>> the term "abstraction layer" is used to specify that the end user/client
>> need not have the complete visibility of the working or implementation of
>> how the I2NSF controller communicates with the NSFs. This is what
>> interested me in I2NSF, as this opens up to a new set of end users who need
>> not have complete understanding of how a network operates. I implemented
>> this in my research, where a web application tool is built that can be used
>> by "any" end user to give simple natural language inputs through Interface1
>> (Service Layer) to the controller (or Openstack Cloud controller in my
>> case) and the controller translates and transfers the security commands to
>> the IDS and firewalls through Interface2(Capability layer). The way in
>> which the controller transfers to the NSFs is hidden from the end user (or
>> the end user need not know, details being hidden or abstracted) but the end
>> user will have the authority over Interface2 in his/her own network.
>>
>> Please let me know if I understood wrongly.
>>
>> Thanks  and Regards,
>>
>> Rajasekhar
>>
>>
>> --
>> *From:* Linda Dunbar <linda.dun...@huawei.com>
>> *Sent:* Friday, June 17, 2016 4:10 AM
>> *To:* John Strassner
>> *Cc:* I2NSF@ietf.org; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com);
>> Susan Hares
>> *Subject:* Re: [I2nsf] questions about some terminologies defined by
>> draft-ietf-i2nsf-terminology-00
>>
>>
>> John,
>>
>>
>>
>> My thinking maybe too simplistic.
>>
>> I picture a “Controller” having two ports,
>>
>> -one port connecting to clients (which can be another domain
>> controller or Overlay network controller), interface from this port is
>> “Service layer interface”
>>
>> -another port connecting to NSFs, the interface from this port
>> is “capability layer interface”.
>>
>>
>>
>> So I thought that the Service Layer interface is the North Bound
>> interface to the Controller, the capability interface is the south bound to
>> the controller.
>>
>>
>>
>> What extra meaning does it carry with the wording “abstraction Layer” ?
>>
>> *Capability Layer: Defines an abstraction layer that exposes a set of
>> {features that are available from a managed entity} of the I

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

[John Strassner]

Hi Linda,

these are two different questions:

> My thinking maybe too simplistic.

> I picture a “Controller” having two ports,

>  one port connecting to clients ..., interface from this port is “Service
layer interface”

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


I think this could be a bit ambiguous.

When I think of "southbound interface", I think of a programming interface.
The Capability Layer Interface is not a pure programming interface; rather,
it is an interface that advertises the set of functions available. It does
not define how to program those functions.

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

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

Here is the text of the last note; Diego and Dacheng liked the second of my
proposed definitions.


On 16 Jun 2016, at 15:05 , John Strassner <straz...@gmail.com> wrote:

Hi Dacheng,

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

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

or

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


On Fri, Jun 17, 2016 at 6:10 PM, Linda Dunbar <linda.dun...@huawei.com>
wrote:

> John,
>
>
>
> My thinking maybe too simplistic.
>
> I picture a “Controller” having two ports,
>
> -one port connecting to clients (which can be another domain
> controller or Overlay network controller), interface from this port is
> “Service layer interface”
>
> -another port connecting to NSFs, the interface from this port is
> “capability layer interface”.
>
>
>
> So I thought that the Service Layer interface is the North Bound interface
> to the Controller, the capability interface is the south bound to the
> controller.
>
>
>
> What extra meaning does it carry with the wording “abstraction Layer” ?
>
> *Capability Layer: Defines an abstraction layer that exposes a set of
> {features that are available from a managed entity} of the I2NSF system.*
>
> Thank you.
>
>
>
> Linda
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Thursday, June 16, 2016 12:58 AM
> *To:* Linda Dunbar; John Strassner
> *Cc:* Susan Hares; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com);
> I2NSF@ietf.org
> *Subject:* Re: questions about some terminologies defined by
> draft-ietf-i2nsf-terminology-00
>
>
>
> HI Linda,
>
>
>
> I don't see the conflict in the two definitions. If I substitute the first
> (within braces) into the second, I get:
>
>
>
> *Capability Layer: Defines an abstraction layer that exposes a set of
> {features that are available from a managed entity} of the I2NSF system.*
>
>
>
> When I look at the Charter's Capability Layer, I think we're still OK -
> the Charter "...specifies how to control and monitor NSFs at a functional
> level...", and Capabilities (the features that are available) are essential
> for planning how to control and monitor NSFs.
>
>
>
> Features (i.e., capabilities) are independent of interface (northbound or
> southbound). Would you like us to add that point to the terminology I-D?
>
>
>
> best regards,
>
> John
>
>
>
>
>
> On Wed, Jun 15, 2016 at 8:40 AM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
> Dear Authors:
>
>
>
> The term “Capability Layer” defined by the
> “draft-ietf-i2nsf-terminology-00” carries different  meaning than the
> “Capability Layer” used by the I2NSF charter.
>
>
>
> “draft-ietf-i2nsf-terminology-00”:
>
> *Capability: Defines a set of features that are available from a managed
> entity (see also I2NSF Capability).*
>
>
>
> *Capability Layer: Defines an abstraction layer that exposes a set of
> capabilities of the I2NSF system.*
>
>
>
> I2NSF Charter:
>
> *I2NSF will specify interfaces at two functional levels for the control
> and monitoring of network security functions:*
>
>
>
> *The I2NSF Capability Layer specifies how to control and monitor NSFs at a
> functional implementation level. The term "Functional Implementation" is
> us