Hi Quifang, This version looks good.
Thanks, Acee > On Feb 3, 2026, at 6:01 AM, maqiufang (A) <[email protected]> wrote: > > 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]> 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]> > wrote: > > > > > On Jan 30, 2026, at 12:45 PM, Acee Lindem <[email protected]> wrote: > > Inline. > > > On Jan 30, 2026, at 3:08 PM, Mahesh Jethanandani <[email protected]> > wrote: > > Hi Acee/Qiufang, > > > On Jan 29, 2026, at 4:32 AM, Acee Lindem <[email protected]> wrote: > > Hi Qiufang, > > > See inline. > > > On Jan 29, 2026, at 2:41 AM, maqiufang (A) <[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 > (seehttps://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] > > > > Mahesh Jethanandani > [email protected] > > > > > > > Mahesh Jethanandani > [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
