From nobody Tue Feb 3 09:13:50 2015 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 525891A6F14; Mon, 2 Feb 2015 21:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 W1LuCC4-eUxj; Mon, 2 Feb 2015 21:36:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id E376A1A6FBC; Mon, 2 Feb 2015 21:36:06 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CEDE7180489; Mon, 2 Feb 2015 21:35:54 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150203053554.CEDE7180489@rfc-editor.org> Date: Mon, 2 Feb 2015 21:35:54 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 03 Feb 2015 09:13:43 -0800 Cc: drafts-update-ref@iana.org, eppext@ietf.org, rfc-editor@rfc-editor.org Subject: [eppext] RFC 7451 on Extension Registry for the Extensible Provisioning Protocol 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 Feb 2015 05:36:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7451 Title: Extension Registry for the Extensible Provisioning Protocol Author: S. Hollenbeck Status: Informational Stream: IETF Date: February 2015 Mailbox: shollenbeck@verisign.com Pages: 12 Characters: 20373 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-eppext-reg-10.txt URL: https://www.rfc-editor.org/info/rfc7451 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 document is a product of the Extensible Provisioning Protocol Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Feb 5 05:16:36 2015 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 49B021A8783 for ; Thu, 5 Feb 2015 05:16:34 -0800 (PST) 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 Ou-wlSOAdoy5 for ; Thu, 5 Feb 2015 05:16:32 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212591A8763 for ; Thu, 5 Feb 2015 05:16:22 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKVNNtJcsPORUwrJ842eoufwIxc7OvsMhC@postini.com; Thu, 05 Feb 2015 05:16:32 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t15DGKNn003088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 08:16:20 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Feb 2015 08:16:19 -0500 From: "Hollenbeck, Scott" To: Antoin Verschuren Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AQHQQUGFTPfpv98sekenYy9pVCPnm5ziBdxg Date: Thu, 5 Feb 2015 13:16:18 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-54! 25-4BAC-A 17A-25D13EF88A8F@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" , "Gould, James" Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 13:16:34 -0000 > -----Original Message----- > From: Antoin Verschuren [mailto:antoin@antoin.nl] > Sent: Thursday, February 05, 2015 7:45 AM > To: Hollenbeck, Scott > Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels; > eppext@ietf.org > Subject: Re: [eppext] New draft for keyrelay available >=20 > Scott, >=20 > What do you considder a duplication? The exact same message being sent or received more than once. This introduc= es a risk of inconsistency between client and server if there isn't a way t= o provide command idempotency, which is one of the reasons I prefer an appr= oach that involves creating a transient object. Note that Section 2 of RFC = 5730 includes this statement about EPP commands: "EPP commands fall into three categories: session management commands, quer= y commands, and object transform commands." Which of these categories does the command fall into? The draft des= cribes it as a "transient" command, and there's no mention of "transient" c= ommands in 5730. Scott From nobody Thu Feb 5 06:08:31 2015 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 7FF2C1A88BD for ; Thu, 5 Feb 2015 06:08:23 -0800 (PST) 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 yWHyAYDApEUp for ; Thu, 5 Feb 2015 06:08:18 -0800 (PST) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BFB1A8863 for ; Thu, 5 Feb 2015 06:08:09 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKVNN5SChcbq1Lg5kQJQJIEQ8neVvY7KRO@postini.com; Thu, 05 Feb 2015 06:08:14 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t15E87SD009185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 09:08:07 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Feb 2015 09:08:07 -0500 From: "Gould, James" To: "Hollenbeck, Scott" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAELswAAABaAQAAAMFFgAABzoiAAApRdhD//7ZaAIAATNuwgAidxICAAAjhAIAADnsA Date: Thu, 5 Feb 2015 14:08:06 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-54! 25-4BAC-A 17A-25D13EF88A8F@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_ECD1F4F1B5E7466790CC454204CCB065verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" , Antoin Verschuren Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 14:08:23 -0000 --_004_ECD1F4F1B5E7466790CC454204CCB065verisigncom_ Content-Type: multipart/alternative; boundary="_000_ECD1F4F1B5E7466790CC454204CCB065verisigncom_" --_000_ECD1F4F1B5E7466790CC454204CCB065verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Scott, I believe that RFC 5730 is not limited to a certain class of objects that c= an be provisioned. A create of a transient, immutable message object is a = transform command and the use of a poll response supports a query command. = In this case the server is being used to support the passing of messages b= etween two clients. There is no idempotency issue between the clients and = the server since the object is immutable, but there is an idempotency issue= between the participating clients that could be addressed by including a u= nique relay identifier in the relay message that the consuming client can s= imply verify against previously applied relay identifiers ahead of applying= the relay message. There could be other use cases were clients need to co= mmunicate through the server using a transient object message pattern. My recommendation to the authors of the Key Relay Extension is to make the = draft an object mapping with a create transform command, a the poll respons= e, and with a unique relay identifier to address the end-to-end idempotency= concern. =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Feb 5, 2015, at 8:16 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: Antoin Verschuren [mailto:antoin@antoin.nl] Sent: Thursday, February 05, 2015 7:45 AM To: Hollenbeck, Scott Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, What do you considder a duplication? The exact same message being sent or received more than once. This introduc= es a risk of inconsistency between client and server if there isn't a way t= o provide command idempotency, which is one of the reasons I prefer an appr= oach that involves creating a transient object. Note that Section 2 of RFC = 5730 includes this statement about EPP commands: "EPP commands fall into three categories: session management commands, quer= y commands, and object transform commands." Which of these categories does the command fall into? The draft des= cribes it as a "transient" command, and there's no mention of "transient" c= ommands in 5730. Scott --_000_ECD1F4F1B5E7466790CC454204CCB065verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5D22ECF98FF0724D837497304F0341D8@verisign.com> Content-Transfer-Encoding: quoted-printable
Scott,

I believe that RFC 5730 is not limited to a certain class of objects that c= an be provisioned.  A create of a transient, immutable message object = is a transform command and the use of a poll response supports a query comm= and.  In this case the server is being used to support the passing of messages between two clients.  There i= s no idempotency issue between the clients and the server since the object = is immutable, but there is an idempotency issue between the participating c= lients that could be addressed by including a unique relay identifier in the relay message that the consuming client c= an simply verify against previously applied relay identifiers ahead of appl= ying the relay message.  There could be other use cases were clients n= eed to communicate through the server using a transient object message pattern.  

My recommendation to the authors of the Key Relay Extension is to make= the draft an object mapping with a create transform command, a the poll re= sponse, and with a unique relay identifier to address the end-to-end i= dempotency concern.  

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

On Feb 5, 2015, at 8:16 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

-----Original Message-----
From: Antoin Verschuren [mailto:antoin@= antoin.nl]
Sent: Thursday, February 05, 2015 7:45 AM
To: Hollenbeck, Scott
Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels;
eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Scott,

What do you considder a duplication?

The exact same message being sent or received more than once. This introduc= es a risk of inconsistency between client and server if there isn't a way t= o provide command idempotency, which is one of the reasons I prefer an appr= oach that involves creating a transient object. Note that Section 2 of RFC 5730 includes this statement about EPP = commands:

"EPP commands fall into three categories: session management commands,= query commands, and object transform commands."

Which of these categories does the <relay> command fall into? The dra= ft describes it as a "transient" command, and there's no mention = of "transient" commands in 5730.

Scott


