Ben Campbell has entered the following ballot position for
draft-ietf-regext-launchphase-06: 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-regext-launchphase/



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

Substantive Comments:

-2.2, 2nd to last paragraph: "Both the Validator Identifier and the Issuer ot
Identifier used MUST be unique."
At what scope must they be unique? Can you offer guidance on how to ensure
uniqueness?

-2.2, last paragraph:
I don't understand what is meant by this paragraph. Please elaborate.

-2.4, paragraph after definitions: "The OPTIONAL "lang" element MAY be
present..." Why is this only a MAY? Is it really reasonable to leave out the
language tag for non-English languages?

-2.4, 3rd to last paragraph:
Why does the custom status value exist if the server should not use it? Are
there cases where a client uses it?

-3.4, 2nd paragraph, first sentence: Is a client expected to know in advance
whether the server supports launch applications? If so, how?

Editorial Comments:

- There are lowercase instances of 2119 keywords. I assume those are not meant
as normative keywords. If so, please consider using the boilerplate from RFC
8174 instead of 2119.

- General: I urge a pass to check the use of 2119/8174 keywords. I think there
may be some instances where the author typed words in upper case from habit
where the keywords don't make sense.  I point out some of these below, but I
suspect I did not get all of them.

-1-1, 3rd paragraph: "REQUIRED" seems like a statement of fact.

-2.2, first sentence: s/that/which

-2.3, definitions: Please consider avoiding 2119 keywords in definitions? As
written, they read more like statements of fact than normative requirements.
(Please feel free to ignore this, since it is really a style issue.) Also,
please try to add white space between hanging indent list entries. They are
hard to read when run together. (Same for other definition sections.)

-2.3, last paragraph: Please avoid 2119 keywords in examples.

-2.3.1: The "MUST" and "MAY" seem like statements-of-fact.

-2.4, 2nd to last paragraph: 2119 keywords in examples.

-2.6.1, first paragraph: The "that" might should be a "which". But it's not
clear to me whether the word is intended to constrain which codemark elements
are being discussed ("that") , or to just mention that codemark elements are
used in those models. ("which")


_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext

Reply via email to