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