On Wed, Oct 26, 2011 at 10:04 PM, Jens Wagne= r <jwagner@hexo= net.net> wrote:

On 26.10.2011 12:42, Andrew Sullivan wrote:

On Wed, Oct 26, 2011 at 12:21:15PM +0200, Jens Wagner wrote:

Furthermore, I'd prefer if there's no redundancy in responses, e.g.=
variants should be returned in punycode only.

I don't think you can do that. =C2=A0The Punycode form of IDNA2003 labe= ls
is not lossless, so while you get what is in the DNS, you don't know what the input string for the label was.

You could return only the A-label, of course, for IDNA2008, because
there's no ambiguity there (each A-label corresponds to exactly one
U-label). =C2=A0But we're not in an IDNA2008-only world yet, and if you= 'd
meant to stick to IDNA2008, you'd have said "A-label" instead= .

for now, the extension needs to cover IDNA2003 too, imho we can't stick= to IDNA2008 in the forseeable future.
But - do we need the unicode labels at all? The set of 'usable' dom= ain names always matches the set of them encoded in punycode.

Whenever folks suggested tha= t registries should collect the input string, I've always wondered the = practical utility of it other than as an FYI? I think I've heard some a= rguments along the lines of "future-proofing". Perhaps it could b= e useful in the transition to IDNA2008 (with the =C3=9F and sigma, etc.) bu= t still it can only be used as a partial aid. Moreover, there's no guar= antee that the registrar didn't submit the ToUnicode(ToAscii(input)) ve= rsion, in which case it's truly redundant as Jens stated.

Andrew, could you share your reasoning?

<= /div>

.wil

--0016e6407dba86b17f04b034a4e3-- From JGould@verisign.com Wed Oct 26 12:08:05 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 1D66411E807F for ; Wed, 26 Oct 2011 12:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=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 FRlKVtrqxCha for ; Wed, 26 Oct 2011 12:08:04 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 732A211E8073 for ; Wed, 26 Oct 2011 12:08:03 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Wed, 26 Oct 2011 12:08:03 PDT 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 p9QJ7smh026263; Wed, 26 Oct 2011 15:07: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); Wed, 26 Oct 2011 15:07:53 -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, 26 Oct 2011 15:07:54 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com (10.173.152.246) by brn1wnexcas01.vcorp.ad.vrsn.com (10.173.152.205) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Oct 2011 15:07:53 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 26 Oct 2011 15:07:52 -0400 From: "Gould, James" To: Ning Kong Thread-Topic: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review Thread-Index: AQHMks6CtlnE+eylqkijIIXz2WJaB5WNF9WAgAGB+wCAAGWhgA== Date: Wed, 26 Oct 2011 19:07:52 +0000 Message-ID: In-Reply-To: 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="us-ascii" Content-ID: <97E6085DD0984C438689B20E4FED91DD@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2011 19:07:54.0150 (UTC) FILETIME=[907F8460:01CC9412] 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, 26 Oct 2011 19:08:05 -0000 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 James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 10/26/11 5:03 AM, "Ning Kong" wrote: >Hi Gould, > >Thanks for reviewing this draft. Comments are inline below. > >> Are you saying that the CDN's inherit all of the attributes of the OCDN >> except for the DNSSEC attributes that can't? >Yes. Actually we hope all the CDNs could inherit all of the atrributes >of the OCDN. But because the DS must be bound with the name of CDN, so >the DNSSEC attributes of CDNs can't be same. > >> Wouldn't it be easier and >> more standard to treat the CDN's as separate domains related to the OCDN >> that are automatically created when creating the OCDN, meaning that the >> RFC 5910 could be used as is on a with the >> element containing the CDN instead of the OCDN? >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. > >> It would be up to >> registry policy what other attributes (e.g. name servers, statuses) can >>be >> set on a per CDN basis. >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. > >> Since the CDN is linked to the OCDN the >> , , and wouldn't apply >> directly the CDN's, but certainly , , and >> could. One extension that would be useful for CDN would >>be >> to return the list of CDN's in a info response of the OCDN and to >>require >> the CDN list on a transfer request of the OCDN to make it explicit from >> the gaining Registrar that they're transferring the OCDN along with the >> list of CDN's and that they support the management of CDN's. Returning >> the list of CDN's could be based on the inclusion of the CDN extension >>URI >> in the login services. >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! > >> A nit on the draft is to use camel case for the element names. >We think we use camel case for the element names. Could you please >tell us which elements names are wrong? Thanks! > >Cheers, >Ning From peter@denic.de Thu Oct 27 01:45:06 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 E3B7521F8669 for ; Thu, 27 Oct 2011 01:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ENPdDmGBwZ0q for ; Thu, 27 Oct 2011 01:45:06 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 5A49221F85B5 for ; Thu, 27 Oct 2011 01:45:05 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RJLaB-0007pP-Vt; Thu, 27 Oct 2011 10:45:04 +0200 Received: from localhost by x27.adm.denic.de with local id 1RJLaB-0000J2-S3; Thu, 27 Oct 2011 10:45:03 +0200 Date: Thu, 27 Oct 2011 10:45:03 +0200 From: Peter Koch To: provreg@ietf.org Message-ID: <20111027084503.GW1673@x27.adm.denic.de> References:

Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch 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: Thu, 27 Oct 2011 08:45:07 -0000 On Wed, Oct 26, 2011 at 05:03:54PM +0800, Ning Kong wrote: > > Are you saying that the CDN's inherit all of the attributes of the OCDN > > except for the DNSSEC attributes that can't? > Yes. Actually we hope all the CDNs could inherit all of the atrributes > of the OCDN. But because the DS must be bound with the name of CDN, so > the DNSSEC attributes of CDNs can't be same. so, why not operate on DNSKEY only - instead of DS? -Peter From ajs@anvilwalrusden.com Thu Oct 27 03:44:27 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 EF6F721F89BA for ; Thu, 27 Oct 2011 03:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8SgqCmVF8okj for ; Thu, 27 Oct 2011 03:44:27 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7B53F21F899D for ; Thu, 27 Oct 2011 03:44:27 -0700 (PDT) Received: from shinkuro.com (unknown [199.91.193.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EC0F51ECB41C for ; Thu, 27 Oct 2011 10:44:13 +0000 (UTC) Date: Thu, 27 Oct 2011 06:44:21 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20111027104420.GB45392@shinkuro.com> References:

