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

"Gould, James" <> Wed, 23 December 2015 15:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4058F1A1B11 for <>; Wed, 23 Dec 2015 07:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.418
X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C5ZZxNJoB6ep for <>; Wed, 23 Dec 2015 07:53:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 738451A1B13 for <>; Wed, 23 Dec 2015 07:53:01 -0800 (PST)
Received: by with SMTP id k90so10391720qge.0 for <>; Wed, 23 Dec 2015 07:53:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=51Y/oI7csgKo6q7XkjJDnw+Xa0b2qX8h/DDomLxpYC4=; b=iF0shQcBK7pt14pDkqdMe9zVCJVzMLIfUQSHKQMlD2jhZQHtr7/Ah+a6XRgUtM+4fl WbF8SWidYuroHe0/Pm9sH8HH4NAfQYnbk5HpVD81fnBF1k9W/G7QV3qaQt2G3MT10D2M DieJNYqHaNl6rhDiITni33S+tlNg8f1QoEXdglLTLspbf2iDSq6feVcx4Uit6vz3+rZO H9CAH5UYM5ot8XlVzfMWj6jSB9gxe2LcK38p4C1NrG2IWJXomwE4GKSEGtfSkRWKeNWo qBJI1IGZ+dKpzKcNOHw70IAmwSpAyXX+BZo3hKhKmtJEdan2HnFCF10SIx+bl4LhpK7L DMmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=51Y/oI7csgKo6q7XkjJDnw+Xa0b2qX8h/DDomLxpYC4=; b=MNgBUN8HwyUSveEHDMkZMey0hAVox4dxTVy72Q6lhIMwgq5waPAh3kQXhPcj3d7nMz n7cTS9oMFoz49hiHnrrnZ1Adgilo5TcWCKi8Rau7PGe+lQsJo1MSy8vTKRiVaZHh/YrO +uIcVBtomG9TSaXCm7IPHqIIGwftWPtxUKBcrlWEPU6L3N/04pvBdqiL6SaiOFkWxczO LBzJKQ+at/cKLC9UvUEzakclDSv+XF3JZeIT5VwRGKW68cjSo7JtavR/POaaiNBhWiWP VAFocFoShoadTgnVEmqadaXTtxky7YPiU+OBj7s3FIKtk2T3WP1n3ZkAm2w9JJkITBrF f2Ew==
X-Gm-Message-State: ALoCoQntu6qxisLuZVrtNXNgvQeTqndCTEsJXclUyC7uSLZnXyUeTT5DPu0EdAL8CKxw3bUq4VLvbwlf38pFQUtkVFBddgOWnLW1D+5GGtOCl4LSz89AzJQ=
X-Received: by with SMTP id g37mr41561642qge.78.1450885980447; Wed, 23 Dec 2015 07:53:00 -0800 (PST)
Received: from ( []) by with ESMTPS id e185sm5434318qkb.0.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 23 Dec 2015 07:53:00 -0800 (PST)
Received: from (brn1wnexchm01 []) by (8.13.8/8.13.8) with ESMTP id tBNFqwAF018994 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Dec 2015 10:52:58 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Wed, 23 Dec 2015 10:52:56 -0500
From: "Gould, James" <>
To: Linlin Zhou <>
Thread-Topic: [eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt
Thread-Index: AQHRO/2+1uj5XhK+O0WFBG7QV7Mp2Z7V7yGMgACnmk2AAnkTAA==
Date: Wed, 23 Dec 2015 15:52:54 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_1A233C0F484E4064A9DB97D109811986verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, lidaiming <>
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt
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: Wed, 23 Dec 2015 15:53:05 -0000


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




James Gould
Distinguished Engineer

12061 Bluemont Way
Reston, VA 20190<>

On Dec 22, 2015, at 2:07 AM, Linlin Zhou <<>> 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.

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?
  2.  What is the expected behavior when a domain references a blocked or unverified registrant?
     *   Does it impact the status of the domain and if so how?
     *   How does the client get notified of the domain status change?  We’re leveraging draft-gould-change-poll for this purpose.
  3.  What happens when the domain is updated to reference a different set of contacts that have different statuses?
  4.  What happens to the domain when the contact statuses change?

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 Zhou

发件人: Gould, James<>
发送时间: 2015-12-22 05:16
收件人: lidaiming<>; Linlin Zhou<>;<>
主题: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt

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.



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


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.


KNET Technologies

发件人:"Linlin Zhou" <<>>
发送时间:2015-12-21 09:49
主题:[eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt

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

Linlin Zhou

From: internet-drafts<>
Date: 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        : draft-zhou-eppext-contact-verification-00.txt
Pages           : 17
Date            : 2015-12-20

   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<>.

Internet-Drafts are also available by anonymous FTP at:

I-D-Announce mailing list<>
Internet-Draft directories:
EppExt mailing list<>