Benjamin Kaduk has entered the following ballot position for draft-ietf-regext-change-poll-10: Discuss
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-regext-change-poll/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a fairly minor point, but the text of Section 2.3 implies that there is a distinct list of identifier types that the server MAY use (and thus that there would be a protocol element to convey such an identifier type), but the actual schema in Section 4.1 is clear that the <changePoll:who> element is just a freeform token with some modest length restrictions (i.e., no place for internal structure). I'd like to hear from others on the IESG whether the text about the schema used being up to server policy is enough to make this clear, or we think there is some level of internal inconsistency in the document to be rectified. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the generally well-written document! There are several places in the document where we read about a "list of [...] values includes" that is in fact required to be one of a fixed enumerated set of values. In such cases I would suggest "comprises" or "is" rather than "includes", which could be taken to indicate the possibility of additional values being defined at a later time. Section 2.1 has multiple instances of this, and Section 3.12. as well. Section 2.2 Maybe state explicitly what it's inserted into, for clarity. Section 2.3 "CSR" could expand to either "Customer Support Representative" or "Certificate Signing Request" for some people. I don't know if there's better name to suggest. Section 2.4 I don't know if it's worth saying anything that would remind recipients of their (non-?)obligation to accept time values that correspond to leap seconds, but IIRC we've seen cases in the past of software that chokes when presented with leap-second timestamps. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