<4EA7DF1B.6010903@hexonet.net> <20111026104232.GC41225@shinkuro.com> <4EA7E94F.8060903@hexonet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA7E94F.8060903@hexonet.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 27 Oct 2011 10:44:28 -0000 On Wed, Oct 26, 2011 at 01:04:47PM +0200, Jens Wagner wrote: > for now, the extension needs to cover IDNA2003 too, imho we can't > stick to IDNA2008 in the forseeable future. > But - do we need the unicode labels at all? The set of 'usable' > domain names always matches the set of them encoded in punycode. It's of course true that the IDNA2003 Punycode-encoded label, or the IDNA2008 A-label, is the only thing that actually gets looked up. But given that people seem to want variants, those variants are based on the string requested by the originator of the registration request (we usually call this the registrant). But what qualifies as a variant is at least partly determined by registry policy, the registry will need to be able to evaluate the extent to which a UTF-8 label (in IDNA2003) or U-label (in IDNA2008) has variants. Moreover, IDNA2008 suggests that the repository evaluate the U-label/A-label pair for conformance with one another, in order to ensure that the A-label to be placed in the zone really corresponds to the desired U-label (and that that U-label is a real U-label). See section 4.2.1 of RFC 5891. > The only purpose of the extension would be, that a registry can list > all manageble domains derived from an original domain, right? Sure, but under IDNA2003, you can't be sure what that "original domain" is, because of the case folding and so on. A -- Andrew Sullivan ajs@anvilwalrusden.com From JGould@verisign.com Thu Oct 27 06:57:12 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 88FD421F8772 for ; Thu, 27 Oct 2011 06:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 wcbtrMjkK1yR for ; Thu, 27 Oct 2011 06:57:11 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 87FAB21F85F1 for ; Thu, 27 Oct 2011 06:57:09 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP; Thu, 27 Oct 2011 06:57:11 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 p9RDv1Ae012540; Thu, 27 Oct 2011 09:57:01 -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); Thu, 27 Oct 2011 09:57:01 -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); Thu, 27 Oct 2011 09:57:01 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Thu, 27 Oct 2011 09:57:00 -0400 From: "Gould, James" To: Peter Koch , "provreg@ietf.org" Thread-Topic: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review Thread-Index: AQHMlLBMY2vIyr7lXUipEz5ZmgGryA== Date: Thu, 27 Oct 2011 13:57:00 +0000 Message-ID: In-Reply-To: <20111027084503.GW1673@x27.adm.denic.de> 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Oct 2011 13:57:01.0789 (UTC) FILETIME=[4D3CD8D0:01CC94B0] 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: Thu, 27 Oct 2011 13:57:12 -0000 Peter, Yes, you are correct that inheriting the DNSKEY of the OCDN across the CDN's would work and the server would then generate the set of DS across the OCDN and it's CDN's. I guess the only question is whether you would really want to share / inherit the key material, but that might make sense for related domains like OCDN and CDN's. I like the OCDN and CDN's to be treated as separate entities, but if the CDN's are contained by the OCDN and have to inherit the OCDN attributes, than use of the DNSKEY with the Key Data Interface of RFC 5910 should meet the goal. -- 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/27/11 4:45 AM, "Peter Koch" wrote: >On Wed, Oct 26, 2011 at 05:03:54PM +0800, Ning Kong wrote: > >> > Are you saying that the CDN's inherit all of the attributes of the >>OCDN >> > except for the DNSSEC attributes that can't? >> Yes. Actually we hope all the CDNs could inherit all of the atrributes >> of the OCDN. But because the DS must be bound with the name of CDN, so >> the DNSSEC attributes of CDNs can't be same. > >so, why not operate on DNSKEY only - instead of DS? > >-Peter >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From wil@cloudregistry.net Fri Oct 28 06:33:57 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 635E621F8B7D for ; Fri, 28 Oct 2011 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 9FYCz2HRVR2K for ; Fri, 28 Oct 2011 06:33:56 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC4DD21F8B7A for ; Fri, 28 Oct 2011 06:33:51 -0700 (PDT) Received: by qadc10 with SMTP id c10so4601604qad.31 for ; Fri, 28 Oct 2011 06:33:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.169 with SMTP id t41mr645011qch.249.1319808830999; Fri, 28 Oct 2011 06:33:50 -0700 (PDT) Received: by 10.229.225.197 with HTTP; Fri, 28 Oct 2011 06:33:50 -0700 (PDT) In-Reply-To: <20111027104420.GB45392@shinkuro.com> References:

