Discovering Provisioning Domain Names and Data
draft-ietf-intarea-provisioning-domains-11

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

Comment (2020-02-03)
No email
send info
Thanks for addressing my COMMENT and DISCUSS items.

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-02-03)
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

Comment (2020-02-03)
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)
No email
send info
I am a co-author of this document ;-)