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:03, "Mirja Kühlewind via Datatracker" <[email protected]> wrote: Mirja Kühlewind 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: ---------------------------------------------------------------------- A couple of comments/question: 1) I would like to see it more explicitly mentioned in the title, abstract, and introduction that this is only documenting the protocol as deployed today. Usually we use titles like “Company X’s TACACS+ protocol”; this is probably not applicable here but maybe something like “Documentation of the TACACS+ Protocol” would work as well…? TA> Agreed, will update as advised [AI-TA] 2) If Single Connection Mode is used and the connection is idle for a while, it can be possible that some middlebox or the server lost state and the connection is actually not available anymore. I guess it could be good to explicit mention this case and say something like if a RST or timeout is encountered for a connection in Single Connection Mode, the client should try to open a new connection and resend the request immediately. TA> Yes, that is certainly a possible scenario. I believe it will likely be caught by regular timeout mechanisms in the implementation, but we can call it out explicitly [AI-TA] 3) I would recommend to define the term “session” in section 3 (as it seems to a central term that is important to understand correctly). TA>Agreed, will add a definition of session as advised [AI-TA] 4) Sec 10.5.1: “TACACS+ servers MUST NOT leak sensitive data.” Not sure if that is an actionable requirement, as I would assume leaking is often done by accident. Maybe “TACACS+ servers MUST store sensitive data securely.”… or something…? Not sure how much better that is… Actually the next sentence could probably be normative: S/TACACS+ servers should not expose shared secrets in logs./TACACS+ servers MUST NOT expose shared secrets in logs./ TA> Agreed that section can be tidied and the clause you highlight normatized. [AI-TA] 5) One question regarding the unencrypted/non-obfuscated mode: Why was this mode (and TAC_PLUS_UNENCRYPTED_FLAG=1) not deprecated completely? You mention briefly somewhere that this is/was used for debugging but then later say that modern tools should also support debugging of obfuscated traffic. TA> It is certainly a valid point. If there is consensus, then I agreed it would make sense to be clear and say that unencrypted mode MUST NOT be used. 6) Sec 10.5.5: “TACACS+ servers SHOULD deprecate the redirection mechanism.” I believe you want to use a MUST here because you anyway only specify this for servers that follow or update to this spec; it will of course not change existing implementations… TA> Agreed [AI-TA] _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
