Hi, Adrian Thanks a lot for the comments! The authors have create a PR to resolve these: https://github.com/boucadair/policy-based-network-acl/pull/19/files, except the one that moves the schedule model in a separate draft, we have created an issue to track this alone: https://github.com/boucadair/policy-based-network-acl/issues/17.
One thing that might be worth mentioning is that we have used a slightly different title from the one you suggested: A YANG data model and RADIUS extension for Policy-based Network Access Control(note that there will be only one data model since the schedule model is going to be moved out), and a reference has also been added for "policy". Best Regards, Qiufang From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, September 12, 2023 4:33 AM To: 'Tianran Zhou' <zhoutianran=40huawei....@dmarc.ietf.org>; opsawg@ietf.org Cc: opsawg-cha...@ietf.org Subject: Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03 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<mailto:opsawg-boun...@ietf.org>> On Behalf Of Tianran Zhou Sent: Tuesday, September 5, 2023 2:13 AM To: opsawg@ietf.org<mailto:opsawg@ietf.org> Cc: opsawg-cha...@ietf.org<mailto: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
