From nobody Tue Jun 3 13:51:55 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020FD1A0337 for ; Tue, 3 Jun 2014 13:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv-vCVLq7qbm for ; Tue, 3 Jun 2014 13:51:48 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED621A0271 for ; Tue, 3 Jun 2014 13:51:23 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKU441RvPAoQupeiiiRAJ4OZ8+UgOFWCag@postini.com; Tue, 03 Jun 2014 13:51:41 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s53KpG4g020471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 16:51:17 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 16:51:16 -0400 From: "Gould, James" To: Christopher Browne Thread-Topic: [eppext] draft-ietf-eppext-keyrelay-00 Feedback Thread-Index: AQHPPTZwhTqnVBiC0UudESqSbZQK05rcFYQAgALzWICAAEbDgIBDSP2AgAUi7ACAOKWqgA== Date: Tue, 3 Jun 2014 20:51:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CFB39BF6604FCjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/XYVvReokxhJDO94z4bO7iYeWKvM Cc: Antoin Verschuren , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:51:52 -0000 --_004_CFB39BF6604FCjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CFB39BF6604FCjgouldverisigncom_" --_000_CFB39BF6604FCjgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It has been a while since we=92ve discussed this thread. Have the draft-ie= tf-eppext-keyrelay authors considered the feedback to include in a new vers= ion of the draft? Is there a plan for an EPPEXT meeting at the next IETF m= eeting in Toronto, where this can be worked out? In review, there were thr= ee options discussed on the thread: 1. Command-Response Extension * Key Relay Command as an extension to an empty domain update simila= r to the restore command in RFC 3915. * Key Relay Poll Response as an extension to the domain info respons= e. 2. Object Extension * Key Relay is an object that can be created via the create command = and can get information via the info command and response. The poll messag= e is simply a key relay info response. 3. Protocol and Object Mix Extension * As draft-ietf-eppext-keyrelay is currently defined using a Protoco= l Extension for the Key Relay Command and using an Object Extension for the= Key Relay Poll Message. As Christopher pointed out, we=92re talking about the protocol definition a= nd not if and what is stored in the Registry Database. In this case, the K= ey Relay does need to be stored somewhere to support the asynchronous consu= mption of the poll message by the losing hosting provider. As stated earli= er in this thread, I prefer option 2 =93Object Extension=94 since the gaini= ng hosting provider is creating a poll message to be consumed later by the = losing hosting provider. The poll message does reference the domain but is= fundamentally not an attribute of the domain itself. Thanks, -- JG [cid:8181E34D-61FE-4848-B65B-9E9ECABBC8ED] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Christopher Browne > Date: Monday, April 28, 2014 at 11:49 AM To: James Gould > Cc: Antoin Verschuren >, "eppext@ietf.org" > Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback Reactions here were broadly consistent with yours, James. The proposal that this be an object-less command wasn't terribly popular; s= everal people thought that it would be more logical for this to be somethin= g to be added or returned as an extension to the domain object. I understand there being a desire not to add more data to associate with do= mains in a registry, but frankly, if, as a registry operator operator, we p= lanned to support this, I think we'd rather associate the data with domains= than anything else. Alternately, to point at the opposite position, were we inclined to refuse = to associate key data with domains, we'd be mostly inclined to refuse to su= pport the extension altogether; that's an entirely simpler answer to the ma= tter. (And if the idea was to "not update anything in the DB", that would = indeed need to be the outcome. If it's not to go in the DB, then it can't = go in the Poll Queue, as that is in the DB.) The common thinking here was that it seemed like a good idea to: a) Add keyrelay data via an extension to b) Perhaps pass, to the recipient, a message indicating presence of such da= ta, via Poll Queue, perhaps also including all the data in the poll queue. c) Access the data via an extension to . That suggests that t= here might be storage of data beyond "just" in the poll queue. The proposal that James Gould just put forth for a Keyrelay object extensio= n seems no worse than that, and that seems cleaner than the initial proposa= l in that it presents the same sort of object/command division of things as= we have elsewhere in the EPP standards. I have a bit of a meta-comment... There are several references to database= s such as the following: "we looked at a way to do this communication step without even touching = the DB." It seems to me that there's something rather peculiar about discussing data= bases here; while I tend to "live the database" in many of my day-to-day du= ties, I try to be careful to take that hat off here. What we're doing here= is protocol design, and that should be kept independent of internal implem= entation considerations. Whether someone's using a relational database, ha= sh tables, IMS, or passing data through message-oriented middleware shouldn= 't be tightly encoded into the protocol. It also seems odd to me that it seems to be imagined that associating data = with a domain indicates that there *are* database updates, whereas associat= ing data with a poll queue indicates that there *are not* database updates = there, when poll queue entries still need to be kept durable enough to surv= ive until they are sent to their recipients. (Indeed, and this is certainly an aside, I'm a bit unhappy that RFC 4930 re= quires having a message count, e.g. - . Th= at's more data about what's in the queue than I think there ought to need t= o be.) --_000_CFB39BF6604FCjgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3A47B75A93E4B443807866B98AA17D48@verisign.com> Content-Transfer-Encoding: quoted-printable
It has been a while since we=92ve discussed this thread.  Have the draft-ietf-eppext-keyrelay authors considered the feedback to include in a = new version of the draft?  Is there a plan for an EPPEXT meeting at th= e next IETF meeting in Toronto, where this can be worked out?  In revi= ew, there were three options discussed on the thread:
  1. Command-Response Extension
    1. Key Re= lay Command as an extension to an empty domain update similar to the restor= e command in RFC 3915.
    2. Key Relay Poll Response as an extension to the = domain info response.
  2. Object Ext= ension
    1. Key Relay is an object that can b= e created via the create command and can get information via the info comma= nd and response.  The poll message is simply a key relay info response= .  
  3. Protocol and Object Mix Extension
    1. As draft-ietf-eppext-keyr= elay is currently defined using a Protocol Extension for the Key Relay Comm= and and using an Object Extension for the Key Relay Poll Message.
As Christopher pointed out, we=92re talking about the protocol definition a= nd not if and what is stored in the Registry Database.  In this case, = the Key Relay does need to be stored somewhere to support the asynchronous = consumption of the poll message by the losing hosting provider.  As stated earlier in this thread, I prefer = option 2 =93Object Extension=94 since the gaining hosting provider is creat= ing a poll message to be consumed later by the losing hosting provider. &nb= sp;The poll message does reference the domain but is fundamentally not an attribute of the domain itself.  

Thanks,

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com


From: Christopher Browne <cbbrowne@afilias.info>
Date: Monday, April 28, 2014 at 11:= 49 AM
To: James Gould <jgould@verisign.com>
Cc: Antoin Verschuren <antoin.verschuren@sidn.nl>, &q= uot;eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] draft-ietf-ep= pext-keyrelay-00 Feedback

Reactions here were broadly consistent with yours, James.<= br>
The proposal that this be an object-less command wasn't terribly popular; s= everal people thought that it would be more logical for this to be somethin= g to be added or returned as an extension to the domain object.

I understand there being a desire not to add more data to associate with do= mains in a registry, but frankly, if, as a registry operator operator, we p= lanned to support this, I think we'd rather associate the data with domains= than anything else.

Alternately, to point at the opposite position, were we inclined to refuse = to associate key data with domains, we'd be mostly inclined to refuse to su= pport the extension altogether; that's an entirely simpler answer to the ma= tter.  (And if the idea was to "not update anything in the DB", that would indeed need to be the outcome.=  If it's not to go in the DB, then it can't go in the Poll Queue, as = that is in the DB.)

The common thinking here was that it seemed like a good idea to:
a) Add keyrelay data via an extension to <domain:update>
b) Perhaps pass, to the recipient, a message indicating presence of such da= ta, via Poll Queue, perhaps also including all the data in the poll queue.<= /div>
c) Access the data via an extension to <domain:info>.  That= suggests that there might be storage of data beyond "just" in th= e poll queue.

The proposal that James Gould just put forth for a Keyrelay object ext= ension seems no worse than that, and that seems cleaner than the initial pr= oposal in that it presents the same sort of object/command division of thin= gs as we have elsewhere in the EPP standards.

I have a bit of a meta-comment...  There are several references to dat= abases such as the following:
   "we looked at a way to do this communication step without= even touching the DB."

It seems to me that there's something rather peculiar about discussing data= bases here; while I tend to "live the database" in many of my day= -to-day duties, I try to be careful to take that hat off here.  What w= e're doing here is protocol design, and that should be kept independent of internal implementation considerations.  Wheth= er someone's using a relational database, hash tables, IMS, or passing data= through message-oriented middleware shouldn't be tightly encoded into the = protocol.  

It also seems odd to me that it seems to be imagined that associating = data with a domain indicates that there *are* database updates, whereas ass= ociating data with a poll queue indicates that there *are not* database upd= ates there, when poll queue entries still need to be kept durable enough to survive until they are sent to the= ir recipients.

