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

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

----- Original Message -----
Sent: Friday, May 19, 2017 7:06 PM

Isn't this handled by RFC 20?

<tp>
Eliot

RFC20, AFACT, does not define Boolean, or Numeric or Printable (albeit
something which the current I-D does not currently use) while its
definition of 'text' (which the I-D does use) is based on starting with
STX so IMHO, no.

RFC20 is just a list of 128 characters with a numeric code.  Every other
protocol specification I can think of places restrictions thereon; DC3
in a username, anyone?

RFC4234 is to me a good example of an RFC that starts with RFC20 (or the
equivalent thereof) and produces something more usable.

Tom Petch

On 5/19/17 7:51 PM, Douglas Gash (dcmgash) wrote:
>
> On 19/05/2017 18:11, "Alan DeKok" <[e-mail]> wrote:
>
>> On May 19, 2017, at 6:38 AM, t.petch <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>