From mcanix@gmail.com Tue Nov 1 00:33:51 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5D121F8F9F for ; Tue, 1 Nov 2011 00:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIbzVH98NWKr for ; Tue, 1 Nov 2011 00:33:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8805721F8F9A for ; Tue, 1 Nov 2011 00:33:50 -0700 (PDT) Received: by wyg30 with SMTP id 30so2119177wyg.31 for ; Tue, 01 Nov 2011 00:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=NO+sqN5fW39pgIu2v6zMkOPtN1SbB6uMWYH0ps8uZwU=; b=p+lZukZuBXqrKKJqKF1sbNSUwK6eQZdsUgCnN6LTFjqziMsY3WPRI4qQ/byOMVPYLR V/2To9kHCX3o9YH08dls3mqmCx4BFBB+RA4m3H/8HfpWGG0xeYTffnBn5Kj3DSnhEPjI SIfhUngy21AItrlMKSAZNbwa9UiwIFwyzGdkA= Received: by 10.227.208.77 with SMTP id gb13mr24904369wbb.4.1320132829569; Tue, 01 Nov 2011 00:33:49 -0700 (PDT) Received: from nakal.int.coza.net.za (41-132-12-44.dsl.mweb.co.za. [41.132.12.44]) by mx.google.com with ESMTPS id ff6sm36788326wbb.10.2011.11.01.00.33.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 00:33:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Mike O'Connell In-Reply-To: Date: Tue, 1 Nov 2011 09:33:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B785268-AF43-43AC-9DF3-7D40FE52BE54@gmail.com> References: To: James Gould , provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] EPP Poll 'msgid' attribute X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 07:33:51 -0000 Hi James, One of our larger registrars did request the feature.=20 The only reason why I wouldn't use the svTRID is from a referencing = perspective. Our queued messages are all in response to a single clTRID = so it makes it very easy to reference any related unacked responses.=20 Our system doesn't allow for duplicated clTRIDs, it will either be = rejected or uniquified (with the unique value being returned) based on = policy. Kind Regards, Mike O'Connell Domain Name Services On 31 Oct 2011, at 4:40 PM, Gould, James wrote: > Mike, >=20 > It is good that you make it backward compatible; although it would not = be > an RFC compliant addition. Has any registrar explicitly asked for = such a > feature? Why wouldn't you use the svTRID since it would be guaranteed = to > be unique? What would happen if the client sent you a duplicate = clTRID? >=20 >=20 > -- >=20 >=20 > JG >=20 >=20 >=20 > James Gould > Principal Software Engineer > jgould@Verisign.com >=20 > 703-948-3271 > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 >=20 > VerisignInc.com From JGould@verisign.com Tue Nov 1 06:59:09 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF181F0C72 for ; Tue, 1 Nov 2011 06:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBye7Zp10mVb for ; Tue, 1 Nov 2011 06:59:08 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1009C11E8163 for ; Tue, 1 Nov 2011 06:59:06 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP; Tue, 01 Nov 2011 06:59:08 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA1DwswI009718; Tue, 1 Nov 2011 09:58:54 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 09:58:54 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 09:58:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Tue, 1 Nov 2011 09:58:52 -0400 From: "Gould, James" To: "xiejiagui@cnnic.cn" Thread-Topic: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review Thread-Index: AQHMks6CtlnE+eylqkijIIXz2WJaB5WNF9WAgAGB+wCAAGWhgIAFrjQAgAHRvYCAARlhgIAAfmCA Date: Tue, 1 Nov 2011 13:58:51 +0000 Message-ID: In-Reply-To: <1320114389.1685.36.camel@zenus> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <0A76B2F21E470C47AD890240F5C4040F@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Nov 2011 13:58:54.0645 (UTC) FILETIME=[64920E50:01CC989E] Cc: "provreg@ietf.org" Subject: Re: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:59:09 -0000 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 jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 10/31/11 10:26 PM, "Kevin Tes" 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 ,if the registrant want to and new variant >domain or delete the exit variant domain, he/she can do it by >. >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 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 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=1B$B!"=1B(Bcreate=1B$B!"=1B(Binfo=1B$B!"=1B(Bdelete and so on. > >This extension allows the registrant add ds by specifying the domain >name,or add key data by specifying the "type =3D all, or type =3D 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, >>=20 >> 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 >> 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. >>=20 >>=20 >> -- >>=20 >>=20 >> JG >>=20 >>=20 >>=20 >> James Gould >> Principal Software Engineer >> jgould@Verisign.com >>=20 >> 703-948-3271 >> 21345 Ridgetop Circle >> LS2-2-1 >> Dulles, VA 20166 >>=20 >> VerisignInc.com >>=20 >>=20 >>=20 >>=20 >> On 10/30/11 1:52 AM, "Ning Kong" wrote: >>=20 >> > >> >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:JGould@verisign.com] >> >> Sent: Thursday, October 27, 2011 3:08 AM >> >> To: Ning Kong >> >> Cc: provreg@ietf.org >> >> Subject: Re: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted >> >>for >> >> Review >> >>=20 >> >> Ning, >> >>=20 >> >> > 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. >> >>=20 >> >>=20 >> >> 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 >> >> value in a standard 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? >> >>=20 >> >> > 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. >> >>=20 >> >>=20 >> >> 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. >> >>=20 >> >> > 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! >> >>=20 >> >>=20 >> >> Thanks, I'll review it and provide my feedback. >> >>=20 >> >> > We think we use camel case for the element names. Could you please >> >> > tell us which elements names are wrong? Thanks! >> >>=20 >> >>=20 >> >> Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, where they >> >> should be secCDNS:cdn, secCDNS:key, secCDNS:ds. >> >>=20 >> >> -- >> >>=20 >> >>=20 >> >> JG >> > >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > > From wil@cloudregistry.net Wed Nov 2 03:53:29 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AED11E80D9 for ; Wed, 2 Nov 2011 03:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=-2.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48Orz8pKcxPY for ; Wed, 2 Nov 2011 03:53:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA1111E8149 for ; Wed, 2 Nov 2011 03:53:27 -0700 (PDT) Received: by gye5 with SMTP id 5so879858gye.31 for ; Wed, 02 Nov 2011 03:53:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.185.138 with SMTP id fc10mr2644659igc.33.1320231206565; Wed, 02 Nov 2011 03:53:26 -0700 (PDT) Received: by 10.50.185.167 with HTTP; Wed, 2 Nov 2011 03:53:26 -0700 (PDT) In-Reply-To: References: <1320114389.1685.36.camel@zenus> Date: Wed, 2 Nov 2011 21:53:26 +1100 Message-ID: From: Wil Tan To: "Gould, James" Content-Type: multipart/alternative; boundary=14dae934105316b79304b0be48de Cc: "provreg@ietf.org" Subject: Re: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:53:29 -0000 --14dae934105316b79304b0be48de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable James, 2011/11/2 Gould, James > 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 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 command covers, so that it can be verified by the server. For example, an command that modifies core domain attributes MUST specify all variants [1] in the bundle because the operation will affect them all. Conversely, an 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 and 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 > jgould@Verisign.com > > 703-948-3271 > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > VerisignInc.com > > > > > On 10/31/11 10:26 PM, "Kevin Tes" 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 ,if the registrant want to and new variant > >domain or delete the exit variant domain, he/she can do it by > >. > >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 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 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=E3=80=81create=E3=80=81info=E3=80=81delete and so on. > > > >This extension allows the registrant add ds by specifying the domain > >name,or add key data by specifying the "type =3D all, or type =3D 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 t= he > >> element of RFC 5731 to the variant domain name. This do= es > >> mean that the DS for the domain and the variants are managed in separa= te > >> 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 goo= d > >>to > >> hear from the registrars if managing DS in bulk is needed. > >> > >> > >> -- > >> > >> > >> JG > >> > >> > >> > >> James Gould > >> Principal Software Engineer > >> jgould@Verisign.com > >> > >> 703-948-3271 > >> 21345 Ridgetop Circle > >> LS2-2-1 > >> Dulles, VA 20166 > >> > >> VerisignInc.com > >> > >> > >> > >> > >> On 10/30/11 1:52 AM, "Ning Kong" 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 i= f > >>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 C= DN > >> >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:JGould@verisign.com] > >> >> Sent: Thursday, October 27, 2011 3:08 AM > >> >> To: Ning Kong > >> >> Cc: provreg@ietf.org > >> >> Subject: Re: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitt= ed > >> >>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 domai= ns > >> >>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 fo= r > >> >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 > >> >> value in a standard with the dnssec extension for > >> >>managing > >> >> the DS or keys with additional server-side validation seems like th= e > >> >>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 for= m, > >> >> > 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 o= f > >>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 pleas= e > >> >> > 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 > >> provreg@ietf.org > >> https://www.ietf.org/mailman/listinfo/provreg > > > > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > --=20 Wil Tan CTO Cloud Registry --14dae934105316b79304b0be48de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable James,

2011/11/2 Gould, James <JGould@verisign.com= >
Xiejiagui,


I can understand what you're trying to accomplish. =C2=A0I would have h= andled
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. =C2=A0The same thing applies to the u= se of
other EPP RFC's (e.g. RFC 3915) and custom EPP extensions that could be=
applied to OCDN and VCDN's.
=C2=A0Something like
http://tools.ietf.org/html/draft-kong-epp-cdn-mapping-00 wo= uld be needed
at a minimum to include the relationship of the OCDN and VCDN's in the<= br> info response as well in my opinion the transfer request of the OCDN to
make it explicit for the gaining client. =C2=A0By 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 t= his approach is more elegant, and would yield greater reuse and flexibility= .

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

Perhaps=C2=A0draft-kong-epp-cdn-mapping-00 should inclu= de a way for the client to specify the domains that the <update> comm= and covers, so that it can be verified by the server. For example, an <u= pdate> command that modifies core domain attributes MUST specify all var= iants [1] in the bundle because the operation will affect them all. Convers= ely, an <update> command that modifies DNSSEC attributes may specify = one or more variants in the bundle (not necessarily all variants, but it ca= n be.)

FWIW, when I was at NeuStar, we implemented Chinese dom= ain 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

=C2=A0
--


JG



James Gould
Principal Software Engineer
jgould@Verisign.com

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

VerisignInc.com




On 10/31/11 10:26 PM, "Kevin T= es" <xiejiagui@cnnic.cn&g= t; 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 vari= ant
>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,no= t
>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<= br> >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=E3=80=81create=E3=80=81info=E3=80=81delete and so on.
>
>This extension allows the registrant add ds by specifying the domain >name,or add key data by specifying the "type =3D all, or type =3D = 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. =C2=A0If
>>the
>> clients need to be able to explicitly set DS instead of keys (DS D= ata
>> Interface), then RFC 5731 along with RFC 5910 can be used by setti= ng the
>> <domain:name> element of RFC 5731 to the variant domain name= . =C2=A0This does
>> mean that the DS for the domain and the variants are managed in se= parate
>> commands. =C2=A0The key value of the extension that you draf= ted is managing
>>the
>> DS in bulk. =C2=A0My suggestion is to support managing the DS indi= vidually
>>with
>> RFC 5731 and RFC 5910 and to make your extension as an option for<= br> >> registrars that have the need to manage them in bulk. =C2=A0It wou= ld be good
>>to
>> hear from the registrars if managing DS in bulk is needed.
>>
>>
>> --
>>
>>
>> JG
>>
>>
>>
>> James Gould
>> Principal Software Engineer
>> jgould@Verisign.com
>>
>> 703-948-3271
>> 21345 Ridgetop Circle
>> LS2-2-1
>> Dulles, VA 20166
>>
>> VerisignInc.com
>>
>>
>>
>>
>> On 10/30/11 1:52 AM, "Ning Kong" <nkong.cnnic@gmail.com> 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 y= ou
>>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 o= f the
>> >attributes of CDNs, and then maybe cause the confusion to CDN = users.
>>So we
>> >prefer to choose the "inflexibility" of policy in or= der to reduce the
>>risk
>> >of confusion. Then we are trying to extend RFC 5731 and RFC 59= 10 to
>> >provide
>> >some ways to simplify the heritance of all of the attributes a= mong
>>CDNs.
>> >By
>> >these extensions, CDN registries or registrars can operate CDN= s 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 SC= DN 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 regis= trant, 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 "inflexi= bility" of CDN
>> >policy is accepted, the extensions of RFC 5731 and RFC 5910 su= pposed
>>by us
>> >might be useful to CDN registries (e.g. CNNIC) or registrars.<= br> >> >
>> >> Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, wh= ere 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:JGould@verisign.com]
>> >> Sent: Thursday, October 27, 2011 3:08 AM
>> >> To: Ning Kong
>> >> Cc: provreg@ietf.org<= /a>
>> >> 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 fina= lly get
>>several or
>> >> > more CDNs. So if a registrant needs to update the DN= SSEC
>>attributes of
>> >> > all the CDNs, he or she has to do this kind of opera= tion 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 registra= rs. 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 up= dates in bulk is
>> >easier.
>> >> The same case could be made for making DNSSEC updates acr= oss an
>> >>unrelated
>> >> set of domains in bulk since a registrant could have mult= iple domains
>> >>that
>> >> they want to manage. =C2=A0What if there is an error in a= dding or
>>removing DS
>> >in
>> >> one or more of the CDN's in the bulk command? =C2=A0W= ould you then have to
>> >> extend the response as well to indicate what the specific= errors
>>are? =C2=A0I
>> >> believe that it's best to update the CDN's on a o= ne-by-one basis for
>> >DNSSEC
>> >> instead of in bulk for simplicity, consistency, and accur= acy. =C2=A0This
>>way
>> >all of
>> >> the existing interfaces can be used instead of requiring = the
>>registrars
>> >>to
>> >have
>> >> to implement updates in bulk. =C2=A0Providing 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 see= ms like the
>> >>most
>> >> straight forward approach to me. =C2=A0I ask the registra= rs what they
>>think
>> >>is
>> >the
>> >> best?
>> >>
>> >> > For Chinese users, the variants of a Chinese charact= er in SC form,
>>TC
>> >> > form and other variant forms are regarded as the sam= e. 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 sh= ould inherit all of
>> >> > the attributes of the OCDN (except for the DNSSEC at= tributes) 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. =C2=A0A third model is to open up the registrat= ion of the
>>variants
>> >>by
>> >the
>> >> sponsoring registrar and registrant, where the OCDN and C= DN are
>>related
>> >but
>> >> are independently managed. =C2=A0Building the inheritance= of all of the
>> >attributes
>> >> into the interface makes it less flexible in supporting d= ifferent
>>models
>> >and less
>> >> flexible for the registrants. =C2=A0What 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. =C2= =A0I 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-ep= p-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. Co= uld you please
>> >> > tell us which elements names are wrong? Thanks!
>> >>
>> >>
>> >> Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, wh= ere they
>> >> should be secCDNS:cdn, secCDNS:key, secCDNS:ds.
>> >>
>> >> --
>> >>
>> >>
>> >> JG
>> >
>>
>> ____________________= ___________________________
>> provreg mailing list
>> provreg@ietf.org
>> https://www.ietf.org/mailman/listinfo/provreg
>
>

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg



--
= Wil Tan
CTO
Cloud Registry <http://www.cloudregistry.net>
--14dae934105316b79304b0be48de-- From JGould@verisign.com Wed Nov 2 06:20:39 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0506E11E80B4 for ; Wed, 2 Nov 2011 06:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=-2.188, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptJeP0W8vcQc for ; Wed, 2 Nov 2011 06:20:37 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id D53AA1F0C34 for ; Wed, 2 Nov 2011 06:20:29 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP; Wed, 02 Nov 2011 06:20:36 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pA2DKHuj019212; Wed, 2 Nov 2011 09:20:17 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 09:20:17 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 09:20:17 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 2 Nov 2011 09:20:16 -0400 From: "Gould, James" To: Wil Tan Thread-Topic: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review Thread-Index: AQHMks6CtlnE+eylqkijIIXz2WJaB5WNF9WAgAGB+wCAAGWhgIAFrjQAgAHRvYCAARlhgIAAfmCAgAGhmQD//+XwgA== Date: Wed, 2 Nov 2011 13:20:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CAD6B9571A8A8jgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2011 13:20:17.0686 (UTC) FILETIME=[29F7EB60:01CC9962] Cc: "provreg@ietf.org" Subject: Re: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:20:39 -0000 --_004_CAD6B9571A8A8jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CAD6B9571A8A8jgouldverisigncom_" --_000_CAD6B9571A8A8jgouldverisigncom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Will, The main question is why do the attributes need to be inherited at all? Yo= u can validate the right to create/enable and update variants based on the = sponsorship information and leave all of the remainder of the attributes in= dependent. Things get a little messy when the sponsorship changes via a tr= ansfer or registrant change via update. You could make a policy decision t= hat sponsorship changes can only be made via the original domain, meaning t= he transfer and registrant update would need to be applied across the origi= nal domain and all its variants which is the only bulk action needed. The = relationship between the domains could be satisfied with something like htt= p://tools.ietf.org/html/draft-kong-epp-cdn-mapping-00; although some change= s would be required with the separate and related model. Adding the inheri= tance between the related objects is what reduces the flexibility and incre= ases the complexity of the interface since the standard RFC's can not be fu= lly utilized. -- JG [cid:AC61BF7B-A561-4340-A416-ABEDA0D3A740] James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com From: Wil Tan > Date: Wed, 2 Nov 2011 21:53:26 +1100 To: James Gould > Cc: "xiejiagui@cnnic.cn" >, "provreg@ietf.org" > Subject: Re: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for R= eview James, 2011/11/2 Gould, James > 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 a= nd flexibility. The only caveat is that core domain attributes specified in RFC 5731 are sh= ared among domains in the bundle, while DNSSEC attributes are stored on a p= er-domain basis (at least that's what I gathered to be the requirement here= .) As a result, an command operating on a VCDN should only be allo= wed to change the DNSSEC attributes, and not core domain attributes. Perhaps draft-kong-epp-cdn-mapping-00 should include a way for the client t= o specify the domains that the command covers, so that it can be v= erified by the server. For example, an command that modifies core = domain attributes MUST specify all variants [1] in the bundle because the o= peration will affect them all. Conversely, an command that modifie= s DNSSEC attributes may specify one or more variants in the bundle (not nec= essarily all variants, but it can be.) FWIW, when I was at NeuStar, we implemented Chinese domain bundling in such= a way that and may work for any domain in the bundle but wr= ite 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 jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 10/31/11 10:26 PM, "Kevin Tes" > 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 ,if the registrant want to and new variant >domain or delete the exit variant domain, he/she can do it by >. >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 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 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=1B$B!"=1B(Bcreate=1B$B!"=1B(Binfo=1B$B!"=1B(Bdelete and so on. > >This extension allows the registrant add ds by specifying the domain >name,or add key data by specifying the "type =3D all, or type =3D 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 >> 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 >> jgould@Verisign.com >> >> 703-948-3271 >> 21345 Ridgetop Circle >> LS2-2-1 >> Dulles, VA 20166 >> >> VerisignInc.com >> >> >> >> >> On 10/30/11 1:52 AM, "Ning Kong" > 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:JGould@verisign.com] >> >> Sent: Thursday, October 27, 2011 3:08 AM >> >> To: Ning Kong >> >> Cc: provreg@ietf.org >> >> 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 >> >> value in a standard 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 >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > > _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg -- Wil Tan CTO Cloud Registry --_000_CAD6B9571A8A8jgouldverisigncom_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: <5BB75572778E964D8877BA882344984C@verisign.com> Content-Transfer-Encoding: quoted-printable
Will,

The main question is why do the attributes need to be inherited at all= ?  You can validate the right to create/enable and update variants bas= ed on the sponsorship information and leave all of the remainder of the att= ributes independent.  Things get a little messy when the sponsorship changes via a transfer or registrant change via= update.  You could make a policy decision that sponsorship changes ca= n only be made via the original domain, meaning the transfer and registrant= update would need to be applied across the original domain and all its variants which is the only bulk action nee= ded.  The relationship between the domains could be satisfied with som= ething like http://tools.ietf.org/html/draft-kon= g-epp-cdn-mapping-00; although some changes would be required with the separate and related mode= l.  Adding the inheritance between the related objects is what reduces= the flexibility and increases the complexity of the interface since the st= andard RFC's can not be fully utilized.  

--


JG


James Gould
Pr= incipal Software Engineer
jgould@Verisign.com

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

VerisignInc.com<= /div>

From: Wil Tan <wil@cloudregistry.net>
Date: Wed, 2 Nov 2011 21:53:26 += ;1100
To: James Gould <jgould@verisign.com>
Cc: "xiejiagui@cnnic.cn" <xiejiagui@cnnic.cn>, "provreg@ietf.org" <prov= reg@ietf.org>
Subject: Re: [provreg] draft-kong-e= pp-cdn-dnssec-mapping-00 Submitted for Review

