Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII

[t.petch <[e-mail]>]

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" <[e-mail]>
To: "Douglas Gash (dcmgash)" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, May 17, 2017 3:54 PM
Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status
and Plans


<snip>