Ballot for draft-ietf-intarea-provisioning-domains
Yes
No Objection
Recuse
Note: This ballot was opened for revision 09 and is now closed.
Thank you for writing such a useful (and readable!) document; the amount of Operational Considerations (and examples) warms my heart :-) I was going to point out the "an hostile network" nit, but Barry beat me to it... Thanks to Tim Chown for his OpsDir review, and the authors for addressing the comments.
Thanks for addressing my COMMENT and DISCUSS items.
I am a co-author of this document ;-)
Thanks for this well-written document (and thanks Martin for the TSV-ART review)! I have no real issues but two quick questions: 1) In Sec 3.4 (and somewhere earlier as well), you say: "In case multiple PvD Options are found in a given RA, hosts MUST ignore all but the first PvD Option." Why is that restriction actually needed? I mean given you can send multiple RA from the same source address with each an PvD Option with either different of the same ID, would it be so bad to have multiple PvD Option in the same RA? 2) As this document refers to draft-kline-mif-mpvd-api-reqs, is there any plan to update and publish this doc? However, this draft anyway "only" talk about API requirement, but I guess some network signalling would also be needed...? Is there any additional work? P.S.: The shepherd writ-up seems a bit out-dated...
Thanks for addressing my discuss and comment points!
This is a well written document, but I have a small set of issues I would like to discuss: 4.4. Detecting misconfiguration and misuse When a host retrieves the PvD Additional Information, it MUST verify that the TLS server certificate is valid for the performed request (e.g., that the Subject Alternative Name is equal to the PvD ID expressed as an FQDN). The last sentence is not right: you should say “one of Subject Alternative Names is equal to ... “ because a server certificate can have multiple Subject Alternative Names. 5.4. Providing Additional Information to PvD-Aware Hosts This section is using HTTP/2 syntax for requests and responses, but HTTP 2 RFC is not listed as a reference.
Thanks for addressing my ballot comments.
I believe that rfc7556 must be a Normative reference: it defines PvDs, which are the base for this specification. [I am not balloting DISCUSS because this should be a fairly simple issue to address, and I trust the Responsible AD to do the right thing.]
Nit in Section 6: “an hostile network access provider”. In Section 8.4, please add the “Fragment identifier considerations” entry in the template, as required by RFC 6838.
Thank you for addressing my Discuss points!