> -Original Message-
> From: Alan DeKok [mailto:al...@deployingradius.com]
> Sent: Friday, May 19, 2017 1:40 AM
> To: t.petch
> Cc: Tianran Zhou; Ignas Bagdonas; IETF OOPSAWG;
> draft-ietf-opsawg-tac...@ietf.org; opsawg-cha...@ietf.org
> Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Co
Hi Tom,
There was a conclusion based on the WG consensus:
https://mailarchive.ietf.org/arch/msg/opsawg/lR3TFRfaR8OldmPFjuVhRTQZHEE
As the first step, we
"Produce an informational document which documents the TACACS+ protocol as it
stands today (as best as we can)."
My suggestion is that we do n
On May 18, 2017, at 12:57 PM, t.petch wrote: of thought.
>
>
> This I-D, as Alan has commented and Doug acknowledges, has several
> places where the description of security is more 1997 than 2017. If we
> turn such parts into a clear, concise specification, we may then find
> that we have waste
In such a query, it might be worth mentioning that the doc was originally
intended to include TLS support added in order to address significant
elements of the security issues.
The current plan is a two-phased approach whereby the original protocol
would be documented for information first, and th
WG Chairs
A slight change of thought.
This I-D, as Alan has commented and Doug acknowledges, has several
places where the description of security is more 1997 than 2017. If we
turn such parts into a clear, concise specification, we may then find
that we have wasted our time since the Security Di
Hi Med and Senthil,
I had a look at this draft, and found some issues that I'd like to discuss.
Regards,
Tianran
1. You use the uint32 type id as key for many list objects. For example:
| +--rw nat-instances
| +--rw nat-instance* [id]
|+--rw id
