Re: [eppext] I-D Action: draft-zhou-eppext-contact-verification-00.txt

["Linlin Zhou" <[e-mail]>]

Hi James,

 

I assume that you mean SCP or HTTP.  Do you plan on submitting a draft that describes the protocol for transmitting the verification material for verification?

[Linlin] Yes, we are supposed to submit a draft. We are still in discussion.

 

Yes, but since the contact mapping does not have the concept of type, the verification extension will apply to all contacts independent of the domain to contact relationship.  The contact verification status has interplay with the domain status that could be clarified in the contact extension, the domain extension, or both.

[Linlin] The verification process is based on the contact id. I think maybe a contact status element in domain extension would be possible to reflect the relation.

 

For example, what happens to the domain if it references contacts (registrant, admin, tech, and billing) with the supported set of verification statuses on a domain create or domain update?

[Linlin] In our preliminary design, we would like to leave this part to the new draft.

 

Regards,

Linlin

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Gould, James
Sent: Tuesday, December 29, 2015 12:39 AM
To: Linlin Zhou
Cc: [e-mail]; lidaiming
Subject: Re: [eppext] I-D Action: draft-zhou-eppext-contact-verification-00.txt

 

Linlin, 

 

My feedback is included below.

 

We've considered this issue and found that BCP of HTTP API may be more proper. 

 

I assume that you mean SCP or HTTP.  Do you plan on submitting a draft that describes the protocol for transmitting the verification material for verification?  draft-xie-eppext-nv-mapping provides a mechanism to submit the verification material via EPP, which is the most straight forward mechanism.       

 

Actually only the registrant need to be verified according to the regulation in China.

 

 

Yes, but since the contact mapping does not have the concept of type, the verification extension will apply to all contacts independent of the domain to contact relationship.  The contact verification status has interplay with the domain status that could be clarified in the contact extension, the domain extension, or both.  

 

 

Yes, I think the poll command should be extented too.

 

draft-gould-change-poll can be used to extend the info response of the contact or domain to provide the client with the information associated with the server side verification change.

 

 

If only the registrant should be verified, I think a domain will not have different statuses contatcts.

 

Yes, the focus is on the registrant, but the registrant's contact verification status relationship with the domain status would be good to understand.  Also, the drafts should provide more detail into the relationship of the contact verification statuses of the other contact types (admin, tech, and billing).  This could be left to server policy, if the goal if for the drafts to be used more generically.  For example, what happens to the domain if it references contacts (registrant, admin, tech, and billing) with the supported set of verification statuses on a domain create or domain update?

 

>From my rough understanding, a extensible protocol should support multiple applicable profiles.

 

Do you intend on targeting these drafts to meet only the China verification rules or to meet a more general set of verification rules?  If you intend on just meeting the China verification rules, then you can add more specific text to describe the China verification policies, and if you intend on meeting a more general set of verification rules, you may want to consider including the concept of verification profiles.  

 

—

 

JG




James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com 

 

On Dec 24, 2015, at 4:31 AM, Linlin Zhou <[e-mail]> wrote:

 

Hi James,

Thanks for your feedback.

Regards,


  _____  


Linlin Zhou

 

From: Gould, James <mailto:[e-mail]> 

Date: 2015-12-23 23:52

To: Linlin Zhou <mailto:[e-mail]> 

CC: [e-mail]; lidaiming <mailto:[e-mail]> 

Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt

Linlin, 

 

Thanks of the quick reply, my feedback is included below.

 

—

 

JG


<BF09FAA4-32D8-46(12-24-13-34-16).png>

James Gould
Distinguished Engineer
[e-mail] <x-msg://8/[e-mail]> 

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com <http://verisigninc.com/> 

 

On Dec 22, 2015, at 2:07 AM, Linlin Zhou <[e-mail]> wrote:

 

Hi James,

Thanks for your review. I have following feedbacks about your questions.

1. The drafts specified the query commands only, which are now implemented in some registries in China, to fufill most of the critical requirements . We are not going to add transform extension in EPP drafts at present as this function of upload proof materials has been developed and implemented via HTTP. Maybe after a sufficient test of using EPP transform commands to transfer large files, we could consider standardizing this part in EPP extension. 

 

Since they are informational drafts it makes sense to include what is currently implemented, but it does not provide a complete solution for verification.  My recommendation is to publish your HTTP API as informational drafts to cover the transform side of the solution or extend the transform commands in your EPP extensions.  As noted previously on the list, there is no technical reason that EPP cannot be used to submit the verification material.

 

[Linlin] Thanks for your suggestion. We've considered this issue and found that BCP of HTTP API may be more proper. 





2. Actually in verification process, there are typically two phases, domain verification and contact verification. Domain verification is aimed to check whether a domain is reserved or prohibited. Contact verification is to check the facticity of a person. So These two drafts are seperated.

 

There is added complexity in separating them since the aggregate verification (domain and real name) impacts the domain and not the contact.  In EPP contacts are managed separately from the domains, so putting the verification on the contacts raises some additional questions:

 

