Francisco,

I have the following issues with&nbs= p;draft-ietf-eppext-idnmap that I would like addressed:

The <idn:uname> should be optional in the info response.
The <idn:table> is too flexible at this point. Based on&= nbsp;draft-ietf-eppext-idnmap the registrars have no way of knowing what ta= ble values are required for any one server. This is a opportunity for= the eppext WG to define a standard model.

My concern is related to clients hav= ing to deal with an infinite number of server policies and schemes for the = <idn:table> values. Are there any registrars out there that hav= e the same concern?

James Gould

Principal Software Engineer

jgould@verisign.com

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

On 3/11/1= 4, 12:04 AM, "Francisco Obispo" <fobispo@uniregistry.com> wrote:

This is a complicated problem to solve. It was one of the reasons why = we switched to =93table=94 from =93language=94.

Defining what can be registered or not is a server policy issue that t= he only way we could solve it is by passing an identifier. In fact in our r= egistry we have created a set of identifiers to match certain language =93t= ags=94, but the component that we wrote for our database can support multiple tables with a specific name, so we c= an support things like =93com-es=94, =93com-it=94, etc. if needed.

I would really like to standardize it, but it=92s beyond the purpose o= f this extension.

Also on the server language/table discovery issue, what if a name matc= hes multiple tables? what if multiple tables had different registration pol= icies? We decided to keep it simple, and the table must be passed along by = the registrar which at the end, shows the intent of the registration and its associated policy to be appli= ed.

Thanks for feedback again!

On Mar 10, 2014, at 2:26 PM, Gould, James <JGould@verisign.com> wrote:

My main concern requiring the client to specify server specific table<= /div>
identifiers that are not standardized. I prefer sticking wi= th a standard

identifier like language and leave the mapping to language or script
tables up to the server.

--

Francisco Obispo

CTO - Registry Operations

fobispo@uniregistry.com=

PGP Key ID: 0xB38DB1BE

--_000_CF44B7D259768jgouldverisigncom_-- From nobody Wed Mar 12 19:52:02 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7900F1A087D for ; Wed, 12 Mar 2014 19:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWTxsaZN5NlW for ; Wed, 12 Mar 2014 19:52:00 -0700 (PDT) Received: from mail.hostingnet.com (mail.hostingnet.com [208.87.35.115]) by ietfa.amsl.com (Postfix) with ESMTP id E50471A0881 for ; Wed, 12 Mar 2014 19:51:59 -0700 (PDT) Received: from [10.0.1.15] (ip72-211-217-143.oc.oc.cox.net [72.211.217.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fobispo@uniregistry.com) by mail.hostingnet.com (Postfix) with ESMTPSA id 8406644CDDF; Wed, 12 Mar 2014 19:51:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 $1874$) From: Francisco Obispo In-Reply-To: Date: Wed, 12 Mar 2014 19:51:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Gould, James" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/iFOGONEGGd99Ak9TBbj1iCKDzpk Cc: "eppext@ietf.org" , =?windows-1252?Q?Luis_Mu=F1oz?= Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 02:52:01 -0000 On Mar 11, 2014, at 10:02 AM, Gould, James wrote: > Francisco, >=20 > I have the following issues with draft-ietf-eppext-idnmap that I would = like addressed: >=20 > =95 The should be optional in the info response.=20 We can make it optional. I=92ll add that to the next draft. =20 >=20 > =95 The is too flexible at this point. Based on = draft-ietf-eppext-idnmap the registrars have no way of knowing what = table values are required for any one server. This is a opportunity for = the eppext WG to define a standard model. =20 > My concern is related to clients having to deal with an infinite = number of server policies and schemes for the values. Are = there any registrars out there that have the same concern? >=20 Well registrars currently don=92t have a way of knowing a lot of things, = and even though I agree with you on the identifiers, there is no = guarantee that the same identifier will result in the same code points, = because that=92s a registry policy decision. I don=92t want to create the impression that if you pass =93es=94 as the = table identifier, you=92ll get the same results across all registries, = in fact if you look at the tables on the IANA website, multiple = registries have different identifiers, and in some cases the code points = don=92t even match.=20 So even though I agree with you in concept, I think that it is = unpractical to try to standardize it. Francisco -- Francisco Obispo CTO - Registry Operations fobispo@uniregistry.com PGP Key ID: 0xB38DB1BE =20 From nobody Thu Mar 13 02:39:39 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1221A0928 for ; Thu, 13 Mar 2014 02:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.547, 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 y5f5zE3EL4Zx for ; Thu, 13 Mar 2014 02:39:35 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6E71A090B for ; Thu, 13 Mar 2014 02:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=AmPovojEY51edRmFEItcZiwgTRpRqYPbt5X2xyvrOVw=; b=jtYOkzbYBw3o3zYCXKbsNmz0Y83TZxxQexvOQAXLGjILx6be38e4wpdXxhaU04hLjLK01/nR4K3AcAOtkVT95r6PGT7nisEaS4xcZB3XT8Vwm2z0Aa7/xx8AvBvwCa1DPFPf/yphQehTnbNLbFYwr5EbVX6IT2EHVQE+XoHdOjY= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id s2D9dShS018749-s2D9dShU018749 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL); Thu, 13 Mar 2014 10:39:28 +0100 Received: from [94.198.152.214] (94.198.152.214) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 13 Mar 2014 10:39:23 +0100 Message-ID: <53217CCB.4060908@sidn.nl> Date: Thu, 13 Mar 2014 10:39:23 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Gould, James" , "eppext@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.152.214] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/i9MImdSnQlczhsGOfx_GWERGlJw Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 09:39:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 11-03-14 17:36, Gould, James schreef: Hi James, Thanks for your suggestions. We have particularly looked at: > 2. Create a Command-Response Extension of the domain mapping that > creates a new keyrelay verb similar to the restore verb in RFC > 3915, which is an extension of an empty domain update. The server > can define who is authorized to invoke the new verb on the domain > name. > > By defining Key Relay as a new object or a new verb extension to > the domain object, you get all of the advantages of an object > mapping (extensions, client and server transaction identifier). > My recommendation is to go with option #2, since I view Key Relay > as a verb. In summary, I don�t believe there is the need to create > a protocol extension for this. One of the requirements from certain registries for keyrelay was that since keyrelay is only a "preparation communication step" for a DNS operator change that may or may not be followed by an NS change or combined transfer/NS change, they did not want any changes made to records owned by the registrar of record for a domain object. It's not compulsory to do this "communication" via the registry, it only facilitates registrars that have no other secure communication channel. Sometimes a keyrelay command is not followed by an NS change as the process is abandoned, and that should not lead to changes in the DB that need to be reverted. The process would then become more complex than necessary. Another requirement that we heard from especially gTLD registries is that a command for which it was necessary to change the database tables in a fundamental way would not be implemented by those registries. Since most EPP commands are processes that change an object in the registry DB and is only authorized by the current registrar of record, we looked at a way to do this communication step without even touching the DB. EPP keyrelay can be implemented without any changes to the registry DB, and only queries existing records. This is also how we implemented it. We only know of one other command that is NOT authorized by the current registrar of record for a domain object, and that is a transfer. But if authorized properly by an auth-info token, the goal of a transfer command is ultimately also to make changes to the domain object in the DB. Keyrelay does not intend to change anything to DB objects. That is ultimately done by an NS change that usually follows a keyrelay if the process is continued AND the loosing DNS operator cooperates. If the loosing DNS operator does not cooperate, a different change to the DB may follow, and it's complex to predict which action would follow. There is no default process flow, it's up to the gaining registrar which next step to take (Abandon, postpone, go insecure, transfer and leave delegation as is, ...), we want him to be in control. Could you elaberate on how a Command-Response Extension of the domain mapping would meet the requirement of not changing anything fundamental to the registry DB, nor creating a complex unpredictable state flow? How would the State Diagram similar to Figure 1 of RFC3915 look like for EPP keyrelay? Bear in mind, that a pending NS change state for a secure transfer cannot be held forever, nor can it be predicted what a reasonable period for that state is. It depends on DNS TTL values that are not prescribed nor verified in most registry policies. And since we want the registrant to be in control over his domain, it may well be that during a pending state, yet another registrar may invoke a keyrelay if the registrant chooses to change registrars because the process takes too long or there is another (technical) reason to change his delegation. So a state diagram is much more difficult to create than a state diagram for a grace period that is only dependent on 1 registrar and a state period defined by the registry's policy. By completely separating the "preparation communication" from the state of a domain object, we have avoided the need for a complex state diagram and fundamental changes to the registry DB. It also extends EPP with a new command type that may have other benefits in the future. For an (even more) elaborate explanation on how we came to this conclusion, we have written a white paper: https://www.sidnlabs.nl/uploads/tx_sidnpublications/wp_2013_EPP-keyrelay_v1.en.pdf > On 3/11/14, 9:23 AM, "Antoin Verschuren" > > > wrote: > > Hi, > > I'd like to answer the question asked in London why EPP keyrelay > is not an object extension or domain update. > > Regular EPP commands are submitted to a registry by the current > registrar of record for that object in the database. Only the > registrar of record is allowed to change attributes to a domain > object. > > EPP keyrelay is a command that typically is sent to a registry by > a registrar NOT being the registrar of record for that domain > object. So the registrar sending the command is not permitted to > change anything in the database to that object. > > EPP keyrelay is therefor only a communication command, and the > domain object is only used to identify the registrar of record for > that domain object as a recipient. The domain object is only > queried to identify the registrar of record, but no attributes are > allowed to be changed. > > Hope that clarifies the questions raised in London. > > > _______________________________________________ EppExt mailing > list EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTIXzKAAoJEDqHrM883AgnH/sIAKYi48zCXAmWXaNjBc+Jik22 /90SrAeV2E3nG9A3FvaM0+0F6lHH9oiKVNzveYD8E6+9pojOdw++scRENqAOuseh 0cE3XjvAZh6EQAt2HDKv4Be/LyX5ZnJR8iorecMSl8M0BGQhu7/EDZwD31gFe3kw ac5ePOijelbte4vIb1gN3WjqWbUjbavMJVxt7hQwL75km0uS3WUGdpo0YwKg3Xan zjSB/2G7tv0KDVoBIMsKnmTWoR38s4aEXTpdZqq1hJUDIwnwdvHwzbJjRq9a9yKV Hy3+KJfXZvGIPsiHQZBHLyY3vNJJnA3kKCRO7U7twOiBL5WLPyvaqEhscuJqbRs= =Xyh/ -----END PGP SIGNATURE----- From nobody Thu Mar 13 07:16:51 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021F11A09AA for ; Thu, 13 Mar 2014 07:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ENOvx-wA0kV for ; Thu, 13 Mar 2014 07:16:34 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE671A098A for ; Thu, 13 Mar 2014 07:16:34 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUyG9ukW0wIoOXNmPdQ0o1PiX2hcmiKie@postini.com; Thu, 13 Mar 2014 07:16:28 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s2DEGPAc005229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 10:16:25 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 10:16:25 -0400 From: "Gould, James" To: Francisco Obispo Thread-Topic: [eppext] draft-ietf-eppext-idnmap Feedback Thread-Index: AQHPOlT+4eaYxDDdEE+oj57oox5INZrbCyoA///O6wCAALJlAIAAlk4AgAJ59gCAAHwvAA== Date: Thu, 13 Mar 2014 14:16:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CF471A9759CD2jgouldverisigncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/6vgoUkzvtNgPa9KkOYIncvyPJYQ Cc: "eppext@ietf.org" , =?Windows-1252?Q?Luis_Mu=F1oz?= Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 14:16:42 -0000 --_000_CF471A9759CD2jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Francisco, How about supporting two models in draft-ietf-eppext-idnmap that matches th= e current and desired models supported by the servers, which is to support = a choice of language or table? The table element is intended to be a 1-to-= 1 match with the language or script tables posted to IANA and language is t= he language code per ISO 639-2. Ideally the choice would be explicitly def= ined in the XML schema, but to minimize the changes, it could look like bel= ow: Extensible Provisioning Protocol v1.0 domain name extension schema for IDN Table selection. The text for the create could specify the use of either or <= idn:table> element based on server policy. Ideally a element= would be defined in the XML schema that made and a choice. Below is an example of the create with the language: xn--espaol-zwa.example.com 2 ns1.example.net ns2.example.net jd1234 sh8013 sh8013 2fooBAR SPA español.example.com 123456 Below is an example of the create with the table (script table in this inst= ance that can be prefixed with http://www.iana.org/domains/idn-tables/ and = postfixed with .txt): xn--espaol-zwa.example.com 2 ns1.example.net ns2.example.net jd1234 sh8013 sh8013 2fooBAR com_latn_1.1 español.example.com 123456 For servers that support the language model, the info response should retur= n both the language sent as well as the resulting table that can be mapped = to the IANA language or script table: Command completed successfully xn--espaol-zwa.example.com EXAMPLE1-REP jd1234 sh8013 sh8013 ns1.example.com ns1.example.net ClientX ClientY 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2005-04-03T22:00:00.0Z 2000-04-08T09:00:00.0Z 2fooBAR SPA com_latn_1.1 español.example.com ABC-12345 54322-XYZ -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/12/14, 10:51 PM, "Francisco Obispo" > wrote: On Mar 11, 2014, at 10:02 AM, Gould, James > wrote: Francisco, I have the following issues with draft-ietf-eppext-idnmap that I would like= addressed: =95 The should be optional in the info response. We can make it optional. I=92ll add that to the next draft. =95 The is too flexible at this point. Based on draft-ietf-epp= ext-idnmap the registrars have no way of knowing what table values are requ= ired for any one server. This is a opportunity for the eppext WG to define= a standard model. My concern is related to clients having to deal with an infinite number of = server policies and schemes for the values. Are there any regi= strars out there that have the same concern? Well registrars currently don=92t have a way of knowing a lot of things, an= d even though I agree with you on the identifiers, there is no guarantee th= at the same identifier will result in the same code points, because that=92= s a registry policy decision. I don=92t want to create the impression that if you pass =93es=94 as the ta= ble identifier, you=92ll get the same results across all registries, in fac= t if you look at the tables on the IANA website, multiple registries have d= ifferent identifiers, and in some cases the code points don=92t even match. So even though I agree with you in concept, I think that it is unpractical = to try to standardize it. Francisco -- Francisco Obispo CTO - Registry Operations fobispo@uniregistry.com PGP Key ID: 0xB38DB1BE --_000_CF471A9759CD2jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <04012EACAC98BA41BA9B38B67C15AAE6@verisign.com> Content-Transfer-Encoding: quoted-printable

