Éric Vyncke 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: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-uta-rfc6125bis-14 Thank you for the work put into this document. I find this document update useful ***BUT*** it lacks the support of the new SVCB (draft-ietf-dnsop-svcb-https)... May I recommend that this document is sent back to the WG in order to incorporate the SCVB (it is very similar to SRV IMHO)? I appreciate that the SVCB started in a different WG hence the disconnect even if some authors of the two I-Ds have the same affiliation ;-) I added the SVCB authors in copy to this ballot, just in case. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Orie Steele for the shepherd's detailed write-up including the WG consensus, *but it lacks* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## Component or label ? The text uses terms like `component of a domain name` while RFC 8499 (DNS terminology) would prefer to use `label of a domain name`. Most parts of the document correctly use 'labels' but there are some use of 'component'. ## Section 1.4.2 s/Certificates representing client identities other than as described above, such as rfc822Name, are beyond the scope of this document/Certificates representing client identities, such as rfc822Name, other than as described above are beyond the scope of this document/ to simplify the parsing ? # NITS ## Section 1.4.2 `for our purposes we care`, RFCs usually do not use a personal voice. But this is a matter of taste. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
