[OPSAWG] Alissa Cooper's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)

[Alissa Cooper via Datatracker <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-opsawg-tacacs-13: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) The Gen-ART reviewer Stewart Bryant (SB) asked the following:

     TAC_PLUS_PRIV_LVL_MAX := 0x0f

     TAC_PLUS_PRIV_LVL_ROOT := 0x0f

     TAC_PLUS_PRIV_LVL_USER := 0x01

     TAC_PLUS_PRIV_LVL_MIN := 0x00

SB> Where are these defined?

Please define the semantics of these values.

(2) Stewart also noted the following:

     TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01

     TAC_PLUS_AUTHEN_TYPE_PAP := 0x02

     TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03

     TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)

     TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05

     TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06

SB> There are lots of lists similar to the above.
SB> I have not checked them all, but a number of the types
SB> in this and subsequent parts of the design don't seem
SB> to be defined or have a definitive reference

The way I would say this is that the document seems to be written for people
who have already deployed this protocol, and elides details that would make it
comprehensible to a new implementor. But it also contemplates the prospect of
new implementations. If new implementations are actually expected (which I was
surprised about, but can believe), I agree with Stewart that each of the field
values need a definition that explains its semantic. If new implementations are
not expected, then the reference to new implementations should be removed.

(3) How is "secure deployment" defined? Since this is used as a restriction in
several places, I think it needs to be defined precisely.


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

I agree with Deborah's comment, and would further suggest that the lack of
modern security mechanisms in this protocol needs to be called out in the
introduction, with a reference to Section 10.

Please respond to the Gen-ART review, which makes several suggestions for
needed clarifications.

In Section 2, please use the RFC 8174 boilerplate.