Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAABC1A6F5A for ; Mon, 4 Jan 2016 00:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.212 X-Spam-Level: X-Spam-Status: No, score=-0.212 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uhh16X2M8AF for ; Mon, 4 Jan 2016 00:10:31 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id EEFAF1A6F57 for ; Mon, 4 Jan 2016 00:10:29 -0800 (PST) Received: from zll (unknown [218.241.111.73]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5gDjpKIpWubooCQ--.32682S2; Mon, 04 Jan 2016 16:10:18 +0800 (CST) From: "Linlin Zhou" To: "'Gould, James'" References: <2015122109491079450710@cnnic.cn> <56780FA4.1000609@knet.cn> <2015122215070435275863@cnnic.cn> <1A233C0F-484E-4064-A9DB-97D109811986@verisign.com> <2015122417311749669576@cnnic.cn> <218EF327-9DD0-4ED7-A0C7-024BE2D6D29C@verisign.com> In-Reply-To: <218EF327-9DD0-4ED7-A0C7-024BE2D6D29C@verisign.com> Date: Mon, 4 Jan 2016 16:10:55 +0800 Message-ID: <014701d146c7$70a14b30$51e3e190$@cn> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0148_01D1470A.7EC48B30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHRQY40+9agQdGoNUWL0RRuGTv8u57q827Q Content-Language: zh-cn X-CM-TRANSID: AQAAf0B5gDjpKIpWubooCQ--.32682S2 X-Coremail-Antispam: 1UD129KBjvAXoW3uF17tw17JF4kKw45Wry5CFg_yoW8JrWDGo WfW34jqwsxtrnruFs8C34DJ3y5XFW3KwnYyF12qF1DKFnIqw13Jw4xGa17XFnxGFWY9w1D Ja48AayDZr4DGa4fn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUOx7k0a2IF6F4UM7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0 x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj4 1l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0 I7IYx2IY6xkF7I0E14v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wASzI0EjI02 j7AqF2xKxwAqx4xG67k08I80eVW8JVW5JwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK04 8IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIec xEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF 1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI 0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8Jr1l6VACY4xI67k04243AbIYCTnI WIevJa73UjIFyTuYvjxUc3C7UUUUU X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/ Archived-At: Cc: eppext@ietf.org, 'lidaiming' Subject: Re: [eppext] I-D Action: draft-zhou-eppext-contact-verification-00.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 08:10:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0148_01D1470A.7EC48B30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0149_01D1470A.7EC48B30" ------=_NextPart_001_0149_01D1470A.7EC48B30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi James, =20 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. =20 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. =20 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. =20 Regards, Linlin =20 From: eppext-bounces@ietf.org [mailto:eppext-bounces@ietf.org] On Behalf = Of Gould, James Sent: Tuesday, December 29, 2015 12:39 AM To: Linlin Zhou Cc: eppext@ietf.org; lidaiming Subject: Re: [eppext] I-D Action: = draft-zhou-eppext-contact-verification-00.txt =20 Linlin,=20 =20 My feedback is included below. =20 We've considered this issue and found that BCP of HTTP API may be more = proper.=20 =20 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. =20 =20 Actually only the registrant need to be verified according to the = regulation in China. =20 =20 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. =20 =20 =20 Yes, I think the poll command should be extented too. =20 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. =20 =20 If only the registrant should be verified, I think a domain will not = have different statuses contatcts. =20 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? =20 >From my rough understanding, a extensible protocol should support = multiple applicable profiles. =20 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. =20 =20 =E2=80=94 =20 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com=20 =20 On Dec 24, 2015, at 4:31 AM, Linlin Zhou wrote: =20 Hi James, Thanks for your feedback. Regards, _____ =20 Linlin Zhou =20 From: Gould, James =20 Date: 2015-12-23 23:52 To: Linlin Zhou =20 CC: eppext@ietf.org; lidaiming =20 Subject: Re: [eppext] Fw: I-D Action: = draft-zhou-eppext-contact-verification-00.txt Linlin,=20 =20 Thanks of the quick reply, my feedback is included below. =20 =E2=80=94 =20 JG James Gould Distinguished Engineer jgould@Verisign.com =20 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =20 =20 On Dec 22, 2015, at 2:07 AM, Linlin Zhou wrote: =20 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.=20 =20 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. =20 [Linlin] Thanks for your suggestion. We've considered this issue and = found that BCP of HTTP API may be more proper.=20 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. =20 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: =20 1. Do all contacts need to be verified (registrant, admin, tech, and = billing), since contacts themselves don=E2=80=99t have the concept of = type?=20 [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? =20 1. Does it impact the status of the domain and if so how? =20 [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=E2=80=99re 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? =20 [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? =20 [Linlin] Please see the above answer. =20 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. =20 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. =20 =20 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. =20 [Linlin] From my rough understanding, a extensible protocol should = support multiple applicable profiles. Regards, _____ =20 Linlin Zhou =20 =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Gould, James = =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A 2015-12-22 05:16 =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A lidaiming = ; Linlin Zhou ; = eppext@ietf.org =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [eppext] Fw: I-D Action: = draft-zhou-eppext-contact-verification-00.txt Hi,=20 =20 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? =20 2. What is the relationship between the = draft-zhou-eppext-contact-verification and = draft-wang-eppext-domain-verification drafts? =20 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. =20 Thanks, =20 Jim =20 _____ =20 From: EppExt [eppext-bounces@ietf.org] on behalf of lidaiming = [lidaiming@knet.cn] Sent: Monday, December 21, 2015 9:41 AM To: Linlin Zhou; eppext@ietf.org Subject: Re: [eppext] Fw: I-D Action: = draft-zhou-eppext-contact-verification-00.txt Linlin, =20 Thanks for your efforts.=20 =20 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. =20 Daiming =20 KNET Technologies =20 _____ =20 =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A"Linlin Zhou" =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2015-12-21 09:49 =E4=B8=BB=E9=A2=98=EF=BC=9A[eppext] Fw: I-D Action: = draft-zhou-eppext-contact-verification-00.txt =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A"eppext@ietf.org" =E6=8A=84=E9=80=81=EF=BC=9A =20 The draft of contact verification has been submitted, which is now = applied in practice in some registries of China. Any comments are = welcome. =20 Regards, _____ =20 Linlin Zhou =20 From: internet-drafts =20 Date: 2015-12-21 09:36 To: i-d-announce@ietf.org Subject: I-D Action: draft-zhou-eppext-contact-verification-00.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 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 =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. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zhou-eppext-contact-verification/ =20 There's also a htmlized version available at: https://tools.ietf.org/html/draft-zhou-eppext-contact-verification-00 =20 =20 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 = . =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org 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 EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext =20 _______________________________________________ EppExt mailing list EppExt@ietf.org = https://www.ietf.org/mailman/listinfo/eppext =20 ------=_NextPart_001_0149_01D1470A.7EC48B30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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:= = eppext-bounces@ietf.org [mailto:eppext-bounces@ietf.org] On Behalf Of = Gould, James
Sent: Tuesday, December 29, 2015 12:39 = AM
To: Linlin Zhou
Cc: eppext@ietf.org; = 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.  

=  

=E2=80=94=

=  

JG=

=


James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271<= br>12061 Bluemont Way
Reston, VA 20190

VerisignInc.com=

 

On Dec 24, 2015, at 4:31 AM, Linlin = Zhou <zhoulinlin@cnnic.cn> = wrote:

 

Hi James,

Thanks for your = feedback.

Regards,

Linlin = Zhou

 

From:<= /b> Gould, = James

Date:<= /b> 2015-12= -23 23:52

CC: eppext@ietf.org; lidaiming

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.

 

=E2=80=94<= /span>

 <= /o:p>

JG<= /span>


<BF09= FAA4-32D8-46(12-24-13-34-16).png>
=
James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

 

On Dec 22, 2015, at 2:07 AM, Linlin Zhou <zhoulinlin@cnnic.cn> = 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=E2=80=99t 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=E2=80=99re = 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

 

=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Gould, = James

=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A<= span lang=3DEN-US = style=3D'font-size:9.0pt;font-family:"Tahoma","sans-serif"'> 2015-12= -22 05:16

=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A lidaiming; Linlin Zhou; eppext@ietf.org

=

=E4=B8=BB=E9=A2=98=EF=BC=9A 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?  <= /span>
  2. What is the relationship between the draft-zhou-= eppext-contact-verification and draft-wang-eppext-domain-verification drafts? =  <= /span>
  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.  <= /span>

Thanks,<= /span>

 <= /o:p>

Jim<= /span>

 

From:=  EppExt [eppext-bounces@ietf.org] on = behalf of lidaiming [lidaiming@knet.cn]
Sent:<= span class=3Dapple-converted-space> Monday, December 21, = 2015 9:41 AM
To: Linlin Zhou; eppext@ietf.org
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

 

=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A"Linli= n Zhou" <zhoulinlin@cnnic.cn>

=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2015-12-21&= nbsp;09:49

=E4=B8=BB=E9=A2=98=EF=BC=9A[eppext] = Fw: I-D Action: = draft-zhou-eppext-contact-verification-00.txt

=

=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A"eppext@ietf.org"<eppext@ietf.org>=

=E6=8A=84=E9=80=81=EF=BC=9A=

 =

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:<= /b> internet-drafts

Date:<= /b> 2015-12= -21 09:36

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&nb= sp;       : = draft-zhou-eppext-contact-verification-00.txt

=

Pages =           : = 17

Date &= nbsp;          : = 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:

 =

There's = also a htmlized version available at:

 =

 =

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.

=

 =

Internet-Dr= afts are also available by anonymous FTP = at:

 =

___________= ____________________________________

I-D-Announc= e mailing list

Internet-Dr= aft directories: http://www.ietf.org/shadow.html<= /a>

_______________________________________________
EppExt= mailing list
EppExt@ietf.org
https://www.ietf.or= g/mailman/listinfo/eppext

 

_______________________________________________
EppExt= mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext

 

<= /html> ------=_NextPart_001_0149_01D1470A.7EC48B30-- ------=_NextPart_000_0148_01D1470A.7EC48B30 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= ------=_NextPart_000_0148_01D1470A.7EC48B30--