Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

All, This last call is now closed. Since the comments were minor, this last call is considered successful. Authors, Please address any/all comments received during the LC. Once you've published the version that you believe addresses all comments/pending changes, I'll perform

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

All, This last call is now closed. Since the comments were minor, this last call is considered successful. Authors, Please address any/all comments received during the LC. Once you've published the version that you believe addresses all comments/pending changes, I'll perform

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

Tom, If we were to introduce this, yes, that (or some similar term) may help clarify. But I think that at the moment we have suggested that we leave this issue out of the initial draft until it is better understood what we should specify. I think the question at this point is whether explicit

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

Maybe it would help to say “to all interfaces” instead of “globally”? —Tom > On Dec 13, 2017, at 4:15 PM, Einar Nilsen-Nygaard (einarnn) > wrote: > > I’m not sure we have a clear enough common understanding of “global” as yet > to be able to say that we

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

I’m not sure we have a clear enough common understanding of “global” as yet to be able to say that we should make the provisioning of an ACL on an interface or “globally” mutually exclusive in the model. I think attaching an ACL to a specific interface in either the ingress or egress direction

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

You can use the same ACL definition to attach to different points in the system, provided they do not overlap. Otherwise, you are just wasting CAM entries. Global and interface attachment points will overlap with each other, because global means ‘any’ interface. > On Dec 13, 2017, at 12:40 PM,

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

We need to be able to attach any one ACL to a whole range of different places. Just speaking from the Cisco platform perspective, I may attach an ACL to: * Interfaces * NAT configuration * Class maps for QoS policy * Class maps for FW policy * …etc… Not sure if we have any

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

My understanding is that you would attach an ACL either to an interface or globally. Not both. > On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) > wrote: > > I’m happy to have a way to attach an ACL globally, but that’s orthogonal to > attaching to an

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

I’m happy to have a way to attach an ACL globally, but that’s orthogonal to attaching to an interface, isn’t it? Attaching ACLs directly to an interface doesn’t preclude global attachment in any way as far as I can see…or have I missed something? I’m not sure I understand why choices are an

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

We want to support “global” attachment point down the line, and that “global” attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node. > On Dec 13, 2017, at 6:57 AM, Einar

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

On 12/13/2017 04:26 PM, Vladimir Vassilev wrote: Hi, On 12/13/2017 03:47 PM, Martin Bjorklund wrote: Hi, Thanks for reporting this.  I'll add the missing origin.  But why did you think forwarding and mtu should be removed? 1. IMO since is not present in the container in the Appendix A ()

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

Hi, On 12/13/2017 03:47 PM, Martin Bjorklund wrote: Hi, Thanks for reporting this. I'll add the missing origin. But why did you think forwarding and mtu should be removed? 1. IMO since is not present in the container in the Appendix A () example and does not have default value in the

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

I like this because ACLs will be used in many different ways, and expecting that a single model be augmented for each attachment seems a bit unrealistic. Eliot On 12/13/17 3:57 PM, Einar Nilsen-Nygaard (einarnn) wrote: > Perhaps like this, as an augmentation to the interface: > >   augment

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

Perhaps like this, as an augmentation to the interface: augment /if:interfaces/if:interface: +--rw ingress-acls | +--rw acl-sets | +--rw acl-set* [name] |+--rw name -> /access-lists/acl/name |+--rw type? -> /access-lists/acl/type

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

On 11/12/2017 20:55, Andy Bierman wrote: On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton > wrote: Hi, On 08/12/2017 18:01, Andy Bierman wrote: Hi, A library per datastore sounds too complicated. I prefer the proposal that

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

Hi, Thanks for reporting this. I'll add the missing origin. But why did you think forwarding and mtu should be removed? In fact, I think I missed , so here's my diff: --- ex-get-data-reply.xml +++ ex-get-data-reply.xml @@ -13,6 +13,7 @@ + true false

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

On 12/13/2017 08:40 AM, Martin Bjorklund wrote: Vladimir Vassilev wrote: On 12/12/2017 08:20 PM, Martin Bjorklund wrote: Hi, Vladimir Vassilev wrote: On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: On Fri, Dec 08, 2017 at

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

On Wed, Dec 13, 2017 at 08:50:33AM +0100, Vladimir Vassilev wrote: > > At the current point I think all issues raised are addressed with the > following model (notice the added anydata option which can replace the use > of yang-library-datastore and if implemented as an alternative can make >