<4EA7DF1B.6010903@hexonet.net> <20111026104232.GC41225@shinkuro.com> <4EA7E94F.8060903@hexonet.net> <20111027104420.GB45392@shinkuro.com> Date: Sat, 29 Oct 2011 00:33:50 +1100 Message-ID: From: Wil Tan To: Andrew Sullivan Content-Type: multipart/alternative; boundary=0016e64fd32c8b0db404b05bf0c8 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: Fri, 28 Oct 2011 13:33:57 -0000 --0016e64fd32c8b0db404b05bf0c8 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 27, 2011 at 9:44 PM, Andrew Sullivan wrote: > On Wed, Oct 26, 2011 at 01:04:47PM +0200, Jens Wagner wrote: > > > for now, the extension needs to cover IDNA2003 too, imho we can't > > stick to IDNA2008 in the forseeable future. > > But - do we need the unicode labels at all? The set of 'usable' > > domain names always matches the set of them encoded in punycode. > > It's of course true that the IDNA2003 Punycode-encoded label, or the > IDNA2008 A-label, is the only thing that actually gets looked up. But > given that people seem to want variants, those variants are based on > the string requested by the originator of the registration request (we > usually call this the registrant). But what qualifies as a variant is > at least partly determined by registry policy, the registry will need > to be able to evaluate the extent to which a UTF-8 label (in IDNA2003) > or U-label (in IDNA2008) has variants. > > I can't think of a case where the registry can't determine the variants from the ToUnicode(ToAscii(input)) alone. The language/script variant tables are constructed such that only the permitted codepoints after mapping (IDNA2003), normalisation and case folding have been applied. I'd expect that the internal data structures within registries' implementations also similarly only operate on permitted code points. So, if given the input UTF-8 label, the registry would only either store and forget about it, or perform ToUnicode(ToAscii()) on it. Moreover, IDNA2008 suggests that the repository evaluate the > U-label/A-label pair for conformance with one another, in order to > ensure that the A-label to be placed in the zone really corresponds to > the desired U-label (and that that U-label is a real U-label). See > section 4.2.1 of RFC 5891. > > Practically, in an SRS environment, I'd expect this evaluation of U-label/A-label pair to be done by the registrar, rather than the registry (repository) because registrants should be educated about IDNA2008 rules at the entry point, rather than being presented with a cryptic EPP error message. .wil --0016e64fd32c8b0db404b05bf0c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 27, 2011 at 9:44 PM, Andrew = Sullivan <aj= s@anvilwalrusden.com> wrote:

On Wed, Oct 26, 2011 at 01:04:47PM +0200, Jens Wagner wro= te:

> for now, the extension needs to cover IDNA2003 too, imho we can't<= br> > stick to IDNA2008 in the forseeable future.
> But - do we need the unicode labels at all? The set of 'usable'= ;
> domain names always matches the set of them encoded in punycode.

It's of course true that the IDNA2003 Punycode-encoded label, or = the
IDNA2008 A-label, is the only thing that actually gets looked up. =C2=A0But=
given that people seem to want variants, those variants are based on
the string requested by the originator of the registration request (we
usually call this the registrant). =C2=A0But what qualifies as a variant is=
at least partly determined by registry policy, the registry will need
to be able to evaluate the extent to which a UTF-8 label (in IDNA2003)
or U-label (in IDNA2008) has variants.

I can't think of a case where the = registry can't determine the variants from the ToUnicode(ToAscii(input)= ) alone. The language/script variant tables are constructed such that only = the permitted codepoints after mapping (IDNA2003), normalisation and case f= olding have been applied. I'd expect that the internal data structures = within registries' implementations also similarly only operate on permi= tted code points.

So, if given the input UTF-8 label, the registry would = only either store and forget about it, or perform ToUnicode(ToAscii()) on i= t.

Moreover, IDNA2008 suggests that the repository evaluate the
U-label/A-label pair for conformance with one another, in order to
ensure that the A-label to be placed in the zone really corresponds to
the desired U-label (and that that U-label is a real U-label). =C2=A0See section 4.2.1 of RFC 5891.

Practically, i= n an SRS environment, I'd expect this evaluation of U-label/A-label pai= r to be done by the registrar, rather than the registry (repository) becaus= e registrants should be educated about IDNA2008 rules at the entry point, r= ather than being presented with a cryptic EPP error message.

.wil

--0016e64fd32c8b0db404b05bf0c8-- From nkong.cnnic@gmail.com Sat Oct 29 22:52:36 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 99A8911E8080 for ; Sat, 29 Oct 2011 22:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=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 TjAAk8iZQpx8 for ; Sat, 29 Oct 2011 22:52:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DAE1F11E8073 for ; Sat, 29 Oct 2011 22:52:35 -0700 (PDT) Received: by iabn5 with SMTP id n5so7330389iab.31 for ; Sat, 29 Oct 2011 22:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=eVXUnrwH6ybFQntiTz/+0hTWDi8IE3KaClegCfNwfl4=; b=qLOUlJOvaiUbTDfh6MjJjgIuQxTim8Bh0qAEQwNEs/QAiLJuWySDwsGFz+715n++m6 smRBqG4T9338yiAfmIox1H+knNFqwkJYc8Dzc91cOSrg5jrQT2Y8pILzt+jS34T7D8uX c8dN81R4bHyiiXPlOGh5/xQ4ZNYN8vR9bfoGw= Received: by 10.42.141.69 with SMTP id n5mr13642487icu.47.1319953955483; Sat, 29 Oct 2011 22:52:35 -0700 (PDT) Received: from NAPTRTHINK ([114.247.10.156]) by mx.google.com with ESMTPS id el2sm20282451ibb.10.2011.10.29.22.52.30 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 22:52:33 -0700 (PDT) From: "Ning Kong" To: "'Gould, James'" References: In-Reply-To: Date: Sun, 30 Oct 2011 13:52:26 +0800 Message-ID: <000001cc96c8$1e2e05e0$5a8a11a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1EYLyJyUCVWgckPNCS0acP82yoJVDQ5tA Content-Language: zh-cn 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: Sun, 30 Oct 2011 05:52:36 -0000 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 From nkong.cnnic@gmail.com Sat Oct 29 23:06:04 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 E327221F84CF for ; Sat, 29 Oct 2011 23:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 NCwCm+5WRzk8 for ; Sat, 29 Oct 2011 23:06:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87B4821F84B7 for ; Sat, 29 Oct 2011 23:05:59 -0700 (PDT) Received: by iabn5 with SMTP id n5so7342634iab.31 for ; Sat, 29 Oct 2011 23:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=jD4x3ouoxVWJJdqdHZcsNmM2voqqWs9cS28yq3Y+KwE=; b=ofsgatSOJSBUu9u10InLfQFED4ujjVCGRP8Rf0hpI+Kh3qhNqTXCC6EeElHY2aVhz8 5hmDrLNJllEKO+XWVGjmlttz1BqzTgIHc7V0XWDqdqQhaag1JdBAGqZPxUbK9/yisGLA cL6yN87uI3bYQr/wG0pv7b2o1b9FHF0omXflE= Received: by 10.42.153.6 with SMTP id k6mr13723615icw.30.1319954759205; Sat, 29 Oct 2011 23:05:59 -0700 (PDT) Received: from NAPTRTHINK ([114.247.10.156]) by mx.google.com with ESMTPS id g16sm20330443ibs.8.2011.10.29.23.05.56 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 23:05:58 -0700 (PDT) From: "Ning Kong" To: "'Peter Koch'" , References:

