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

Ning Kong <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <CAHeBMjzfiK4vjnwvqt5-_92CQOR7vS8=dyeGOQvzEz+VTQaXBw@mail.gmail.com>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.