Francisco,

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

<?xml version=3D"1= .0" encoding=3D"UTF-8"?>

<schema xmlns=3D"h= ttp://www.w3.org/2001/XMLSchema"

xmlns:eppcom=3D"urn:ietf:p= arams:xml:ns:eppcom-1.0"

xmlns:idn=3D"urn:ietf:para= ms:xml:ns:idn-1.0"

targetNamespace=3D"urn:iet= f:params:xml:ns:idn-1.0"

elementFormDefault=3D"qual= ified">

Extensible Provisioning Protocol v1.0= domain name extension

schema for IDN Table selection.

</documentation>

</annotation>=

<import namespac= e=3D"urn:ietf:params:xml:ns:eppcom-1.0"

schemaLocation=3D"eppcom-1.0.xsd= "/>

<element name=3D"language&= quot; type=3D"language"

minOccurs=3D"0&= quot;/>

<element name=3D"table&quo= t; type=3D"eppcom:minTokenType"

minOccurs=3D"0&= quot;/>

<element name=3D"uname" = type=3D"eppcom:labelType"

minOccurs=3D"= ;0"/>

</sequence>

</complexType>

</schema>

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

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

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>

<domain:create

xmlns:domain=3D"urn:ietf:params:xml:ns= :domain-1.0">

<domain:name>xn--espaol-zwa.example.com</= domain:name>

<domain:period unit=3D"y">2</do= main:period>

<domain:ns>

<domain:hostObj>ns1.example.net</d= omain:hostObj>

<domain:hostObj>ns2.example.net</d= omain:hostObj>

</domain:ns>

<domain:registrant>jd1234</domain:registr= ant>

<domain:contact type=3D"admin">sh8= 013</domain:contact>

<domain:contact type=3D"tech">sh80= 13</domain:contact>

<domain:authInfo>

<domain:pw>2fooBAR</domain:pw><= /div>

</domain:authInfo>

</domain:create>

</create>

<idn:data xmlns:idn=3D"urn:ietf:params:xml:ns:idn= -1.0">

<idn:language>SPA</idn:language>

<idn:uname>español.example.com<= /idn:uname>

</idn:data>

</extension>

<clTRID>123456</clTRID>

</command>

</epp>

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

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">

<command>

<create>

<domain:create

xmlns:domain=3D"urn:ietf:params:xml:ns= :domain-1.0">

<domain:name>xn--espaol-zwa.example.com</= domain:name>

<domain:period unit=3D"y">2</do= main:period>

<domain:ns>

<domain:hostObj>ns1.example.net</d= omain:hostObj>

<domain:hostObj>ns2.example.net</d= omain:hostObj>

</domain:ns>

<domain:registrant>jd1234</domain:registr= ant>

<domain:contact type=3D"admin">sh8= 013</domain:contact>

<domain:contact type=3D"tech">sh80= 13</domain:contact>

<domain:authInfo>

<domain:pw>2fooBAR</domain:pw><= /div>
</domain:authInfo>

</domain:create>

</create>

<extension>

<idn:data xmlns:idn=3D"urn:ietf:params:xml:ns:idn= -1.0">

<idn:table>com_latn_1.1</idn:table>= ;

<idn:uname>español.example.com<= /idn:uname>

</idn:data>

</extension>

<clTRID>123456</clTRID>

</command>

</epp>

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

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">

<response>

<result code=3D"1000">

<msg>Command completed successfully</msg= >

</result>

<resData>

<domain:infData

xmlns:domain=3D"urn:ietf:params:xml:ns= :domain-1.0">

<domain:name>xn--espaol-zwa.example.= com</domain:name>

<domain:roid>EXAMPLE1-REP</domain= :roid>

<domain:status s=3D"ok"/><= /div>
<domain:registrant>jd1234</domain= :registrant>

<domain:contact type=3D"admin"= ;>sh8013</domain:contact>

<domain:contact type=3D"tech"= >sh8013</domain:contact>

<domain:ns>

<domain:hostObj>ns1.example.c= om</domain:hostObj>

<domain:hostObj>ns1.example.n= et</domain:hostObj>

</domain:ns>

<domain:clID>ClientX</domain:clID= >

<domain:crID>ClientY</domain:crID= >

<domain:crDate>1999-04-03T22:00:00.0= Z</domain:crDate>

<domain:upID>ClientX</domain:upID= >

<domain:upDate>1999-12-03T09:00:00.0= Z</domain:upDate>

<domain:exDate>2005-04-03T22:00:00.0= Z</domain:exDate>

<domain:trDate>2000-04-08T09:00:00.0= Z</domain:trDate>

<domain:authInfo>

<domain:pw>2fooBAR</domain= :pw>

</domain:authInfo>

</domain:infData>

</resData>

<extension>

<idn:data xmlns:idn=3D"urn:ietf:params:xm= l:ns:idn-1.0">

<idn:language>SPA</idn:languag= e>

<idn:table>com_latn_1.1</idn:t= able>

<idn:uname>español.example.= com</idn:uname>

</idn:data>

</extension>

<trID>

<clTRID>ABC-12345</clTRID>

<svTRID>54322-XYZ</svTRID>

</trID>

</response>

</epp>

--

JG

James Gould

Principal Software Engineer

jgould@verisign.com

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

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

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

Francisco,

I have the following issues with draft-ietf-eppext-idnmap that I would= like addressed:

=95 Th= e <idn:uname> should be optional in the info response.

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

