Note: This ballot was opened for revision 14 and is now closed.

(Alexey Melnikov) Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Thank you for addressing my comments on version 14.

Alissa Cooper (was Discuss) No Objection

Thank you for addressing my DISCUSS questions. Original COMMENT is below.

= Section 1.1 =

Please use the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

= Section 2=

s/To avoid conflict, the identifiers for these MUST be a URL with a domain owned by the vendor./To avoid conflict, an identifier for a vendor-specific extension MUST be a URL with a domain owned by the vendor./

= Section 8 =

Depending on the outcome of the discussion related to the DISCUSS point above, I think it would be appropriate to describe or even normatively require client ID construction such that client IDs are opaque and can change over time at the client's choosing.

(Spencer Dawkins) No Objection

Benjamin Kaduk (was Discuss) No Objection

Thank you for addressing my DISCUSS (and COMMENT!) points!

(Suresh Krishnan) No Objection

Warren Kumari No Objection

"Trusting AD"

(Mirja Kühlewind) (was Discuss, No Objection) No Objection

Thanks for considering my discuss!

Thanks for addressing the TSV-ART comments (and thanks to Allison for the review)!

----------------------------
Old comment (for the record):
----------------------------
One question regarding sec 9.4.1.:
How long should IANA wait for comments before the registration is performed?

(Eric Rescorla) (was No Record, Discuss) No Objection

Thank you for addressing my DISCUSS

Alvaro Retana No Objection

(Adam Roach) (was Discuss) No Objection

Thanks for addressing my discuss and comment points.

Martin Vigoureux No Objection