headers
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)

Permalink | Reply | 5 comments |
headers
Hollenbeck, Scott | 14 Dec 2011 19:45
Picon
Favicon

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

Section 4: it would be really helpful to include examples of the additional element(s) described in
sections 4 and 4.1.

Section 5.2: Please change 'A "type" attribute is used to identify a bundle of CDNs' to 'A REQUIRED "type"
attribute is used to identify a bundle of CDNs'

Sorry, I haven't had time to explore the meaty parts of the document.

Scott
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 1 comment |
headers
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
Permalink | Reply | 3 comments |
headers
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
Permalink | Reply | 1 comment |
headers
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
Permalink | Reply | 0 comments |
headers
Ning Kong | 15 Dec 2011 17:05
Picon

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


> Section 4: it would be really helpful to include examples of the
additional
> element(s) described in sections 4 and 4.1.
I'd like to add such examples later.

> Section 5.2: Please change 'A "type" attribute is used to identify a
bundle of
> CDNs' to 'A REQUIRED "type" attribute is used to identify a bundle of
CDNs'
Thanks for your good suggestion.

Cheers,
Ning

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
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
Permalink | Reply | 0 comments |
headers
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
Permalink | Reply | 0 comments |
headers
Michael Young | 20 Dec 2011 22:38
Picon

Extensions in regards to NTLDs

Hi all,

It's been a few years since I've posted to this list and I wonder how many
of us are still subscribed to it. Hopefully enough to make this question
meaningful.

If you are tracking the new GTLD process closely you will have noticed a
requirement in the draft Registry Agreement  to format any EPP extensions in
I-D format.

<If Registry Operator requires the use of functionality outside the base EPP
RFCs, Registry
Operator must document EPP extensions in Internet-Draft format following the
guidelines described in
RFC 3735. Registry Operator will provide and update the relevant
documentation of all the EPP Objects
and Extensions supported to ICANN prior to deployment.>

It occurs to me that once Operators have gone to the trouble of doing this,
numerous extensions may be submitted to the IETF for possibly the standards
track but maybe even more commonly as informational.

Here's my concern, that we will see numerous extensions with heavily
overlapping purposes to solve the common problems of running and launching a
TLD registry.  It seems to me that it would be great to have a group of
volunteers trying to rally disparate efforts to solve similar registry
problems and create standardized extensions where feasible.  I know we've
talked about this sort of idea before around EPP extensions, but given the
impending expansion of the TLD space I thought it was worth raising again.

Thoughts? Comments?

Best Regards,

Michael Young
M:+1-647-289-1220

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 12 comments |
headers
Francisco Obispo | 20 Dec 2011 22:56

Re: Extensions in regards to NTLDs

Hi Michael,

I'm envisioning at least two:

1) Launch Phase extension (currently a draft from Wil Tan),

2) IDN - for collecting the "language tag" as required by
   ICANN's IDN implementation guidelines.

I've written a draft for #2, which I could share/submit 
if you guys find it useful.

Francisco,

On Dec 20, 2011, at 1:38 PM, Michael Young wrote:

> Here's my concern, that we will see numerous extensions with heavily
> overlapping purposes to solve the common problems of running and launching a
> TLD registry.  It seems to me that it would be great to have a group of
> volunteers trying to rally disparate efforts to solve similar registry
> problems and create standardized extensions where feasible.  I know we've
> talked about this sort of idea before around EPP extensions, but given the
> impending expansion of the TLD space I thought it was worth raising again.
> 
> Thoughts? Comments?
> 
> 
> Best Regards,
> 
> Michael Young
> M:+1-647-289-1220
> 

Francisco Obispo 
email: fobispo <at> isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 11 comments |

Gmane