Skip to main content

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

Yes

(Suresh Krishnan)

No Objection

(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)

Recuse


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

Warren Kumari
Yes
Comment (2020-01-21 for -10) Sent
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.
Roman Danyliw
(was Discuss) No Objection
Comment (2020-02-03) Sent for earlier
Thanks for addressing my COMMENT and DISCUSS items.
Éric Vyncke
Recuse
Comment (2020-01-03 for -09) Not sent
I am a co-author of this document ;-)
Mirja Kühlewind Former IESG member
Yes
Yes (2020-01-20 for -10) Sent
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...
Suresh Krishnan Former IESG member
Yes
Yes (for -09) Unknown

                            
Adam Roach Former IESG member
(was Discuss) No Objection
No Objection (2020-02-03) Sent
Thanks for addressing my discuss and comment points!
Alexey Melnikov Former IESG member
No Objection
No Objection (2020-01-17 for -10) Sent
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.
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2020-01-22 for -10) Sent
Thanks for addressing my ballot comments.
Alvaro Retana Former IESG member
No Objection
No Objection (2020-01-21 for -10) Sent
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.]
Barry Leiba Former IESG member
No Objection
No Objection (2020-01-16 for -10) Sent
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.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-02-03) Sent
Thank you for addressing my Discuss points!
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -10) Not sent