Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04
Yes, I support this draft, and thank the authors for their effort! Cheers!Ed Lopez On 1/26/2018 at 6: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
Re: [I2nsf] Call for WG adoption of draft-kumar-i2nsf-client-facing-interface-req
I am good with the framework, but I have reservations on the functional and operational requirements. I'm good to adopt this as a WG document, in the intent that we need to focus our effort on this, but I'm not comfortable with the content in its current state - Ed On 9/21/2016 at 1:55 PM, "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
Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model
One of the difficulties in defining an ACL is actually in how an ACL works. The RFC 4949 definition describes a 'mechanism' where ietf-netmod-acl-model describe a functional 'ordered set'. In other words, RFC 4949 does not say how a list is processed, where ietf-netmod-acl-model implies a serial processing, although not how the list is ordered or how a resulting match is attained. It seems like splitting hairs but I would argue that the ietf-netmod-acl-model definition is a subset of the RFC 4949 one. So which one we use determines a scope of outcome. I think the real implied question here is if the focus of our work is biased or limited towards YANG models, and by implication NETCONF as a management protocol? Adopting the ietf-netmod-acl-model definition clearly means yes. I do not believe that RFC 4949 is planned to be superseded, and I agree with BobN in this case that the RFC 4949 definition is the broader one Cheers!Ed Lopez On 9/12/2016 at 1:27 PM, "Bob Natale" 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 ; Susan Hares ; 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___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
