[Trans] Mirja Kühlewind's No Objection on draft-ietf-trans-rfc6962-bis-34: (with COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-trans-rfc6962-bis-34: 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-trans-rfc6962-bis/



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

Thanks for addressing my discuss and adding some more text in the security
consideration section!

I believe all comments below are still valid, expect 2 which is a nit that was
fixed. I would really like to see some recommendations on point 5 before this
document moves on!

 1) I found section 2 a bit hard to follow. Would it maybe be possible to
 provide more textual explanation of the algorithms instead of just describing
 the steps of the algorithms? Also I was wondering how much much these
 algorithms are actually „part“ of the protocol spec…? Are could these be
 rather seen as example algorithms? Maybe that could be further clarified

 2) Please expand STH on first occurrence (in sec 4.1)

 3) Sec 4.4: „A log's operator MUST either allocate the OID
    themselves or request an OID from the Log ID Registry (see
    Section 10.6.1).“
Isn't there an obligation to register?

 4) sec 4.8: „If an
   implementation sees an extension that it does not understand, it
   SHOULD ignore that extension.“
Maybe it’s just me because I may have missed some context but does „ignore“
mean here that it should log it or not?

 5) sec 5: „MAY retry the same
   request without modification at a later date.“
Would it be possible to provide a recommendation how long the client should
wait?

 6) sec 5.6: „Logs MAY restrict the number of entries that can be retrieved per
   "get-entries" request.“
Should this be added to sec 4.1?

 7) sec 10.3: Couldn’t you use the TLS  SignatureScheme Registry directly
 (instead of forming an own registry)?

 8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate
 for the VersionedTransTypes registry?

 9) sec 10.6.1:I guess  the registration policy is FCFS? RFC 8126 recommend to
 always (clearly) name the registry.

And finally one higher level question mainly out of curiosity: was it
considered to e.g. use json for all data structures? Is there a performance
reason to not do that or wasn’t that even discussed?