From nobody Wed Apr 2 04:29:59 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 0D9D61A01DC for ; Wed, 2 Apr 2014 04:29:58 -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 lUEd9vQocnCj for ; Wed, 2 Apr 2014 04:29:54 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id E35931A01D7 for ; Wed, 2 Apr 2014 04:29:46 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUzv0p0jY1LtcVhMH+2I3m6RMV0qDbVIj@postini.com; Wed, 02 Apr 2014 04:29:47 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s32BTgYS027451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 07:29:42 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 2 Apr 2014 07:29:42 -0400 From: "Hollenbeck, Scott" To: Frederico A C Neves , "eppext@ietf.org" Thread-Topic: [eppext] Updates for eppext-reg Based on IETF-89 Discussion Thread-Index: AQHPP1HNl1DMiSZ4QE6xFMhwjtDNHJrpyGYagACUlICAE/Df8A== Date: Wed, 2 Apr 2014 11:29:41 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4939565C@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> <831693C2CDA2E849A7D7A712B24E257F49378250@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20140320100223.GA20310@miek.nl> <20140320145423.GN36262@registro.br> In-Reply-To: <20140320145423.GN36262@registro.br> 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/XdURqAOaGv4C8PatGC3IAfrOJUU 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, 02 Apr 2014 11:29:58 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Frederico A > C Neves > Sent: Thursday, March 20, 2014 10:54 AM > To: eppext@ietf.org > Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 > Discussion >=20 > 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. > > >=20 > It's fine by me as well. I've been waiting to see if anyone else had anything else to say, but given= the lack of further comment I'm going to assume that there are no issues w= ith making this minor change. I'll take care of it this week. Folks, I'd like to encourage everyone to speak up and express support for e= ven minor suggestions like this one. Without expressions of support it's go= ing to be tough to convince the IESG that we have WG consensus. Don't worry= , "+1" notes are OK! Scott From nobody Wed Apr 2 06:47:46 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7B61A01D9 for ; Wed, 2 Apr 2014 06:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBre18j_l30K for ; Wed, 2 Apr 2014 06:47:40 -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 387E41A01E4 for ; Wed, 2 Apr 2014 06:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=fhT1+TE/2CCj+zcpH5lL6e9qfO6UaIwpkstL4q4bZM0=; b=PkO8dzeoKeRpig6sikUTuWyPW5BVDGISmHvOqSP3Aq+kVc1ZY/6GfMCLDVaojXCsRVOTHGEscswjv55cNfvrIr5z1UtQeZE+TIGRM9yhyXd91KQtGeMtgx8SgdVe06ehQqBhxArLGc7HwsUx1CaPnocidbqcXJXZBsMTt0CBwr0= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s32DlZZb017650-s32DlZZd017650 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 2 Apr 2014 15:47:35 +0200 Received: from KAMBX1.SIDN.local ([fe80::501d:affc:30a9:4edf]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Wed, 2 Apr 2014 15:47:35 +0200 From: Marc Groeneweg To: "'eppext@ietf.org'" Thread-Topic: [eppext] Updates for eppext-reg Based on IETF-89 Discussion Thread-Index: Ac88Xg6L7wic2SxfSnKB32VU/k2mfQC61FKAAAM3JIAABInYAADQvtcAAAAY44AAADawAAAqXhyAAB3zZAAAE034gAAKMq+AAoSLPoAACP7KcA== Date: Wed, 2 Apr 2014 13:47:34 +0000 Message-ID: <5BFD186DCB661E4D951017B0818285AE934DDEBD@kambx1.SIDN.local> 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> <20140320145423.GN36262@registro.br> <831693C2CDA2E849A7D7A712B24E257F4939565C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4939565C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.156] 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/nBlEn3nGcUUgo2vL4_l_MG7_qXU 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, 02 Apr 2014 13:47:44 -0000 +1 ;-) -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Hollenbeck, Scot= t Sent: woensdag 2 april 2014 13:30 To: Frederico A C Neves; eppext@ietf.org Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89 Discussion > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Frederico A=20 > C Neves > Sent: Thursday, March 20, 2014 10:54 AM > To: eppext@ietf.org > Subject: Re: [eppext] Updates for eppext-reg Based on IETF-89=20 > Discussion >=20 > 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=20 > 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=20 > > fine > as-is. > > >=20 > It's fine by me as well. I've been waiting to see if anyone else had anything else to say, but given= the lack of further comment I'm going to assume that there are no issues w= ith making this minor change. I'll take care of it this week. Folks, I'd like to encourage everyone to speak up and express support for e= ven minor suggestions like this one. Without expressions of support it's go= ing to be tough to convince the IESG that we have WG consensus. Don't worry= , "+1" notes are OK! Scott _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext From nobody Thu Apr 3 09:15:58 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 A1FB71A0269; Thu, 3 Apr 2014 09:15:52 -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 4OWz7MAHL8oV; Thu, 3 Apr 2014 09:15:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5091A01F4; Thu, 3 Apr 2014 09:15:46 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140403161546.30564.84638.idtracker@ietfa.amsl.com> Date: Thu, 03 Apr 2014 09:15:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/K18CxgF8R69Dxn1NSpBO77A3Sc4 Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-reg-03.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: Thu, 03 Apr 2014 16:15:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Provisioning Protocol Extensions Working Group of the IETF. Title : Extension Registry for the Extensible Provisioning Protocol Author : Scott Hollenbeck Filename : draft-ietf-eppext-reg-03.txt Pages : 10 Date : 2014-04-03 Abstract: The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP and it specifies a format for an IANA registry to record those extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-reg-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-reg-03 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 Thu Apr 3 09:18:56 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA5F1A0211 for ; Thu, 3 Apr 2014 09:18:54 -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 JKblhk2RneDM for ; Thu, 3 Apr 2014 09:18:47 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 680C61A01FA for ; Thu, 3 Apr 2014 09:18:47 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUz2J45DL6CMfZIeW/u4TRMrD3RP/kzVa@postini.com; Thu, 03 Apr 2014 09:18:43 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 s33GIgq5018959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 3 Apr 2014 12:18:42 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 3 Apr 2014 12:18:41 -0400 From: "Hollenbeck, Scott" To: "eppext@ietf.org" Thread-Topic: [eppext] I-D Action: draft-ietf-eppext-reg-03.txt Thread-Index: AQHPT1f+tJAp4NoCdESqCxmLa3o0S5sAEYIA Date: Thu, 3 Apr 2014 16:18:40 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49396BDA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20140403161546.30564.84638.idtracker@ietfa.amsl.com> In-Reply-To: <20140403161546.30564.84638.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/tkCqX0Xn337muYs5c2cicORDSe0 Subject: Re: [eppext] I-D Action: draft-ietf-eppext-reg-03.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: Thu, 03 Apr 2014 16:18:54 -0000 Scott > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, April 03, 2014 12:16 PM > To: i-d-announce@ietf.org > Cc: eppext@ietf.org > Subject: [eppext] I-D Action: draft-ietf-eppext-reg-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Extensible Provisioning Protocol > Extensions Working Group of the IETF. >=20 > Title : Extension Registry for the Extensible > Provisioning Protocol > Author : Scott Hollenbeck > Filename : draft-ietf-eppext-reg-03.txt > Pages : 10 > Date : 2014-04-03 This version completes the action I proposed here: http://www.ietf.org/mail-archive/web/eppext/current/msg00091.html I do not currently have any other edits enqueued for this document. Is it f= inished? Are you comfortable with the approach it describes? Scott From nobody Thu Apr 3 14:06:00 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 237E31A018A for ; Thu, 3 Apr 2014 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNezoAd_RIEh for ; Thu, 3 Apr 2014 14:05:40 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 111FC1A01CA for ; Thu, 3 Apr 2014 14:05:38 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id lx4so2398383iec.23 for ; Thu, 03 Apr 2014 14:05:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=qu1yRzzfPenlYPZTl+xQkZz5kLuWWgiuHqKNgkJu10s=; b=VPuDeBt79LZ+9k9wguKNiSD607wLPrHbEujPMQ9O0fQPmhyukvqSyB6WkHJgdn/e6D qqwWoRq/thTVcCeGeQrSXEFgKreBxwfn95pEsh9sIopMjF5Rn+YMshtawBOonOLs51Lt 3ua65b5MRQRZzhpoKF0/NCiUZf8OBL33LjIDXkwqlRRp2O+0u0yckvDfxuE66xTD2bf6 FO0coLvgdRMCdrqRMMPp0uJ9BoftO7IDd4ldyzcrLO7VfKUASLmc8YouIzWhxfJV73sc vZ+RC3RpZP2o2Jaud488y6gZ3QiPI9MbGk+DN0+hUdTG/UcwReSsL7iOdgLw2KfsyIJF 74WQ== X-Gm-Message-State: ALoCoQmv6Ybt9qySt14qJB1Z1WBwxdQ8cD1VGQSi3TO5apnM19NszQB5f3rZzwWAvTyqcwR8ZgTQ MIME-Version: 1.0 X-Received: by 10.50.43.170 with SMTP id x10mr10782162igl.20.1396559133237; Thu, 03 Apr 2014 14:05:33 -0700 (PDT) Received: by 10.64.229.66 with HTTP; Thu, 3 Apr 2014 14:05:33 -0700 (PDT) X-Originating-IP: [73.180.137.82] Date: Thu, 3 Apr 2014 17:05:33 -0400 Message-ID: From: James Galvin To: "eppext@ietf.org" Content-Type: multipart/alternative; boundary=089e01176cad0b79e204f629c3f0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/AS8gtokcpl7-rMa1jFxiCZbwVE8 Subject: [eppext] minutes of meeting, Thursday, 6 March 2014 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, 03 Apr 2014 21:05:46 -0000 --089e01176cad0b79e204f629c3f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First, thank you to Alexander Mayrhofer for taking notes during our meeting. He did an excellent job. He provided his notes immediately after the meeting and I delayed until now to distribute them to the working group for review. I did an editorial review of the minutes, expanding acronyms and creating complete sentences. If there are any mistakes I take responsibility for that. I left the format as a recording of the dialogue. If folks would prefer this be different please comment on this. These are due for the proceedings tomorrow, Friday, 4 April. Folks should read through this, especially if you spoke, and confirm that you are accurately represented. This chair takes responsibility for the delay in distributing these. I will do better in the future, if we actually have another meeting! Thanks, Jim -------- begin meeting minutes eppext =3D=3D=3D=3D=3D=3D Jim Galvin, Antoin Verschuuren Meeting opens at 17:02 Notetakers & Scribes available. Note Well is shown on the screen Agenda slide ------------ 0. Welcome and charter (Jim/Antoin 10 min.) 1. draft-ietf-eppext-reg (Scott Hollenbeck 30 min.) 2. draft-ietf-eppext-keyrelay (Miek Gieben 10 min.) 3. draft-ietf-eppext-launchphase (Gavin Brown 10 min.) 4. draft-ietf-eppext-tmch-smd (Gustavo Lozano 10 min.) 5. draft-ietf-eppext-idnmap (Francisco/Luis Enrique* 10 min.) (*Editors did not submit issues) 6. AOB eppext-idnmap will be dropped from agenda - none of the presenters are here and there are no issues at this time. No further agenda comments. 0. EPPEXT Charter slide ----------------------- As this is the first meeting of the working group the charter is displayed as a reminder of the scope of our work and set the stage for our discussions. Jim notes that the charter mentions individual internet-drafts rather than working group drafts. 1. Extension Registry (Scott) 17:08 ----------------------------------- draft-ietf-eppext-reg: Specifies creation registry plus definition of policy; Based heavily on RFC5226. Current proposal is "specification required" with "designated expert". Question for discussion: - Is Specification Required ok? Pete Resnick: IESG asks "why is first-come-first-served" not possible? Alex: FCFS wouldn't gurantee that specification for the extension is available. Pete: What if i do my private extension, and want an identifier? Scott: It's not about the identifier, it's about de-duplication. James Gould: If we want to prevent collisions, why do not use "RFC required"? Pete: Barry will come and ask why do you really need an RFC. Why don't register "duplicates" because someone uses them? Scott: Correct, document is missing text that describes what the designated expert is supposed to do. Experts will probably be a group of persons, mailing list will be kept open and serve as the venue. Chris Wright: In reference to FCFS, definitely don't want RFC required. Fundamentally against the situation where an expert can refuse work because there's already work on similar items. Frederico Neves: I want a registry where I can look up what's there. Antoin: Expert Review means that people with new ideas can be pointed to existing solutions. Scott: Charter provides rationale why this working group is needed. Patrik (Faltstr=C3=B6m) said he had to implement the same function 3 times. Expert Review has human interaction built in - could also agree that both extensions go in. Chris: If they don't what do I do? Pete: Appeals go to the IESG. But IESG expects that Experts act according to the rules of that RFC. There is something "between", which is Expert Review. Alex: Yep, Experts Review works well for URI schemes. Jim: What if we consider harmonization as a service to the community? FCFS is one extreme, other extreme is trying to "merge" similar extensions? Pete: Policy can be very creative (eg. column with "level of acceptance" in the registry). Chris: "Standardizing" of existing work will be massive effort for both registries and registrars. Scott: We are *registering* not *standardizing*. Chris: RFC5226 says for expert review the expert could deny entry because of duplication - that is what I'm objecting to. Scott: Instruction to Expert can be very creative. Gavin Brown: IPR considerations: "specification required" could imply IPR-laden documents - registry could then implement it, and registrar could be forced to violate IPR - can we add into the specification that IPR needs to be disclosed? Pete: Even RFCs can have IPR against that - we ask people to disclose it, but it exists no matter whether or not people disclose it. James Gould: We would need some "outreach" to get people to document. Scott: Try to find what's out there, and try harmonization on new work. Jim: My assessment of the group is that we're not leaning towards "harmonization". We're closer to FCFS with refusal for "document completeness" only. Chris: A checkbox of "documentation is complete" should be good enough. Sense of the Room: Hum if you agree: We want a registry. We want complete technical specifications. Group strongly in favor, noone against. Pete: "Legacy" extensions: Do they need specifications, or can they be marked with "does not exist, but well known"? Scott: At least they're written in XML Schema. So a technical specification might not be avilable, but some form of documentation exists. Antoin: What about taking things out of the registry, eg. when the registry migrates to another solution? Jim: Since we're running short of time let's discuss on the list: What has to be in the checkbox to make the spec pass. Scott: Does "specification" means an RFC5226 policy, or something else? 2. EPP Keyrelay --------------- Goal: When domain names are transferred, transfer the ZSK from old to new registrar (draft by Peter Koch). Problem is the communication path between registrars does not exist. "keyrelay" uses the registry as a 3rd-party trusted channel to communicate. We are doing transfers successfully using this under .NL. We are not aware of any outstanding issues. We want to go to WGLC. Scott: I just want to note that the documents are not really a "-00" document; they are pretty mature. Gavin Brown: Security consideration: what is being transported? Answer: Just the public key. Dan York: Fully in support, that's exactly what the registry is supposed to do. Chris: How many registrars? Antoin: 4. Pete: This is an unusual working group, because the document is not fully reviewed in-working-group, and rather here for "registration mechanics". PROTO review will need to reflect this properly. James Mitchell: Standardization does not necessarily foster interopability, eg. the requirement for authinfo in this extension allows for variety. Pete: Having "implementation status" helps to show community support - could be part of shepherding information. Chris: Even core EPP allows for so many choices that harmonization is even hard for the EPP core. Different problem, but do we want to address this? James Cole (?): Curious why this is a protocol rather than a object extension? James Gould: I had an identical question. This feels like it's tied to the domain, why not a "domain update"? Antoin: Idea was to extend it beyond keyrelay (but said no in the draft itself). Jay: Why not call it "relay" instead of "key relay"? How specific or how generic is it? Miek: We wanted to fix that specific problem, not the generic problem. Dan: Could we list registrars that support this (in spite of the marketing issue)? Pete: RFC6982 describes an implementation report that goes into the document itself. Patrik Wallstr=C3=B6m: Charter Question: We have a limited number of extensions - I might have another one - do we have to update the charter? Jim: Yes, we would have to negotiate with ADs and recharter. However depending on the registry policy that might not be necessary - the working group could go away and new extensions could still be registered. Pete: I just need to say that "groups with EXT in name" tend to live forever; that's why the charter was defined the way it is. James Gould: Why not specify times in seconds, and other periods differently? Jim (Chair): We have a few issues to discuss on list, not yet at WGLC, but close. 3. Launch Phase Document ------------------------ Gavin Brown Developed by Cloud Registry, later implemented by CentralNIC, process began in 2011 to standardaze it, 15 revisions so far. Contains Sunrise, Trademark Claims Period, and Landrush - implements registry-registrar functions. Has two dependencies on SMD document, another is the TMCH functional specification - functional specification is just an informational reference. Outstanding issues: - Async ACK Verification model - not supported at the moment. Shall we do that? Alex: Keep that out of the draft, it's already complicated enough and looks logical: Verification at time when domain create comes in. James: If somebody wants to do that, would they need to create a duplicate? Gavin: No, they would need to describe their one transaction. Chris: We used completely different extensions, not this. We could have lots to say about this, but we don't use it. Whether or not we say something depends on outcome of the first document (duplicate issue). Gavin: Might be the case that once. James Gould: It could be done outside of EPP. Gavin: Yes. Multiple Status issue: Text says that multiple statuses are possible Alex: Flowchart does not allow multiple statuses, text should be corrected. Also, subphase definition conflicts. James Gould: Can be used to define a subphase or a new phase. Jim (Chair): We will decide about progress with this document once we decide about the first document. Let's take comments on the list. Implementations: Neustar uses this. 4. SMD document --------------- Gustavo Lozano SMD: It's blob of XML plus a signature showing that a trademark validator has validated a mark. Shows a slide of the "TMCH ecosystem". Gavin: Why is there an "unbounded" number of contacts? Gustavo: The maximum you will see is currently *2*. Gavin: Type Trademark? James Gould: Any updates for qualified launch program? Gustavo: Will be updates, but it's premature. Chris: It's an XML schema, but not an EPP extension? Would that go into the registry? Scott: If it was normatively referenced in the extension it uses, it would be in. 6. AOB ------ Gavin Brown: Extensions have URNs, but version is always 1.0 - please do version number your namespace - this would allow for inclusion of the version in the greeting. Jim: Include that into the registry specification? Scott nods. James Gould: Bumping the namespace would create implementation issues. Chris: Publishing a new version of a draft might not necessarily need to bump the version number. It only needs to be done when there are incompatible changes. Jim: I agree - a non-backwards-compatible change would bump the version number. Meeting concludes. --089e01176cad0b79e204f629c3f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, thank you to Alexander Mayrhofer for taki= ng notes during our meeting.=C2=A0 He did an excellent job.

