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

Xiejiagui,


I can understand what you're trying to accomplish.  I would have handled
it differently by using RFC 5731 for the CRUD of the VCDN'S that are
related to a OCDN and using RFC 5910 to manage the DNSSEC attributes of
the OCDN and VCDN's individually.  The same thing applies to the use of
other EPP RFC's (e.g. RFC 3915) and custom EPP extensions that could be
applied to OCDN and VCDN's.  Something like
http://tools.ietf.org/html/draft-kong-epp-cdn-mapping-00 would be needed
at a minimum to include the relationship of the OCDN and VCDN's in the
info response as well in my opinion the transfer request of the OCDN to
make it explicit for the gaining client.  By treating the OCDN and the
VCDN's as individual provisioned objects that are related with extra
server-side policies the standard EPP mappings and extensions could be
utilized with added flexibility for the registry, registrar, and the
registrant. Tightly coupling them in the protocol requires treating them
in bulk which leads to a more complex interface and reduced flexibility.


--


JG



James Gould
Principal Software Engineer
[email protected]

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com




On 10/31/11 10:26 PM, "Kevin Tes" <[email protected]> wrote:

>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
>updatecreateinfodelete 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