I have something that might delay WGLC, but found out an optimization which
would help in the future
In ietf-packet-fields.yang, example below
grouping acl-ipv4-header-fields {
description
"Fields in IPv4 header.";
leaf destination-ipv4-network {
type inet:ipv4-prefix;
description
"Destination IPv4 address prefix.";
}
leaf source-ipv4-network {
type inet:ipv4-prefix;
description
"Source IPv4 address prefix.";
}
}
Instead of using "leaf" for "destination-ipv4-network" and
"source-ipv4-network", "leaf-list" reduces the number of terms/ace needed.
If we would agree with this change, then would propose one more
for mac-addresses, having the mask under the address itself look better in the
data itself:
<destination-mac-address>
<address>01:01:01:00:00:00</address>
<mask>ff:ff:ff:00:00:00</mask>
</destination-mac-address>
Or create a new type 'mac-address-prefix'.
This allows having matching multiple destinations to 1 source, or multiple
sources to 1 destination, if they cannot be easily combined into 1 entry.
<destination-mac-address>
<address>01:01:01:00:00:00</address>
<mask>ff:ff:ff:00:00:00</mask>
</destination-mac-address>
<destination-mac-address>
<address>01:04:01:00:00:00</address>
<mask>ff:ff:ff:00:00:00</mask>
</destination-mac-address>
<source-mac-address>
....
</source-mac-address>
> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic <ivand...@gmail.com> wrote:
>
> Kent,
>
> Thank you for the answer
>> On Nov 13, 2016, at 1:20 PM, Kent Watsen <kwat...@juniper.net
>> <mailto:kwat...@juniper.net>> wrote:
>>
>> Hi Dean,
>>
>> > Don’t understand your question. What is the difference between system and
>> > user generated acls?
>>
>> User-generated would be, for instance, configured via NETCONF or RESTCONF,
>> whereas system-generated would be ACLs that get created by default. For
>> example, RFC 7223 has the top-level /interfaces-state to support
>> system-generated interfaces (e.g., lo) so, when running `shows interfaces`,
>> the result includes both configured and system-generated interfaces. Makes
>> sense?
>
> I understand now what you meant. Where I can see for the interfaces the use
> case you describe (for loopback and physical interfaces), for ACLs have much
> harder time to find an example use case where a system would generate an ACL.
> Maybe for a highly secure system would generate an ACL to deny all traffic to
> and from, except to access it via console when it comes up. Can you come with
> some other use cases? If we can find viable use cases, then yes, would say
> that reporting opstate for system generated ACLs is useful.
>
> Dean
>
>>
>> Thanks,
>> Kent
>>
>> From: Dean Bogdanovic <ivand...@gmail.com <mailto:ivand...@gmail.com>>
>> Date: Friday, November 11, 2016 at 3:45 PM
>> To: Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>
>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
>> <mailto:netmod@ietf.org>>
>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until
>> Oct 27, 2016)
>>
>>
>>> On Oct 29, 2016, at 4:01 AM, Kent Watsen <kwat...@juniper.net
>>> <mailto:kwat...@juniper.net>> wrote:
>>>
>>> The last call period for this draft has ended. Thank you to all that
>>> responded. Given the responses received, my co-chair and I believe that
>>> the draft is ready to move forward. I will begin the shepherd write-up
>>> shortly.
>>> In parallel, prompted by a conversation I had this morning, I’m wondering
>>> about the YANG module’s use of the config false nodes ‘acl-oper-data’ and
>>> ‘ace-oper-data’. In particular, are the lifetimes of these nodes always
>>> the same as the configured nodes?
>>
>> Yes, they are. When the nodes are created, they are don’t have to be
>> attached to an another object, like interface or RIB, etc, but they get
>> operational state. Once attached, (to continue with the example) operational
>> status of counters is changing. When detached from the interface, the last
>> know counter is kept, until the ace is deleted. Same is for acl-oper-data.
>>
>>> - is there any need to support reporting opstate for system-generated acts?
>>
>> Don’t understand your question. What is the difference between system and
>> user generated acls?
>>
>> Dean
>>
>>>
>>> Thanks,
>>> Kent (as shepherd)
>>>
>>>
>>> From: netmod <netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org>> on
>>> behalf of Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>
>>> Date: Thursday, October 13, 2016 at 5:05 PM
>>> To: "netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
>>> <mailto:netmod@ietf.org>>
>>> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until
>>> Oct 27, 2016)
>>>
>>>
>>> This is a notice to start a two-week NETMOD WG last call for the document:
>>>
>>> Network Access Control List (ACL) YANG Data Model
>>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09
>>> <https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09>
>>>
>>> Please indicate your support or concerns by Thursday, October 27, 2016.
>>>
>>> We are particularly interested in statements of the form:
>>> * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>>> * I have reviewed draft-ietf-netmod-acl-model-09 and found the following
>>> issues: ...
>>>
>>> As well as:
>>> * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>>> * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>>> * I am considering to implement the data model in
>>> draft-ietf-netmod-acl-model-09.
>>> * I am not considering to implement the data model in
>>> draft-ietf-netmod-acl-model-09.
>>>
>>> Thank you,
>>> NETMOD WG Chairs
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