James,

2011/11/2 Gould, James <JGould@verisign.com>
Xiejiagui,


I can understand what you're trying to accomplish.  I would have handl= ed
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 o= f
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 wo= uld 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 re= use and flexibility.

The only caveat is that core domain attributes specified in RFC 5731 a= re shared among domains in the bundle, while DNSSEC attributes are stored o= n 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 at= tributes, and not core domain attributes.

Perhaps draft-kong-epp-cdn-mapping-00 should include a way for th= e client to specify the domains that the <update> command covers, so = that it can be verified by the server. For example, an <update> comma= nd 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, b= ut 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
jgould@Verisign.com

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

VerisignInc.com




On 10/31/11 10:26 PM, "Kevin Tes" <xiejiagui@cnnic.cn> 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 vari= ant
>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,no= t
>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<= br> >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=1B$B!"=1B(Bcreate=1B$B!"=1B(Binfo=1B$B!"=1B(Bdelete and so on. >
>This extension allows the registrant add ds by specifying the domain >name,or add key data by specifying the "type =3D all, or type =3D = 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 59= 10 could be used.  If
>>the
>> clients need to be able to explicitly set DS instead of keys (DS D= ata
>> Interface), then RFC 5731 along with RFC 5910 can be used by setti= ng 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 se= parate
>> commands.  The key value of the extension that you drafted is= managing
>>the
>> DS in bulk.  My suggestion is to support managing the DS indi= vidually
>>with
>> RFC 5731 and RFC 5910 and to make your extension as an option for<= br> >> registrars that have the need to manage them in bulk.  It wou= ld be good
>>to
>> hear from the registrars if managing DS in bulk is needed.
>>
>>
>> --
>>
>>
>> JG
>>
>>
>>
>> James Gould
>> Principal Software Engineer
>> jgould@Verisign.com
>>
>> 703-948-32= 71
>> 21345 Ridgetop Circle
>> LS2-2-1
>> Dulles, VA 20166
>>
>> VerisignInc.com
>>
>>
>>
>>
>> On 10/30/11 1:52 AM, "Ning Kong" <nkong.cnnic@gmail.com> 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 y= ou
>>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 o= f the
>> >attributes of CDNs, and then maybe cause the confusion to CDN = users.
>>So we
>> >prefer to choose the "inflexibility" of policy in or= der to reduce the
>>risk
>> >of confusion. Then we are trying to extend RFC 5731 and RFC 59= 10 to
>> >provide
>> >some ways to simplify the heritance of all of the attributes a= mong
>>CDNs.
>> >By
>> >these extensions, CDN registries or registrars can operate CDN= s 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 SC= DN 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 regis= trant, 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 "inflexi= bility" of CDN
>> >policy is accepted, the extensions of RFC 5731 and RFC 5910 su= pposed
>>by us
>> >might be useful to CDN registries (e.g. CNNIC) or registrars.<= br> >> >
>> >> Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, wh= ere 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:JGould@verisign.com]
>> >> Sent: Thursday, October 27, 2011 3:08 AM
>> >> To: Ning Kong
>> >> Cc: provreg@ietf.org<= /a>
>> >> 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 fina= lly get
>>several or
>> >> > more CDNs. So if a registrant needs to update the DN= SSEC
>>attributes of
>> >> > all the CDNs, he or she has to do this kind of opera= tion 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 registra= rs. 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 update= s in bulk is
>> >easier.
>> >> The same case could be made for making DNSSEC updates acr= oss an
>> >>unrelated
>> >> set of domains in bulk since a registrant could have mult= iple domains
>> >>that
>> >> they want to manage.  What if there is an error in a= dding 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-on= e basis for
>> >DNSSEC
>> >> instead of in bulk for simplicity, consistency, and accur= acy.  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 see= ms like the
>> >>most
>> >> straight forward approach to me.  I ask the registra= rs what they
>>think
>> >>is
>> >the
>> >> best?
>> >>
>> >> > For Chinese users, the variants of a Chinese charact= er in SC form,
>>TC
>> >> > form and other variant forms are regarded as the sam= e. 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 at= tributes) 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 registrat= ion of the
>>variants
>> >>by
>> >the
>> >> sponsoring registrar and registrant, where the OCDN and C= DN are
>>related
>> >but
>> >> are independently managed.  Building the inheritance= of all of the
>> >attributes
>> >> into the interface makes it less flexible in supporting d= ifferent
>>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 r= egistrant
>>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. Co= uld you please
>> >> > tell us which elements names are wrong? Thanks!
>> >>
>> >>
>> >> Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, wh= ere they
>> >> should be secCDNS:cdn, secCDNS:key, secCDNS:ds.
>> >>
>> >> --
>> >>
>> >>
>> >> JG
>> >
>>
>> _______________________________________________<= br> >> provreg mailing list
>> provreg@ietf.org
>> https://www.ietf.org/mailman/listinfo/provreg
>
>

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg



