Subject: [provreg] Comments on draft-kong-epp-cdn-mapping-00.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 14 Dec 2011 18:45:07 +0000

I am not a Chinese domain name expert, so please excuse any ignorance I expose with these comments.

Section 5.1.1: I'd recommend including an example <check> response.

Section 5.1.2 and 5.1.3: All of the extension elements are described as optional in the text and the schema, which implies that they can all be omitted. That doesn't seem right - shouldn't at least one of the elements be included?

These sections don't describe any differences in the response depending on the domain submitted in the command. What happens if the query is for an OCDN?  For an SCDN?  For a TCDN?  For a VCDN?  Does it matter?  The example responses contain a lot of information, but without knowing what was queried I don't know how to interpret the examples.

Section 5.2.1: Why are the <cdn:VCDNList> and <cdn:VCDN> elements OPTIONAL? If they're not present, there's no reason to extend the <create> command at all, right?  Shouldn't one of them be present?

Section 5.2.2: I really think this section needs more text to explain what happens when a request is made to delete an OCDN, SCDN, TCDN, and VCDNs. Is the list of domains returned in the response a list of domains that are being deleted as a result of deleting an OCDN? If so, that should be clearly explained.

Section 5.2.3 and 5.2.4: Similar comment with OPTIONAL elements and processing of the different forms.

In a private email exchange with Ning Kong we discussed the possibility of this draft (and others like it) being revised to describe a more general approach to IDN variants.  I would support that effort.

Scott

---

From: James Mitchell <[email-masked]>
Date: Thu, 15 Dec 2011 13:55:53 +1100

>
>In a private email exchange with Ning Kong we discussed the possibility
>of this draft (and others like it) being revised to describe a more
>general approach to IDN variants.  I would support that effort.
>

I also support a more general approach to IDN variants.

---

From: Wil Tan <[email-masked]>
Date: Thu, 15 Dec 2011 17:03:03 +1100

> I also support a more general approach to IDN variants.
+1
I've also expressed the same interest to Ning in a private exchange, and
will gladly contribute to the efforts.

.wil

---

From: "Ning Kong" <[email-masked]>
Date: Fri, 16 Dec 2011 00:02:15 +0800

Hi Scott,

Thanks for your comments!

> Section 5.1.1: I'd recommend including an example <check> response.
OK. I'd like to add an example in the next version or maybe in the new draft
for IDN in future.

> Section 5.1.2 and 5.1.3: All of the extension elements are described as
> optional in the text and the schema, which implies that they can all be
> omitted. That doesn't seem right - shouldn't at least one of the elements
be
> included?
Yep, you're right. That's our mistake.

> These sections don't describe any differences in the response depending on
> the domain submitted in the command. What happens if the query is for an
> OCDN?  For an SCDN?  For a TCDN?  For a VCDN?  Does it matter?  The
> example responses contain a lot of information, but without knowing what
> was queried I don't know how to interpret the examples.
In this draft, we take OCDN, SCDN, TCDN and all VCDNs as one bundle. And
each CDN from the same bundle might have the same attributes (based on our
policy). That's to say, whether or not the query if for an OCDN, SCDN, TCDN,
or VCDN, the response should be same except the <domain:name> tag.

> Section 5.2.1: Why are the <cdn:VCDNList> and <cdn:VCDN> elements
> OPTIONAL? If they're not present, there's no reason to extend the <create>
> command at all, right?  Shouldn't one of them be present?
You're right. We made a similar mistake like Section 5.1.2 and 5.1.3. Thanks
for your corrections.

> Section 5.2.2: I really think this section needs more text to explain what
> happens when a request is made to delete an OCDN, SCDN, TCDN, and VCDNs.
> Is the list of domains returned in the response a list of domains that are
being
> deleted as a result of deleting an OCDN? If so, that should be clearly
> explained.
We indeed should make more explanations in this draft. In this draft, we
take OCDN, SCDN, TCDN and all VCDNs as one bundle, as I said above, we
extend the <delete> Command to delete all CDNs of the same bundle. If a
client only wants to delete one or some VCDNs, we suggest the client uses
<update> Command (<cdn:rem> element) which is also extended by us.

> processing of the different forms.
Our similar mistakes.

> In a private email exchange with Ning Kong we discussed the possibility of
this
> draft (and others like it) being revised to describe a more general
approach to
> IDN variants.  I would support that effort.
I realize that this draft which only focuses on CDNs is limited, and a more
general approach for IDNs would be more helpful. I'd like to do this work
later. Thanks a lot for your support!

Cheers,
Ning

---

From: "Ning Kong" <[email-masked]>
Date: Fri, 16 Dec 2011 00:07:09 +0800

> I also support a more general approach to IDN variants.
I'm very glad to see your feedback. Thanks for your such support.

Cheers,
Ning

---

From: "Ning Kong" <[email-masked]>
Date: Fri, 16 Dec 2011 00:10:17 +0800

Hi Wil,

Thanks! Looking forward to cooperating with you later.

Cheers,

Ning

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wil Tan
Sent: Thursday, December 15, 2011 2:03 PM
To: James Mitchell
Cc: [email-masked]
Subject: Re: [provreg] Comments on draft-kong-epp-cdn-mapping-00.txt

 

+1

I've also expressed the same interest to Ning in a private exchange, and will gladly contribute to the efforts.

.wil