Hi Tianran,
I think this is a timely piece of work that should be adopted. I commit
to further reviews if it is adopted.
A few minor comments on this version, below. Nothing that needs to be
fixed before adoption.
There is a meta-question: should the schedule model be moved out into
a separate document? It isn't necessary at this point in time (we can
continue to work on everything in one document), but given the intended
wider applicability it might be convenient to hold it in a separate
document.
Cheers,
Adrian
===
It would be good if the document title indicated (as the Abstract does)
what the document contains. Something like...
Management Tools for Policy-based Access Control
---
The abbreviation "UCL" is fine, but I don't like the expansion you give
in Section 2
* User group based ACL (UCL): A YANG data model for policy-based
network access control that specifies an extension to the IETF
ACL model defined in [RFC8519].
1. It is weird to say that the UCL is a YANG model (when the ACL is
clearly not a YANG model in its own right).
2. It is hard to make "User group based ACL" into UCL.
3. I am currently going through pain with the IESG objecting to calling
something "the IETF foo" because "what if another one comes along?"
How about...
* User group based Control List (UCL) model: A YANG data model for
policy-based network access control that specifies an extension
to the ACL YANG model defined in [RFC8519].
---
I think you might move the definition of NACL to Section 2 (especially
given the name of the document and its short title.
---
In section 2, the definition of endpoint includes "end user". I find
that term confusing: is "a user" a person, an application, or a device?
Actually, probably you mean "end-user", not a the user of an end :-)
---
Section 3 has...
NACL policies may need to vary over time. For example, companies may
restrict (or grant) employees access to specific internal or external
resources during work hours, while another policy is adopted during
off-hours and weekends.
Pedantically, the example you give here is of use of different policies
over time, not actually varying the policies themselves.
---
4.1 should expand "SDN". A reference would be useful, too. References
for NAS and AAA on their first use would also be useful.
---
While this is obviously in the purview of this working group, it is
going to need some serious security review. The chairs need to make
provision for that, possibly by approaching SAAG to get a security
reviewer assigned.
From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of Tianran Zhou
Sent: Tuesday, September 5, 2023 2:13 AM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03
Hi WG,
This mail starts a two weeks working group adoption call for
draft-ma-opsawg-ucl-acl-03
https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/
Please send over your objections or supports to the mailing list.
If you object the adoption, please also give the reason, so that the authors
can improve.
We will conclude this adoption call on Sep 20, 2023.
All your comments are welcome.
Best,
Tianran
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
