On Thu, 12 Oct 2023 at 18:05, <mohamed.boucad...@orange.com> wrote:
> Thank you for catching this. > > > > What is actually interesting is that we are discussing a PR to make the > change in the other way around: > https://github.com/boucadair/policy-based-network-acl/pull/20/files. > The PR documents the length of group-id as "1..64". Looking at 'string' type definition for Radius, RFC 8044 requires this length restriction to be a part of the new attribute definition: https://datatracker.ietf.org/doc/html/rfc8044#section-3.5 I took a quick look at YANG definitions, and YANG's 'string' definitions talks about Unicode. https://datatracker.ietf.org/doc/html/rfc7950#section-9.4 Because the Unicode code points need to be somehow encoded when sent over the network, the draft likely needs a definition of how to encode YANG 'string' type group-id so that it can be sent with a Radius attribute. In this case the Radius attribute payload length could be more than 64. In other words, the draft should likely define how to encode YANG 'string' type group-id to a presentation suitable for Radius transport. I think doing this clarifies, for example, what's the Radius attribute length restriction. It would also make it clear on how to encode/decode a group-id value for transporting it over the new Radius attribute. Radius also has type 'text' for carrying UTF-8 encoded strings. https://datatracker.ietf.org/doc/html/rfc8044#section-3.4 This might be helpful too. -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
