Hollenbeck, Scott | 14 Dec 2011 19:45
Picon
Favicon

Comments on draft-kong-epp-cdn-mapping-00.txt

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
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
(Continue reading)

James Mitchell | 15 Dec 2011 03:55
Picon

Re: Comments on draft-kong-epp-cdn-mapping-00.txt


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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Wil Tan | 15 Dec 2011 07:03
Favicon
Gravatar

Re: Comments on draft-kong-epp-cdn-mapping-00.txt

On Thu, Dec 15, 2011 at 1:55 PM, James Mitchell <james.mitchell <at> ausregistry.com.au> wrote:


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


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

.wil
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Ning Kong | 15 Dec 2011 17:10
Picon

Re: Comments on draft-kong-epp-cdn-mapping-00.txt

 

Hi Wil,

 

Thanks! Looking forward to cooperating with you later.

 

Cheers,

Ning

 

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

 

On Thu, Dec 15, 2011 at 1:55 PM, James Mitchell <james.mitchell <at> ausregistry.com.au> wrote:


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

 

 

+1

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

 

.wil

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Ning Kong | 15 Dec 2011 17:07
Picon

Re: Comments on draft-kong-epp-cdn-mapping-00.txt


> 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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Ning Kong | 15 Dec 2011 17:02
Picon

Re: Comments on draft-kong-epp-cdn-mapping-00.txt

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.

> Section 5.2.3 and 5.2.4: Similar comment with OPTIONAL elements and
> 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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg


Gmane