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