Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
Thanks Alan, will correct the nit. I need to correct by previous ambiguity: By: 'without changing too much the draft spec' I should have said: 'without changing too much the protocol that was "defined" draft spec. The original draft spec text has already been largely rewritten by the recent submissions. Thanks, Regards, Doug. On 17/09/2017 15:26, "Alan DeKok" wrote: >On Sep 16, 2017, at 11:41 PM, Douglas Gash (dcmgash) >wrote: >> >> We¹re preparing the next revision. Regarding attribute value encoding, >> we¹re proposing to add the following, then to assign a type to each >> attribute. As always with T+, the issue is getting the right balance in >> adding some order without changing too much the draft spec. > > The right balance is to document the protocol. > > If documenting the spec means tossing the draft and starting from >scratch, then so be it. > >> Proposed content is as below, please share any views: > > It definitely seems better that the previous ad-hoc definitions. > >> Boolean >> >> All boolean attributes are encoded with values "true" or "false". > > Nit: encoded as US-ASCII strings with values... > > > Alan DeKok. > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
On Sep 16, 2017, at 11:41 PM, Douglas Gash (dcmgash) wrote: > > We¹re preparing the next revision. Regarding attribute value encoding, > we¹re proposing to add the following, then to assign a type to each > attribute. As always with T+, the issue is getting the right balance in > adding some order without changing too much the draft spec. The right balance is to document the protocol. If documenting the spec means tossing the draft and starting from scratch, then so be it. > Proposed content is as below, please share any views: It definitely seems better that the previous ad-hoc definitions. > Boolean > > All boolean attributes are encoded with values "true" or "false". Nit: encoded as US-ASCII strings with values... Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
Hi All,
We¹re preparing the next revision. Regarding attribute value encoding,
we¹re proposing to add the following, then to assign a type to each
attribute. As always with T+, the issue is getting the right balance in
adding some order without changing too much the draft spec.
Proposed content is as below, please share any views:
7. Attribute-Value Pairs
TACACS+ is intended to be an extensible protocol. The attributes
used in Authorization and Accounting are not limited by this
document. Some attributes are defined below for common use cases,
clients MUST use these attributes when supporting the corresponding
use cases.
7.1. Value Encoding
All attribute values are encoded as printable US-ASCII strings. The
following type representations SHOULD be followed
Numeric
All numeric values in an attribute-value string are provided as
decimal printable US-ASCII numbers, unless otherwise stated.
Boolean
All boolean attributes are encoded with values "true" or "false".
IP-Address
It is recommended that hosts be specified as a IP address so as to
avoid any ambiguities. ASCII numeric IPV4 address are specified as
octets separated by dots ('.'), IPV6 address text representation
defined in RFC 4291.
Date Time
Absolute date/times are specified in seconds since the epoch, 12:00am
Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is
specified.
String
Many values have no specific type representation and so are
interpreted as plain strings.
Empty Values
Attributes may be submitted with no value, in which case they consist
of the name and the mandatory or optional separator. For example,
the attribute "cmd" which has no value is transmitted as a string of
four characters "cmd="
7.2. Authorization Attributes
service (String)
The primary service. Specifying a service attribute indicates that
this is a request for authorization or accounting of that service.
For example: "shell", "tty-server", "connection", "system" and
"firewall". This attribute MUST always be included.
protocol (String)
the ptotocol field may be used to indicate a subset of a service.
cmd-arg (String)
an argument to a shell (exec) command. This indicates an argument
for the shell command that is to be run. Multiple cmd-arg attributes
may be specified, and they are order dependent.
acl (Numeric)
printable US-ASCII number representing a connection access list.
Applicable only to session-based shell authorization.
Š etc
On 21/05/2017 21:34, "t.petch" wrote:
>- Original Message -
>Sent: Friday, May 19, 2017 7:06 PM
>
>Isn't this handled by RFC 20?
>
>
>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" wrote:
>>
>>> On May 19, 2017, at 6:38 AM, t.petch 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
>
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
- Original Message - Sent: Friday, May 19, 2017 7:06 PM Isn't this handled by RFC 20? 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" wrote: > >> On May 19, 2017, at 6:38 AM, t.petch 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 fo
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
Isn't this handled by RFC 20? On 5/19/17 7:51 PM, Douglas Gash (dcmgash) wrote: > > On 19/05/2017 18:11, "Alan DeKok" wrote: > >> On May 19, 2017, at 6:38 AM, t.petch 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 m
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
On 19/05/2017 18:11, "Alan DeKok" wrote: >On May 19, 2017, at 6:38 AM, t.petch 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 OPSAWG@ietf.org https://www.ietf.org/mailman/
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
On May 19, 2017, at 6:38 AM, t.petch 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
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
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" To: "Douglas Gash (dcmgash)" Cc: ; Sent: Wednesday, May 17, 2017 3:54 PM Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
