[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-13: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Wed, 15 May 2019 20:35 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B781200FE; Wed, 15 May 2019 13:35:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsawg-tacacs@ietf.org, Joe Clarke <jclarke@cisco.com>, opsawg-chairs@ietf.org, opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <155795250991.30689.1445498577568703956.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 13:35:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/2oiBcQlAH7W96wMyMV9ezgfYIDw>
Subject: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-13: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 20:35:10 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-tacacs-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work everyone has put into this document. I have some comments
and some nits. I also support most of the other comments issued by the IESG
members.

And, I appreciate the time taken to document a protocol that I used in the mid
90's ;-) it took sometime to document it... I also appreciate the use of
'obfuscation' in section 4.7.

== COMMENTS ==
- section 1, I am unsure whether the 'today' in 'It is primarily used today...'
still stands in 2019. - a little late to ask, but, is there any reason why
draft-dahm-opsawg-tacacs does not refer to 'The Draft' in the datatracker? -
section 4.8, the flag values are 0x01 and 0x04, but what about the other bits?
Should they be considered as 0 and ignored on reception? - section 5.1, should
TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 also be deprecated ? - section 5.4.2.1 about
'ASCII login' while I understand that years ago it was ASCII only hence the
name of the value but the text is unclear whether UTF-8 could be used (assuming
that the network devices support this character set) - section 8.2, the route
attribute is defined only for IPv4 while the T+ can send IPv6 addresses to the
client. Is it sensible?

== NITS ==
- abstract TACACS is an acronym which should be expanded in the abstract
- section 3 could be updated esp around "character mode front end and then
allow the user to telnet" - section 4.1 add that the port 49 has been allocated
by the IANA ? - section 4.3 talks about flags but the packet format is also
presented in section . Not a logical flow - section 8.1 s/IPV6 address text
representation defined/IPv6 address text representation is defined/ (lower case
V as well) - section 8.2, please clarify the inacl value, is it an ACL name or
an ASCII representation of the list of ACL entries?