Subject: [OPSAWG] MUD draft 13: ietf-acldns suggested augmentation.

From: "M. Ranganathan" <[email-masked]>
Date: Sun, 29 Oct 2017 12:22:00 -0400

The MUD draft says ACL names should be scoped by file.

The following augmentation to ietf-acldns would make the association
explicit :

51a52,61
>   augment "/acl:access-lists/acl:acl/" {
>     description
>          "MUD URI to associate the  ACL to a MUD scope";
>     leaf mud-url {
>         type inet:uri;
>         description
>            "The MUD URI to associate with this ACL";
>     }
>   }
>

Thereby, scoping by file would be avoided.

Thanks,

Ranga

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Sun, 29 Oct 2017 17:34:31 +0100

I'm not sure that does what you want it to do, Ranga.  All it does is
add an information element that is actually already present within the
MUD model.  But you can do that in your own implementation, and no harm
will come of it.

Eliot

On 10/29/17 5:22 PM, M. Ranganathan wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Sun, 29 Oct 2017 23:04:59 +0000

I don’t think you can do anything in your own implementation that is useful as to be useful it would need to be something manufacturers also placed in MUD files. And such a leaf would have no relevance in the implementation of the ACL. In fact, at this point I can’t see any utility for it at all.

The MUD file is intended to be a self-contained parcel of information, and, as I said before, the note about the scoping of the ACL names is purely to remind consumers that the names of ACLs are defined only within the scope of the MUD file and there is no automatic disambiguation with respect to the other ACLs the network admin may also be working with. The MUD file will always be pre-processed before any ACLs are placed on a device, and the ACLs in the MUS file may not even manifest as standalone ACLs. They may just become a stanza in an already-existing ACL, or they may become filter rules in a RADIUS Access-Accept packet!

As such, anything we do to try and make these names globally unique just, IMO, adds unnecessary complexity to the overall model.

I suggest we take the “scoping” text out of the YANG definition, and add some text alluding to what I say above to the body of the document.

Cheers,

Einar

On Oct 29, 2017, at 16:34, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

I'm not sure that does what you want it to do, Ranga.  All it does is add an information element that is actually already present within the MUD model.  But you can do that in your own implementation, and no harm will come of it.

Eliot

The following augmentation to ietf-acldns would make the association explicit :

51a52,61

Thanks,

Ranga

--
M. Ranganathan

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg