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

James,

2011/11/2 Gould, James <[email protected]>

> 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.
>
>
I agree that this approach is more elegant, and would yield greater reuse
and flexibility.

The only caveat is that core domain attributes specified in RFC 5731 are
shared among domains in the bundle, while DNSSEC attributes are stored on a
per-domain basis (at least that's what I gathered to be the requirement
here.) As a result, an <update> command operating on a VCDN should only be
allowed to change the DNSSEC attributes, and not core domain attributes.

Perhaps draft-kong-epp-cdn-mapping-00 should include a way for the client
to specify the domains that the <update> command covers, so that it can be
verified by the server. For example, an <update> command that modifies core
domain attributes MUST specify all variants [1] in the bundle because the
operation will affect them all. Conversely, an <update> command that
modifies DNSSEC attributes may specify one or more variants in the bundle
(not necessarily all variants, but it can be.)

FWIW, when I was at NeuStar, we implemented Chinese domain bundling in such
a way that <info> and <check> may work for any domain in the bundle but
write operations must specify the OCDN so as to be explicit.

[1] using the term in a loose sense here.

.wil



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



-- 
Wil Tan
CTO
Cloud Registry <http://www.cloudregistry.net>

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