[yang-doctors] Re: YANG Doctor review for "A YANG Data Model and RADIUS Extension for Policy-based Network Access Control" - draft-ietf-opsawg-ucl-acl

[Mahesh Jethanandani <[e-mail]>]

> On Jan 30, 2026, at 12:45 PM, Acee Lindem <[e-mail]> wrote:
> 
> Inline.
> 
>> On Jan 30, 2026, at 3:08 PM, Mahesh Jethanandani <[e-mail]> wrote:
>> 
>> Hi Acee/Qiufang,
>> 
>>> On Jan 29, 2026, at 4:32 AM, Acee Lindem <[e-mail]> wrote:
>>> 
>>> Hi Qiufang, 
>>> 
>>> 
>>> See inline. 
>>> 
>>>> On Jan 29, 2026, at 2:41 AM, maqiufang (A) <[e-mail]> 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
>> [e-mail]


Mahesh Jethanandani
[e-mail]