Subject: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-rfc2845bis-07: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 09 Mar 2020 21:19:45 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-dnsop-rfc2845bis-07: 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-dnsop-rfc2845bis/

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

— Section 4.2 —

         *  Other Len - an unsigned 16-bit integer specifying the length
            of the "Other Data" field in octets.
         *  Other Data - this unsigned 48-bit integer field will be

Does this mean that “other data” is always 48 bits?  If so, does that mean tgat
the value of “other len” is always 6?  If so, then shouldn’t it say that?  If
not, then what don’t I understand?

— Section 5.1 —

   Clients SHOULD only attempt signed
   transactions with servers who are known to support TSIG and share
   some algorithm and secret key with the client -- so, this is not a
   problem in practice.

Why SHOULD and not MUST?

— Section 5.3.2 —

   The server SHOULD also cache the most recent time signed
   value in a message generated by a key

I tripped over this until I realized you mean “Time Signed value”.  You
capitalize it elsewhere, and it helps the parsing if it’s consistent. There are
four uncapitalized instances in this section.

— Section 9 —

   There is no structure
   required other than names for different algorithms must be unique
   when compared as DNS names, i.e., comparison is case insensitive.

I found this sentence to be really awkward and hard to parse.  May I suggest
this?:

NEW
There is no structure to the names, and algorithm names are compared as if they
were DNS names (the comparison is case-insensitive). END

I don’t think you really need to say that each name is different/unique, right?

   other algorithm
   names are simple (i.e., single-component) names.

Nitty thing that you can completely ignore, but I would avoid the Latin
abbreviation thus: “other algorithm names are simple, single-component names.”