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 (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] >> >> >> >> Mahesh Jethanandani >> [email protected] >> >> >> >> >> >> > Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
