Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

Ning,

> We can do it as you suggest. But we don't think this method is easier.
> Because a registrant who registers an OCDN will finally get several or
> more CDNs. So if a registrant needs to update the DNSSEC attributes of
> all the CDNs, he or she has to do this kind of operation one by one.
> Moreover, any reserved variant CDN can be validated by the same
> registrant later. If the quantity of CDNs is large, we think this
> method is not convenient for registrants or registrars. So, we suppose
> an extension of RFC 5910 to support bulk operations for CDNs.


I don't believe that I agree that doing the DNSSEC updates in bulk is
easier.  The same case could be made for making DNSSEC updates across an
unrelated set of domains in bulk since a registrant could have multiple
domains that they want to manage.  What if there is an error in adding or
removing DS in one or more of the CDN's in the bulk command?  Would you
then have to extend the response as well to indicate what the specific
errors are?  I believe that it's best to update the CDN's on a one-by-one
basis for DNSSEC instead of in bulk for simplicity, consistency, and
accuracy.  This way all of the existing interfaces can be used instead of
requiring the registrars to have to implement updates in bulk.  Providing
the CDN as the <domain:name> value in a standard <domain:update> with the
dnssec extension for managing the DS or keys with additional server-side
validation seems like the most straight forward approach to me.  I ask the
registrars what they think is the best?

> For Chinese users, the variants of a Chinese character in SC form, TC
> form and other variant forms are regarded as the same. Most of Chinese
> Domain Names (CDNs) have different variant forms (SC form, TC form,
> and other variant forms) which are also regarded as the same by
> Chinese users. So we think that all the CDN's should inherit all of
> the attributes of the OCDN (except for the DNSSEC attributes) to avoid
> the confusion of CDNs users.


Your policy indirectly creates the variants when creating the OCDN while
our policy is to allow the creation of the OCDN and block the creates of
the variants.  A third model is to open up the registration of the
variants by the sponsoring registrar and registrant, where the OCDN and
CDN are related but are independently managed.  Building the inheritance
of all of the attributes into the interface makes it less flexible in
supporting different models and less flexible for the registrants.  What
if a registrant wanted to use a different set of name servers for a subset
of the CDN's and what if a registrant never intended to use one of more of
the CDN's at all.  I believe there can be related entities but that
requiring inheritance of all of the attributes is not flexible enough for
the different business models and for the registrars/registrants.

> We have made such kind of extension in the draft
> http://tools.ietf.org/html/draft-kong-epp-cdn-mapping-00. Any comments
> on this draft are welcomed!


Thanks, I'll review it and provide my feedback.

> We think we use camel case for the element names. Could you please
> tell us which elements names are wrong? Thanks!


Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, where they should
be secCDNS:cdn, secCDNS:key, secCDNS:ds.

--


JG



James Gould
Principal Software Engineer
[email protected]

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com




On 10/26/11 5:03 AM, "Ning Kong" <[email protected]> wrote:

>Hi Gould,
>
>Thanks for reviewing this draft. Comments are inline below.
>
>> Are you saying that the CDN's inherit all of the attributes of the OCDN
>> except for the DNSSEC attributes that can't?
>Yes. Actually we hope all the CDNs could inherit all of the atrributes
>of the OCDN. But because the DS must be bound with the name of CDN, so
>the DNSSEC attributes of CDNs can't be same.
>
>> Wouldn't it be easier and
>> more standard to treat the CDN's as separate domains related to the OCDN
>> that are automatically created when creating the OCDN, meaning that the
>> RFC 5910 could be used as is on a <domain:update> with the <domain:name>
>> element containing the CDN instead of the OCDN?
>We can do it as you suggest. But we don't think this method is easier.
>Because a registrant who registers an OCDN will finally get several or
>more CDNs. So if a registrant needs to update the DNSSEC attributes of
>all the CDNs, he or she has to do this kind of operation one by one.
>Moreover, any reserved variant CDN can be validated by the same
>registrant later. If the quantity of CDNs is large, we think this
>method is not convenient for registrants or registrars. So, we suppose
>an extension of RFC 5910 to support bulk operations for CDNs.
>
>> It would be up to
>> registry policy what other attributes (e.g. name servers, statuses) can
>>be
>> set on a per CDN basis.
>For Chinese users, the variants of a Chinese character in SC form, TC
>form and other variant forms are regarded as the same. Most of Chinese
>Domain Names (CDNs) have different variant forms (SC form, TC form,
>and other variant forms) which are also regarded as the same by
>Chinese users. So we think that all the CDN's should inherit all of
>the attributes of the OCDN (except for the DNSSEC attributes) to avoid
>the confusion of CDNs users.
>
>>  Since the CDN is linked to the OCDN the
>> <domain:create>, <domain:delete>, and <domain:transfer> wouldn't apply
>> directly the CDN's, but certainly <domain:check>, <domain:update>, and
>> <domain:info> could.  One extension that would be useful for CDN would
>>be
>> to return the list of CDN's in a info response of the OCDN and to
>>require
>> the CDN list on a transfer request of the OCDN to make it explicit from
>> the gaining Registrar that they're transferring the OCDN along with the
>> list of CDN's and that they support the management of CDN's.  Returning
>> the list of CDN's could be based on the inclusion of the CDN extension
>>URI
>> in the login services.
>We have made such kind of extension in the draft
>http://tools.ietf.org/html/draft-kong-epp-cdn-mapping-00. Any comments
>on this draft are welcomed!
>
>> A nit on the draft is to use camel case for the element names.
>We think we use camel case for the element names. Could you please
>tell us which elements names are wrong? Thanks!
>
>Cheers,
>Ning

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg