Subject: [OPSAWG] Barry Leiba's No Objection on draft-ietf-opsawg-tacacs-15: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Sun, 22 Sep 2019 10:59:38 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-opsawg-tacacs-15: 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 posting version -15.  It resolves my DISCUSS issues with respect to
character encoding, though it adds a couple of oddities -- not at the level of
DISCUSS, but worthy of comment, which I ask that you consider:

1. Three times in the new Section 3.7 you refer to "byte arrays":

   original draft intended that these strings would be treated as byte
   arrays where each byte would represent a US-ASCII character.

   Where specifically mentioned, data fields contain arrays of arbitrary
   bytes as required for protocol processing.

   All other text fields in TACACS+ MUST be treated as printable byte
   arrays of US-ASCII

I'm sort of OK with the use of "arrays of arbitrary bytes" in the second case,
as you're not talking about character strings, though we usually reserve
"array" to refer to a particular data structure with a particular mechanism of
access.  But I won't quibble about that.  In the other two cases, it seems an
odd distraction, and I wish you would use "strings" instead of "arrays".

2. In many places in the document you have added a space after ")" or "]".  For
example, "For IPv6 address text representation defined please see RFC 5952
[RFC5952] ." and "For more details please refer to security section (Section
10) ."  Why did you do that?  The RFC Editor will only have to take them back
out, so I recommend that you take them out now, instead.

Again, thanks for the update and for addressing my DISCUSS.