- gtld-tech - lists.icann.org

RDAP Features Missing from the Draft Profile Related to Current Policy Initiatives
by Hollenbeck, Scott Oct. 13, 2015

Oct. 13, 2015

Others have shared comments on the RDAP features described in the draft operational profile. I'd like to address features that aren't mentioned in the profile that could help address known operational issues with WHOIS. At least some of these should be given serious consideration in order to take advantage of the opportunity we have to address WHOIS issues as part of a transition to RDAP. In RFC 7482 I described a number of issues with the WHOIS protocol that RDAP was designed to address, including: o lack of standardized command structures; o lack of standardized output and error structures; o lack of support for internationalization and localization; and o lack of support for user identification, authentication, and access control. The profile addresses the need for standardized command structures, output structures, and error structures. It is incomplete in terms of support for internationalization/localization, user identification, authentication, and access control. There are a number of active WHOIS-related policy efforts that can produce RDAP implementation requirements. It's not unreasonable to require implementation changes to add new features as these efforts produce results, but I'd like to avoid having to undo or remove features driven by policies that may be in conflict with the current profile proposal. Examples: Expert Working Group on gTLD Directory Services (EWG) https://community.icann.org/pages/viewpage.action?pageId=40175189 The EWG (of which I was a member) produced a lengthy final report that includes a number of recommendations that were intended to address many of the issues associated with WHOIS. The final report included a number of recommendations focused on data privacy. As-is, the profile perpetuates the WHOIS "all data available to everyone" policy. I'd very much prefer to start with a more limited approach to data access that can be broadened as we decide how best to implement the RDAP features that provide identification, authentication, authorization, and access control security services. Thick WHOIS: http://gnso.icann.org/en/group-activities/active/thick-whois The profile describes a number of features that assume implementation of a "thick" registry. Two large top-level domain registries (.com and .net) are currently "thin" registries. There's still work to be done to determine how best to implement RDAP as the thick vs. thin policy discussion evolves. I would not want to be required to implement thick WHOIS knowing that there is a looming RDAP transition requirement. I am also a little concerned about the possibility of being required to implement thick RDAP without a thorough understanding of how it works in the evolving world of laws focused on protecting personally identifiable information (PII). It would be helpful if the profile included proposed implementation requirements for thin registries. WHOIS Policy Review Team https://community.icann.org/display/whoisreview/WHOIS+Policy+Review+Team This team published its final report in May 2012. Among other things, the recommendations documented in the report address data accuracy and internationalized domain names (IDNs) and internationalized registration data. If we assume that issues with data accuracy are at least somewhat associated with current WHOIS requirements for public disclosure of PII, it may be wise to consider inclusion of RDAP security services that can be used to protect against unauthorized disclosure of PII. Draft Final Report from the Expert Working Group on Internationalized Registration Data https://gnso.icann.org/en/issues/ird/ird-draft-final-10mar15-en.pdf The profile includes provisions for the representation of IDNs as either A-labels or U-Labels. It doesn't describe requirements to return responses containing internationalized registration data. Noting that internationalized registration data is referenced in Appendix E, it would be helpful to note that such requirements are being deferred (assuming that they are indeed being deferred and were not inadvertently omitted). Scott

1 0

Verisign Engineering Comments Re: Draft RDAP Operational Profile for gTLD Registries and Registrars
by Hollenbeck, Scott Oct. 12, 2015

Oct. 12, 2015

