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

James,

Firstly,in this draft
http://tools.ietf.org/html/draft-kong-epp-cdn-mapping-00,
it allows the registrant to create domain and its related variant
domains by <domain:create>,if the registrant want to and new variant
domain or delete the exit variant domain, he/she can do it by
<domain:update>.
The registrant can do this operation by using any type of the domain,not
just the OCDN, that is to say, the registrant can use any type of the
domain(may be ocdn,tcdn,scdn,or vcdn)in the <domain:name>element to do
this operation,but the operation is for all of these domains(for they
shared the same elements).The registries (registrars)do not care which
type of the domain the registrant used, they just maintain the bulk
relationship of it. So it is was easy for registry and registrar to
operate IDN which may have many variants.


The registrant can use <domain:info>to get the domains(ocdn,scdn and so
on).

In this case,it is useful to extend the 5910 to meet this feature.
The registrant can use any type of the domain to do operation such as
update、create、info、delete and so on.

This extension allows the registrant add ds by specifying the domain
name,or add key data by specifying the "type = all, or type = sc".
I think this way is convenient not only for the registrant but also for
the registry and registrar.


xiejiagui


On Mon, 2011-10-31 at 13:39 +0000, Gould, James wrote:
> Ning,
> 
> To meet your requirement of having a domain and it's variants inherit the
> same attributes the Key Data Interface of RFC 5910 could be used.  If the
> clients need to be able to explicitly set DS instead of keys (DS Data
> Interface), then RFC 5731 along with RFC 5910 can be used by setting the
> <domain:name> element of RFC 5731 to the variant domain name.  This does
> mean that the DS for the domain and the variants are managed in separate
> commands.  The key value of the extension that you drafted is managing the
> DS in bulk.  My suggestion is to support managing the DS individually with
> RFC 5731 and RFC 5910 and to make your extension as an option for
> registrars that have the need to manage them in bulk.  It would be good to
> hear from the registrars if managing DS in bulk is needed.
> 
> 
> --
> 
> 
> JG
> 
> 
> 
> James Gould
> Principal Software Engineer
> [email protected]
> 
> 703-948-3271
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
> 
> VerisignInc.com
> 
> 
> 
> 
> On 10/30/11 1:52 AM, "Ning Kong" <[email protected]> wrote:
> 
> >
> >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


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