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

From: Patrick Mevzek <[email-masked]>
Date: Thu, 31 Mar 2016 02:13:45 +0200

Linlin Zhou <[email-masked]> 2015-12-21 02:49
> The draft of contact verification has been submitted, which is now applied in practice in some registries of China. Any comments are welcome.

Hello Linlin,

I've implemented both the contact-verification and domain-verification
specifications in my open source EPP toolkit.

Here is my feedback. Please note that most of it apply equally to both
drafts.

* it is purely aesthetics, but I do not find vericontact and
veridomain good namespaces names. Maybe domainVerification and
contactVerification instead?

* also, I'm not a native English speaker, but I'm not sure that
"distinction" has the proper meaning in this context for node names.
Maybe better "restriction" or even "verification" directly?

* for Verification State Values, you have "unverified" and "failed",
so why not "passed" instead of "pass"?

* in domain-verification, the §4 state diagram speaks only about
contacts, so I think the whole section should be removed has it has no
relation with domains
and in contact-verification it is the exact opposite, so maybe do a
swap?

* in info reply you have this sentence lacking its end:
"o  An OPTIONAL <veridomain:distinction> element contains the"

* I do not understand what clID represents exactly? Whose client is
this id for?

* in §7, this sentence has a problem:
"As an extension of the EPP domain name mapping, the elements,
element"

* in contact:info reply you have this data:
<contact:crDate>2015-02-03T212:00:00.0Z</contact:crDate

the hour "212" is wrong

* also in all your info replies you have invalid dates: you need
the leading 0 to always have 2 or 4 digits.
2015-2-6T12:00:00.0Z should be 2015-02-06T12:00:00.0Z
and so on…

* if you can do contact:check on existing contacts you do not own, you
retrieve data that probably only the sponsoring registrar should see.
Same for domain:check
I believe output should be restricted to sponsoring registrar.

Also the draft does not specify what is returned in the case of non
existing contact/domain.

* in this XML snippet you have a namespace problem (verification
instead of vericontact/veridomain) :
S:      <veridomain:chkData xmlns:verification="urn:ietf:params:xml:ns:veridomain-1.0">
S:        <veridomain:distinction name="example.com" type="reserved"/>
S:        <veridomain:distinction name="example.net" type="prohibited"/>
S:      </veridomain:chkData>

* also for chkData, why not mimicking the core domain:check result,
with the domain name as node text content instead of attribute?

* I believe that having the extension in all check/info results is not
 a good idea because registrar will not need it everytime and it is
surely more costly than a standard check/info, especially with the
need of history retrieval.
Why not letting the registrar specify at request time if it wants in
the reply the vericontact/veridomain extension?
He could do that by just specifying an empty vericontact/veridomain
node in the extension part during the domain:info/domain:check request.

HTH,

-- 
Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 31 Mar 2016 11:25:15 +0800

Hi Patrick,
Thanks for your review. Please see my feedback inline. Most of your comments are valuable for us.

Regards,

Linlin Zhou
 
From: Patrick Mevzek
Date: 2016-03-31 08:13
To: Linlin Zhou
CC: [email-masked]
Subject: Re: [regext] [eppext] Fw: I-D Action: draft-zhou-eppext-contact-verification-00.txt
Linlin Zhou <[email-masked]> 2015-12-21 02:49
 
Hello Linlin,

 
* it is purely aesthetics, but I do not find vericontact and
veridomain good namespaces names. Maybe domainVerification and
contactVerification instead?
[Linlin] Thanks for your advice.
 
* also, I'm not a native English speaker, but I'm not sure that
"distinction" has the proper meaning in this context for node names.
Maybe better "restriction" or even "verification" directly?
[Linlin] We've considered this name for a while. Mabe this name would lead some misunderstanding. We'll try to change 
 
[Linlin] OK.
 
* in domain-verification, the §4 state diagram speaks only about
contacts, so I think the whole section should be removed has it has no
relation with domains
and in contact-verification it is the exact opposite, so maybe do a
swap?
[Linlin]Yes, this is a typo. We should swap the text and diagram in these two drafts. Thanks.
 
* in info reply you have this sentence lacking its end:
"o  An OPTIONAL <veridomain:distinction> element contains the"
[Linlin] This should add some words like "An OPTIONAL <veridomain:distinction> element contains the information whether a domain is allowed to be registered with respect to the verification rules of a specific registry."
 
* I do not understand what clID represents exactly? Whose client is
this id for?
[Linlin] Do you mean the clID in veriDomain level may be duplicated with the clID in domain level?
 
* in §7, this sentence has a problem:
"As an extension of the EPP domain name mapping, the elements,
element"
[Linlin] Yes. "the elements content described in this document" , delete "element".

the hour "212" is wrong
[Linlin] Yes.
 
[Linlin] Yes.

[Linlin] This is two important scenario. I'll give some specification in next version.
 
[Linlin] I'll correct this.

[Linlin] Ok.
 
[Linlin] Yes, this is a good suggestion. 

-- 
Patrick Mevzek
 
_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext