On Oct 5, 2022, at 8:37 AM, Bernie Volz <bev...@gmail.com> wrote: > One minor item you may want to look at is whether “text” is the best way to > label the following data type in Table 2: > > TBA3 | Encrypted-DNS-ADN | text | This-Document, | > | | | | > Section 3.3.1 > > Perhaps “dns wire encoding” might be better?
If it's encoded as a sequence of DNS labels (length + data, length + data, 00), then the correct RADIUS data type is "string" [RFC8044] Section 3.5: The "string" data type encodes binary data as a sequence of undistinguished octets. ... > Someone that just uses this table may get it wrong? While perhaps there is > some definition of “text” for Radius attributes, a quick check of some seems > to show that it is mostly used for textual values. RFC 8044 Section 3.4 says this: The "text" data type encodes UTF-8 text ... > But perhaps you have limited choices here and other dns encoded attributes > already use text? There are other attributes in RADIUS which encode host names, but those are all printable / UTF-8. I think this is the first RFC which uses the "dns encoding" format for DNS names. RFC 8044 allows the transport of non-RADIUS data types when that data is simply carried in RADIUS, and is not supposed to be interpreted or used by a RADIUS client or server. In this case, I think it's a wash. Everything else in RADIUS uses printable strings. But if this attribute is simply sent to a another system which copies it into a DHCPv6 packet as-is, then that's fine. i.e. "this attribute is then copied verbatim into a DHCPv6 attribute ????" Such text is missing from the document. The Introduction does imply that the RADIUS attributes can be copied to DHCPv5: However, there are no RADIUS attributes that can be used to populate the discovery messages discussed in [I-D.ietf-add-dnr]. But there is nothing which says "RADIUS attribute FOO is copied to DHCPv6 option BAR". There should probably either be an explicit mapping table given, or each attribute definition should be extended with "this attribute is copied to DHCPv6 attribute BAR" Without such direction, an implementor has to guess as to the mapping. As an implementor, I would strongly prefer that the document gives explicit direction. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