The Verisign Engineering team that is responsible for implementing RDAP in our production environment has reviewed the draft operational profile. Their comments are included below. Scott ---------- Verisign has read the proposed RDAP Profile and we have comments on the following sections. In addition to the commentary on the items addressed in the profile, we wish to express our hope that the profile will be expanded to address authentication and authorization. Merely replacing existing port43 WHOIS with JSON-formatted data misses an opportunity to improve upon deficiencies in WHOIS. Respectfully, Verisign Follow-up to publication of ICANN's RDAP profile: 1.3.2: "The RDAP service MUST be provided only over HTTPS. The TLS certificate used for the RDAP service must be issued by a Certificate Authority (CA) trusted by major browsers and mobile OS such as the ones listed in the Mozilla Included CA Certificate List (https://wiki.mozilla.org/CA:IncludedCAs) The CA, the certificate and its usage MUST follow the CAB Forum Baseline Requirements (https://cabforum.org/baseline-requirements-documents) The RDAP service MUST use the best practices for secure use of TLS as described in RFC7525 or its successors." Comment: The above seem to be guidelines missing specifics. Is the certificate used by the RDAP service domain-validated or organization-validated? What ciphers should be supported? 1.3.4/1.3: "RDAP extensions, if used, MUST be registered in the IANA's RDAP Extensions registry (https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml) as defined in RFC7480. Deployment of RDAP extensions in gTLD Registries operated under agreement with ICANN, are subject to approval by ICANN via the RSEP process." Comment: The above is contrary to the implication from Sec 2.1 of RFC 7483 that "Clients of these JSON responses SHOULD ignore unrecognized JSON members in responses" - this definitely indicates that unregistered or new RDAP extensions may be used without being formally registered as an RDAP extension. We believe it appropriate to change the "MUST" in this section to "SHOULD". One benefit of defining the RDAP protocol is extensibility, and this profile shouldn't be unnecessarily restrictive. 1.4.3: "The case (i.e. uppercase and lowercase) of the data returned in RDAP responses MUST be preserved." Comment: It is unclear where the original input of the data returned in RDAP response was derived from - are we referring to the EPP data sent by registrars during registration or is the reference specifically for the capitalization mode used in the RDAP request. Why is this a requirement? 1.4.12: "RDAP responses MUST contain the last update date and time of the database used to generate the RDAP responses (RDAP database in this document) when an RFC defining this capability has been published. The RDAP database MUST include the registration data in the SRS database. The RDAP database must be updated within the allowed Service Level Requirement (SLR) (e.g. RDDS update time, ≤ 60 minutes). In a case where the contracted party is querying its SRS database directly, and therefore, using real-time data, this date and time will show the timestamp of the response to the query." Comment: We suggest that this be specified with a new field such as "icann_db_timestamp" encoded in the top-level object instead of defining a new event. 1.5.2: "The top-level domain object in the RDAP response MUST contain the U-label format of the domain in the unicodeName member [RFC7483], only if the domain name is an IDN." Comment: For an IDN domain name, specifying 2 different encodings in the same response seems redundant and leads to wasted bandwidth. Why is the a-label not sufficient? 1.5.8: "The domain object in the RDAP response MUST contain entities with the following roles, exactly one entity per role MUST be present in the response, each of them with a handle" Comment: This seems to suggest that a prerequisite for implementing RDAP is that the top-level domain (TLD) contain "thick" registry data. That would seem to preclude the deployment of .COM and .NET RDAP services till the registries are fully converted into "thick" registries. 1.5.14: "The domain object in the RDAP response MUST contain the following events:...An event with the expiration date of the Registrar, when a RFC defining this capability has been published" Comment: Is this meant to apply to registries? Domains at the registry typically auto-renew so they usually do not expire. If it does not apply to registries, this requirement should be moved to Section 3. If it does apply, this implies that a change in the EPP specification is required before the registry can derive this information for the domain. 1.5.17: "If allocated variant domain names exist for the queried domain name or if the domain name is an allocated variant domain name, the domain object in the RDAP response MUST contain a variants member [RFC7483]. The variants relation member MUST contain valid variant relation types as defined in the IANA's RDAP JSON Values registry. If the queried domain name is an allocated variant name, the original name MUST be included in the variants member." Comment: The first sentence of this item is unclear. Is the intent that a queried (and allocated) domain having possible variants provide *allocated* variants in the reply? Is the intent that queried names that are variants of an allocated domains produce a domain response with the allocated name as the domain object? The expected behavior should be clarified through examples. 1.5.18: "A domain name RDAP response MUST contain a remarks member with a title "EPP Status Codes", a description containing the string "For more information on domain status codes, please visit https://icann.org/epp" and a links member with the https://icann.org/epp URL." Comment: Should the status definitions be defined on a top-level object instead of using a "remarks" member? This could be handled much like the suggestion for 1.4.12, with an "icann_" prefix. 1.5.19: "The domain object in the RDAP response MUST contain a secureDNS member [RFC7483] including at least a delegationSigned element. Other elements (e.g. dsData, maxSigLife) of the secureDNS member MUST be included, if the domain name is signed and the elements are known by the server." Comment: The above is ambiguous - what exactly is meant by "known to the server"? This phrasing should be changed to "stored by the registry or registrar". 2.1: "Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities. Entities MUST be searchable by name search pattern as defined in RFC7482 section 3.2.3 in order to allow for searches by contact name or address. Boolean search capabilities (AND, OR) MUST be supported, when a RFC defining this capability has been published." Comment: We believe the purpose of this profile is to define expected behaviors of a complaint RDAP implementation for registries and registrars. It should not mandate compliance with some future, yet-to-be defined RFC and, therefore, the reference to boolean search should be removed. 2.3: "If a Registry supports multiple host objects with the same name, the Registry MUST support the capability to respond with a set of host objects in response to a name server lookup, when an RFC defining this capability has been published." Comment: As with 2.1, the purpose of the profile is to define expectations of conforming registries and registrars, not mandate compliance with undefined requirements. 2.4: "The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL of the queried domain object." This requirement is unclear. A domain lookup response will contain a domain object, potentially having links to other objects, including a link back to the domain object itself. The "rel" element is optional in the RFC for good reason; if it's to be required, then the value should be either "self" or "related" depending on whether the link is back to the queried domain object, or to a related object. Regardless, the mandate for such an element is unnecessary and therefore questionable. 2.9.1: "Entity RDAP queries (registrar queries): The returned RDAP response MUST be an entity with registrar role, with a handle (IANA Registrar ID) and valid elements fn, adr, tel, email. Registrar object lookup using an entity search on the fn element MUST be supported." The above implies that Entities are only registrars which conflicts with the RFC definition of Entities as Contacts AND Registrars. It is also not stated that a Registry may only provide information on Registrars that are contracted to resell domains of a specific TLD - this list is not necessarily exhaustive or representative of a list of all registrars - that information is stored with ICANN and IANA.