=95 Th= e <idn:table> is too flexible at this point.  Based on draf= t-ietf-eppext-idnmap the registrars have no way of knowing what table value= s are required for any one server.  This is a opportunity for the eppext WG to define a standard model.

My concern is related to clients having to deal with an infinite numbe= r of server policies and schemes for the <idn:table> values. &nb= sp;Are there any registrars out there that have the same concern?

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

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

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

Francisco

--

Francisco Obispo

CTO - Registry Operations

fobispo@uniregistry.com=

PGP Key ID: 0xB38DB1BE

--_000_CF471A9759CD2jgouldverisigncom_-- From nobody Thu Mar 13 10:53:22 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA921A0A23 for ; Thu, 13 Mar 2014 10:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TRACKER_ID=1.306] 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 dDIscVHQX7fq for ; Thu, 13 Mar 2014 10:53:14 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD5B1A0A43 for ; Thu, 13 Mar 2014 10:53:08 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUyHwfTgKBbCYBbcDFfzgvtWjHQCsB6Go@postini.com; Thu, 13 Mar 2014 10:53:04 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s2DHqwTD003574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 13:53:01 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 13:52:58 -0400 From: "Gould, James" To: Antoin Verschuren , "eppext@ietf.org" Thread-Topic: [eppext] draft-ietf-eppext-keyrelay-00 Feedback Thread-Index: AQHPPTZwhTqnVBiC0UudESqSbZQK05rcFYQAgALzWICAAEbDgA== Date: Thu, 13 Mar 2014 17:52:57 +0000 Message-ID: In-Reply-To: <53217CCB.4060908@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CF47367659EADjgouldverisigncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/tDLxtA3GfOgZn2CKJOtBbjYCaVc Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:53:20 -0000 --_000_CF47367659EADjgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Antoin, Thanks for the detailed explanation. The choice of which form of EPP exten= sion to use (protocol, object, command-response) does not change the proces= s flow at all, but simply determines the syntax of the key relay commands a= nd responses. Technically draft-ietf-eppext-keyrelay uses both the protoco= l extension for the command and the object extension for the poll response.= My recommendation is to get down to one type of extension for the specifi= cation. The best way to describe the use of the object and command-respon= se extensions is to provide some examples, which I do below: Command-Response Extension: Key Relay Command as extension to empty domain update similar to the restor= e command in RFC 3915. To note this is a new verb that is not mixed with t= he update from a feature and authorization perspective. example.org example.org 256 3 8 cmlraXN0aGViZXN0 JnSdBAZSxxzJ P1M13D ABC-12345-XYZ Key Relay Poll Response as an extension to the domain info response. Command completed successfully; ack to dequeue 1999-04-04T22:01:00.0Z Key Relay action completed successfully. example.org EXAMPLE1-REP ClientX example.org 1999-04-04T22:01:00.0Z 256 3 8 cmlraXN0aGViZXN0 JnSdBAZSxxzJ P24D ClientX ClientY ABC-12345 54321-XYZ Object Extension: Key Relay is an object that can be created via the create command and can g= et information via the info command and response. The poll message is simp= ly a key relay info response. Key Relay Command using a Key Relay Create Command. example.org 256 3 8 cmlraXN0aGViZXN0 JnSdBAZSxxzJ P1M13D 123456 Key Relay Poll Response Command completed successfully; ack to dequeue 1999-04-04T22:01:00.0Z Key Relay action completed successfully. example.org 1999-04-04T22:01:00.0Z 256 3 8 cmlraXN0aGViZXN0 JnSdBAZSxxzJ P24D ClientX ClientY BCD-23456 65432-WXY In addition, support can be provided for the Relay Info Command and associa= ted Response (example provided already with the poll response). example.org 123456 In looking at the samples, I actually like the Object Extension the best. = I can provide the XSD=92s that I validated the examples against if desired. Thanks, -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/13/14, 5:39 AM, "Antoin Verschuren" > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 11-03-14 17:36, Gould, James schreef: Hi James, Thanks for your suggestions. We have particularly looked at: 2. Create a Command-Response Extension of the domain mapping that creates a new keyrelay verb similar to the restore verb in RFC 3915, which is an extension of an empty domain update. The server can define who is authorized to invoke the new verb on the domain name. By defining Key Relay as a new object or a new verb extension to the domain object, you get all of the advantages of an object mapping (extensions, client and server transaction identifier). My recommendation is to go with option #2, since I view Key Relay as a verb. In summary, I don=92t believe there is the need to create a protocol extension for this. One of the requirements from certain registries for keyrelay was that since keyrelay is only a "preparation communication step" for a DNS operator change that may or may not be followed by an NS change or combined transfer/NS change, they did not want any changes made to records owned by the registrar of record for a domain object. It's not compulsory to do this "communication" via the registry, it only facilitates registrars that have no other secure communication channel. Sometimes a keyrelay command is not followed by an NS change as the process is abandoned, and that should not lead to changes in the DB that need to be reverted. The process would then become more complex than necessary. Another requirement that we heard from especially gTLD registries is that a command for which it was necessary to change the database tables in a fundamental way would not be implemented by those registries. Since most EPP commands are processes that change an object in the registry DB and is only authorized by the current registrar of record, we looked at a way to do this communication step without even touching the DB. EPP keyrelay can be implemented without any changes to the registry DB, and only queries existing records. This is also how we implemented it. We only know of one other command that is NOT authorized by the current registrar of record for a domain object, and that is a transfer. But if authorized properly by an auth-info token, the goal of a transfer command is ultimately also to make changes to the domain object in the DB. Keyrelay does not intend to change anything to DB objects. That is ultimately done by an NS change that usually follows a keyrelay if the process is continued AND the loosing DNS operator cooperates. If the loosing DNS operator does not cooperate, a different change to the DB may follow, and it's complex to predict which action would follow. There is no default process flow, it's up to the gaining registrar which next step to take (Abandon, postpone, go insecure, transfer and leave delegation as is, ...), we want him to be in control. Could you elaberate on how a Command-Response Extension of the domain mapping would meet the requirement of not changing anything fundamental to the registry DB, nor creating a complex unpredictable state flow? How would the State Diagram similar to Figure 1 of RFC3915 look like for EPP keyrelay? Bear in mind, that a pending NS change state for a secure transfer cannot be held forever, nor can it be predicted what a reasonable period for that state is. It depends on DNS TTL values that are not prescribed nor verified in most registry policies. And since we want the registrant to be in control over his domain, it may well be that during a pending state, yet another registrar may invoke a keyrelay if the registrant chooses to change registrars because the process takes too long or there is another (technical) reason to change his delegation. So a state diagram is much more difficult to create than a state diagram for a grace period that is only dependent on 1 registrar and a state period defined by the registry's policy. By completely separating the "preparation communication" from the state of a domain object, we have avoided the need for a complex state diagram and fundamental changes to the registry DB. It also extends EPP with a new command type that may have other benefits in the future. For an (even more) elaborate explanation on how we came to this conclusion, we have written a white paper: https://www.sidnlabs.nl/uploads/tx_sidnpublications/wp_2013_EPP-keyrelay_v1= .en.pdf On 3/11/14, 9:23 AM, "Antoin Verschuren" > wrote: Hi, I'd like to answer the question asked in London why EPP keyrelay is not an object extension or domain update. Regular EPP commands are submitted to a registry by the current registrar of record for that object in the database. Only the registrar of record is allowed to change attributes to a domain object. EPP keyrelay is a command that typically is sent to a registry by a registrar NOT being the registrar of record for that domain object. So the registrar sending the command is not permitted to change anything in the database to that object. EPP keyrelay is therefor only a communication command, and the domain object is only used to identify the registrar of record for that domain object as a recipient. The domain object is only queried to identify the registrar of record, but no attributes are allowed to be changed. Hope that clarifies the questions raised in London. _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTIXzKAAoJEDqHrM883AgnH/sIAKYi48zCXAmWXaNjBc+Jik22 /90SrAeV2E3nG9A3FvaM0+0F6lHH9oiKVNzveYD8E6+9pojOdw++scRENqAOuseh 0cE3XjvAZh6EQAt2HDKv4Be/LyX5ZnJR8iorecMSl8M0BGQhu7/EDZwD31gFe3kw ac5ePOijelbte4vIb1gN3WjqWbUjbavMJVxt7hQwL75km0uS3WUGdpo0YwKg3Xan zjSB/2G7tv0KDVoBIMsKnmTWoR38s4aEXTpdZqq1hJUDIwnwdvHwzbJjRq9a9yKV Hy3+KJfXZvGIPsiHQZBHLyY3vNJJnA3kKCRO7U7twOiBL5WLPyvaqEhscuJqbRs=3D =3DXyh/ -----END PGP SIGNATURE----- --_000_CF47367659EADjgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Antoin,

Thanks for the detailed explanation. The choice of which form of= EPP extension to use (protocol, object, command-response) does not change = the process flow at all, but simply determines the syntax of the key r= elay commands and responses. Technically draft-ietf-eppext-keyrelay uses both the protocol extension for the comman= d and the object extension for the poll response. My recommendation i= s to get down to one type of extension for the specification. The be= st way to describe the use of the object and command-response extensions is to provide some examples, which I do b= elow:

Command-Response Extension:

Key Relay Command as extension to empty domain update similar to th= e restore command in RFC 3915. To note this is a new verb that is not= mixed with the update from a feature and authorization perspective.

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"

xmlns:secDNS=3D"urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"
xmlns:keyrelay=3D"urn:ietf:params:xml:ns:keyrelay-1.0">= ;

<command>

<update>

<domain:update>

<domain:name>example.org</domain:name= >

</domain:update>

</update>

<extension>

<keyrelay:keyrelay>

<keyrelay:name>example.org</keyrelay:= name>

<keyrelay:keyData>

<secDNS:flags>256</secDN= S:flags>

<secDNS:protocol>3</secD= NS:protocol>

<secDNS:alg>8</secDNS:al= g>

