Many thanks to Ulrich Wisser for taking these notes for us.
I have already posted these to the datatracker, however folks should
please review them for accuracy and completeness. If there are any
suggestions I can upload a revised version of the minutes.
Thanks to all for an excellent
Regarding the drafts position of "the authorization information MUST NOT
be stored by the registrar."
I agree that registrars will need the ability to store the password for a
request to transfer in a domain in some situations (bulk transfers, network
outages, registry maintence etc.).
I believe a proper response to Stephane and Peters stated concerns in
privacy, is for a "Privacy in RDAP" document to be written which
becomes a reference back into the patterns like reverse search. I do
not believe we can expect to go forward without reverse-index lookup:
it is a fundamental tool
Capturing/elaborating on my comments at the mic the WG meeting in Montreal…
Â
Related to these three drafts:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
On Fri, Jul 26, 2019 at 4:06 AM Gavin Brown wrote:
>
> On 25 Jul 2019, at 22:43, Andrew Newton wrote:
> > In other words, who is NOT doing RDAP because of jCard? Are there any
> > registries willing to step up and say they'll deploy RDAP if we move
> > to JSContact?
>
> I'm not too concerned
Roger,
Yes, registrars will be running RDAP servers and I did not intend to
minimize your efforts. But it is my understanding that registrars are
being compelled to do RDAP and therefore will be implementing jCard as
getting a jCard replacement will take some time.
I was really thinking of the
On 25 Jul 2019, at 22:43, Andrew Newton wrote:
> In other words, who is NOT doing RDAP because of jCard? Are there any
> registries willing to step up and say they'll deploy RDAP if we move
> to JSContact?
I'm not too concerned about jCard as a barrier to server deployment. I'm more
concerned
