> 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. <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-10> 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]