<secDNS:pubKey>cmlraXN0aGVi= ZXN0</secDNS:pubKey>

</keyrelay:keyData>

<keyrelay:authInfo>

<domain:pw>JnSdBAZSxxzJ<= /domain:pw>

</keyrelay:authInfo>

<keyrelay:expiry>

<keyrelay:relative>P1M13D&l= t;/keyrelay:relative>

</keyrelay:expiry>

</keyrelay:keyrelay>

</extension>

<clTRID>ABC-12345-XYZ</clTRID>

</command>

</epp>

Key Relay Poll Response as an extension to the domain info res= ponse.

<?xml version=3D"1.0" encoding=3D"UTF-8"?>

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"

xmlns:secDNS=3D"urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"
xmlns:keyrelay=3D"urn:ietf:params:xml:ns:keyrelay-1.0">= ;

<response>

<result code=3D"1301">

<msg>Command completed successfully; ack = to dequeue</msg>

</result>

<msgQ count=3D"5" id=3D"12345">
<qDate>1999-04-04T22:01:00.0Z</qDate&g= t;

<msg>Key Relay action completed successfu= lly.</msg>

</msgQ>

<resData>

<domain:infData

xmlns:domain=3D"urn:ietf:params:xml:ns:do= main-1.0">

<domain:name>example.org</domain:name= >

<domain:roid>EXAMPLE1-REP</domain:roi= d>

<domain:clID>ClientX</domain:clID>=

</domain:infData>
</resData>

<extension>

<= ;keyrelay:panData>

<= ;keyrelay:name paResult=3D"true">example.org

<= ;/keyrelay:name>

<= ;keyrelay:paDate>1999-04-04T22:01:00.0Z

</keyrelay:= paDate>

<= ;keyrelay:keyData>

<secDNS:fla= gs>256</secDNS:flags>

<secDNS:pro= tocol>3</secDNS:protocol>

<= ;secDNS:alg>8</secDNS:alg>

<= ;secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>

<= ;/keyrelay:keyData>

<= ;keyrelay:authInfo>

<= ;domain:pw>JnSdBAZSxxzJ</domain:pw>

<= ;/keyrelay:authInfo>

<= ;keyrelay:expiry>

<keyrelay:r= elative>P24D</keyrelay:relative>

<= ;/keyrelay:expiry>

<= ;keyrelay:reID>ClientX</keyrelay:reID>

<= ;keyrelay:acID>ClientY</keyrelay:acID>

<= ;/keyrelay:panData>

</extension>

<trID>

<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>

</response>

</epp>

Object Extension:

Key Relay is an object that can be created via the create command and = can get information via the info command and response. The poll messa= ge is simply a key relay info response.

Key Relay Command using a Key Relay Create Command.

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"

xmlns:secDNS=3D"urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"
xmlns:keyrelay=3D"urn:ietf:params:xml:ns:keyrelay-1.0"= ;>

<command>

<create>

<keyrelay:create>

<keyrelay:name>example.org</keyrel= ay:name>

<keyrelay:keyData>

<secDNS:flags>256</secDNS:= flags>

<secDNS:protocol>3</secDNS= :protocol>

<secDNS:alg>8</secDNS:alg&= gt;

<secDNS:pubKey>cmlraXN0aGViZX= N0</secDNS:pubKey>

</keyrelay:keyData>

<keyrelay:authInfo>

<domain:pw>JnSdBAZSxxzJ</d= omain:pw>

</keyrelay:authInfo>

<keyrelay:expiry>

<keyrelay:relative>P1M13D<= /keyrelay:relative>

</keyrelay:expiry>

</keyrelay:create>

</create>

<clTRID>123456</clTRID>

</command>

</epp>

Key Relay Poll Response

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"

xmlns:secDNS=3D"urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"
xmlns:keyrelay=3D"urn:ietf:params:xml:ns:keyrelay-1.0"= ;>

<response>

<result code=3D"1301">

<msg>Command completed successfully; = ack to dequeue</msg>

</result>

<msgQ count=3D"5" id=3D"12345">= ;

<qDate>1999-04-04T22:01:00.0Z</qDa= te>

<msg>Key Relay action completed succe= ssfully.</msg>

</msgQ>

<resData>

<keyrelay:infData>

<keyrelay:name paResult=3D"true&qu= ot;>example.org

</keyrelay:name>

<keyrelay:paDate>1999-04-04T22:01:00= .0Z

</keyrelay:paDate>

<keyrelay:keyData>

<secDNS:flags>256</secDNS:= flags>

<secDNS:protocol>3</secDNS= :protocol>

<secDNS:alg>8</secDNS:alg&= gt;

<secDNS:pubKey>cmlraXN0aGViZX= N0</secDNS:pubKey>

</keyrelay:keyData>

<keyrelay:authInfo>

<domain:pw>JnSdBAZSxxzJ</d= omain:pw>

</keyrelay:authInfo>

<keyrelay:expiry>

<keyrelay:relative>P24D</k= eyrelay:relative>

</keyrelay:expiry>

<keyrelay:reID>ClientX</keyrelay:= reID>

<keyrelay:acID>ClientY</keyrelay:= acID>

</keyrelay:infData>

</resData>

<trID>

<clTRID>BCD-23456</clTRID>
<svTRID>65432-WXY</svTRID>
</trID>

</response>

</epp>

In addition, support can be provided for the Relay Info Command and as= sociated Response (example provided already with the poll response). =

<?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"no"?>

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"

xmlns:keyrelay=3D"urn:ietf:params:xml:ns:keyrelay-1.0"= ;>

<command>

<info>

<keyrelay:info>

<keyrelay:name>example.org</keyrel= ay:name>

</keyrelay:info>

</info>

<clTRID>123456</clTRID>

</command>

</epp>

In looking at the samples, I actually like the Object Extension the be= st. I can provide the XSD=92s that I validated the examples against i= f desired.

Thanks,

--

JG

James Gould

Principal Software Engineer

jgould@verisign.com

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

On 3/13/1= 4, 5:39 AM, "Antoin Verschuren" <antoin.verschuren@sidn.nl> wrote:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

op 11-03-14 17:36, Gould, James schreef:

Hi James,

Thanks for your suggestions. We have particularly looked at:

2. Create a Command-Response Extension of the domain mapping that
creates a new keyrelay verb similar to the restore verb in RFC

3915, which is an extension of an empty domain update.  The = server

can define who is authorized to invoke the new verb on the domain
name.

By defining Key Relay as a new object or a new verb extension to

the domain object, you get all of the advantages of an object

mapping (extensions, client and server transaction identifier).

My recommendation is to go with option #2, since I view Key Relay
as a verb.  In summary, I don=92t believe there is the need = to create

a protocol extension for this.

One of the requirements from certain registries for keyrelay was that<= /div>
since keyrelay is only a "preparation communication step" fo= r a DNS

operator change that may or may not be followed by an NS change or
combined transfer/NS change, they did not want any changes made to
records owned by the registrar of record for a domain object. It's not=

compulsory to do this "communication" via the registry, it o= nly

facilitates registrars that have no other secure communication

channel. Sometimes a keyrelay command is not followed by an NS change<= /div>
as the process is abandoned, and that should not lead to changes in
the DB that need to be reverted. The process would then become more
complex than necessary.

Another requirement that we heard from especially gTLD registries is
that a command for which it was necessary to change the database

tables in a fundamental way would not be implemented by those

registries. Since most EPP commands are processes that change an

object in the registry DB and is only authorized by the current

registrar of record, we looked at  a way to do this communic= ation step

without even touching the DB. EPP keyrelay can be implemented without<= /div>
any changes to the registry DB, and only queries existing records.
This is also how we implemented it.

We only know of one other command that is NOT authorized by the

current registrar of record for a domain object, and that is a

transfer. But if authorized properly by an auth-info token, the goal
of a transfer command is ultimately also to make changes to the domain=

object in the DB.

Keyrelay does not intend to change anything to DB objects. That is
ultimately done by an NS change that usually follows a keyrelay if the=

process is continued AND the loosing DNS operator cooperates. If the
loosing DNS operator does not cooperate, a different change to the DB<= /div>
may follow, and it's complex to predict which action would follow.
There is no default process flow, it's up to the gaining registrar
which next step to take (Abandon, postpone, go insecure, transfer and<= /div>
leave delegation as is, ...), we want him to be in control.

Could you elaberate on how a Command-Response Extension of the domain<= /div>
mapping would meet the requirement of not changing anything

fundamental to the registry DB, nor creating a complex unpredictable
state flow?

How would the State Diagram similar to Figure 1 of RFC3915 look like
for EPP keyrelay?

Bear in mind, that a pending NS change state for a secure transfer
cannot be held forever, nor can it be predicted what a reasonable
period for that state is. It depends on DNS TTL values that are not
prescribed nor verified in most registry policies. And since we want
the registrant to be in control over his domain, it may well be that
during a pending state, yet another registrar may invoke a keyrelay if=

the registrant chooses to change registrars because the process takes<= /div>
too long or there is another (technical) reason to change his

delegation. So a state diagram is much more difficult to create than a=

state diagram for a grace period that is only dependent on 1 registrar=

and a state period defined by the registry's policy.

By completely separating the "preparation communication" fro= m the

state of a domain object, we have avoided the need for a complex state=

diagram and fundamental changes to the registry DB. It also extends
EPP with a new command type that may have other benefits in the future= .

For an (even more) elaborate explanation on how we came to this

conclusion, we have written a white paper:

https://www.sidnlabs.nl/uploads/tx_sidnpublication= s/wp_2013_EPP-keyrelay_v1.en.pdf

On 3/11/14, 9:23 AM, "Antoin Verschuren"

<antoin.verschuren@sid= n.nl <mailto:antoin= .verschuren@sidn.nl>>

wrote:

Hi,

I'd like to answer the question asked in London why EPP keyrelay

is not an object extension or domain update.

Regular EPP commands are submitted to a registry by the current

registrar of record for that object in the database. Only the

registrar of record is allowed to change attributes to a domain

object.

