Many thanks for the comments. Please see responses from authors inline, marked “TA”. Action items from this mail to update the document are marked: [AI-TA] to mean: “action item for the authors”.
On 15/05/2019, 19:55, "Alissa Cooper via Datatracker" <[email protected]> wrote: 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. TA> Agreed, will add definition [AI-TA] (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. TA> There is some coverage in section: “5.4.2. Common Authentication Flows”. The document does not help at all though as there is no reference from the enumeration to 5.4.2, we will add that. [AI-TA] (3) How is "secure deployment" defined? Since this is used as a restriction in several places, I think it needs to be defined precisely. TA> Will define that early in the document. [AI-TA] ---------------------------------------------------------------------- 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. TA> Agreed [AI-TA] Please respond to the Gen-ART review, which makes several suggestions for needed clarifications. In Section 2, please use the RFC 8174 boilerplate. TA> Agreed [AI-TA] _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