He= provided his notes immediately after the meeting and I delayed until now t= o distribute them to the working group for review.=C2=A0 I did an editorial= review of the minutes, expanding acronyms and creating complete sentences.= =C2=A0 If there are any mistakes I take responsibility for that.

I left the format as a recording of the dialogue.=C2=A0 If f= olks would prefer this be different please comment on this.
<= br>
These are due for the proceedings tomorrow, Friday, 4 April.<= br>
Folks should read through this, especially if you spoke, and confirm th= at you are accurately represented.

This chair takes respo= nsibility for the delay in distributing these.=C2=A0 I will do better in th= e future, if we actually have another meeting!

Thanks,

Jim

-------- begin meeting minutes
=
eppext
=3D=3D=3D=3D=3D=3D

Jim Galvin, Antoin Verschuuren
<= br>Meeting opens at 17:02

Notetakers & Scribes available.
Note Well is shown on the screen


Agenda slide
------------

0. Welcome and charter (Jim/Ant= oin 10 min.)

1. draft-ietf-eppext-reg (Scott Hollenbeck 30 min.)
=
2. draft-ietf-eppext-keyrelay (Miek Gieben 10 min.)

3. draft-iet= f-eppext-launchphase (Gavin Brown 10 min.)

4. draft-ietf-eppext-tmch-smd (Gustavo Lozano 10 min.)