--
Wil Tan
CTO
Cloud Registry <http://www.clou= dregistry.net>
 --_000_CAD6B9571A8A8jgouldverisigncom_-- --_004_CAD6B9571A8A8jgouldverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[6].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[6].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[6].png"; size=4109; creation-date="Wed, 02 Nov 2011 13:20:15 GMT"; modification-date="Wed, 02 Nov 2011 13:20:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CAD6B9571A8A8jgouldverisigncom_-- From JGould@verisign.com Thu Nov 10 12:33:00 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A2421F8B6D for ; Thu, 10 Nov 2011 12:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.443 X-Spam-Level: X-Spam-Status: No, score=-5.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2KfJ7z-e0Sa for ; Thu, 10 Nov 2011 12:32:59 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id C844E21F8B68 for ; Thu, 10 Nov 2011 12:32:57 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTrw08vQzYjG1VJCRsC2pIVApM4/ZIzhI@postini.com; Thu, 10 Nov 2011 12:32:58 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pAAKWnW7014006; Thu, 10 Nov 2011 15:32:50 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 15:32:49 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Thu, 10 Nov 2011 15:32:49 -0500 From: "Gould, James" To: Wil Tan , "provreg@ietf.org" Thread-Topic: [provreg] Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt Thread-Index: AQHMn+fow85soGNG8Emi3VoJ6dqLsw== Date: Thu, 10 Nov 2011 20:32:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CAE199C91B0A8jgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2011 20:32:49.0876 (UTC) FILETIME=[E9FBD940:01CC9FE7] Subject: Re: [provreg] Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 20:33:00 -0000 --_004_CAE199C91B0A8jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CAE199C91B0A8jgouldverisigncom_" --_000_CAE199C91B0A8jgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wil, Below is some feedback to the draft: 1. Hopefully the trademark clearinghouse interface can be better underst= ood to help drive the elements needed by the launchphase extension, since t= hings could greatly change once that interface is defined. Hopefully an EP= P interface can be defined for the trademark clearinghouse that goes hand i= n hand with the launchphase extension. 2. Please add the XML schema to the Formal Syntax section 3. Why is the status optional in ? Shouldn't an application= always have a status? 4. The text says that is "(optional) one or more e= lements" where optional kind of conflicts with one or more. I would state = "zero or more elements" instead. 5. Are all of the elements required? 6. Shouldn't the be of type dateTime instead of date? 7. Shouldn't the be of type dateTime instead of date? 8. Wouldn't it be better to shorten the element names by not = including the "claim" prefix (e.g. instead of )= ? 9. It would be good if there is guidance or a description of the possibl= e values of the optional element. 10. Isn't it assuming a certain trademark clearinghouse interface with th= e name ? What if the elements are signed by the clearinghouse and= the clearinghouse generates a verifiable token? 11. Would the really be a contact identifier defined in = RFC 5733 or would it simply be a issuer identifier / handle? I'm not sure = how many issuers there will be and how they would be referenced. 12. The info response sample needs to change the duplicate element to a element. I'll provide more feedback as I work through the draft. -- JG [cid:F49929C4-D86D-4FE9-BA78-FE7B430C86DD] James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com From: Wil Tan > Date: Tue, 18 Oct 2011 01:36:11 +1100 To: > Subject: [provreg] Fwd: New Version Notification for draft-tan-epp-launchph= ase-01.txt Dear colleagues, Gavin and I have published a new version of the draft: http://tools.ietf.or= g/html/draft-tan-epp-launchphase-01 This is mostly Gavin's work, with the following changes: - element names are now in camelCase - renamed to - a "preValidated" attribute of element - there can be one or more elements As usual, we'd love to hear any feedback that you may have. -- .wil Cloud Registry ---------- Forwarded message ---------- From: > Date: Fri, Oct 14, 2011 at 3:16 AM Subject: New Version Notification for draft-tan-epp-launchphase-01.txt To: wil@cloudregistry.net Cc: wil@cloudregistry.net, gavin.brown@centra= lnic.com A new version of I-D, draft-tan-epp-launchphase-01.txt has been successfull= y submitted by Wil Tan and posted to the IETF repository. Filename: draft-tan-epp-launchphase Revision: 01 Title: Launch Phase Mapping for the Extensible Provisioning Proto= col (EPP) Creation date: 2011-10-14 WG ID: Individual Submission Number of pages: 19 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain names during the launch phase of a domain name registry. The IETF Secretariat _______________________________________________ provreg mailing list provre= g@ietf.org https://www.ietf.org/mailman/listinfo/p= rovreg --_000_CAE199C91B0A8jgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Wil,

Below is some feedback to the draft:

  1. Hopefully the trademark clearinghouse interface can be better understoo= d to help drive the elements needed by the launchphase extension, since thi= ngs could greatly change once that interface is defined.  Hopefully an= EPP interface can be defined for the trademark clearinghouse that goes hand in hand with the launchphase extens= ion.  
  2. Please add the XML schema to the Formal Syntax section<= /li>
  3. Why is the status optional in <lp:infData>?  Shouldn't a= n application always have a status?
  4. The text says that <lp:claim= > is "(optional) one or more <lp:claim> elements" where = optional kind of conflicts with one or more.  I would state "zero= or more <lp:claim> elements" instead.  
  5. Are all of= the <lp:claim> elements required?  
  6. Shouldn't the <l= p:claimRegDate> be of type dateTime instead of date?  
  7. Shou= ldn't the <lp:claimExDate> be of type dateTime instead of date?
    8. <= li>Wouldn't it be better to shorten the <lp:claim> element names by n= ot including the "claim" prefix (e.g. <lp:issuer> instead o= f <lp:claimIssuer>)?
  8. It would be good if there is guidance or= a description of the possible values of the <lp:phase> optional elem= ent.  
  9. Isn't it assuming a certain trademark clearinghouse int= erface with the name <lp:pvcs>?  What if the elements are signed= by the clearinghouse and the clearinghouse generates a verifiable token? &= nbsp;
  10. Would the <lp:claimIssuer> really be a contact identifi= er defined in RFC 5733 or would it simply be a issuer identifier / handle? =  I'm not sure how many issuers there will be and how they would be ref= erenced.
  11. The info response sample needs to change the duplicate <= ;lp:claimCountry> element to a <lp:region> element.  
    12. I'll provide more feedback as I work through the draft.  

    --


    JG


    James Gould
    Pr= incipal Software Engineer
    jgould@Verisign.com

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

    VerisignInc.com    <= /div>

