Some minor wording adjustments

[ounsworth]

No description provided.

[davidben]

Thanks! That makes things a bit clearer! Some comments below.

[davidben]

caution -> cautios, protocls -> protocols.
Though "should be cautious about" reads like SHOULD CONSIDER. :-)

I dunno, I guess we should sort out what we're actually trying to say here. Previously it was:

• You probably don't want to exceed 65535. You probably are using tlog-tiles, and that is limited there
• PS: Don't worry about PQ stuff

And I suppose the point here is that there's an implicit "you should honor the limits or whatever other things impose on you" that's... honestly tautological but perhaps a glue thought missing between them.

But also maybe this is too complicated and we just keep it simple:

Suggested change

An MTCLogEntry's size SHOULD NOT exceed 65535 (2<sup>16</sup>-1) bytes. Doing so might exceed size limits in common log-serving protocols, such as {{TLOG-TILES}}, so implementer SHOULD be caution about any limits imposed by the protocls and log providers that they intend to use. TBSCertificateLogEntry does not include signatures and hashes public keys, so post-quantum algorithms do not contribute to this size.

An MTCLogEntry's size SHOULD NOT exceed 65535 (2<sup>16</sup>-1) bytes. TBSCertificateLogEntry does not include signatures and hashes public keys, so post-quantum algorithms do not contribute to this size.

That:

1. Makes you compatible with tlog-tiles, but that's not normative text and the little FYI seems to be too complicated.
2. Hints that, if you're building a log protocol that's not tlog, you should maybe try to accommodate 65535

And then if hypothetically someone were building something new on top of MTCs and needed a different limit, they can sort that out then. We don't need to say "if you have other limits, you have other limits".

Thoughts?

[ounsworth]

Yeah, I agree this is a weird non-normative "but what about the children TLOG" sentence that mostly doesn't do anything. I'll give you another commit that goes halfway to Deleted.

[davidben]

I think this will render as "start and end MUST define a valid subtree of the log Section 1.2.3". I.e. just stick "Section 1.2.3" directly inline in the text. I usually put parens like ({{sec-subtree}}) or write See {{sec-subtree}}.

Although these are both citing the same section. It's annoying that our specs don't allow more lightweight links everywhere but, failing that, perhaps:

Suggested change

	`start` and `end` MUST define a valid subtree of the log {{sec-subtree}}, and `subtree_hash` MUST be the subtree's hash value {{sec-subtree}} in the cosigner's view of the log.
	`start` and `end` MUST define a valid subtree of the log , and `subtree_hash` MUST be the subtree's hash value in the cosigner's view of the log. See {{sec-subtree}}.

[ounsworth]

Yup, that's better.

By the way, does the {{name-of-section}} syntax work for all kramdown, or did you have to do something in the preamble to make that work?

[davidben]

By the way, does the {{name-of-section}} syntax work for all kramdown, or did you have to do something in the preamble to make that work?

As far as I know, it works for all of kramdown.

[davidben]

One last comment but otherwise looks good. Thanks for this!

[davidben]

Merged and then added you to acknowledgements in 2e87ea1