EPP keyrelay is a command that typically is sent to a registry by
a registrar NOT being the registrar of record for that domain

object. So the registrar sending the command is not permitted to

change anything in the database to that object.

EPP keyrelay is therefor only a communication command, and the

domain object is only used to identify the registrar of record for
that domain object as a recipient. The domain object is only

queried to identify the registrar of record, but no attributes are
allowed to be changed.

Hope that clarifies the questions raised in London.

_______________________________________________ EppExt mailing

list EppExt@ietf.org <mailto:EppExt@ietf.org>

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

- --

Antoin Verschuren

Technical Policy Advisor SIDN

Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970

Mailto: antoin.verschuren= @sidn.nl

XMPP: antoin.versc= huren@jabber.sidn.nl

HTTP://www.sidn.nl/

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTIXzKAAoJEDqHrM883AgnH/sIAKYi48zCXAmWXaNjBc+Jik22
/90SrAeV2E3nG9A3FvaM0+0F6lHH9oiKVNzveYD8E6+9pojOdw++sc= RENqAOuseh

0cE3XjvAZh6EQAt2HDKv4Be/LyX5ZnJR8iorecMSl8M0BGQhu7/EDZwD31gFe3kw

ac5ePOijelbte4vIb1gN3WjqWbUjbavMJVxt7hQwL75km0uS3WUGdpo0YwKg3Xan

zjSB/2G7tv0KDVoBIMsKnmTWoR38s4aEXTpdZqq1hJUDIwnwdvHwzbJjRq9a9yKV

Hy3+KJfXZvGIPsiHQZBHLyY3vNJJnA3kKCRO7U7twOiBL5WLPyvaqEhscuJqbRs=3D=

=3DXyh/

-----END PGP SIGNATURE-----