<20111027084503.GW1673@x27.adm.denic.de> In-Reply-To: <20111027084503.GW1673@x27.adm.denic.de> Date: Sun, 30 Oct 2011 14:05:52 +0800 Message-ID: <000101cc96c9$fdff4660$f9fdd320$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIOM8YcZ3DOtwpq2pUfs2W03DnIFwKCjAMTAeBvYWgCZWJVOpTa5xiQ Content-Language: zh-cn 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: Sun, 30 Oct 2011 06:06:05 -0000 Hi Peter, > so, why not operate on DNSKEY only - instead of DS? I also think the use of the DNSKEY with the Key Data Interface is more convenient. Because the DS Data Interface is defined by RFC 5910, I think it's difficult to forbid CDN registrars to use the DS Data Interface. So we extended both interfaces in our draft. Ning From mcanix@gmail.com Mon Oct 31 02:33:33 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 D16D921F8D00 for ; Mon, 31 Oct 2011 02:33:33 -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 z84p+BSTGoUz for ; Mon, 31 Oct 2011 02:33:33 -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 7844821F8CFE for ; Mon, 31 Oct 2011 02:33:31 -0700 (PDT) Received: by wyg30 with SMTP id 30so999191wyg.31 for ; Mon, 31 Oct 2011 02:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=ytdOtMu+Cdkn2pOHqWy6K5Z5IbmtSsUFTMD9NRt/iwo=; b=GCRsuEyeRBNtVJGlL/YnkhZc0Nk1jF52GM8OECgEKH1BAdSlPcD4+XP1ZDYT/Pmnmu Z1XI9yJoLiyEkduSK7oFAgaen8ceHZU8slwwIumW6765XUOzzoOGU8POfOFhARXUrxly +wbzSHK7Y3eVO4YEPMks75HH+ZBwJs+aYaDEk= Received: by 10.227.202.71 with SMTP id fd7mr16648738wbb.9.1320053610572; Mon, 31 Oct 2011 02:33:30 -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 ei16sm31305853wbb.21.2011.10.31.02.33.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 02:33:29 -0700 (PDT) From: Mike O'Connell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2011 11:33:19 +0200 Message-Id: <0A7AD9D9-4EEF-4E9A-AE57-AF253AF81E83@gmail.com> To: provreg@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [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: Mon, 31 Oct 2011 09:33:33 -0000 Hi All We're currently implementing an EPP based registry. One of our test registrars pointed out something of interest which I = thought should be mentioned in the spec. The EPP schema element for 'poll' requests allows for two attributes = 'op' and 'msgid'. The spec states that when op=3D'req' is used the = server should return an unacked item from the FIFO queue, and that when = op=3D'ack' is used you need to specify the 'msgid' to acknowledge. We're looking at implementing a selectable poll message process where = the op=3D'req' can specify the clTRID as the 'msgid' attribute to = retrieve any unacked responses associated with that client identifier. Has anyone implemented anything like this? What are the thoughts = regarding this? Kind Regards, Mike O'Connell Domain Name Services From shollenbeck@verisign.com Mon Oct 31 04:19:27 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 782D721F8AD8 for ; Mon, 31 Oct 2011 04:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 R4101WfvBS7y for ; Mon, 31 Oct 2011 04:19:26 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 32BB321F8ABB for ; Mon, 31 Oct 2011 04:19:25 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Mon, 31 Oct 2011 04:19:26 PDT 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 p9VBJ9U1013537; Mon, 31 Oct 2011 07:19:09 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 07:19:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 07:19:08 -0400 From: "Hollenbeck, Scott" To: "Mike O'Connell" , "provreg@ietf.org" Thread-Topic: [provreg] EPP Poll 'msgid' attribute Thread-Index: AQHMl7A47035S/oUD0C8qd3INyuyBJWWTHzQ Date: Mon, 31 Oct 2011 11:19:07 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D54671F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0A7AD9D9-4EEF-4E9A-AE57-AF253AF81E83@gmail.com> In-Reply-To: <0A7AD9D9-4EEF-4E9A-AE57-AF253AF81E83@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 11:19:08.0930 (UTC) FILETIME=[E8A04620:01CC97BE] 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: Mon, 31 Oct 2011 11:19:27 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Mike O'Connell > Sent: Monday, October 31, 2011 5:33 AM > To: provreg@ietf.org > Subject: [provreg] EPP Poll 'msgid' attribute >=20 > Hi All >=20 >=20 > We're currently implementing an EPP based registry. >=20 > One of our test registrars pointed out something of interest which I > thought should be mentioned in the spec. >=20 > The EPP schema element for 'poll' requests allows for two attributes > 'op' and 'msgid'. The spec states that when op=3D'req' is used the server > should return an unacked item from the FIFO queue, and that when > op=3D'ack' is used you need to specify the 'msgid' to acknowledge. >=20 > We're looking at implementing a selectable poll message process where > the op=3D'req' can specify the clTRID as the 'msgid' attribute to > retrieve any unacked responses associated with that client identifier. >=20 > Has anyone implemented anything like this? What are the thoughts > regarding this? I personally think you're better off following the spec. One-off deviations= make it more difficult for registrars to develop software systems that wor= k across registries. You might want to check with your other registrar part= ners to see what they think. Having said that, if you do it be sure to change the URIs for the namespace= and schema identifiers. Once you change the schema you're (as you describe= d above) EPP-based, not EPP. Scott From wil@cloudregistry.net Mon Oct 31 04:23:25 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 18E9821F8DAB for ; Mon, 31 Oct 2011 04:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 GZCtRs9gstpn for ; Mon, 31 Oct 2011 04:23:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7821F8DA6 for ; Mon, 31 Oct 2011 04:23:24 -0700 (PDT) Received: by ggnv1 with SMTP id v1so6939964ggn.31 for ; Mon, 31 Oct 2011 04:23:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.244.133 with SMTP id lq5mr22353708icb.29.1320060203709; Mon, 31 Oct 2011 04:23:23 -0700 (PDT) Received: by 10.50.185.167 with HTTP; Mon, 31 Oct 2011 04:23:23 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D54671F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0A7AD9D9-4EEF-4E9A-AE57-AF253AF81E83@gmail.com> <831693C2CDA2E849A7D7A712B24E257F0D54671F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 31 Oct 2011 22:23:23 +1100 Message-ID: From: Wil Tan To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=90e6ba3fcc338634de04b09677f2 Cc: "provreg@ietf.org" 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: Mon, 31 Oct 2011 11:23:25 -0000 --90e6ba3fcc338634de04b09677f2 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 31, 2011 at 10:19 PM, Hollenbeck, Scott < shollenbeck@verisign.com> wrote: > > -----Original Message----- > > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > > Behalf Of Mike O'Connell > > Sent: Monday, October 31, 2011 5:33 AM > > To: provreg@ietf.org > > Subject: [provreg] EPP Poll 'msgid' attribute > > > > Hi All > > > > > > We're currently implementing an EPP based registry. > > > > One of our test registrars pointed out something of interest which I > > thought should be mentioned in the spec. > > > > The EPP schema element for 'poll' requests allows for two attributes > > 'op' and 'msgid'. The spec states that when op='req' is used the server > > should return an unacked item from the FIFO queue, and that when > > op='ack' is used you need to specify the 'msgid' to acknowledge. > > > > We're looking at implementing a selectable poll message process where > > the op='req' can specify the clTRID as the 'msgid' attribute to > > retrieve any unacked responses associated with that client identifier. > > > Not sure I understand you correctly, but I presume your intention is to allow a registrar to skip the head of the queue while reading messages off the poll queue. Piggybacking on clTRID sounds like a bad idea. If you had to do it, the "msgID" attribute would be a better place as it's not used when op="req". While specifying a "msgID" with op="req" is not explicitly forbidden by RFC 5730, it's still a hack. You'd still have to solve the problem of the registrar needing to discover the message IDs after the head of the queue, except in the special case of monotonically increasing msgID's, but msgID is of type xsd:token and so isn't is pretty much up to server implementation. > > Has anyone implemented anything like this? What are the thoughts > > regarding this? > > I personally think you're better off following the spec. One-off > deviations make it more difficult for registrars to develop software > systems that work across registries. You might want to check with your > other registrar partners to see what they think. > > Having said that, if you do it be sure to change the URIs for the > namespace and schema identifiers. Once you change the schema you're (as you > described above) EPP-based, not EPP. > > Rather than changing the namespace URI on the entire core EPP schema, you could create an extension command and use that instead of the standard . If you do that, I'd urge you to write an I-D as others may be interested in this work as well, and it'll go a long way towards interoperability. .wil --90e6ba3fcc338634de04b09677f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 31, 2011 at 10:19 PM, Hollen= beck, Scott <shollenbeck@verisign.com> wrote:

> -----Original Message-----
> From: provreg-bounces@ietf= .org [mailto:provreg-bounce= s@ietf.org] On
> Behalf Of Mike O'Connell
> Sent: Monday, October 31, 2011 5:33 AM
> To: provreg@ietf.org
> Subject: [provreg] EPP Poll 'msgid' attribute

>
> Hi All
>
>
> We're currently implementing an EPP based registry.
>
> One of our test registrars pointed out something of interest which I > thought should be mentioned in the spec.
>
> The EPP schema element for 'poll' requests allows for two attr= ibutes
> 'op' and 'msgid'. The spec states that when op=3D'= req' is used the server
> should return an unacked item from the FIFO queue, and that when
> op=3D'ack' is used you need to specify the 'msgid' to = acknowledge.
>
> We're looking at implementing a selectable poll message process wh= ere
> the op=3D'req' can specify the clTRID as the 'msgid' a= ttribute to
> retrieve any unacked responses associated with that client identifier.=
>

Not sure I understand you co= rrectly, but I presume your intention is to allow a registrar to skip the h= ead of the queue while reading messages off the poll queue.

Piggybacking on clTRID sounds like a bad idea.

If you had to do it, the "msgID" attribute would be a= better place as it's not used when op=3D"req". While specify= ing a "msgID" with op=3D"req" is not explicitly forbidd= en by RFC 5730, it's still a hack.

You'd still have to solve the problem of the regist= rar needing to discover the message IDs after the head of the queue, except= in the special case of monotonically increasing msgID's, but msgID is = of type xsd:token and so isn't is pretty much up to server implementati= on.

=C2=A0

> Has anyone implemented anything like this? What are the thoughts
> regarding this?

I personally think you're better off following the spec. One-off = deviations make it more difficult for registrars to develop software system= s that work across registries. You might want to check with your other regi= strar partners to see what they think.

Having said that, if you do it be sure to change the URIs for the namespace= and schema identifiers. Once you change the schema you're (as you desc= ribed above) EPP-based, not EPP.

Rather = than changing the namespace URI on the entire core EPP schema, you could cr= eate an extension command and use that instead of the standard <poll>= .

If you do that, I'd urge you to write an I-D as oth= ers may be interested in this work as well, and it'll go a long way tow= ards interoperability.

.wil

--90e6ba3fcc338634de04b09677f2-- From JGould@verisign.com Mon Oct 31 06:17:01 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 003AB21F8C30 for ; Mon, 31 Oct 2011 06:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, 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 Pg6dm-8he2pV for ; Mon, 31 Oct 2011 06:17:00 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0563121F8C16 for ; Mon, 31 Oct 2011 06:16:57 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP; Mon, 31 Oct 2011 06:17:00 PDT 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 p9VDGlA9017152; Mon, 31 Oct 2011 09:16:47 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 09:16:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 09:16:45 -0400 From: "Gould, James" To: Ning Kong , "'Peter Koch'" , "provreg@ietf.org" Thread-Topic: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review Thread-Index: AQHMl89W3jLvupb1pEOJxScYJ+ivsw== Date: Mon, 31 Oct 2011 13:16:45 +0000 Message-ID: In-Reply-To: <000101cc96c9$fdff4660$f9fdd320$@gmail.com> 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="us-ascii" Content-ID: <7AAB1A07896FA94589C317CD4B16B23A@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 13:16:47.0111 (UTC) FILETIME=[57A13970:01CC97CF] 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: Mon, 31 Oct 2011 13:17:01 -0000 Ning, RFC 5910 defines both the DS Data Interface and the Key Data Interface, where the Registry must support one or the other except during a transition period. If the Registry supported the Key Data Interface instead of the DS Data Interface the inheritance model that you're looking for would be met with a greatly simplified interface for the registrars. -- 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 2:05 AM, "Ning Kong" wrote: >Hi Peter, > >> so, why not operate on DNSKEY only - instead of DS? > >I also think the use of the DNSKEY with the Key Data Interface is more >convenient. Because the DS Data Interface is defined by RFC 5910, I think >it's difficult to forbid CDN registrars to use the DS Data Interface. So >we >extended both interfaces in our draft. > >Ning > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From JGould@verisign.com Mon Oct 31 06:39:32 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 49CE521F8496 for ; Mon, 31 Oct 2011 06:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=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 PT4NfSPbmfu9 for ; Mon, 31 Oct 2011 06:39:31 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id D0FB821F841A for ; Mon, 31 Oct 2011 06:39:30 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Mon, 31 Oct 2011 06:39:30 PDT 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 p9VDdPIl017817; Mon, 31 Oct 2011 09:39:26 -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); Mon, 31 Oct 2011 09:39:25 -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); Mon, 31 Oct 2011 09:39:25 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 09:39:24 -0400 From: "Gould, James" To: Ning Kong Thread-Topic: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review Thread-Index: AQHMks6CtlnE+eylqkijIIXz2WJaB5WNF9WAgAGB+wCAAGWhgIAFrjQAgAHRvYA= Date: Mon, 31 Oct 2011 13:39:24 +0000 Message-ID: In-Reply-To: <000001cc96c8$1e2e05e0$5a8a11a0$@gmail.com> 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 13:39:25.0683 (UTC) FILETIME=[8166DC30:01CC97D2] 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: Mon, 31 Oct 2011 13:39:32 -0000 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 >>=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 > From ajs@anvilwalrusden.com Mon Oct 31 06:42:37 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 9B38421F8CB9 for ; Mon, 31 Oct 2011 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] 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 cOXzSh1QB0Sl for ; Mon, 31 Oct 2011 06:42:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1B57721F8CB8 for ; Mon, 31 Oct 2011 06:42:37 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4C0E71ECB41D for ; Mon, 31 Oct 2011 13:42:25 +0000 (UTC) Date: Mon, 31 Oct 2011 09:42:40 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20111031134214.GA48552@shinkuro.com> References: <0A7AD9D9-4EEF-4E9A-AE57-AF253AF81E83@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A7AD9D9-4EEF-4E9A-AE57-AF253AF81E83@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Mon, 31 Oct 2011 13:42:37 -0000 On Mon, Oct 31, 2011 at 11:33:19AM +0200, Mike O'Connell wrote: > > We're looking at implementing a selectable poll message process where the op='req' can specify the clTRID as the 'msgid' attribute to retrieve any unacked responses associated with that client identifier. > > Has anyone implemented anything like this? What are the thoughts regarding this? I argued for altering the way poll worked to do something quite like this, about the time that EPP went through one of the standards levels (I think from proposed to draft). I outlined the suggestion in a long-expired I-D that is still available: http://tools.ietf.org/id/draft-sullivan-epp-experience-00.txt. See sections 3.4 and 4.2. I strongly recommend you not try to shoehorn this functionality into the existing poll queue mechanism. The existing mechanism is quite clearly FIFO, and if you try to manage it differently while using the same syntax, you not only produce quite different behaviour with the same protocol; you'll also find that you don't have enough primitives to manage the queue correctly, and messages will get lost. Anyway, you'll be in flagrant violation of section 2.9.2.3 of RFC 5730: "a successful response to a command MUST return the first message from the message queue." If conformance is important to you for contractual reasons, then you just can't do this. When I argued in favour of the approach to the poll queue I outlined in that I-D, Scott Hollenbeck pointed out (correctly) that you could do it with an extension anyway. That's what I'd recommend. Afilias never did undertake that work, however, because a colleague of mine in the development department decided instead that the passage, "Service messages SHOULD be created for passive clients affected by an action on an object," used the ordinary English meaning of SHOULD and not the RFC 2119 one. (Note that in RFC 3730, that SHOULD was a MUST, but I still don't see how the SHOULD gets one off the hook in case it's merely convenient.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From JGould@verisign.com Mon Oct 31 06:51:40 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 D03DA21F8CEF for ; Mon, 31 Oct 2011 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, 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 3MghN5crjIEk for ; Mon, 31 Oct 2011 06:51:40 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9EA21F8CEE for ; Mon, 31 Oct 2011 06:51:39 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP; Mon, 31 Oct 2011 06:51:39 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 p9VDpaJ9018395; Mon, 31 Oct 2011 09:51:36 -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); Mon, 31 Oct 2011 09:51:36 -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); Mon, 31 Oct 2011 09:51:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 09:51:35 -0400 From: "Gould, James" To: "Mike O'Connell" , "provreg@ietf.org" Thread-Topic: [provreg] EPP Poll 'msgid' attribute Thread-Index: AQHMl7A4XrCWA1mKmkeQWN9A0P/DDpWWeQeA Date: Mon, 31 Oct 2011 13:51:35 +0000 Message-ID: In-Reply-To: <0A7AD9D9-4EEF-4E9A-AE57-AF253AF81E83@gmail.com> 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="us-ascii" Content-ID: <2D4E09B752557F4BB0B1A12D54E1983A@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 13:51:36.0722 (UTC) FILETIME=[35228F20:01CC97D4] 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: Mon, 31 Oct 2011 13:51:41 -0000 Mike, If you are creating a different type of queue that is not FIFO I suggest that you create a new object mapping (e.g. Selectable Queue Object Mapping) that would provide the interface that you're looking for and to keep the FIFO queue support as defined by RFC 5730. Changing the semantics of existing mature interfaces for a new purpose would be an interoperability issue that is highly discouraged. -- 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 5:33 AM, "Mike O'Connell" wrote: >Hi All > > >We're currently implementing an EPP based registry. > >One of our test registrars pointed out something of interest which I >thought should be mentioned in the spec. > >The EPP schema element for 'poll' requests allows for two attributes 'op' >and 'msgid'. The spec states that when op=3D'req' is used the server shoul= d >return an unacked item from the FIFO queue, and that when op=3D'ack' is >used you need to specify the 'msgid' to acknowledge. > >We're looking at implementing a selectable poll message process where the >op=3D'req' can specify the clTRID as the 'msgid' attribute to retrieve any >unacked responses associated with that client identifier. > >Has anyone implemented anything like this? What are the thoughts >regarding this? > >Kind Regards, > > >Mike O'Connell >Domain Name Services > > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From mcanix@gmail.com Mon Oct 31 07:15:23 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 38B9821F8C64 for ; Mon, 31 Oct 2011 07:15:23 -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 UbdXEE2y6DfO for ; Mon, 31 Oct 2011 07:15:22 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id B3DFC21F8B7A for ; Mon, 31 Oct 2011 07:15:21 -0700 (PDT) Received: by wwf22 with SMTP id 22so1867448wwf.1 for ; Mon, 31 Oct 2011 07:15:20 -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=KRFwJl5FNAIcQOsZPeYdRJREzBvAOR2aOkb6tbks+Ik=; b=OqsCD7BlX67nuoJNvvLqqsgvvmhoET76PxIkQ5cDWZEEPABkOHHPtcQMVy0BmNU4lo 1Dmx5Qz0IDYfFSNUaone/X5tQ6aacOeknd38vJ8zvNVzawplrv/uE/TL9HJCsTRRa2CE ekFZjm4yLnC9hatJhxlcs1/3HGFSn1bsmhJ2U= Received: by 10.216.4.207 with SMTP id 57mr4333652wej.110.1320070520566; Mon, 31 Oct 2011 07:15:20 -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 ei16sm32687273wbb.21.2011.10.31.07.15.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 07:15:19 -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: Mon, 31 Oct 2011 16:15:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5DF2925B-832A-41E7-BA4B-F5C423F10294@gmail.com> References: To: "Gould, James" , 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: Mon, 31 Oct 2011 14:15:23 -0000 Hi James, Just to clarify the idea here is not to replace the FIFO queue, but = merely supplement the poll request by allowing the registrar to retrieve = a pending action response to a specific client message identifier = (clTRID). That way the registrar doesn't have to sift through dozens or = even hundreds of pending poll messages to get to what he wants/needs. This functionality would be completely optional but still fully = compliant with the default EPP schema, and it assumes the registrar = maintains his clTRID values. Thank you for the responses. Kind Regards, Mike O'Connell Domain Name Services On 31 Oct 2011, at 3:51 PM, Gould, James wrote: > Mike, >=20 > If you are creating a different type of queue that is not FIFO I = suggest > that you create a new object mapping (e.g. Selectable Queue Object > Mapping) that would provide the interface that you're looking for and = to > keep the FIFO queue support as defined by RFC 5730. Changing the > semantics of existing mature interfaces for a new purpose would be an > interoperability issue that is highly discouraged. >=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 ajs@anvilwalrusden.com Mon Oct 31 07:33:22 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 9C06721F8CBC for ; Mon, 31 Oct 2011 07:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] 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 dRiqnz89FSlY for ; Mon, 31 Oct 2011 07:33:22 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1D721F8C73 for ; Mon, 31 Oct 2011 07:33:22 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7B9631ECB41D for ; Mon, 31 Oct 2011 14:33:10 +0000 (UTC) Date: Mon, 31 Oct 2011 10:33:19 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20111031143319.GC48552@shinkuro.com> References: <000001cc96c8$1e2e05e0$5a8a11a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Mon, 31 Oct 2011 14:33:22 -0000 On Mon, Oct 31, 2011 at 01:39:24PM +0000, Gould, James wrote: > 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. It would be good to have a definition of "variant" that allows us to know the answer. Half the problem with these discussions is that the meaning of variant is so fluid. There are currently two competing definition of Chinese Domain Name, one of which requires them all to have effectively the same DNS data and another of which explicitly intends to use the DNS for application support, with different RDATA for different A-label names (even though the different A-labels are conceptually "the same name"). This basic confusion in terms makes generalizing and standardizing the behaviour of such things rather tricky. A -- Andrew Sullivan ajs@anvilwalrusden.com From JGould@verisign.com Mon Oct 31 07:40:08 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 36EA521F8C82 for ; Mon, 31 Oct 2011 07:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, 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 aNDEqaIFU6r0 for ; Mon, 31 Oct 2011 07:40:07 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2308A21F8C66 for ; Mon, 31 Oct 2011 07:40:07 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP; Mon, 31 Oct 2011 07:40:07 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 p9VEe4If019956; Mon, 31 Oct 2011 10:40:04 -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); Mon, 31 Oct 2011 10:40:04 -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); Mon, 31 Oct 2011 10:40:04 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 10:40:03 -0400 From: "Gould, James" To: "Mike O'Connell" , "provreg@ietf.org" Thread-Topic: [provreg] EPP Poll 'msgid' attribute Thread-Index: AQHMl7A4XrCWA1mKmkeQWN9A0P/DDpWWeQeAgABJpQD//8PlAA== Date: Mon, 31 Oct 2011 14:40:02 +0000 Message-ID: In-Reply-To: <5DF2925B-832A-41E7-BA4B-F5C423F10294@gmail.com> 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 14:40:04.0331 (UTC) FILETIME=[FA347BB0:01CC97DA] 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: Mon, 31 Oct 2011 14:40:08 -0000 Mike, 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? -- 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:15 AM, "Mike O'Connell" wrote: >Hi James, > > >Just to clarify the idea here is not to replace the FIFO queue, but >merely supplement the poll request by allowing the registrar to retrieve >a pending action response to a specific client message identifier >(clTRID). That way the registrar doesn't have to sift through dozens or >even hundreds of pending poll messages to get to what he wants/needs. > >This functionality would be completely optional but still fully compliant >with the default EPP schema, and it assumes the registrar maintains his >clTRID values. > >Thank you for the responses. > >Kind Regards, > > >Mike O'Connell >Domain Name Services > > > >On 31 Oct 2011, at 3:51 PM, Gould, James wrote: > >> Mike, >>=20 >> If you are creating a different type of queue that is not FIFO I suggest >> that you create a new object mapping (e.g. Selectable Queue Object >> Mapping) that would provide the interface that you're looking for and to >> keep the FIFO queue support as defined by RFC 5730. Changing the >> semantics of existing mature interfaces for a new purpose would be an >> interoperability issue that is highly discouraged. >>=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 xiejiagui@cnnic.cn Mon Oct 31 19:26:36 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 6BFFB1F0C5D for ; Mon, 31 Oct 2011 19:26:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.404 X-Spam-Level: ** X-Spam-Status: No, score=2.404 tagged_above=-999 required=5 tests=[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, MSGID_FROM_MTA_HEADER=0.803] 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 ekCvr89ZX63E for ; Mon, 31 Oct 2011 19:26:35 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id A00E71F0C5B for ; Mon, 31 Oct 2011 19:26:33 -0700 (PDT) Received: (eyou send program); Tue, 01 Nov 2011 10:26:30 +0800 Message-ID: <520114390.14010@cnnic.cn> X-EYOUMAIL-SMTPAUTH: xiejiagui@cnnic.cn Received: from unknown (HELO [218.241.111.81]) (218.241.111.81) by 159.226.7.146 with SMTP; Tue, 01 Nov 2011 10:26:30 +0800 From: Kevin Tes To: "Gould, James" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: CNNIC Date: Tue, 01 Nov 2011 10:26:29 +0800 Message-ID: <1320114389.1685.36.camel@zenus> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit 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 Reply-To: xiejiagui@cnnic.cn List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 02:26:36 -0000 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、create、info、delete and so on. This extension allows the registrant add ds by specifying the domain name,or add key data by specifying the "type = all, or type = sc". I think this way is convenient not only for the registrant but also for the registry and registrar. xiejiagui On Mon, 2011-10-31 at 13:39 +0000, Gould, James wrote: > Ning, > > To meet your requirement of having a domain and it's variants inherit the > same attributes the Key Data Interface of RFC 5910 could be used. If the > clients need to be able to explicitly set DS instead of keys (DS Data > Interface), then RFC 5731 along with RFC 5910 can be used by setting the > 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 From nkong@cnnic.cn Mon Oct 31 23:48:17 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 C3CFF11E80B2 for ; Mon, 31 Oct 2011 23:48:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MSGID_FROM_MTA_HEADER=0.803] 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 llqBPbl9HUIZ for ; Mon, 31 Oct 2011 23:48:17 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D35CB11E808E for ; Mon, 31 Oct 2011 23:48:16 -0700 (PDT) Received: (eyou send program); Tue, 01 Nov 2011 14:48:07 +0800 Message-ID: <520130087.11967@cnnic.cn> X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 01 Nov 2011 14:48:07 +0800 From: "Ning Kong" To: "'Gould, James'" References: <000001cc96c8$1e2e05e0$5a8a11a0$@gmail.com> <520068382.22754@cnnic.cn> In-Reply-To: <520068382.22754@cnnic.cn> Date: Tue, 1 Nov 2011 14:48:01 +0800 Message-ID: <012401cc9862$33159090$9940b1b0$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGHjGTR53vPs/3NFjCgsSpaseW0L5YhfEmQ Content-Language: zh-cn 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 06:48:17 -0000 Hi James, > 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. IMO, the Key Data Interface of RFC 5910 is only designed for single domain name. So I think it's necessary to extend the element (for example < secDNS:keyData type="single/bulk">) in order to let the users (registrars/registries) know whether the key is for single domain name or bulk. > 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. Thanks for your partly positive comments. I do hope to get more comments from the registrars. That's why I sent email on this mailing list ;-) IMHO, I think our extension might be useful to not only registrars but also registries. So I do hope we can hear from more registries related on CDN registration. Ning