--_000_ECD1F4F1B5E7466790CC454204CCB065verisigncom_-- --_004_ECD1F4F1B5E7466790CC454204CCB065verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 05 Feb 2015 14:08:06 GMT"; modification-date="Thu, 05 Feb 2015 14:08:06 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_ECD1F4F1B5E7466790CC454204CCB065verisigncom_-- From nobody Thu Feb 5 06:33:02 2015 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 732A21A8AD0 for ; Thu, 5 Feb 2015 06:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, T_RP_MATCHES_RCVD=-0.01] 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 dpJboDltBS7A for ; Thu, 5 Feb 2015 06:32:58 -0800 (PST) Received: from walhalla.antoin.nl (walhalla.antoin.nl [88.159.164.218]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9F1A8A54 for ; Thu, 5 Feb 2015 06:32:58 -0800 (PST) Received: by walhalla.antoin.nl (Postfix, from userid 5001) id 8900B280813; Thu, 5 Feb 2015 15:32:56 +0100 (CET) Received: from [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2] (unknown [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2]) by walhalla.antoin.nl (Postfix) with ESMTPSA id 73B21280345 for ; Thu, 5 Feb 2015 15:32:53 +0100 (CET) From: Antoin Verschuren Content-Type: multipart/signed; boundary="Apple-Mail=_954E2C4F-529A-476D-9DB4-12E1FA093CE0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 5 Feb 2015 15:32:45 +0100 References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "eppext@ietf.org" In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 14:33:00 -0000 --Apple-Mail=_954E2C4F-529A-476D-9DB4-12E1FA093CE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I believe this is the essence of the confusion. The authors believe that like Scott, an "EPP Command" always = creates an object in the registry. That is how we read section 2.9.3 of = RFC5730. James believes that a create command can also be used to create = "something=94 in the poll queue only, without creating an object in the = registry. Reusing the create command like this is less work. For relay, it is not desirable to create an object in the registry, as = nothing is done with the object data after queueing in the poll queue, = and just polutes the registry, let alone the question of who owns the = object and what will trigger it to be deleted. For relay we are looking for a process to place data in the poll queue = only without it becomming an object in the registry. That is why the relay draft sugested a 4th section (2.9.4) of a new type = of protocol commands that we will call "Communication Commands=94 where = a command will create a poll queue message, but does not create or = change any objects in the registry.=20 We cannot call this new command an "EPP Command=94 under this = new "Communication Commands=94 section, just like there is a difference = between an "EPP Query Command=94 under Query Commands, and an = "EPP Command=94 under the Object Transform Commands. I have no deep knowledge of XML namespaces or mixing protocol and = command extensions, but this is what this new command needs to do, and = is something EPP hasn=92t seen the need to do before. All previous = commands were meant to touch an object in the registry. - --=20 Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 xmpp:antoinverschuren@gmail.com Op 30 jan. 2015, om 16:08 heeft Hollenbeck, Scott = het volgende geschreven: > EPP has no concept of =93objects=94 in the poll queue. The poll queue = manipulates messages. Objects are manipulated by transform commands like = create, delete, etc. > =20 > I was thinking that the source client would create a relay object, = which would result in a message being queued for the target client. The = info could exist in both the poll message (which would be short-lived = and lost once dequeued), and in the object (which would be slightly = longer-lived, but would be automatically deleted when it expired). > =20 > Scott > =20 > From: Gould, James=20 > Sent: Friday, January 30, 2015 9:57 AM > To: Hollenbeck, Scott > Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org > Subject: Re: [eppext] New draft for keyrelay available > =20 > Scott, > =20 > I believe the intent is to insert the transient object into the poll = queue for the target client. The acknowledgement of the poll message = should result in the implicit removal of the transient object from the = server. With what you=92re proposing, the source client would create = the transient object that I=92m assuming would result in a poll = notification containing a signal to the client to submit an info command = to get the transient object information? I=92m assuming that the target = client would then need to delete the transient object once they=92re = done with processing the message. I believe it=92s simpler and = consistent with the concept of creating a transient poll message to = support the create to create the poll message and the info response poll = message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object = with the signal and data being one and the same, and the deletion of the = transient object handled via the standard poll queue mechanism. =20 > =20 > =97 > =20 > JG >=20 >=20 > >=20 > James Gould > Distinguished Engineer > jgould@Verisign.com >=20 > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 >=20 > VerisignInc.com > =20 > On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott = wrote: >=20 >=20 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers > Sent: Tuesday, January 20, 2015 3:02 AM > To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org > Subject: Re: [eppext] New draft for keyrelay available >=20 > Hello Maarten, >=20 > Thx for the feedback, I hope more people with experience on extending > EPP will state their opinion on the list. >=20 > We have implemented the functionality in our registration system, but > it is not very actively used. What we see is that most registrars go > insecure. Most of the time we see a transfer command followed (some > time later in time) by a domain update to remove the old key material > and add new key material. There is even a losing registrar that = removes > all DNS key data when a registrant requests its authorization token > before the actual transfer. >=20 > One more opinion: >=20 > After reading through the draft again I believe I would have designed = this differently. EPP commands typically act on or read data from = objects, and if I'm reading keyrelay correctly the command isn't = doing either of those things. It's pushing information to the server to = be stored temporarily (in what?) so that it can be retrieved with a = command. It would be more architecturally consistent to create a = temporary relay object with the needed information and use an = command to retrieve the data. can be used to notify the receiving = client that the information is there to be retrieved. Anyway, that's my = two cents. >=20 > Rik's "not very actively used" comment is telling. DNSSEC isn't widely = supported by registrars, so it makes sense that we're not seeing a lot = of use. I don't have an issue with continuing work on this draft if the = intention is to document the existing practice of one operator in an = informational way, but I'm not comfortable with pursuing the current = approach on the standards track. We should confirm the need before doing = standards track work. >=20 > Scott > =20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext --Apple-Mail=_954E2C4F-529A-476D-9DB4-12E1FA093CE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJU038UAAoJEHda8rd0+iNRnZYH/Rhn/QaM6ysYmocktpCv0tPe cd8cQ+HoEiSkWJ2LyY+7dZebTRJriCa1iSxf5f3Lj6pw0nbJD2zItVdd/g7g4qVQ bQLj9YlT8SmDMk4daPOb2YvnV24NJfhdepSTmHxX/w4XSzk4ZvTF0ANWXYiGf9+t 1SfXyiLAFvjzS0440dAacOaCdrs8T629AEFHJE+cAD15rLHsgIlYv06q/RnscwS+ m/V1kfo+Z4Ayhw0taotkjCYXM51XWUSHIcx6U1jhBPMl5wp9240kZKcRtidupLyW XD6AMQhhAEI7ce1hHuY3WIBCJdyk223rB1o+N89yHY1Kph3BnzApuMMhu4Ick1E= =kQf/ -----END PGP SIGNATURE----- --Apple-Mail=_954E2C4F-529A-476D-9DB4-12E1FA093CE0-- From nobody Thu Feb 5 06:49:54 2015 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 1E26C1A8848 for ; Thu, 5 Feb 2015 06:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, T_RP_MATCHES_RCVD=-0.01] 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 eX8Fa2vzIaNr for ; Thu, 5 Feb 2015 06:49:46 -0800 (PST) Received: from walhalla.antoin.nl (walhalla.antoin.nl [88.159.164.218]) by ietfa.amsl.com (Postfix) with ESMTP id E3B931A885D for ; Thu, 5 Feb 2015 06:49:42 -0800 (PST) Received: by walhalla.antoin.nl (Postfix, from userid 5001) id 24CAB280813; Thu, 5 Feb 2015 15:49:42 +0100 (CET) Received: from [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2] (unknown [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2]) by walhalla.antoin.nl (Postfix) with ESMTPSA id CA2C7280345 for ; Thu, 5 Feb 2015 15:49:39 +0100 (CET) From: Antoin Verschuren Content-Type: multipart/signed; boundary="Apple-Mail=_097F4798-3A6F-4A7C-B7E0-0D499A31D572"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 5 Feb 2015 15:49:37 +0100 References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-54! 25-4BAC -A 17A-25D13EF88A8F@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "eppext@ietf.org" In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 14:49:47 -0000 --Apple-Mail=_097F4798-3A6F-4A7C-B7E0-0D499A31D572 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Like I said, I believe the command falls into a 4th category of = EPP commands which I'd like to call "Communication Commands=94 or = "Transient Commands=94 (name to be discussed). So we will have session management commands, query commands, object = transform commands and communication commands. We didn=92t see the need for this category back then. That is the = innovative idea of relay. Communication commands don=92t touch objects, so there is no risk of = inconsistency in the registry. - --=20 Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 xmpp:antoinverschuren@gmail.com Op 5 feb. 2015, om 14:16 heeft Hollenbeck, Scott = het volgende geschreven: >> -----Original Message----- >> From: Antoin Verschuren [mailto:antoin@antoin.nl] >> Sent: Thursday, February 05, 2015 7:45 AM >> To: Hollenbeck, Scott >> Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels; >> eppext@ietf.org >> Subject: Re: [eppext] New draft for keyrelay available >>=20 >> Scott, >>=20 >> What do you considder a duplication? >=20 > The exact same message being sent or received more than once. This = introduces a risk of inconsistency between client and server if there = isn't a way to provide command idempotency, which is one of the reasons = I prefer an approach that involves creating a transient object. Note = that Section 2 of RFC 5730 includes this statement about EPP commands: >=20 > "EPP commands fall into three categories: session management commands, = query commands, and object transform commands." >=20 > Which of these categories does the command fall into? The = draft describes it as a "transient" command, and there's no mention of = "transient" commands in 5730. >=20 > Scott --Apple-Mail=_097F4798-3A6F-4A7C-B7E0-0D499A31D572 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJU04MBAAoJEHda8rd0+iNR6C8H/Ahcal3M463QH+9nZz9Yvva1 1VuscBi6MHRtPJ+Cc15MFNNWIQ9TLs93ZB9k0FFSEcuz7hEOJ5DbTDv1hpvOjsnb OMEuIGjsq1uThqY8DiCNiSj0FtZWILtFb2uwLpmeigeKe853U4l1ZnaGR1aYZ8a6 /PEKMXOtD/F6KKRuIDt70RxHtzv/fF1nL3XAZQcQvQ3GZPkER+4IQ3NUhpH45M6U gFh9dx5JTi9vJ5qdF7jdihAKgM6j7TE+FlheuEdx5G8obM4Ro2GalF7nFtUiqLT/ MjkL+oOLfGivheoUI4R9U6xSYn8XKIQZ36b7KMnvMVmLbb10fx/XEQQqv9XBqW4= =V5Ke -----END PGP SIGNATURE----- --Apple-Mail=_097F4798-3A6F-4A7C-B7E0-0D499A31D572-- From nobody Thu Feb 5 06:58:58 2015 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 C16D31A88DC for ; Thu, 5 Feb 2015 06:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mxC_m8BJEiDT for ; Thu, 5 Feb 2015 06:58:51 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723B91A8955 for ; Thu, 5 Feb 2015 06:57:37 -0800 (PST) Received: from DB4PR06MB128.eurprd06.prod.outlook.com (10.242.155.27) by DB4PR06MB128.eurprd06.prod.outlook.com (10.242.155.27) with Microsoft SMTP Server (TLS) id 15.1.75.20; Thu, 5 Feb 2015 14:57:08 +0000 Received: from DB4PR06MB128.eurprd06.prod.outlook.com ([169.254.16.15]) by DB4PR06MB128.eurprd06.prod.outlook.com ([169.254.16.15]) with mapi id 15.01.0075.002; Thu, 5 Feb 2015 14:57:08 +0000 From: Maarten Bosteels To: "Gould, James" , "Hollenbeck, Scott" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutM5ziBdxg40oDLgCAAB52gA== Date: Thu, 5 Feb 2015 14:57:08 +0000 Message-ID: <46DE906F-03B9-4CBB-9CC9-885B15EDCA01@dnsbelgium.be> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [77.67.63.234] authentication-results: verisign.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB128; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB128; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(19617315012)(2656002)(40100003)(18206015028)(33656002)(102836002)(122556002)(16601075003)(87936001)(16236675004)(83716003)(15975445007)(93886004)(66066001)(86362001)(2900100001)(82746002)(19580405001)(62966003)(77156002)(19580395003)(36756003)(46102003)(92566002)(2950100001)(74482002)(54356999)(50986999)(76176999)(17760045003)(99936001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB128; H:DB4PR06MB128.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/mixed; boundary="_004_46DE906F03B94CBB9CC9885B15EDCA01dnsbelgiumbe_" MIME-Version: 1.0 X-OriginatorOrg: dnsbelgium.be X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2015 14:57:08.2706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 695195de-c0cb-4478-9204-2a861e60e59c X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB128 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" , Antoin Verschuren Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 14:58:55 -0000 --_004_46DE906F03B94CBB9CC9885B15EDCA01dnsbelgiumbe_ Content-Type: multipart/alternative; boundary="_000_46DE906F03B94CBB9CC9885B15EDCA01dnsbelgiumbe_" --_000_46DE906F03B94CBB9CC9885B15EDCA01dnsbelgiumbe_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb21wbGV0ZWx5IGFncmVlIHdpdGggSmFtZXMnIGFyZ3VtZW50YXRpb24gYW5kIHJlY29tbWVu ZGF0aW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWFydGVuDQoNCkZyb206IDxHb3VsZD4sIEphbWVz IDxKR291bGRAdmVyaXNpZ24uY29tPG1haWx0bzpKR291bGRAdmVyaXNpZ24uY29tPj4NCkRhdGU6 IFRodXJzZGF5IDUgRmVicnVhcnkgMjAxNSAxNTowOA0KVG86ICJIb2xsZW5iZWNrLCBTY290dCIg PHNob2xsZW5iZWNrQHZlcmlzaWduLmNvbTxtYWlsdG86c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29t Pj4NCkNjOiBBbnRvaW4gVmVyc2NodXJlbiA8YW50b2luQGFudG9pbi5ubDxtYWlsdG86YW50b2lu QGFudG9pbi5ubD4+LCBSaWsgUmliYmVycyA8cmlrLnJpYmJlcnNAc2lkbi5ubDxtYWlsdG86cmlr LnJpYmJlcnNAc2lkbi5ubD4+LCBNaWVrIEdpZWJlbiA8bWlla0BtaWVrLm5sPG1haWx0bzptaWVr QG1pZWsubmw+PiwgTWFhcnRlbiBCb3N0ZWVscyA8bWFhcnRlbi5ib3N0ZWVsc0BkbnNiZWxnaXVt LmJlPG1haWx0bzptYWFydGVuLmJvc3RlZWxzQGRuc2JlbGdpdW0uYmU+PiwgImVwcGV4dEBpZXRm Lm9yZzxtYWlsdG86ZXBwZXh0QGlldGYub3JnPiIgPGVwcGV4dEBpZXRmLm9yZzxtYWlsdG86ZXBw ZXh0QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbZXBwZXh0XSBOZXcgZHJhZnQgZm9yIGtleXJl bGF5IGF2YWlsYWJsZQ0KDQpTY290dCwNCg0KSSBiZWxpZXZlIHRoYXQgUkZDIDU3MzAgaXMgbm90 IGxpbWl0ZWQgdG8gYSBjZXJ0YWluIGNsYXNzIG9mIG9iamVjdHMgdGhhdCBjYW4gYmUgcHJvdmlz aW9uZWQuICBBIGNyZWF0ZSBvZiBhIHRyYW5zaWVudCwgaW1tdXRhYmxlIG1lc3NhZ2Ugb2JqZWN0 IGlzIGEgdHJhbnNmb3JtIGNvbW1hbmQgYW5kIHRoZSB1c2Ugb2YgYSBwb2xsIHJlc3BvbnNlIHN1 cHBvcnRzIGEgcXVlcnkgY29tbWFuZC4gIEluIHRoaXMgY2FzZSB0aGUgc2VydmVyIGlzIGJlaW5n IHVzZWQgdG8gc3VwcG9ydCB0aGUgcGFzc2luZyBvZiBtZXNzYWdlcyBiZXR3ZWVuIHR3byBjbGll bnRzLiAgVGhlcmUgaXMgbm8gaWRlbXBvdGVuY3kgaXNzdWUgYmV0d2VlbiB0aGUgY2xpZW50cyBh bmQgdGhlIHNlcnZlciBzaW5jZSB0aGUgb2JqZWN0IGlzIGltbXV0YWJsZSwgYnV0IHRoZXJlIGlz IGFuIGlkZW1wb3RlbmN5IGlzc3VlIGJldHdlZW4gdGhlIHBhcnRpY2lwYXRpbmcgY2xpZW50cyB0 aGF0IGNvdWxkIGJlIGFkZHJlc3NlZCBieSBpbmNsdWRpbmcgYSB1bmlxdWUgcmVsYXkgaWRlbnRp ZmllciBpbiB0aGUgcmVsYXkgbWVzc2FnZSB0aGF0IHRoZSBjb25zdW1pbmcgY2xpZW50IGNhbiBz aW1wbHkgdmVyaWZ5IGFnYWluc3QgcHJldmlvdXNseSBhcHBsaWVkIHJlbGF5IGlkZW50aWZpZXJz IGFoZWFkIG9mIGFwcGx5aW5nIHRoZSByZWxheSBtZXNzYWdlLiAgVGhlcmUgY291bGQgYmUgb3Ro ZXIgdXNlIGNhc2VzIHdlcmUgY2xpZW50cyBuZWVkIHRvIGNvbW11bmljYXRlIHRocm91Z2ggdGhl IHNlcnZlciB1c2luZyBhIHRyYW5zaWVudCBvYmplY3QgbWVzc2FnZSBwYXR0ZXJuLg0KDQpNeSBy ZWNvbW1lbmRhdGlvbiB0byB0aGUgYXV0aG9ycyBvZiB0aGUgS2V5IFJlbGF5IEV4dGVuc2lvbiBp cyB0byBtYWtlIHRoZSBkcmFmdCBhbiBvYmplY3QgbWFwcGluZyB3aXRoIGEgY3JlYXRlIHRyYW5z Zm9ybSBjb21tYW5kLCBhIHRoZSBwb2xsIHJlc3BvbnNlLCBhbmQgd2l0aCBhIHVuaXF1ZSByZWxh eSBpZGVudGlmaWVyIHRvIGFkZHJlc3MgdGhlIGVuZC10by1lbmQgaWRlbXBvdGVuY3kgY29uY2Vy bi4NCg0KDQrigJQNCg0KDQpKRw0KDQoNCltjaWQ6NzcwMzFDQzMtQkU3QS00MTg4LUE5NUYtRDIz MTE1QTMwQTREQHZjb3JwLmFkLnZyc24uY29tXQ0KDQpKYW1lcyBHb3VsZA0KRGlzdGluZ3Vpc2hl ZCBFbmdpbmVlcg0KamdvdWxkQFZlcmlzaWduLmNvbQ0KDQo3MDMtOTQ4LTMyNzENCjEyMDYxIEJs dWVtb250IFdheQ0KUmVzdG9uLCBWQSAyMDE5MA0KDQpWZXJpc2lnbkluYy5jb208aHR0cDovL1Zl cmlzaWduSW5jLmNvbT4NCg0KT24gRmViIDUsIDIwMTUsIGF0IDg6MTYgQU0sIEhvbGxlbmJlY2ss IFNjb3R0IDxzaG9sbGVuYmVja0B2ZXJpc2lnbi5jb208bWFpbHRvOnNob2xsZW5iZWNrQHZlcmlz aWduLmNvbT4+IHdyb3RlOg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW50 b2luIFZlcnNjaHVyZW4gW21haWx0bzphbnRvaW5AYW50b2luLm5sXQ0KU2VudDogVGh1cnNkYXks IEZlYnJ1YXJ5IDA1LCAyMDE1IDc6NDUgQU0NClRvOiBIb2xsZW5iZWNrLCBTY290dA0KQ2M6IEdv dWxkLCBKYW1lczsgUmlrIFJpYmJlcnM7IE1pZWsgR2llYmVuOyBNYWFydGVuIEJvc3RlZWxzOw0K ZXBwZXh0QGlldGYub3JnPG1haWx0bzplcHBleHRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2Vw cGV4dF0gTmV3IGRyYWZ0IGZvciBrZXlyZWxheSBhdmFpbGFibGUNCg0KU2NvdHQsDQoNCldoYXQg ZG8geW91IGNvbnNpZGRlciBhIGR1cGxpY2F0aW9uPw0KDQpUaGUgZXhhY3Qgc2FtZSBtZXNzYWdl IGJlaW5nIHNlbnQgb3IgcmVjZWl2ZWQgbW9yZSB0aGFuIG9uY2UuIFRoaXMgaW50cm9kdWNlcyBh IHJpc2sgb2YgaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIGlmIHRoZXJl IGlzbid0IGEgd2F5IHRvIHByb3ZpZGUgY29tbWFuZCBpZGVtcG90ZW5jeSwgd2hpY2ggaXMgb25l IG9mIHRoZSByZWFzb25zIEkgcHJlZmVyIGFuIGFwcHJvYWNoIHRoYXQgaW52b2x2ZXMgY3JlYXRp bmcgYSB0cmFuc2llbnQgb2JqZWN0LiBOb3RlIHRoYXQgU2VjdGlvbiAyIG9mIFJGQyA1NzMwIGlu Y2x1ZGVzIHRoaXMgc3RhdGVtZW50IGFib3V0IEVQUCBjb21tYW5kczoNCg0KIkVQUCBjb21tYW5k cyBmYWxsIGludG8gdGhyZWUgY2F0ZWdvcmllczogc2Vzc2lvbiBtYW5hZ2VtZW50IGNvbW1hbmRz LCBxdWVyeSBjb21tYW5kcywgYW5kIG9iamVjdCB0cmFuc2Zvcm0gY29tbWFuZHMuIg0KDQpXaGlj aCBvZiB0aGVzZSBjYXRlZ29yaWVzIGRvZXMgdGhlIDxyZWxheT4gY29tbWFuZCBmYWxsIGludG8/ IFRoZSBkcmFmdCBkZXNjcmliZXMgaXQgYXMgYSAidHJhbnNpZW50IiBjb21tYW5kLCBhbmQgdGhl cmUncyBubyBtZW50aW9uIG9mICJ0cmFuc2llbnQiIGNvbW1hbmRzIGluIDU3MzAuDQoNClNjb3R0 DQoNCg0K --_000_46DE906F03B94CBB9CC9885B15EDCA01dnsbelgiumbe_ Content-Type: text/html; charset="utf-8" Content-ID: <3D090113DFF22E4A986BDC858CA78187@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkkgY29tcGxldGVseSBhZ3JlZSB3aXRoIEphbWVzJyBhcmd1bWVudGF0aW9uIGFuZCByZWNv bW1lbmRhdGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJlc3QgcmVnYXJkcyw8 L2Rpdj4NCjxkaXY+TWFhcnRlbjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJ R05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNr OyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ QURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGlu OyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJv bTogPC9zcGFuPiZsdDtHb3VsZCZndDssIEphbWVzICZsdDs8YSBocmVmPSJtYWlsdG86SkdvdWxk QHZlcmlzaWduLmNvbSI+SkdvdWxkQHZlcmlzaWduLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSA1IEZlYnJ1YXJ5IDIw MTUgMTU6MDg8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4m cXVvdDtIb2xsZW5iZWNrLCBTY290dCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNob2xsZW5i ZWNrQHZlcmlzaWduLmNvbSI+c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5BbnRvaW4gVmVyc2NodXJl biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFudG9pbkBhbnRvaW4ubmwiPmFudG9pbkBhbnRvaW4ubmw8 L2E+Jmd0OywgUmlrIFJpYmJlcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWsucmliYmVyc0BzaWRu Lm5sIj5yaWsucmliYmVyc0BzaWRuLm5sPC9hPiZndDssIE1pZWsgR2llYmVuICZsdDs8YSBocmVm PSJtYWlsdG86bWlla0BtaWVrLm5sIj5taWVrQG1pZWsubmw8L2E+Jmd0OywgTWFhcnRlbg0KIEJv c3RlZWxzICZsdDs8YSBocmVmPSJtYWlsdG86bWFhcnRlbi5ib3N0ZWVsc0BkbnNiZWxnaXVtLmJl Ij5tYWFydGVuLmJvc3RlZWxzQGRuc2JlbGdpdW0uYmU8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmVwcGV4dEBpZXRmLm9yZyI+ZXBwZXh0QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmVwcGV4dEBpZXRmLm9yZyI+ZXBwZXh0QGlldGYub3JnPC9hPiZndDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbZXBw ZXh0XSBOZXcgZHJhZnQgZm9yIGtleXJlbGF5IGF2YWlsYWJsZTxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiPg0KPGRpdj5TY290dCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQpJIGJlbGlldmUg dGhhdCBSRkMgNTczMCBpcyBub3QgbGltaXRlZCB0byBhIGNlcnRhaW4gY2xhc3Mgb2Ygb2JqZWN0 cyB0aGF0IGNhbiBiZSBwcm92aXNpb25lZC4gJm5ic3A7QSBjcmVhdGUgb2YgYSB0cmFuc2llbnQs IGltbXV0YWJsZSBtZXNzYWdlIG9iamVjdCBpcyBhIHRyYW5zZm9ybSBjb21tYW5kIGFuZCB0aGUg dXNlIG9mIGEgcG9sbCByZXNwb25zZSBzdXBwb3J0cyBhIHF1ZXJ5IGNvbW1hbmQuICZuYnNwO0lu IHRoaXMgY2FzZSB0aGUgc2VydmVyIGlzIGJlaW5nDQogdXNlZCB0byBzdXBwb3J0IHRoZSBwYXNz aW5nIG9mIG1lc3NhZ2VzIGJldHdlZW4gdHdvIGNsaWVudHMuICZuYnNwO1RoZXJlIGlzIG5vIGlk ZW1wb3RlbmN5IGlzc3VlIGJldHdlZW4gdGhlIGNsaWVudHMgYW5kIHRoZSBzZXJ2ZXIgc2luY2Ug dGhlIG9iamVjdCBpcyBpbW11dGFibGUsIGJ1dCB0aGVyZSBpcyBhbiBpZGVtcG90ZW5jeSBpc3N1 ZSBiZXR3ZWVuIHRoZSBwYXJ0aWNpcGF0aW5nIGNsaWVudHMgdGhhdCBjb3VsZCBiZSBhZGRyZXNz ZWQgYnkgaW5jbHVkaW5nDQogYSB1bmlxdWUgcmVsYXkgaWRlbnRpZmllciBpbiB0aGUgcmVsYXkg bWVzc2FnZSB0aGF0IHRoZSBjb25zdW1pbmcgY2xpZW50IGNhbiBzaW1wbHkgdmVyaWZ5IGFnYWlu c3QgcHJldmlvdXNseSBhcHBsaWVkIHJlbGF5IGlkZW50aWZpZXJzIGFoZWFkIG9mIGFwcGx5aW5n IHRoZSByZWxheSBtZXNzYWdlLiAmbmJzcDtUaGVyZSBjb3VsZCBiZSBvdGhlciB1c2UgY2FzZXMg d2VyZSBjbGllbnRzIG5lZWQgdG8gY29tbXVuaWNhdGUgdGhyb3VnaCB0aGUgc2VydmVyDQogdXNp bmcgYSB0cmFuc2llbnQgb2JqZWN0IG1lc3NhZ2UgcGF0dGVybi4gJm5ic3A7DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5NeSByZWNvbW1lbmRhdGlvbiB0byB0aGUgYXV0aG9ycyBvZiB0aGUgS2V5 IFJlbGF5IEV4dGVuc2lvbiBpcyB0byBtYWtlIHRoZSBkcmFmdCBhbiBvYmplY3QgbWFwcGluZyB3 aXRoIGEgY3JlYXRlIHRyYW5zZm9ybSBjb21tYW5kLCBhIHRoZSBwb2xsIHJlc3BvbnNlLCBhbmQg d2l0aCBhIHVuaXF1ZSByZWxheSBpZGVudGlmaWVyIHRvIGFkZHJlc3MgdGhlIGVuZC10by1lbmQm bmJzcDtpZGVtcG90ZW5jeSZuYnNwO2NvbmNlcm4uICZuYnNwOzxicj4NCjxkaXY+PGJyPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBWZXJkYW5h OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyI+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7Ij48Zm9udCBmYWNlPSJDYWxpYnJpLFZlcmRhbmEs SGVsdmV0aWNhLEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyI+4oCUPC9zcGFu PjwvZm9udD48L3A+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IG1hcmdpbjogMHB4OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLFZlcmRhbmEsSGVsdmV0aWNhLEFy aWFsIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBtYXJnaW46IDBweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxWZXJk YW5hLEhlbHZldGljYSxBcmlhbCIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7Ij5KRzxicj4NCjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRh bmE7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7Ij48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiIHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogVmVyZGFuYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+PHNwYW4+PGltZyBoZWlnaHQ9 IjY0IiB3aWR0aD0iNzMiIGFwcGxlLWlubGluZT0ieWVzIiBpZD0iRjY1ODAyMjQtNUJCRi00NTA2 LUFENTEtOTA4OEZDN0MzOEY4IiBhcHBsZS13aWR0aD0ieWVzIiBhcHBsZS1oZWlnaHQ9InllcyIg c3JjPSJjaWQ6NzcwMzFDQzMtQkU3QS00MTg4LUE5NUYtRDIzMTE1QTMwQTREQHZjb3JwLmFkLnZy c24uY29tIj48L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSxWZXJkYW5hLEhlbHZldGljYSxBcmlh bCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmb250LXNpemU6IDE0cHg7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyxUaW1lcyBOZXcgUm9t YW4iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZm9udC1zaXplOiAxNHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTJwdDsiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDZBQUEiIHN0eWxlPSJm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxmb250IHNpemU9IjIiPjxmb250IGZh Y2U9IkhlbHZldGljYSxWZXJkYW5hLEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyI+PGI+SmFtZXMNCiBHb3VsZDxicj4NCjwvYj48L3NwYW4+PC9mb250PjwvZm9udD48L2ZvbnQ+ PGZvbnQgc2l6ZT0iMiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPjxmb250IGZhY2U9IkhlbHZldGljYSwgVmVyZGFuYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7Ij48Zm9udCBjb2xvcj0iIzZCNkQ3MSI+RGlzdGluZ3Vpc2hlZA0KIEVu Z2luZWVyPGJyPg0KPGEgaHJlZj0iamdvdWxkQFZlcmlzaWduLmNvbSI+amdvdWxkQFZlcmlzaWdu LmNvbTwvYT48YnI+DQo8YnI+DQo3MDMtOTQ4LTMyNzE8YnI+DQoxMjA2MSBCbHVlbW9udCBXYXk8 YnI+DQpSZXN0b24sIFZBIDIwMTkwPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IGNvbG9yPSIjMDA2 QUFBIj48YSBocmVmPSJodHRwOi8vVmVyaXNpZ25JbmMuY29tIj5WZXJpc2lnbkluYy5jb208L2E+ PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8YnI+DQo8 ZGl2Pg0KPGRpdj5PbiBGZWIgNSwgMjAxNSwgYXQgODoxNiBBTSwgSG9sbGVuYmVjaywgU2NvdHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpzaG9sbGVuYmVja0B2ZXJpc2lnbi5jb20iPnNob2xsZW5iZWNr QHZlcmlzaWduLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBBbnRvaW4g VmVyc2NodXJlbiBbPGEgaHJlZj0ibWFpbHRvOmFudG9pbkBhbnRvaW4ubmwiPm1haWx0bzphbnRv aW5AYW50b2luLm5sPC9hPl08YnI+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDUsIDIwMTUg Nzo0NSBBTTxicj4NClRvOiBIb2xsZW5iZWNrLCBTY290dDxicj4NCkNjOiBHb3VsZCwgSmFtZXM7 IFJpayBSaWJiZXJzOyBNaWVrIEdpZWJlbjsgTWFhcnRlbiBCb3N0ZWVsczs8YnI+DQo8YSBocmVm PSJtYWlsdG86ZXBwZXh0QGlldGYub3JnIj5lcHBleHRAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVj dDogUmU6IFtlcHBleHRdIE5ldyBkcmFmdCBmb3Iga2V5cmVsYXkgYXZhaWxhYmxlPGJyPg0KPGJy Pg0KU2NvdHQsPGJyPg0KPGJyPg0KV2hhdCBkbyB5b3UgY29uc2lkZGVyIGEgZHVwbGljYXRpb24/ PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KVGhlIGV4YWN0IHNhbWUgbWVzc2FnZSBiZWluZyBz ZW50IG9yIHJlY2VpdmVkIG1vcmUgdGhhbiBvbmNlLiBUaGlzIGludHJvZHVjZXMgYSByaXNrIG9m IGluY29uc2lzdGVuY3kgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlciBpZiB0aGVyZSBpc24ndCBh IHdheSB0byBwcm92aWRlIGNvbW1hbmQgaWRlbXBvdGVuY3ksIHdoaWNoIGlzIG9uZSBvZiB0aGUg cmVhc29ucyBJIHByZWZlciBhbiBhcHByb2FjaCB0aGF0IGludm9sdmVzIGNyZWF0aW5nIGEgdHJh bnNpZW50DQogb2JqZWN0LiBOb3RlIHRoYXQgU2VjdGlvbiAyIG9mIFJGQyA1NzMwIGluY2x1ZGVz IHRoaXMgc3RhdGVtZW50IGFib3V0IEVQUCBjb21tYW5kczo8YnI+DQo8YnI+DQomcXVvdDtFUFAg Y29tbWFuZHMgZmFsbCBpbnRvIHRocmVlIGNhdGVnb3JpZXM6IHNlc3Npb24gbWFuYWdlbWVudCBj b21tYW5kcywgcXVlcnkgY29tbWFuZHMsIGFuZCBvYmplY3QgdHJhbnNmb3JtIGNvbW1hbmRzLiZx dW90Ozxicj4NCjxicj4NCldoaWNoIG9mIHRoZXNlIGNhdGVnb3JpZXMgZG9lcyB0aGUgJmx0O3Jl bGF5Jmd0OyBjb21tYW5kIGZhbGwgaW50bz8gVGhlIGRyYWZ0IGRlc2NyaWJlcyBpdCBhcyBhICZx dW90O3RyYW5zaWVudCZxdW90OyBjb21tYW5kLCBhbmQgdGhlcmUncyBubyBtZW50aW9uIG9mICZx dW90O3RyYW5zaWVudCZxdW90OyBjb21tYW5kcyBpbiA1NzMwLjxicj4NCjxicj4NClNjb3R0PGJy Pg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_46DE906F03B94CBB9CC9885B15EDCA01dnsbelgiumbe_-- --_004_46DE906F03B94CBB9CC9885B15EDCA01dnsbelgiumbe_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: attachment; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 05 Feb 2015 14:57:08 GMT"; modification-date="Thu, 05 Feb 2015 14:57:08 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_46DE906F03B94CBB9CC9885B15EDCA01dnsbelgiumbe_-- From nobody Thu Feb 5 07:14:46 2015 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 5698F1A88C2 for ; Thu, 5 Feb 2015 07:14:35 -0800 (PST) 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 Dw62HpGqULoB for ; Thu, 5 Feb 2015 07:14:26 -0800 (PST) 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 5F7871A9063 for ; Thu, 5 Feb 2015 07:13:22 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKVNOIkVOPGw95PxQ3Z17n+RkAV4QDlQhI@postini.com; Thu, 05 Feb 2015 07:13:24 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t15FDKxt016928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 10:13:21 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Feb 2015 10:13:20 -0500 From: "Gould, James" To: Antoin Verschuren Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAEsf/2AAAFq2AA= Date: Thu, 5 Feb 2015 15:13:19 +0000 Message-ID: <1C730264-F439-4FB8-9ABF-803BB4DCC2E0@verisign.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_1C730264F4394FB89ABF803BB4DCC2E0verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 15:14:36 -0000 --_004_1C730264F4394FB89ABF803BB4DCC2E0verisigncom_ Content-Type: multipart/alternative; boundary="_000_1C730264F4394FB89ABF803BB4DCC2E0verisigncom_" --_000_1C730264F4394FB89ABF803BB4DCC2E0verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Antoin, My understanding of EPP is that it defines 7 object verbs (check, info, cre= ate, delete, renew, transfer query / request / cancel / reject / approve, a= nd update), where I don=92t capture some of the base protocol commands like= login, logout, and poll, with the ability to extend the protocol to suppor= t new objects in separate specifications that define which verbs are suppor= ted for those objects and what is passed in the commands and responses. No= where does it state in RFC 5730 or RFC 3735 that an object extension must s= upport a specific set of verbs and that a create must create =93an object i= n the registry=94 with a single class of object. The verbs supported are s= pecific to the object that exists in some form in the registry. An object = could be a standard object like domain, it could be an immutable message ob= ject like with the key relay message, or could be a generated object based = on a client info command ( Name Suggestion Mapping - http://www.verisigninc= .com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf and Balance Mapping - http:/= /www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_balance_v00.html= ). I believe the key is that there can be many forms of objects that are s= upported by the server that can be represented using an EPP object extensio= n. The specification of the EPP object extension defines the specifics abo= ut what verbs are supported. Reusing a create command is not simply less work but matches what the clien= t is doing. The client is creating a immutable message object that is deli= vered to a consuming client via the poll queue. There is a message object = getting created in the registry that is automatically removed once consumed= . I don=92t view this as a protocol extension based on the extensibility o= ptions provided in RFC 5730. Please show me in the RFC=92s where it states that all previous commands we= re meant to touch an object in the registry. There is no way that RFC 5730= could foresee all of the possible set of objects that a server could suppo= rt, which is why there is the concept of an object extension. There is var= iance in the set of verbs supported by the EPP domain, host, and contact RF= C=92s. A transfer and renew is not applicable to a host object and a renew= is not applicable to a contact object. EPP provides the ability to specif= ically define what verbs apply and what data needs to be sent and received = to meet the needs of the particular object. As stated many times on this list, there should be no mixing of a protocol = extension and an object extension in a single specification, which is what = is currently being done in draft-ietf-eppext-keyrelay. Making draft-ietf-e= ppext-keyrelay an object extension that includes support for the create com= mand addresses this issue and is not disallowed by any text that I=92m awar= e of in the EPP RFC=92S. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Feb 5, 2015, at 9:32 AM, Antoin Verschuren > wrote: I believe this is the essence of the confusion. The authors believe that like Scott, an "EPP Command" always creat= es an object in the registry. That is how we read section 2.9.3 of RFC5730. James believes that a create command can also be used to create "something= =94 in the poll queue only, without creating an object in the registry. Reu= sing the create command like this is less work. For relay, it is not desirable to create an object in the registry, as noth= ing is done with the object data after queueing in the poll queue, and just= polutes the registry, let alone the question of who owns the object and wh= at will trigger it to be deleted. For relay we are looking for a process to place data in the poll queue only= without it becomming an object in the registry. That is why the relay draft sugested a 4th section (2.9.4) of a new type of= protocol commands that we will call "Communication Commands=94 where a com= mand will create a poll queue message, but does not create or change any ob= jects in the registry. We cannot call this new command an "EPP Command=94 under this new = "Communication Commands=94 section, just like there is a difference between= an "EPP Query Command=94 under Query Commands, and an "EPP Command=94 under the Object Transform Commands. I have no deep knowledge of XML namespaces or mixing protocol and command e= xtensions, but this is what this new command needs to do, and is something = EPP hasn=92t seen the need to do before. All previous commands were meant t= o touch an object in the registry. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 xmpp:antoinverschuren@gmail.com Op 30 jan. 2015, om 16:08 heeft Hollenbeck, Scott > het volgende geschreven: EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you=92re proposing, the source client would create the transient object= that I=92m assuming would result in a poll notification containing a signa= l to the client to submit an info command to get the transient object infor= mation? I=92m assuming that the target client would then need to delete th= e transient object once they=92re done with processing the message. I beli= eve it=92s simpler and consistent with the concept of creating a transient = poll message to support the create to create the poll message and the info = response poll message for the consumption of the transient object. In this= case the poll queue is functioning as the repository for the transient obj= ect with the signal and data being one and the same, and the deletion of th= e transient object handled via the standard poll queue mechanism. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott w= rote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_1C730264F4394FB89ABF803BB4DCC2E0verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7B659979E190364BA5D7D71889140EDF@verisign.com> Content-Transfer-Encoding: quoted-printable Antoin,

My understanding of EPP is that it defines 7 object verbs (check, info= , create, delete, renew, transfer query / request / cancel / reject / appro= ve, and update), where I don=92t capture some of the base protocol commands= like login, logout, and poll, with the ability to extend the protocol to support new objects in separate spec= ifications that define which verbs are supported for those objects and what= is passed in the commands and responses.  Nowhere does it state in RF= C 5730 or RFC 3735 that an object extension must support a specific set of verbs and that a create must create =93an o= bject in the registry=94 with a single class of object.  The verbs sup= ported are specific to the object that exists in some form in the registry.=  An object could be a standard object like domain, it could be an immutable message object like with the key relay me= ssage, or could be a generated object based on a client info command ( Name= Suggestion Mapping - http://www.verisigninc.com/assets/epp-sdk/= EPP-Suggestion-Mapping.pdf and Balance Mapping - http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_balance_v0= 0.html).  I believe the key is that there can be many forms of obj= ects that are supported by the server that can be represented using an EPP = object extension.  The specification of the EPP object extension defines the specifics about what verbs are sup= ported.  

Reusing a create command is not simply less work but matches what the = client is doing.  The client is creating a immutable message object th= at is delivered to a consuming client via the poll queue.  There is a = message object getting created in the registry that is automatically removed once consumed.  I don=92t view this as = a protocol extension based on the extensibility options provided in RFC 573= 0.  

Please show me in the RFC=92s where it states that all previous comman= ds were meant to touch an object in the registry.  There is no way tha= t RFC 5730 could foresee all of the possible set of objects that a server c= ould support, which is why there is the concept of an object extension.  There is variance in the set of verb= s supported by the EPP domain, host, and contact RFC=92s.  A transfer = and renew is not applicable to a host object and a renew is not applicable = to a contact object.  EPP provides the ability to specifically define what verbs apply and what data needs to be sent and= received to meet the needs of the particular object.

As stated many times on this list, there should be no mixing of a prot= ocol extension and an object extension in a single specification, which is = what is currently being done in draft-ietf-eppext-keyrelay.  Maki= ng draft-ietf-eppext-keyrelay an object extension that includes support for the create command addresses this issue and is n= ot disallowed by any text that I=92m aware of in the EPP RFC=92S.  

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

On Feb 5, 2015, at 9:32 AM, Antoin Verschuren <ietf@antoin.nl> wrote:

I believe this is the essence of the confusion. The authors believe that like Scott, an "EPP <create> Command&qu= ot; always creates an object in the registry. That is how we read section 2= .9.3 of RFC5730.
James believes that a create command can also be used to create "somet= hing=94 in the poll queue only, without creating an object in the registry.= Reusing the create command like this is less work.

For relay, it is not desirable to create an object in the registry, as noth= ing is done with the object data after queueing in the poll queue, and just= polutes the registry, let alone the question of who owns the object and wh= at will trigger it to be deleted.

For relay we are looking for a process to place data in the poll queue only= without it becomming an object in the registry.
That is why the relay draft sugested a 4th section (2.9.4) of a new type of= protocol commands that we will call "Communication Commands=94 where = a command will create a poll queue message, but does not create or change a= ny objects in the registry.

We cannot call this new command an "EPP <create> Command=94 unde= r this new "Communication Commands=94 section, just like there is a di= fference between an "EPP <transfer> Query Command=94 under Query= Commands, and an "EPP <transfer> Command=94 under the Object Tr= ansform Commands.

I have no deep knowledge of XML namespaces or mixing protocol and command e= xtensions, but this is what this new command needs to do, and is something = EPP hasn=92t seen the need to do before. All previous commands were meant t= o touch an object in the registry.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
xmpp:antoinverschuren@gmail.com=




Op 30 jan. 2015, om 16:08 heeft Hollenbeck, Scott <shollenbeck@verisign.com> het volgende geschr= even:

EPP has no concept of =93objects=94 in the poll q= ueue. The poll queue manipulates messages. Objects are manipulated by trans= form commands like create, delete, etc.

I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would be automatically deleted when it= expired).

Scott

From: Gould, James
Sent: Friday, January 30, 2015 9:57 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Scott,

I believe the intent is to insert the transient object into the poll queue = for the target client.  The acknowledgement of the poll message should= result in the implicit removal of the transient object from the server. &n= bsp;With what you=92re proposing, the source client would create the transient object that I=92m assuming would result = in a poll notification containing a signal to the client to submit an info = command to get the transient object information?  I=92m assuming that = the target client would then need to delete the transient object once they=92re done with processing the message. &nbs= p;I believe it=92s simpler and consistent with the concept of creating a tr= ansient poll message to support the create to create the poll message and t= he info response poll message for the consumption of the transient object.  In this case the poll queue is functioning = as the repository for the transient object with the signal and data being o= ne and the same, and the deletion of the transient object handled via the s= tandard poll queue mechanism.     

=97

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <shollenbeck@verisign.com= > wrote:


-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

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

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

--_000_1C730264F4394FB89ABF803BB4DCC2E0verisigncom_-- --_004_1C730264F4394FB89ABF803BB4DCC2E0verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 05 Feb 2015 15:13:19 GMT"; modification-date="Thu, 05 Feb 2015 15:13:19 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_1C730264F4394FB89ABF803BB4DCC2E0verisigncom_-- From nobody Thu Feb 5 08:08:32 2015 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 E46491A8981 for ; Thu, 5 Feb 2015 08:08:24 -0800 (PST) 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 YbHd4hEHpDSD for ; Thu, 5 Feb 2015 08:08:11 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645241A00DF for ; Thu, 5 Feb 2015 08:08:09 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKVNOVaLaOi0hscLx08PTO8TTHbPEBoZxW@postini.com; Thu, 05 Feb 2015 08:08:11 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t15G87Q9016414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 11:08:07 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Feb 2015 11:08:06 -0500 From: "Hollenbeck, Scott" To: "Gould, James" , Antoin Verschuren Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AQHQQVCbn3FmCyCWSq6l2+OWlzutM5zifbyA//+611A= Date: Thu, 5 Feb 2015 16:08:06 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F3B453@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <1C730264-F439-4FB8-9ABF-803BB4DCC2E0@verisign.com> In-Reply-To: <1C730264-F439-4FB8-9ABF-803BB4DCC2E0@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_831693C2CDA2E849A7D7A712B24E257F49F3B453BRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 16:08:27 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F49F3B453BRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F49F3B453BRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F49F3B453BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Making draft-ietf-eppext-keyrelay an object extension that includes suppo= rt for the create command addresses this issue... I could support this. It's consistent with what I described in this message= : http://www.ietf.org/mail-archive/web/eppext/current/msg00319.html Scott From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James Sent: Thursday, February 05, 2015 10:13 AM To: Antoin Verschuren Cc: eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Antoin, My understanding of EPP is that it defines 7 object verbs (check, info, cre= ate, delete, renew, transfer query / request / cancel / reject / approve, a= nd update), where I don't capture some of the base protocol commands like l= ogin, logout, and poll, with the ability to extend the protocol to support = new objects in separate specifications that define which verbs are supporte= d for those objects and what is passed in the commands and responses. Nowh= ere does it state in RFC 5730 or RFC 3735 that an object extension must sup= port a specific set of verbs and that a create must create "an object in th= e registry" with a single class of object. The verbs supported are specifi= c to the object that exists in some form in the registry. An object could = be a standard object like domain, it could be an immutable message object l= ike with the key relay message, or could be a generated object based on a c= lient info command ( Name Suggestion Mapping - http://www.verisigninc.com/a= ssets/epp-sdk/EPP-Suggestion-Mapping.pdf and Balance Mapping - http://www.v= erisigninc.com/assets/epp-sdk/verisign_epp-extension_balance_v00.html). I = believe the key is that there can be many forms of objects that are support= ed by the server that can be represented using an EPP object extension. Th= e specification of the EPP object extension defines the specifics about wha= t verbs are supported. Reusing a create command is not simply less work but matches what the clien= t is doing. The client is creating a immutable message object that is deli= vered to a consuming client via the poll queue. There is a message object = getting created in the registry that is automatically removed once consumed= . I don't view this as a protocol extension based on the extensibility opt= ions provided in RFC 5730. Please show me in the RFC's where it states that all previous commands were= meant to touch an object in the registry. There is no way that RFC 5730 c= ould foresee all of the possible set of objects that a server could support= , which is why there is the concept of an object extension. There is varia= nce in the set of verbs supported by the EPP domain, host, and contact RFC'= s. A transfer and renew is not applicable to a host object and a renew is = not applicable to a contact object. EPP provides the ability to specifical= ly define what verbs apply and what data needs to be sent and received to m= eet the needs of the particular object. As stated many times on this list, there should be no mixing of a protocol = extension and an object extension in a single specification, which is what = is currently being done in draft-ietf-eppext-keyrelay. Making draft-ietf-e= ppext-keyrelay an object extension that includes support for the create com= mand addresses this issue and is not disallowed by any text that I'm aware = of in the EPP RFC'S. Thanks, - JG [cid:image001.png@01D04134.04B15620] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Feb 5, 2015, at 9:32 AM, Antoin Verschuren > wrote: I believe this is the essence of the confusion. The authors believe that like Scott, an "EPP Command" always creat= es an object in the registry. That is how we read section 2.9.3 of RFC5730. James believes that a create command can also be used to create "something"= in the poll queue only, without creating an object in the registry. Reusin= g the create command like this is less work. For relay, it is not desirable to create an object in the registry, as noth= ing is done with the object data after queueing in the poll queue, and just= polutes the registry, let alone the question of who owns the object and wh= at will trigger it to be deleted. For relay we are looking for a process to place data in the poll queue only= without it becomming an object in the registry. That is why the relay draft sugested a 4th section (2.9.4) of a new type of= protocol commands that we will call "Communication Commands" where a comma= nd will create a poll queue message, but does not create or change any obje= cts in the registry. We cannot call this new command an "EPP Command" under this new "C= ommunication Commands" section, just like there is a difference between an = "EPP Query Command" under Query Commands, and an "EPP = Command" under the Object Transform Commands. I have no deep knowledge of XML namespaces or mixing protocol and command e= xtensions, but this is what this new command needs to do, and is something = EPP hasn't seen the need to do before. All previous commands were meant to = touch an object in the registry. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 xmpp:antoinverschuren@gmail.com Op 30 jan. 2015, om 16:08 heeft Hollenbeck, Scott > het volgende geschreven: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_831693C2CDA2E849A7D7A712B24E257F49F3B453BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Making draft-ietf-eppext-keyrelay an = object extension that includes support for the create command addresses thi= s issue…

 

I could support this. It’s consisten= t with what I described in this message:

 

http://www.ietf.org/mail-archive/web/eppex= t/current/msg00319.html

 

Scott<= o:p>

 

From: EppExt [= mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James
Sent: Thursday, February 05, 2015 10:13 AM
To: Antoin Verschuren
Cc: eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Antoin,

 

My understanding of EPP is that it defines 7 object = verbs (check, info, create, delete, renew, transfer query / request / cance= l / reject / approve, and update), where I don’t capture some of the = base protocol commands like login, logout, and poll, with the ability to extend the protocol to support new objects i= n separate specifications that define which verbs are supported for those o= bjects and what is passed in the commands and responses.  Nowhere does= it state in RFC 5730 or RFC 3735 that an object extension must support a specific set of verbs and that a create= must create “an object in the registry” with a single class of= object.  The verbs supported are specific to the object that exists i= n some form in the registry.  An object could be a standard object like domain, it could be an immutable message object lik= e with the key relay message, or could be a generated object based on a cli= ent info command ( Name Suggestion Mapping - http://www.verisign= inc.com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf and Balance Mapping - http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_balance_v0= 0.html).  I believe the key is that there can be many forms of obj= ects that are supported by the server that can be represented using an EPP = object extension.  The specification of the EPP object extension defines the specifics about what verbs are sup= ported.  

 

Reusing a create command is not simply less work but= matches what the client is doing.  The client is creating a immutable= message object that is delivered to a consuming client via the poll queue.=  There is a message object getting created in the registry that is automatically removed once consumed.  I don&#= 8217;t view this as a protocol extension based on the extensibility options= provided in RFC 5730.  

 

Please show me in the RFC’s where it states th= at all previous commands were meant to touch an object in the registry. &nb= sp;There is no way that RFC 5730 could foresee all of the possible set of o= bjects that a server could support, which is why there is the concept of an object extension.  There is variance i= n the set of verbs supported by the EPP domain, host, and contact RFC’= ;s.  A transfer and renew is not applicable to a host object and a ren= ew is not applicable to a contact object.  EPP provides the ability to specifically define what verbs apply and what data needs to= be sent and received to meet the needs of the particular object.

 

As stated many times on this list, there should be n= o mixing of a protocol extension and an object extension in a single specif= ication, which is what is currently being done in draft-ietf-eppext-ke= yrelay.  Making draft-ietf-eppext-keyrelay an object extension that includes support for the create command addresses= this issue and is not disallowed by any text that I’m aware of in th= e EPP RFC’S.  

 

Thanks,

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Veri= signInc.com

 

On Feb 5, 2015, at 9:32 AM, Antoin Verschuren <ietf@antoin.nl> wrote:



I believe this is the essence of the confusion.
The authors believe that like Scott, an "EPP <create> Command&qu= ot; always creates an object in the registry. That is how we read section 2= .9.3 of RFC5730.
James believes that a create command can also be used to create "somet= hing” in the poll queue only, without creating an object in the regis= try. Reusing the create command like this is less work.

For relay, it is not desirable to create an object in the registry, as noth= ing is done with the object data after queueing in the poll queue, and just= polutes the registry, let alone the question of who owns the object and wh= at will trigger it to be deleted.

For relay we are looking for a process to place data in the poll queue only= without it becomming an object in the registry.
That is why the relay draft sugested a 4th section (2.9.4) of a new type of= protocol commands that we will call "Communication Commands” wh= ere a command will create a poll queue message, but does not create or chan= ge any objects in the registry.

We cannot call this new command an "EPP <create> Command” = under this new "Communication Commands” section, just like there= is a difference between an "EPP <transfer> Query Command”= under Query Commands, and an "EPP <transfer> Command” und= er the Object Transform Commands.

I have no deep knowledge of XML namespaces or mixing protocol and command e= xtensions, but this is what this new command needs to do, and is something = EPP hasn’t seen the need to do before. All previous commands were mea= nt to touch an object in the registry.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
xmpp:antoinverschuren@gmail.com=




Op 30 jan. 2015, om 16:08 heeft Hollenbeck, Scott <shollenbeck@verisign.com> het volgende geschr= even:


EPP has no concept of “objects” in the p= oll queue. The poll queue manipulates messages. Objects are manipulated by = transform commands like create, delete, etc.

I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would be automatically deleted when it= expired).

Scott

From: Gould, James
Sent: Friday, January 30, 2015 9:57 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Scott,

I believe the intent is to insert the transient object into the poll queue = for the target client.  The acknowledgement of the poll message should= result in the implicit removal of the transient object from the server. &n= bsp;With what you’re proposing, the source client would create the transient object that I’m assuming would res= ult in a poll notification containing a signal to the client to submit an i= nfo command to get the transient object information?  I’m assumi= ng that the target client would then need to delete the transient object once they’re done with processing the message. =  I believe it’s simpler and consistent with the concept of creat= ing a transient poll message to support the create to create the poll messa= ge and the info response poll message for the consumption of the transient object.  In this case the poll queue is functioning = as the repository for the transient object with the signal and data being o= ne and the same, and the deletion of the transient object handled via the s= tandard poll queue mechanism.     

—

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:


-----Original Message-----
From: EppExt [mailto:eppext-boun= ces@ietf.org] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.o= rg/mailman/listinfo/eppext


_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.o= rg/mailman/listinfo/eppext

 

--_000_831693C2CDA2E849A7D7A712B24E257F49F3B453BRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F49F3B453BRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Thu, 05 Feb 2015 16:08:06 GMT"; modification-date="Thu, 05 Feb 2015 16:08:06 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F49F3B453BRN1WNEXMBX01vc_-- From nobody Thu Feb 5 08:40:57 2015 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 D57011A19F7; Thu, 5 Feb 2015 08:40:53 -0800 (PST) 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 vHx_UgAmBmPR; Thu, 5 Feb 2015 08:40:45 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB1D1A89A7; Thu, 5 Feb 2015 08:40:45 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKVNOc+CsbphrMdfO3HlT2gcIngLM7/445@postini.com; Thu, 05 Feb 2015 08:40:45 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t15GeNv0020190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 11:40:23 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Feb 2015 11:40:22 -0500 From: "Gould, James" To: "eppext@ietf.org" , EPP Provreg , "gtld-tech@icann.org" Thread-Topic: Publishing of the IDN Table EPP Mapping IETF Draft Thread-Index: AQHQQWJumxRDFmqfz0eXkuVv273QPg== Date: Thu, 5 Feb 2015 16:40:21 +0000 Message-ID: <96D1CC17-60A1-445A-8B2F-B56918E4D881@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_96D1CC1760A1445A8B2FB56918E4D881verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [eppext] Publishing of the IDN Table EPP Mapping IETF Draft 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, 05 Feb 2015 16:40:54 -0000 --_004_96D1CC1760A1445A8B2FB56918E4D881verisigncom_ Content-Type: multipart/alternative; boundary="_000_96D1CC1760A1445A8B2FB56918E4D881verisigncom_" --_000_96D1CC1760A1445A8B2FB56918E4D881verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The first draft of the IDN Table EPP Mapping has been submitted to the IETF= . I co-authored this draft with Francisco Obispo and Luis Mu=F1oz from Uni= registry to provide a mechanism for getting IDN Table information for the r= egistration of IDNs, using the EPP domain name mapping, and optionally with= the IDN mapping extension ( draft-ietf-eppext-idnmap ). We would like thi= s draft to be included in a re-charting of the EPPEXT Working Group. The d= raft information is provided below. URL: http://www.ietf.org/internet-drafts/draft-gould-idn-table-0= 0.txt Status: https://datatracker.ietf.org/doc/draft-gould-idn-table/ Htmlized: http://tools.ietf.org/html/draft-gould-idn-table-00 Please review the draft and provide any feedback. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_96D1CC1760A1445A8B2FB56918E4D881verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0A0C674CD8A7B24798CCC8BAA7045AFF@verisign.com> Content-Transfer-Encoding: quoted-printable
The first draft of the IDN Table EPP Mapping has been submitted to the= IETF.  I co-authored this draft with Francisco Obispo and Luis Mu=F1o= z from Uniregistry to provide a mechanism for getting IDN Table information= for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension (&n= bsp;draft-ietf-eppext-idnmap ).  We would like this draft to be includ= ed in a re-charting of the EPPEXT Working Group.  The draft informatio= n is provided below.


Please review the draft and provide any feedback.

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_96D1CC1760A1445A8B2FB56918E4D881verisigncom_-- --_004_96D1CC1760A1445A8B2FB56918E4D881verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 05 Feb 2015 16:40:21 GMT"; modification-date="Thu, 05 Feb 2015 16:40:21 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_96D1CC1760A1445A8B2FB56918E4D881verisigncom_-- From nobody Thu Feb 5 09:08:18 2015 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 05F081A064C for ; Thu, 5 Feb 2015 09:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, T_RP_MATCHES_RCVD=-0.01] 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 I9UPykITLja5 for ; Thu, 5 Feb 2015 09:08:11 -0800 (PST) Received: from walhalla.antoin.nl (walhalla.antoin.nl [IPv6:2a01:670:6aa4:da00::6]) by ietfa.amsl.com (Postfix) with ESMTP id 210B81A87ED for ; Thu, 5 Feb 2015 09:08:11 -0800 (PST) Received: by walhalla.antoin.nl (Postfix, from userid 5001) id 6C6A1280813; Thu, 5 Feb 2015 18:08:10 +0100 (CET) Received: from [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2] (unknown [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2]) by walhalla.antoin.nl (Postfix) with ESMTPSA id 92D0828041F; Thu, 5 Feb 2015 18:08:07 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_1157B647-490C-4EC7-AA1E-D27E19F4F58F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Antoin Verschuren In-Reply-To: Date: Thu, 5 Feb 2015 18:07:50 +0100 Message-Id: <2E3BF4C3-5348-4B15-A520-990C0938299B@antoin.nl> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-54! 25-4BAC -A 17A-25D13EF88A8F@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Gould, James" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Rik Ribbers , Miek Gieben , "Hollenbeck, Scott" , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 17:08:13 -0000 --Apple-Mail=_1157B647-490C-4EC7-AA1E-D27E19F4F58F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Op 5 feb. 2015, om 15:08 heeft Gould, James het = volgende geschreven: > I believe that RFC 5730 is not limited to a certain class of objects = that can be provisioned. A create of a transient, immutable message = object is a transform command and the use of a poll response supports a = query command. =20 Apologies James if I am confused.=20 So the question boiles down to: -What is meant by "object=94 in RFC5730? The authors believe what is meant here with "object" is something stored = in the registry database that requires uniqueness and ownership. Not all = EPP commands can be performed on all objects, A database can be extended = with new objects which will require an extension to provision the new = object, or an existing object could be extended with new records which = needs an extension of the command to provision the new records. You think "object" does not relate to a registry database table and can = be any data blob in the communication stream as well. If we all agree that an object means any blob, should that be clarified = in RFC5730? At least I am confused when object does not refer to an object in the = registry database, as I cannot verify uniqueness and consistancy of the = EPP processes over the database. > My recommendation to the authors of the Key Relay Extension is to make = the draft an object mapping with a create transform command, a the poll = response, and with a unique relay identifier to address the end-to-end = idempotency concern. =20 I don=92t see the need for a seperate unique relay identifier. Since the = timestamp can be part of the calculation of the expiry of the relayed = key, no second message is identical. If and only if the timestamp is = different and the expiry is not dependant of the timestamp and the rest = of the message is identical can the message be disguarded as identical, = but we don=92t need a duplicate field to identify that, and it is left = to the receiver how to interpret that. There may be future use cases = where only the timestamp is different but where the message is valid and = needs to be processed by the receiver. - --=20 Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 xmpp:antoinverschuren@gmail.com --Apple-Mail=_1157B647-490C-4EC7-AA1E-D27E19F4F58F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJU06N2AAoJEHda8rd0+iNRVe8H/Al7kymufkWsYor4IJTcpFOH uqSMhUnLK8xA8KqW0ajXTYdEZ2gBuuDDD0l7usy4f/l5EZrDn31oZP/aQXrw1w8d bMTf0jYA+cy6c9wdnOd4d4QWqkuHDapy2lmfNjGzpf6bccniZfdHz26GlbVPrImQ +IQ+005SQF/mJU0Lj6mPqB1g1mqM0qPxMyyzNNXZQK+sxYjMiUmh6QDy0BBv1X7/ knbKoLTlU40++SdGiKQbEdWBXEseE0Nvy8UQSet/IpDrAHjjMKPQgv+DgjpGPfiq OpsuRBk31tmmgSqlSTnk3S3+a57ifvl5e8Yy1pZfCyBam4Fb2wyRtDAR09BPXoA= =rz90 -----END PGP SIGNATURE----- --Apple-Mail=_1157B647-490C-4EC7-AA1E-D27E19F4F58F-- From nobody Thu Feb 5 10:22:57 2015 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 5CD5A1A0AF1 for ; Thu, 5 Feb 2015 10:22:52 -0800 (PST) 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 a43Ww4Kz2M_x for ; Thu, 5 Feb 2015 10:22:49 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88FA1A00A7 for ; Thu, 5 Feb 2015 10:22:40 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKVNO08EBEnUZ9+Eyve3Sh9ZLsA8Sc5cop@postini.com; Thu, 05 Feb 2015 10:22:49 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t15IMc8K006575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 13:22:39 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Feb 2015 13:22:38 -0500 From: "Gould, James" To: Antoin Verschuren Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAELswAAABaAQAAAMFFgAABzoiAAApRdhD//7ZaAIAATNuwgAidxICAAAjhAIAADnsAgAAyNgCAABTjAA== Date: Thu, 5 Feb 2015 18:22:38 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-54! ! 25-4BAC -A 17A-25D13EF88A8F@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2E3BF4C3-5348-4B15-A520-990C0938299B@antoin.nl> In-Reply-To: <2E3BF4C3-5348-4B15-A520-990C0938299B@antoin.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_C3589E621E454ED29AEFEE0D1C998F60verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , "Hollenbeck, Scott" , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available 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, 05 Feb 2015 18:22:52 -0000 --_004_C3589E621E454ED29AEFEE0D1C998F60verisigncom_ Content-Type: multipart/alternative; boundary="_000_C3589E621E454ED29AEFEE0D1C998F60verisigncom_" --_000_C3589E621E454ED29AEFEE0D1C998F60verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Antoin, RFC 5730 does not explicitly specify what an object is or is not. I believ= e that you are putting unnecessary restrictions on what an object in EPP ca= n be. To give you an example, the IDN Table Mapping ( https://tools.ietf.o= rg/html/draft-gould-idn-table ) that was posted today defines a new IDN Tab= le object that supports no transform commands and it may or may not be phys= ically stored in the registry database. Should it be defined as a protocol= extension as well based on your restriction? The protocol does not and sh= ould not dictate whether an object is physically stored in the database, is= an immutable object that is stored in a queue or in a specific database ta= ble, or is cached or generated to provide information to the client. A blo= b that is well formed and structured is an object in a programming language= as well as in a protocol like EPP. My recommendation is to create a singl= e EPP extension form in draft-ietf-eppext-keyrelay, where an object extensi= on makes the most sense. The responses on the list seem to support this ap= proach. Use of a unique relay identifier is a straight forward mechanism for the co= nsuming client to know that it has or has not processed the message before.= There is no need to rely on some heuristic on the timestamp or comparing = a set of fields to address the concern that Scott raised. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Feb 5, 2015, at 12:07 PM, Antoin Verschuren > wrote: Op 5 feb. 2015, om 15:08 heeft Gould, James > het volgende geschreven: I believe that RFC 5730 is not limited to a certain class of objects that c= an be provisioned. A create of a transient, immutable message object is a = transform command and the use of a poll response supports a query command. Apologies James if I am confused. So the question boiles down to: -What is meant by "object=94 in RFC5730? The authors believe what is meant here with "object" is something stored in= the registry database that requires uniqueness and ownership. Not all EPP = commands can be performed on all objects, A database can be extended with n= ew objects which will require an extension to provision the new object, or = an existing object could be extended with new records which needs an extens= ion of the command to provision the new records. You think "object" does not relate to a registry database table and can be = any data blob in the communication stream as well. If we all agree that an object means any blob, should that be clarified in = RFC5730? At least I am confused when object does not refer to an object in the regis= try database, as I cannot verify uniqueness and consistancy of the EPP proc= esses over the database. My recommendation to the authors of the Key Relay Extension is to make the = draft an object mapping with a create transform command, a the poll respons= e, and with a unique relay identifier to address the end-to-end idempotency= concern. I don=92t see the need for a seperate unique relay identifier. Since the ti= mestamp can be part of the calculation of the expiry of the relayed key, no= second message is identical. If and only if the timestamp is different and= the expiry is not dependant of the timestamp and the rest of the message i= s identical can the message be disguarded as identical, but we don=92t need= a duplicate field to identify that, and it is left to the receiver how to = interpret that. There may be future use cases where only the timestamp is d= ifferent but where the message is valid and needs to be processed by the re= ceiver. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 xmpp:antoinverschuren@gmail.com --_000_C3589E621E454ED29AEFEE0D1C998F60verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Antoin,

RFC 5730 does not explicitly specify what an object is or is not. &nbs= p;I believe that you are putting unnecessary restrictions on what an object= in EPP can be.  To give you an example, the IDN Table Mapping ( https://tools= .ietf.org/html/draft-gould-idn-table ) that was posted today defines a = new IDN Table object that supports no transform commands and it may or may = not be physically stored in the registry database.  Should it be defined as a protocol extension as well based= on your restriction?  The protocol does not and should not dictate wh= ether an object is physically stored in the database, is an immutable objec= t that is stored in a queue or in a specific database table, or is cached or generated to provide information to the cl= ient.  A blob that is well formed and structured is an object in a pro= gramming language as well as in a protocol like EPP.  My recommendatio= n is to create a single EPP extension form in draft-ietf-eppext-keyrelay, where an object extension makes the most se= nse.  The responses on the list seem to support this approach.

Use of a unique relay identifier is a straight forward mechanism for t= he consuming client to know that it has or has not processed the message be= fore.  There is no need to rely on some heuristic on the timestamp or = comparing a set of fields to address the concern that Scott raised.  

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

On Feb 5, 2015, at 12:07 PM, Antoin Verschuren <ietf@antoin.nl> wrote:

Op 5 feb. 2015, om 15:08 heeft Gould, James <<= a href=3D"mailto:JGould@verisign.com">JGould@verisign.com> het volge= nde geschreven:

I believe that RFC 5730 is not limited to a certa= in class of objects that can be provisioned.  A create of a transient,= immutable message object is a transform command and the use of a poll resp= onse supports a query command.  

Apologies James if I am confused.

So the question boiles down to:

-What is meant by "object=94 in RFC5730?

The authors believe what is meant here with "object" is something= stored in the registry database that requires uniqueness and ownership. No= t all EPP commands can be performed on all objects, A database can be exten= ded with new objects which will require an extension to provision the new object, or an existing object could be exte= nded with new records which needs an extension of the command to provision = the new records.
You think "object" does not relate to a registry database table a= nd can be any data blob in the communication stream as well.

If we all agree that an object means any blob, should that be clarified in = RFC5730?
At least I am confused when object does not refer to an object in the regis= try database, as I cannot verify uniqueness and consistancy of the EPP proc= esses over the database.

My recommendation to the authors of the Key Relay= Extension is to make the draft an object mapping with a create transform c= ommand, a the poll response, and with a unique relay identifier to address = the end-to-end idempotency concern.  

I don=92t see the need for a seperate unique relay identifier. Since the ti= mestamp can be part of the calculation of the expiry of the relayed key, no= second message is identical. If and only if the timestamp is different and= the expiry is not dependant of the timestamp and the rest of the message is identical can the message be disg= uarded as identical, but we don=92t need a duplicate field to identify that= , and it is left to the receiver how to interpret that. There may be future= use cases where only the timestamp is different but where the message is valid and needs to be processed by t= he receiver.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
xmpp:antoinverschuren@gmail.com=





--_000_C3589E621E454ED29AEFEE0D1C998F60verisigncom_-- --_004_C3589E621E454ED29AEFEE0D1C998F60verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 05 Feb 2015 18:22:38 GMT"; modification-date="Thu, 05 Feb 2015 18:22:38 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_C3589E621E454ED29AEFEE0D1C998F60verisigncom_-- From nobody Fri Feb 6 05:40:49 2015 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 9CF691A1AAC for ; Fri, 6 Feb 2015 05:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 DeStEyNfBIyq for ; Fri, 6 Feb 2015 05:40:44 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759C01A0367 for ; Fri, 6 Feb 2015 05:40:44 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKVNTEW/SeCZKTWpQGgbtU6Syme13sLaUb@postini.com; Fri, 06 Feb 2015 05:40:44 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t16DehEp009427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Feb 2015 08:40:43 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 6 Feb 2015 08:40:42 -0500 From: "Hollenbeck, Scott" To: "eppext@ietf.org" Thread-Topic: Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Thread-Index: AdBCEn+vvcyzjjByRt6JTgZTR3aSZA== Date: Fri, 6 Feb 2015 13:40:41 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@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: Subject: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 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 Feb 2015 13:40:46 -0000 IANA has received a request to register an EPP extension titled "Registry F= ee Extension for the Extensible Provisioning Protocol (EPP)". Per RFC 7451 = they have requested designated expert review of the request. The list of de= signated experts appointed by the IESG can be found IANA's registry web pag= e: http://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#epp-ext= ensions-1 This is the form received by IANA: -----BEGIN FORM----- Name of Extension: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Document Status: Informational Reference: http://tools.ietf.org/html/draft-brown-epp-fees Registrant Name and Email Address: Gavin Brown, TLDs: any IPR Disclosure: None Status: Active Notes: None -----END FORM----- As specified in RFC 7451 the discussion of this request is to take place on= this mailing list. So let's discuss it. I have no issue with the extension itself. Given that this request refers t= o an existing Internet-Draft document, I believe it would be more appropria= te for the document to include an IANA Considerations section that includes= a request to register the extension if the document becomes an RFC. My rec= ommendation to IANA would be to hold off on processing the request until th= e document is either submitted to and approved by the IESG or it is publish= ed outside the IETF process. Would the other designated experts please share the results of your individ= ual evaluations in this thread. Scott From nobody Fri Feb 6 09:35:10 2015 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 D69451A7004 for ; Fri, 6 Feb 2015 09:35:08 -0800 (PST) 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 woetmv1gCCV8 for ; Fri, 6 Feb 2015 09:35:07 -0800 (PST) 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 E17F91A6FEC for ; Fri, 6 Feb 2015 09:35:06 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKVNT7Sm6DFBDNhiEhoALdJ6dekqdqZKHG@postini.com; Fri, 06 Feb 2015 09:35:07 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t16HZ5UB000543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Feb 2015 12:35:05 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 6 Feb 2015 12:35:04 -0500 From: "Hollenbeck, Scott" To: "eppext@ietf.org" Thread-Topic: Call for Participation: Registration Operations Workshop 2015-1 Thread-Index: AdBCMz3Z58Mol4M9RqC9OKMMKdDecA== Date: Fri, 6 Feb 2015 17:35:04 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F3CD0F@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: Subject: [eppext] Call for Participation: Registration Operations Workshop 2015-1 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 Feb 2015 17:35:09 -0000 Plans are well under way for the first registration operations workshop of = 2015. It's scheduled for Sunday, 22 March 2015, at the start of IETF-92 in = Dallas, Texas, USA. A call for participation is now active. Details can be = found in blog posts on the Verisign and CircleID web sites: http://blogs.verisigninc.com/blog/entry/call_for_participation_registration= _operations http://www.circleid.com/posts/20150206_call_for_participation_registration_= operations_workshop_at_ietf_92/ I'd like to emphasize a few points: The focus of this workshop will be on EPP extensions, how they can be regis= tered, and how we can work on new extensions. The new EPP Extension registr= y is described in RFC 7451: http://www.rfc-editor.org/rfc/rfc7451.txt We're asking people to submit proposals for help with extensions they'd lik= e to register and for extensions they'd like to discuss. If you've develope= d an extension for your registry you're part of the audience we're trying t= o reach. Remote participation will be supported using WebEx. Nothing beats face-to-f= ace conversation, but if you can't make the trip to Dallas you *will* be ab= le to actively participate. Please register in advance. The form and other information can be found at = http://www.regiops.net/. I'll be at the ICANN meeting in Singapore on Tuesday. I'll make time for an= yone who wants to talk. Scott From nobody Mon Feb 9 07:42:19 2015 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 51BD01A1B17 for ; Mon, 9 Feb 2015 07:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.785 X-Spam-Level: ** X-Spam-Status: No, score=2.785 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TuWGWGxmfYn4 for ; Mon, 9 Feb 2015 07:22:54 -0800 (PST) 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 6E1911A1A37 for ; Mon, 9 Feb 2015 07:19:53 -0800 (PST) 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:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version; bh=KMz4b3FdiUW+1j/ItZrlTqkBzhqF/u1aD78tRuRS51c=; b=47Bc3OKVcnn+CZNCwRo9KZoHuwxFHJRzVrXwSevRNgHCcCqbLbGK2yikeA380d+KqiT+It/zONeaW1WT1ns+8/gmI15VH3Xz5yle7qCIfdE+Ltg6hEimaQTZ9xY9ODmdBEID22/RocQFW8hsUzLQsIn384LU/LQX6CNgkTwDzej59Zk2lOwSLJbk39Q60UDCt6AM0/5brCuFuMXowXd8kAfjDrXFBG/nBDkElpD7owBR6Am9E4uX9/w5wYtPceZPgt+9shgkGyKIim1OxzYjdK1Ergn/NCStuoZBFKyVkioOt+kTftWL1vgvuF1fTKLf73smx7ApBpXyRIguD+UvRQ== Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id t19FJU80016865-t19FJU82016865 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Mon, 9 Feb 2015 16:19:30 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01 ([192.168.2.73]) with mapi id 14.03.0174.001; Mon, 9 Feb 2015 16:19:26 +0100 From: Rik Ribbers To: "eppext@ietf.org" , "gtld-tech@icann.org" Thread-Topic: draft-lozano-tmch-func-spec and QLP addendum Thread-Index: AdBEe3u+8NqS47DpRweFcBo3x2Oq6Q== Date: Mon, 9 Feb 2015 15:19:26 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.154] Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B9291E5Akambx2SIDNlocal_" MIME-Version: 1.0 Archived-At: Subject: [eppext] draft-lozano-tmch-func-spec and QLP addendum 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, 09 Feb 2015 15:22:56 -0000 --_000_C80127C588F8F2409E2B535AF968B768B9291E5Akambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I've got a question concerning the QLP addendum in relation to the IETF TMC= H functional specification draft (http://tools.ietf.org/id/draft-lozano-tmc= h-func-spec-09.txt ) In section "5.4.1. Domain Registration" of the IEFT draft a decision table= is provided the services a registry must provide for the QLP allocation sc= enarios. This table suggests that a QLP registration during sunrise must be= validated against the DNL list and the SURL list. However in the QLP addendum it is only mentioned that a QLP registration du= ring sunrise must be validated against the SURL list. I assume that the addendum is correct, but is that a correct assumption? Kind regards, Rik Ribbers --_000_C80127C588F8F2409E2B535AF968B768B9291E5Akambx2SIDNlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I’ve got a question conce= rning the QLP addendum in relation to the IETF TMCH functional specificatio= n draft (http://tools.ietf.org/id/draft-lozano-tmch-func-spec-09.txt )

 

In section “5.4.1.  = Domain Registration” of the IEFT draft a decision table is provided t= he services a registry must provide for the QLP allocation scenarios. This = table suggests that a QLP registration during sunrise must be validated against the DNL list and the SURL list.

 

However in the QLP addendum it = is only mentioned that a QLP registration during sunrise must be validated = against the SURL list.

 

I assume that the addendum is c= orrect, but is that a correct assumption?

 

Kind regards,=

Rik Ribbers

 

 

--_000_C80127C588F8F2409E2B535AF968B768B9291E5Akambx2SIDNlocal_-- From m.alzoba@gmail.com Mon Feb 9 17:44:34 2015 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 47D5A1A8AE4 for ; Mon, 9 Feb 2015 17:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 A0xiZD3KrC0p for ; Mon, 9 Feb 2015 17:44:31 -0800 (PST) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4611A8AD3 for ; Mon, 9 Feb 2015 17:44:31 -0800 (PST) Received: by pdev10 with SMTP id v10so12852942pde.10 for ; Mon, 09 Feb 2015 17:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LjJCNm4dF0zJAtLE0ggyuGJWnB1crS01/f7TTW8jBtY=; b=G6trwOA6gTBdzzYsor46mgR0u00jwn1lqEBfcAqTLBvuLD8HfZm3deio+OmE91QLJE qXe4UajXHNEN8yuXB2hxHOMNJEu2kMfGkmw2rYnBxTLKW2W6Hg0GPZI/FOnfsikbsTcy G2cQJI57RR4ilAfFwi/cz7GGtwXItLOox+a8QVIsisM8cvdF8HtohjrqcSFCAw+ZZADK bpTwe9yp64ufcfxtxxnXoAnv094Uc2FecmPUdZYCreR+2kMXZpPNzHFk4SSwthxv22Gl eigbH/ryBmWsnJB1WscSnkhTQjF74DLVkUNtolW5pW2KXKPea0rAfOf2KllfNfH/Pl0c 1YXw== X-Received: by 10.70.47.70 with SMTP id b6mr14187818pdn.136.1423532670752; Mon, 09 Feb 2015 17:44:30 -0800 (PST) Received: from [10.196.197.177] (47-193.icannmeeting.org. [199.91.193.47]) by mx.google.com with ESMTPSA id qk7sm17516693pbc.74.2015.02.09.17.44.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 17:44:29 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Maxim Alzoba In-Reply-To: Date: Tue, 10 Feb 2015 09:44:26 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2ECFB600-EAFF-4851-A49A-57893CAA150C@gmail.com> References: To: Rik Ribbers X-Mailer: Apple Mail (2.1510) Archived-At: X-Mailman-Approved-At: Mon, 09 Feb 2015 17:52:47 -0800 Cc: gtld-tech@icann.org, eppext@ietf.org, Dmitry Burkov Subject: Re: [eppext] [gtld-tech] draft-lozano-tmch-func-spec and QLP addendum 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, 10 Feb 2015 01:45:30 -0000 Dear Rik,=20 Please be aware that GEO applicants can register domains even not being = in SURL for benefit of the Public Authority. I do not personally understand how to technically formalize it ... list = of public authorities is not limited to 10th ... it is up to 1000-2000 = departments / wholly owned companies belonging to the city=20 in a case of a capital ... also names of parks and monuments in = translation / transliteration ... e.t.c. it is Art 2.2 of the = http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirement= s-qlp-addendum-10apr14-en.pdf Trademark Clearinghouse Rights Protection Mechanism Requirements Qualified Launch Program Addendum "=20 2.2 To a registrant who is an international, national, regional, local = or municipal governmental authority (a =93Public Authority=94) and such = QLP Name is either identical to, or translation or a transliteration of, = (i) the name or acronym of such Public Authority, (ii) the name of a = building, park, monument, airport or other public place operated by such = Public Authority, (iii) the name of a region, city, street, district or = other geographic area under the governance of such Public Authority, or = (iv) the name of a recognized public service provided by such Public = Authority. Except as permitted by this Section 2.2, if a QLP Name = matches a label contained in the Sunrise List, such QLP Name MUST NOT as = part of the Qualified Launch Program be Allocated or registered to a = registrant who is not a SunriseEligible Rights Holder with a valid SMD = file for a label that matches the QLP Name. " P.s: example: police.GEOtld_city should not go to eyewearmaker ... it = should go to Police department of the city.=20 Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID m. +7 916 6761580 skype oldfrogger Current UTC offset: +3 On Feb 9, 2015, at 23:19 , Rik Ribbers wrote: > Hello, > =20 > I=92ve got a question concerning the QLP addendum in relation to the = IETF TMCH functional specification draft = (http://tools.ietf.org/id/draft-lozano-tmch-func-spec-09.txt ) > =20 > In section =935.4.1. Domain Registration=94 of the IEFT draft a = decision table is provided the services a registry must provide for the = QLP allocation scenarios. This table suggests that a QLP registration = during sunrise must be validated against the DNL list and the SURL list. > =20 > However in the QLP addendum it is only mentioned that a QLP = registration during sunrise must be validated against the SURL list. > =20 > I assume that the addendum is correct, but is that a correct = assumption? > =20 > Kind regards, > Rik Ribbers > =20 > =20 From nobody Tue Feb 10 00:38:45 2015 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 DC0EE1A00DB for ; Tue, 10 Feb 2015 00:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.294 X-Spam-Level: X-Spam-Status: No, score=0.294 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 8i7iSF4t5RQF for ; Tue, 10 Feb 2015 00:38:41 -0800 (PST) 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 828B81A0056 for ; Tue, 10 Feb 2015 00:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=95HaWTQ4a57O9NSMYBaOaiYcp3db693csTjxl5kFuZI=; b=VVrnxw4/zI7pxRx/LBlHMpxS24Uxwj3cy7tDLtrsWDwETUeZ9IPzmabe63vTeAr2Pa7ANEbfoUEVG1ValfJSqikVOCBnjlEpqwHv1k9JUvDbA7vnUuDCb5wjv8psGqGWMjT5lnPv5/o6iiMKDnknewjtI1If5cmCWBM6ZMIEog7mfiQ+tqyGZBmJj8mIQiXTOaznw0ukqiCrnYPOX9x9q4Jts2SyESai7XjmCyL4SRKnS+lL4KpGlUWu6WNVitVbJul5Ucz5CC90xAbBktsIcjpPERu895W6Ezo249Oxq2++cDJWKa1GWhulwraPimgUN3wHduaCpy2BCikUftzITQ== Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id t1A8cGPT021874-t1A8cGPV021874 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Tue, 10 Feb 2015 09:38:16 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01 ([192.168.2.73]) with mapi id 14.03.0174.001; Tue, 10 Feb 2015 09:38:12 +0100 From: Rik Ribbers To: "'Maxim Alzoba'" Thread-Topic: [gtld-tech] draft-lozano-tmch-func-spec and QLP addendum Thread-Index: AdBEe3u+8NqS47DpRweFcBo3x2Oq6QATzyQAAA9FRvA= Date: Tue, 10 Feb 2015 08:38:12 +0000 Message-ID: References: <2ECFB600-EAFF-4851-A49A-57893CAA150C@gmail.com> In-Reply-To: <2ECFB600-EAFF-4851-A49A-57893CAA150C@gmail.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "gtld-tech@icann.org" , "eppext@ietf.org" , Dmitry Burkov Subject: Re: [eppext] [gtld-tech] draft-lozano-tmch-func-spec and QLP addendum 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, 10 Feb 2015 08:38:44 -0000 Hello Maxim, Thanks for your reply, I am aware of Article 2.2, but that is not what we a= re confused about. I want to know if our assumption is correct that during a TMCH sunrise a do= main create for a QLP domain name should be validated against the SURL list= and not the DNL list. According the Addendum this is correct, however the = functional spec suggests otherwise. Kind regards, Rik Ribbers -----Original Message----- From: Maxim Alzoba [mailto:m.alzoba@gmail.com]=20 Sent: dinsdag 10 februari 2015 2:44 To: Rik Ribbers Cc: eppext@ietf.org; gtld-tech@icann.org; Dmitry Burkov Subject: Re: [gtld-tech] draft-lozano-tmch-func-spec and QLP addendum Dear Rik,=20 Please be aware that GEO applicants can register domains even not being in = SURL for benefit of the Public Authority. I do not personally understand how to technically formalize it ... list of = public authorities is not limited to 10th ... it is up to 1000-2000 departm= ents / wholly owned companies belonging to the city in a case of a capital = ... also names of parks and monuments in translation / transliteration ... = e.t.c. it is Art 2.2 of the http://newgtlds.icann.org/en/about/trademark-clearingh= ouse/rpm-requirements-qlp-addendum-10apr14-en.pdf Trademark Clearinghouse Rights Protection Mechanism Requirements Qualified = Launch Program Addendum "=20 2.2 To a registrant who is an international, national, regional, local or m= unicipal governmental authority (a "Public Authority") and such QLP Name is= either identical to, or translation or a transliteration of, (i) the name = or acronym of such Public Authority, (ii) the name of a building, park, mon= ument, airport or other public place operated by such Public Authority, (ii= i) the name of a region, city, street, district or other geographic area un= der the governance of such Public Authority, or (iv) the name of a recogni= zed public service provided by such Public Authority. Except as permitted b= y this Section 2.2, if a QLP Name matches a label contained in the Sunrise = List, such QLP Name MUST NOT as part of the Qualified Launch Program be All= ocated or registered to a registrant who is not a SunriseEligible Rights Ho= lder with a valid SMD file for a label that matches the QLP Name. " P.s: example: police.GEOtld_city should not go to eyewearmaker ... it shou= ld go to Police department of the city.=20 Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID m. +7 916 6761580 skype oldfrogger Current UTC offset: +3 On Feb 9, 2015, at 23:19 , Rik Ribbers wrote: > Hello, > =20 > I've got a question concerning the QLP addendum in relation to the=20 > IETF TMCH functional specification draft=20 > (http://tools.ietf.org/id/draft-lozano-tmch-func-spec-09.txt ) > =20 > In section "5.4.1. Domain Registration" of the IEFT draft a decision tab= le is provided the services a registry must provide for the QLP allocation = scenarios. This table suggests that a QLP registration during sunrise must = be validated against the DNL list and the SURL list. > =20 > However in the QLP addendum it is only mentioned that a QLP registration = during sunrise must be validated against the SURL list. > =20 > I assume that the addendum is correct, but is that a correct assumption? > =20 > Kind regards, > Rik Ribbers > =20 > =20 From nobody Tue Feb 10 18:19:23 2015 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 8B0AA1A1BA2 for ; Tue, 10 Feb 2015 18:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.447 X-Spam-Level: ** X-Spam-Status: No, score=2.447 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] 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 cLCW8ngjjBNE for ; Tue, 10 Feb 2015 18:19:18 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 496691A1B82 for ; Tue, 10 Feb 2015 18:19:17 -0800 (PST) Received: from [218.241.103.85] (unknown [218.241.103.85]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BZYGQavNpU6bQFAA--.4338S2; Wed, 11 Feb 2015 10:19:07 +0800 (CST) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ning Kong In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 11 Feb 2015 10:19:08 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.2070.6) X-CM-TRANSID: AQAAf0BZYGQavNpU6bQFAA--.4338S2 X-Coremail-Antispam: 1UD129KBjvJXoWxuF1DGFyDZry3tw4xZFyfXrb_yoW5Xw4Upa 17tw1jkan5tr1UK34xt3WUXw4j9an3tw4xWr9xKr1UAa9xJa48KF1Y9w4rXFZ7CrsYka1j gw4UKr15ur4qv3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkSb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4UMxAI w28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr 4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxG rwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8Jw CI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAI cVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUchL0UUUUU X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 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, 11 Feb 2015 02:19:21 -0000 Hi Scott and all, As one of the designated experts, I read this request and draft. I have = some comments as follows. #1 The document status is Informational according to the request, but = the intended status of draft is Experimental. #2 IMO, the extension of is not necessary. It seems that the = extended is a little overused. I think the extension of = is enough. #3 I=A1=AFm afraid this extension may increase the risk of Security and = Privacy. The fee information of domain registration is sensitive and = maybe trade secrets for most registrars and registries. Because = different registrars would get different price based on their each = commercial contract. So usually the fee information can only be known by = the business people. But if the EPP is extended with the fee function, = the sensitive information about fee may be accessed by the technical = guys even through the log file of EPP system. Regards, Ning > =D4=DA 2015=C4=EA2=D4=C26=C8=D5=A3=AC=CF=C2=CE=E79:40=A3=ACHollenbeck, = Scott =D0=B4=B5=C0=A3=BA >=20 > IANA has received a request to register an EPP extension titled = "Registry Fee Extension for the Extensible Provisioning Protocol (EPP)". = Per RFC 7451 they have requested designated expert review of the = request. The list of designated experts appointed by the IESG can be = found IANA's registry web page: >=20 > = http://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#epp-ex= tensions-1 >=20 > This is the form received by IANA: >=20 > -----BEGIN FORM----- > Name of Extension: > Registry Fee Extension for the Extensible Provisioning Protocol (EPP) >=20 > Document Status: Informational >=20 > Reference: http://tools.ietf.org/html/draft-brown-epp-fees >=20 > Registrant Name and Email Address: > Gavin Brown, >=20 > TLDs: any >=20 > IPR Disclosure: None >=20 > Status: Active >=20 > Notes: None >=20 > -----END FORM----- >=20 > As specified in RFC 7451 the discussion of this request is to take = place on this mailing list. So let's discuss it. >=20 > I have no issue with the extension itself. Given that this request = refers to an existing Internet-Draft document, I believe it would be = more appropriate for the document to include an IANA Considerations = section that includes a request to register the extension if the = document becomes an RFC. My recommendation to IANA would be to hold off = on processing the request until the document is either submitted to and = approved by the IESG or it is published outside the IETF process. >=20 > Would the other designated experts please share the results of your = individual evaluations in this thread. >=20 > Scott >=20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext From nobody Wed Feb 11 17:39:39 2015 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 D8FA91A89F6 for ; Wed, 11 Feb 2015 17:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 MJDU-H5UXehS for ; Wed, 11 Feb 2015 17:39:37 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 685C21A89B5 for ; Wed, 11 Feb 2015 17:39:36 -0800 (PST) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Thu, 12 Feb 2015 02:39:30 +0100 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 02:39:25 +0100 From: Alexander Mayrhofer To: "Hollenbeck, Scott" , "eppext@ietf.org" Thread-Topic: Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Thread-Index: AdBCEn+vvcyzjjByRt6JTgZTR3aSZAEUMAKQ Date: Thu, 12 Feb 2015 01:39:24 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0754674EED8@NICS-EXCH2.sbg.nic.at> References: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: Re: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 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, 12 Feb 2015 01:39:39 -0000 All, > I have no issue with the extension itself. Given that this request refers= to an > existing Internet-Draft document, I believe it would be more appropriate = for > the document to include an IANA Considerations section that includes a > request to register the extension if the document becomes an RFC. My > recommendation to IANA would be to hold off on processing the request > until the document is either submitted to and approved by the IESG or it = is > published outside the IETF process. I do agree with Scott that the registration details should go into the IANA= considerations section of the document, using the template from RFC7451. B= asically, i also agree that the registration should be held off until publi= cation, if the intended goal of the document is publication as an RFC.=20 I understand the document describes one of the candidate extensions that co= uld be adopted as WG items once EPPEXT recharters. My recommendation above = is based on this assumption. However, i'm slightly concerned about the curr= ent level of progress of the rechartering / scope work, and hence i do also= recommend that the author should consider restarting the registration requ= est once the final direction for the publication path of the document is c= lear. Alex From nobody Fri Feb 13 05:13:23 2015 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 10BB91A702E for ; Fri, 13 Feb 2015 05:13:22 -0800 (PST) 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 d6NOyRqhXdpe for ; Fri, 13 Feb 2015 05:13:20 -0800 (PST) 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 24D651A7033 for ; Fri, 13 Feb 2015 05:13:13 -0800 (PST) Received: from Gavins-MacBook-Pro.local (unknown [217.138.20.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 0ECDA9E93; Fri, 13 Feb 2015 13:13:12 +0000 (UTC) Message-ID: <54DDF867.1070705@centralnic.com> Date: Fri, 13 Feb 2015 13:13:11 +0000 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ning Kong , "Hollenbeck, Scott" References: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="18XQPvu9CHrRLfTexjGspQnUF0DoXX6W9" Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 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, 13 Feb 2015 13:13:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --18XQPvu9CHrRLfTexjGspQnUF0DoXX6W9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/02/2015 02:19, Ning Kong wrote: > #2 IMO, the extension of is not necessary. It seems that the ex= tended is a little overused. I think the extension of is e= nough. There has been some discussion of this point on this list; there seemed to be no consensus for using only or only. In the interests of pleasing the most number of people, I chose to support both.= I would be happy to revisit this question again as my personal preference would be to only support one query command. > #3 I=E2=80=99m afraid this extension may increase the risk of Security = and Privacy. The fee information of domain registration is sensitive and = maybe trade secrets for most registrars and registries. Because differen= t registrars would get different price based on their each commercial con= tract. So usually the fee information can only be known by the business p= eople. But if the EPP is extended with the fee function, the sensitive in= formation about fee may be accessed by the technical guys even through th= e log file of EPP system. This is an interesting point. I will think about adding a Security Considerations section to the draft which addresses this concern. G. --=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. --18XQPvu9CHrRLfTexjGspQnUF0DoXX6W9 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) iEYEARECAAYFAlTd+GcACgkQ6H45IPkjtM7VAwCffIJk5rmMi0KYsUhQZhUxsbcy TD0AnA06f6Tijw8ANRzi3tlS2Lnjy1yL =Z2DW -----END PGP SIGNATURE----- --18XQPvu9CHrRLfTexjGspQnUF0DoXX6W9-- From nobody Fri Feb 13 05:37:49 2015 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 5ACE31A70FE for ; Fri, 13 Feb 2015 05:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.561 X-Spam-Level: X-Spam-Status: No, score=0.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01] 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 ILC7cAB_BaD5 for ; Fri, 13 Feb 2015 05:37:41 -0800 (PST) Received: from mail-oi0-f97.google.com (mail-oi0-f97.google.com [209.85.218.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960961A70E2 for ; Fri, 13 Feb 2015 05:37:41 -0800 (PST) Received: by mail-oi0-f97.google.com with SMTP id u20so987795oif.0 for ; Fri, 13 Feb 2015 05:37:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=WTUrDStq4WewXe/xhtS3bsUJRG3sKWpyfjQaT/i3itc=; b=chhurqcfZOj4PcKUzGXhe+6mvEbB4f2vCaCm6LptfZC1Fh3zKYQ8iKXn3Nf8TCOUVp orrA4Y7OFRXdF9nyAFqcFIUmt1FO7e4WjQpK0RHIW7TbJ9ti0FdWyY4012n3H7EBYAFf 0e7ZwdwMTVPffgSBP0z8lwntitOJUbuhxNu2wz9yS5RlRRoRSGteRiw8T+7TDEzzOgF1 kPemSSCfQqUkCPp59Xn8yS5LYbu6sDBlTYk0lil/+kxSZgj92IRwrRwDStOYcBT53WzE yY2skDlGH0/Lpib692tsnym2ut2oNwN2sZvcWs9TjHRXI0Vx68KZ8VHnZo26pz6nMrik 8bVA== X-Gm-Message-State: ALoCoQkWWrY7IkS1jLOV7oIegchQsbNl76WUguLjipOtRx6gtDPXcF3za4c7XXqJR/nm6Z9z5U9M8VHSm4RBfaKEj57AWAlu8w== X-Received: by 10.236.27.72 with SMTP id d48mr8708825yha.60.1423834660975; Fri, 13 Feb 2015 05:37:40 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id x9sm1776023qcq.0.2015.02.13.05.37.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Feb 2015 05:37:40 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t1DDbeDv013418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Feb 2015 08:37:40 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 13 Feb 2015 08:37:39 -0500 From: "Gould, James" To: Ning Kong Thread-Topic: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Thread-Index: AdBCEn+vvcyzjjByRt6JTgZTR3aSZADuIaYAAHxHn4A= Date: Fri, 13 Feb 2015 13:37:38 +0000 Message-ID: <29323ABA-D158-460E-ACBC-514BB48AF830@verisign.com> References: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_29323ABAD158460EACBC514BB48AF830verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "Hollenbeck, Scott" , "eppext@ietf.org" Subject: Re: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 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, 13 Feb 2015 13:37:46 -0000 --_004_29323ABAD158460EACBC514BB48AF830verisigncom_ Content-Type: multipart/alternative; boundary="_000_29323ABAD158460EACBC514BB48AF830verisigncom_" --_000_29323ABAD158460EACBC514BB48AF830verisigncom_ Content-Type: text/plain; charset="GB18030" Content-Transfer-Encoding: quoted-printable Ning, I provide some feedback below to your feedback. =A1=AA JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Feb 10, 2015, at 9:19 PM, Ning Kong > wrote: Hi Scott and all, As one of the designated experts, I read this request and draft. I have som= e comments as follows. #1 The document status is Informational according to the request, but the i= ntended status of draft is Experimental. I believe this draft should be targeted for Standards track based on the am= ount of interest in it by the community. I believe it is passed Experiment= al and it is certainly being looked at by multiple independent parties. Ho= pefully the EPPEXT WG will be re-charted to include this draft. #2 IMO, the extension of is not necessary. It seems that the extend= ed is a little overused. I think the extension of is enough. I believe the draft should stay as is. Since the fee draft is an extension= and not an object mapping, how would you represent the price for a non-exi= sting domain name using an extension of the info command? The extension re= ally could not extend the info response for a non-existing domain name sinc= e RFC 5731 requires the name, roid, and clID element to be returned in the = response. As is, the extension to the check command and response enables a= client to get pricing information for existing and non-existing domain nam= es, and the extension to the info command and response enables a client to = get the pricing information for an existing domain name. #3 I=A1=AFm afraid this extension may increase the risk of Security and Pri= vacy. The fee information of domain registration is sensitive and maybe tra= de secrets for most registrars and registries. Because different registrar= s would get different price based on their each commercial contract. So usu= ally the fee information can only be known by the business people. But if t= he EPP is extended with the fee function, the sensitive information about f= ee may be accessed by the technical guys even through the log file of EPP s= ystem. I don=A1=AFt agree with this feedback. The client system needs to know the= fee to ensure that the expected fee will or is going to be charged by the = server. I don=A1=AFt believe this can only be known by a client business p= erson. The extension is optional and the business person can decide to req= uire the client system to support the fee extension or not. The security p= ractices of the client for disclosure of the fee information is up to the c= lient to define and enforce, and really does not play into the protocol bet= ween the client and the server. Regards, Ning =D4=DA 2015=C4=EA2=D4=C26=C8=D5=A3=AC=CF=C2=CE=E79:40=A3=ACHollenbeck, Scot= t > =D0=B4=B5=C0= =A3=BA IANA has received a request to register an EPP extension titled "Registry F= ee Extension for the Extensible Provisioning Protocol (EPP)". Per RFC 7451 = they have requested designated expert review of the request. The list of de= signated experts appointed by the IESG can be found IANA's registry web pag= e: http://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#epp-ext= ensions-1 This is the form received by IANA: -----BEGIN FORM----- Name of Extension: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Document Status: Informational Reference: http://tools.ietf.org/html/draft-brown-epp-fees Registrant Name and Email Address: Gavin Brown, TLDs: any IPR Disclosure: None Status: Active Notes: None -----END FORM----- As specified in RFC 7451 the discussion of this request is to take place on= this mailing list. So let's discuss it. I have no issue with the extension itself. Given that this request refers t= o an existing Internet-Draft document, I believe it would be more appropria= te for the document to include an IANA Considerations section that includes= a request to register the extension if the document becomes an RFC. My rec= ommendation to IANA would be to hold off on processing the request until th= e document is either submitted to and approved by the IESG or it is publish= ed outside the IETF process. Would the other designated experts please share the results of your individ= ual evaluations in this thread. Scott _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_29323ABAD158460EACBC514BB48AF830verisigncom_ Content-Type: text/html; charset="GB18030" Content-ID: <006901CE65B845429C86074039C835F8@verisign.com> Content-Transfer-Encoding: quoted-printable Ning, 

I provide some feedback below to your feedback.

=A1=AA

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

On Feb 10, 2015, at 9:19 PM, Ning Kong <nkong@cnnic.cn> wrote:


Hi Scott and all,

As one of the designated experts, I read this request and draft. I have som= e comments as follows.

#1 The document status is Informational according to the request, but the i= ntended status of draft is Experimental.

I believe this draft should be targeted for Standards track based on t= he amount of interest in it by the community.  I believe it is passed = Experimental and it is certainly being looked at by multiple independent pa= rties.  Hopefully the EPPEXT WG will be re-charted to include this draft.  


#2 IMO, the extension of <check> is not necessary. It seems that the = extended <check> is a little overused. I think the extension of <i= nfo> is enough.


I believe the draft should stay as is.  Since the fee draft is an= extension and not an object mapping, how would you represent the price for= a non-existing domain name using an extension of the info command?  T= he extension really could not extend the info response for a non-existing domain name since RFC 5731 requires the name, = roid, and clID element to be returned in the response.  As is, the ext= ension to the check command and response enables a client to get pricing in= formation for existing and non-existing domain names, and the extension to the info command and response enables a= client to get the pricing information for an existing domain name.  <= /div>
#3 I=A1=AFm afraid this extension may increase th= e risk of Security and Privacy. The fee information of domain registration = is sensitive and maybe trade secrets for most registrars and registries. &n= bsp;Because different registrars would get different price based on their each commercial contract. So usually the fee informat= ion can only be known by the business people. But if the EPP is extended wi= th the fee function, the sensitive information about fee may be accessed by= the technical guys even through the log file of EPP system.


I don=A1=AFt agree with this feedback.  The client system needs t= o know the fee to ensure that the expected fee will or is going to be charg= ed by the server.  I don=A1=AFt believe this can only be known by a cl= ient business person.  The extension is optional and the business person can decide to require the client system to support the= fee extension or not.  The security practices of the client for discl= osure of the fee information is up to the client to define and enforce, and= really does not play into the protocol between the client and the server.  


Regards,
Ning


=D4=DA 2015=C4=EA2=D4=C26=C8=D5=A3=AC=CF=C2=CE=E7= 9:40=A3=ACHollenbeck, Scott <shollenbeck@verisign.com> =D0=B4=B5=C0=A3=BA

IANA has received a request to register an EPP extension titled "Regis= try Fee Extension for the Extensible Provisioning Protocol (EPP)". Per= RFC 7451 they have requested designated expert review of the request. The = list of designated experts appointed by the IESG can be found IANA's registry web page:

http://www.iana.org/assignments/epp-extensions/epp-ex= tensions.xhtml#epp-extensions-1

This is the form received by IANA:

-----BEGIN FORM-----
Name of Extension:
Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

Document Status: Informational

Reference: http://tools.ietf.org/html/draft-brown-epp-fees

Registrant Name and Email Address:
Gavin Brown, <gavin.brown@centralnic.com>

TLDs: any

IPR Disclosure: None

Status: Active

Notes: None

-----END FORM-----

As specified in RFC 7451 the discussion of this request is to take place on= this mailing list. So let's discuss it.

I have no issue with the extension itself. Given that this request refers t= o an existing Internet-Draft document, I believe it would be more appropria= te for the document to include an IANA Considerations section that includes= a request to register the extension if the document becomes an RFC. My recommendation to IANA would be to hold= off on processing the request until the document is either submitted to an= d approved by the IESG or it is published outside the IETF process.

Would the other designated experts please share the results of your individ= ual evaluations in this thread.

Scott

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


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

--_000_29323ABAD158460EACBC514BB48AF830verisigncom_-- --_004_29323ABAD158460EACBC514BB48AF830verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 13 Feb 2015 13:37:38 GMT"; modification-date="Fri, 13 Feb 2015 13:37:38 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_29323ABAD158460EACBC514BB48AF830verisigncom_-- From nobody Tue Feb 17 03:48:00 2015 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 7B2F51A8791 for ; Tue, 17 Feb 2015 03:47:59 -0800 (PST) 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 no6Qh1dqfiZ8 for ; Tue, 17 Feb 2015 03:47:57 -0800 (PST) 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 36B761A87AD for ; Tue, 17 Feb 2015 03:47:56 -0800 (PST) Received: from Gavins-MacBook-Pro.local (unknown [217.138.20.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id B9860A21B for ; Tue, 17 Feb 2015 11:47:54 +0000 (UTC) Message-ID: <54E32A6A.2050905@centralnic.com> Date: Tue, 17 Feb 2015 11:47:54 +0000 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: eppext@ietf.org References: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> In-Reply-To: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> OpenPGP: id=F923B4CE X-Forwarded-Message-Id: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jMowEdmdQDmUoS0mVVuFe6fTEEKlHLADs" Archived-At: Subject: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.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, 17 Feb 2015 11:47:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jMowEdmdQDmUoS0mVVuFe6fTEEKlHLADs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've just submitted a new version of the fee extension draft for your review. 9.4. Changes from 03 to 04 1. Changed Intended Status to Standards Track. 2. As per suggestion from Michael Bauland, the element is no longer included in and responses for "restore" commands. It's still mandatory for all other commands. 3. Added summary of the attributes for the element. 4. Clarified that the "refundable" and "grace-period" attributes of the fee elements are dependant on each other and cannot appear on their own. 5. Removed the option of returning a 1001 response when the fee is incorrect. 6. Forbidden the inclusion of extension elements in transform responses if no fee/credit has been assessed. 7. Made the element optional in transform commands. 8. Amended XML Namespace section of IANA Considerations, added EPP Extension Registry section. 10. TODO (Note to RFC Editor: remove this section before publication as an RFC.) 1. Make the extension object-agnostic so it can be used with other objects, not just vanilla domains. 2. Change the command so that availability data is not returned. -------- Forwarded Message -------- Subject: New Version Notification for draft-brown-epp-fees-04.txt Date: Tue, 17 Feb 2015 02:16:09 -0800 From: internet-drafts@ietf.org To: Gavin Brown A new version of I-D, draft-brown-epp-fees-04.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-brown-epp-fees Revision: 04 Title: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Document date: 2015-02-17 Group: Individual Submission Pages: 36 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-0= 4 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. --jMowEdmdQDmUoS0mVVuFe6fTEEKlHLADs 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) iEYEARECAAYFAlTjKmoACgkQ6H45IPkjtM43/wCdHOZod/4wAZ1e/h0ePfDy47pw uMAAn1kOt2CIuoq7kWw4P8kkYkSlWep3 =sppT -----END PGP SIGNATURE----- --jMowEdmdQDmUoS0mVVuFe6fTEEKlHLADs-- From nobody Tue Feb 17 11:37:44 2015 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 4C55E1A90A9 for ; Tue, 17 Feb 2015 11:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.516 X-Spam-Level: X-Spam-Status: No, score=0.516 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 mypn2UqlfJyP for ; Tue, 17 Feb 2015 11:37:40 -0800 (PST) Received: from mail-oi0-f99.google.com (mail-oi0-f99.google.com [209.85.218.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594401A90A0 for ; Tue, 17 Feb 2015 11:37:40 -0800 (PST) Received: by mail-oi0-f99.google.com with SMTP id z81so3087137oif.2 for ; Tue, 17 Feb 2015 11:37:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=2nJr4te6GplFetx8nHyCM+kiujq3VDqj4hsaZKw/a9g=; b=iDYM7Q9xw4oh9/j3iBVq99kj6hm+QgexOntMf2S7ti+VulGqCnJ/hBbU+YRAIiYY9J sTKI/c6WEXas7v+oUVYxBHv9SbOOOfgDEY/Fka5R/HKqt/FY2fVzshf8osbNUSB7cgU+ 32XNgf6bRFDfr8k9apriFlQrKWGeOQZe1N7JBPSxK/h30Iz69pN1lqHEJBZ0x4CPXI3r hhk7VBbAvEwfYlRM/I2OESGGx7kp1sS8KfP4lI590MJEOb+na3fL/usv0aNB99wOQqM9 V1NPu2R+Jc83f++ccB009jpY+HJX8e8s0n7InPhUksgQdWyKwgBSXZys1gJ6AqOpjiZ1 yciQ== X-Gm-Message-State: ALoCoQkS3YWYeWvvU08EqzpvuVOR01UplE9PkQNQm5MlHOLYbAkXeTy47dIj9dU9+RCxL6GGrvQwWeQ2QNJNV6QooYb+uwcUhQ== X-Received: by 10.229.190.6 with SMTP id dg6mr174109qcb.16.1424201859568; Tue, 17 Feb 2015 11:37:39 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id t2sm2016148qcz.2.2015.02.17.11.37.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Feb 2015 11:37:39 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t1HJbc8Q003245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 14:37:39 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 17 Feb 2015 14:37:38 -0500 From: "Gould, James" To: Gavin Brown Thread-Topic: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.txt Thread-Index: AQHQSqeZT1s/3cxmEUKTbmq4h/W6y5z1kOYA Date: Tue, 17 Feb 2015 19:37:37 +0000 Message-ID: <248414D5-0DE0-4BEB-8B0B-E327619058A3@verisign.com> References: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> <54E32A6A.2050905@centralnic.com> In-Reply-To: <54E32A6A.2050905@centralnic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_248414D50DE04BEB8B0BE327619058A3verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.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, 17 Feb 2015 19:37:43 -0000 --_004_248414D50DE04BEB8B0BE327619058A3verisigncom_ Content-Type: multipart/alternative; boundary="_000_248414D50DE04BEB8B0BE327619058A3verisigncom_" --_000_248414D50DE04BEB8B0BE327619058A3verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gavin, Thanks for posting the 04 update to the draft. In reviewing the changes, I= have the following feedback: 1. I believe you can remove the sentence =93The element MUS= T be present in and commands and responses=94, since it conf= licts with the start of the paragraph =93The element is OPTION= AL in and commands=94. The is OPTIONAL but has= a default value of 1 year if omitted. 2. The infDataType type supports an OPTIONAL list of elemen= ts, but section 5.1.2 does not include a description of it. 3. The domainCDType type supports an OPTIONAL list of eleme= nt, but section 5.1.1. does not include a description of it. 4. The transfer response as defined in section 5.1.3 does not define the= added OPTIONAL elements. The use case for inclusion of a element covers providing any applicable credits to the losing cli= ent of a transfer. For example, an auto renew happened, then a transfer re= quest is executed that applies a credit to the losing client for the auto r= enew. Based on this use case, the element should OPTIONAL, so mi= nOccurs=3D0 should be defined. The same holds true for the transfer respon= se in section 5.2.4. Does it make sense to include the same i= nformation for the losing client for a transfer op=3D=93approve=94? 5. Support for the OPTIONAL list of elements in the create,= renew, and update responses is supported in the XML schema, but is not des= cribed in section 5.2.1, section 5.2.3, and section 5.2.5, respectively. 6. The is required for the element in the X= ML schema, but is defined as OPTIONAL in section 5.2.2. I=92m assuming tha= t the XML schema is correct. 7. Since the response to the transform commands (create, renew, update) = can include both fees and credits, the text =93If no fee or credit has been= assessed by the server for this transaction, a element OPTIONAL in item #4 above i= s the only item that would require a change to the XML schema. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Feb 17, 2015, at 6:47 AM, Gavin Brown > wrote: I've just submitted a new version of the fee extension draft for your review. 9.4. Changes from 03 to 04 1. Changed Intended Status to Standards Track. 2. As per suggestion from Michael Bauland, the element is no longer included in and responses for "restore" commands. It's still mandatory for all other commands. 3. Added summary of the attributes for the element. 4. Clarified that the "refundable" and "grace-period" attributes of the fee elements are dependant on each other and cannot appear on their own. 5. Removed the option of returning a 1001 response when the fee is incorrect. 6. Forbidden the inclusion of extension elements in transform responses if no fee/credit has been assessed. 7. Made the element optional in transform commands. 8. Amended XML Namespace section of IANA Considerations, added EPP Extension Registry section. 10. TODO (Note to RFC Editor: remove this section before publication as an RFC.) 1. Make the extension object-agnostic so it can be used with other objects, not just vanilla domains. 2. Change the command so that availability data is not returned. -------- Forwarded Message -------- Subject: New Version Notification for draft-brown-epp-fees-04.txt Date: Tue, 17 Feb 2015 02:16:09 -0800 From: internet-drafts@ietf.org To: Gavin Brown > A new version of I-D, draft-brown-epp-fees-04.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-brown-epp-fees Revision: 04 Title: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Document date: 2015-02-17 Group: Individual Submission Pages: 36 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-04 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- 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. _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_248414D50DE04BEB8B0BE327619058A3verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5B9D2AD7725D7644AC8D1D05CC2EA705@verisign.com> Content-Transfer-Encoding: quoted-printable Gavin,

Thanks for posting the 04 update to the draft.  In reviewing the = changes, I have the following feedback:

  1. I believe you can remove the sentence =93The <fee:period> element= MUST be present in <check> and <info> commands and responses= =94, since it conflicts with the start of the paragraph =93The <fee:peri= od> element is OPTIONAL in <check> and <info> commands=94. &= nbsp;The <fee:period> is OPTIONAL but has a default value of 1 year if omitte= d. 
  2. The infDataType type supports an OPTIONAL list of <fee:= credit> elements, but section 5.1.2 does not include a description of it= .   
  3. The domainCDType type supports an OPTIONAL list of &= lt;fee:credit> element, but section 5.1.1. does not include a descriptio= n of it.
  4. The transfer response as defined in section 5.1.3 does not= define the added OPTIONAL <fee:credit> elements.  The use case = for inclusion of a <fee:credit> element covers providing any applicab= le credits to the losing client of a transfer.  For example, an auto renew happened, then a transfer request is executed that applies a cr= edit to the losing client for the auto renew.  Based on this use case,= the <fee:fee> element should OPTIONAL, so minOccurs=3D0 should be de= fined.  The same holds true for the transfer response in section 5.2.4.  Does it make sense to include the same &l= t;fee:credit> information for the losing client for a transfer op=3D=93a= pprove=94?  
  5. Support for the OPTIONAL list of <fee:credit&g= t; elements in the create, renew, and update responses is supported in the = XML schema, but is not described in section 5.2.1, section 5.2.3, and secti= on 5.2.5, respectively.  
  6. The <fee:currency> is required= for the <fee:delData> element in the XML schema, but is defined as O= PTIONAL in section 5.2.2.  I=92m assuming that the XML schema is corre= ct. 
  7. Since the response to the transform commands (create, ren= ew, update) can include both fees and credits, the text =93If no fee or credit has been assessed by the server for this transaction,= a <fee:XXXData) element MUST NOT be included in the response=94 should = be updated.   

To note, I believe making the <fee:fee> element OPTIONAL in item= #4 above is the only item that would require a change to the XML schema. &= nbsp;

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

On Feb 17, 2015, at 6:47 AM, Gavin Brown <gavin.brown@centralnic.com> wrote:

I've just submitted a new version of the fee exte= nsion draft for your
review.

9.4. Changes from 03 to 04

  1.  Changed Intended Status to Standards Track.

  2.  As per suggestion from Michael Bauland, the <fee:pe= riod> element
      is no longer included in <check> = and <info> responses for
      "restore" commands.  It'= s still mandatory for all other commands.

  3.  Added summary of the attributes for the <fee:fee>= ; element.

  4.  Clarified that the "refundable" and "gr= ace-period" attributes of
      the <fee> fee elements are depend= ant on each other and cannot
      appear on their own.

  5.  Removed the option of returning a 1001 response when t= he fee is
      incorrect.

  6.  Forbidden the inclusion of extension elements in trans= form
      responses if no fee/credit has been ass= essed.

  7.  Made the <fee:currency> element optional in tran= sform commands.

  8.  Amended XML Namespace section of IANA Considerations, = added EPP
      Extension Registry section.

10. TODO


  (Note to RFC Editor: remove this section before publication as = an
  RFC.)

  1.  Make the extension object-agnostic so it can be used w= ith other
      objects, not just vanilla domains.

  2.  Change the <check> command so that availability = data is not
      returned.

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: internet-drafts@ietf.org<= /a>
To: Gavin Brown <gavin.bro= wn@centralnic.com>

A new version of I-D, draft-brown-epp-fees-04.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name: draft-brown-epp-= fees
Revision: 0= 4
Title: Registry Fee Ex= tension for the Extensible Provisioning Protocol
(EPP)
Document date: 2015-02-17
Group: Individual Subm= ission
Pages: 36
URL:
http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt
Status:         https://datatracker.ietf.or= g/doc/draft-brown-epp-fees/
Htmlized:       http://tools.ietf.org/html/draft-brown-ep= p-fees-04
Diff:           http://www.= ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-04

Abstract:
  This document describes an Extensible Provisioning Protocol (EP= P)
  extension mapping for registry fees.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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



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

--_000_248414D50DE04BEB8B0BE327619058A3verisigncom_-- --_004_248414D50DE04BEB8B0BE327619058A3verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 17 Feb 2015 19:37:37 GMT"; modification-date="Tue, 17 Feb 2015 19:37:37 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_248414D50DE04BEB8B0BE327619058A3verisigncom_-- From nobody Tue Feb 17 22:02:08 2015 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 183541A902E for ; Tue, 17 Feb 2015 22:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 ot87-WKH7GqJ for ; Tue, 17 Feb 2015 22:02:04 -0800 (PST) Received: from cpanel.faults.co.za (ns1.faults.co.za [41.72.133.173]) (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 A96E01A8FD6 for ; Tue, 17 Feb 2015 22:02:03 -0800 (PST) Received: from mail-we0-f171.google.com ([74.125.82.171]:37001) by cpanel.faults.co.za with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YNxhn-0004VU-Sl for eppext@ietf.org; Wed, 18 Feb 2015 08:01:58 +0200 Received: by wesw55 with SMTP id w55so2580156wes.4 for ; Tue, 17 Feb 2015 22:01:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.58.209 with SMTP id t17mr5433089wjq.156.1424239310833; Tue, 17 Feb 2015 22:01:50 -0800 (PST) Received: by 10.27.224.15 with HTTP; Tue, 17 Feb 2015 22:01:50 -0800 (PST) In-Reply-To: <54E32A6A.2050905@centralnic.com> References: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> <54E32A6A.2050905@centralnic.com> Date: Wed, 18 Feb 2015 08:01:50 +0200 Message-ID: From: Ed Pascoe To: Gavin Brown Content-Type: multipart/alternative; boundary=047d7ba96ec432aebc050f568e60 X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel.faults.co.za X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - pascoe.co.za X-Get-Message-Sender-Via: cpanel.faults.co.za: authenticated_id: ed@pascoe.co.za X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: eppext@ietf.org Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.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 Feb 2015 06:02:07 -0000 --047d7ba96ec432aebc050f568e60 Content-Type: text/plain; charset=UTF-8 While I think this extension is well written and valuable I do have to question if a standards track is appropriate? The competing version of this is the UnitedTLD "Price Categories Guide" http://rightside.co/fileadmin/downloads/policies/Rightside_Price_Categories.pdf which has not been formally published. However its in active use by Rightside, Donuts and Domain Name Services (that I know of) meaning that around 190 new TLDs are using it or about to do so. So the question is where do we go to from here? Do we try and get Rightside to have the original author publish it to the EPP extension registry or do we pretend it doesn't exist and ignore the significant percentage of new TLDs using it? On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown wrote: > I've just submitted a new version of the fee extension draft for your > review. > > 9.4. Changes from 03 to 04 > > 1. Changed Intended Status to Standards Track. > > 2. As per suggestion from Michael Bauland, the element > is no longer included in and responses for > "restore" commands. It's still mandatory for all other commands. > > 3. Added summary of the attributes for the element. > > 4. Clarified that the "refundable" and "grace-period" attributes of > the fee elements are dependant on each other and cannot > appear on their own. > > 5. Removed the option of returning a 1001 response when the fee is > incorrect. > > 6. Forbidden the inclusion of extension elements in transform > responses if no fee/credit has been assessed. > > 7. Made the element optional in transform commands. > > 8. Amended XML Namespace section of IANA Considerations, added EPP > Extension Registry section. > > 10. TODO > > > (Note to RFC Editor: remove this section before publication as an > RFC.) > > 1. Make the extension object-agnostic so it can be used with other > objects, not just vanilla domains. > > 2. Change the command so that availability data is not > returned. > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-brown-epp-fees-04.txt > Date: Tue, 17 Feb 2015 02:16:09 -0800 > From: internet-drafts@ietf.org > To: Gavin Brown > > A new version of I-D, draft-brown-epp-fees-04.txt > has been successfully submitted by Gavin Brown and posted to the > IETF repository. > > Name: draft-brown-epp-fees > Revision: 04 > Title: Registry Fee Extension for the Extensible Provisioning > Protocol > (EPP) > Document date: 2015-02-17 > Group: Individual Submission > Pages: 36 > URL: > http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt > Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ > Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-04 > > 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 > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > -- > 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. > > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > > --047d7ba96ec432aebc050f568e60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While I think this extension is well written and valuable = I do have to question if a standards track is appropriate?

The competing version of this is the UnitedTLD "Price Categories Gu= ide"=C2=A0http://rightside.co/fileadmin/downloads/pol= icies/Rightside_Price_Categories.pdf which has not been formally publis= hed. However its in active use by Rightside, Donuts and Domain Name Service= s (that I know of) meaning that around 190 new TLDs are using it or about t= o do so.

So the question is where do we go to from= here? Do we try and get Rightside to have the original author publish it t= o the EPP extension registry or do we pretend it doesn't exist and igno= re the significant percentage of new TLDs using it?


On Tue, Feb 17= , 2015 at 1:47 PM, Gavin Brown <gavin.brown@centralnic.com>= ; wrote:
I've just submitted a= new version of the fee extension draft for your
review.

9.4. Changes from 03 to 04

=C2=A0 =C2=A01.=C2=A0 Changed Intended Status to Standards Track.

=C2=A0 =C2=A02.=C2=A0 As per suggestion from Michael Bauland, the <fee:p= eriod> element
=C2=A0 =C2=A0 =C2=A0 =C2=A0is no longer included in <check> and <i= nfo> responses for
=C2=A0 =C2=A0 =C2=A0 =C2=A0"restore" commands.=C2=A0 It's sti= ll mandatory for all other commands.

=C2=A0 =C2=A03.=C2=A0 Added summary of the attributes for the <fee:fee&g= t; element.

=C2=A0 =C2=A04.=C2=A0 Clarified that the "refundable" and "g= race-period" attributes of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the <fee> fee elements are dependant on ea= ch other and cannot
=C2=A0 =C2=A0 =C2=A0 =C2=A0appear on their own.

=C2=A0 =C2=A05.=C2=A0 Removed the option of returning a 1001 response when = the fee is
=C2=A0 =C2=A0 =C2=A0 =C2=A0incorrect.

=C2=A0 =C2=A06.=C2=A0 Forbidden the inclusion of extension elements in tran= sform
=C2=A0 =C2=A0 =C2=A0 =C2=A0responses if no fee/credit has been assessed.
=C2=A0 =C2=A07.=C2=A0 Made the <fee:currency> element optional in tra= nsform commands.

=C2=A0 =C2=A08.=C2=A0 Amended XML Namespace section of IANA Considerations,= added EPP
=C2=A0 =C2=A0 =C2=A0 =C2=A0Extension Registry section.

10. TODO


=C2=A0 =C2=A0(Note to RFC Editor: remove this section before publication as= an
=C2=A0 =C2=A0RFC.)

=C2=A0 =C2=A01.=C2=A0 Make the extension object-agnostic so it can be used = with other
=C2=A0 =C2=A0 =C2=A0 =C2=A0objects, not just vanilla domains.

=C2=A0 =C2=A02.=C2=A0 Change the <check> command so that availability= data is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0returned.

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: internet-drafts@ietf.org<= /a>
To: Gavin Brown <gavin.bro= wn@centralnic.com>

A new version of I-D, draft-brown-epp-fees-04.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-brown-epp-fees
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Registry Fee Extension for the Ext= ensible Provisioning Protocol
(EPP)
Document date:=C2=A0 2015-02-17
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 36
URL:
http://www.ietf.org/internet-drafts/draft-brown-epp-fees= -04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf= .org/doc/draft-brown-epp-fees/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/draft-= brown-epp-fees-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf= .org/rfcdiff?url2=3Ddraft-brown-epp-fees-04

Abstract:
=C2=A0 =C2=A0This document describes an Extensible Provisioning Protocol (E= PP)
=C2=A0 =C2=A0extension mapping for registry fees.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
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.centr= alnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.




_______________________________________________
EppExt mailing list
EppExt@ietf.org
= https://www.ietf.org/mailman/listinfo/eppext


--047d7ba96ec432aebc050f568e60-- From nobody Wed Feb 18 01:04:38 2015 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 9E4E71A6FFF for ; Wed, 18 Feb 2015 01:04:36 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9B_Fa5G1fmFr for ; Wed, 18 Feb 2015 01:04:33 -0800 (PST) Received: from smtp107.iad3a.emailsrvr.com (smtp107.iad3a.emailsrvr.com [173.203.187.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9691A00A9 for ; Wed, 18 Feb 2015 01:04:33 -0800 (PST) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6FA3D28042F for ; Wed, 18 Feb 2015 04:04:32 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp14.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6C525280487 for ; Wed, 18 Feb 2015 04:04:32 -0500 (EST) Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id B6F9C28042F for ; Wed, 18 Feb 2015 04:04:31 -0500 (EST) X-Sender-Id: m4bh@comlaude.com Received: from [192.168.1.10] (p578E6A76.dip0.t-ipconnect.de [87.142.106.118]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Wed, 18 Feb 2015 09:04:32 GMT Message-ID: <54E4559E.4050109@comlaude.com> Date: Wed, 18 Feb 2015 10:04:30 +0100 From: Michael Holloway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: eppext@ietf.org References: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> <54E32A6A.2050905@centralnic.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010108050909040809020200" Archived-At: Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.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 Feb 2015 09:04:36 -0000 This is a multi-part message in MIME format. --------------010108050909040809020200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Ed, Good point. The UnitedTLD is also used ZACR, while this extension is in use by CentralNIC, GMO, Charleston, Minds and Machines - albeit they are using varying versions. Ignoring the fact that the big 3 all have their their own alternatives (and 1 or 2 more), these two extensions already have a large coverage. UnitedTLD's extension is much simpler while this one is much more complex (due to registry input to Gavin indicating they want the flexibility). I do not believe that any registry that has already implemented one or the other will switch, which means both of the extensions will continue to be used even if one were to take the lead. So is there an argument to propose two standards for the same purpose or do we back the one that pushes in the interest of having a standard? Two standards are better than none which results in several alternative custom extensions, so I would back either or both if they are going down standards track. Cheers, Michael * Michael Holloway Senior Systems Administrator**| Com Laude* E: michael.holloway@comlaude.com On 02/18/2015 07:01 AM, Ed Pascoe wrote: > While I think this extension is well written and valuable I do have to > question if a standards track is appropriate? > > The competing version of this is the UnitedTLD "Price Categories > Guide" > http://rightside.co/fileadmin/downloads/policies/Rightside_Price_Categories.pdf > which has not been formally published. However its in active use by > Rightside, Donuts and Domain Name Services (that I know of) meaning > that around 190 new TLDs are using it or about to do so. > > So the question is where do we go to from here? Do we try and get > Rightside to have the original author publish it to the EPP extension > registry or do we pretend it doesn't exist and ignore the significant > percentage of new TLDs using it? > > > On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown > > wrote: > > I've just submitted a new version of the fee extension draft for your > review. > > 9.4. Changes from 03 to 04 > > 1. Changed Intended Status to Standards Track. > > 2. As per suggestion from Michael Bauland, the > element > is no longer included in and responses for > "restore" commands. It's still mandatory for all other > commands. > > 3. Added summary of the attributes for the element. > > 4. Clarified that the "refundable" and "grace-period" > attributes of > the fee elements are dependant on each other and cannot > appear on their own. > > 5. Removed the option of returning a 1001 response when the fee is > incorrect. > > 6. Forbidden the inclusion of extension elements in transform > responses if no fee/credit has been assessed. > > 7. Made the element optional in transform commands. > > 8. Amended XML Namespace section of IANA Considerations, added EPP > Extension Registry section. > > 10. TODO > > > (Note to RFC Editor: remove this section before publication as an > RFC.) > > 1. Make the extension object-agnostic so it can be used with other > objects, not just vanilla domains. > > 2. Change the command so that availability data is not > returned. > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-brown-epp-fees-04.txt > Date: Tue, 17 Feb 2015 02:16:09 -0800 > From: internet-drafts@ietf.org > To: Gavin Brown > > > A new version of I-D, draft-brown-epp-fees-04.txt > has been successfully submitted by Gavin Brown and posted to the > IETF repository. > > Name: draft-brown-epp-fees > Revision: 04 > Title: Registry Fee Extension for the Extensible > Provisioning Protocol > (EPP) > Document date: 2015-02-17 > Group: Individual Submission > Pages: 36 > URL: > http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt > Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ > Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-04 > > 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 > submission > until the htmlized version and diff are available at > tools.ietf.org . > > The IETF Secretariat > > > -- > 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. > > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext --------------010108050909040809020200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Ed, Good point.

The UnitedTLD is also used ZACR, while this extension is in use by CentralNIC, GMO, Charleston, Minds and Machines - albeit they are using varying versions. Ignoring the fact that the big 3 all have their their own alternatives (and 1 or 2 more), these two extensions already have a large coverage. UnitedTLD's extension is much simpler while this one is much more complex (due to registry input to Gavin indicating they want the flexibility).

I do not believe that any registry that has already implemented one or the other will switch, which means both of the extensions will continue to be used even if one were to take the lead.

So is there an argument to propose two standards for the same purpose or do we back the one that pushes in the interest of having a standard? Two standards are better than none which results in several alternative custom extensions, so I would back either or both if they are going down standards track.

Cheers,
Michael



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com




On 02/18/2015 07:01 AM, Ed Pascoe wrote:
While I think this extension is well written and valuable I do have to question if a standards track is appropriate?

The competing version of this is the UnitedTLD "Price Categories Guide" http://rightside.co/fileadmin/downloads/policies/Rightside_Price_Categories.pdf which has not been formally published. However its in active use by Rightside, Donuts and Domain Name Services (that I know of) meaning that around 190 new TLDs are using it or about to do so.

So the question is where do we go to from here? Do we try and get Rightside to have the original author publish it to the EPP extension registry or do we pretend it doesn't exist and ignore the significant percentage of new TLDs using it?


On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown <gavin.brown@centralnic.com> wrote:
I've just submitted a new version of the fee extension draft for your
review.

9.4. Changes from 03 to 04

   1.  Changed Intended Status to Standards Track.

   2.  As per suggestion from Michael Bauland, the <fee:period> element
       is no longer included in <check> and <info> responses for
       "restore" commands.  It's still mandatory for all other commands.

   3.  Added summary of the attributes for the <fee:fee> element.

   4.  Clarified that the "refundable" and "grace-period" attributes of
       the <fee> fee elements are dependant on each other and cannot
       appear on their own.

   5.  Removed the option of returning a 1001 response when the fee is
       incorrect.

   6.  Forbidden the inclusion of extension elements in transform
       responses if no fee/credit has been assessed.

   7.  Made the <fee:currency> element optional in transform commands.

   8.  Amended XML Namespace section of IANA Considerations, added EPP
       Extension Registry section.

10. TODO


   (Note to RFC Editor: remove this section before publication as an
   RFC.)

   1.  Make the extension object-agnostic so it can be used with other
       objects, not just vanilla domains.

   2.  Change the <check> command so that availability data is not
       returned.

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: internet-drafts@ietf.org
To: Gavin Brown <gavin.brown@centralnic.com>

A new version of I-D, draft-brown-epp-fees-04.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:           draft-brown-epp-fees
Revision:       04
Title:          Registry Fee Extension for the Extensible Provisioning Protocol
(EPP)
Document date:  2015-02-17
Group:          Individual Submission
Pages:          36
URL:
http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt
Status:         https://datatracker.ietf.org/doc/draft-brown-epp-fees/
Htmlized:       http://tools.ietf.org/html/draft-brown-epp-fees-04
Diff:           http://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-04

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 submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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




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




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


--------------010108050909040809020200-- From nobody Wed Feb 18 04:09:42 2015 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 F40DE1A8547 for ; Wed, 18 Feb 2015 04:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 KO6Kova31vfI for ; Wed, 18 Feb 2015 04:09:39 -0800 (PST) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8751A876E for ; Wed, 18 Feb 2015 04:09:38 -0800 (PST) Received: by mail-qg0-f97.google.com with SMTP id h3so42306qgf.0 for ; Wed, 18 Feb 2015 04:09:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=MWt+cjMA3wKJqrfLp9Sok7Y5xGQz3umFMCdk4rT5SFg=; b=gpJI394dXtOI9lJVZURn/ksMD38T6K1LevU5sXuOay2Afx0Tz1VN0aiWtRJ9PAv6Qm bmsn1+bAs07CL7qOWS2iN3vO5flwIV2UrAqDL1dqaLj0IpU49OPtt/gYlk3oNxSYS1y5 yldSyiDetz2fOeyc9Uxm5yNc7htuV7a0ULF9TOQyS0PzNHRNDLkYyD3KJQL2LbE/eJ++ 9C0JPwcBDNucF7EpB3/GSfUwrQQPme+mcDXK5iWRfP/aUx/h9RF/Iit9T96IHhCSLX41 1ogyB+URVWlQpNcR8X0mBLOaTO8h3H1nixRnib5zxVBGylvpMwaOfd2uKAxkyguYQbVG bDRA== X-Gm-Message-State: ALoCoQkO4SwcIOWJNrMfxETEq9v7Ecpu8g1dC5ZQKRAITTyXCL3Q/TRx0siagk27BsfRbFvq+SHhEfZa1rOcpYAdG8qEIJaFYw== X-Received: by 10.140.145.13 with SMTP id 13mr1992299qhr.104.1424261377624; Wed, 18 Feb 2015 04:09:37 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id j6sm5306281qcm.4.2015.02.18.04.09.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 18 Feb 2015 04:09:37 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t1IC9Zcl018760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2015 07:09:36 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 18 Feb 2015 07:09:35 -0500 From: "Hollenbeck, Scott" To: Ed Pascoe , Gavin Brown Thread-Topic: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.txt Thread-Index: AQHQS0B0vFiNGWanc0+BWUQlUh5Sepz2TWCA Date: Wed, 18 Feb 2015 12:09:34 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F490A7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> <54E32A6A.2050905@centralnic.com> 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_831693C2CDA2E849A7D7A712B24E257F49F490A7BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.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 Feb 2015 12:09:41 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F49F490A7BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBFcHBFeHQgW21haWx0bzplcHBleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEVkIFBhc2NvZQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxOCwgMjAxNSAxOjAyIEFN DQpUbzogR2F2aW4gQnJvd24NCkNjOiBlcHBleHRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZXBw ZXh0XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJvd24tZXBwLWZl ZXMtMDQudHh0DQoNCldoaWxlIEkgdGhpbmsgdGhpcyBleHRlbnNpb24gaXMgd2VsbCB3cml0dGVu IGFuZCB2YWx1YWJsZSBJIGRvIGhhdmUgdG8gcXVlc3Rpb24gaWYgYSBzdGFuZGFyZHMgdHJhY2sg aXMgYXBwcm9wcmlhdGU/DQoNClRoZSBjb21wZXRpbmcgdmVyc2lvbiBvZiB0aGlzIGlzIHRoZSBV bml0ZWRUTEQgIlByaWNlIENhdGVnb3JpZXMgR3VpZGUiIGh0dHA6Ly9yaWdodHNpZGUuY28vZmls ZWFkbWluL2Rvd25sb2Fkcy9wb2xpY2llcy9SaWdodHNpZGVfUHJpY2VfQ2F0ZWdvcmllcy5wZGYg d2hpY2ggaGFzIG5vdCBiZWVuIGZvcm1hbGx5IHB1Ymxpc2hlZC4gSG93ZXZlciBpdHMgaW4gYWN0 aXZlIHVzZSBieSBSaWdodHNpZGUsIERvbnV0cyBhbmQgRG9tYWluIE5hbWUgU2VydmljZXMgKHRo YXQgSSBrbm93IG9mKSBtZWFuaW5nIHRoYXQgYXJvdW5kIDE5MCBuZXcgVExEcyBhcmUgdXNpbmcg aXQgb3IgYWJvdXQgdG8gZG8gc28uDQoNCltTQUhdIEnigJlkIHJhdGhlciBmb2N1cyBvbiBudW1i ZXIgb2Ygb3BlcmF0b3JzL2ltcGxlbWVudGF0aW9ucyB0aGFuIG51bWJlciBvZiBUTERzLg0KDQpX ZSBjYW7igJl0IGRvIG5vdGhpbmcgYmVjYXVzZSBzb21lIG9wZXJhdG9ycyBhcmUgZG9pbmcgdGhl aXIgb3duIHRoaW5nIGFuZCBkb2N1bWVudGluZyB0aGVpciBvd24gZXh0ZW5zaW9ucyBvdXRzaWRl IHRoZSBJRVRGLiBXZSBzaG91bGQgZm9jdXMgb24gZG9pbmcgdGhlIGJlc3Qgd2UgY2FuIHdpdGgg d2hhdCB3ZSBoYXZlLg0KDQpTY290dA0K --_000_831693C2CDA2E849A7D7A712B24E257F49F490A7BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gRXBwRXh0IFttYWlsdG86ZXBwZXh0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkVkIFBhc2NvZTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDE4LCAyMDE1IDE6MDIgQU08YnI+DQo8Yj5Ubzo8L2I+IEdhdmluIEJyb3duPGJyPg0KPGI+ Q2M6PC9iPiBlcHBleHRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtlcHBleHRd IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1icm93bi1lcHAtZmVlcy0w NC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2hpbGUgSSB0aGluayB0aGlzIGV4dGVuc2lvbiBpcyB3ZWxsIHdyaXR0ZW4gYW5kIHZhbHVh YmxlIEkgZG8gaGF2ZSB0byBxdWVzdGlvbiBpZiBhIHN0YW5kYXJkcyB0cmFjayBpcyBhcHByb3By aWF0ZT88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBj b21wZXRpbmcgdmVyc2lvbiBvZiB0aGlzIGlzIHRoZSBVbml0ZWRUTEQgJnF1b3Q7UHJpY2UgQ2F0 ZWdvcmllcyBHdWlkZSZxdW90OyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9yaWdodHNpZGUuY28vZmls ZWFkbWluL2Rvd25sb2Fkcy9wb2xpY2llcy9SaWdodHNpZGVfUHJpY2VfQ2F0ZWdvcmllcy5wZGYi Pmh0dHA6Ly9yaWdodHNpZGUuY28vZmlsZWFkbWluL2Rvd25sb2Fkcy9wb2xpY2llcy9SaWdodHNp ZGVfUHJpY2VfQ2F0ZWdvcmllcy5wZGY8L2E+DQogd2hpY2ggaGFzIG5vdCBiZWVuIGZvcm1hbGx5 IHB1Ymxpc2hlZC4gSG93ZXZlciBpdHMgaW4gYWN0aXZlIHVzZSBieSBSaWdodHNpZGUsIERvbnV0 cyBhbmQgRG9tYWluIE5hbWUgU2VydmljZXMgKHRoYXQgSSBrbm93IG9mKSBtZWFuaW5nIHRoYXQg YXJvdW5kIDE5MCBuZXcgVExEcyBhcmUgdXNpbmcgaXQgb3IgYWJvdXQgdG8gZG8gc28uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0FIXSBJ4oCZZCByYXRoZXIg Zm9jdXMgb24gbnVtYmVyIG9mIG9wZXJhdG9ycy9pbXBsZW1lbnRhdGlvbnMgdGhhbiBudW1iZXIg b2YgVExEcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgY2Fu4oCZdCBkbyBu b3RoaW5nIGJlY2F1c2Ugc29tZSBvcGVyYXRvcnMgYXJlIGRvaW5nIHRoZWlyIG93biB0aGluZyBh bmQgZG9jdW1lbnRpbmcgdGhlaXIgb3duIGV4dGVuc2lvbnMgb3V0c2lkZSB0aGUgSUVURi4gV2Ug c2hvdWxkIGZvY3VzIG9uIGRvaW5nIHRoZSBiZXN0IHdlIGNhbiB3aXRoIHdoYXQNCiB3ZSBoYXZl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TY290dDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_831693C2CDA2E849A7D7A712B24E257F49F490A7BRN1WNEXMBX01vc_-- From nobody Wed Feb 18 06:26:37 2015 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 D03791A8833 for ; Wed, 18 Feb 2015 06:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 mpNi-luF0eK5 for ; Wed, 18 Feb 2015 06:26:30 -0800 (PST) Received: from mail-oi0-f99.google.com (mail-oi0-f99.google.com [209.85.218.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7DB1A87A1 for ; Wed, 18 Feb 2015 06:26:29 -0800 (PST) Received: by mail-oi0-f99.google.com with SMTP id z81so101226oif.2 for ; Wed, 18 Feb 2015 06:26:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=fGNsv/coRnS5/s74CGPP1swuFwEVL2mr2V8gk749th8=; b=KBDHhc+tXMVDwq+pc2lFKTfvTt6ib/hQ3vr9BAP/l5vvm5eYsvfsKicZ7IDsaIjnZF Sw1PbbdC9Kiaoj9dMheXEUj6YTZA/p23eAcukR3QGRqpgdtzbBBtr3qaE08RWWGehezN LNd0yByhGbmHOl6zDS7Y48YfsjZr/QxAW0KdsQbDN3ZRIumDLirZySQWYgodrh70mtqU gk2egxU+cwZ9sbbJhMNyhfsCtbqvSrPm3bBxldJL0qF3/7RpJeD2hLWRuEtHnfmLub/X R8bJ+wxn4rhvopQtzNBlyGJZ8hpwAB3MxEloRjZndtCYHeAVkBC9S5k/6YGplMnpYitp WNIg== X-Gm-Message-State: ALoCoQlmbTRrqcu/MFnuaO5cFl72NcS1jlXxZq5oGfrVLni6K5jTjlXSEU2drkYUwf4+4uL3M5aH9ztxRvLbN/AmHtFGyfeFhQ== X-Received: by 10.140.232.149 with SMTP id d143mr484876qhc.81.1424269589097; Wed, 18 Feb 2015 06:26:29 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id jy4sm1848169qcb.0.2015.02.18.06.26.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 18 Feb 2015 06:26:29 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t1IEQSaP007604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2015 09:26:28 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 18 Feb 2015 09:26:27 -0500 From: "Gould, James" To: Michael Holloway Thread-Topic: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.txt Thread-Index: AQHQS0B0WAU5qNqLlEWtQs5ZbM3sFpz2cR8AgABZ8wA= Date: Wed, 18 Feb 2015 14:26:27 +0000 Message-ID: <55005756-7D80-4BA3-9DA4-ABD7F75DA03D@verisign.com> References: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> <54E32A6A.2050905@centralnic.com> <54E4559E.4050109@comlaude.com> In-Reply-To: <54E4559E.4050109@comlaude.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_550057567D804BA39DA4ABD7F75DA03Dverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.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 Feb 2015 14:26:34 -0000 --_004_550057567D804BA39DA4ABD7F75DA03Dverisigncom_ Content-Type: multipart/alternative; boundary="_000_550057567D804BA39DA4ABD7F75DA03Dverisigncom_" --_000_550057567D804BA39DA4ABD7F75DA03Dverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I was the one that proposed that draft-brown-epp-fees be defined as Standar= ds Track based on it being a published Internet Draft, based on the incorpo= ration of community input, and based on interest to implement it by multipl= e independent parties. I believe that we will find many extensions that pr= ivately exist with overlap. We too have proprietary extensions that exist = that have overlap with draft-brown-epp-fees, but these extensions were not = targeted for Standards Track and there is little case for attempting to cre= ate competing Standards Track drafts. In this case I see a lot of overlap= between draft-brown-epp-fees and the private Price Categories Guide extens= ion. My recommendation is to register the Price Categories Guide extension= as an Informational extension in the Extension Registry and contribute to = the discussion around draft-brown-epp-fees to reconcile the material differ= ences. =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Feb 18, 2015, at 4:04 AM, Michael Holloway > wrote: Ed, Good point. The UnitedTLD is also used ZACR, while this extension is in use by CentralN= IC, GMO, Charleston, Minds and Machines - albeit they are using varying ver= sions. Ignoring the fact that the big 3 all have their their own alternativ= es (and 1 or 2 more), these two extensions already have a large coverage. U= nitedTLD's extension is much simpler while this one is much more complex (d= ue to registry input to Gavin indicating they want the flexibility). I do not believe that any registry that has already implemented one or the = other will switch, which means both of the extensions will continue to be u= sed even if one were to take the lead. So is there an argument to propose two standards for the same purpose or do= we back the one that pushes in the interest of having a standard? Two stan= dards are better than none which results in several alternative custom exte= nsions, so I would back either or both if they are going down standards tra= ck. Cheers, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 02/18/2015 07:01 AM, Ed Pascoe wrote: While I think this extension is well written and valuable I do have to ques= tion if a standards track is appropriate? The competing version of this is the UnitedTLD "Price Categories Guide" htt= p://rightside.co/fileadmin/downloads/policies/Rightside_Price_Categories.pd= f which has not been formally published. However its in active use by Right= side, Donuts and Domain Name Services (that I know of) meaning that around = 190 new TLDs are using it or about to do so. So the question is where do we go to from here? Do we try and get Rightside= to have the original author publish it to the EPP extension registry or do= we pretend it doesn't exist and ignore the significant percentage of new T= LDs using it? On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown > wrote: I've just submitted a new version of the fee extension draft for your review. 9.4. Changes from 03 to 04 1. Changed Intended Status to Standards Track. 2. As per suggestion from Michael Bauland, the element is no longer included in and responses for "restore" commands. It's still mandatory for all other commands. 3. Added summary of the attributes for the element. 4. Clarified that the "refundable" and "grace-period" attributes of the fee elements are dependant on each other and cannot appear on their own. 5. Removed the option of returning a 1001 response when the fee is incorrect. 6. Forbidden the inclusion of extension elements in transform responses if no fee/credit has been assessed. 7. Made the element optional in transform commands. 8. Amended XML Namespace section of IANA Considerations, added EPP Extension Registry section. 10. TODO (Note to RFC Editor: remove this section before publication as an RFC.) 1. Make the extension object-agnostic so it can be used with other objects, not just vanilla domains. 2. Change the command so that availability data is not returned. -------- Forwarded Message -------- Subject: New Version Notification for draft-brown-epp-fees-04.txt Date: Tue, 17 Feb 2015 02:16:09 -0800 From: internet-drafts@ietf.org To: Gavin Brown > A new version of I-D, draft-brown-epp-fees-04.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-brown-epp-fees Revision: 04 Title: Registry Fee Extension for the Extensible Provisioning Prot= ocol (EPP) Document date: 2015-02-17 Group: Individual Submission Pages: 36 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-04 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- 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. _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_550057567D804BA39DA4ABD7F75DA03Dverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I was the one that proposed that draft-brown-epp-fees be defined as St= andards Track based on it being a published Internet Draft, based on the in= corporation of community input, and based on interest to implement it by mu= ltiple independent parties.  I believe that we will find many extensions that privately exist with overlap. =  We too have proprietary extensions that exist that have overlap with&= nbsp;draft-brown-epp-fees, but these extensions were not targeted for Stand= ards Track and there is little case for attempting to create competing Standards Track drafts.   In this case I see= a lot of overlap between draft-brown-epp-fees and the private Price C= ategories Guide extension.  My recommendation is to register the Price= Categories Guide extension as an Informational extension in the Extension Registry and contribute to the discussion around dra= ft-brown-epp-fees to reconcile the material differences.     &nbs= p; 

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

On Feb 18, 2015, at 4:04 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:
Ed, Good point.

The UnitedTLD is also used ZACR, while this extension is in use by CentralN= IC, GMO, Charleston, Minds and Machines - albeit they are using varying ver= sions. Ignoring the fact that the big 3 all have their their own alternativ= es (and 1 or 2 more), these two extensions already have a large coverage. UnitedTLD's extension is much si= mpler while this one is much more complex (due to registry input to Gavin i= ndicating they want the flexibility).

I do not believe that any registry that has already implemented one or the = other will switch, which means both of the extensions will continue to be u= sed even if one were to take the lead.

So is there an argument to propose two standards for the same purpose or do= we back the one that pushes in the interest of having a standard? Two stan= dards are better than none which results in several alternative custom exte= nsions, so I would back either or both if they are going down standards track.

Cheers,
Michael



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com




On 02/18/2015 07:01 AM, Ed Pascoe wrote:
While I think this extension is well written and valuable = I do have to question if a standards track is appropriate?

The competing version of this is the UnitedTLD "Price Categories = Guide" http://rightside= .co/fileadmin/downloads/policies/Rightside_Price_Categories.pdf which has not been formally published. However its in active use by Rights= ide, Donuts and Domain Name Services (that I know of) meaning that around 1= 90 new TLDs are using it or about to do so.

So the question is where do we go to from here? Do we try and get Righ= tside to have the original author publish it to the EPP extension registry = or do we pretend it doesn't exist and ignore the significant percentage of = new TLDs using it?


On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown <gavin.brown@centralnic.com> wrote:
I've just submitted a new version of the fee extension draft for your
review.

9.4. Changes from 03 to 04

   1.  Changed Intended Status to Standards Track.

   2.  As per suggestion from Michael Bauland, the <fee:p= eriod> element
       is no longer included in <check> and <i= nfo> responses for
       "restore" commands.  It's still m= andatory for all other commands.

   3.  Added summary of the attributes for the <fee:fee&g= t; element.

   4.  Clarified that the "refundable" and "g= race-period" attributes of
       the <fee> fee elements are dependant on ea= ch other and cannot
       appear on their own.

   5.  Removed the option of returning a 1001 response when = the fee is
       incorrect.

   6.  Forbidden the inclusion of extension elements in tran= sform
       responses if no fee/credit has been assessed.
   7.  Made the <fee:currency> element optional in tra= nsform commands.

   8.  Amended XML Namespace section of IANA Considerations,= added EPP
       Extension Registry section.

10. TODO


   (Note to RFC Editor: remove this section before publication as= an
   RFC.)

   1.  Make the extension object-agnostic so it can be used = with other
       objects, not just vanilla domains.

   2.  Change the <check> command so that availability= data is not
       returned.

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: = internet-drafts@ietf.org
To: Gavin Brown <gavin.brown@centralnic.com>

A new version of I-D, draft-brown-epp-fees-04.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:           draft-brown-epp-fees
Revision:       04
Title:          Registry Fee Extension for the Ext= ensible Provisioning Protocol
(EPP)
Document date:  2015-02-17
Group:          Individual Submission
Pages:          36
URL:
http://www.ietf.org/internet-dr= afts/draft-brown-epp-fees-04.txt
Status:         https://datatracker.ietf.org/doc/draft-brown-epp-fees/
Htmlized:       http://t= ools.ietf.org/html/draft-brown-epp-fees-04
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-04<= br>
Abstract:
   This document describes an Extensible Provisioning Protocol (E= PP)
   extension mapping for registry fees.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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




_______________________________________________
EppExt mailing list
EppExt@ietf.org=
https://www.ietf.org/mailman/listinfo/eppext 



_______________________________________________
EppExt mailing list
EppEx=
t@ietf.org
https://www.ietf.org/mailman/listinfo/eppext


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

--_000_550057567D804BA39DA4ABD7F75DA03Dverisigncom_-- --_004_550057567D804BA39DA4ABD7F75DA03Dverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Wed, 18 Feb 2015 14:26:26 GMT"; modification-date="Wed, 18 Feb 2015 14:26:26 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_550057567D804BA39DA4ABD7F75DA03Dverisigncom_-- From nobody Wed Feb 18 07:18:48 2015 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 66E2C1A89C6 for ; Wed, 18 Feb 2015 07:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 PEFhQt_pxT-B for ; Wed, 18 Feb 2015 07:18:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F841A89EB for ; Wed, 18 Feb 2015 07:18:40 -0800 (PST) Received: from BN1PR02MB119.namprd02.prod.outlook.com (10.255.204.21) by BN1PR02MB119.namprd02.prod.outlook.com (10.255.204.21) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 15:18:23 +0000 Received: from BN1PR02MB119.namprd02.prod.outlook.com ([169.254.8.151]) by BN1PR02MB119.namprd02.prod.outlook.com ([169.254.8.151]) with mapi id 15.01.0087.013; Wed, 18 Feb 2015 15:18:23 +0000 From: Roger D Carney To: "eppext@ietf.org" Thread-Topic: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.txt Thread-Index: AQHQS0BySuobxDwleUuP+G19HqAPa5z2HU0AgABZ9ICAAAvCEA== Date: Wed, 18 Feb 2015 15:18:23 +0000 Message-ID: References: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> <54E32A6A.2050905@centralnic.com> <54E4559E.4050109@comlaude.com> <55005756-7D80-4BA3-9DA4-ABD7F75DA03D@verisign.com> In-Reply-To: <55005756-7D80-4BA3-9DA4-ABD7F75DA03D@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.18.124.240] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR02MB119; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR02MB119; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(243025005)(2473001)(24454002)(48184003)(479174004)(377454003)(52604005)(377424004)(230783001)(2656002)(40100003)(19625215002)(62966003)(16601075003)(77156002)(19627595001)(93886004)(74316001)(14971765001)(2501002)(450100001)(19617315012)(54356999)(66066001)(92566002)(18206015028)(50986999)(76176999)(76576001)(33656002)(87936001)(99286002)(99936001)(106116001)(122556002)(19609705001)(110136001)(107886001)(86362001)(2950100001)(2900100001)(2351001)(102836002)(15395725005)(19300405004)(2420400003)(15975445007)(19580395003)(16236675004)(17760045003)(46102003)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR02MB119; H:BN1PR02MB119.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/related; boundary="_004_BN1PR02MB119F03E8AD2C986A2DCB88DB12C0BN1PR02MB119namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: godaddy.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 15:18:23.5694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR02MB119 Archived-At: Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.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 Feb 2015 15:18:47 -0000 --_004_BN1PR02MB119F03E8AD2C986A2DCB88DB12C0BN1PR02MB119namprd_ Content-Type: multipart/alternative; boundary="_000_BN1PR02MB119F03E8AD2C986A2DCB88DB12C0BN1PR02MB119namprd_" --_000_BN1PR02MB119F03E8AD2C986A2DCB88DB12C0BN1PR02MB119namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for bringing this forward Ed! I agree with Jim and think that we should encourage the author(s) of the "P= rice Categories Guide" to publish this document as an Informational extensi= on to the Extension Registry. Thanks Roger From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James Sent: Wednesday, February 18, 2015 8:26 AM To: Michael Holloway Cc: eppext@ietf.org Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fee= s-04.txt I was the one that proposed that draft-brown-epp-fees be defined as Standar= ds Track based on it being a published Internet Draft, based on the incorpo= ration of community input, and based on interest to implement it by multipl= e independent parties. I believe that we will find many extensions that pr= ivately exist with overlap. We too have proprietary extensions that exist = that have overlap with draft-brown-epp-fees, but these extensions were not = targeted for Standards Track and there is little case for attempting to cre= ate competing Standards Track drafts. In this case I see a lot of overlap= between draft-brown-epp-fees and the private Price Categories Guide extens= ion. My recommendation is to register the Price Categories Guide extension= as an Informational extension in the Extension Registry and contribute to = the discussion around draft-brown-epp-fees to reconcile the material differ= ences. - JG [cid:image001.png@01D04B5A.F34F6170] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Feb 18, 2015, at 4:04 AM, Michael Holloway > wrote: Ed, Good point. The UnitedTLD is also used ZACR, while this extension is in use by CentralN= IC, GMO, Charleston, Minds and Machines - albeit they are using varying ver= sions. Ignoring the fact that the big 3 all have their their own alternativ= es (and 1 or 2 more), these two extensions already have a large coverage. U= nitedTLD's extension is much simpler while this one is much more complex (d= ue to registry input to Gavin indicating they want the flexibility). I do not believe that any registry that has already implemented one or the = other will switch, which means both of the extensions will continue to be u= sed even if one were to take the lead. So is there an argument to propose two standards for the same purpose or do= we back the one that pushes in the interest of having a standard? Two stan= dards are better than none which results in several alternative custom exte= nsions, so I would back either or both if they are going down standards tra= ck. Cheers, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 02/18/2015 07:01 AM, Ed Pascoe wrote: While I think this extension is well written and valuable I do have to ques= tion if a standards track is appropriate? The competing version of this is the UnitedTLD "Price Categories Guide" htt= p://rightside.co/fileadmin/downloads/policies/Rightside_Price_Categories.pd= f which has not been formally published. However its in active use by Right= side, Donuts and Domain Name Services (that I know of) meaning that around = 190 new TLDs are using it or about to do so. So the question is where do we go to from here? Do we try and get Rightside= to have the original author publish it to the EPP extension registry or do= we pretend it doesn't exist and ignore the significant percentage of new T= LDs using it? On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown > wrote: I've just submitted a new version of the fee extension draft for your review. 9.4. Changes from 03 to 04 1. Changed Intended Status to Standards Track. 2. As per suggestion from Michael Bauland, the element is no longer included in and responses for "restore" commands. It's still mandatory for all other commands. 3. Added summary of the attributes for the element. 4. Clarified that the "refundable" and "grace-period" attributes of the fee elements are dependant on each other and cannot appear on their own. 5. Removed the option of returning a 1001 response when the fee is incorrect. 6. Forbidden the inclusion of extension elements in transform responses if no fee/credit has been assessed. 7. Made the element optional in transform commands. 8. Amended XML Namespace section of IANA Considerations, added EPP Extension Registry section. 10. TODO (Note to RFC Editor: remove this section before publication as an RFC.) 1. Make the extension object-agnostic so it can be used with other objects, not just vanilla domains. 2. Change the command so that availability data is not returned. -------- Forwarded Message -------- Subject: New Version Notification for draft-brown-epp-fees-04.txt Date: Tue, 17 Feb 2015 02:16:09 -0800 From: internet-drafts@ietf.org To: Gavin Brown > A new version of I-D, draft-brown-epp-fees-04.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-brown-epp-fees Revision: 04 Title: Registry Fee Extension for the Extensible Provisioning Prot= ocol (EPP) Document date: 2015-02-17 Group: Individual Submission Pages: 36 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-04 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- 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. _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_BN1PR02MB119F03E8AD2C986A2DCB88DB12C0BN1PR02MB119namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for bringing th= is forward Ed!

 

I agree with Jim and t= hink that we should encourage the author(s) of the “Price Categories = Guide” to publish this document as an Informational extension to the = Extension Registry.

 

 

Thanks

Roger

 

 

From: EppExt [mailto:eppext-bounces@= ietf.org] On Behalf Of Gould, James
Sent: Wednesday, February 18, 2015 8:26 AM
To: Michael Holloway
Cc: eppext@ietf.org
Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-= epp-fees-04.txt

 

I was the one that proposed that draft-brown-ep= p-fees be defined as Standards Track based on it being a published Internet= Draft, based on the incorporation of community input, and based on interes= t to implement it by multiple independent parties.  I believe that we will find many extensions that priva= tely exist with overlap.  We too have proprietary extensions that exis= t that have overlap with draft-brown-epp-fees, but these extensions we= re not targeted for Standards Track and there is little case for attempting to create competing Standards Track drafts.  &nbs= p;In this case I see a lot of overlap between draft-brown-epp-fees and= the private Price Categories Guide extension.  My recommendation is t= o register the Price Categories Guide extension as an Informational extension in the Extension Registry and contribute to the di= scussion around draft-brown-epp-fees to reconcile the material differe= nces.       

 

—

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<= /a>

 



Ed, Good point.

The UnitedTLD is also used ZACR, while this extension is in use by CentralN= IC, GMO, Charleston, Minds and Machines - albeit they are using varying ver= sions. Ignoring the fact that the big 3 all have their their own alternativ= es (and 1 or 2 more), these two extensions already have a large coverage. UnitedTLD's extension is much si= mpler while this one is much more complex (due to registry input to Gavin i= ndicating they want the flexibility).

I do not believe that any registry that has already implemented one or the = other will switch, which means both of the extensions will continue to be u= sed even if one were to take the lead.

So is there an argument to propose two standards for the same purpose or do= we back the one that pushes in the interest of having a standard? Two stan= dards are better than none which results in several alternative custom exte= nsions, so I would back either or both if they are going down standards track.

Cheers,
Michael



Michael Holloway
Senior Systems Administrator | Com Laud= e
E: michael.holloway@comlaude.com




On 02/18/2015 07:01 AM, Ed Pascoe wrote:

While I think this extension is well written and val= uable I do have to question if a standards track is appropriate?

 

The competing version of this is the UnitedTLD "= ;Price Categories Guide" http://rightside.co/fil= eadmin/downloads/policies/Rightside_Price_Categories.pdf which has not been formally published. However its in active use by Rights= ide, Donuts and Domain Name Services (that I know of) meaning that around 1= 90 new TLDs are using it or about to do so.

 

So the question is where do we go to from here? Do w= e try and get Rightside to have the original author publish it to the EPP e= xtension registry or do we pretend it doesn't exist and ignore the signific= ant percentage of new TLDs using it?

 

 

On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown <gavin.brown@ce= ntralnic.com> wrote:

I've just submitted a= new version of the fee extension draft for your
review.

9.4. Changes from 03 to 04

   1.  Changed Intended Status to Standards Track.

   2.  As per suggestion from Michael Bauland, the <fee:p= eriod> element
       is no longer included in <check> and <i= nfo> responses for
       "restore" commands.  It's still m= andatory for all other commands.

   3.  Added summary of the attributes for the <fee:fee&g= t; element.

   4.  Clarified that the "refundable" and "g= race-period" attributes of
       the <fee> fee elements are dependant on ea= ch other and cannot
       appear on their own.

   5.  Removed the option of returning a 1001 response when = the fee is
       incorrect.

   6.  Forbidden the inclusion of extension elements in tran= sform
       responses if no fee/credit has been assessed.
   7.  Made the <fee:currency> element optional in tra= nsform commands.

   8.  Amended XML Namespace section of IANA Considerations,= added EPP
       Extension Registry section.

10. TODO


   (Note to RFC Editor: remove this section before publication as= an
   RFC.)

   1.  Make the extension object-agnostic so it can be used = with other
       objects, not just vanilla domains.

   2.  Change the <check> command so that availability= data is not
       returned.

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: internet-drafts@ietf.org<= /a>
To: Gavin Brown <gavin.bro= wn@centralnic.com>

A new version of I-D, draft-brown-epp-fees-04.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:           draft-brown-epp-fees
Revision:       04
Title:          Registry Fee Extension for the Ext= ensible Provisioning Protocol
(EPP)
Document date:  2015-02-17
Group:          Individual Submission
Pages:          36
URL:
http://www.ietf.org/internet-drafts/draft-brown-epp-fees= -04.txt
Status:         https://datatracker.ietf= .org/doc/draft-brown-epp-fees/
Htmlized:       http://tools.ietf.org/html/draft-= brown-epp-fees-04
Diff:           http://www.ietf= .org/rfcdiff?url2=3Ddraft-brown-epp-fees-04

Abstract:
   This document describes an Extensible Provisioning Protocol (E= PP)
   extension mapping for registry fees.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services<= /span>
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in Engl= and and Wales with
company number 8576358. Registered Offices: 35-39 Mo= orgate, London,
EC2R 6AR.




_______________________________________________
EppExt mailing list
EppExt@ietf.org
= https://www.ietf.org/mailman/listinfo/eppext

 




_______________________________________________
EppExt mailing list
EppExt@ietf.org

https://www.i=
etf.org/mailman/listinfo/eppext

 

 

_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.o= rg/mailman/listinfo/eppext

 

--_000_BN1PR02MB119F03E8AD2C986A2DCB88DB12C0BN1PR02MB119namprd_-- --_004_BN1PR02MB119F03E8AD2C986A2DCB88DB12C0BN1PR02MB119namprd_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Wed, 18 Feb 2015 15:18:23 GMT"; modification-date="Wed, 18 Feb 2015 15:18:23 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_BN1PR02MB119F03E8AD2C986A2DCB88DB12C0BN1PR02MB119namprd_-- From nobody Sun Feb 22 15:19:35 2015 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 AE4531A00B0 for ; Sun, 22 Feb 2015 15:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 9DyPWJ9gNkr8 for ; Sun, 22 Feb 2015 15:19:33 -0800 (PST) Received: from mail-qg0-f99.google.com (mail-qg0-f99.google.com [209.85.192.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319491A00AE for ; Sun, 22 Feb 2015 15:19:32 -0800 (PST) Received: by mail-qg0-f99.google.com with SMTP id a108so2157192qge.2 for ; Sun, 22 Feb 2015 15:19:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type:content-id :content-transfer-encoding:mime-version; bh=PWVZnV+HkSFa0mtEMXuGREQ7v5Spp0KmndGHn1agUqQ=; b=Kkep8Q9SHuoDQJhCQAcAWN5QYyvl8+99iGI8zRqnhEn6PFKcOJk/W0a9xz0XW0of9M slwjAX2agnY1M8abaWj1LgXLeHUxs1lLlrAauzamJlpg0K9ccitvAHVuuCQEnC/Yl5uh gfcPaCeR4xFdmRH7irvDxRKn9W/hH+09iu4oyDNY7VJBbulFp5zL6gfbb7uooF9pcMUq 9EoAQJU0w9O2TbvhGmMzqbYUUNowy6FtWdwp/c0nfxPWOfzkAl4orArPHMVIRx/vBiO5 +AGahTzTT3Edb0RI+MJpt/fL26gwaJFyll1awGMCdOeD8d7hD5uazeWh8worljrWWlhE WXiw== X-Gm-Message-State: ALoCoQmYdwHTJguvRI9VgX5HdsHl6sBMxGwbrNaQzmTay+891LzI/wpKSBvWMoCb9nHbnxdAqBcnHlOh9QiMpNIHyMm7Kh9mEA== X-Received: by 10.229.175.131 with SMTP id ba3mr19482058qcb.3.1424647172177; Sun, 22 Feb 2015 15:19:32 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id jy4sm5193412qcb.0.2015.02.22.15.19.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 22 Feb 2015 15:19:32 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t1MNJVOq017659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 22 Feb 2015 18:19:31 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sun, 22 Feb 2015 18:19:30 -0500 From: "Hollenbeck, Scott" To: "eppext@ietf.org" Thread-Topic: Meeting at IETF-92 Thread-Index: AdBO9gCZJJ0oSPcEQcqftSrZG5flOg== Date: Sun, 22 Feb 2015 23:19:27 +0000 Message-ID: <07D5589F-2BD2-41DD-BCDD-647D86D1FA0A@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [eppext] Meeting at IETF-92 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 Feb 2015 23:19:34 -0000 The preliminary agenda has been posted. Right now eppext has a Friday after= noon slot. Please plan accordingly, folks. It would be nice if our chairs shared their thoughts on the agenda... Scott= From nobody Mon Feb 23 05:57:01 2015 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 D3CE41A1ACC for ; Mon, 23 Feb 2015 05:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 QTAuTbkd-w7x for ; Mon, 23 Feb 2015 05:56:58 -0800 (PST) Received: from mail-oi0-f97.google.com (mail-oi0-f97.google.com [209.85.218.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DD41A1A32 for ; Mon, 23 Feb 2015 05:56:58 -0800 (PST) Received: by mail-oi0-f97.google.com with SMTP id u20so2394440oif.0 for ; Mon, 23 Feb 2015 05:56:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type :mime-version; bh=x2e2OrHur7xkU0jh1oDTh5u1N/paSKgYOM7JKRkCm9E=; b=AvUflDuRoN8NjbBcO02etAICHbevhmjCSEWXj1roZnZOLyZ9SWgS6mZwabVoDYozy4 mkqn+N6KWlsIin4HzT7vq7JvM7D5eIwDRvA41V6aUEzjA/9MxjnotjHPKB2pr7qb8LEl osqxzRjENEnuNGdB/iaDxuouYYWg+vOXSYCQe5Uj96ig/A77VxHm47+aSqzYEL7F0zja Cmux62EKRnu4yjpXKGfUwUBzTrNCpT0NYg5B2F2c9B4X32baOrmlNXy3g3yVdQ/DUxxq KLnGpsdC0bZBTuq45CyNwCBCTYOVQrr6lnhKBJ3b9/fCEZvWj6jAc/vCG0bt/wb7x2GZ GTVw== X-Gm-Message-State: ALoCoQkogwmg+r+9LAc7DjQmtffxz8ZWpOVoptesGG+69Ba5ZiDPZGYEmvGZgwNZ5g1ylYVG26eLqOl0LB7SZqkOfcqKUTydrQ== X-Received: by 10.140.91.201 with SMTP id z67mr24193509qgd.27.1424699817482; Mon, 23 Feb 2015 05:56:57 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id t2sm6411705qcz.2.2015.02.23.05.56.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Feb 2015 05:56:57 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t1NDuuJn005243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Feb 2015 08:56:56 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 23 Feb 2015 08:56:56 -0500 From: "Gould, James" To: "eppext@ietf.org" , EPP Provreg , "gtld-tech@icann.org" Thread-Topic: Publishing of the Change Poll EPP Extension 01 IETF Draft Thread-Index: AQHQT3CVTV7ZUMdjakSc1GLcf4WpdA== Date: Mon, 23 Feb 2015 13:56:51 +0000 Message-ID: <5CD280FB-62A2-4587-89C3-122A46D03752@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_5CD280FB62A2458789C3122A46D03752verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [eppext] Publishing of the Change Poll EPP Extension 01 IETF Draft 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, 23 Feb 2015 13:57:00 -0000 --_004_5CD280FB62A2458789C3122A46D03752verisigncom_ Content-Type: multipart/alternative; boundary="_000_5CD280FB62A2458789C3122A46D03752verisigncom_" --_000_5CD280FB62A2458789C3122A46D03752verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The second draft of the Change Poll EPP Extension ( https://tools.ietf.org/= html/draft-gould-change-poll-01 ) has been published to the IETF. This dra= ft includes the following change: 1. Added an optional caseId element that defines the case identifier from UDRP= , URS, or custom case, based on feedback from Michael Holloway. Please review the draft and provide any feedback. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_5CD280FB62A2458789C3122A46D03752verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <10CACCFF3D85F84988767809FC556DCC@verisign.com> Content-Transfer-Encoding: quoted-printable The second draft of the Change Poll EPP Extension ( https://tools.ietf.org/htm= l/draft-gould-change-poll-01 ) has been published to the IETF.  Th= is draft includes the following change: 

  1. Added an optional caseId eleme=
nt that defines the case identifier from UDRP, URS, or custom case, based o=
n feedback from Michael Holloway.

Please review the draft and provide any feedback.

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_5CD280FB62A2458789C3122A46D03752verisigncom_-- --_004_5CD280FB62A2458789C3122A46D03752verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Mon, 23 Feb 2015 13:56:51 GMT"; modification-date="Mon, 23 Feb 2015 13:56:51 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_5CD280FB62A2458789C3122A46D03752verisigncom_-- From nobody Mon Feb 23 13:16:48 2015 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 CAF1B1A6F27 for ; Mon, 23 Feb 2015 13:16:46 -0800 (PST) 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 xpv3aCsHfe5c for ; Mon, 23 Feb 2015 13:16:45 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162591A6F17 for ; Mon, 23 Feb 2015 13:16:45 -0800 (PST) Received: by qcrw7 with SMTP id w7so13289048qcr.4 for ; Mon, 23 Feb 2015 13:16:44 -0800 (PST) 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=v1jLh29ZUYBCQLuZPD4EJSBxRc8IYsn8/6P+qayAAnY=; b=dKQ6egcJIrhzpkrhk/8Nh7D/M7oeW6iFw5TqeDqA/EVxdB+wMb8hp8BVsZbG5O/i5M xngkkueDNtDvEJ6f9lAcf7fCl5TWExTL8C1ZxrcWzhCsrRuNkX28Uq3zHEFs16EUY3ru dvIdtkpFuSHVxCHamBhvGeIheoenQyhEc2jOm7bF27zPlCxHp8ZLMI/SBasj+HB3jz0X 3Cg26HInGrvLi/WrY1l/8qSNPDTLSMQrW5LktPN2gQ11IT9qTNrDQsL3fa//sEgBmwPh EozjJaBBahpHpnnE2kt1QHlb6Pc6IGRiZ3XdBDLjZISQgKS6riG2W6/s81RzOeIYtDLq WoFA== X-Gm-Message-State: ALoCoQkFYk4I0mtlGyaORM+NQEJrVhac0Rq9oLTg2/Q1ZzZ1z5jdoXtMngBATSabph5QdBsXgetx X-Received: by 10.229.71.69 with SMTP id g5mr29340539qcj.7.1424726204331; Mon, 23 Feb 2015 13:16:44 -0800 (PST) Received: from jgalvin-lt.local (c-73-133-108-218.hsd1.md.comcast.net. [73.133.108.218]) by mx.google.com with ESMTPSA id 142sm18198980qhg.16.2015.02.23.13.16.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 13:16:43 -0800 (PST) Message-ID: <54EB98D1.40607@elistx.com> Date: Mon, 23 Feb 2015 16:17:05 -0500 From: James Galvin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "eppext@ietf.org" References: <07D5589F-2BD2-41DD-BCDD-647D86D1FA0A@verisign.com> In-Reply-To: <07D5589F-2BD2-41DD-BCDD-647D86D1FA0A@verisign.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [eppext] Meeting at IETF-92 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, 23 Feb 2015 21:16:47 -0000 Actually, help from the working group would be great! The issue is the opportunity to request a meeting snuck up on the chairs, so we urgently grasped at the opportunity and our AD obliged, although we drew the short straw this time and got the last meeting slot on Friday. That said, following up on our discussions from the last IETF, I would expect our agenda to at least look like the following. 1. Complete (or plan) working group last call on all existing EPP extension documents. 2. Consider the question of rechartering to continue review of standards track EPP extension proposal. Comments and suggestions from the working group are welcome. I will send some messages to move existing documents and discussions along shortly. Jim co-Chair On 2/22/15 6:19 PM, Hollenbeck, Scott wrote: > The preliminary agenda has been posted. Right now eppext has a Friday afternoon slot. Please plan accordingly, folks. > > It would be nice if our chairs shared their thoughts on the agenda... > > Scott > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > From nobody Thu Feb 26 17:07:46 2015 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 22C961A1AA2; Thu, 26 Feb 2015 17:07:45 -0800 (PST) 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 S8ARFnz2_cOt; Thu, 26 Feb 2015 17:07:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B53661A00B1; Thu, 26 Feb 2015 17:07:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150227010743.18058.27998.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 17:07:43 -0800 Archived-At: Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-tmch-smd-01.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: Fri, 27 Feb 2015 01:07:45 -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 : Mark and Signed Mark Objects Mapping Author : Gustavo Lozano Filename : draft-ietf-eppext-tmch-smd-01.txt Pages : 29 Date : 2015-02-26 Abstract: This document describes the format of a mark and a digitally signed mark, referred to as a signed mark and the Signed Mark Data (SMD) file as defined by the ICANN Trademark Clearinghouse. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-tmch-smd-01 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 Fri Feb 27 07:15:22 2015 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 A58711ACD3A; Fri, 27 Feb 2015 07:15:20 -0800 (PST) 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 f2TTNe_nUQ47; Fri, 27 Feb 2015 07:15:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB3E1ACD30; Fri, 27 Feb 2015 07:15:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150227151519.31302.55983.idtracker@ietfa.amsl.com> Date: Fri, 27 Feb 2015 07:15:19 -0800 Archived-At: Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-launchphase-04.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: Fri, 27 Feb 2015 15:15:20 -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 : Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Authors : James Gould Wil Tan Gavin Brown Filename : draft-ietf-eppext-launchphase-04.txt Pages : 60 Date : 2015-02-27 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-launchphase/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-launchphase-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-launchphase-04 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 Fri Feb 27 07:25:34 2015 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 5FD621A01AE for ; Fri, 27 Feb 2015 07:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Sgolr8HwRQmL for ; Fri, 27 Feb 2015 07:25:28 -0800 (PST) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6501A01A5 for ; Fri, 27 Feb 2015 07:25:28 -0800 (PST) Received: by mail-qg0-f97.google.com with SMTP id e89so326494qgf.0 for ; Fri, 27 Feb 2015 07:25:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type :mime-version; bh=Djr7hP5xExn43MaaN4p/yP1Nwh/LnX3QamL1TuKoeK0=; b=ZpnN2/B53EJ3ajQZh98LCTjXWuAHi/CZ7VWaeWKV3dlEsDGl3yvpdj6MlTZvtseTeK 5cEFMQUK6tBTbOACFNlB2sAbT6MlYd9w3mhQaXHlbCtZ1tUswOFZTB0dihKNEDz+3+Ew DX1LQFTzyLYA1GR7g5ABf1bZ9uakgT4ifsYyS64OMPTVJwF+i+tz6rfaH89AH/gXRvKl txixjSV30OttjJP9pwowOmVPNFJUFv2h/5dB6555zJQbseE3ieDkhLCOcJ9m0pK6qHOS Rk04YQw/iWnjjfbt/PQYtnElXMqaVq5PYmZZiJ08GQ+lRxQKQQw/4bv7NAVVuJxt/ioM rYiA== X-Gm-Message-State: ALoCoQkb/GPK3TU/YlV/MTo2FSYXYwfkLDFJyB3x4pV9nokqKMQbMRlDzq8r+Pwhqg5VnpQ4Qc+1gNSyhtNsNfTzOcoMWRqyYA== X-Received: by 10.229.71.69 with SMTP id g5mr30114768qcj.7.1425050727815; Fri, 27 Feb 2015 07:25:27 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id gt4sm1006492qcb.3.2015.02.27.07.25.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 27 Feb 2015 07:25:27 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t1RFPQwR015365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Feb 2015 10:25:26 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 27 Feb 2015 10:25:25 -0500 From: "Gould, James" To: "eppext@ietf.org" , EPP Provreg , "tmch-tech@icann.org" , "gtld-tech@icann.org" Thread-Topic: draft-ietf-eppext-launchphase-04 Posted Thread-Index: AQHQUqGb4VXK9LkxzUu++7MPil311g== Date: Fri, 27 Feb 2015 15:25:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_B4040F94702D427CAF311C3662DDBB8Fverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [eppext] draft-ietf-eppext-launchphase-04 Posted 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 Feb 2015 15:25:31 -0000 --_004_B4040F94702D427CAF311C3662DDBB8Fverisigncom_ Content-Type: multipart/alternative; boundary="_000_B4040F94702D427CAF311C3662DDBB8Fverisigncom_" --_000_B4040F94702D427CAF311C3662DDBB8Fverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, The fifth draft of draft-ietf-eppext-launchphase (draft-ietf-eppext-launchp= hase-04) was posted to the IETF to include the EPP Extension Registry secti= on under the IANA Considerations. This draft is ready for Working Group La= st Call by the EPPEXT Working Group. I support draft-ietf-eppext-tmch-smd = moving to Working Group Last Call as well. The following is the draft info= rmation: URL: https://tools.ietf.org/id/draft-ietf-eppext-launchphase-04.= txt Status: https://datatracker.ietf.org/doc/draft-ietf-eppext-launchph= ase/ Htmlized: https://tools.ietf.org/html/draft-ietf-eppext-launchphase-0= 4 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eppext-launch= phase-04 The following is a description of the changes from draft-ietf-eppext-launch= phase-03 to draft-ietf-eppext-launchphase-04: 1. Amended XML Namespace section of IANA Considerations, added EPP Extension R= egistry section. Please review draft-ietf-eppext-launchphase-04 and post any issues to the e= ppext mailing list. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_B4040F94702D427CAF311C3662DDBB8Fverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9944B6E7F6EB18439FC84D8AB7CA4FFC@verisign.com> Content-Transfer-Encoding: quoted-printable All,

The fifth draft of draft-ietf-eppext-launchphase (draft-ietf-eppext-la= unchphase-04) was posted to the IETF to include the EPP Extension Registry = section under the IANA Considerations.  This draft is ready for Workin= g Group Last Call by the EPPEXT Working Group.  I support draft-ietf-eppext-tmch-smd moving to Working Group = Last Call as well.  The following is the draft information:


The following is a description of the changes from draft-ietf-eppext-l= aunchphase-03 to draft-ietf-eppext-launchphase-04:   
  1. Amended XML Namespace section of IANA Considerations, added EPP Ex=
tension Registry section.
Please review draft-ietf-eppext-launchphase-04 and post any issues to = the eppext mailing list. 

Thanks,
    

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignI= nc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_B4040F94702D427CAF311C3662DDBB8Fverisigncom_-- --_004_B4040F94702D427CAF311C3662DDBB8Fverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 27 Feb 2015 15:25:15 GMT"; modification-date="Fri, 27 Feb 2015 15:25:15 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> 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_B4040F94702D427CAF311C3662DDBB8Fverisigncom_-- From nobody Fri Feb 27 07:31:21 2015 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 E6F171A01A5 for ; Fri, 27 Feb 2015 07:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.485 X-Spam-Level: * X-Spam-Status: No, score=1.485 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tpx98sqsFtDJ for ; Fri, 27 Feb 2015 07:31:18 -0800 (PST) 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 E751E1A00FB for ; Fri, 27 Feb 2015 07:31:17 -0800 (PST) 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:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version; bh=NH/LYArXmG+gIr0i2vF/7p12nUw+WsGX+DftqOyMMYU=; b=5ROPoVJTiEjtwz59gw4asH2/KIACUFfEGDu7D7vAmdvUZPHdYz5Ll+WwPNFXw01PSaSVb+UVALLfqlRK81VBy5DMSRAgsPg9GwPpt9sjGVJqZb4P6rsmYNStAUJOEj+ePIbiFaAhBEkLF8NTCzwh2NteqEBCrgZvboZtEhx6lUr/jcvVRC5xlsisb2zcUTKr7BnCLX2joTeAKQ47ROEbGbd3yZrOIvh5Ss8maR9oql5h4bO8uqmyt4mpOAn7FRo4FY9LaphCYynqG0glZ9KDPXhaR1B+tIn975slAjbAAff+O2jM2hY4/7E5uREicdGAa4A0PLBpxY3i0U9+kjBCyg== Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t1RFVGUC029683-t1RFVGUE029683 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Fri, 27 Feb 2015 16:31:16 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0224.002; Fri, 27 Feb 2015 16:31:12 +0100 From: Rik Ribbers To: "eppext@ietf.org" Thread-Topic: keyrelay Thread-Index: AdBSnx272/YvP91BSD+PPZAC0ramcw== Date: Fri, 27 Feb 2015 15:31:11 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.153] Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B9351218kambx2SIDNlocal_" MIME-Version: 1.0 Archived-At: Subject: [eppext] keyrelay 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 Feb 2015 15:31:20 -0000 --_000_C80127C588F8F2409E2B535AF968B768B9351218kambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'd like to inform you that we had a lot of off mailing list discussion on = how to proceed with the keyrelay draft. The short version is that we wish t= o proceed with the standards track and that we accept the advice of the WG = to go with Jim Gould's proposal on the xml structure for keyrelay. However given the time constraint on our daily activities we cannot update = the document before the next IETF meeting. We have planned to publish a ne= w version by the end of April. Kind regards, Rik Ribbers --_000_C80127C588F8F2409E2B535AF968B768B9351218kambx2SIDNlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I’d like to inform you th= at we had a lot of off mailing list discussion on how to proceed with the k= eyrelay draft. The short version is that we wish to proceed with the standa= rds track and that we accept the advice of the WG to go with Jim Gould’s proposal on the xml structure for keyr= elay.

 

However given the time constrai= nt on our daily activities we cannot update the document before the next IE= TF meeting. We have planned  to publish a new version by the end of Ap= ril.

 

Kind regards,=

Rik Ribbers <= /p>

 

 

--_000_C80127C588F8F2409E2B535AF968B768B9351218kambx2SIDNlocal_--