Hi, Mahesh, Acee, -12 is posted, please review it and let us know if you have further comments. As the -11 contains formatting issues that might make the diff at https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ucl-acl-12 difficult to read, the following one may be clearer which shows the updates in the reverse direction: https://author-tools.ietf.org/diff?url_1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ucl-acl-12.txt&url_2=https://www.ietf.org/archive/id/draft-ietf-opsawg-ucl-acl-11.txt
Thanks a lot. Best Regards, Qiufang From: Mahesh Jethanandani [mailto:[email protected]] Sent: Tuesday, February 3, 2026 2:01 AM To: Acee Lindem <[email protected]> Cc: Mohamed Boucadair <[email protected]>; maqiufang (A) <[email protected]>; [email protected]; YANG Doctors <[email protected]>; [email protected] Subject: Re: [yang-doctors] YANG Doctor review for "A YANG Data Model and RADIUS Extension for Policy-based Network Access Control" - draft-ietf-opsawg-ucl-acl Hi Acee, Thanks. In this particular case, I do not think we need a separate module for scheduling. The ucl-acl model is already using groupings from ietf-scheduie module. Qiufang, if you can address the remaining comments and post an updated draft, it will allow Acee to clear the document. Cheers. On Feb 2, 2026, at 8:07 AM, Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Hey Mahesh, Med, if you guys are fine with not having a separate model for the ACL scheduling augmentation, then I am too. I'll look at the next revision and the mark the YANG doctor review as ready. I'm not trying to make the YANG doctors my life's work đ Thanks, Acee On Jan 30, 2026, at 4:10âŻPM, Mahesh Jethanandani <[email protected]<mailto:[email protected]>> wrote: On Jan 30, 2026, at 12:45 PM, Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Inline. On Jan 30, 2026, at 3:08âŻPM, Mahesh Jethanandani <[email protected]<mailto:[email protected]>> wrote: Hi Acee/Qiufang, On Jan 29, 2026, at 4:32 AM, Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Hi Qiufang, See inline. On Jan 29, 2026, at 2:41âŻAM, maqiufang (A) <[email protected]<mailto:[email protected]>> wrote: Hi, Acee, Thanks for the follow-up, please see below inline with [Qiufang]. My co-authors may chime in if they wish. I have one major concern with this document. The YANG model adds generalized schedule-based ACEs, yet this is not reflected in the YANG model name, draft title, or abstract. This should at least be in a separate YANG model and possibly in a separate draft since it appears to have been added as an afterthought and, IMO, it is much more important than the group-based access control. [Qiufang] Note that this is not an afterthought design, it is there when the draft was -00. We split the scheduling related definition into a separate I-D to define common groupings (see https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/), based on the WG feedback. I agree with you that the extension regarding scheduling is of great importance, it addresses the requirement of âwhen to take effectâ, together with endpoint group based matching, which resolves the requirement of âfor whom to take effectâ, they both constitutes the data model, separating them could fragment the policy model. Hopefully this clarifies the intention. To enhance the visibility of the scheduling feature, we have updated both the abstract and introduction sections to reflect it explicitly. Will you also have a separate YANG model? For example, ietf-acl-ace-sched.yang? [Qiufang] As clarified, creating a separate model might introduce unnecessary fragmentation. Note we already use if-feature to make each augment conditional ("match-on-group" feature for endpoint group based augmentation and "schedule" feature for date and time based ACLs), this allows the potential for reuse that a separate model could provide, especially for implementations that wants to support time-based ACLs without the complexity of endpoint group matching. Thanks. I think quite the contrary. Hiding this important capability with a feature into a model relating to RADIUS authentication is just wrong. This model will need to be imported just to get the scheduled ACE functionality. I'd like to hear what Med (Co-author) and Majesh have to say about this. I am not sure if this is directed to me, as I am not Majesh :-) That is Mahesh in Español... Ha ha! The core offering of the draft is a policy-based network access control. As part of that offering, there is as you note Acce, a *capability* of being able to schedule that policy. That capability is much like the rest of the capabilities in the module, e.g., mapping of a user group to set of IP/MAC addresses. Rather than listing every capability in the Abstract, how about this as a suggested change? Who is Acce? đ đ€Ș Abstract: The abstract anyway needs to be short and succint. It could therefore drop the second paragraph and just say: "This document defines a YANG data model for policy-based network access control, which provides enforcement of network access control policies based on group identity.â and then in the Introduction, where one normally starts describing the module in detail could add a sentence, (which BTW, appears later in the draft). Specifically, in the Introduction section, the paragraph that starts with âSpecifically in scenarios âŠâ, could see an addition of the following sentence at the end. âFinally, it enables access control policy activation based on date and time conditions.' I was also thinking the scheduling should have its own YANG module, e.g., ietf-acl-sched.yang, that could be imported separately since this is more significant the the extension for authentication. You will notice that large parts of the scheduling portion of the module is an import of groupings from "ietf-scheduleâ data model which is already a separate module defined in draft-ietf-netmod-schedule-yang. Cheers. Thanks, Acee Cheers. 5. How did you decide on 64 octets for the group identifier string maximum? [Qiufang] As specified in the YANG module, the âgroup-idâ is defined as a string type with a length constraint of "1..64". This is to align with that. Right - I'm asking how you came up with 64 octets as a limit? [Qiufang] sorry for misunderstanding. 64 is not arbitrary, see https://www.rfc-editor.org/rfc/rfc7950.html#section-6.2: "Implementations MUST support identifiers up to 64 characters in length and MAY support longer identifiers." And also https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#section-4.3: "All YANG identifiers in published modules MUST be between 1 and 64 characters in length." The references you cite are relating to YANG model identifiers, e.g, "group-id", NOT the length of the value of a YANG type string leaf. 6. In section 6, I would have expected the attribute to be the first column in table 4. [Qiufang] Review of RADIUS-related RFCs (e.g., RFC 8044, RFC 2865) reveals no mandatory requirement that the attribute column be placed as the first column in the table. Since the table focuses solely on the single attribute "User-Access-Group-ID"âwith no need to distinguish between multiple attributesâplacing the attribute column last does not obscure the key information. There are also some input received from RADEXT WG, see some previous discussion at : https://mailarchive.ietf.org/arch/msg/opsawg/EWuvlu623PgapTPSB4s8LM6lc5M/. But English is normally left-to-right and one would expect the attribute to be in the first column. [Qiufang] Thanks, Acee. I donât really have a strong feeling regarding this. While I checked some existing RFCs that register the RADIUS attribute type from "Radius Attribute Types", it seems that most of the RFCs put the attribute as the last column, e.g., https://datatracker.ietf.org/doc/html/rfc5176#section-3.6, https://datatracker.ietf.org/doc/html/rfc8658#Table3, https://datatracker.ietf.org/doc/html/rfc5090#section-5, and https://datatracker.ietf.org/doc/html/rfc9445#table-1, perhaps aligning with existing RFCs would help improve consistency? Ok, You can leave it if there are other places where it is backwards. THanks, Acee Best Regards, Qiufang Mahesh Jethanandani [email protected]<mailto:[email protected]> Mahesh Jethanandani [email protected]<mailto:[email protected]> Mahesh Jethanandani [email protected]<mailto:[email protected]>
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
