vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)
draft-hollenbeck-vcarddav-icann-rdap-extensions-01
Yes
(Adam Roach)
(Alexey Melnikov)
(Barry Leiba)
No Objection
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Suresh Krishnan)
Note: This ballot was opened for revision 00 and is now closed.
Roman Danyliw
No Objection
Comment
(2019-04-12)
Sent for earlier
Thank you for addressing my Comment.
Warren Kumari
No Objection
Comment
(2019-04-08 for -00)
Not sent
Just a small nit: While reading this I kept stumbling over "Namespace: " -- it really looks like the authors forgot to fill in this section, and I had to go look at the Registry and RFC 6350 to confirm that this is an empty value. As a courtesy to future readers I think it would be helpful to include a sentence saying that the Namespace: attributes are intentionally blank (kind of like "This page intentionally left blank." :-))
Adam Roach Former IESG member
Yes
Yes
(for -00)
Not sent
Alexey Melnikov Former IESG member
Yes
Yes
(for -00)
Unknown
Barry Leiba Former IESG member
Yes
Yes
(for -00)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(2019-04-10 for -00)
Sent
Section 5 says: "The CONTACT-URI value is purposefully intended to be a publicly visible contact reference, and as such, it cannot require privacy protection." The publication of the URI itself makes sense, but this makes it sound as if the URI scheme chosen has no privacy implications. Surely if the point of supporting this is to protect people's privacy, than an HTTPS CONTACT-URI is preferable to an HTTP one. I would suggest modifying this text to make that more clear.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -00)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2019-04-11 for -00)
Sent
Two addresses are used in the examples for the CC parameter; the first (TYPE=work) seems to be a real address (a Verisign office) whereas the second (TYPE=home) appears to be dummy data. I don't know if there's a desire or need to make the examples consistently real or consistently fake (though putting someone's real home address in an RFC is perhaps unwise).
Deborah Brungard Former IESG member
No Objection
No Objection
(for -00)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -00)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2019-04-02 for -00)
Sent
Looking at RFC6350, was this step followed: "The registration procedure begins when a completed registration template, defined in the sections below, is sent to vcarddav@ietf.org and iana@iana.org." ?
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -00)
Not sent