(Indeed, and this is certainly an aside, I'm a bit unhappy that RFC 49= 30 requires having a message count, e.g. - <msgQ count=3D"5" id=3D"12345"/>.  That's= more data about what's in the queue than I think there ought to need to be= .)
 --_000_CFB39BF6604FCjgouldverisigncom_-- --_004_CFB39BF6604FCjgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[175].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[175].png Content-Disposition: inline; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[175].png"; size=4109; creation-date="Tue, 03 Jun 2014 20:51:15 GMT"; modification-date="Tue, 03 Jun 2014 20:51:15 GMT" Content-ID: <8181E34D-61FE-4848-B65B-9E9ECABBC8ED> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CFB39BF6604FCjgouldverisigncom_-- From nobody Tue Jun 3 14:35:12 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D37E1A0383 for ; Tue, 3 Jun 2014 14:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgLlU7iRdDNK for ; Tue, 3 Jun 2014 14:35:04 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95B61A0381 for ; Tue, 3 Jun 2014 14:35:02 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKU44/gXdbyBUzbbtgjDCsxtl3/3xgtD2M@postini.com; Tue, 03 Jun 2014 14:34:58 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s53LKgis021488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 17:20:42 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 17:20:41 -0400 From: "Gould, James" To: Francisco Obispo Thread-Topic: [eppext] draft-ietf-eppext-idnmap Feedback Thread-Index: AQHPOlT+4eaYxDDdEE+oj57oox5INZrbCyoA///O6wCAALJlAIAAlk4AgAJ59gCAAHwvAIBDhWIAgD3Q4wA= Date: Tue, 3 Jun 2014 21:20:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_006_CFB3AF43606C6jgouldverisigncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/bIXGCMX2VPO1ea_8p0Z8UtdDQP4 Cc: "eppext@ietf.org" , =?Windows-1252?Q?Luis_Mu=F1oz?= Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:35:08 -0000 --_006_CFB3AF43606C6jgouldverisigncom_ Content-Type: multipart/related; boundary="_005_CFB3AF43606C6jgouldverisigncom_"; type="multipart/alternative" --_005_CFB3AF43606C6jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CFB3AF43606C6jgouldverisigncom_" --_000_CFB3AF43606C6jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It has been a while since we=92ve discussed this thread. Have the draft-ie= tf-eppext-idnmap authors considered the feedback to include in a new versio= n of the draft? Is there a plan for an EPPEXT meeting at the next IETF mee= ting in Toronto, where this can be worked out? In review, I included a pro= posal to support two models in draft-ietf-eppext-idnmap that offer the choi= ce of language or table. The text for the create could specify the use of = either the or element based on server policy. = Ideally an element would be defined in the XML schema that mad= e and a choice. For servers that support the l= anguage model, the info response should return both the language sent as we= ll as the resulting table that can be mapped to the IANA language or script= table. Thanks, -- JG [cid:A395BE95-2A23-4DEF-99D9-DC7840201DE4] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , James Gould = > Date: Friday, April 25, 2014 at 9:23 AM To: James Gould >, Francisc= o Obispo > Cc: "eppext@ietf.org" >, Luis Mu=F1oz = > Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback I have not received any feedback publicly or privately on this proposal. A= ny thoughts on this? Thanks, -- JG [cid:790FBBC9-7B94-4961-AC24-2D07A94F8E37] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , James Gould = > Date: Thursday, March 13, 2014 at 10:16 AM To: Francisco Obispo > Cc: "eppext@ietf.org" >, Luis Mu=F1oz = > Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback Francisco, How about supporting two models in draft-ietf-eppext-idnmap that matches th= e current and desired models supported by the servers, which is to support = a choice of language or table? The table element is intended to be a 1-to-= 1 match with the language or script tables posted to IANA and language is t= he language code per ISO 639-2. Ideally the choice would be explicitly def= ined in the XML schema, but to minimize the changes, it could look like bel= ow: Extensible Provisioning Protocol v1.0 domain name extension schema for IDN Table selection. The text for the create could specify the use of either or <= idn:table> element based on server policy. Ideally a element= would be defined in the XML schema that made and a choice. Below is an example of the create with the language: xn--espaol-zwa.example.com 2 ns1.example.net ns2.example.net jd1234 sh8013 sh8013 2fooBAR SPA español.example.com 123456 Below is an example of the create with the table (script table in this inst= ance that can be prefixed with http://www.iana.org/domains/idn-tables/ and = postfixed with .txt): xn--espaol-zwa.example.com 2 ns1.example.net ns2.example.net jd1234 sh8013 sh8013 2fooBAR com_latn_1.1 español.example.com 123456 For servers that support the language model, the info response should retur= n both the language sent as well as the resulting table that can be mapped = to the IANA language or script table: Command completed successfully xn--espaol-zwa.example.com EXAMPLE1-REP jd1234 sh8013 sh8013 ns1.example.com ns1.example.net ClientX ClientY 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2005-04-03T22:00:00.0Z 2000-04-08T09:00:00.0Z 2fooBAR SPA com_latn_1.1 español.example.com ABC-12345 54322-XYZ -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/12/14, 10:51 PM, "Francisco Obispo" > wrote: On Mar 11, 2014, at 10:02 AM, Gould, James > wrote: Francisco, I have the following issues with draft-ietf-eppext-idnmap that I would like= addressed: =95 The should be optional in the info response. We can make it optional. I=92ll add that to the next draft. =95 The is too flexible at this point. Based on draft-ietf-epp= ext-idnmap the registrars have no way of knowing what table values are requ= ired for any one server. This is a opportunity for the eppext WG to define= a standard model. My concern is related to clients having to deal with an infinite number of = server policies and schemes for the values. Are there any regi= strars out there that have the same concern? Well registrars currently don=92t have a way of knowing a lot of things, an= d even though I agree with you on the identifiers, there is no guarantee th= at the same identifier will result in the same code points, because that=92= s a registry policy decision. I don=92t want to create the impression that if you pass =93es=94 as the ta= ble identifier, you=92ll get the same results across all registries, in fac= t if you look at the tables on the IANA website, multiple registries have d= ifferent identifiers, and in some cases the code points don=92t even match. So even though I agree with you in concept, I think that it is unpractical = to try to standardize it. Francisco -- Francisco Obispo CTO - Registry Operations fobispo@uniregistry.com PGP Key ID: 0xB38DB1BE --_000_CFB3AF43606C6jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4975C483D14C714B956D3BAFC38B2E43@verisign.com> Content-Transfer-Encoding: quoted-printable
It has been a while since we=92ve di= scussed this thread.  Have the draft-ietf-eppext-idnmap&nb= sp;authors considered the feedback to include in a new version of the draft= ?  Is there a plan for an EPPEXT meeting at the next IETF meeting in Toronto, where this can be worked out?  In review,&nb= sp;I included a proposal to support two models in draft-ietf-eppext-idnmap tha= t offer the choice of language or table.  The text for the create could specify the use of either the <idn:language&g= t; or <idn:table> element based on server policy.   Ideally an &= lt;idn:create> element would be defined in the XML schema that made <= idn:language> and <idn:table> a choice.   For servers that support the language model, the info response should return b= oth the language sent as well as the resulting table that can be mapped to = the IANA language or script table.
Tha= nks,

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com


From: <Gould>, James Gould &l= t;jgould@verisign.com>
Date: Friday, April 25, 2014 at 9:2= 3 AM
To: James Gould <jgould@verisign.com>, Francisco Obispo <<= a href=3D"mailto:fobispo@uniregistry.com">fobispo@uniregistry.com> Cc: "eppext@ietf.org" <= eppext@ietf.org>, Luis Mu=F1oz <lem@uniregistry.com>
Subject: Re: [eppext] draft-ietf-ep= pext-idnmap Feedback

I have not received any feedback publicly or privately on this proposa= l.  Any thoughts on this?    

Thanks,

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

<= a href=3D"mailto:jgould@verisign.com">jgould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com


From: <Gould>, James Gould &l= t;jgould@verisign.com>
Date: Thursday, March 13, 2014 at 1= 0:16 AM
To: Francisco Obispo <fobispo@uniregistry.com>
Cc: "eppext@ietf.org" <= eppext@ietf.org>, Luis Mu=F1oz <lem@uniregistry.com>
Subject: Re: [eppext] draft-ietf-ep= pext-idnmap Feedback

Francisco,

How about supporting two m= odels in draft-ietf-eppext-idnmap that matches the current and desired mode= ls supported by the servers, which is to support a choice of language or ta= ble?  The table element is intended to be a 1-to-1 match with the language or script tables posted to IANA and= language is the language code per ISO 639-2.  Ideally the choice woul= d be explicitly defined in the XML schema, but to minimize the changes, it = could look like below:

<?xml version=3D"1= .0" encoding=3D"UTF-8"?>
<schema xmlns=3D"<= a href=3D"http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchem= a"
 xmlns:eppcom=3D"urn:ietf:p= arams:xml:ns:eppcom-1.0"
 xmlns:idn=3D"urn:ietf:para= ms:xml:ns:idn-1.0"
 targetNamespace=3D"urn:iet= f:params:xml:ns:idn-1.0"
 elementFormDefault=3D"qual= ified">
  <annotation><= /div>
<documentation>
Extensible Provisioning Protocol v1.0= domain name extension
schema for IDN Table selection.
</documentation>
  </annotation>=
  <import namespac= e=3D"urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation=3D"eppcom-1.0.xsd= "/>
  <!-- Child eleme= nts found in IDN -->
<element name=3D"data" t= ype=3D"idn:idnDataType"/>
<complexType name=3D"idnDataT= ype">
 <sequence>
<element name=3D"language&= quot; type=3D"language"
    minOccurs=3D"0&= quot;/>
<element name=3D"table&quo= t; type=3D"eppcom:minTokenType"
    minOccurs=3D"0&= quot;/>
<element name=3D"uname" = type=3D"eppcom:labelType"
     minOccurs=3D"= ;0"/>
 </sequence>
</complexType>
  <!-- End of sche= ma. -->
</schema>
   

The text for the create co= uld specify the use of either <idn:language> or <idn:table> ele= ment based on server policy.   Ideally a <idn:create> element wo= uld be defined in the XML schema that made <idn:language> and <idn:table> a choice.  

Below is an example of the= create with the language:

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>
<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
 <command>
   <create>
     <domain:create
       xmlns:domain=3D"urn:ietf:params:xml:ns= :domain-1.0">
     <domain:name>xn--espaol-zwa.example.com</= domain:name>
     <domain:period unit=3D"y">2</do= main:period>
     <domain:ns>
       <domain:hostObj>ns1.example.net</d= omain:hostObj>
       <domain:hostObj>ns2.example.net</d= omain:hostObj>
     </domain:ns>
     <domain:registrant>jd1234</domain:registr= ant>
     <domain:contact type=3D"admin">sh8= 013</domain:contact>
     <domain:contact type=3D"tech">sh80= 13</domain:contact>
     <domain:authInfo>
       <domain:pw>2fooBAR</domain:pw><= /div>
     </domain:authInfo>
     </domain:create>
   </create>
   <extension>
   <idn:data xmlns:idn=3D"urn:ietf:params:xml:ns:idn= -1.0">
      <idn:language>SPA</idn:language>
      <idn:uname>espa&#xF1;ol.example.com<= /idn:uname>
   </idn:data>
   </extension>
   <clTRID>123456</clTRID>
 </command>
</epp>

Below is an example of the= create with the table (script table in this instance that can be prefixed = with http://www.iana.org/doma= ins/idn-tables/ and postfixed with .txt):

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>
<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
 <command>
   <create>
     <domain:create
       xmlns:domain=3D"urn:ietf:params:xml:ns= :domain-1.0">
     <domain:name>xn--espaol-zwa.example.com</= domain:name>
     <domain:period unit=3D"y">2</do= main:period>
     <domain:ns>
       <domain:hostObj>ns1.example.net</d= omain:hostObj>
       <domain:hostObj>ns2.example.net</d= omain:hostObj>
     </domain:ns>
     <domain:registrant>jd1234</domain:registr= ant>
     <domain:contact type=3D"admin">sh8= 013</domain:contact>
     <domain:contact type=3D"tech">sh80= 13</domain:contact>
     <domain:authInfo>
       <domain:pw>2fooBAR</domain:pw><= /div>
     </domain:authInfo>
     </domain:create>
   </create>
   <extension>
   <idn:data xmlns:idn=3D"urn:ietf:params:xml:ns:idn= -1.0">
      <idn:table>com_latn_1.1</idn:table>= ;
      <idn:uname>espa&#xF1;ol.example.com<= /idn:uname>
   </idn:data>
   </extension>
   <clTRID>123456</clTRID>
 </command>
</epp>

For servers that support t= he language model, the info response should return both the language sent a= s well as the resulting table that can be mapped to the IANA language or sc= ript table:

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>
<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code=3D"1000">
      <msg>Command completed successfully</msg= >
    </result>
    <resData>
      <domain:infData
       xmlns:domain=3D"urn:ietf:params:xml:ns= :domain-1.0">
        <domain:name>xn--espaol-zwa.example.= com</domain:name>
        <domain:roid>EXAMPLE1-REP</domain= :roid>
        <domain:status s=3D"ok"/><= /div>
        <domain:registrant>jd1234</domain= :registrant>
        <domain:contact type=3D"admin"= ;>sh8013</domain:contact>
        <domain:contact type=3D"tech"= >sh8013</domain:contact>
        <domain:ns>
          <domain:hostObj>ns1.example.c= om</domain:hostObj>
          <domain:hostObj>ns1.example.n= et</domain:hostObj>
        </domain:ns>
        <domain:clID>ClientX</domain:clID= >
        <domain:crID>ClientY</domain:crID= >
        <domain:crDate>1999-04-03T22:00:00.0= Z</domain:crDate>
        <domain:upID>ClientX</domain:upID= >
        <domain:upDate>1999-12-03T09:00:00.0= Z</domain:upDate>
        <domain:exDate>2005-04-03T22:00:00.0= Z</domain:exDate>
        <domain:trDate>2000-04-08T09:00:00.0= Z</domain:trDate>
        <domain:authInfo>
          <domain:pw>2fooBAR</domain= :pw>
        </domain:authInfo>
      </domain:infData>
    </resData>
    <extension>
      <idn:data xmlns:idn=3D"urn:ietf:params:xm= l:ns:idn-1.0">
        <idn:language>SPA</idn:languag= e>
        <idn:table>com_latn_1.1</idn:t= able>
        <idn:uname>espa&#xF1;ol.example.= com</idn:uname>
      </idn:data>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>



-- 
 
JG
 

 
James Gould
Principal Software Engineer
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com



On 3/12/1= 4, 10:51 PM, "Francisco Obispo" <fobispo@uniregistry.com> wrote:


On Mar 11, 2014, at 10:02 AM, Gould, James <JGould@verisign.com> wrote:

Francisco,
I have the following issues with draft-ietf-eppext-idnmap that I would= like addressed:
=95 Th= e <idn:uname> should be optional in the info response.

We can make it optional. I=92ll add that to the next draft.

=95 Th= e <idn:table> is too flexible at this point.  Based on draf= t-ietf-eppext-idnmap the registrars have no way of knowing what table value= s are required for any one server.  This is a opportunity for the eppext WG to define a standard model.  
My concern is related to clients having to deal with an infinite numbe= r of server policies and schemes for the <idn:table> values. &nb= sp;Are there any registrars out there that have the same concern?

Well registrars currently don=92t have a way of knowing a lot of thing= s, and even though I agree with you on the identifiers, there is no guarant= ee that the same identifier will result in the same code points, because th= at=92s a registry policy decision.

I don=92t want to create the impression that if you pass =93es=94 as t= he table identifier, you=92ll get the same results across all registries, i= n fact if you look at the tables on the IANA website, multiple registries h= ave different identifiers, and in some cases the code points don=92t even match.

So even though I agree with you in concept, I think that it is unpract= ical to try to standardize it.

Francisco


--
Francisco Obispo
CTO - Registry Operations
PGP Key ID: 0xB38DB1BE


 --_000_CFB3AF43606C6jgouldverisigncom_-- --_005_CFB3AF43606C6jgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[176].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[176].png Content-Disposition: inline; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[176].png"; size=4109; creation-date="Tue, 03 Jun 2014 21:20:41 GMT"; modification-date="Tue, 03 Jun 2014 21:20:41 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_005_CFB3AF43606C6jgouldverisigncom_-- --_006_CFB3AF43606C6jgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[1].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[1].png Content-Disposition: attachment; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[1].png"; size=4109; creation-date="Tue, 03 Jun 2014 21:20:41 GMT"; modification-date="Tue, 03 Jun 2014 21:20:41 GMT" Content-ID: <790FBBC9-7B94-4961-AC24-2D07A94F8E37> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_006_CFB3AF43606C6jgouldverisigncom_-- From nobody Tue Jun 3 15:01:02 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839791A038A for ; Tue, 3 Jun 2014 15:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-e8dlks1zl4 for ; Tue, 3 Jun 2014 15:01:00 -0700 (PDT) Received: from mail.hostingnet.com (mail.hostingnet.com [208.87.35.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EBD1A0386 for ; Tue, 3 Jun 2014 15:00:59 -0700 (PDT) Received: from [192.168.105.12] (wsip-98-189-199-149.oc.oc.cox.net [98.189.199.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fobispo@uniregistry.com) by mail.hostingnet.com (Postfix) with ESMTPSA id 4770044EC6F; Tue, 3 Jun 2014 15:00:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Francisco Obispo In-Reply-To: Date: Tue, 3 Jun 2014 15:00:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Gould, James" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/Mgus47vTX0FWylk9ZjEx0xroCtQ Cc: "eppext@ietf.org" , =?windows-1252?Q?Luis_Mu=F1oz?= Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 22:01:01 -0000 On Jun 3, 2014, at 2:20 PM, Gould, James wrote: > It has been a while since we=92ve discussed this thread. Have the = draft-ietf-eppext-idnmap authors considered the feedback to include in a = new version of the draft? Is there a plan for an EPPEXT meeting at the = next IETF meeting in Toronto, where this can be worked out? =20 I don=92t have plans to be at that meeting, but I can certainly = participate remotely if we need an in-depth discussion. > In review, I included a proposal to support two models in = draft-ietf-eppext-idnmap that offer the choice of language or table. = The text for the create could specify the use of either the = or element based on server policy. Ideally = an element would be defined in the XML schema that made = and a choice. =20 We had a discussion a long time ago whether we should use = or , and we decided to go for the latter, because of the = complications of calling =93scripts=94 as languages, etc. the term = =93table=94 was neutral so we went for that instead. > For servers that support the language model, the info response should = return both the language sent as well as the resulting table that can be = mapped to the IANA language or script table. >=20 This is another complicated issue, table identifiers are registry = specific, and usually match some sort of registry policy. I don=92t = believe that this extension should aim at standardizing the table = identifiers, but instead, we should just let registries define them as = part of their local policies. If standardization ever happens, all we need to do is update registries = IDN policies, but not the IETF standard. The other piece has to do with the automatic language detection that you = talked about last time. I=92m not sure if that is better than having the = RAR pass it along every time. A registry could have overlapping unicode = code point tables associated with different policies, so letting the = server choose one could introduce some uncertainty to the RAR and = registrant, while passing the all the time does not. I=92ll try to push a change to the text by end of the week, and we can = review it from there. -- Francisco Obispo CTO - Registry Operations fobispo@uniregistry.com PGP Key ID: 0xB38DB1BE =20 From nobody Fri Jun 6 12:30:52 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2471A0073 for ; Fri, 6 Jun 2014 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjzLUl_7C0OQ for ; Fri, 6 Jun 2014 12:30:49 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738B71A0078 for ; Fri, 6 Jun 2014 12:30:48 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKU5IW4IELkAoKiLHQtjeL0fmJPuUyaKxq@postini.com; Fri, 06 Jun 2014 12:30:42 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s56JUdCQ021911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 15:30:39 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 15:30:39 -0400 From: "Gould, James" To: Francisco Obispo Thread-Topic: [eppext] draft-ietf-eppext-idnmap Feedback Thread-Index: AQHPOlT+4eaYxDDdEE+oj57oox5INZrbCyoA///O6wCAALJlAIAAlk4AgAJ59gCAAHwvAIBDhWIAgD3Q4wCAAE2+gIAESe2A Date: Fri, 6 Jun 2014 19:30:38 +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.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CFB73BE3611B6jgouldverisigncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/vAJVc3cAllnuNoyPNxyvsQfSZZQ Cc: "eppext@ietf.org" , =?Windows-1252?Q?Luis_Mu=F1oz?= Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 19:30:51 -0000 --_000_CFB73BE3611B6jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Francisco, I will not be able to make the IETF in person, but will attend remotely if = there is a meeting. As stated previously on the list, is too generic and implies so= me level of pre-coordination between the clients with each server to be abl= e to register IDN domain names. I have the following questions: 1. In the examples provided on the list, how would the client know to pa= ss =93com_latn_1.1=94 for the .com domain name? Can you describe the step= s that the client can or should make? 2. Is there some implied relationship between the table / script tables = loaded to the IANA site to the values, or is the sc= heme completely up to server policy? 3. Should the server provide some mechanism for clients to query for the= correct set of values? If so, do you have a proposal for the = mechanism? 4. Is the client required to auto-detect the appropriate val= ue based on pre-loading the tables on a per-TLD basis from the IANA site? 5. Do you believe that use of language codes per ISO 639-2 can be used f= or the values? Thanks, -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 6/3/14, 6:00 PM, "Francisco Obispo" > wrote: On Jun 3, 2014, at 2:20 PM, Gould, James > wrote: It has been a while since we=92ve discussed this thread. Have the draft-ie= tf-eppext-idnmap authors considered the feedback to include in a new versio= n of the draft? Is there a plan for an EPPEXT meeting at the next IETF mee= ting in Toronto, where this can be worked out? I don=92t have plans to be at that meeting, but I can certainly participate= remotely if we need an in-depth discussion. In review, I included a proposal to support two models in draft-ietf-eppext= -idnmap that offer the choice of language or table. The text for the creat= e could specify the use of either the or element= based on server policy. Ideally an element would be defined= in the XML schema that made and a choice. We had a discussion a long time ago whether we should use or= , and we decided to go for the latter, because of the complicat= ions of calling =93scripts=94 as languages, etc. the term =93table=94 was n= eutral so we went for that instead. For servers that support the language model, the info response should retur= n both the language sent as well as the resulting table that can be mapped = to the IANA language or script table. This is another complicated issue, table identifiers are registry specific,= and usually match some sort of registry policy. I don=92t believe that thi= s extension should aim at standardizing the table identifiers, but instead,= we should just let registries define them as part of their local policies. If standardization ever happens, all we need to do is update registries IDN= policies, but not the IETF standard. The other piece has to do with the automatic language detection that you ta= lked about last time. I=92m not sure if that is better than having the RAR = pass it along every time. A registry could have overlapping unicode code po= int tables associated with different policies, so letting the server choose= one could introduce some uncertainty to the RAR and registrant, while pass= ing the all the time does not. I=92ll try to push a change to the text by end of the week, and we can revi= ew it from there. -- Francisco Obispo CTO - Registry Operations fobispo@uniregistry.com PGP Key ID: 0xB38DB1BE --_000_CFB73BE3611B6jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5FBF05BE2E8CE54D81AB99856BC0CBAB@verisign.com> Content-Transfer-Encoding: quoted-printable
Francisco,

I will not be able to make the IETF in person, but will attend remotel= y if there is a meeting.  

As stated previously on the list, <idn:table> is too generic and= implies some level of pre-coordination between the clients with each serve= r to be able to register IDN domain names.  I have the following quest= ions:
  1. In the examples provided on the list, how would the client know to pass=  =93com_latn_1.1=94 for the .com domain name?   Can you describe = the steps that the client can or should make?  
  2. Is there some = implied relationship between the table / script tables loaded to the IANA s= ite to the <idn:table> values, or is the <idn:table> schem= e completely up to server policy?   
  3. Should the server pr= ovide some mechanism for clients to query for the correct set of <idn:ta= ble> values?  If so, do you have a proposal for the mechanism? &nbs= p;  
  4. Is the client required to auto-detect the appropriate <= ;idn:table> value based on pre-loading the tables on a per-TLD basis fro= m the IANA site?   
  5. Do you believe that use of language c= odes per ISO 639-2 can be used for the <idn:table> values?
Thanks,

-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould@verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com



On 6/3/14= , 6:00 PM, "Francisco Obispo" <fobispo@uniregistry.com> wrote:


On Jun 3, 2014, at 2:20 PM, Gould, James <JGould@verisign.com> wrote:

It has been a while since we=92ve discussed this thread.  Ha= ve the draft-ietf-eppext-idnmap authors considered the feedback to include = in a new version of the draft?  Is there a plan for an EPPEXT mee= ting at the next IETF meeting in Toronto, where this can be worked out?  

I don=92t have plans to be at that meeting, but I can certainly partic= ipate remotely if we need an in-depth discussion.

In review, I included a proposal to support two models in draft-ietf-e= ppext-idnmap that offer the choice of language or table.  The tex= t for the create could specify the use of either the <idn:language> o= r <idn:table> element based on server policy.   Ideally an <idn:create> element would be defined in the XML schema t= hat made <idn:language> and <idn:table> a choice.  

We had a discussion a long time ago whether we should use <idn:lang= uage> or <idn:table>, and we decided to go for the latter, because= of the complications of calling =93scripts=94 as languages, etc. the term = =93table=94 was neutral so we went for that instead.

For servers that support the language model, the info response should = return both the language sent as well as the resulting table that can be ma= pped to the IANA language or script table.

This is another complicated issue, table identifiers are registry spec= ific, and usually match some sort of registry policy. I don=92t believe tha= t this extension should aim at standardizing the table identifiers, but ins= tead, we should just let registries define them as part of their local policies.

If standardization ever happens, all we need to do is update registrie= s IDN policies, but not the IETF standard.

The other piece has to do with the automatic language detection that y= ou talked about last time. I=92m not sure if that is better than having the= RAR pass it along every time. A registry could have overlapping unicode co= de point tables associated with different policies, so letting the server choose one could introduce some uncertaint= y to the RAR and registrant, while passing the <idn:table> all the ti= me does not.

I=92ll try to push a change to the text by end of the week, and we can= review it from there.

--
Francisco Obispo
CTO - Registry Operations
PGP Key ID: 0xB38DB1BE


--_000_CFB73BE3611B6jgouldverisigncom_-- From nobody Wed Jun 18 07:52:39 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159891A0279 for ; Wed, 18 Jun 2014 07:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-3-FJBfcvrj for ; Wed, 18 Jun 2014 07:52:35 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECC21A0263 for ; Wed, 18 Jun 2014 07:52:34 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so774459qae.5 for ; Wed, 18 Jun 2014 07:52:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OsFWi1An+b9My14ZgSnTJQAJ1As63+kZqaoO+e8HOW4=; b=DqqA2UPVP3gjenxesXFMZ+5f4YmyS40a7Z0byhWp0J2noLLSdNBmMtIZ3zBnI7Tvbx fdLySRQypZPF/wU8aIpEe8rgPOeQ3lORnhFZJzdqUnM2ytCN0xtSrpRgYx0j+jYn9MCV XkIh9jPdmJViEeaY6NkWWXWQjTdmFffJ/DQQitxLDnZ7vQ/wbQ5B0KiCjBhmsKu1d4pA aon8xRMH6x/fmVcgMA+3xzACxWf2D77VEFSfgI0nsTjEi//EMZSVhf6SXTRkGHq5t9pH XZR8srI7LyYQZyL87a8USsGwcjwse6IY2NrGqK/PKM3k7Ko25iSbnRoeWR6GlRjIBloP 71pw== X-Gm-Message-State: ALoCoQl7Pg5hNv8gD8hYuXEbFI8UTmNYykq0AmFbsTnFSPADtACjO+6WbgPxQ+G2KZRs96+yRhG3 X-Received: by 10.140.26.196 with SMTP id 62mr3536422qgv.37.1403103154061; Wed, 18 Jun 2014 07:52:34 -0700 (PDT) Received: from jgalvin-lt.local ([73.180.137.82]) by mx.google.com with ESMTPSA id u7sm3619385qat.2.2014.06.18.07.52.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Jun 2014 07:52:33 -0700 (PDT) Message-ID: <53A1A7D3.6070502@elistx.com> Date: Wed, 18 Jun 2014 10:53:07 -0400 From: James Galvin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hollenbeck, Scott" , "eppext@ietf.org" References: <20140530135524.24706.83740.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F49409C57@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49409C57@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/O19gvI5qW9nVtGIHFdsZj6C3i7g Subject: Re: [eppext] I-D Action: draft-ietf-eppext-reg-05.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 14:52:37 -0000 Thanks Scott for moving this along! The chairs have compared notes and we want to move this document along too. Although it is a bit formal we want to start a working group last call on the document. Our working group is small and perhaps we could get away with not doing it but for the archives it is a step that almost all working groups actually do. So, unless anyone objects, you will see a message in the next day or so announcing a "WG LAST CALL" for the document. It is common for a last call to last at least two weeks. We are thinking three weeks just to avoid any conflicts with the ICANN meeting next week and the US national holiday the week after. The last call would end on Friday, 11 July 2014. If anyone has any questions or concerns with this please do speak up. We will be following up to move each of the other documents forward as soon as we get this one started. Thanks! Jim Antoin On 5/30/14, 9:57 AM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Friday, May 30, 2014 9:55 AM >> To: i-d-announce@ietf.org >> Cc: eppext@ietf.org >> Subject: [eppext] I-D Action: draft-ietf-eppext-reg-05.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Extensible Provisioning Protocol >> Extensions Working Group of the IETF. >> >> Title : Extension Registry for the Extensible >> Provisioning Protocol >> Author : Scott Hollenbeck >> Filename : draft-ietf-eppext-reg-05.txt >> Pages : 11 >> Date : 2014-05-30 > This update includes a new paragraph describing how registry entries can and can't be updated. Please take a look and bring any concerns to the list for discussion. > > Scott > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext From nobody Thu Jun 19 00:09:21 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBC01A031D for ; Thu, 19 Jun 2014 00:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdWXq-acJysr for ; Thu, 19 Jun 2014 00:09:17 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFFA1A0299 for ; Thu, 19 Jun 2014 00:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:user-agent:x-originating-ip:content-type:mime-version; bh=ASdyxS1eQ2sfNGUydu+j9qJ0c3B5mGwB975Zyu6GNdM=; b=qtj+jMrmWYuLQJmjoHvmDEJA4vTVXdqbpj2mzE7/JU8aqyJCu5kPiOUzBvz+3YM/AHAmuLitsmZmDduC2D7yqP9KZHB4xdW7C48dg3mXJa+3SrxDFYft3MlhERuIilfUcTVhBStVG9HobBIz0o1RrQrS9DU2j7Dm7VqmiW4UcH4= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s5J79Fuu032698-s5J79Fuw032698 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 19 Jun 2014 09:09:15 +0200 Received: from KAMBX1.SIDN.local ([fe80::501d:affc:30a9:4edf]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Thu, 19 Jun 2014 09:09:11 +0200 From: Marc Groeneweg To: "eppext@ietf.org" Thread-Topic: [eppext] draft-ietf-eppext-keyrelay-00 Feedback Thread-Index: AQHPPS0YgCxNWBlNXk+aQfXNlhT+aJrcBN6AgAKwP4CAAInngIBDOB+AgAR9xwCAAEctgIBRZEmA Date: Thu, 19 Jun 2014 07:09:11 +0000 Message-ID: References: <535E2642.3010104@sidn.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [192.168.4.164] Content-Type: multipart/alternative; boundary="_000_CFC857BE157C2marcgroenewegsidnnl_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/Aug8UG8jZqL6qALdzC8xxB24Xbw Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 07:09:19 -0000 --_000_CFC857BE157C2marcgroenewegsidnnl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Thank you all for the given feedback. The authors have considered your feedback, and they make sense EPP protocol wise. When we started the EPPEXT WG, we promised we would document what is currently implemented, and that is the draft as is. The changes are significant to the current implementation at SIDN, our registrars and what's implemented in EPP clients already, so changing the draft would mean there would be no implementation. So we would like to stick to the Draft, and register this version as a SIDN version of the Key Relay. How about registering EPP-keyrelay as is for now with the draft as documentation, as it is an implemented extension, and progress with a new version of the draft aimed to be accepted as EPP RFC for a generic relay command? All your feedback is being considered as input for this new version, which we are discussing internally at this moment. Regards, (on behalf of the authors) Marc Groeneweg SIDN --_000_CFC857BE157C2marcgroenewegsidnnl_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
All,

Thank you all for the given feedback. The authors h= ave considered your
feedback, an= d they make sense EPP protocol wise.

When we started th= e EPPEXT WG, we promised we would document what is
currently implemen= ted, and that is the draft as is. The changes are
significant to the= current implementation at SIDN, our registrars and
what's implemented= in EPP clients already, so changing the draft would
mean there would b= e no implementation. So we would like to stick to the
Draft, and registe= r this version as a SIDN version of the Key Relay.

How about register= ing EPP-keyrelay as is for now with the draft as 
documentation, as = it is an implemented extension, and progress with a
new version of the= draft aimed to be accepted as EPP RFC for a 
generic relay comm= and? All your feedback is being considered as input for
this new version, = which we are discussing internally at this moment.

Regards,
(on behalf of the = authors)

Marc Groeneweg
SIDN
--_000_CFC857BE157C2marcgroenewegsidnnl_-- From nobody Thu Jun 19 04:16:17 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D53F1A036D for ; Thu, 19 Jun 2014 04:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnaAhHfT3wO4 for ; Thu, 19 Jun 2014 04:16:12 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BBC1A014F for ; Thu, 19 Jun 2014 04:16:09 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKU6LGeREa1zZk0G8q3L4OChesltsWy5GU@postini.com; Thu, 19 Jun 2014 04:16:12 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s5JBG82a032423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 07:16:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 19 Jun 2014 07:16:08 -0400 From: "Hollenbeck, Scott" To: Marc Groeneweg , "eppext@ietf.org" Thread-Topic: [eppext] draft-ietf-eppext-keyrelay-00 Feedback Thread-Index: AQHPPS0YgCxNWBlNXk+aQfXNlhT+aJrcBN6AgAKwP4CAAInngIBDOB+AgAR9xwCAAEctgIBRZEmAgABD9WA= Date: Thu, 19 Jun 2014 11:16:07 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494246E5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <535E2642.3010104@sidn.nl> In-Reply-To: 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: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F494246E5BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/AKJkPG8inBSkjwgxD4_dFE2G2rM Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 11:16:15 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494246E5BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Marc Groeneweg Sent: Thursday, June 19, 2014 3:09 AM To: eppext@ietf.org Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback All, Thank you all for the given feedback. The authors have considered your feedback, and they make sense EPP protocol wise. When we started the EPPEXT WG, we promised we would document what is currently implemented, and that is the draft as is. The changes are significant to the current implementation at SIDN, our registrars and what's implemented in EPP clients already, so changing the draft would mean there would be no implementation. So we would like to stick to the Draft, and register this version as a SIDN version of the Key Relay. How about registering EPP-keyrelay as is for now with the draft as documentation, as it is an implemented extension, and progress with a new version of the draft aimed to be accepted as EPP RFC for a generic relay command? All your feedback is being considered as input for this new version, which we are discussing internally at this moment. [SAH] I see value in this. Documents that describe existing implementations= are often published as Informational RFCs, and the approach we're taking = should be able to accommodate the registration of non-standard extensions. = I'm OK with the idea of using this document to explore that kind of registr= ation use case. Scott --_000_831693C2CDA2E849A7D7A712B24E257F494246E5BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: EppExt [= mailto:eppext-bounces@ietf.org] On Behalf Of Marc Groeneweg
Sent: Thursday, June 19, 2014 3:09 AM
To: eppext@ietf.org
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

 

All,

 

Thank you all for the given feedback. The authors have con= sidered your

feedback, and they make sense EPP protocol wise.<= span style=3D"font-size:10.5pt;font-family:"Calibri","sans-s= erif";color:black">

 

When we started the EPPEXT WG, we promised we would document = what is

currently implemented, and that is the draft as is. The chang= es are

significant to the current implementation at SIDN, our regist= rars and

what's implemented in EPP clients already, so changing the dr= aft would

mean there would be no implementation. So we would like to st= ick to the

Draft, and register this version as a SIDN version of the Key= Relay.

 

How about registering EPP-keyrelay as is for now with the dra= ft as 

documentation, as it is an implemented extension, and progres= s with a

new version of the draft aimed to be accepted as EPP RFC for = a 

generic relay command? All your feedback is being considered = as input for

this new version, which we are discussing internally at this = moment.

 

[SAH] I see value in this. Documents that = describe existing implementations are often published as Informational RFCs= , and the approach we’re taking  should be able to accommodate the registration of non-standard extensions. I’m OK with the idea of= using this document to explore that kind of registration use case.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F494246E5BRN1WNEXMBX01vc_-- From nobody Sat Jun 21 06:14:46 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1311A0769 for ; Sat, 21 Jun 2014 06:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.503 X-Spam-Level: * X-Spam-Status: No, score=1.503 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arXLQXqr9bjb for ; Sat, 21 Jun 2014 06:14:43 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [120.29.249.162]) by ietfa.amsl.com (Postfix) with ESMTP id 081411A064E for ; Sat, 21 Jun 2014 06:14:29 -0700 (PDT) Received: from offex01.ausregistrygroup.local (HELO ausregistry.com.au) ([10.30.220.61]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 21 Jun 2014 23:12:11 +1000 Received: from MELEX01.ausregistrygroup.local ([10.11.220.61]) by OFFEX01.ausregistrygroup.local ([169.254.2.102]) with mapi id 14.03.0181.006; Sat, 21 Jun 2014 23:14:33 +1000 From: Chris Wright To: "eppext@ietf.org" Thread-Topic: Review of draft-ietf-eppext-reg-05 Thread-Index: Ac+NUqoPpEpiaB9xSzaNShHoGgFu6A== Date: Sat, 21 Jun 2014 13:14:33 +0000 Message-ID: <89A7E0AE8025CE4FA324483B8D02A6B224010927@MELEX01> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.195.12] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/faaXQ3wp_qyB5E3Zph4hO_upTjc Cc: "James M. Galvin" Subject: [eppext] Review of draft-ietf-eppext-reg-05 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 13:14:45 -0000 Hi all, I have finally sat down and had a look at draft-ietf-eppext-reg-05. I am on= ly concerned about one section (admittedly probably the core section of the= document). The following text in 3.1.1 "A request to register a new, undeployed extension that duplicates the func= tionality of an existing, deployed extension should be rejected with guidan= ce provided to the requestor to consider the existing, deployed extension." In my opinion is too strong and should be revised to something along the li= nes of the following (I am sure someone else can wordsmith this better than= I can): "A person/entity requesting to register a new, un-deployed extension that i= ncludes similar functionality to an existing, registered extension should h= ave that fact pointed out to them and be asked to reconsider their request = for registration. Should the person/entity still feel they have a compellin= g reason to register the extension (which they don't necessarily need to di= sclose), as long as all other requirements are met, the mere fact of simila= rity should not be a sufficient reason for rejection."=20 Essentially my intention is that any well documented extension specificatio= n should be allowed in the registry for a number of reasons: - 1. If two parties develop extensions in parallel, one shouldn't be locked= out just because the other got in first - I certainly would not want to th= row away all my engineering effort. Anyone developing a decent extension wi= ll actually build it in code first and test it to see if it works properly = - before they try to register it (we don't want the registry filling up wit= h abandoned extensions that are going nowhere, not maintained and blocking = other extensions). In fact it probably should be a requirement that an exte= nsion is deployed in the wild for it to remain registered. Perhaps extensio= ns need more elaborate status than the currently proposed 'active', 'inacti= ve. They almost have a life-cycle: -- a. 'in-development' - so if two parties are working on the same thing a= t the same time they can see that -- b. 'registered' - once it is complete -- c. 'in-use' - at least one domain name registry is actively using the ex= tension -- d. 'depreciated' - the extension has been superseded by another extensio= n that enhances the functionality -- e. 'archived' - an extension that was once 'in-use' but is no longer act= ively used by any registries Of course this complicates matters for how we should manage the status' and= may not be worth the overhead, but it certainly would make things a lot cl= earer. I would probably leave it to the person who registered the extension= to manage, with expert to step in when required. (Probably with a post to = the list first) - 2. Who is to say that the existing extension is right for another operato= r - all too often extensions are tightly coupled to implementation details/= limitations etc. of the underlying registry., I would not want to find myse= lf in a position of needing to significantly re-engineer a production syste= m to retro-fit someone else extension into it, simply because they got ther= e first. There is always going to be a cost benefit trade of for each indiv= idual registry to make, I know there is a dream of creating a single unifie= d set of extensions, but I don't think we can force this (I just don't thin= k it is reality). There can be legal reasons (For example in Australia we h= ave GST not VAT (they are effectively the same thing) but we legally must r= efer to it as GST. If someone had a VAT extension in the registry, would a = GST extension not be allowed as it is a duplicate?), technical reasons and = other reasons why it might not always be possible. Having a centralised reg= istry for people to look for prior work before embarking on their own is a = good thing, and will help to reduce the number of extensions but forcing it= is not the right thing to do, and just won't work, registries will end up = just ignoring the extension registry, do what they want to do, and we will = be no better off - my view is that being more permissive is a better approa= ch. Just like what happens with software libraries. Look at java libraries,= Maven Central is effectively a (limited) registry of the available java li= braries, and any good java developer worth there salt will look for an exis= ting library that meets their needs before trying to implement their own, b= ut maven central doesn't disallow libraries that do similar or the same thi= ng from registering themselves. It allows the developers to do the right th= ing, just as we should trust registries to 'do the right thing' (we are rea= lly talking about developers here anyway, so it's built in there DNA) - and= know that when they are not 'doing the right thing' they have a damn good = reason. With Java libraries eventually popularity wins and a good library b= ecomes the most popular or the most used, and if there is enough outside pr= essure (in our case registrars) it will become the norm to use a particular= ones. It is not our job to become the extension police - we should just fa= cilitate the user community (broader than the IETF community) to be able to= influence one another as appropriate. If this is really a big problem, the= users (registrars) will unite and force a fix. Having a registry is a good= start to that. - 3. I also think that the text 'duplicates the functionality of' is a very= tricky concept to qualify. What if a new extension does part of what an al= ready registered extension does but adds something logical to it, adds enha= nced functionality, where it would just be silly to create a further separa= te extension for? Is this a duplicate? What if an already registered extens= ion is found to be wrong, or unworkable, and a new one is required? These a= re just two examples I can think of where this defining a 'duplicate' will = be hard to judge, I am sure there is many more. Thanks Chris From nobody Sun Jun 22 08:34:20 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F401A039A for ; Sun, 22 Jun 2014 08:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_LOOK=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGpiXKpxSjxt for ; Sun, 22 Jun 2014 08:34:16 -0700 (PDT) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCF31A0393 for ; Sun, 22 Jun 2014 08:34:13 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKU6b3YBMWuBfsjnr94YquJ1yPY69Wc8mq@postini.com; Sun, 22 Jun 2014 08:34:15 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s5MFXpAW028394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Jun 2014 11:33:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sun, 22 Jun 2014 11:33:48 -0400 From: "Hollenbeck, Scott" To: "chris@ausregistry.com.au" , "eppext@ietf.org" Thread-Topic: Review of draft-ietf-eppext-reg-05 Thread-Index: Ac+NUqoPpEpiaB9xSzaNShHoGgFu6AA2AmSQ Date: Sun, 22 Jun 2014 15:33:49 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49434FFC@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <89A7E0AE8025CE4FA324483B8D02A6B224010927@MELEX01> In-Reply-To: <89A7E0AE8025CE4FA324483B8D02A6B224010927@MELEX01> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/9azV6VQmZ4g6SNfjDz67s3nvvkU Cc: "James M. Galvin" Subject: Re: [eppext] Review of draft-ietf-eppext-reg-05 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 15:34:18 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Chris Wright > Sent: Saturday, June 21, 2014 9:15 AM > To: eppext@ietf.org > Cc: James M. Galvin > Subject: [eppext] Review of draft-ietf-eppext-reg-05 >=20 > Hi all, >=20 > I have finally sat down and had a look at draft-ietf-eppext-reg-05. I > am only concerned about one section (admittedly probably the core > section of the document). The following text in 3.1.1 >=20 > "A request to register a new, undeployed extension that duplicates the > functionality of an existing, deployed extension should be rejected > with guidance provided to the requestor to consider the existing, > deployed extension." >=20 > In my opinion is too strong and should be revised to something along > the lines of the following (I am sure someone else can wordsmith this > better than I can): >=20 > "A person/entity requesting to register a new, un-deployed extension > that includes similar functionality to an existing, registered > extension should have that fact pointed out to them and be asked to > reconsider their request for registration. Should the person/entity > still feel they have a compelling reason to register the extension > (which they don't necessarily need to disclose), as long as all other > requirements are met, the mere fact of similarity should not be a > sufficient reason for rejection." >=20 > Essentially my intention is that any well documented extension > specification should be allowed in the registry for a number of > reasons: >=20 > - 1. If two parties develop extensions in parallel, one shouldn't be > locked out just because the other got in first - I certainly would not > want to throw away all my engineering effort. Anyone developing a > decent extension will actually build it in code first and test it to > see if it works properly - before they try to register it (we don't > want the registry filling up with abandoned extensions that are going > nowhere, not maintained and blocking other extensions). In fact it > probably should be a requirement that an extension is deployed in the > wild for it to remain registered. Perhaps extensions need more > elaborate status than the currently proposed 'active', 'inactive. They > almost have a life-cycle: > -- a. 'in-development' - so if two parties are working on the same > thing at the same time they can see that > -- b. 'registered' - once it is complete > -- c. 'in-use' - at least one domain name registry is actively using > the extension > -- d. 'depreciated' - the extension has been superseded by another > extension that enhances the functionality > -- e. 'archived' - an extension that was once 'in-use' but is no longer > actively used by any registries > Of course this complicates matters for how we should manage the status' > and may not be worth the overhead, but it certainly would make things a > lot clearer. I would probably leave it to the person who registered the > extension to manage, with expert to step in when required. (Probably > with a post to the list first) >=20 > - 2. Who is to say that the existing extension is right for another > operator - all too often extensions are tightly coupled to > implementation details/limitations etc. of the underlying registry., I > would not want to find myself in a position of needing to significantly > re-engineer a production system to retro-fit someone else extension > into it, simply because they got there first. There is always going to > be a cost benefit trade of for each individual registry to make, I know > there is a dream of creating a single unified set of extensions, but I > don't think we can force this (I just don't think it is reality). There > can be legal reasons (For example in Australia we have GST not VAT > (they are effectively the same thing) but we legally must refer to it > as GST. If someone had a VAT extension in the registry, would a GST > extension not be allowed as it is a duplicate?), technical reasons and > other reasons why it might not always be possible. Having a centralised > registry for peop! > le to loo > k for prior work before embarking on their own is a good thing, and > will help to reduce the number of extensions but forcing it is not the > right thing to do, and just won't work, registries will end up just > ignoring the extension registry, do what they want to do, and we will > be no better off - my view is that being more permissive is a better > approach. Just like what happens with software libraries. Look at java > libraries, Maven Central is effectively a (limited) registry of the > available java libraries, and any good java developer worth there salt > will look for an existing library that meets their needs before trying > to implement their own, but maven central doesn't disallow libraries > that do similar or the same thing from registering themselves. It > allows the developers to do the right thing, just as we should trust > registries to 'do the right thing' (we are really talking about > developers here anyway, so it's built in there DNA) - and know that > when they are not 'doing ! > the right > thing' they have a damn good reason. With Java libraries eventually > popularity wins and a good library becomes the most popular or the most > used, and if there is enough outside pressure (in our case registrars) > it will become the norm to use a particular ones. It is not our job to > become the extension police - we should just facilitate the user > community (broader than the IETF community) to be able to influence one > another as appropriate. If this is really a big problem, the users > (registrars) will unite and force a fix. Having a registry is a good > start to that. >=20 > - 3. I also think that the text 'duplicates the functionality of' is a > very tricky concept to qualify. What if a new extension does part of > what an already registered extension does but adds something logical to > it, adds enhanced functionality, where it would just be silly to create > a further separate extension for? Is this a duplicate? What if an > already registered extension is found to be wrong, or unworkable, and a > new one is required? These are just two examples I can think of where > this defining a 'duplicate' will be hard to judge, I am sure there is > many more. I want to give as much guidance to whomever ends up providing the designate= d expert function if/when the registry becomes reality. They will certainly= encounter requests that we haven't considered, and I'll concede the it may= be difficult to accurately define functional duplication - but that's why = we're asking people to perform the task. So, I'm more or less OK with Chris= ' proposal but I do want to question one part of it: "Should the person/entity still feel they have a compelling reason to regis= ter the extension (which they don't necessarily need to disclose)" I'm OK with the "compelling reason" part, but if the designated expert asks= a question and the response is "sorry, I'm not going to explain" (or silen= ce), why do we need designated experts at all? We're currently asking a hum= an (or group of humans) to make a qualitative assessment of every registrat= ion request. That task may require dialog. The expert should have the abili= ty to reject a request in the absence of satisfactory answers to their ques= tions. So, I'll make a counter proposal: "A potential registrant who submits a request to register a new, un-deploye= d extension that includes similar functionality to an existing, registered = extension should be made aware of the existing extension. The registrant sh= ould be asked to reconsider their request given the existence of a similar = extension. Should they decline to do so perceived similarity should not be = a sufficient reason for rejection as long as all other requirements are met= ." I think this addresses the spirit of Chris' suggested text while preserving= the ability of the expert to assess the request. Scott From nobody Sun Jun 22 08:51:02 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01421A0395 for ; Sun, 22 Jun 2014 08:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.803 X-Spam-Level: *** X-Spam-Status: No, score=3.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MANGLED_LOOK=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGkNURudMfOj for ; Sun, 22 Jun 2014 08:51:00 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [120.29.255.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEB51A0393 for ; Sun, 22 Jun 2014 08:50:59 -0700 (PDT) Received: from offex01.ausregistrygroup.local (HELO ausregistry.com.au) ([10.30.220.61]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 23 Jun 2014 01:50:42 +1000 Received: from MELEX01.ausregistrygroup.local ([10.11.220.61]) by OFFEX01.ausregistrygroup.local ([169.254.2.102]) with mapi id 14.03.0181.006; Mon, 23 Jun 2014 01:50:08 +1000 From: Chris Wright To: "Hollenbeck, Scott" , "eppext@ietf.org" Thread-Topic: Review of draft-ietf-eppext-reg-05 Thread-Index: Ac+NUqoPpEpiaB9xSzaNShHoGgFu6AA2AmSQAAG0LVA= Date: Sun, 22 Jun 2014 15:50:07 +0000 Message-ID: <89A7E0AE8025CE4FA324483B8D02A6B224015064@MELEX01> References: <89A7E0AE8025CE4FA324483B8D02A6B224010927@MELEX01> <831693C2CDA2E849A7D7A712B24E257F49434FFC@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49434FFC@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.195.116] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/wQwEE5h_LCp4E2hNw_BJa1ZZ7Y0 Cc: "James M. Galvin" Subject: Re: [eppext] Review of draft-ietf-eppext-reg-05 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 15:51:02 -0000 Thanks Scott, I like your suggested wording. If we added that I think the document is in = a good place. Thanks Chris -----Original Message----- From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]=20 Sent: Monday, 23 June 2014 1:34 AM To: Chris Wright; eppext@ietf.org Cc: James M. Galvin Subject: RE: Review of draft-ietf-eppext-reg-05 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Chris=20 > Wright > Sent: Saturday, June 21, 2014 9:15 AM > To: eppext@ietf.org > Cc: James M. Galvin > Subject: [eppext] Review of draft-ietf-eppext-reg-05 >=20 > Hi all, >=20 > I have finally sat down and had a look at draft-ietf-eppext-reg-05. I=20 > am only concerned about one section (admittedly probably the core=20 > section of the document). The following text in 3.1.1 >=20 > "A request to register a new, undeployed extension that duplicates the=20 > functionality of an existing, deployed extension should be rejected=20 > with guidance provided to the requestor to consider the existing,=20 > deployed extension." >=20 > In my opinion is too strong and should be revised to something along=20 > the lines of the following (I am sure someone else can wordsmith this=20 > better than I can): >=20 > "A person/entity requesting to register a new, un-deployed extension=20 > that includes similar functionality to an existing, registered=20 > extension should have that fact pointed out to them and be asked to=20 > reconsider their request for registration. Should the person/entity=20 > still feel they have a compelling reason to register the extension=20 > (which they don't necessarily need to disclose), as long as all other=20 > requirements are met, the mere fact of similarity should not be a=20 > sufficient reason for rejection." >=20 > Essentially my intention is that any well documented extension=20 > specification should be allowed in the registry for a number of > reasons: >=20 > - 1. If two parties develop extensions in parallel, one shouldn't be=20 > locked out just because the other got in first - I certainly would not=20 > want to throw away all my engineering effort. Anyone developing a=20 > decent extension will actually build it in code first and test it to=20 > see if it works properly - before they try to register it (we don't=20 > want the registry filling up with abandoned extensions that are going=20 > nowhere, not maintained and blocking other extensions). In fact it=20 > probably should be a requirement that an extension is deployed in the=20 > wild for it to remain registered. Perhaps extensions need more=20 > elaborate status than the currently proposed 'active', 'inactive. They=20 > almost have a life-cycle: > -- a. 'in-development' - so if two parties are working on the same=20 > thing at the same time they can see that > -- b. 'registered' - once it is complete > -- c. 'in-use' - at least one domain name registry is actively using=20 > the extension > -- d. 'depreciated' - the extension has been superseded by another=20 > extension that enhances the functionality > -- e. 'archived' - an extension that was once 'in-use' but is no=20 > longer actively used by any registries Of course this complicates=20 > matters for how we should manage the status' > and may not be worth the overhead, but it certainly would make things=20 > a lot clearer. I would probably leave it to the person who registered=20 > the extension to manage, with expert to step in when required.=20 > (Probably with a post to the list first) >=20 > - 2. Who is to say that the existing extension is right for another=20 > operator - all too often extensions are tightly coupled to=20 > implementation details/limitations etc. of the underlying registry., I=20 > would not want to find myself in a position of needing to=20 > significantly re-engineer a production system to retro-fit someone=20 > else extension into it, simply because they got there first. There is=20 > always going to be a cost benefit trade of for each individual=20 > registry to make, I know there is a dream of creating a single unified=20 > set of extensions, but I don't think we can force this (I just don't=20 > think it is reality). There can be legal reasons (For example in=20 > Australia we have GST not VAT (they are effectively the same thing)=20 > but we legally must refer to it as GST. If someone had a VAT extension=20 > in the registry, would a GST extension not be allowed as it is a=20 > duplicate?), technical reasons and other reasons why it might not=20 > always be possible. Having a centralised registry for peop! > le to loo > k for prior work before embarking on their own is a good thing, and=20 > will help to reduce the number of extensions but forcing it is not the=20 > right thing to do, and just won't work, registries will end up just=20 > ignoring the extension registry, do what they want to do, and we will=20 > be no better off - my view is that being more permissive is a better=20 > approach. Just like what happens with software libraries. Look at java=20 > libraries, Maven Central is effectively a (limited) registry of the=20 > available java libraries, and any good java developer worth there salt=20 > will look for an existing library that meets their needs before trying=20 > to implement their own, but maven central doesn't disallow libraries=20 > that do similar or the same thing from registering themselves. It=20 > allows the developers to do the right thing, just as we should trust=20 > registries to 'do the right thing' (we are really talking about=20 > developers here anyway, so it's built in there DNA) - and know that=20 > when they are not 'doing ! > the right > thing' they have a damn good reason. With Java libraries eventually=20 > popularity wins and a good library becomes the most popular or the=20 > most used, and if there is enough outside pressure (in our case=20 > registrars) it will become the norm to use a particular ones. It is=20 > not our job to become the extension police - we should just facilitate=20 > the user community (broader than the IETF community) to be able to=20 > influence one another as appropriate. If this is really a big problem,=20 > the users > (registrars) will unite and force a fix. Having a registry is a good=20 > start to that. >=20 > - 3. I also think that the text 'duplicates the functionality of' is a=20 > very tricky concept to qualify. What if a new extension does part of=20 > what an already registered extension does but adds something logical=20 > to it, adds enhanced functionality, where it would just be silly to=20 > create a further separate extension for? Is this a duplicate? What if=20 > an already registered extension is found to be wrong, or unworkable,=20 > and a new one is required? These are just two examples I can think of=20 > where this defining a 'duplicate' will be hard to judge, I am sure=20 > there is many more. I want to give as much guidance to whomever ends up providing the designate= d expert function if/when the registry becomes reality. They will certainly= encounter requests that we haven't considered, and I'll concede the it may= be difficult to accurately define functional duplication - but that's why = we're asking people to perform the task. So, I'm more or less OK with Chris= ' proposal but I do want to question one part of it: "Should the person/entity still feel they have a compelling reason to regis= ter the extension (which they don't necessarily need to disclose)" I'm OK with the "compelling reason" part, but if the designated expert asks= a question and the response is "sorry, I'm not going to explain" (or silen= ce), why do we need designated experts at all? We're currently asking a hum= an (or group of humans) to make a qualitative assessment of every registrat= ion request. That task may require dialog. The expert should have the abili= ty to reject a request in the absence of satisfactory answers to their ques= tions. So, I'll make a counter proposal: "A potential registrant who submits a request to register a new, un-deploye= d extension that includes similar functionality to an existing, registered = extension should be made aware of the existing extension. The registrant sh= ould be asked to reconsider their request given the existence of a similar = extension. Should they decline to do so perceived similarity should not be = a sufficient reason for rejection as long as all other requirements are met= ." I think this addresses the spirit of Chris' suggested text while preserving= the ability of the expert to assess the request. Scott From nobody Tue Jun 24 06:28:17 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC9E1B2935; Tue, 24 Jun 2014 06:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57rqKnK0SMzU; Tue, 24 Jun 2014 06:28:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC321B29DD; Tue, 24 Jun 2014 06:28:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624132812.22959.92491.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 06:28:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/CaPk_I_QCsOePyQfP0b9qo6GTZY Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-reg-06.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:28:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Provisioning Protocol Extensions Working Group of the IETF. Title : Extension Registry for the Extensible Provisioning Protocol Author : Scott Hollenbeck Filename : draft-ietf-eppext-reg-06.txt Pages : 11 Date : 2014-06-24 Abstract: The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP and it specifies a format for an IANA registry to record those extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-reg-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-reg-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 24 06:34:02 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8212B1B29F6 for ; Tue, 24 Jun 2014 06:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zodX6gZF-_q for ; Tue, 24 Jun 2014 06:33:57 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4D11B29EE for ; Tue, 24 Jun 2014 06:33:49 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKU6l+PN8JJcDqCwi/AR3IBWFp6AWqWl16@postini.com; Tue, 24 Jun 2014 06:33:49 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s5ODXkRF017669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Jun 2014 09:33:46 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 09:33:46 -0400 From: "Hollenbeck, Scott" To: "eppext@ietf.org" Thread-Topic: [eppext] I-D Action: draft-ietf-eppext-reg-06.txt Thread-Index: AQHPj7Ap2fl3G/iWoUODo6Jc5Em53puAQStA Date: Tue, 24 Jun 2014 13:33:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4943911A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140624132812.22959.92491.idtracker@ietfa.amsl.com> In-Reply-To: <20140624132812.22959.92491.idtracker@ietfa.amsl.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 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/08vnaLroXwnqvJS6htVLvShBe1Y Subject: Re: [eppext] I-D Action: draft-ietf-eppext-reg-06.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:34:01 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, June 24, 2014 9:28 AM > To: i-d-announce@ietf.org > Cc: eppext@ietf.org > Subject: [eppext] I-D Action: draft-ietf-eppext-reg-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Extensible Provisioning Protocol > Extensions Working Group of the IETF. >=20 > Title : Extension Registry for the Extensible > Provisioning Protocol > Author : Scott Hollenbeck > Filename : draft-ietf-eppext-reg-06.txt > Pages : 11 > Date : 2014-06-24 >=20 > Abstract: > The Extensible Provisioning Protocol (EPP) includes features to add > functionality by extending the protocol. It does not, however, > describe how those extensions are managed. This document describes > a > procedure for the registration and management of extensions to EPP > and it specifies a format for an IANA registry to record those > extensions. This version addresses a review comment received from Chris Wright as descr= ibed in this thread: http://www.ietf.org/mail-archive/web/eppext/current/msg00121.html With this update all comments that I am aware of have been addressed. Scott From nobody Wed Jun 25 01:46:17 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72251B2B1C for ; Wed, 25 Jun 2014 01:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7cLJYJOVkb8 for ; Wed, 25 Jun 2014 01:46:12 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BA91B2B18 for ; Wed, 25 Jun 2014 01:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=8QbqZDj7Y9X3iPtyR+de6ti0XXHvGC9WhZMQsFDVzHk=; b=Uob9wejDa1zE6aRXQZbpvoP1uWhA2A7tAQvDwvr5Rqu19Bfb1kyNT2blIkS6qMLmdx0eQrI16est+nwBX3ldwDvXbFQu5eHEdw+q93l0XPIOVYuw9hFJLrb8cv+wEK1WcTSk9nqAjSZilQq3orwl+u/OYvLo2w+5yxA1WQIZf1E= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s5P8kAMj021829-s5P8kAMl021829 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 25 Jun 2014 10:46:10 +0200 Received: from [94.198.152.216] (94.198.152.216) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 25 Jun 2014 10:46:08 +0200 Message-ID: <53AA8C4F.20807@sidn.nl> Date: Wed, 25 Jun 2014 10:46:07 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "eppext@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.216] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/XFdfBeW1ob8NjVIdUoJKnOi-904 Subject: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 08:46:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, This is the starting of the WGLC on the Extension Registry for the Extensible Provisioning Protocol. This was discussed in London and on the mailing list, an we believe the outcome is incorporated in the document and is ready for WGLC. The current versions of this documents can be found here: https://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ http://www.ietf.org/id/draft-ietf-eppext-reg-06.txt We'll have a 2,5 week period for comments, closing on Friday, 11 July 2014. thanks - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTqoxPAAoJEDqHrM883Agn2MQH/1lKA6/9RMHK6nTMmeAtU/aJ qJykFcZWjl1wA4e8rSyg+vMT+QaPezclQMMSAfM4fsTgByFf014ZQWkb1EX8Xzlg 1J2aAYX/rHr+6nAGVhZhtKSUfQ7KagldBmtVVrUKDHQP/NZFuU6GV/aPNxq841N8 QT1pUsmyvzf838k0SQY9BJHjtZs+eW/Lq29MKqvWdotv5tM9gaIp6kK6Oj2FAN++ tojUK7WNYYEh+v4LAoqOa+008ScuReE2NOuxZl/oX76M6FT11Dm0bpmsof6uUHB4 4Gacp5qUitTIYsNpVxUIe50Rqk+dFUW2PyjTXyYJWuxQO+xPhPU3QSMz+mr0RXw= =+LK5 -----END PGP SIGNATURE----- From nobody Wed Jun 25 07:40:32 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848C21B2CCD for ; Wed, 25 Jun 2014 07:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5ZJX2fyirOQ for ; Wed, 25 Jun 2014 07:40:21 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3111B2CD6 for ; Wed, 25 Jun 2014 07:40:12 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKU6rfTBhAmstD8dosYkKE89a9JQBLfK1H@postini.com; Wed, 25 Jun 2014 07:40:12 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s5PEeBML018611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Jun 2014 10:40:11 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 25 Jun 2014 10:40:10 -0400 From: "Hollenbeck, Scott" To: "eppext@ietf.org" Thread-Topic: [eppext] Working Group Last call for draft-ietf-eppext-reg Thread-Index: AQHPkFHuW1oWNgQ3kU+3DoSxy7bwg5uB5SKg Date: Wed, 25 Jun 2014 14:40:09 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4943ACA0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <53AA8C4F.20807@sidn.nl> In-Reply-To: <53AA8C4F.20807@sidn.nl> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/PcAuC1MAESTH0aKyRB9u4hdIxXY Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 14:40:24 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Antoin > Verschuren > Sent: Wednesday, June 25, 2014 4:46 AM > To: eppext@ietf.org > Subject: [eppext] Working Group Last call for draft-ietf-eppext-reg >=20 > Greetings, >=20 > This is the starting of the WGLC on the Extension Registry for the > Extensible Provisioning Protocol. This was discussed in London and on > the mailing list, an we believe the outcome is incorporated in the > document and is ready for WGLC. > The current versions of this documents can be found here: >=20 > https://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ > http://www.ietf.org/id/draft-ietf-eppext-reg-06.txt >=20 >=20 > We'll have a 2,5 week period for comments, closing on Friday, 11 July > 2014. For anyone new to the IETF process: statements of support are just as signi= ficant to the last call process as identification of issues or errors. If y= ou're happy with the document as-is, please say so. Silence makes it more d= ifficult for our chairs and AD to determine consensus. Scott From nobody Thu Jun 26 02:48:20 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1F91B2F7C for ; Thu, 26 Jun 2014 02:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz-6QMcw4z-W for ; Thu, 26 Jun 2014 02:48:13 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE201B2ADF for ; Thu, 26 Jun 2014 02:48:13 -0700 (PDT) Received: from Gavins-MacBook-Pro.local (2-193.icannmeeting.org [199.91.193.2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id DB50B9E48; Thu, 26 Jun 2014 09:48:10 +0000 (UTC) Message-ID: <53ABEC5A.9090007@centralnic.com> Date: Thu, 26 Jun 2014 10:48:10 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Antoin Verschuren X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="af9lwHNog4jEsNpXXFKiwabDAl8cHwDPS" Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/GE9pOfLFFbuEoU6sO0EOn2oXmYE Cc: eppext@ietf.org Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 09:48:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --af9lwHNog4jEsNpXXFKiwabDAl8cHwDPS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 25 Jun 2014 10:46:07 +0200, Antoin Verschuren wrote: > Greetings, >=20 > This is the starting of the WGLC on the Extension Registry for the > Extensible Provisioning Protocol. This was discussed in London and on > the mailing list, an we believe the outcome is incorporated in the > document and is ready for WGLC. > The current versions of this documents can be found here: >=20 > https://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ > http://www.ietf.org/id/draft-ietf-eppext-reg-06.txt >=20 >=20 > We'll have a 2,5 week period for comments, closing on Friday, 11 July > 2014. >=20 > thanks I have reviewed the current draft and consider it ready for publication. I'm not aware of any outstanding issues with it. Gavin. --=20 Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. --af9lwHNog4jEsNpXXFKiwabDAl8cHwDPS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOr7FoACgkQ6H45IPkjtM6WcwCdGCYmZaTnI3Wk1+l8NR5c7y0/ +vgAn3rttteXT6w0DSUhSOAZbXJdfCos =ASVP -----END PGP SIGNATURE----- --af9lwHNog4jEsNpXXFKiwabDAl8cHwDPS-- From nobody Thu Jun 26 11:50:51 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F851B2C7C for ; Thu, 26 Jun 2014 11:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIcTriddq7il for ; Thu, 26 Jun 2014 11:50:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BD21B30BA for ; Thu, 26 Jun 2014 11:35:55 -0700 (PDT) Received: from [10.143.195.93] ([31.55.12.2]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5QIZpLG049611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Jun 2014 11:35:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.12.2] claimed to be [10.143.195.93] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <53AA8C4F.20807@sidn.nl> Date: Thu, 26 Jun 2014 19:35:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53AA8C4F.20807@sidn.nl> To: "eppext@ietf.org" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/ZzulpRjDvKGmkjfkvKSlTKZHNE8 Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 18:50:50 -0000 I have read the document and think it is ready to progress to the IETF. = (And I say that as someone who is reading it for the first time, so I = really did read the whole thing.) I wish that the experts could reject = applications for similar extensions, but grudgingly agree that anything = that has actually been implemented is accepted as long as it is = well-docuemented. --Paul Hoffman= From nobody Thu Jun 26 18:24:20 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4CA1B30BC for ; Thu, 26 Jun 2014 18:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeOG4cBwJkEH for ; Thu, 26 Jun 2014 18:24:16 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 127D01B30BB for ; Thu, 26 Jun 2014 18:24:15 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 27 Jun 2014 09:24:12 +0800 Date: Fri, 27 Jun 2014 09:25:01 +0800 From: "Linlin Zhou" To: "Antoin Verschuren" , "eppext@ietf.org" References: <53AA8C4F.20807@sidn.nl> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <201406270924569504127@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart075245175617_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/YXTeYVWnTjonk2gqSy_mMWYIt1E Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 01:24:19 -0000 This is a multi-part message in MIME format. ------=_001_NextPart075245175617_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkuDQpPbmx5IG9uZSBuaXQsIEkgdGhp bmsgYSBjb21tYSBpcyBtaXNzaW5nIGluIHNlY3Rpb24gMy4yLjQuDQpJZiB0aGUgcmVnaXN0cmFu dCBiZWNvbWVzIHVuYXZhaWxhYmxlIG9yIG90aGVyd2lzZSB1bnJlc3BvbnNpdmUsIHRoZSBkZXNp Z25hdGVkIGV4cGVydCBNQVkgc3VibWl0IGEgcmVnaXN0cmF0aW9uIGZvcm0gdG8gSUFOQSB0byB1 cGRhdGUgdGhlIHJlZ2lzdHJhbnQgaW5mb3JtYXRpb24uDQoNCg0KDQpMaW5saW4gWmhvdQ0KIA0K RnJvbTogQW50b2luIFZlcnNjaHVyZW4NCkRhdGU6IDIwMTQtMDYtMjUgMTY6NDYNClRvOiBlcHBl eHRAaWV0Zi5vcmcNClN1YmplY3Q6IFtlcHBleHRdIFdvcmtpbmcgR3JvdXAgTGFzdCBjYWxsIGZv ciBkcmFmdC1pZXRmLWVwcGV4dC1yZWcNCi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0t LS0NCkhhc2g6IFNIQTENCiANCkdyZWV0aW5ncywNCiANClRoaXMgaXMgdGhlIHN0YXJ0aW5nIG9m IHRoZSBXR0xDIG9uIHRoZSBFeHRlbnNpb24gUmVnaXN0cnkgZm9yIHRoZQ0KRXh0ZW5zaWJsZSBQ cm92aXNpb25pbmcgUHJvdG9jb2wuICBUaGlzIHdhcyBkaXNjdXNzZWQgaW4gTG9uZG9uIGFuZCBv bg0KdGhlIG1haWxpbmcgbGlzdCwgYW4gd2UgYmVsaWV2ZSB0aGUgb3V0Y29tZSBpcyBpbmNvcnBv cmF0ZWQgaW4gdGhlDQpkb2N1bWVudCBhbmQgaXMgcmVhZHkgZm9yIFdHTEMuDQpUaGUgY3VycmVu dCB2ZXJzaW9ucyBvZiB0aGlzIGRvY3VtZW50cyBjYW4gYmUgZm91bmQgaGVyZToNCiANCiAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWVwcGV4dC1yZWcvDQog ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWVwcGV4dC1yZWctMDYudHh0DQog DQogDQpXZSdsbCBoYXZlIGEgMiw1IHdlZWsgcGVyaW9kIGZvciBjb21tZW50cywgY2xvc2luZyBv biBGcmlkYXksIDExIEp1bHkNCjIwMTQuDQogDQp0aGFua3MNCiANCi0gLS0gDQpBbnRvaW4gVmVy c2NodXJlbg0KIA0KVGVjaG5pY2FsIFBvbGljeSBBZHZpc29yIFNJRE4NCk1lYW5kZXIgNTAxLCBQ TyBCb3ggNTAyMiwgNjgwMiBFQSBBcm5oZW0sIFRoZSBOZXRoZXJsYW5kcw0KIA0KUDogKzMxIDI2 IDM1MjU1MDAgIE06ICszMSA2IDIzMzY4OTcwDQpNYWlsdG86IGFudG9pbi52ZXJzY2h1cmVuQHNp ZG4ubmwNClhNUFA6IGFudG9pbi52ZXJzY2h1cmVuQGphYmJlci5zaWRuLm5sDQpIVFRQOi8vd3d3 LnNpZG4ubmwvDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogR251UEcg djEuNC4xMSAoR05VL0xpbnV4KQ0KIA0KaVFFY0JBRUJBZ0FHQlFKVHFveFBBQW9KRURxSHJNODgz QWduMk1RSC8xbEtBNi85Uk1ISzZuVE1tZUF0VS9hSg0KcUp5a0ZjWldqbDF3QTRlOHJTeWcrdk1U K1FhUGV6Y2xRTU1TQWZNNGZzVGdCeUZmMDE0WlFXa2IxRVg4WHpsZw0KMUoyYUFZWC9ySHIrNm5B R1ZoWmh0S1NVZlE3S2FnbGRCbXRWVnJVS0RIUVAvTlpGdVU2R1YvYVBOeHE4NDFOOA0KUVQxcFVz bXl2emY4MzhrMFNRWTlCSkhqdFpzK2VXL0xxMjlNS3F2V2RvdHY1dE05Z2FJcDZrSzZPajJGQU4r Kw0KdG9qVUs3V05ZWUVoK3Y0TEFvcU9hKzAwOFNjdVJlRTJOT3V4Wmwvb1g3Nk02RlQxMURtMGJw bXNvZjZ1VUhCNA0KNEdhY3A1cVVpdFRJWXNOcFZ4VUllNTBScWsrZEZVVzJQeWpUWHlZSld1eFFP K3hQaFBVM1FTTXorbXIwUlh3PQ0KPStMSzUNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVwcEV4 dCBtYWlsaW5nIGxpc3QNCkVwcEV4dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lcHBleHQNCg== ------=_001_NextPart075245175617_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
I agree that this docu= ment is ready.
Only one nit, I think a comma is missing in secti= on 3.2.4.
If the registrant becomes unavai=
lable or otherwise unresponsive, the designated expert MAY submit a regist=
ration form to IANA to update the registrant information.
=0A

=0A
Linlin Zhou
<= /div>=0A
 
From:&n= bsp;Antoin Verschuren
Date: 2014-06-25 16:46
To: <= a href=3D"mailto:eppext@ietf.org">eppext@ietf.org
Subject= : [eppext] Working Group Last call for draft-ietf-eppext-reg
-----BEGIN PGP SIGNED MESSAGE-----
=0A
Has= h: SHA1
=0A
 
=0A
Greetings,
=0A
 =0A
This is the starting of the WGLC on the Extension Registry for = the
=0A
Extensible Provisioning Protocol.  This was discusse= d in London and on
=0A
the mailing list, an we believe the outcom= e is incorporated in the
=0A
document and is ready for WGLC.=0A
The current versions of this documents can be found here:
= =0A
 
=0A
    https://datatracker.ietf.or= g/doc/draft-ietf-eppext-reg/
=0A
    http://www.ie= tf.org/id/draft-ietf-eppext-reg-06.txt
=0A
 
=0A
&n= bsp;
=0A
We'll have a 2,5 week period for comments, closing on Fr= iday, 11 July
=0A
2014.
=0A
 
=0A
thanks=0A
 
=0A
- --
=0A
Antoin Verschuren
= =0A
 
=0A
Technical Policy Advisor SIDN
=0A
Mea= nder 501, PO Box 5022, 6802 EA Arnhem, The Netherlands
=0A
 =
=0A
P: +31 26 3525500  M: +31 6 23368970
=0A
Mailt= o: antoin.verschuren@sidn.nl
=0A
XMPP: antoin.verschuren@jabber.s= idn.nl
=0A
HTTP://www.sidn.nl/
=0A
-----BEGIN PGP SIGNAT= URE-----
=0A
Version: GnuPG v1.4.11 (GNU/Linux)
=0A
&nbs= p;
=0A
iQEcBAEBAgAGBQJTqoxPAAoJEDqHrM883Agn2MQH/1lKA6/9RMHK6nTMme= AtU/aJ
=0A
qJykFcZWjl1wA4e8rSyg+vMT+QaPezclQMMSAfM4fsTgByFf014ZQW= kb1EX8Xzlg
=0A
1J2aAYX/rHr+6nAGVhZhtKSUfQ7KagldBmtVVrUKDHQP/NZFuU= 6GV/aPNxq841N8
=0A
QT1pUsmyvzf838k0SQY9BJHjtZs+eW/Lq29MKqvWdotv5t= M9gaIp6kK6Oj2FAN++
=0A
tojUK7WNYYEh+v4LAoqOa+008ScuReE2NOuxZl/oX7= 6M6FT11Dm0bpmsof6uUHB4
=0A
4Gacp5qUitTIYsNpVxUIe50Rqk+dFUW2PyjTXy= YJWuxQO+xPhPU3QSMz+mr0RXw=3D
=0A
=3D+LK5
=0A
-----END PG= P SIGNATURE-----
=0A
 
=0A
________________________= _______________________
=0A
EppExt mailing list
=0A
EppE= xt@ietf.org
=0A
https://www.ietf.org/mailman/listinfo/eppext=0A
=0A ------=_001_NextPart075245175617_=------ From nobody Thu Jun 26 19:23:44 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473731B30E4 for ; Thu, 26 Jun 2014 19:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9gOVKvBIHkA for ; Thu, 26 Jun 2014 19:23:41 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C07B1B30CA for ; Thu, 26 Jun 2014 19:23:41 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s5R2Neqr010415 for ; Fri, 27 Jun 2014 11:23:40 +0900 X-AuditID: ac120820-b7f638e000000e09-ef-53acd5acf44a Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 1B.16.03593.CA5DCA35; Fri, 27 Jun 2014 11:23:40 +0900 (JST) Date: Fri, 27 Jun 2014 11:23:33 +0900 (JST) Message-Id: <20140627.112333.32727126.kambe@jprs.co.jp> To: eppext@ietf.org From: Naoki Kambe In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4943ACA0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <53AA8C4F.20807@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F4943ACA0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsWyRoiFT3fN1TXBBpOOCltcuH2P2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGcv3X2EtmChccfvTDLYGxg98XYycHBICJhLf278zQthiEhfu rWfrYuTiEBI4ySjRsfweE0iCRUBbYuec6awgNq+AuUT7+kfsILaIgLDE/n1rWUBsYQF3iQfn r4PVswmoSCy7txnM5hQIl2g6vQlsgZBAocSnTWeB4hwc/AL6ElObUiD22kk0/X3HAhLmFRCU +LtDGCTMLKAl0TPjMTuELS+x/e0c5gmM/LMQqmYhqZqFpGoBI/MqRpn8tDTd4tS8lOLcdAND vZLKfL2sgqJivWQQvYkRHHIcCjsYZ5wyOMQowMGoxMPb5bUmWIg1say4MvcQoyQHk5IoL/cR oBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3tjjQDnelMTKqtSifJiUNAeLkjgvs3FvsJBAemJJ anZqakFqEUxWhoNDSYJ3z2WgRsGi1PTUirTMnBKENBMHJ8hwHqDhC0BqeIsLEnOLM9Mh8qcY JaXEeWeCJARAEhmleXC9rxjFgV4Q5t0BkuUBpg+4rldAA5mABpoXrAIZWJKIkJJqYJRO4T3u cnzFnc/9myfp+U9dvLT+bt+qrYsY7t1+lXxok52mzLmn0Yv1giw2vmSXbF9wKXGXyCfNLuZ/ 8g2zVVp+fOdzbet69e5U3JGNtXsCZkzKdirv3cF+iLdpofjch3G1Fd/XHTSP4SjU3mqUwFKT 4f3vi8+M7QIJZuUbOU+qXj7BGBTd8ViJpTgj0VCLuag4EQDI0MV23AIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/Q4Z9h7_RcL00Q3gy_Q3iGcLDEC0 Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 02:23:43 -0000 Hello, Here is a couple of minor comments: == 2. Introduction ... RFCs 5730 and 5735 do not describe how extension development can be ^^^^ 3735? managed and coordinated. This has led to a situation in which server === 3.2.1. Required Information ... TLDs: A case-insensitive text string description of the top-level domain (or domains) for which the extension has been specified. "Any" or "ANY" MUST be used if the extension is not associated with a specific top-level domain. Multiple TLDs SHOULD be specified as a list of domain names separated by commas, e.g. ".com, .net". # In case of an IDN TLD, should a-label or u-label or both be # specified? (sorry for the duplication if already discussed) ... specification the IPR disclosure MAY be filed with the IETF in accordance with RFCs 3979 [RFC3979] as updated by RFC 4879 [RFC4879]. ^^^^ RFC === Regards, Naoki Kambe From: "Hollenbeck, Scott" Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg Date: Wed, 25 Jun 2014 14:40:09 +0000 > > -----Original Message----- > > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Antoin > > Verschuren > > Sent: Wednesday, June 25, 2014 4:46 AM > > To: eppext@ietf.org > > Subject: [eppext] Working Group Last call for draft-ietf-eppext-reg > > > > Greetings, > > > > This is the starting of the WGLC on the Extension Registry for the > > Extensible Provisioning Protocol. This was discussed in London and on > > the mailing list, an we believe the outcome is incorporated in the > > document and is ready for WGLC. > > The current versions of this documents can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ > > http://www.ietf.org/id/draft-ietf-eppext-reg-06.txt > > > > > > We'll have a 2,5 week period for comments, closing on Friday, 11 July > > 2014. > > For anyone new to the IETF process: statements of support are just as significant to the last call process as identification of issues or errors. If you're happy with the document as-is, please say so. Silence makes it more difficult for our chairs and AD to determine consensus. > > Scott > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > From nobody Fri Jun 27 01:41:56 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7089E1B278A for ; Fri, 27 Jun 2014 01:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9b8QTvOluo6 for ; Fri, 27 Jun 2014 01:41:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB981B2F2A for ; Fri, 27 Jun 2014 01:41:54 -0700 (PDT) Received: from [10.32.64.173] (31-221-87-78.cust-31.exponential-e.net [31.221.87.78] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5R8fpMr086743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 27 Jun 2014 01:41:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 31-221-87-78.cust-31.exponential-e.net [31.221.87.78] (may be forged) claimed to be [10.32.64.173] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <20140627.112333.32727126.kambe@jprs.co.jp> Date: Fri, 27 Jun 2014 09:41:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B366C4F-3456-4306-AE33-7904FB130DA5@vpnc.org> References: <53AA8C4F.20807@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F4943ACA0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140627.112333.32727126.kambe@jprs.co.jp> To: eppext@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/GH6VcZVyX1qpClYttYX_DP24lv4 Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:41:55 -0000 On Jun 27, 2014, at 3:23 AM, Naoki Kambe wrote: > =3D=3D=3D > 3.2.1. Required Information >=20 > ... >=20 > TLDs: A case-insensitive text string description of the top-level > domain (or domains) for which the extension has been specified. > "Any" or "ANY" MUST be used if the extension is not associated with = a > specific top-level domain. Multiple TLDs SHOULD be specified as a > list of domain names separated by commas, e.g. ".com, .net". >=20 > # In case of an IDN TLD, should a-label or u-label or both be > # specified? (sorry for the duplication if already discussed) A-label. Unless we trust the application process to correctly maintain = UTF-8 throughout (and I certainly don't), the A-label would be a much = better format. --Paul Hoffman= From nobody Fri Jun 27 02:12:07 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC351B2F38 for ; Fri, 27 Jun 2014 02:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfrnGpIdJfHX for ; Fri, 27 Jun 2014 02:12:04 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7A71B2B03 for ; Fri, 27 Jun 2014 02:12:03 -0700 (PDT) Received: from [192.168.0.11] (unknown [2.123.84.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 9BDFD45C01 for ; Fri, 27 Jun 2014 09:12:01 +0000 (UTC) Message-ID: <53AD3560.8070504@centralnic.com> Date: Fri, 27 Jun 2014 10:12:00 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: eppext@ietf.org References: <20140627090422.26314.10937.idtracker@ietfa.amsl.com> In-Reply-To: <20140627090422.26314.10937.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE X-Forwarded-Message-Id: <20140627090422.26314.10937.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p963kvUpICDO4h5d7cX1e8pk5pcbr63LF" Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/fEG2LUkT8tzk9iuflXCj-9DTNxg Subject: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-02.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 09:12:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p963kvUpICDO4h5d7cX1e8pk5pcbr63LF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear colleagues, I've just uploaded a new version of the fee extension draft, your feedback would be much appreciated. Changes in this version: * added default values and made certain command elements optional to keep commands simple. * support for multiple fee and credit elements in responses. Fee elements may also take "refundable", "grace-period" and "description" attributes. * support for providing the registrar's current account balance and/or credit limit in responses. * Use a single child element of instead of multiple elements for each domain. * added an element to allow classification of domains into categories or tiers. Many thanks to all who contributed feedback and suggestions. Regards, -------- Original Message -------- Subject: New Version Notification for draft-brown-epp-fees-02.txt Date: Fri, 27 Jun 2014 02:04:22 -0700 From: internet-drafts@ietf.org To: Gavin Brown , Gavin Brown A new version of I-D, draft-brown-epp-fees-02.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-brown-epp-fees Revision: 02 Title: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Document date: 2014-06-27 Group: Individual Submission Pages: 33 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-02.txt Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-0= 2 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for registry fees. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. --p963kvUpICDO4h5d7cX1e8pk5pcbr63LF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOtNWAACgkQ6H45IPkjtM5SogCfR0LEOzRyOaTq1i5tk1kO31B5 vysAmwdG+uAi0H4zdYA8hCAPz/9vAGwp =GXDh -----END PGP SIGNATURE----- --p963kvUpICDO4h5d7cX1e8pk5pcbr63LF-- From nobody Sun Jun 29 18:25:40 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC52B1A0081 for ; Sun, 29 Jun 2014 18:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.657 X-Spam-Level: ** X-Spam-Status: No, score=2.657 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndw73fyiSn9c for ; Sun, 29 Jun 2014 18:25:38 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599DF1A0080 for ; Sun, 29 Jun 2014 18:25:38 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s5U1PaBb023345 for ; Mon, 30 Jun 2014 10:25:36 +0900 X-AuditID: ac120820-b7f638e000000e09-e7-53b0bc9079da Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id E7.C8.03593.09CB0B35; Mon, 30 Jun 2014 10:25:36 +0900 (JST) Date: Mon, 30 Jun 2014 10:25:36 +0900 (JST) Message-Id: <20140630.102536.112824787.kambe@jprs.co.jp> To: eppext@ietf.org From: Naoki Kambe In-Reply-To: <8B366C4F-3456-4306-AE33-7904FB130DA5@vpnc.org> References: <831693C2CDA2E849A7D7A712B24E257F4943ACA0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140627.112333.32727126.kambe@jprs.co.jp> <8B366C4F-3456-4306-AE33-7904FB130DA5@vpnc.org> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsWyRoiFT3fCng3BBme3i1hcuH2P2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGe2vPrEWfGWveP5wKUsD40S2LkZODgkBE4mdjw9D2WISF+6t B7K5OIQETjJK3P67lhkkwSKgLdGx9DI7iM0rYCEx8eAZFhBbREBYYv++tWC2sIC7xIPz15lA bDYBFYll9zaD2ZwCNhKzT79ighi6jVHi5ZddQIM4OPgF9CWmNqVALLaTaPr7jgUkzCsgKPF3 hzBImFlAS6JnxmN2CFteYvvbOcwTGPlnIVTNQlI1C0nVAkbmVYwy+WlpusWpeSnFuekGhnol lfl6WQVFxXrJIHoTIzjoOBR2MM44ZXCIUYCDUYmHt2P9hmAh1sSy4srcQ4ySHExKorwX1gKF +JLyUyozEosz4otKc1KLDzFKcDArifAK1QHleFMSK6tSi/JhUtIcLErivMzGvcFCAumJJanZ qakFqUUwWRkODiUJ3qW7gBoFi1LTUyvSMnNKENJMHJwgw3mAhu8DqeEtLkjMLc5Mh8ifYpSU EufVBkkIgCQySvPgel8xigO9IMzbBZLlASYQuK5XQAOZgAZ+XQU2sCQRISXVwBjOb/bsZtfy xz+XF24xLFd1OTCxyFKILcmzpUzGsEV5EbdVs+qqbwYmLz7JVf5g2Pk7qlujaWvFaoYyw53O snZaIYo9CzjerIu42tLlGVS9w17TdXvephCHlvylPftFq5eIuyYKH393WNE2VEfvxO8Xx5aw XX61021Ts0HbGwvpmq1hmTNOK7EUZyQaajEXFScCAIuyc73dAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/-DRDImYvcJs47bm680m_u7iIlgE Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 01:25:40 -0000 From: Paul Hoffman Date: Fri, 27 Jun 2014 09:41:49 +0100 > On Jun 27, 2014, at 3:23 AM, Naoki Kambe wrote: > > > === > > 3.2.1. Required Information > > > > ... > > > > TLDs: A case-insensitive text string description of the top-level > > domain (or domains) for which the extension has been specified. > > "Any" or "ANY" MUST be used if the extension is not associated with a > > specific top-level domain. Multiple TLDs SHOULD be specified as a > > list of domain names separated by commas, e.g. ".com, .net". > > > > # In case of an IDN TLD, should a-label or u-label or both be > > # specified? (sorry for the duplication if already discussed) > > A-label. Unless we trust the application process to correctly maintain UTF-8 throughout (and I certainly don't), the A-label would be a much better format. Thanks for replying. I agree with you. And I think it might need some text in case of IDNs. Regards, Naoki Kambe From nobody Mon Jun 30 03:53:23 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D661A01F9 for ; Mon, 30 Jun 2014 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9HonubPCVHc for ; Mon, 30 Jun 2014 03:53:19 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6601A01F4 for ; Mon, 30 Jun 2014 03:53:17 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKU7FBnQqd4uw4S6T3Pyz4iDlwBS5HQXJF@postini.com; Mon, 30 Jun 2014 03:53:19 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s5UArGR8026763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 06:53:16 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 06:53:04 -0400 From: "Hollenbeck, Scott" To: Naoki Kambe , "eppext@ietf.org" Thread-Topic: [eppext] Working Group Last call for draft-ietf-eppext-reg Thread-Index: AQHPkFHuW1oWNgQ3kU+3DoSxy7bwg5uEPPqUgACstYCABD0eAIAAWsJg Date: Mon, 30 Jun 2014 10:53:15 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4943F938@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4943ACA0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140627.112333.32727126.kambe@jprs.co.jp> <8B366C4F-3456-4306-AE33-7904FB130DA5@vpnc.org> <20140630.102536.112824787.kambe@jprs.co.jp> In-Reply-To: <20140630.102536.112824787.kambe@jprs.co.jp> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/wIHyf5aWnchwsk-GORIp0rpN4H8 Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 10:53:22 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Naoki Kambe > Sent: Sunday, June 29, 2014 9:26 PM > To: eppext@ietf.org > Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg >=20 > From: Paul Hoffman > Date: Fri, 27 Jun 2014 09:41:49 +0100 >=20 > > On Jun 27, 2014, at 3:23 AM, Naoki Kambe wrote: > > > > > =3D=3D=3D > > > 3.2.1. Required Information > > > > > > ... > > > > > > TLDs: A case-insensitive text string description of the top-level > > > domain (or domains) for which the extension has been specified. > > > "Any" or "ANY" MUST be used if the extension is not associated > with a > > > specific top-level domain. Multiple TLDs SHOULD be specified as > a > > > list of domain names separated by commas, e.g. ".com, .net". > > > > > > # In case of an IDN TLD, should a-label or u-label or both be > > > # specified? (sorry for the duplication if already discussed) > > > > A-label. Unless we trust the application process to correctly > maintain UTF-8 throughout (and I certainly don't), the A-label would be > a much better format. >=20 > Thanks for replying. I agree with you. And I think it might need some > text in case of IDNs. Agreed. How about adding this sentence: "Internationalized Domain Name (IDN= ) top-level domains should be specified in a-label [RFC5890] format." Scott From nobody Mon Jun 30 03:57:57 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7FF1A01FA for ; Mon, 30 Jun 2014 03:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUoiNV7aMzuH for ; Mon, 30 Jun 2014 03:57:54 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA9A1A01F9 for ; Mon, 30 Jun 2014 03:57:51 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKU7FCr7KDcYtoe5dI/+S3+8IJOCk158m3@postini.com; Mon, 30 Jun 2014 03:57:54 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s5UAvoEj029134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 06:57:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 06:57:39 -0400 From: "Hollenbeck, Scott" To: Linlin Zhou , "eppext@ietf.org" Thread-Topic: [eppext] Working Group Last call for draft-ietf-eppext-reg Thread-Index: AQHPkFHuW1oWNgQ3kU+3DoSxy7bwg5uELGobgAVWHfA= Date: Mon, 30 Jun 2014 10:57:50 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4943F951@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <53AA8C4F.20807@sidn.nl> <201406270924569504127@cnnic.cn> In-Reply-To: <201406270924569504127@cnnic.cn> 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: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4943F951BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/CPXV_q2MKINNlbbe7wMPotuI7Fk Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 10:57:56 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4943F951BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRXBwRXh0IFttYWlsdG86ZXBwZXh0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMaW5saW4gWmhvdQ0KU2VudDogVGh1cnNkYXksIEp1bmUgMjYsIDIwMTQgOToyNSBQTQ0KVG86 IEFudG9pbiBWZXJzY2h1cmVuOyBlcHBleHRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZXBwZXh0 XSBXb3JraW5nIEdyb3VwIExhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1lcHBleHQtcmVnDQoNCkkg YWdyZWUgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHJlYWR5Lg0KT25seSBvbmUgbml0LCBJIHRoaW5r IGEgY29tbWEgaXMgbWlzc2luZyBpbiBzZWN0aW9uIDMuMi40Lg0KDQpJZiB0aGUgcmVnaXN0cmFu dCBiZWNvbWVzIHVuYXZhaWxhYmxlIG9yIG90aGVyd2lzZSB1bnJlc3BvbnNpdmUsIHRoZSBkZXNp Z25hdGVkIGV4cGVydCBNQVkgc3VibWl0IGEgcmVnaXN0cmF0aW9uIGZvcm0gdG8gSUFOQSB0byB1 cGRhdGUgdGhlIHJlZ2lzdHJhbnQgaW5mb3JtYXRpb24uDQoNCltTQUhdIE9LLCBJ4oCZbGwgYWRk IGEgY29tbWEgaW4gdGhlIGludGVyZXN0IG9mIGFkZGluZyBhIHBhdXNlIHRvIGEgbG9uZyBzZW50 ZW5jZS4NCg0KDQoNClNjb3R0DQo= --_000_831693C2CDA2E849A7D7A712B24E257F4943F951BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1pY3Jvc29mdCBZYUhlaSI7 DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsInNlcmlm Ijt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5v cm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEVwcEV4dCBbbWFpbHRvOmVwcGV4dC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5MaW5saW4gWmhvdTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAyNiwgMjAx NCA5OjI1IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRvaW4gVmVyc2NodXJlbjsgZXBwZXh0QGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZXBwZXh0XSBXb3JraW5nIEdyb3VwIExhc3Qg Y2FsbCBmb3IgZHJhZnQtaWV0Zi1lcHBleHQtcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPkkgYWdyZWUgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHJlYWR5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Pbmx5IG9uZSBuaXQsIEkgdGhpbmsg YSBjb21tYSBpcyBtaXNzaW5nIGluIHNlY3Rpb24gMy4yLjQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIHRoZSByZWdpc3RyYW50IGJlY29tZXMg dW5hdmFpbGFibGUgb3Igb3RoZXJ3aXNlIHVucmVzcG9uc2l2ZSwgdGhlIGRlc2lnbmF0ZWQgZXhw ZXJ0IE1BWSBzdWJtaXQgYSByZWdpc3RyYXRpb24gZm9ybSB0byBJQU5BIHRvIHVwZGF0ZSB0aGUg cmVnaXN0cmFudCBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltTQUhdIE9LLCBJ4oCZbGwgYWRkIGEgY29tbWEgaW4gdGhlIGludGVy ZXN0IG9mIGFkZGluZyBhIHBhdXNlIHRvIGEgbG9uZyBzZW50ZW5jZS48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2NvdHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_831693C2CDA2E849A7D7A712B24E257F4943F951BRN1WNEXMBX01vc_-- From nobody Mon Jun 30 04:00:43 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F131A0201 for ; Mon, 30 Jun 2014 04:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-wo4EXe_6UU for ; Mon, 30 Jun 2014 04:00:39 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405941A01FA for ; Mon, 30 Jun 2014 04:00:38 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKU7FDVVdOOT4b5H3aNpdZmi8KHsJGlUiQ@postini.com; Mon, 30 Jun 2014 04:00:39 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s5UB0bkK027001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 07:00:37 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 07:00:36 -0400 From: "Hollenbeck, Scott" To: Naoki Kambe , "eppext@ietf.org" Thread-Topic: [eppext] Working Group Last call for draft-ietf-eppext-reg Thread-Index: AQHPkFHuW1oWNgQ3kU+3DoSxy7bwg5uEPPqUgAVG5WA= Date: Mon, 30 Jun 2014 11:00:36 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4943F97E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <53AA8C4F.20807@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F4943ACA0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140627.112333.32727126.kambe@jprs.co.jp> In-Reply-To: <20140627.112333.32727126.kambe@jprs.co.jp> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/yoMVpPnjiFyvIInoLzImXrBDXrY Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 11:00:41 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Naoki Kambe > Sent: Thursday, June 26, 2014 10:24 PM > To: eppext@ietf.org > Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg >=20 > Hello, >=20 > Here is a couple of minor comments: >=20 > =3D=3D > 2. Introduction >=20 > ... >=20 > RFCs 5730 and 5735 do not describe how extension development can be > ^^^^ 3735? >=20 > managed and coordinated. This has led to a situation in which > server Good catch! Yes, it should be 3735. > =3D=3D=3D > 3.2.1. Required Information >=20 > ... >=20 > TLDs: A case-insensitive text string description of the top-level > domain (or domains) for which the extension has been specified. > "Any" or "ANY" MUST be used if the extension is not associated with > a > specific top-level domain. Multiple TLDs SHOULD be specified as a > list of domain names separated by commas, e.g. ".com, .net". >=20 > # In case of an IDN TLD, should a-label or u-label or both be > # specified? (sorry for the duplication if already discussed) Yes. I'll add a sentence to address IDN TLDs. > specification the IPR disclosure MAY be filed with the IETF in > accordance with RFCs 3979 [RFC3979] as updated by RFC 4879 > [RFC4879]. > ^^^^ RFC Yes, that should be "RFC". Thanks for the feedback! Scott From nobody Mon Jun 30 06:30:43 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EE81A030D for ; Mon, 30 Jun 2014 06:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNTWcU-YMufv for ; Mon, 30 Jun 2014 06:30:41 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by ietfa.amsl.com (Postfix) with ESMTP id 23B3D1A0309 for ; Mon, 30 Jun 2014 06:30:41 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 7E85624BD99; Mon, 30 Jun 2014 10:30:40 -0300 (BRT) Date: Mon, 30 Jun 2014 10:30:40 -0300 From: Frederico A C Neves To: "eppext@ietf.org" Message-ID: <20140630133040.GG59857@registro.br> References: <89A7E0AE8025CE4FA324483B8D02A6B224010927@MELEX01> <831693C2CDA2E849A7D7A712B24E257F49434FFC@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49434FFC@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/60Rz08QHAlD8dz4Qirifgc961ag Subject: Re: [eppext] Review of draft-ietf-eppext-reg-05 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 13:30:42 -0000 Sorry for the late answer, On Sun, Jun 22, 2014 at 03:33:49PM +0000, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Chris Wright > > Sent: Saturday, June 21, 2014 9:15 AM > > To: eppext@ietf.org > > Cc: James M. Galvin > > Subject: [eppext] Review of draft-ietf-eppext-reg-05 ... > > "A potential registrant who submits a request to register a new, un-deployed extension that includes similar functionality to an existing, registered extension should be made aware of the existing extension. The registrant should be asked to reconsider their request given the existence of a similar extension. Should they decline to do so perceived similarity should not be a sufficient reason for rejection as long as all other requirements are met." > > I think this addresses the spirit of Chris' suggested text while preserving the ability of the expert to assess the request. > > Scott I support Chris's suggestions and Scott's text. Fred From nobody Mon Jun 30 07:24:36 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831F51A0343 for ; Mon, 30 Jun 2014 07:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V09hyIlS9g0 for ; Mon, 30 Jun 2014 07:24:34 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by ietfa.amsl.com (Postfix) with ESMTP id A5C671A031F for ; Mon, 30 Jun 2014 07:24:34 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 1773B24BDD7; Mon, 30 Jun 2014 11:24:33 -0300 (BRT) Date: Mon, 30 Jun 2014 11:24:33 -0300 From: Frederico A C Neves To: "eppext@ietf.org" Message-ID: <20140630142433.GH59857@registro.br> References: <53AA8C4F.20807@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53AA8C4F.20807@sidn.nl> Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/x-WVcbXXZuqyxH_5odd6eyXT6kk Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 14:24:35 -0000 I've read the document and the so far comments on the ML and I fully support its publication. Fred From nobody Mon Jun 30 12:18:13 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DD91A03D9; Mon, 30 Jun 2014 12:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYDD3SdZCnHy; Mon, 30 Jun 2014 12:18:09 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1DA1A03C6; Mon, 30 Jun 2014 12:18:09 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKU7G38MuSt0x5rDfMZNEGXMUG2+bi1oiG@postini.com; Mon, 30 Jun 2014 12:18:09 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s5UJI8A6010900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 15:18:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 15:18:07 -0400 From: "Hollenbeck, Scott" To: "eppext@ietf.org" , "provreg@ietf.org" Thread-Topic: Registry Operations Industry Alliance Redux on RegOps Thread-Index: Ac+UmAS6R0nvj84LR/aMUok33q84Pg== Date: Mon, 30 Jun 2014 19:18:06 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49440B78@BRN1WNEXMBX01.vcorp.ad.vrsn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/lLFx1tb1YojpsPY74qfIvk4TpuQ Subject: [eppext] Registry Operations Industry Alliance Redux on RegOps X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Hollenbeck, Scott" List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 19:18:11 -0000 Sorry for cross-posting - please DO NOT reply to the eppext or provreg list= s! I just started this discussion on the regops mailing list. There might be p= eople on provreg or eppext who aren't aware of regops so I thought I'd brin= g it to your attention: http://nlnetlabs.nl/mailman/private/regops/2014-June/000139.html You'll need to subscribe to regops to view the archive and join the discuss= ion: http://nlnetlabs.nl/mailman/listinfo/regops Scott From nobody Mon Jun 30 18:35:47 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57901A007B for ; Mon, 30 Jun 2014 18:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLluokVbWc32 for ; Mon, 30 Jun 2014 18:35:44 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6D01A0078 for ; Mon, 30 Jun 2014 18:35:44 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s611Zg0G008978; Tue, 1 Jul 2014 10:35:42 +0900 X-AuditID: ac120820-b7f638e000000e09-4c-53b2106e7269 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id A1.E3.03593.E6012B35; Tue, 1 Jul 2014 10:35:42 +0900 (JST) Date: Tue, 01 Jul 2014 10:35:42 +0900 (JST) Message-Id: <20140701.103542.160233624.kambe@jprs.co.jp> To: shollenbeck@verisign.com From: Naoki Kambe In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4943F938@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8B366C4F-3456-4306-AE33-7904FB130DA5@vpnc.org> <20140630.102536.112824787.kambe@jprs.co.jp> <831693C2CDA2E849A7D7A712B24E257F4943F938@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsWyRoiFTzdPYFOwwf3dahYXbt9jtph59w2z A5PHkiU/mTx2bW5gC2CK4rJJSc3JLEst0rdL4Mr4vvQ2Y8EEvoqzG+YxNTD+5upi5OSQEDCR +HaigwXCFpO4cG89WxcjF4eQwElGiY8fT7GDJFgEtCWOtWxkBrF5BSwkjj1eBBYXEZCRaHh+ hg3EZhYQlujp2sAEYgsLuEs8OH8dzGYTUJFYdm8zmM0pEC7xrGMuO8SC7YwSVzf1AzkcHPwC +hJTm1IgjrCTaPr7jgUkzCsgKPF3hzDEeC2JnhmP2SFseYntb+cwT2AUmIVQNQtJ1SwkVQsY mVcxyuSnpekWp+alFOemGxjqlVTm62UVFBXrJYPoTYzgAOVQ2ME445TBIUYBDkYlHt6Kpo3B QqyJZcWVuYcYJTmYlER5d3JtChbiS8pPqcxILM6ILyrNSS0+xCjBwawkwvuXAyjHm5JYWZVa lA+TkuZgURLnZTbuDRYSSE8sSc1OTS1ILYLJynBwKEnwevADNQoWpaanVqRl5pQgpJk4OEGG 8wANTwap4S0uSMwtzkyHyJ9ilJQS5z3HB5QQAElklObB9b5iFAd6QZj3MUiWB5hs4LpeAQ1k Ahr4ddUGkIEliQgpqQbGpc8q7waUBHxiejj3aHIhz+S0vR/ecbM2sgvccXY9ZPT9qvH9PWlT 5t3RvpK+xq+Yv0IhUPjoxCVf9bm5+c8vXPrAM0ZAuYflQDILx0+P7o9OBRFbP9/LON5rqKD9 82mshkj4Eh3/t/x5q797iB4N6LnDwWT47WNz/4cLxw/ePcGyYdHuuBPXlViKMxINtZiLihMB aJLYIfMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/GcdRGXRNXRsNlQRzMF3Ex9OSJgg Cc: eppext@ietf.org Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 01:35:46 -0000 From: "Hollenbeck, Scott" Date: Mon, 30 Jun 2014 10:53:15 +0000 > > -----Original Message----- > > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Naoki Kambe > > Sent: Sunday, June 29, 2014 9:26 PM > > To: eppext@ietf.org > > Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-reg > > > > From: Paul Hoffman > > Date: Fri, 27 Jun 2014 09:41:49 +0100 > > > > > On Jun 27, 2014, at 3:23 AM, Naoki Kambe wrote: > > > > > > > === > > > > 3.2.1. Required Information > > > > > > > > ... > > > > > > > > TLDs: A case-insensitive text string description of the top-level > > > > domain (or domains) for which the extension has been specified. > > > > "Any" or "ANY" MUST be used if the extension is not associated > > with a > > > > specific top-level domain. Multiple TLDs SHOULD be specified as > > a > > > > list of domain names separated by commas, e.g. ".com, .net". > > > > > > > > # In case of an IDN TLD, should a-label or u-label or both be > > > > # specified? (sorry for the duplication if already discussed) > > > > > > A-label. Unless we trust the application process to correctly > > maintain UTF-8 throughout (and I certainly don't), the A-label would be > > a much better format. > > > > Thanks for replying. I agree with you. And I think it might need some > > text in case of IDNs. > > Agreed. How about adding this sentence: "Internationalized Domain Name (IDN) top-level domains should be specified in a-label [RFC5890] format." Thanks for proposing. The sentence seems good for me. As a very minor point, "TLDs" is already used over all. So you might be able to use it instead of "top-level domains" above. Regards, Naoki Kambe