1 0

Re: [gtld-tech] [eppext] RDAP server of the registry
by Hollenbeck, Scott Oct. 9, 2015

Oct. 9, 2015

> -----Original Message----- > From: Greg Aaron [mailto:greg@illumintel.com] > Sent: Wednesday, October 07, 2015 11:27 AM > To: 'Gustavo Lozano'; 'Patrik Wallström'; Hollenbeck, Scott > Cc: gtld-tech(a)icann.org; eppext(a)ietf.org > Subject: RE: [gtld-tech] [eppext] RDAP server of the registry > > Gustavo correctly notes some important things --ICANN has contractual > requirements that tell registries and registrars what data they MUST > deliver > (currently via the WHOIS protocol), and ICANN is now working on how > that > data should be delivered via RDAP. Whatever document is created is > going > to be binding on registries and registrars. As per the 2013 RAA, once > RDAP > spec is mature "ICANN reserves the right to specify alternative formats > and > protocols, and upon such specification, the Registrar will implement > such > alternative specification as soon as reasonably practicable." The new > gTLD > registry agreements contain similar. > > RDAP's supposedly been designed to deliver what ICANN might require of > its > registrars and registries. If so, we are embarking on an exercise in > implementation in the gTLD world, with ICANN as the policy authority. > BCPs > for ccTLDs etc. might be nice, but seem like a distraction from the > immediate task at hand. Thinking about the best way to implement RDAP is no distraction. It will help reduce implementation costs *and* ensure that we deliver the best technical solutions in the long run. Remember, the agreements you mentioned above were written before the RDAP specifications were completed. There are features in RDAP that aren't mentioned in the agreements or the proposed profile. There are ongoing policy efforts in ICANN that *will* have an impact on RDAP implementers. I'm suggesting that we need to take a big picture approach before we're told to implement current WHOIS operational requirements with RDAP as a transport. That just makes RDAP part of the ongoing problems. Here's one example: data privacy. WHOIS can't do it, but RDAP can, and it's not part of the profile. Shouldn't it be part of the discussion? Why shouldn't we think about it before we perpetuate a WHOIS issue that becomes an RDAP issue? > The implementation requirements should certainly be well-thought-out, > should > receive input (and hopefully collegial buy-in) from the parties who > will > have to make it work, and should be clearly documented. As Gustavo > says, > ICANN has process to deliver that. Requiring "community consensus" > about > the contents, as Scott suggested, is a different and higher standard > from > what has been agreed to in the ICANN contracts. I'm not a lawyer, so contracts aren't my area of expertise. I do, however, know something about software engineering and the costs associated with software development. Knowing that the new gTLD RA says this: "Registry Operator shall implement a new standard supporting access to domain name registration data ... if ... its implementation is commercially reasonable in the context of the overall operation of the registry." How does one determine that which is "commercially reasonable"? We know that there are policy development efforts happening in parallel that will produce additional implementation requirements. Requirements that conflict with the profile (changes in data privacy requirements, for example) will increase implementation costs, and "commercially reasonable" becomes a point of contention. The process I've described should help mitigate that risk. It's not a higher standard, it's a method that can be used to help confirm that the "commercially reasonable" requirement has been met. Scott