1.	Do all contacts need to be verified (registrant, admin, tech, and billing), since contacts themselves don’t have the concept of type? 

        [Linlin] Actually only the registrant need to be verified according to the regulation in China.





1.	What is the expected behavior when a domain references a blocked or unverified registrant?   

1.	Does it impact the status of the domain and if so how?  
[Linlin] I think the simple process is to verify the domain, the verification status of a domain is pendingVerify. If it is a banned domain, after the period of pendingVerify, the domain will be deleted, no need to further check contact. If a domain passes verification but the registrant is unverified, the status of the domain maybe changed to serverHold and the status of the contact is failed. Updated proof materials are waited to be resubmitted.
2.	How does the client get notified of the domain status change?  We’re leveraging draft-gould-change-poll for this purpose.

                    [Linlin] Yes, I think the poll command should be extented too.





1.	What happens when the domain is updated to reference a different set of contacts that have different statuses?  

        [Linlin] If only the registrant should be verified, I think a domain will not have different statuses contatcts.

1.	What happens to the domain when the contact statuses change?  

        [Linlin] Please see the above answer.

 

Some of this behavior can be left to server policy and not explicitly defined in the protocol, but it would be good to know how you see this could work.  





3. Yes, it is specific to China currently. But we don't exclude the possibility to make them as more general drafts if some other countries also have the verification regulations. Daiming Li mentioned to add some content about verification background as well. I think this is a good suggestion and a quick update will be posted soon.

 

 

In the verification code draft we defined the concept of a verification profile, which enables the server to communicate the applicable profile and for the client to explicitly specify the desired verification profile to apply.  You may want to consider some sort of similar concept.  The question is whether a client can have more than one applicable profile (province or state within a country), which may not be the case in China but could be elsewhere.  

[Linlin]  From my rough understanding, a extensible protocol should support multiple applicable profiles.





Regards,


  _____  


Linlin Zhou

 

发件人： Gould, James <mailto:[e-mail]> 

发送时间： 2015-12-22 05:16

收件人： lidaiming <mailto:[e-mail]> ; Linlin Zhou <mailto:[e-mail]> ; [e-mail]

主题： Re: [eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt

Hi, 

 

I have a few high level questions:

1.	In reviewing draft-zhou-eppext-contact-verification and draft-wang-eppext-domain-verification, I see only extensions of the query responses (check and info), but I don't see extensions to the transform commands to submit the verification material.  Do you plan on adding extensions to the transform commands in the existing drafts or creating separate drafts for that purpose?  
2.	What is the relationship between the draft-zhou-eppext-contact-verification and draft-wang-eppext-domain-verification drafts?  
3.	Is draft-zhou-eppext-contact-verification and draft-wang-eppext-domain-verification only applicable to China verification or is being proposed as more general drafts?  I assume based on the Informational track that it's specific to China, but there is no reference to China in either draft.  

Thanks,

 

Jim

 


  _____  


From: EppExt [[e-mail]] on behalf of lidaiming [[e-mail]]
Sent: Monday, December 21, 2015 9:41 AM
To: Linlin Zhou; [e-mail]
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt

Linlin,

 

Thanks for your efforts. 

 

Since this draft together with draft-wang-eppext-domain-verification-00 is intended to describe the very EPP extensions relating to verification mechanism in China, you might include their background and usecases in these drafts, to shed light on their applications and implementations.

 

Daiming

 

KNET Technologies

 


  _____  


发件人："Linlin Zhou" <[e-mail]>

发送时间：2015-12-21 09:49

主题：[eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt

收件人："[e-mail]"<[e-mail]>

抄送：

 

The draft of contact verification has been submitted, which is now applied in practice in some registries of China. Any comments are welcome.

 

Regards,


  _____  


Linlin Zhou

 

From: internet-drafts <mailto:[e-mail]> 

Date: 2015-12-21 09:36

To: [e-mail]

Subject: I-D Action: draft-zhou-eppext-contact-verification-00.txt

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 

 

        Title           : Verification Extension for the Extensible Provisioning Protocol (EPP) Contact Mapping

        Authors         : Linlin Zhou

                          Di Ma

                          Wei Wang

                          Ning Kong

                          Xiaodong Lee

                          James Galvin

Filename        : draft-zhou-eppext-contact-verification-00.txt

Pages           : 17

Date            : 2015-12-20

 

Abstract:

   This mapping describes an verification extension to EPP contact

   mapping [RFC5733].  Specified in Extensible Markup Language (XML),

   this extended mapping is applied to provide additional features

   required for the provisioning of contact verification.

 

 

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-zhou-eppext-contact-verification/

 

There's also a htmlized version available at:

https://tools.ietf.org/html/draft-zhou-eppext-contact-verification-00

 

 

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 <http://tools.ietf.org/> .

 

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

 

_______________________________________________

I-D-Announce mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
EppExt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/eppext

 

_______________________________________________
EppExt mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/eppext> https://www.ietf.org/mailman/listinfo/eppext