[Trans] Roman Danyliw's Yes on draft-ietf-trans-rfc6962-bis-34: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-trans-rfc6962-bis-34: Yes

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-trans-rfc6962-bis/



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

(Adding a Yes ballot with comments on my own document as it was inherent during
an AD change)

** Section 2.2 and 3.2.  Reference the IANA registry name, not just the
document section

-- Section 2.2. Per “A log MUST use one of the signature algorithms defined in
Section 10.3.”, recommend instead saying that the acceptable signature
algorithms are defined in “the IANA ‘CT Signature Algorithms’ registry
described in Section 10.3.

-- Section 3.2.  Per the digestAlgorithm “MUST be one of the hash algorithm
OIDs listed in Section 10.2”, recommend instead saying “MUST be one of the hash
algorithms OIDs listed in the IANA ‘CT Hash  Algorithms’ registry described in
Section 10.2”.

** Section 4.13.  Per the list of guidance on shutting down a log following
“[t]o avoid that, the following actions are suggested:”, should normative
language be used in making this recommendation.  Perhaps “To avoid that the
following actions are RECOMMENDED:” or “To avoid that the following actions
SHOULD be taken:”?

** Section 4.13.  Per “Make it known to clients and monitors that the log will
be frozen.”, I recommend clarifying that this is via some
out-of-band/out-of-scope mechanism not defined in the Section 5.x API.

** Section 5.1, 5.3, 5.4, 5.6.  Each of these sections helpfully lists the
possible errors given the action, however, the corresponding HTTP response
codes is not clear.

** Section 11.3 and 11.4.  Do the following references to gossip still make
sense since ietf-trans-gossip is not proceeding? -- (Section 11.3) “There are
various ways this could be done, for example via gossip (see
[I-D.ietf-trans-gossip]) …”

-- (Section 11.4)  “Clients that gossip STH …”, if the gossip reference is
removed, using this verb doesn’t make sense.

** Editorial nits:

-- Per “Various data structures Section 1.2 are signed”:
o s/Section 1.2/in Section 1.2/
o practically, there are no data structures in Section 1.2, only a reference to
a presentation language of available data structures.