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? _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