2 1

RDAP server of the registry
by Gustavo Lozano Oct. 9, 2015

Oct. 9, 2015

Hello, The first version of the ICANN gTLD profile was published days ago, (see: http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html) this document describes basic parameters and objects to be implemented by ICANN-contracted parties. The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date). The gTLD profile support the same functionality with the following mechanism: The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object. Questions for this group: * What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D? Regards, Gustavo Lozano ICANN

7 14

FW: New Version Notification for draft-lozano-rdap-gtld-whois-additional-events-00.txt
by Gustavo Lozano Oct. 4, 2015

Oct. 4, 2015

Hello, [Apologies if you received this email multiple times] I published draft-lozano-rdap-gtld-whois-additional-events-00.txt (see http://www.ietf.org/id/draft-lozano-rdap-gtld-whois-additional-events-00.tx t) that tries to solve open issues 2 and 5 identified in the gTLD RDAP profile (see http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html) The gTLD RDAP profile describes which features, basic parameters and objects will need to be implemented by ICANN-contracted parties in order to support analogous functionality to gTLD Whois service. Your feedback is appreciated. Regards, Gustavo Lozano ICANN On 10/4/15, 11:20, "internet-drafts(a)ietf.org" <internet-drafts(a)ietf.org> wrote: > >A new version of I-D, >draft-lozano-rdap-gtld-whois-additional-events-00.txt >has been successfully submitted by Gustavo Lozano and posted to the >IETF repository. > >Name: draft-lozano-rdap-gtld-whois-additional-events >Revision: 00 >Title: Additional RDAP events to support the gTLD Whois output >Document date: 2015-10-04 >Group: Individual Submission >Pages: 4 >URL: >https://www.ietf.org/internet-drafts/draft-lozano-rdap-gtld-whois-addition >al-events-00.txt >Status: >https://datatracker.ietf.org/doc/draft-lozano-rdap-gtld-whois-additional-e >vents/ >Htmlized: >https://tools.ietf.org/html/draft-lozano-rdap-gtld-whois-additional-events >-00 > > >Abstract: > This document adds two event action types to the IANA RDAP JSON > Values registry, defined in [RFC7483], which are required to map two > fields from the gTLD Whois output into the RDAP response. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat >

1 0

Definition of "% of DNS Service Availability" used in Registrant Survey
by Chris Baker Sept. 28, 2015

Sept. 28, 2015

Hello, I was reading the recent ICANN Releases Phase One Registrant Survey on the Domain Name Landscape and saw mention in the metrics section a "% of DNS Service Availability." I was wondering if there was a definition for this measurement available? Possibly some details about how data is collected where it is collected from? ... etc Please let me know if you have any questions, Thank you for your time, CBaker Reference: "% of DNS Service Availability ( Present SLA is 100% )" Category - Trust in http://newgtlds.icann.org/en/reviews/cct/iag-metrics-final-recs-26sep14-en.…

2 1

About repository identifier
by liangchenguang＠zdns.cn Sept. 15, 2015

Sept. 15, 2015

Dear Sir or Madam, I had to write e-mail to iana,but did not receive a reply.You acknowledge that i send to her acceptance? Mail content: We want to apply for the repository identifier below , among which "zdns" is for registrar and the other 22 IDs are all TLDs. Please check whether they are correct or not. Change Controller ID: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Name: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Thank you. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190

1 0

About repository identifier
by liangchenguang＠zdns.cn Sept. 8, 2015

Sept. 8, 2015

Dear Sir or Madam, We want to apply for the repository identifier below , among which "zdns" is for registrar and the other 22 IDs are all TLDs. Please check whether they are correct or not. Change Controller ID: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Name: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Thank you. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190

1 0

Fw: Re: About repository identifier
by liangchenguang＠zdns.cn Sept. 7, 2015

Sept. 7, 2015

FYI. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190 From: liangchenguang(a)zdns.cn Date: 2015-09-07 17:00 To: Kuhl CC: 高雷; gtld-tech; os_zhangjun Subject: Re: Re: [gtld-tech] About repository identifier Dear Sir or Madam, Sorry, the information in the last email is wrong, this is the update information. Change Controller ID: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Name: zdns wang top show citic shop ren sohu bagua wangzhi wangzhan zhongxin yule wangdian sb zhaopin woaini shishang canting cishan sc xinwen jituan Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Thank you. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190 From: liangchenguang(a)zdns.cn Date: 2015-09-07 16:28 To: Kuhl CC: 高雷; gtld-tech; os_zhangjun Subject: Re: Re: [gtld-tech] About repository identifier Dear Sir or Madam, Thank you for your response. We want to apply for the repository identifier below , among which "zdns" is for registrar and the other 22 IDs are all TLDs. Please check whether they are correct or not. Change Controller ID: zdns wang top show citic shop ren sohu &#x7f51 &#x5740 &#x7f51 &#x7ad9 &#x7f51 &#x5e97 &#x516b &#x5366 &#x4e2d &#x4fe1 &#x5a31 &#x4e50 &#x5546 &#x6807 &#x62db &#x8058 &#x6211 &#x7231 &#x4f60 &#x65f6 &#x5c1a &#x9910 &#x5385 &#x6148 &#x5584 &#x5546 &#x57ce &#x65b0 &#x95fb &#x96c6 &#x56e2 Change Controller Name: zdns wang top show citic shop ren sohu &#x7f51 &#x5740 &#x7f51 &#x7ad9 &#x7f51 &#x5e97 &#x516b &#x5366 &#x4e2d &#x4fe1 &#x5a31 &#x4e50 &#x5546 &#x6807 &#x62db &#x8058 &#x6211 &#x7231 &#x4f60 &#x65f6 &#x5c1a &#x9910 &#x5385 &#x6148 &#x5584 &#x5546 &#x57ce &#x65b0 &#x95fb &#x96c6 &#x56e2 Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Thank you. 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190 From: Rubens Kuhl Date: 2015-09-07 11:33 To: liangchenguang(a)zdns.cn CC: gtld-tech; 高雷 Subject: Re: [gtld-tech] About repository identifier On Sep 6, 2015, at 10:12 PM, liangchenguang(a)zdns.cn wrote: Dear Sir or Madam, A shall be part of the ROID and the identifier shall be registered by IANA. What dose the Controller Email and Reference/Contact Email mean? Change Controller Email and Reference/Contact Email Is the information below right?we want to ues "zdns" as our repository identifier for all our tlds. Although it's not what ICANN prefers, I don't see many options for IDN TLDs... they would prefer the TLD itself due to the possibility a business transaction or a back-end change. Also, RFCs are not totally clear where RoIDs must be unique between domains and contacts, but just in case you could use ZDNHDL and ZDNSDOM, ZDNSHDL and ZDNS etc. Change Controller ID: #x007A #x0064 #x006E #x0073 Change Controlled ID doesn't need to be expressed in this notation, although it could be ZDNS Change Controller Name:#x007A #x0064 #x006E #x0073 Same as above. Reference/Contact ID:#x007A #x0064 #x006E #x0073 This could a person's name represented like Liang_Chen_Guang or a role name Back_End_Registry_Admin Reference/Contact Name:#x007A #x0064 #x006E #x0073 This could Liang Chen Guang, Back End Registry Admin Do we need to provide other information to prove our identity? There is no such thing. Obama could use ZDNS as RoID unique suffix if he registers first... Argentinians might not like the AusRegistry registered AR, but sounds like a good suffix since AusRegistry contains more than 8 letters. Some registries clearly went for random IDs (Q9JYB4C, for instance). Rubens

1 0

About repository identifier
by liangchenguang＠zdns.cn Sept. 7, 2015

Sept. 7, 2015

Dear Sir or Madam, A shall be part of the ROID and the identifier shall be registered by IANA. What dose the Controller Email and Reference/Contact Email mean? Change Controller Email and Reference/Contact Email Is the information below right?we want to ues "zdns" as our repository identifier for all our tlds.Change Controller ID: #x007A #x0064 #x006E #x0073Change Controller Name:#x007A #x0064 #x006E #x0073Reference/Contact ID:#x007A #x0064 #x006E #x0073 Reference/Contact Name:#x007A #x0064 #x006E #x0073 Do we need to provide other information to prove our identity? 梁晨光产品经理互联网域名系统北京市工程研究中心有限公司座机：010-58813244 手机：13811479777 邮件：liangchenguang(a)zdns.cn 网址：www.zdns.cn 地址：北京市海淀区中关村南4街4号中国科学院软件园1号楼邮编：100190

3 4