On 8/10/23 1:40 AM, Murray Kucherawy via Datatracker wrote:
Murray Kucherawy has entered the following ballot position for
draft-ietf-uta-rfc6125bis-14: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Sadly, I support Lars' Worst DISCUSS Ever.
OBE:
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/108
Thanks for doing the work here. It's quite well done.
Much appreciated.
Just a couple of comments:
In Section 2, I find it weird to use SHOULD and MUST language to establish BCP
14 style interoperability requirements on future documents.
One could argue that this document (which forms something of a companion
to RFC 9325) ought to be a BCP. But that ship has sailed.
Assuming that you mean Section 3, I'd note that the text about designing
application protocols is phrased as a hypothetical imperative: "if your
application protocol specification cites this document, then you need to
proceed as follows"; but nothing stipulates that one must cite this
document.
We had similar text in RFC 6125, although presented as a checklist, not
as normative requirements and recommendations; perhaps that approach
would be more palatable?
Section 1.5 defines "delegated domain" but doesn't use that term anywhere.
Good catch, will fix.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
