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

Hi James,

I think the essence of our debate is which model of CDN policy should be
accepted by CDN registries or registrars. If the third model you mentioned
is accepted, I agree with you that we don't need to extend RFC 5910.

IMHO, the flexibility of policy might cause the inconformity of the
attributes of CDNs, and then maybe cause the confusion to CDN users. So we
prefer to choose the "inflexibility" of policy in order to reduce the risk
of confusion. Then we are trying to extend RFC 5731 and RFC 5910 to provide
some ways to simplify the heritance of all of the attributes among CDNs. By
these extensions, CDN registries or registrars can operate CDNs as a group,
and they can easily create or modify the attributes among CDNs even if the
quantity of CDNs is large. You know, our policy creates the SCDN and TCDN
when creating the OCDN and blocks the VCDNs in the same time. In the future,
our policy will allow the creation of the VCDNs by the same registrant. So
in theory, all the CDNs of an OCDN can be validated by a registrant, so the
quantity of CDNs could be huge.

In short, IMO if the flexibility of CDN policy is accepted, it's not
necessary to extend RFC 5910 or RFC 5731. If the "inflexibility" of CDN
policy is accepted, the extensions of RFC 5731 and RFC 5910 supposed by us
might be useful to CDN registries (e.g. CNNIC) or registrars.

> Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, where they
> should be secCDNS:cdn, secCDNS:key, secCDNS:ds.
Thank you. I'll modify them in the next version.


Ning

> -----Original Message-----
> From: Gould, James [mailto:[email protected]]
> Sent: Thursday, October 27, 2011 3:08 AM
> To: Ning Kong
> Cc: [email protected]
> Subject: Re: [provreg] 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

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