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

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