From: Wil Tan <wil@cloudregistry.net>
Date: Tue, 18 Oct 2011 01:36:11 = 3;1100
To: <provreg@ietf.org>
Subject: [provreg] Fwd: New Version= Notification for draft-tan-epp-launchphase-01.txt

Dear colleagues,=

Gavin and I= have published a new version of the draft: http://= tools.ietf.org/html/draft-tan-epp-launchphase-01

This is mos= tly Gavin's work, with the following changes:

- element n= ames are now in camelCase
- renamed &= lt;trademark> to <claim>
- a "p= reValidated" attribute of <claim> element
- there can= be one or more <claim> elements

As usual, w= e'd love to hear any feedback that you may have.

-- 
.wil
Cloud Regis= try <http://www.cloudregistry.net&g= t;

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Oct 14, 2011 at 3:16 AM
Subject: New Version Notification for draft-tan-epp-launchphase-01.txt
To: wil@cloudregistry.net
Cc: wil@cloudregistry.net, gavin.brown@centralnic.com


A new version of I-D, draft-tan-epp-launchphase-01.txt has been successfull= y submitted by Wil Tan and posted to the IETF repository.

Filename:        draft-tan-epp-launchphase
Revision:        01
Title:           Launch Phase Mapping for the Exte= nsible Provisioning Protocol (EPP)
Creation date:   2011-10-14
WG ID:           Individual Submission
Number of pages: 19

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)   extension mapping for the provisioning and management of domain name= s
  during the launch phase of a domain name registry.




The IETF Secretariat
_______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg --_000_CAE199C91B0A8jgouldverisigncom_-- --_004_CAE199C91B0A8jgouldverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[70].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[70].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[70].png"; size=4109; creation-date="Thu, 10 Nov 2011 20:32:47 GMT"; modification-date="Thu, 10 Nov 2011 20:32:47 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CAE199C91B0A8jgouldverisigncom_-- From gavin.brown@centralnic.com Thu Nov 17 01:20:34 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4268C21F9B4D for ; Thu, 17 Nov 2011 01:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJjFBtNkPcBn for ; Thu, 17 Nov 2011 01:20:27 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id C091321F9B35 for ; Thu, 17 Nov 2011 01:20:26 -0800 (PST) Received: from [10.42.42.146] (unknown [178.101.251.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 48591712B93; Thu, 17 Nov 2011 09:20:24 +0000 (UTC) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-0F95D9E8-80C7-4877-B9AF-89D2E4238C28 Content-Transfer-Encoding: 7bit Message-Id: <13A570CE-3446-4314-845E-37A3FBEABC71@centralnic.com> X-Mailer: iPad Mail (9A405) From: Gavin Brown Date: Thu, 17 Nov 2011 10:20:22 +0100 To: "Gould, James" Cc: "provreg@ietf.org" Subject: Re: [provreg] Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:20:34 -0000 --Apple-Mail-0F95D9E8-80C7-4877-B9AF-89D2E4238C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi James, > Hopefully the trademark clearinghouse interface can be better understood t= o help drive the elements needed by the launchphase extension, since things c= ould greatly change once that interface is defined. Hopefully an EPP interf= ace can be defined for the trademark clearinghouse that goes hand in hand wi= th the launchphase extension. =20 The data elements in our draft are derived from our experience of working wi= th CHIP (ipclearinghouse.org) as both a registry and as a registrar. My gues= s is that any entity that operates a trademark clearing house for the new gT= LD round will require most of the data elements as CHIP do. We've been reach= ing out to potential clearing house operators (as well as organisations like= WIPO and the UK's Intellectual Property Office) for their feedback on this,= and would appreciate further input. > Please add the XML schema to the Formal Syntax section We removed it from this draft because we wanted to get the description of th= e data model out there for discussion and revision before encoding it into a= schema. The next draft will have the schema included. > Why is the status optional in ? Shouldn't an application alwa= ys have a status? Yes, it should. We'll correct that. > The text says that is "(optional) one or more elemen= ts" where optional kind of conflicts with one or more. I would state "zero o= r more elements" instead. =20 Thanks, we'll fix that. > Are all of the elements required? =20 Most of them should be optional in the standard as different servers (and ph= ases) will have different requirements (eg registered trademarks versus comp= any names). > Shouldn't the be of type dateTime instead of date? =20 > Shouldn't the be of type dateTime instead of date? I think that using a dateTime is excessive precision, unless there is a pres= umption to use dateTimes where possible in EPP. > Wouldn't it be better to shorten the element names by not inclu= ding the "claim" prefix (e.g. instead of )? That makes sense. > It would be good if there is guidance or a description of the possible val= ues of the optional element. =20 This would be useful. > Isn't it assuming a certain trademark clearinghouse interface with the nam= e ? What if the elements are signed by the clearinghouse and the c= learinghouse generates a verifiable token? =20 Perhaps a more flexible solution would be something like the way domain auth= orisation works, which supports a as well as as whi= ch can contain anything. > Would the really be a contact identifier defined in RFC 5= 733 or would it simply be a issuer identifier / handle? I'm not sure how ma= ny issuers there will be and how they would be referenced. We've previously envisioned scenarios where the issuer may not be known to t= he server at the time of request. For a real world example, during the sunri= se we ran for .com.de domains, we allowed registrations based on company nam= es. In Germany, there is no central registry of German companies: each compa= ny is registered with its local court, so there are potentially thousands of= issuers, too many for the server to know about in advance. Perhaps a better approach would be to allow an arbitrary identifier in this e= lement, but provide a suggestion that a good solution to the above scenario i= s to use contact IDs. > The info response sample needs to change the duplicate e= lement to a =20 Thanks, we'll fix that. Gavin. --=20 Gavin Brown Chief Technology Officer CentralNic Ltd Innovative Registry Services for ccTLD and gTLD registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. --Apple-Mail-0F95D9E8-80C7-4877-B9AF-89D2E4238C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi James,
<= blockquote type=3D"cite">
=
  1. Hopefully the trademark clearinghouse interface can be better understood= to help drive the elements needed by the launchphase extension, since thing= s could greatly change once that interface is defined.  Hopefully an EP= P interface can be defined for the trademark clearinghouse that goes hand in hand with the launchphase extensi= on.  
The data elements in our d= raft are derived from our experience of working with CHIP (ipclearinghouse.org) as both a registry and as a r= egistrar. My guess is that any entity that operates a trademark clearing hou= se for the new gTLD round will require most of the data elements as CHIP do.= We've been reaching out to potential clearing house operators (as well as o= rganisations like WIPO and the UK's Intellectual Property Office) for their f= eedback on this, and would appreciate further input.
  1. Please add the XML schema to the Fo= rmal Syntax section
