Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review
Jens Wagner <jwagner <at> hexonet.net>
2011-10-26 10:21:15 GMT
I agree with James. There should be an EPP extension to list domain
variants via <info>, and maybe require them on transfer (server
policy?), but it should cover more than chinese domain variants. As
James pointed out, the variants could be managed using standard EPP, so
there's no need to extend e.g. the <update> command. Imho that's
convenient for registrars (being one myself), EPP doesn't support bulk
Furthermore, I'd prefer if there's no redundancy in responses, e.g.
variants should be returned in punycode only.
should do, where type is a text attribute, and could be e.g.
'simple-chinese', 'traditional-chinese' and so on. For management
purposes, the type doesn't really matter.
Such an extension could even make sense for domains with german umlauts;
depending on how a registry handles IDNA2003 vs. IDNA2008, e.g.
Regarding the camel case, I think it should be e.g. scdn/scdnPunycode,
instead of SCDN/SCDNPunycode.
On 26.10.2011 11:03, Ning Kong 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!
> provreg mailing list
> provreg <at> ietf.org
Chief Executive Officer
Be Your Own Internet Services Provider
T: +49 6841 69 84 0
F: +49 6841 69 84 199
E: jwagner <at> hexonet.net
HEXONET GmbH, Talstrasse 27, 66424 Homburg, Germany. CEO& General Manager: Jens Wagner, HRB 2839 (HOM),
Amtsgericht Saarbrücken, VAT-ID: DE-138316882
HEXONET Services Inc., 1100 - 1200 West 73rd Avenue, Vancouver, B.C., V6P 6G5, Canada. CSO& General
Manager: Robert Birkner
This email and any files transmitted are confidential and intended only or the person(s) directly
addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or
other forms of dissemination is strictly prohibited. If you have received this email in error, please
notify the sender immediately and permanently delete this email with any files that may be attached.
provreg mailing list
provreg <at> ietf.org