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. > 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". > 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. > 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:-( 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
