Discovering Provisioning Domain Names and Data
Note: This ballot was opened for revision 09 and is now closed.
(Suresh Krishnan) Yes
Warren Kumari Yes
Comment (2020-01-21 for -10)
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.
(Mirja Kühlewind) Yes
Comment (2020-01-20 for -10)
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...
Deborah Brungard No Objection
Alissa Cooper (was Discuss) No Objection
Comment (2020-01-22 for -10)
Thanks for addressing my ballot comments.
Roman Danyliw (was Discuss) No Objection
Thanks for addressing my COMMENT and DISCUSS items.
Benjamin Kaduk (was Discuss) No Objection
Thank you for addressing my Discuss points!
Barry Leiba No Objection
Comment (2020-01-16 for -10)
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.
(Alexey Melnikov) No Objection
Comment (2020-01-17 for -10)
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.
Alvaro Retana No Objection
Comment (2020-01-21 for -10)
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.]
(Adam Roach) (was Discuss) No Objection
Thanks for addressing my discuss and comment points!
Martin Vigoureux No Objection
Magnus Westerlund No Objection
Éric Vyncke Recuse
Comment (2020-01-03 for -09)
I am a co-author of this document ;-)