Isn't this handled by RFC 20?
On 5/19/17 7:51 PM, Douglas Gash (dcmgash) wrote: > > On 19/05/2017 18:11, "Alan DeKok" <al...@deployingradius.com> wrote: > >> On May 19, 2017, at 6:38 AM, t.petch <ie...@btconnect.com> wrote: >>> Another fresh topic, so a slight change in the Subject: >>> >>> I think that the use of the term ASCII needs more thought. >> Speaking only as an opinionated WG member... yes. >> >>> d) in some places, I think that the term ASCII is being used too >>> loosely. ASCII is a character set and an encoding. If you simply say >>> US-ASCII, then you are including DC3 and FF, for example, which are >>> unlikely to be valid. Some use US-ASCII to mean printable ASCII, some >>> to mean alphameric plus a few others such as hyphen-minus and period. >>> This needs defining. I don't know how many different character sets you >>> have - I was surprised that '&£#' (or some such) is a valid identifier >>> in places where an equal sign is not - so this needs more work. >> I agree. > Will align the ASCII references for sure, and tie down. I propose to > restrict to printable. Though, to add to complexity: it is common > practice, for example, to include newline in banners. > >>> e) this leads into data types, which Alan raised. Boolean is used as a >>> data type. (I have seen it as a character string of 'true'/'false' of >>> '0'/'1' with zero meaning either true or false or vice versa or as a >>> binary integer of some number of bits or ....) As Alan implied, section >>> 7 and others are full of data types but on the one hand, what type it is >>> is usually omitted and on the other hand, the data types are not >>> defined. >> The main issue with data types is that TACACS+ is a protocol based on >> printable strings. So "data types" really means "printed versions of >> data types", which is a lot more problematic than "32-bit integer". > I agree. Will put a section in regarding at a types, specifically for > attributes (As Alan pointed out). > >>> You need to define datatypes; from the current I-D, I do not know how >>> many there would be; probably not many. Look for example at TLS >>> (RFC5246) or YANG (RFC6020) which nail down the datatypes, semantic and >>> encoding, before they define data structures. This is what I think that >>> you should do, on a smaller scale. Since YANG is being so widely >>> deployed, you would get brownie points IMO for being in line with YANG >>> wherever possible >> That's good, tho there are inconsistencies. e.g. Yang "string" doesn't >> exactly map to TACACS+ "US-ASCII thing". Yang "boolean" is "true/false", >> while TACACS+ has used "yes/no". >> >> We added data types to RADIUS, because it had (roughly) data types from >> day one, 32-bit integers, and all of the implementors had already agreed >> on meanings / encodings for them. So RFC8044 was just a codification of >> existing practices, and not any change to implementations. >> >> Then there's the additional issue of trying to define data types for a >> protocol that's entirely string based, and has 18 years of implementation >> practice. >> >> i.e. before defining data types, it would be good to know what >> implementors have done, and then define types that match that. >> >> However, implementors are largely silent about all possible TACACS+ >> issues. Which makes me think that the draft should name the data types, >> but be a bit vague about what they contain. > Agreed, but try to be explicit about the vagueness. > > >>> I see a need for boolean, character string/text, IPv4 address, IPv6 >>> address, time interval, integer (positive ?negative). I would like a >>> section on datatypes at the front, section 1 or 2. >> I'd agree, subject to the caveats raised above. i.e. "boolean is >> boolean, typically yes/no, but maybe also true/false, we really don't >> know..." >> >>> f) in a similar vein, you use what I take to be hexadecimal >>> representation but are inconsistent with it. I see >>> OX0D 0x0D 0x1 0x01 >>> This should be consistent and is also worth defining, as a >>> representation. >> I agree, subject to the same caveats. It would also be nice to know >> what implementations do... >> >>> g) and then there is i18n, which gets an implicit mention with UTF8 but >>> harks back to d). How much of UTF8 is allowed and where; it encompasses >>> over 65k characters these day:-( > > Well, the approach we had in mind is printable US-ASCII for all fields, > apart form username and passwords, which are the hard points in > interfacing to identity provides which support. For these fields, to allow > UTF-8 on top of the byte streams. > > >> IMHO, the draft should just mention 18n, and run away screaming. :( >> >> As in, "we know about it, we don't know how to fix it, we don't know >> what implementations do, the fields are defined to be US-ASCII, if they >> contain anything else, that's bad." >> >>> This amounts to a lot of potential detailed change, but I would like to >>> see consensus on the approach first before edits are proposed or made. >> I think this is the right approach. >> >> Alan DeKok. >> > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