--_000_CF47367659EADjgouldverisigncom_-- From nobody Thu Mar 13 23:51:22 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846F01A0062 for ; Thu, 13 Mar 2014 23:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 0VY1d63cZwDI for ; Thu, 13 Mar 2014 23:51:16 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 533441A0059 for ; Thu, 13 Mar 2014 23:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394779869; x=1426315869; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UanFMwrEYNQd2fJlWP0N0CfGTYfk3L1mA53vcg/BchI=; b=R0ZsqydL/ZAJbBuZEpp04QNeQb28P2BtP127IPdsnILuW//FUdm+HGcK GreJWITzCbIbzzbCXb7wUCQieHSk/e6x0+dLoFHkDoW5o22Ajo5O1LmT/ UhQWOI3hyaH1Rapwd2vzg7Zp4R+ZWgqMijky3XFlrYT7CX1x8OKvTsnF+ U=; X-IronPort-AV: E=McAfee;i="5400,1158,7376"; a="60636847" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 13 Mar 2014 23:51:09 -0700 X-IronPort-AV: E=Sophos;i="4.97,652,1389772800"; d="scan'208";a="699323954" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2014 23:51:09 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Mar 2014 23:51:08 -0700 Message-ID: <5322A6D3.3070507@qti.qualcomm.com> Date: Fri, 14 Mar 2014 08:50:59 +0200 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/NgEo1HlsWl4BfrPIrx3f9NAPsN0 Cc: "eppext@ietf.org" Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 14 Mar 2014 06:51:21 -0000 On 3/10/14 2:41 PM, Hollenbeck, Scott wrote: > What I think I heard during the meeting in London: > > IANA registration policy: Specification Required (which includes designated expert review) > > Add guidelines for the designated expert function, including a recommendation to appoint a small group of people instead of just one person, use of the eppext mailing list for review and discussion, use of RFC 3735 (Guidelines for Extending the Extensible Provisioning Protocol) as a review guide, general goal is to lean towards a permissive registration policy for existing, deployed extensions while encouraging harmonization for new extensions. > This all sounds like what was said, but I don't remember hearing a final answer to one question: Is a specification required to get into the registry, or can the designated expert approve an entry before a proper specification is written up and a pointer to the specification is provided later? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Mar 14 01:23:18 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B671A00A9 for ; Fri, 14 Mar 2014 01:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.547, 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 LsVbbnksYMWn for ; Fri, 14 Mar 2014 01:23:14 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9F1A00B2 for ; Fri, 14 Mar 2014 01:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=FUElxJgM1yvU22Dh9ZzqOxZAuQ22mwE7IkDOOlSeeX0=; b=LiGUtVeyRxIdGb9luOA2dGMbeTvYh/BA3CEisxW5f9icSECo21Occ2dEZ+GXksfxuMZEBGYon5uf5FB8pi+ajG26sj6TZJ4kvnuqkCR/DNIF0SDDiuOdc/zwReL5yNCcOsMyx3aoEPTaOznNkGJ6seIcwBdmVxtfBxQQK8Pm7PQ= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s2E8N4ks018403-s2E8N4ku018403 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Fri, 14 Mar 2014 09:23:04 +0100 Received: from [94.198.152.222] (94.198.152.222) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 14 Mar 2014 09:23:04 +0100 Message-ID: <5322BC67.8000902@sidn.nl> Date: Fri, 14 Mar 2014 09:23:03 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> In-Reply-To: <5322A6D3.3070507@qti.qualcomm.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.222] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/3mG40duO63g5JSSFBbzsePo1Irk Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 14 Mar 2014 08:23:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 14-03-14 07:50, Pete Resnick schreef: >> >> Add guidelines for the designated expert function, including a >> recommendation to appoint a small group of people instead of just >> one person, use of the eppext mailing list for review and >> discussion, use of RFC 3735 (Guidelines for Extending the >> Extensible Provisioning Protocol) as a review guide, general goal >> is to lean towards a permissive registration policy for existing, >> deployed extensions while encouraging harmonization for new >> extensions. > > This all sounds like what was said, but I don't remember hearing a > final answer to one question: Is a specification required to get > into the registry, or can the designated expert approve an entry > before a proper specification is written up and a pointer to the > specification is provided later? I would say that it is very hard to encourage harmonization for new extensions if you don't have a specification to compare against. - From a registrar's perspective, harmonization is a goal for EPPEXT. Judging if the extension fulfills RFC3735 guidelines is also hard when there is no specification. It will make the reviewer task impossible if there is no specification. So I would say specification is required. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTIrxhAAoJEDqHrM883Agng6EH/2d5TPdfDmEYZ6Wnx01yprN2 9uOZgguofMubYnt2H5riw+ZYuTVN8LI19+O46i7Ea5ZLcLU+2hP3pvSySyBfEEG1 mABt8wtNYtXlNJ6C+y+vrGoqNvnJ3p0HlzQDf9bSmH5zZu09HA0eizbhesJEPPtf RtbUeM4CShkHGhbyUGnbIl3Y/Gs8SkYuo03n0tja1GJr8dh1S2jYZhC3IUaGq9z0 DEiN/0x2PmZW2n7wSyWluI5szhf6m3VT4M2xjT4xjGcpFmu9EkqKCZF1Sg9WFqtE TsTDOU5LMMyvMeqO3g3TySbIzjnJBTD7OASz7xFyhqvdpATHJivWYlmFFC1J24k= =dKK+ -----END PGP SIGNATURE----- From nobody Fri Mar 14 01:36:20 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A511A00C3 for ; Fri, 14 Mar 2014 01:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.547, 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 S0fb33t3Afao for ; Fri, 14 Mar 2014 01:36:10 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id BC7891A00BC for ; Fri, 14 Mar 2014 01:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=iJNtLIDiE9XM7vYX0hS+vOkGKZpKsCzOWeH2+2wCbUA=; b=NgOH4kH5K6PjzW/kHFUwDUw+1qy9s1S4ByRE/JsJyI7l3QmgYSv1ICTNwCvvFHiSo6ESmoup2gsJtRSfRNiNd7yvrumaiIR6EzVxUxH2qaYU6SIa8UplmIlGpcracFb0DYhXZxGrn4sleC0bXCpAGJpz+vkUmyMacq2e0IbcWlQ= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s2E8a0Wx018867-s2E8a0X1018867 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Fri, 14 Mar 2014 09:36:00 +0100 Received: from [94.198.152.222] (94.198.152.222) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 14 Mar 2014 09:36:00 +0100 Message-ID: <5322BF6F.7070308@sidn.nl> Date: Fri, 14 Mar 2014 09:35:59 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: References: <20140311160735.1305.14300.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F493711C8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F493711C8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.222] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/zSiqPUVzA1K1tz8FrOGyqcC_QQg Subject: Re: [eppext] I-D Action: draft-ietf-eppext-reg-02.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 08:36:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 11-03-14 17:13, Hollenbeck, Scott schreef: > > This version contains updates to address our IETF-89 discussion[1]. > I added a section to describe the designated expert function and > guidelines for the experts. I also added a new optional field to > the registration template for the inclusion of notes from the > registrant. Here's a diff: Hi Scott, I have not gone in detail over the added text, but it looks good! One thing I'm missing though, is a method to delete extensions from the registry when f.e. someone harmonizes it's proprietary extension with more accepted one. I'm also in doubt whether we should then "delete" the entry in the registry, or mark it as "historic" or "deprecated" but leave it in there. The risk of leaving it in the registry is off course that the specification may not be available or maintained anymore. Any thoughts? - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTIr9vAAoJEDqHrM883AgnHZQH/3y3X3NrZ3Y4BIeKJFnblehy BCZC8V/o3t2UagFqdFWu5cqXuft57oD+Mvq/6h7QB+EsGsPRrjf8Qo/vL5kBb9/w K8l8fWEeKqhsEJS9gdBw0QAH2B0Gt7KeCvbrMNil7yna/hAJvO9VssqQa0RXWe+U GngCGAInfD+zaIAGhuhgLyuRcSHDxTjCuk9flBNpX1TctvVmf9Ln3r8lcCz3zgiL +xF/GI3RqSiBlOv8HspukfBpozbiKjdmuanoM1sMstxUd+wUUhGsOO/GLUEGDkzz XjUmFPDgCJs+GfB0KXc82vZHQFZzDMjNucpNNzzrIsFSfod7n3a1EXu5e1V+s2k= =ameQ -----END PGP SIGNATURE----- From nobody Fri Mar 14 03:33:15 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2C71A0111 for ; Fri, 14 Mar 2014 03:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSpU82zMFBDQ for ; Fri, 14 Mar 2014 03:33:11 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 621841A0100 for ; Fri, 14 Mar 2014 03:33:09 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUyLa3t93hOAGaGnk92NVAWNEBHWeu6KS@postini.com; Fri, 14 Mar 2014 03:33:05 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s2EAX2oh027433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 06:33:02 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 06:33:01 -0400 From: "Hollenbeck, Scott" To: Antoin Verschuren , "eppext@ietf.org" Thread-Topic: [eppext] Updates for eppext-reg Based on IETF-89 Discussion Thread-Index: AQHPP1HNl1DMiSZ4QE6xFMhwjtDNHJrggaaA///g/AA= Date: Fri, 14 Mar 2014 10:33:00 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> In-Reply-To: <5322BC67.8000902@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/F1B4A980L5mBzSO64Smch-Jz7ec Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 14 Mar 2014 10:33:13 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Antoin > Verschuren > Sent: Friday, March 14, 2014 4:23 AM > To: eppext@ietf.org > Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 > Discussion >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > op 14-03-14 07:50, Pete Resnick schreef: > >> > >> Add guidelines for the designated expert function, including a > >> recommendation to appoint a small group of people instead of just > >> one person, use of the eppext mailing list for review and > >> discussion, use of RFC 3735 (Guidelines for Extending the > >> Extensible Provisioning Protocol) as a review guide, general goal > >> is to lean towards a permissive registration policy for existing, > >> deployed extensions while encouraging harmonization for new > >> extensions. > > > > This all sounds like what was said, but I don't remember hearing a > > final answer to one question: Is a specification required to get > > into the registry, or can the designated expert approve an entry > > before a proper specification is written up and a pointer to the > > specification is provided later? >=20 > I would say that it is very hard to encourage harmonization for new > extensions if you don't have a specification to compare against. > - From a registrar's perspective, harmonization is a goal for EPPEXT. > Judging if the extension fulfills RFC3735 guidelines is also hard when > there is no specification. > It will make the reviewer task impossible if there is no specification. >=20 > So I would say specification is required. I would as well. Scott From nobody Fri Mar 14 03:42:09 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259531A0111 for ; Fri, 14 Mar 2014 03:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9bzlxppPIj3 for ; Fri, 14 Mar 2014 03:42:02 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8B87A1A0100 for ; Fri, 14 Mar 2014 03:42:00 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUyLc8ew7qfnd86CXlLGJLOkLgkauJLt0@postini.com; Fri, 14 Mar 2014 03:41:56 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s2EAfrEX027693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 06:41:53 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 06:41:53 -0400 From: "Hollenbeck, Scott" To: Antoin Verschuren , "eppext@ietf.org" Thread-Topic: [eppext] I-D Action: draft-ietf-eppext-reg-02.txt Thread-Index: AQHPPUQGG2RR7vq2MUuzWBoPotdJrJrgRmbagAAgpGA= Date: Fri, 14 Mar 2014 10:41:52 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49373770@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140311160735.1305.14300.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F493711C8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322BF6F.7070308@sidn.nl> In-Reply-To: <5322BF6F.7070308@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/WJ7d27f8BQP1OgRSD-94YZ0iBwU Subject: Re: [eppext] I-D Action: draft-ietf-eppext-reg-02.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 10:42:06 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Antoin > Verschuren > Sent: Friday, March 14, 2014 4:36 AM > To: eppext@ietf.org > Subject: Re: [eppext] I-D Action: draft-ietf-eppext-reg-02.txt >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > op 11-03-14 17:13, Hollenbeck, Scott schreef: > > > > This version contains updates to address our IETF-89 discussion[1]. > > I added a section to describe the designated expert function and > > guidelines for the experts. I also added a new optional field to > > the registration template for the inclusion of notes from the > > registrant. Here's a diff: >=20 > Hi Scott, >=20 > I have not gone in detail over the added text, but it looks good! >=20 > One thing I'm missing though, is a method to delete extensions from > the registry when f.e. someone harmonizes it's proprietary extension > with more accepted one. > I'm also in doubt whether we should then "delete" the entry in the > registry, or mark it as "historic" or "deprecated" but leave it in > there. The risk of leaving it in the registry is off course that the > specification may not be available or maintained anymore. > Any thoughts? There's also a risk of a specification going missing for an "active" regist= ration. Should such entries be deprecated if/when someone notices? I'm goin= g to say "yes" if attempts to reach the registrant are unsuccessful. We could add a status field to the template to identify active and obsolete= /deprecated extensions. We could also create two sections in the registry, = with one section for active registrations and the other for deprecated exte= nsions. Scott From nobody Mon Mar 17 07:31:39 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05ECF1A03F5; Mon, 17 Mar 2014 07:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btxmzOUVyK6G; Mon, 17 Mar 2014 07:31:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD9A1A0123; Mon, 17 Mar 2014 07:31:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140317143134.16026.78298.idtracker@ietfa.amsl.com> Date: Mon, 17 Mar 2014 07:31:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/4K3xRQLrgU96d3UzZkNmVNlzeRE Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-launchphase-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: Mon, 17 Mar 2014 14:31:36 -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-01.txt Pages : 52 Date : 2014-03-17 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-launchphase-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 Tue Mar 18 07:10:15 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD6B1A043E for ; Tue, 18 Mar 2014 07:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 uCo-wc9AWT7i for ; Tue, 18 Mar 2014 07:10:11 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C21A03D8 for ; Tue, 18 Mar 2014 07:10:11 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id D0BD524BE29; Tue, 18 Mar 2014 11:10:02 -0300 (BRT) Date: Tue, 18 Mar 2014 11:10:02 -0300 From: Frederico A C Neves To: "Hollenbeck, Scott" Message-ID: <20140318141002.GD35698@registro.br> References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/HkA8OzfQCQQ0_clKkeINOnIZ4rM Cc: Antoin Verschuren , "eppext@ietf.org" Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 18 Mar 2014 14:10:13 -0000 On Fri, Mar 14, 2014 at 10:33:00AM +0000, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Antoin > > Verschuren > > Sent: Friday, March 14, 2014 4:23 AM > > To: eppext@ietf.org > > Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 > > Discussion > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > op 14-03-14 07:50, Pete Resnick schreef: > > >> > > >> Add guidelines for the designated expert function, including a > > >> recommendation to appoint a small group of people instead of just > > >> one person, use of the eppext mailing list for review and > > >> discussion, use of RFC 3735 (Guidelines for Extending the > > >> Extensible Provisioning Protocol) as a review guide, general goal > > >> is to lean towards a permissive registration policy for existing, > > >> deployed extensions while encouraging harmonization for new > > >> extensions. > > > > > > This all sounds like what was said, but I don't remember hearing a > > > final answer to one question: Is a specification required to get > > > into the registry, or can the designated expert approve an entry > > > before a proper specification is written up and a pointer to the > > > specification is provided later? > > > > I would say that it is very hard to encourage harmonization for new > > extensions if you don't have a specification to compare against. > > - From a registrar's perspective, harmonization is a goal for EPPEXT. > > Judging if the extension fulfills RFC3735 guidelines is also hard when > > there is no specification. > > It will make the reviewer task impossible if there is no specification. > > > > So I would say specification is required. > > I would as well. I would say as well but, when I mean "stable specification" is required I don't mean RFC or even RFC draft format. > > Scott > Fred From nobody Tue Mar 18 07:13:05 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371151A012F for ; Tue, 18 Mar 2014 07:13:03 -0700 (PDT) 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 brHf594RbC8X for ; Tue, 18 Mar 2014 07:13:01 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5A1A0128 for ; Tue, 18 Mar 2014 07:13:00 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so5810140wes.6 for ; Tue, 18 Mar 2014 07:12:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=YGbeYUyDSTEDzjulwOxMkPwl/YRWTJ6BRcWt17ruxVA=; b=lXlcHd3vFWwFc+PsO4dxYtoSgJgM9IX2cj/sVEgEvZ1oJkW+1Zq47HLLGF2RrzMVbf 8Eoc8MK5Kv8ASkxUYDBqJ2+0qkblDvLjBgkTaZ5yxneOkRZgZr6Ah+76HZ4Veh4XdOA5 wW2QJb280P15o1YmZlT2Zi957To2eVZHkaQeWLgTS5+WwQd2xeEUOcvhJFA1soErQCCh vDTN5H7KOmDE/ShPofIMCyWS1NtrZcZ11gLnSb32h2QSAeuGYi5tClyDco+EBvsPBV7X LtBvenHfVHq3z8FyJdAfhJTPdGMUjGd7vUpFG2W0H1jqT8rPPl1JitQiE4JZRTLmu/wy EL5Q== X-Gm-Message-State: ALoCoQn9I5E6IXOHCEAgPC7NBPse3lyT1PXF8J9k+nkG/UWNDOOLxvJFfF59B225FxXBT12sKyvJ X-Received: by 10.180.221.68 with SMTP id qc4mr14342899wic.30.1395151971977; Tue, 18 Mar 2014 07:12:51 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:feae:e74c]) by mx.google.com with ESMTPSA id fs8sm34370674wib.8.2014.03.18.07.12.50 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 18 Mar 2014 07:12:50 -0700 (PDT) Date: Tue, 18 Mar 2014 14:12:49 +0000 From: Miek Gieben To: eppext@ietf.org Message-ID: <20140318141249.GA13486@miek.nl> Mail-Followup-To: eppext@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140318141002.GD35698@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140318141002.GD35698@registro.br> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/wz9Ehq-vuABmRRetkJ-78u-nM7Y Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 18 Mar 2014 14:13:03 -0000 [ Quoting in "Re: [eppext] Updates for eppext-reg..." ] > > > I would say that it is very hard to encourage harmonization for new > > > extensions if you don't have a specification to compare against. > > > - From a registrar's perspective, harmonization is a goal for EPPEXT. > > > Judging if the extension fulfills RFC3735 guidelines is also hard when > > > there is no specification. > > > It will make the reviewer task impossible if there is no specification. > > > > > > So I would say specification is required. > > > > I would as well. > > I would say as well but, when I mean "stable specification" is > required I don't mean RFC or even RFC draft format. Agreed. But what would a "specification" look like then? What is acceptable, what is not acceptable? /Miek -- Miek Gieben From nobody Tue Mar 18 07:19:13 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF2E1A0410 for ; Tue, 18 Mar 2014 07:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 ozzVSi1jy6VN for ; Tue, 18 Mar 2014 07:19:10 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by ietfa.amsl.com (Postfix) with ESMTP id 008541A040C for ; Tue, 18 Mar 2014 07:19:04 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 68E6524BE8D; Tue, 18 Mar 2014 11:18:56 -0300 (BRT) Date: Tue, 18 Mar 2014 11:18:56 -0300 From: Frederico A C Neves To: eppext@ietf.org Message-ID: <20140318141856.GE35698@registro.br> References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140318141002.GD35698@registro.br> <20140318141249.GA13486@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140318141249.GA13486@miek.nl> Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/I2rlQKJ9gFOhme9JVBjUvrbd2WU Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 18 Mar 2014 14:19:11 -0000 On Tue, Mar 18, 2014 at 02:12:49PM +0000, Miek Gieben wrote: > [ Quoting in "Re: [eppext] Updates for eppext-reg..." ] > > > > I would say that it is very hard to encourage harmonization for new > > > > extensions if you don't have a specification to compare against. > > > > - From a registrar's perspective, harmonization is a goal for EPPEXT. > > > > Judging if the extension fulfills RFC3735 guidelines is also hard when > > > > there is no specification. > > > > It will make the reviewer task impossible if there is no specification. > > > > > > > > So I would say specification is required. > > > > > > I would as well. > > > > I would say as well but, when I mean "stable specification" is > > required I don't mean RFC or even RFC draft format. > > Agreed. But what would a "specification" look like then? What is acceptable, > what is not acceptable? What about a stable URL pointing to a document that respects RFC 3735 2.1 ? > /Miek Fred From nobody Tue Mar 18 07:19:52 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3C31A037C for ; Tue, 18 Mar 2014 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEQvM-xz14Sv for ; Tue, 18 Mar 2014 07:19:49 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id AF9D21A0248 for ; Tue, 18 Mar 2014 07:19:48 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUyhV/NvR+6o1TYYxJD/ypnv3TWAPzKzS@postini.com; Tue, 18 Mar 2014 07:19:41 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s2IEJclE032086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 10:19:39 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Tue, 18 Mar 2014 10:19:38 -0400 From: "Gould, James" To: Miek Gieben , "eppext@ietf.org" Thread-Topic: [eppext] Updates for eppext-reg Based on IETF-89 Discussion Thread-Index: Ac88Xg6L7wic2SxfSnKB32VU/k2mfQDFToiAAAM3I4AABInYAADQvtgAAAAY44D//77MgA== Date: Tue, 18 Mar 2014 14:19:37 +0000 Message-ID: In-Reply-To: <20140318141249.GA13486@miek.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <64D30750F2FD064EAC739B029CB18557@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/u_QXvU77f1f169-lGTRI5GvH65I Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 18 Mar 2014 14:19:51 -0000 I propose taking the language from the registry agreement, which is =B3Internet-Draft format following the guidelines described in RFC 3735=B2. --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/18/14, 10:12 AM, "Miek Gieben" wrote: >[ Quoting in "Re: [eppext] Updates for >eppext-reg..." ] >> > > I would say that it is very hard to encourage harmonization for new >> > > extensions if you don't have a specification to compare against. >> > > - From a registrar's perspective, harmonization is a goal for >>EPPEXT. >> > > Judging if the extension fulfills RFC3735 guidelines is also hard >>when >> > > there is no specification. >> > > It will make the reviewer task impossible if there is no >>specification. >> > >=20 >> > > So I would say specification is required. >> >=20 >> > I would as well. >>=20 >> I would say as well but, when I mean "stable specification" is >> required I don't mean RFC or even RFC draft format. > >Agreed. But what would a "specification" look like then? What is >acceptable, >what is not acceptable? > >/Miek > >--=20 >Miek Gieben > >_______________________________________________ >EppExt mailing list >EppExt@ietf.org >https://www.ietf.org/mailman/listinfo/eppext From nobody Tue Mar 18 07:30:55 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22CF1A045C for ; Tue, 18 Mar 2014 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 50sMgPvKDHdP for ; Tue, 18 Mar 2014 07:30:53 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id B94E11A0410 for ; Tue, 18 Mar 2014 07:30:52 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 07EAA24BEE9; Tue, 18 Mar 2014 11:30:44 -0300 (BRT) Date: Tue, 18 Mar 2014 11:30:44 -0300 From: Frederico A C Neves To: "Gould, James" Message-ID: <20140318143044.GF35698@registro.br> References: <20140318141249.GA13486@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/0MaEVT8w2kLEKKvDpdJuweqGiVk Cc: Miek Gieben , "eppext@ietf.org" Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 18 Mar 2014 14:30:53 -0000 James, On Tue, Mar 18, 2014 at 02:19:37PM +0000, Gould, James wrote: > I propose taking the language from the registry agreement, which is > �Internet-Draft format following the guidelines described in RFC 3735�. That was definitely not the consensus at the London meeting. Even 3735 2.1 last paragraph doesn't say that. We need to remember that one of the intents of the registry is to reference the extensions already out. Some of then are not documented as internet-drafts and we should not impose this barrier if we want this registry to be successful. > -- > > JG > Fred From nobody Tue Mar 18 07:45:48 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A201A046B for ; Tue, 18 Mar 2014 07:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJOZ75y__h7O for ; Tue, 18 Mar 2014 07:45:39 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) by ietfa.amsl.com (Postfix) with ESMTP id D99741A037C for ; Tue, 18 Mar 2014 07:45:38 -0700 (PDT) Received: from [10.63.74.223] (unknown [217.138.20.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 239239D86; Tue, 18 Mar 2014 14:45:29 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_001C04E6-6E78-44BF-8AF0-C91BF186E084"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 $1874$) From: Gavin Brown In-Reply-To: <20140318143044.GF35698@registro.br> Date: Tue, 18 Mar 2014 14:45:27 +0000 Message-Id: References: <20140318141249.GA13486@miek.nl> <20140318143044.GF35698@registro.br> To: Frederico A C Neves X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/kBG_zyKEfdmYFwFx63xKeE_7H1M Cc: Miek Gieben , "eppext@ietf.org" , "Gould, James" Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 18 Mar 2014 14:45:45 -0000 --Apple-Mail=_001C04E6-6E78-44BF-8AF0-C91BF186E084 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree - a specification in I-D format should not be required, although = I am fine with wording which recommends or encourages that format for = new extensions. G. On 18 Mar 2014, at 14:30, Frederico A C Neves = wrote: > James, >=20 > On Tue, Mar 18, 2014 at 02:19:37PM +0000, Gould, James wrote: >> I propose taking the language from the registry agreement, which is >> =B3Internet-Draft format following the guidelines described in RFC = 3735=B2. >=20 > That was definitely not the consensus at the London meeting. Even 3735 > 2.1 last paragraph doesn't say that. >=20 > We need to remember that one of the intents of the registry is to > reference the extensions already out. Some of then are not documented > as internet-drafts and we should not impose this barrier if we want > this registry to be successful. >=20 >> --=20 >>=20 >> JG >>=20 >=20 > Fred >=20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext --=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. --Apple-Mail=_001C04E6-6E78-44BF-8AF0-C91BF186E084 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----- iEYEARECAAYFAlMoXAcACgkQ6H45IPkjtM5s3gCcD2RXWiBygthyUP6l528soG/n 9OwAoI4ob2qPEyE4+ozvBctG8RBSaR4D =NSrr -----END PGP SIGNATURE----- --Apple-Mail=_001C04E6-6E78-44BF-8AF0-C91BF186E084-- From nobody Wed Mar 19 03:32:19 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FB41A0716 for ; Wed, 19 Mar 2014 03:32:17 -0700 (PDT) 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 0hrRkI7PjlIv for ; Wed, 19 Mar 2014 03:32:15 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id 269671A06AF for ; Wed, 19 Mar 2014 03:32:14 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so6729441wes.25 for ; Wed, 19 Mar 2014 03:32:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Y1TV5qNgy91meUL2ckYE2NPG60Uy/U1COZk8rQRFCRA=; b=fL8eNKs0NfKRBSZn6nTlBiF8QGDTXThAPVofjjOIXpDEos41uBzPKjx2uf7+CXkrQO LYWOpAoNMs4gs6hlnTsepKvP8eVy0+GaE6vgOxvMJ/2tvsfeqkxSN0xm+6M4yCPtVzVv m4unaUD4feP78nPxUmjbycLH9+eeRIOE7OU+C127RuErnYlr5fdT6DNEZXiVTpYwdgEN W6XDZY0n3pW2qNYMBXEwt8xpoWtbtXnM5Hmc+aLdAfKcetDJ3bIniQk8gNwBFeI+Wm22 +2mVOXKI//etUh7zAnr03D90Y9qB3QPUxMFk2hAzKJ3+fxHXzwgpBkvo4sVpDKMYer9Z rggQ== X-Gm-Message-State: ALoCoQnnfayHKxgQHpo8EtXOHLl2elYbegYb9H0f3jbfxJRJvPzN4NlM8VFuU9uBsIvf4tSIrYq1 X-Received: by 10.194.109.6 with SMTP id ho6mr28096156wjb.21.1395225125925; Wed, 19 Mar 2014 03:32:05 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:feae:e74c]) by mx.google.com with ESMTPSA id u6sm42311985wif.6.2014.03.19.03.32.04 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 19 Mar 2014 03:32:05 -0700 (PDT) Date: Wed, 19 Mar 2014 10:32:03 +0000 From: Miek Gieben To: eppext@ietf.org Message-ID: <20140319103203.GB16475@miek.nl> Mail-Followup-To: eppext@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140318141002.GD35698@registro.br> <20140318141249.GA13486@miek.nl> <20140318141856.GE35698@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140318141856.GE35698@registro.br> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/9HG45iSHzV2_ofb4sgvq3XjDdcY Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 19 Mar 2014 10:32:17 -0000 [ Quoting in "Re: [eppext] Updates for eppext-reg..." ] > > Agreed. But what would a "specification" look like then? What is acceptable, > > what is not acceptable? > > What about a stable URL pointing to a document that respects RFC 3735 > 2.1 ? That seems like a very sensible requirement. /Miek -- Miek Gieben From nobody Wed Mar 19 17:50:15 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977261A0855 for ; Wed, 19 Mar 2014 17:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5I_R8UZ1OoEn for ; Wed, 19 Mar 2014 17:50:09 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id C1E701A0835 for ; Wed, 19 Mar 2014 17:49:49 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUyo7JIpaMWtW9gNQZm3i3iNcqMuXb+Vz@postini.com; Wed, 19 Mar 2014 17:50:01 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s2K0ndlG004207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 20:49:40 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 20:49:39 -0400 From: "Hollenbeck, Scott" To: Miek Gieben , "eppext@ietf.org" Thread-Topic: [eppext] Updates for eppext-reg Based on IETF-89 Discussion Thread-Index: AQHPP1HNl1DMiSZ4QE6xFMhwjtDNHJrm6ORsgABDz4CAAAG1AIABUvGAgACoj4A= Date: Thu, 20 Mar 2014 00:49:38 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49378250@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140318141002.GD35698@registro.br> <20140318141249.GA13486@miek.nl> <20140318141856.GE35698@registro.br> <20140319103203.GB16475@miek.nl> In-Reply-To: <20140319103203.GB16475@miek.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/dMpBxfuaw0ebpgMBOJhhIwGjmG0 Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 20 Mar 2014 00:50:11 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Miek Gieben > Sent: Wednesday, March 19, 2014 6:32 AM > To: eppext@ietf.org > Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 > Discussion >=20 > [ Quoting in "Re: [eppext] Updates for eppext- > reg..." ] > > > Agreed. But what would a "specification" look like then? What is > acceptable, > > > what is not acceptable? > > > > What about a stable URL pointing to a document that respects RFC 3735 > > 2.1 ? >=20 > That seems like a very sensible requirement. This is the sentiment that's currently described in eppext-reg-02: "The "Specification Required" policy described in RFC 5226 [RFC5226] MUST b= e followed. Extension specifications MUST be written and available in the = English language." "Extensions should be evaluated for architectural soundness using the guide= lines described in RFC 3735 [RFC3735]." Should any of this text be changed? Scott From nobody Thu Mar 20 03:02:42 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D061A076B for ; Thu, 20 Mar 2014 03:02:40 -0700 (PDT) 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 of61AS83EtJW for ; Thu, 20 Mar 2014 03:02:37 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id ADB901A086D for ; Thu, 20 Mar 2014 03:02:35 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so416059wgg.9 for ; Thu, 20 Mar 2014 03:02:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=biO0gwgbXX3je7+xKw8R9qhJofhl3Sr7ymZ/vF8MV8w=; b=VD18cieJyrNYrcq79hZtoUjSkv8LrVVTq1jUIgm3aE6wCL5/cZhQj8/D1Rcbhm9hLx nT+w7upxhjdGwSlrJUmHzJfJrF67uPBVs6rXVU7kcPKgCQg5p5nW7Bgl7OUYhIG8AKM2 vW8DSRWUcEhVxpFIMz1lF63uph4ngwvnJe7cmkuVSW9sSHN6qp6EukLbaFw365q1avrG AoLIrQJmc5xDDuG/TwmcOlFGPggCA9rSjZUQwaMsVcTfgcRCwOtVDePpiQ9m1d5pn9nR L1dLddB9QIk2X0Prhzcez4UvLHHtzTIwG1RhBoogG64cdPmDsnSFo+XjUz0a+9QNvUpX TUxA== X-Gm-Message-State: ALoCoQn02zbgGdrGg9yPnRby3Oqa9Qs1s8TK0SKyZZHqOdtW5WOz2VUM9Ep07Nqjbr453XBYLFPW X-Received: by 10.180.38.41 with SMTP id d9mr23331507wik.9.1395309746346; Thu, 20 Mar 2014 03:02:26 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:feae:e74c]) by mx.google.com with ESMTPSA id t5sm3668235wjw.15.2014.03.20.03.02.25 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 20 Mar 2014 03:02:25 -0700 (PDT) Date: Thu, 20 Mar 2014 10:02:23 +0000 From: Miek Gieben To: "eppext@ietf.org" Message-ID: <20140320100223.GA20310@miek.nl> Mail-Followup-To: "eppext@ietf.org" References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140318141002.GD35698@registro.br> <20140318141249.GA13486@miek.nl> <20140318141856.GE35698@registro.br> <20140319103203.GB16475@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49378250@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49378250@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/YUdI44zVaLHlz_flT3-U1Tg9N88 Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 20 Mar 2014 10:02:40 -0000 [ Quoting in "RE: [eppext] Updates for eppext-reg..." ] > > > What about a stable URL pointing to a document that respects RFC 3735 > > > 2.1 ? > > > > That seems like a very sensible requirement. > > This is the sentiment that's currently described in eppext-reg-02: > > "The "Specification Required" policy described in RFC 5226 [RFC5226] MUST be followed. Extension specifications MUST be written and available in the English language." > > "Extensions should be evaluated for architectural soundness using the guidelines described in RFC 3735 [RFC3735]." > > Should any of this text be changed? Maybe refence the 2.1 section, but that is a minor nit. It looks fine as-is. /Miek -- Miek Gieben From nobody Thu Mar 20 07:54:57 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FD71A03EF for ; Thu, 20 Mar 2014 07:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 jJFM_jeFCreQ for ; Thu, 20 Mar 2014 07:54:45 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by ietfa.amsl.com (Postfix) with ESMTP id C477C1A0747 for ; Thu, 20 Mar 2014 07:54:32 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 81B8824BDD6; Thu, 20 Mar 2014 11:54:23 -0300 (BRT) Date: Thu, 20 Mar 2014 11:54:23 -0300 From: Frederico A C Neves To: "eppext@ietf.org" Message-ID: <20140320145423.GN36262@registro.br> References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140318141002.GD35698@registro.br> <20140318141249.GA13486@miek.nl> <20140318141856.GE35698@registro.br> <20140319103203.GB16475@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49378250@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140320100223.GA20310@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140320100223.GA20310@miek.nl> Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/OukFN_TXxxh6xnK_KKAha5xUofM Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 20 Mar 2014 14:54:52 -0000 On Thu, Mar 20, 2014 at 10:02:23AM +0000, Miek Gieben wrote: > [ Quoting in "RE: [eppext] Updates for eppext-reg..." ] > > > > What about a stable URL pointing to a document that respects RFC 3735 > > > > 2.1 ? > > > > > > That seems like a very sensible requirement. > > > > This is the sentiment that's currently described in eppext-reg-02: > > > > "The "Specification Required" policy described in RFC 5226 [RFC5226] MUST be followed. Extension specifications MUST be written and available in the English language." > > > > "Extensions should be evaluated for architectural soundness using the guidelines described in RFC 3735 [RFC3735]." > > > > Should any of this text be changed? > > Maybe refence the 2.1 section, but that is a minor nit. It looks fine as-is. > It's fine by me as well. Fred From nobody Fri Mar 21 01:09:18 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749EA1A0945 for ; Fri, 21 Mar 2014 01:09:16 -0700 (PDT) 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_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 73HQDJvsJWq3 for ; Fri, 21 Mar 2014 01:09:14 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id DF6F81A0572 for ; Fri, 21 Mar 2014 01:09:13 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 21 Mar 2014 16:09:00 +0800 From: "Linlin Zhou" To: "'Frederico A C Neves'" , References: <831693C2CDA2E849A7D7A712B24E257F493704E4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5322A6D3.3070507@qti.qualcomm.com> <5322BC67.8000902@sidn.nl> <831693C2CDA2E849A7D7A712B24E257F49373745@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140318141002.GD35698@registro.br> <20140318141249.GA13486@miek.nl> <20140318141856.GE35698@registro.br> In-Reply-To: <20140318141856.GE35698@registro.br> Date: Fri, 21 Mar 2014 16:08:59 +0800 Message-ID: <031001cf44dc$d0c2e080$7248a180$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9CtQbwvujyu8NVRO+5TT86K0o93ACJ5lPw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/MBXIvF3m2F8ZLAJ12Vs_S-7d0Oc Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion 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, 21 Mar 2014 08:09:16 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Frederico A C > Neves > Sent: Tuesday, March 18, 2014 10:19 PM > To: eppext@ietf.org > Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion > > On Tue, Mar 18, 2014 at 02:12:49PM +0000, Miek Gieben wrote: > > [ Quoting in "Re: [eppext] Updates for > > eppext-reg..." ] > > > > > I would say that it is very hard to encourage harmonization for > > > > > new extensions if you don't have a specification to compare against. > > > > > - From a registrar's perspective, harmonization is a goal for EPPEXT. > > > > > Judging if the extension fulfills RFC3735 guidelines is also > > > > > hard when there is no specification. > > > > > It will make the reviewer task impossible if there is no specification. > > > > > > > > > > So I would say specification is required. > > > > > > > > I would as well. > > > > > > I would say as well but, when I mean "stable specification" is > > > required I don't mean RFC or even RFC draft format. > > > > Agreed. But what would a "specification" look like then? What is > > acceptable, what is not acceptable? > > What about a stable URL pointing to a document that respects RFC 3735 > 2.1 ? Agreed > > > /Miek > > Fred > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext