Skip to main content

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