Re: [regext] FW: Proposal to remove RDAP from the Thick Whois CL&D Policy (was Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration)

< I'm looking at the new TLD registry agreement. Could you point out the part where it says they can't do that? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly

[regext] Google open source Nomulus registry software

Google's blog today says that they've put their Nomulus registry software on Github. It runs in their App Engine environment and is mostly written in Java blog: https://opensource.googleblog.com/ source code: https://github.com/google/nomulus Regards, John Levine, jo...@taugh.com, Taughannoc

Re: [regext] RDAP lookup queries for reserved or unassignable domains

There are lots of reasons an RDAP server might not have info about a domain, e.g., you ask it about a TLD it doesn't handle, and there's no reason to assume that an RDAP server would know anything about an unknown domain's availability. I would think anybody doing reselling would have the availa

Re: [regext] first reason not to do EPP and DNAME records?

Already replied but see This answer just confirms my main point. Whether to put DNAMEs in the root is primarily a policy question. Even if you thought it was a good idea (which I still don't, see next message) there is

Re: [regext] EPP and DNAME records, second reason not to do it

On Mon, 15 Jan 2018, Stephane Bortzmeyer wrote: Since you can get the effect of a DNAME in the root zone by putting a DNAME at the apex of a TLD as Taiwan has done, No, the goal here is to have no NS delegation (for reasons explained in RFC 7535). So, this cannot work. I don't understand this

Re: [regext] first reason not to do EPP and DNAME records?

for which I've seen no demand. R's, John Matthew Pounsett schrieb am Mo., 15. Jan. 2018 um 20:10 Uhr: On 15 January 2018 at 13:09, John R Levine wrote: Already replied but see <https://mailarchive.ietf.org/arch/msg/dnsop/lGdwGFO58iJ_dYYM9UR87Er9F5c This answer

Re: [regext] EPP and DNAME records, second reason not to do it

in the root (add DNSSEC to taste): ... evil. NS ns1.evilsrv.wtf. evil. NS ns2.evilsrv.wtf. Does not work for the use case of draft-bortzmeyer-dname-root since you cannot delegate new names to the old AS 112 (see RFC 7535 for the rationale). Hi, Stephane. Not to belabor the obvious, but this d

Re: [regext] EPP and DNAME records, how to do it

OK, I see your point. Documented in an appendix in draft-bortzmeyer-dname-root-05.txt as a possible alternative. Thanks. Now my question is that since we have a workable approach that does not require a new EPP extension, and since (in my opinion at least) DNAMEs as 2LDs are an actively bad i

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

The 2119 words MUST and MAY are used to signify requirements; although that does imply interoperability as well. This statement is associated with making the verification code functional, since the verification code represents a signed and typed verification pointer, it must point to something

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

On Wed, 2 Jan 2019, Adam Roach wrote: I don't understand why.  The code is a signed token.  Imagine the registry goes back to the signer asks about token 123-foo666 and the answer is "We're the Ministry, we signed it, of course it's valid.  The details are secret." While that would not be m

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

#x27;s confusing. As you can see, it confused me. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/2/19, 3:56 PM, "regext on behalf of John R Levine" wrote: On We

Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

If a registrant is living in the EU, or a EU citizen, they would be covered by GDPR protections, so its impact is quite significant. As you know, ICANN and the industry is seeking to find one compliance model. I do not see why we would deviate from that. I pretty sure nothing has changed sinc

Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

The final decision on this is planned to be made in April: https://community.icann.org/pages/viewpage.action?pageId=88574682&preview=/88574682/102142026/EPDP_summary_timeline_20190116.pdf Not that it's relevant here, but I am a member of the ICANN SSAC subcommittee that supports the SSAC reps