Another fresh topic, so a slight change in the Subject: I think that the use of the term ASCII needs more thought.
a) There is mix of US-ASCII and ASCII with seemingly no difference in semantic. I would like this to be US-ASCII .. b) except that there is usage of 'ASCII login' which looks like a Term of Art, at least within TACACS so I suggest keeping ASCII solely for the login. c) there is no reference for US-ASCII. There is no good reference for US-ASCII but I usually see RFC20 being usedalthough some prefer ANSI X3.4, 1986. 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. 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. 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 whereever possible 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. 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. 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:-( 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. Tom Petch ----- Original Message ----- From: "Alan DeKok" <[email protected]> To: "Douglas Gash (dcmgash)" <[email protected]> Cc: <[email protected]>; <[email protected]> Sent: Wednesday, May 17, 2017 3:54 PM Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans <snip> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