5. draft-= ietf-eppext-idnmap (Francisco/Luis Enrique* 10 min.)
=C2=A0=C2=A0 (*Edit= ors did not submit issues)

6. AOB


eppext-idnmap will be d= ropped from agenda - none of the presenters are
here and there are no issues at this time.

No further agenda comment= s.


0. EPPEXT Charter slide
-----------------------

As = this is the first meeting of the working group the charter is
displayed = as a reminder of the scope of our work and set the stage for
our discussions.

Jim notes that the charter mentions individual inte= rnet-drafts rather
than working group drafts.


1. Extension Re= gistry (Scott) 17:08
-----------------------------------

draft-ie= tf-eppext-reg: Specifies creation registry plus definition of
policy; Based heavily on RFC5226.

Current proposal is "specific= ation required" with "designated expert".

Question fo= r discussion:

=C2=A0- Is Specification Required ok?

=C2=A0Pet= e Resnick: IESG asks "why is first-come-first-served" not possibl= e?

=C2=A0Alex: FCFS wouldn't gurantee that specification for the exten= sion is
=C2=A0available.

=C2=A0Pete: What if i do my private exte= nsion, and want an identifier?

=C2=A0Scott: It's not about the i= dentifier, it's about de-duplication.

=C2=A0James Gould: If we want to prevent collisions, why do not use &qu= ot;RFC
=C2=A0required"?

=C2=A0Pete: Barry will come and ask = why do you really need an RFC. Why
=C2=A0don't register "duplic= ates" because someone uses them?

=C2=A0Scott: Correct, document is missing text that describes what the<= br>=C2=A0designated expert is supposed to do. Experts will probably be a gr= oup
=C2=A0of persons, mailing list will be kept open and serve as the ve= nue.

=C2=A0Chris Wright: In reference to FCFS, definitely don't want RFC
= =C2=A0required. Fundamentally against the situation where an expert can
= =C2=A0refuse work because there's already work on similar items.
=C2=A0Frederico Neves: I want a registry where I can look up what's th= ere.

=C2=A0Antoin: Expert Review means that people with new ideas can be poi= nted
=C2=A0to existing solutions.

=C2=A0Scott: Charter provides r= ationale why this working group is
=C2=A0needed. Patrik (Faltstr=C3=B6m)= said he had to implement the same function
=C2=A03 times. Expert Review has human interaction built in - could also=C2=A0agree that both extensions go in.

=C2=A0Chris: If they don= 9;t what do I do?

=C2=A0Pete: Appeals go to the IESG. But IESG expec= ts that Experts act
=C2=A0according to the rules of that RFC. There is something "between&= quot;,
=C2=A0which is Expert Review.

=C2=A0Alex: Yep, Experts Rev= iew works well for URI schemes.

=C2=A0Jim: What if we consider harmo= nization as a service to the community?
=C2=A0FCFS is one extreme, other extreme is trying to "merge" sim= ilar
=C2=A0extensions?

