Subject: [OPSAWG] MUD draft 13 nit : Scope of ACL Name

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 26 Oct 2017 13:12:07 -0400

leaf acl-name {
             type leafref {
               path "/acl:access-lists/acl:acl/acl:acl-name";
             }
             description
               "The name of the ACL for this entry.";
           }
           leaf acl-type {
             type identityref {
               base acl:acl-base;
             }
             description
               "The type of the ACL for this entry.  The name is
                scoped ONLY to the MUD file, and may not be unique
                in any other circumstance.";
           }

This is a nit (perhaps has already been reported):

Does the description comment on scope belong with the acl-name node?

Thanks

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Oct 2017 19:14:38 +0200

The acl name comes directly from draft-ietf-netmod-acl.  However, if it
is not clear, the scope is intended to be solely within a MUD file
itself.  I can add words to that effect as part of LC if nobody objects.

Eliot

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

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 26 Oct 2017 13:26:04 -0400

On Thu, Oct 26, 2017 at 1:14 PM, Eliot Lear <[email-masked]> wrote:

> The acl name comes directly from draft-ietf-netmod-acl.  However, if it is
> not clear, the scope is intended to be solely within a MUD file itself.  I
> can add words to that effect as part of LC if nobody objects.
>
> Eliot
>

Hi Eliot:

I had mean to suggest the following change:

       leaf acl-name {
             type leafref {
               path "/acl:access-lists/acl:acl/acl:acl-name";
             }
             description
               "The name of the ACL for this entry.The name is
                scoped ONLY to the MUD file, and may not be unique
                in any other circumstance.";
            }
            leaf acl-type {
             type identityref {
               base acl:acl-base;
             }
             description
               "The type of the ACL for this entry.  ";
           }

However, I have a suggested change to the naming scheme :

I would like to suggest that an ACL name be directly derived from a a
MUD URL instead of scoping it this way (so that it can be specified
independently of the MUD file while achieving the scoping goal you had
in mind).

That would ease the pain of implementation.

Can you make this a requirement?

Thanks,

Ranga.

> OPSAWG mailing [email-masked]://www.ietf.org/mailman/listinfo/opsawg
>
>
>

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Oct 2017 20:18:31 +0200

On 10/26/17 7:26 PM, M. Ranganathan wrote:
>
> I would like to suggest that an ACL name be directly derived from a a MUD URL instead of scoping it this way (so that it can be specified independently of the MUD file while achieving the scoping goal you had in mind).
>

That's a reference to an object outside of our model.   I think I could
write those words, but to be safe, your code should still bind the
scoping to that file.  And so I'm not sure of the point.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 26 Oct 2017 16:07:55 -0400

On Thu, Oct 26, 2017 at 2:18 PM, Eliot Lear <[email-masked]> wrote:

> write those words, but to be safe, your code should still bind the scoping
> to that file.  And so I'm not sure of the point.
>

I would suggest something a little more drastic - i.e. remove the notion of
scoping by file and tie the ACL names to a MUD file using a unique ACL
names (that could be derived from the MUD URL for example).

The ACLs can be changed independently of the MUD files (except for the ACL
names) that way. That would be the utility.

-- 
M. Ranganathan

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 26 Oct 2017 21:50:20 +0000

Ranga,

The description of scoping on the ACL name is really just to warn implementors (primarily those consuming the MUD file) that they cannot just assume that the name (ANY name) used in the MUD file would be guaranteed to be unique if just lifted and used to provision the ACL to a netconf server that may have ACLs provisioned from other sources. Further, the “acl-name” is constrained to be a string of maximum length 64 octets, which probably means that deriving from a MUD URL would be impractical.

Thus any attempt to do anything other than accept that the acl-names used must be unique in the scope of the MUD file they are defined in, but must be examined for uniqueness prior to provisioning to a NETCONF server, is probably not practical.

Anyway, I suspect that ACLs from MUD files will rarely be provisioned directly to devices. Most likely they will be processed by the "MUD controller” and combined with other policies defined by network administrators. IOW, MUD files will almost definitely not be the only source of access policy.

Cheers,

Einar

On 26 Oct 2017, at 21:07, M. Ranganathan <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Oct 26, 2017 at 2:18 PM, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

That's a reference to an object outside of our model.   I think I could write those words, but to be safe, your code should still bind the scoping to that file.  And so I'm not sure of the point.

I would suggest something a little more drastic - i.e. remove the notion of scoping by file and tie the ACL names to a MUD file using a unique ACL names (that could be derived from the MUD URL for example).

The ACLs can be changed independently of the MUD files (except for the ACL names) that way. That would be the utility.

Eliot

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