On 19/05/2017 18:11, "Alan DeKok" <[email protected]> wrote:
>On May 19, 2017, at 6:38 AM, t.petch <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