=C2=A0Pete: Policy can be very creative (e= g. column with "level of
=C2=A0acceptance" in the registry).
=C2=A0Chris: "Standardizing" of existing work will be massi= ve effort for
=C2=A0both registries and registrars.

=C2=A0Scott: We are *registeri= ng* not *standardizing*.

=C2=A0Chris: RFC5226 says for expert review= the expert could deny entry
=C2=A0because of duplication - that is what= I'm objecting to.

=C2=A0Scott: Instruction to Expert can be very creative.

=C2=A0G= avin Brown: IPR considerations: "specification required" could im= ply
=C2=A0IPR-laden documents - registry could then implement it, and re= gistrar
=C2=A0could be forced to violate IPR - can we add into the specification=C2=A0that IPR needs to be disclosed?
=C2=A0
=C2=A0Pete: Even RFCs c= an have IPR against that - we ask people to disclose
=C2=A0it, but it ex= ists no matter whether or not people disclose it.

=C2=A0James Gould: We would need some "outreach" to get peopl= e to document.

=C2=A0Scott: Try to find what's out there, and tr= y harmonization on new work.

=C2=A0Jim: My assessment of the group i= s that we're not leaning towards
=C2=A0"harmonization". We're closer to FCFS with refusal for = "document
=C2=A0completeness" only.

=C2=A0Chris: A chec= kbox of "documentation is complete" should be good
=C2=A0enoug= h.

=C2=A0Sense of the Room: Hum if you agree:

=C2=A0We want a registry. We want complete technical specifications.
=C2=A0Group strongly in favor, noone against.

=C2=A0Pete: "= ;Legacy" extensions: Do they need specifications, or can they
=C2= =A0be marked with "does not exist, but well known"?

=C2=A0Scott: At least they're written in XML Schema. So a technical=
=C2=A0specification might not be avilable, but some form of documentati= on
=C2=A0exists.

=C2=A0Antoin: What about taking things out of th= e registry, eg. when the
=C2=A0registry migrates to another solution?

=C2=A0Jim: Since we'= ;re running short of time let's discuss on the list:
=C2=A0What has = to be in the checkbox to make the spec pass.

=C2=A0Scott: Does "= ;specification" means an RFC5226 policy, or something else?


2. EPP Keyrelay
---------------

Goal: When domain names a= re transferred, transfer the ZSK from old to
new registrar (draft by Pet= er Koch).=C2=A0 Problem is the communication
path between registrars doe= s not exist.

"keyrelay" uses the registry as a 3rd-party trusted channel t= o
communicate. We are doing transfers successfully using this under .NL.=

We are not aware of any outstanding issues. We want to go to WGLC.<= br>
Scott: I just want to note that the documents are not really a "-0= 0"
document; they are pretty mature.

Gavin Brown: Security c= onsideration: what is being transported?

Answer: Just the public key= .

Dan York: Fully in support, that's exactly what the registry is
= supposed to do.

Chris: How many registrars?

Antoin: 4.
Pete: This is an unusual working group, because the document is not
fully reviewed in-working-group, and rather here for "registration
= mechanics". PROTO review will need to reflect this properly.

Ja= mes Mitchell: Standardization does not necessarily foster
interopability= , eg. the requirement for authinfo in this extension
allows for variety.

Pete: Having "implementation status" h= elps to show community support -
could be part of shepherding informatio= n.

Chris: Even core EPP allows for so many choices that harmonizatio= n is
even hard for the EPP core. Different problem, but do we want to
address= this?

James Cole (?): Curious why this is a protocol rather than a = object
extension?

James Gould: I had an identical question. This = feels like it's tied to
the domain, why not a "domain update"?

Antoin: Idea was to= extend it beyond keyrelay (but said no in the
draft itself).

Jay= : Why not call it "relay" instead of "key relay"? How s= pecific or
how generic is it?

Miek: We wanted to fix that specific problem, not= the generic problem.

Dan: Could we list registrars that support thi= s (in spite of the
marketing issue)?

Pete: RFC6982 describes an i= mplementation report that goes into the
document itself.

Patrik Wallstr=C3=B6m: Charter Question: We have a = limited number of
extensions - I might have another one - do we have to = update the
charter?

Jim: Yes, we would have to negotiate with ADs= and recharter. However
depending on the registry policy that might not be necessary - the
worki= ng group could go away and new extensions could still be
registered.
=
Pete: I just need to say that "groups with EXT in name" tend = to live
forever; that's why the charter was defined the way it is.

James= Gould: Why not specify times in seconds, and other periods
differently?=

Jim (Chair): We have a few issues to discuss on list, not yet at WG= LC,
but close.


3. Launch Phase Document
------------------------<= br>
Gavin Brown

Developed by Cloud Registry, later implemented by= CentralNIC, process
began in 2011 to standardaze it, 15 revisions so fa= r.

Contains Sunrise, Trademark Claims Period, and Landrush - implementsregistry-registrar functions.

Has two dependencies on SMD document,= another is the TMCH functional
specification - functional specification= is just an informational
reference.

Outstanding issues:

- Async ACK Verification model= - not supported at the moment. Shall we do that?

Alex: Keep that ou= t of the draft, it's already complicated enough and
looks logical: V= erification at time when domain create comes in.

James: If somebody wants to do that, would they need to create a duplic= ate?

Gavin: No, they would need to describe their one transaction.
Chris: We used completely different extensions, not this. We could have lots to say about this, but we don't use it. Whether or not we
= say something depends on outcome of the first document (duplicate
issue)= .

Gavin: Might be the case that once.

James Gould: It could b= e done outside of EPP.

Gavin: Yes.

Multiple Status issue: Text says that multiple statu= ses are possible

Alex: Flowchart does not allow multiple statuses, t= ext should be
corrected.=C2=A0 Also, subphase definition conflicts.
<= br> James Gould: Can be used to define a subphase or a new phase.

Jim (C= hair): We will decide about progress with this document once we
decide a= bout the first document. Let's take comments on the list.

Implem= entations: Neustar uses this.


4. SMD document
---------------

Gustavo Lozano

SMD= : It's blob of XML plus a signature showing that a trademark
validat= or has validated a mark.

Shows a slide of the "TMCH ecosystem&q= uot;.

Gavin: Why is there an "unbounded" number of contacts?
Gustavo: The maximum you will see is currently *2*.

Gavin: Type Tra= demark?

James Gould: Any updates for qualified launch program?

Gustavo: Will be updates, but it's premature.

Chris: It'= s an XML schema, but not an EPP extension? Would that go
into the regist= ry?

Scott: If it was normatively referenced in the extension it uses= , it
would be in.


6. AOB
------

Gavin Brown: Extensions hav= e URNs, but version is always 1.0 - please
do version number your namesp= ace - this would allow for inclusion of
the version in the greeting.

Jim: Include that into the registry specification? Scott nods.

J= ames Gould: Bumping the namespace would create implementation issues.
Chris: Publishing a new version of a draft might not necessarily need
to bump the version number.=C2=A0 It only needs to be done when there areincompatible changes.

Jim: I agree - a non-backwards-compatible ch= ange would bump the
version number.


Meeting concludes.
--089e01176cad0b79e204f629c3f0-- From nobody Thu Apr 24 13:21:30 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 142F11A03D9 for ; Thu, 24 Apr 2014 13:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.665 X-Spam-Level: * X-Spam-Status: No, score=1.665 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 00fFfLbUaGJL for ; Thu, 24 Apr 2014 13:21:25 -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 7494D1A03E2 for ; Thu, 24 Apr 2014 13:21:24 -0700 (PDT) Received: from [192.168.0.3] (unknown [94.11.130.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id C2D6B9D72; Thu, 24 Apr 2014 20:21:17 +0000 (UTC) Content-Transfer-Encoding: 7bit From: Gavin Brown Content-Type: multipart/alternative; boundary=Apple-Mail-9500463F-5C8D-4AE7-9023-F43FBCD2F9D4 X-Mailer: iPad Mail (11D167) Message-Id: Date: Thu, 24 Apr 2014 21:21:16 +0100 To: "eppext@ietf.org" Mime-Version: 1.0 (1.0) Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/ZIt4sJa6OFU5dk2QnCn7l0BMHsA Cc: Wil Tan , James Gould Subject: [eppext] draft-eppext-launch and followup from ietf89 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, 24 Apr 2014 20:21:27 -0000 --Apple-Mail-9500463F-5C8D-4AE7-9023-F43FBCD2F9D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi colleagues, There were two outstanding issues with our draft that were presented to the w= orking group at the London meeting: 1. The "multiple statuses" issue. I think there was a definite consensus tha= t the draft be changed to only permit a single status. 2. The "asynchronous acknowledgement" issue. There was a lot more discussion= about it, but the impression I got was that there was a consensus in the ro= om that it was not necessary for us to amend our draft to support the "async= hronous acknowledgement" model supported by the TMCH functional specificatio= n. My co-authors and I would like to make progress on these issues, so we're as= king for any further feedback on the above. Thanks, Gavin. -- 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 compa= ny number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.= --Apple-Mail-9500463F-5C8D-4AE7-9023-F43FBCD2F9D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi colleague= s,

There were two outstanding issues with our draft= that were presented to the working group at the London meeting:
<= br>
1. The "multiple statuses" issue. I think there was a definite= consensus that the draft be changed to only permit a single status.

2. The "asynchronous acknowledgement" issue. There was a l= ot more discussion about it, but the impression I got was that there was a c= onsensus in the room that it was not necessary for us to amend our draft to s= upport the "asynchronous acknowledgement" model supported by the TMCH f= unctional specification.

My co-authors and I would l= ike to make progress on these issues, so we're asking for any further feedba= ck on the above.

Thanks,

G= avin.

--
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flex= ible Registry Services
for ccTLD, gTLD and private domain name registries

CentralNic Group plc is a company r= egistered in England and Wales with company number 8576358. Registered Offic= es: 35-39 Moorgate, London, EC2R 6AR.
= --Apple-Mail-9500463F-5C8D-4AE7-9023-F43FBCD2F9D4-- From nobody Fri Apr 25 05:39:17 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6869B1A04B7 for ; Fri, 25 Apr 2014 05:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 pwPHfuKDs7Wz for ; Fri, 25 Apr 2014 05:39:13 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 78FBE1A048D for ; Fri, 25 Apr 2014 05:39:10 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKU1pXZhAWlAmZvNyOWWq7Lp3IBfD/BMxA@postini.com; Fri, 25 Apr 2014 05:39:06 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 s3PCd1Yq018292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 08:39:01 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 25 Apr 2014 08:39:00 -0400 From: "Gould, James" To: Gavin Brown , "eppext@ietf.org" Thread-Topic: draft-eppext-launch and followup from ietf89 Thread-Index: AQHPX/rCiOHGrTRjqk6bRwlCXiZ9A5shR6QA Date: Fri, 25 Apr 2014 12:39:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CF7EF8AA5DB4Cjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/1QjoHH28E-NrLhuVmmF1ipb6hrU Cc: Wil Tan Subject: Re: [eppext] draft-eppext-launch and followup from ietf89 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, 25 Apr 2014 12:39:15 -0000 --_004_CF7EF8AA5DB4Cjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CF7EF8AA5DB4Cjgouldverisigncom_" --_000_CF7EF8AA5DB4Cjgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gavin, I got the same impression that you did from the meeting, which was to chang= e the draft to remove text associated with support for the combining of sta= tus values, and to not change the draft to support the =93asynchronous ackn= owledgement=94 model. -- JG [cid:1626FFA1-C0DC-42F5-97CD-E5D389D0582B] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gavin Brown > Date: Thursday, April 24, 2014 at 4:21 PM To: "eppext@ietf.org" > Cc: James Gould >, Wil Tan = > Subject: draft-eppext-launch and followup from ietf89 Hi colleagues, There were two outstanding issues with our draft that were presented to the= working group at the London meeting: 1. The "multiple statuses" issue. I think there was a definite consensus th= at the draft be changed to only permit a single status. 2. The "asynchronous acknowledgement" issue. There was a lot more discussio= n about it, but the impression I got was that there was a consensus in the = room that it was not necessary for us to amend our draft to support the "as= ynchronous acknowledgement" model supported by the TMCH functional specific= ation. My co-authors and I would like to make progress on these issues, so we're a= sking for any further feedback on the above. Thanks, Gavin. -- 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 comp= any number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. --_000_CF7EF8AA5DB4Cjgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Gavin,

I got the same impression that you did from the meeting, which was to = change the draft to remove text associated with support for the combining o= f status values, and to not change the draft to support the =93asynchronous= acknowledgement=94 model.  

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com


From: Gavin Brown <gavin.brown@centralnic.com>
Date: Thursday, April 24, 2014 at 4= :21 PM
To: "eppext@ietf.org" <= eppext@ietf.org>
Cc: James Gould <jgould@verisign.com>, Wil Tan <wil@cloudregistry.net>
Subject: draft-eppext-launch and fo= llowup from ietf89

Hi colleagues,

There were two outstanding issues with our draft that were presented t= o the working group at the London meeting:

1. The "multiple statuses" issue. I think there was a defini= te consensus that the draft be changed to only permit a single status.

2. The "asynchronous acknowledgement" issue. There was a lot= more discussion about it, but the impression I got was that there was a co= nsensus in the room that it was not necessary for us to amend our draft to = support the "asynchronous acknowledgement" model supported by the TMCH functional specification.

My co-authors and I would like to make progress on these issues, so we= 're asking for any further feedback on the above.

Thanks,

Gavin.

--
Gavin Brown<= /div>
Chief Techno= logy Officer
CentralNic G= roup plc (LSE:CNIC)
Innovative, = Reliable and Flexible Registry Services
for ccTLD, g= TLD and private domain name registries

CentralNic G= roup plc is a company registered in England and Wales with company number 8= 576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
 --_000_CF7EF8AA5DB4Cjgouldverisigncom_-- --_004_CF7EF8AA5DB4Cjgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[53].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[53].png Content-Disposition: inline; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[53].png"; size=4109; creation-date="Fri, 25 Apr 2014 12:39:00 GMT"; modification-date="Fri, 25 Apr 2014 12:39:00 GMT" Content-ID: <1626FFA1-C0DC-42F5-97CD-E5D389D0582B> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CF7EF8AA5DB4Cjgouldverisigncom_-- From nobody Fri Apr 25 06:23: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 5CEB41A04AE for ; Fri, 25 Apr 2014 06:23:17 -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 th6xcl2VwPIX for ; Fri, 25 Apr 2014 06:23:13 -0700 (PDT) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 264241A04B6 for ; Fri, 25 Apr 2014 06:23:12 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKU1phuEZEVRcq9OEpUqcp9CHMIDmLYFyn@postini.com; Fri, 25 Apr 2014 06:23:06 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 s3PDN4YD019575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 09:23:04 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 25 Apr 2014 09:23:03 -0400 From: "Gould, James" To: "Gould, James" , Francisco Obispo Thread-Topic: [eppext] draft-ietf-eppext-idnmap Feedback Thread-Index: AQHPOlT+4eaYxDDdEE+oj57oox5INZrbCyoA///O6wCAALJlAIAAlk4AgAJ59gCAAHwvAIBDhWIA Date: Fri, 25 Apr 2014 13:23:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CF7FD4A25DB7Bjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/S_eSUAn1M4Vi2aZy--LRM7oc7EI Cc: "eppext@ietf.org" , =?Windows-1252?Q?Luis_Mu=F1oz?= Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:23:17 -0000 --_004_CF7FD4A25DB7Bjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CF7FD4A25DB7Bjgouldverisigncom_" --_000_CF7FD4A25DB7Bjgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have not received any feedback publicly or privately on this proposal. A= ny thoughts on this? Thanks, -- JG [cid:790FBBC9-7B94-4961-AC24-2D07A94F8E37] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , James Gould = > Date: Thursday, March 13, 2014 at 10:16 AM To: Francisco Obispo > Cc: "eppext@ietf.org" >, Luis Mu=F1oz = > Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback Francisco, How about supporting two models in draft-ietf-eppext-idnmap that matches th= e current and desired models supported by the servers, which is to support = a choice of language or table? The table element is intended to be a 1-to-= 1 match with the language or script tables posted to IANA and language is t= he language code per ISO 639-2. Ideally the choice would be explicitly def= ined in the XML schema, but to minimize the changes, it could look like bel= ow: Extensible Provisioning Protocol v1.0 domain name extension schema for IDN Table selection. The text for the create could specify the use of either or <= idn:table> element based on server policy. Ideally a element= would be defined in the XML schema that made and a choice. Below is an example of the create with the language: xn--espaol-zwa.example.com 2 ns1.example.net ns2.example.net jd1234 sh8013 sh8013 2fooBAR SPA español.example.com 123456 Below is an example of the create with the table (script table in this inst= ance that can be prefixed with http://www.iana.org/domains/idn-tables/ and = postfixed with .txt): xn--espaol-zwa.example.com 2 ns1.example.net ns2.example.net jd1234 sh8013 sh8013 2fooBAR com_latn_1.1 español.example.com 123456 For servers that support the language model, the info response should retur= n both the language sent as well as the resulting table that can be mapped = to the IANA language or script table: Command completed successfully xn--espaol-zwa.example.com EXAMPLE1-REP jd1234 sh8013 sh8013 ns1.example.com ns1.example.net ClientX ClientY 1999-04-03T22:00:00.0Z ClientX 1999-12-03T09:00:00.0Z 2005-04-03T22:00:00.0Z 2000-04-08T09:00:00.0Z 2fooBAR SPA com_latn_1.1 español.example.com ABC-12345 54322-XYZ -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/12/14, 10:51 PM, "Francisco Obispo" > wrote: On Mar 11, 2014, at 10:02 AM, Gould, James > wrote: Francisco, I have the following issues with draft-ietf-eppext-idnmap that I would like= addressed: =95 The should be optional in the info response. We can make it optional. I=92ll add that to the next draft. =95 The is too flexible at this point. Based on draft-ietf-epp= ext-idnmap the registrars have no way of knowing what table values are requ= ired for any one server. This is a opportunity for the eppext WG to define= a standard model. My concern is related to clients having to deal with an infinite number of = server policies and schemes for the values. Are there any regi= strars out there that have the same concern? Well registrars currently don=92t have a way of knowing a lot of things, an= d even though I agree with you on the identifiers, there is no guarantee th= at the same identifier will result in the same code points, because that=92= s a registry policy decision. I don=92t want to create the impression that if you pass =93es=94 as the ta= ble identifier, you=92ll get the same results across all registries, in fac= t if you look at the tables on the IANA website, multiple registries have d= ifferent identifiers, and in some cases the code points don=92t even match. So even though I agree with you in concept, I think that it is unpractical = to try to standardize it. Francisco -- Francisco Obispo CTO - Registry Operations fobispo@uniregistry.com PGP Key ID: 0xB38DB1BE --_000_CF7FD4A25DB7Bjgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <72DD28CAF65BC44CA4B4D0016F5964FC@verisign.com> Content-Transfer-Encoding: quoted-printable
I have not received any feedback publicly or privately on this proposa= l.  Any thoughts on this?    

Thanks,

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com


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

Francisco,

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

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

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

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

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

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

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

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

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



-- 
 
JG
 

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



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


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

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

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

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

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

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

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

Francisco


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


 --_000_CF7FD4A25DB7Bjgouldverisigncom_-- --_004_CF7FD4A25DB7Bjgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[1].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[1].png Content-Disposition: inline; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[1].png"; size=4109; creation-date="Fri, 25 Apr 2014 13:23:02 GMT"; modification-date="Fri, 25 Apr 2014 13:23:02 GMT" Content-ID: <790FBBC9-7B94-4961-AC24-2D07A94F8E37> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CF7FD4A25DB7Bjgouldverisigncom_-- From nobody Fri Apr 25 06:23:36 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AF21A04B8 for ; Fri, 25 Apr 2014 06:23:32 -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 HXNOumCImPqX for ; Fri, 25 Apr 2014 06:23:27 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 803EB1A04AE for ; Fri, 25 Apr 2014 06:23:24 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKU1phxk1Lqt3Wr/DRajqSHVclP4n/gkQU@postini.com; Fri, 25 Apr 2014 06:23:20 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s3PDNETo019601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 09:23:17 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 25 Apr 2014 09:23:06 -0400 From: "Gould, James" To: "Gould, James" , Antoin Verschuren , "eppext@ietf.org" Thread-Topic: [eppext] draft-ietf-eppext-keyrelay-00 Feedback Thread-Index: AQHPPTZwhTqnVBiC0UudESqSbZQK05rcFYQAgALzWICAAEbDgIBDSP2A Date: Fri, 25 Apr 2014 13:23:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CF7FD9B15DBAAjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/Y9KVQnc60UIASeNZmn0zT-Fh2YU 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: Fri, 25 Apr 2014 13:23:33 -0000 --_004_CF7FD9B15DBAAjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CF7FD9B15DBAAjgouldverisigncom_" --_000_CF7FD9B15DBAAjgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have not received any feedback publicly or privately on the options in th= e message below. Any thoughts on this? Thanks, -- JG [cid:EA6DABC5-C482-4C2A-99B9-B4DC8E3C6A9B] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , James Gould = > Date: Thursday, March 13, 2014 at 1:52 PM To: Antoin Verschuren >, "eppext@ietf.org" > Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback 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_CF7FD9B15DBAAjgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I have not received any feedback publicly or privately on the options = in the message below.  Any thoughts on this?   

Thanks, 

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com


From: <Gould>, James Gould &l= t;jgould@verisign.com>
Date: Thursday, March 13, 2014 at 1= :52 PM
To: Antoin Verschuren <antoin.verschuren@sidn.nl>, &q= uot;eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] draft-ietf-ep= pext-keyrelay-00 Feedback

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


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

- --
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
-----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_CF7FD9B15DBAAjgouldverisigncom_-- --_004_CF7FD9B15DBAAjgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[2].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[2].png Content-Disposition: inline; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[2].png"; size=4109; creation-date="Fri, 25 Apr 2014 13:23:12 GMT"; modification-date="Fri, 25 Apr 2014 13:23:12 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CF7FD9B15DBAAjgouldverisigncom_-- From nobody Mon Apr 28 02:58: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 BB1E21A093A for ; Mon, 28 Apr 2014 02:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.843 X-Spam-Level: X-Spam-Status: No, score=0.843 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeT1KXExyIZY for ; Mon, 28 Apr 2014 02:58:34 -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 D8E5C1A0936 for ; Mon, 28 Apr 2014 02:58:33 -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=YldaHzmOMDgbPWjpiwN37DdtdjLm+isoUZ9oBacuAv8=; b=mdsnkNMnBxt0UwmZ3OB8df9C3sp8hl9SJ7VWmwunhWbUx5cYk7CxxTlYNYG6iq4nHlUECWMkFLB1/WV6PyjO+LoRWeKJx6ErSffIi9UN2QYXgCooKgWzH0owRJe16CoH7IGkh5udEtoYx1YKL4f+wk5YnzDSKYSKNGgaIT1BGvM= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s3S9wWAo021900-s3S9wWAq021900 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL); Mon, 28 Apr 2014 11:58:32 +0200 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; Mon, 28 Apr 2014 11:58:27 +0200 Message-ID: <535E2642.3010104@sidn.nl> Date: Mon, 28 Apr 2014 11:58:26 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.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.222] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/nj7kumLH19z7oFGhHQGrqyOSOCM 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: Mon, 28 Apr 2014 09:58:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 25-04-14 15:23, Gould, James schreef: > I have not received any feedback publicly or privately on the > options in the message below. Any thoughts on this? Hi James, First, thank you for your feedback and extensive suggestions. I did receive private feedback to your suggestions, but was not able to digest it yet due to a lack of time, sorry about that. I've asked the commenter to post on-list, but have not been able to get back on that. The major comments to your suggestions as I understand them were: This suggest an update of a domain object in the registry DB, but a keyrelay does not update anything in the DB as it is not submitted by the registrar of record. A keyrelay only reads object information and uses that to relay data. The authors can live with the suggested changes to the response. You'll get the domain info and key info in the response. This is where both the authors and some others have problems with. A create suggests you're creating an object in the registry DB, but we don't. One of the requirements for keyrelay was that the DB would be left unharmed, no special tables or attributes for keyrelay. I understand the difference between the message syntax and the actual process flow, but this does seem to confuse people. Are there any other extensions that use a create or update syntax when there is no authorization or actual object change? Is it clear enough in the EPP RFC's that there is this separation of syntax and meaning? RFC 5730 section 2.9 states by definition that and actually change objects. The authors feel keyrelay does not fit in any of the current protocol commands. It's not a session management command, not a query command, and not an object transform command. So keyrelay is actually a new 4th protocol command type which can best be described as a communication command. Another comment was about the double use of the domain name in the message: example.org ..... example.org which seemed unnessecary. I'll ask my co-authors to follow up on this, but in the mean time, I would like to hear others comment on the potential violation of RFC 5730 section 2.9 by your suggested syntax on-list. > From: , James Gould > Date: Thursday, March 13, 2014 at > 1:52 PM To: Antoin Verschuren >, "eppext@ietf.org > " > Subject: Re: [eppext] > draft-ietf-eppext-keyrelay-00 Feedback > > 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 relay commands and responses. Technically > draft-ietf-eppext-keyrelay uses both the protocol 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 > specification. The best way to describe the use of the object > and command-response 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 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. > > > > > > xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" > > xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" > > xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"> > > > > > > > > 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. > > > > > > xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" > > xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" > > xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"> > > > > > > Command completed successfully; ack to dequeue > > > > > > 1999-04-04T22:01:00.0Z > > Key Relay action completed successfully. > > > > > > > xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > > 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 get information via the info command and response. The > poll message is simply a key relay info response. > > *Key Relay Command *using a Key Relay Create Command. > > xmlns="urn:ietf:params:xml:ns:epp-1.0" > xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" > xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" > xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"> > > example.org > 256 > 3 8 > cmlraXN0aGViZXN0 > > JnSdBAZSxxzJ > P1M13D > > 123456 > > *Key Relay Poll Response* * * xmlns="urn:ietf:params:xml:ns:epp-1.0" > xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" > xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" > xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"> > 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 > associated Response (example provided already with the poll > response). > > xmlns="urn:ietf:params:xml:ns:epp-1.0" > xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"> > example.org > 123456 > * * > > In looking at the samples, I actually like the Object Extension > the best. I can provide the XSD’s 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: > > 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) iQEcBAEBAgAGBQJTXiZCAAoJEDqHrM883Agn7mEH/1LBGxWRJW3tKeahqRnR57r3 Lr+8y7EEYwA52yOk4aw7F+LcafSE9xylNw4z7pHuzZ1axV05qW1B4wEHDcTtLq8l phq0NY50VIAVB08ICrjT4TAljEcxHkVvoFOdoJxt5vclG6wUFF3Rq502oYYIuY1s EUBJyYxSCogpic+DgnULAqS+0+jQ62n8lGzlOYxJN5eJD2+6wrtTpNukop+IXD5z v2Ima6NNU9ywR+I+QuWbEFxQxQXfl2GUn5RGzAGAJv8AV2merbc89sClboxCBZ6M ZUY9HPyO5T7v+B583yxwm4dnCMRboBEmZtpkyZ/rKnESl44syxZJNNkD0VDv6WI= =xA/Q -----END PGP SIGNATURE----- From nobody Mon Apr 28 07:13:30 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 E93BC1A0A6E for ; Mon, 28 Apr 2014 07:13:25 -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 8p52aD5sJrwY for ; Mon, 28 Apr 2014 07:13:21 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id 560D61A1F20 for ; Mon, 28 Apr 2014 07:13:17 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKU15h/DPRS0U9THWok7pFQj/3FQxEgqB9@postini.com; Mon, 28 Apr 2014 07:13:19 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 s3SEDCq9028562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 10:13:16 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 10:13:12 -0400 From: "Gould, James" To: Antoin Verschuren , "eppext@ietf.org" Thread-Topic: [eppext] draft-ietf-eppext-keyrelay-00 Feedback Thread-Index: AQHPPTZwhTqnVBiC0UudESqSbZQK05rcFYQAgALzWICAAEbDgIBDSP2AgATA0QCAAAQzAA== Date: Mon, 28 Apr 2014 14:13:11 +0000 Message-ID: In-Reply-To: <535E2642.3010104@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_CF83D24B5DC99jgouldverisigncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/xw5XSGnEWoHaDxn0mefb86w5LUA 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: Mon, 28 Apr 2014 14:13:26 -0000 --_000_CF83D24B5DC99jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Antoin, My feedback is below. -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/28/14, 5:58 AM, "Antoin Verschuren" > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 25-04-14 15:23, Gould, James schreef: I have not received any feedback publicly or privately on the options in the message below. Any thoughts on this? Hi James, First, thank you for your feedback and extensive suggestions. I did receive private feedback to your suggestions, but was not able to digest it yet due to a lack of time, sorry about that. I've asked the commenter to post on-list, but have not been able to get back on that. The major comments to your suggestions as I understand them were: This suggest an update of a domain object in the registry DB, but a keyrelay does not update anything in the DB as it is not submitted by the registrar of record. A keyrelay only reads object information and uses that to relay data. The Key Relay is associated with the domain name. A Key Relay Command, by = overriding the update with a new verb (=93Key Relay=94), does persist infor= mation to the registry database to relay to the losing hosting provider in = the form of a poll message. Using the Command-Response Extension, you're d= efining a new command verb, similar to what is done with a protocol extensi= on, but following the pattern that has been followed with other extensions = like the RGP extension (e.g. restore command). The authors can live with the suggested changes to the response. You'll get the domain info and key info in the response. This is where both the authors and some others have problems with. A create suggests you're creating an object in the registry DB, but we don't. One of the requirements for keyrelay was that the DB would be left unharmed, no special tables or attributes for keyrelay. I believe you are adding more requirements around an object extension than = exists. If the Key Relay was an object extension, you are creating a Key R= elay message to the losing hosting provider. This is similar to sending an= e-mail by creating an e-mail message and sending it to your SMTP server. = You are persisting / creating information in the registry database in the f= orm of a poll message in this instance. I understand the difference between the message syntax and the actual process flow, but this does seem to confuse people. Are there any other extensions that use a create or update syntax when there is no authorization or actual object change? Is it clear enough in the EPP RFC's that there is this separation of syntax and meaning? RFC 5730 section 2.9 states by definition that and actually change objects. The authors feel keyrelay does not fit in any of the current protocol commands. It's not a session management command, not a query command, and not an object transform command. So keyrelay is actually a new 4th protocol command type which can best be described as a communication command. A object extension does not require support for all of the transform comman= ds. We have creating custom object extensions that don=92t use all or any = of the transform commands. Examples include: 1. Suggestion Mapping ( http://www.verisigninc.com/assets/epp-sdk/EPP-Su= ggestion-Mapping.pdf ) - This is an EPP object extension to support name su= ggestions in the form of a Name Suggestion object that only supports an inf= o command and response. 2. Balance Mapping ( http://www.verisigninc.com/assets/epp-balance-mappi= ng.pdf ) - This is an EPP object extension to support getting the balance, = available credit, and credit limit information in the form of a Balance obj= ect that only supports an info command and response. 3. WhoWas Mapping ( http://www.verisigninc.com/assets/epp-whowas-mapping= .pdf ) - This is an EPP object extension to support getting history informa= tion (e.g. domain, host, contact) information in the form of a WhoWas objec= t that support an info command and response. Another comment was about the double use of the domain name in the message: example.org ..... example.org which seemed unnessecary. In the case of a Key Relay object extension, you can use the element in place of the shorter form , but the descr= iption of the element is the same in being the domain name that the Key Rel= ay is associated with. I'll ask my co-authors to follow up on this, but in the mean time, I would like to hear others comment on the potential violation of RFC 5730 section 2.9 by your suggested syntax on-list. There is no violation of RFC 5730. It comes down to whether you are extend= ing the domain object extension in the form of a Command-Response Extension= , creating a new object extension for the Key Relay message object, or crea= ting a mix of a protocol extension (command) and an object extension (poll = response). From: , James Gould > Date: Thursday, March 13, 2014 at 1:52 PM To: Antoin Verschuren >, "eppext@ietf.org " > Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback 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 relay commands and responses. Technically draft-ietf-eppext-keyrelay uses both the protocol 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 specification. The best way to describe the use of the object and command-response 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 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. 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 get information via the info command and response. The poll message is simply 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 associated 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: 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) iQEcBAEBAgAGBQJTXiZCAAoJEDqHrM883Agn7mEH/1LBGxWRJW3tKeahqRnR57r3 Lr+8y7EEYwA52yOk4aw7F+LcafSE9xylNw4z7pHuzZ1axV05qW1B4wEHDcTtLq8l phq0NY50VIAVB08ICrjT4TAljEcxHkVvoFOdoJxt5vclG6wUFF3Rq502oYYIuY1s EUBJyYxSCogpic+DgnULAqS+0+jQ62n8lGzlOYxJN5eJD2+6wrtTpNukop+IXD5z v2Ima6NNU9ywR+I+QuWbEFxQxQXfl2GUn5RGzAGAJv8AV2merbc89sClboxCBZ6M ZUY9HPyO5T7v+B583yxwm4dnCMRboBEmZtpkyZ/rKnESl44syxZJNNkD0VDv6WI=3D =3DxA/Q -----END PGP SIGNATURE----- --_000_CF83D24B5DC99jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Antoin,

My feedback is below. 

-- 
 
JG
 

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



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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

op 25-04-14 15:23, Gould, James schreef:
I have not received any feedback publicly or privately on the
options in the message below.  Any thoughts on this?

Hi James,

First, thank you for your feedback and extensive suggestions.
I did receive private feedback to your suggestions, but was not able
to digest it yet due to a lack of time, sorry about that. I've asked
the commenter to post on-list, but have not been able to get back on t= hat.

The major comments to your suggestions as I understand them were:

<command>

    <update>

This suggest an update of a domain object in the registry DB, but a
keyrelay does not update anything in the DB as it is not submitted by<= /div>
the registrar of record. A keyrelay only reads object information and<= /div>
uses that to relay data.

The Key Relay is associated with the domain name.  A Key Relay Co= mmand, by overriding the update with a new verb (=93Key Relay=94), does per= sist information to the registry database to relay to the losing hosting pr= ovider in the form of a poll message.  Using the Command-Response Extension, you're defining a new command verb, simila= r to what is done with a protocol extension, but following the pattern that= has been followed with other extensions like the RGP extension (e.g. resto= re command).      



<resData>

The authors can live with the suggested changes to the response.
You'll get the domain info and key info in the response.

<command>

   <create>

     <keyrelay:create>

This is where both the authors and some others have problems with. A
create suggests you're creating an object in the registry DB, but we
don't. One of the requirements for keyrelay was that the DB would be
left unharmed, no special tables or attributes for keyrelay.

I believe you are adding more requirements around an object extension = than exists.  If the Key Relay was an object extension, you are creati= ng a Key Relay message to the losing hosting provider.  This is simila= r to sending an e-mail by creating an e-mail message and sending it to your SMTP server.  You are persisting / cre= ating information in the registry database in the form of a poll message in= this instance.  


I understand the difference between the message syntax and the actual<= /div>
process flow, but this does seem to confuse people. Are there any
other extensions that use a create or update syntax when there is no
authorization or actual object change? Is it clear enough in the EPP
RFC's that there is this separation of syntax and meaning? RFC 5730
section 2.9 states by definition that <create> and <update>= ; actually
change objects. The authors feel keyrelay does not fit in any of the
current protocol commands. It's not a session management command, not<= /div>
a query command, and not an object transform command. So keyrelay is
actually a new 4th protocol command type which can best be described
as a communication command.

A object extension does not require support for all of the transform c= ommands.  We have creating custom object extensions that don=92t use a= ll or any of the transform commands.  Examples include:
  1. Suggestion Mapping ( http://www.verisigninc.com/assets/epp-s= dk/EPP-Suggestion-Mapping.pdf ) - This is an EPP object extension = to support name suggestions in the form of a Name Suggestion object that only supports an info command and response. &n= bsp; 
  2. Balance Mapping ( http://www.verisigninc.com/assets/epp-= balance-mapping.pdf ) - This is an EPP object extension to support= getting the balance, available credit, and credit limit information in the form of a Balance object that only supports an info command and res= ponse.  
  3. WhoWas Mapping ( http://www.verisigninc.com/assets/epp= -whowas-mapping.pdf ) - This is an EPP object extension to support= getting history information (e.g. domain, host, contact) information in the form of a WhoWas object that support an info command and response.&= nbsp;

Another comment was about the double use of the domain name in the
message:

        <domain:name>exa= mple.org</domain:name>
        .....
        <keyrelay:name>e= xample.org</keyrelay:name>

which seemed unnessecary.

In the case of a Key Relay object extension, you can use the element &= lt;keyrelay:domainName> in place of the shorter form <keyrelay:name&g= t;, but the description of the element is the same in being the domain name= that the Key Relay is associated with.  


I'll ask my co-authors to follow up on this, but in the mean time, I
would like to hear others comment on the potential violation of RFC
5730 section 2.9 by your suggested syntax on-list.

There is no violation of RFC 5730.  It comes down to whether you = are extending the domain object extension in the form of a Command-Response= Extension, creating a new object extension for the Key Relay message objec= t, or creating a mix of a protocol extension (command) and an object extension (poll response).  



From: <Gould>, James Gould <jgould@verisign.com
<mailto:jgould@verisign.= com>> Date: Thursday, March 13, 2014 at
1:52 PM To: Antoin Verschuren <antoin.verschuren@sidn.nl
draft-ietf-eppext-keyrelay-00 Feedback
Antoin,
Thanks for the detailed explanation.  The choice of which fo= rm 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 relay commands and responses.  Technically
draft-ietf-eppext-keyrelay uses both the protocol 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
specification.   The best way to describe the use of the obj= ect
and command-response 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 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</secDNS:flags>
<secDNS:protocol>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:relative>P1M13D</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
response.
<?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><= /div>
</result>
<msgQ count=3D"5" id=3D"12345">
<qDate>1999-04-04T22:01:00.0Z</qDate>
<msg>Key Relay action completed successfully.</msg>
</msgQ>
<resData>
<domain:infData
xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.org</domain:name>
<domain:roid>EXAMPLE1-REP</domain:roid>
<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:flags>256</secDNS:flags>
<secDNS:protocol>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:relative>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 message 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"> &= lt;command>
<create> <keyrelay:create>
<keyrelay:name>example.org</keyrelay:name> <keyrelay:ke= yData>
<secDNS:flags>256</secDNS:flags>
<secDNS:protocol>3</secDNS:protocol> <secDNS:alg>8&l= t;/secDNS:alg>
<secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
</keyrelay:keyData> <keyrelay:authInfo>
<domain:pw>JnSdBAZSxxzJ</domain:pw> </keyrelay:authInfo= >
<keyrelay:expiry> <keyrelay:relative>P1M13D</keyrelay:r= elative>
</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"> &= lt;response>
<result code=3D"1301"> <msg>Command completed su= ccessfully; ack to
dequeue</msg> </result> <msgQ count=3D"5" id= =3D"12345">
<qDate>1999-04-04T22:01:00.0Z</qDate> <msg>Key Relay= action
completed successfully.</msg> </msgQ> <resData> <= keyrelay:infData>
<keyrelay:name paResult=3D"true">example.org </keyr= elay: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&l= t;/secDNS:alg>
<secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
</keyrelay:keyData> <keyrelay:authInfo>
<domain:pw>JnSdBAZSxxzJ</domain:pw> </keyrelay:authInfo= >
<keyrelay:expiry> <keyrelay:relative>P24D</keyrelay:rel= ative>
</keyrelay:expiry> <keyrelay:reID>ClientX</keyrelay:reI= D>
<keyrelay:acID>ClientY</keyrelay:acID> </keyrelay:infDa= ta>
</resData> <trID> <clTRID>BCD-23456</clTRID> <= /div>
<svTRID>65432-WXY</svTRID> </trID> </response>= </epp>
In addition, support can be provided for the Relay Info Command and
associated 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"> &= lt;command>
<info> <keyrelay:info> <keyrelay:name>example.org<= ;/keyrelay:name>
</keyrelay:info> </info> <clTRID>123456</clTRID&g= t; </command> </epp>
* *
In looking at the samples, I actually like the Object Extension
the best.  I can provide the XSD=92s that I validated the ex= amples
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:
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 cr= eate a
protocol extension for this.
One of the requirements from certain registries for keyrelay was
that since keyrelay is only a "preparation communication step&quo= t; 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 communic= ation
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" 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:

On 3/11/14, 9:23 AM, "Antoin Verschuren"
<mailto:antoin.ver= schuren@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

- --
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTXiZCAAoJEDqHrM883Agn7mEH/1LBGxWRJW3tKeahqRnR57r3
Lr+8y7EEYwA52yOk4aw7F+LcafSE9xylNw4z7pHuzZ1axV05qW1B4wEHDcTtLq= 8l
phq0NY50VIAVB08ICrjT4TAljEcxHkVvoFOdoJxt5vclG6wUFF3Rq502oYYIuY1s
EUBJyYxSCogpic+DgnULAqS+0+jQ62n8lGzlOYxJN5eJD2+6wrtTpN= ukop+IXD5z
v2Ima6NNU9ywR+I+QuWbEFxQxQXfl2GUn5RGzAGAJv8AV2merbc89sClboxCBZ= 6M
ZUY9HPyO5T7v+B583yxwm4dnCMRboBEmZtpkyZ/rKnESl44syxZJNNkD0VDv6WI=3D=
=3DxA/Q
-----END PGP SIGNATURE-----

--_000_CF83D24B5DC99jgouldverisigncom_-- From nobody Mon Apr 28 08:49:44 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7641A09EE for ; Mon, 28 Apr 2014 08:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 PmPXMaODWxbI for ; Mon, 28 Apr 2014 08:49:40 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 984591A07A6 for ; Mon, 28 Apr 2014 08:49:40 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1WenoJ-0004E1-6D for eppext@ietf.org; Mon, 28 Apr 2014 15:49:39 +0000 Received: from mail-oa0-f51.google.com ([209.85.219.51]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1WenoJ-00032v-5o for eppext@ietf.org; Mon, 28 Apr 2014 15:49:39 +0000 Received: by mail-oa0-f51.google.com with SMTP id i4so7339068oah.24 for ; Mon, 28 Apr 2014 08:49:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i3FAzUj78IjGxExWW58sQVnmeoY9T5QgK+XtyWedJ80=; b=h+kAy4DCCjAQaTXyDSBUuJ6w2srwvLr1NM5sO8rDrW0e0w3aYQ1nVknqC9eJJpDRxM SmX1fkNxSx5FXXCugi/z+tdvPfBgppf29i+E46XB/inJZ1ln3XL3uAMUxLE31068e2rG +KHgDs+MOSUsrsEZihAFYv9BPyUxEp03w9UrEBOdrSV1AGyKP+d+OfYpiVHAlqXPD7Qp tRkA06+dD9F+r/zYt30+0qYsSsATwUZYm/JKjllxgZ38PV5/caGMyLCzSHbJ+zqfyFiJ 00Kie0pBgvAc4sPyxoT+j5xsTGexWMTOJC649FjqcsIcK/6MC3T9GQf87LK5ImlRQDC9 vGog== X-Gm-Message-State: ALoCoQmC8F7fSZ0ltFoe3Jf9wgU/6ZGJcjaMgXB2snVm6sJgoOSeRu/AWuyl3JU6keH7RGlE7lkGsD6LLKXsi9Lya81vDMFWK4IVvH3x8/DgUDZ1W5fYKRk= X-Received: by 10.60.51.167 with SMTP id l7mr977661oeo.86.1398700174371; Mon, 28 Apr 2014 08:49:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.51.167 with SMTP id l7mr977649oeo.86.1398700174268; Mon, 28 Apr 2014 08:49:34 -0700 (PDT) Received: by 10.76.171.134 with HTTP; Mon, 28 Apr 2014 08:49:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 11:49:34 -0400 Message-ID: From: Christopher Browne To: "Gould, James" Content-Type: multipart/alternative; boundary=001a11c3081408f61f04f81c43f8 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/p9rg_B5FeLDlm3D6UC5obA1asKA Cc: Antoin Verschuren , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:49:42 -0000 --001a11c3081408f61f04f81c43f8 Content-Type: text/plain; charset=ISO-8859-1 Reactions here were broadly consistent with yours, James. The proposal that this be an object-less command wasn't terribly popular; several people thought that it would be more logical for this to be something to be added or returned as an extension to the domain object. I understand there being a desire not to add more data to associate with domains in a registry, but frankly, if, as a registry operator operator, we planned to support this, I think we'd rather associate the data with domains than anything else. Alternately, to point at the opposite position, were we inclined to refuse to associate key data with domains, we'd be mostly inclined to refuse to support the extension altogether; that's an entirely simpler answer to the matter. (And if the idea was to "not update anything in the DB", that would indeed need to be the outcome. If it's not to go in the DB, then it can't go in the Poll Queue, as that is in the DB.) The common thinking here was that it seemed like a good idea to: a) Add keyrelay data via an extension to b) Perhaps pass, to the recipient, a message indicating presence of such data, via Poll Queue, perhaps also including all the data in the poll queue. c) Access the data via an extension to . That suggests that there might be storage of data beyond "just" in the poll queue. The proposal that James Gould just put forth for a Keyrelay object extension seems no worse than that, and that seems cleaner than the initial proposal in that it presents the same sort of object/command division of things as we have elsewhere in the EPP standards. I have a bit of a meta-comment... There are several references to databases such as the following: "we looked at a way to do this communication step without even touching the DB." It seems to me that there's something rather peculiar about discussing databases here; while I tend to "live the database" in many of my day-to-day duties, I try to be careful to take that hat off here. What we're doing here is protocol design, and that should be kept independent of internal implementation considerations. Whether someone's using a relational database, hash tables, IMS, or passing data through message-oriented middleware shouldn't be tightly encoded into the protocol. It also seems odd to me that it seems to be imagined that associating data with a domain indicates that there *are* database updates, whereas associating data with a poll queue indicates that there *are not* database updates there, when poll queue entries still need to be kept durable enough to survive until they are sent to their recipients. (Indeed, and this is certainly an aside, I'm a bit unhappy that RFC 4930 requires having a message count, e.g. - . That's more data about what's in the queue than I think there ought to need to be.) --001a11c3081408f61f04f81c43f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Reactions here were broadly consistent with yours, James.<= br>
The proposal that this be an object-less command wasn't terribly= popular; several people thought that it would be more logical for this to = be something to be added or returned as an extension to the domain object.<= br>
I understand there being a desire not to add more data to associate wit= h domains in a registry, but frankly, if, as a registry operator operator, = we planned to support this, I think we'd rather associate the data with= domains than anything else.

Alternately, to point at the opposite position, were we inclined to ref= use to associate key data with domains, we'd be mostly inclined to refu= se to support the extension altogether; that's an entirely simpler answ= er to the matter. =A0(And if the idea was to "not update anything in t= he DB", that would indeed need to be the outcome. =A0If it's not t= o go in the DB, then it can't go in the Poll Queue, as that is in the D= B.)

The common thinking here was that it seemed like a good idea to:
a)= Add keyrelay data via an extension to <domain:update>
b) Perhaps = pass, to the recipient, a message indicating presence of such data, via Pol= l Queue, perhaps also including all the data in the poll queue.
c) Access the data via an extension to <domain:info>. =A0That su= ggests that there might be storage of data beyond "just" in the p= oll queue.

The proposal that James Gould just put = forth for a Keyrelay object extension seems no worse than that, and that se= ems cleaner than the initial proposal in that it presents the same sort of = object/command division of things as we have elsewhere in the EPP standards= .

I have a bit of a meta-comment... =A0There are several references = to databases such as the following:
=A0 =A0"we looked at a way to d= o this communication step without even touching the DB."

It see= ms to me that there's something rather peculiar about discussing databa= ses here; while I tend to "live the database" in many of my day-t= o-day duties, I try to be careful to take that hat off here. =A0What we'= ;re doing here is protocol design, and that should be kept independent of i= nternal implementation considerations. =A0Whether someone's using a rel= ational database, hash tables, IMS, or passing data through message-oriente= d middleware shouldn't be tightly encoded into the protocol. =A0

It also seems odd to me that it seems to be imagined th= at associating data with a domain indicates that there *are* database updat= es, whereas associating data with a poll queue indicates that there *are no= t* database updates there, when poll queue entries still need to be kept du= rable enough to survive until they are sent to their recipients.

(Indeed, and this is certainly an aside, I'm a bit unhap= py that RFC 4930 requires having a message count, e.g. -=A0<msgQ count=3D"5" id=3D"12345"/>. = =A0That's more data about what's in the queue than I think there ou= ght to need to be.)
--001a11c3081408f61f04f81c43f8--