We removed it fr= om this draft because we wanted to get the description of the data model out= there for discussion and revision before encoding it into a schema. The nex= t draft will have the schema included.
  1. Why is the status optional in <lp:infData>?=  Shouldn't an application always have a status?
<= /div>
Yes, it should. We'll correct that.
  1. The text says that <lp:claim>= ; is "(optional) one or more <lp:claim> elements" where optional kind o= f conflicts with one or more.  I would state "zero or more <lp:claim= > elements" instead.  
Thank= s, we'll fix that.
  1. Are all of the <lp:claim> elements required?  
Most of them should be optional in the standard= as different servers (and phases) will have different requirements (eg regi= stered trademarks versus company names).
<= div>
  1. Shouldn't the <lp:claimRegDate> be of typ= e dateTime instead of date?  
  2. Shouldn't the <lp:claimExDate&= gt; be of type dateTime instead of date?
I think that using a dateTime is excessive precision, unless there= is a presumption to use dateTimes where possible in EPP.
  1. Wouldn't it be better to sho= rten the <lp:claim> element names by not including the "claim" prefix (= e.g. <lp:issuer> instead of <lp:claimIssuer>)?
That makes sense.
  1. It would be good if there is guidance or= a description of the possible values of the <lp:phase> optional eleme= nt.  
This would be useful.
=
  1. Isn't it assum= ing a certain trademark clearinghouse interface with the name <lp:pvcs>= ;?  What if the elements are signed by the clearinghouse and the cleari= nghouse generates a verifiable token?  
Perhaps a more flexible solution would be something like the way do= main authorisation works, which supports a <domain:pw> as well as as &= lt;domain:ext> which can contain anything.
<= div>
  1. Would the <lp:claimIssuer> really b= e a contact identifier defined in RFC 5733 or would it simply be a issuer id= entifier / handle?  I'm not sure how many issuers there will be and how= they would be referenced.
We've pre= viously envisioned scenarios where the issuer may not be known to the server= at the time of request. For a real world example, during the sunrise we ran= for .com.de domains, we allowed registrations based on company names. In Ge= rmany, there is no central registry of German companies: each company is reg= istered with its local court, so there are potentially thousands of issuers,= too many for the server to know about in advance.

= Perhaps a better approach would be to allow an arbitrary identifier in this e= lement, but provide a suggestion that a good solution to the above scenario i= s to use contact IDs.
  1. The info response sample needs to change the duplicate <lp:claim= Country> element to a <lp:region> 
=
Thanks, we'll fix that.

Gavin.

<= span class=3D"Apple-style-span" style=3D"-webkit-tap-highlight-color: rgba(2= 6, 26, 26, 0.300781); -webkit-composition-fill-color: rgba(175, 192, 227, 0.= 234375); -webkit-composition-frame-color: rgba(77, 128, 180, 0.234375);">--&= nbsp;
Gavin Brown
Chief Technology Office= r
CentralNic Ltd
Innovative Registry S= ervices for ccTLD and gTLD registries

<= /span>
CentralNic Ltd is a= company registered in England and Wales with company
numbe= r 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
=
= --Apple-Mail-0F95D9E8-80C7-4877-B9AF-89D2E4238C28--