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