Correct time should be 15:20 -= =20 16:50 tim

On 8/1/13 11:38 AM, Zhouqian (Cathy) wrote:

Hi all,

When is the dnsop meeting time? = It shows=20 17:30-18:30 (UTC-4) on the agenda below:

http://www.ietf.org/proceedings/87/agenda/agend= a-87-dnsop.

I think it is not correct. Can a= nyone tell=20 me the exact time?

Thanks,

Cathy

__=
_____________________________________________
DNSOP mailing list
DNSOP@i=
etf.org
https://www.ietf.org/mailman/listinfo/dnsop

------=_001_NextPart848204236660_=------ From jabley@hopcount.ca Thu Aug 1 02:57:44 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2264F21F9E62 for ; Thu, 1 Aug 2013 02:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZPt1xQrPIm3 for ; Thu, 1 Aug 2013 02:57:43 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B31EE21F9E13 for ; Thu, 1 Aug 2013 02:57:42 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so1963048pad.33 for ; Thu, 01 Aug 2013 02:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=Uc0oyBWZ9FUpKB0m1+8S0GnmOgKrOI/7CX9pIsE4t3Q=; b=LHKAva3s0Qa8K+ziQLyHWxaSZWLqvpmCwK0ndDgciFkc4XJRcUdeSpBSXRnHbeIC+q IhMAATtl3pzGhXOL4LMX8N/gRwb8BTnunUQEe/VTCe2M7JOIQKFd9CeK6HP4lk7aWfJ+ NFeKSh7VET7BPdI5FmIfKuMM8SgOU2QL1jYz0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=Uc0oyBWZ9FUpKB0m1+8S0GnmOgKrOI/7CX9pIsE4t3Q=; b=OTSEHyGDkRAnX7M3RUADwoxK9sePu+ALcRcxhCvAemfKSW7/ioyAN01Axh2TL8UzKZ nGS3zR9kAiMeYP4cTctT9Be3kopsdUVp3qwAdZ90APMdZQZ3/W2rUpedtF+Y97gt6AfX EoLC+w0SLWdbin2tRK7dJKoqM1mVjvHQQMoty1GqYqjTnshET1ILgdPjoR2XXUKawyd/ a7iba89gvKPCHuNpAAQSDZfQTQLUArPX2a5JcnublL9EVos+q0YAB+MQvdsLbSqoFYjf HGwW6i2/F217v564CHYCH5Ntx9s2c8hS4cxzpIgAoYSbiw/CbvxeIUH2WURZC0VMSCOb qXYw== X-Received: by 10.68.52.200 with SMTP id v8mr943849pbo.48.1375351062124; Thu, 01 Aug 2013 02:57:42 -0700 (PDT) Received: from ?IPv6:2001:df8::64:797e:bb2b:260b:b4f6? ([2001:df8:0:64:797e:bb2b:260b:b4f6]) by mx.google.com with ESMTPSA id tr10sm3091366pbc.22.2013.08.01.02.57.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 02:57:41 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7366A80D-35B5-4455-926D-2B2C80062E3D"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Joe Abley X-Priority: 3 In-Reply-To: <201308011752552177052@cnnic.cn> Date: Thu, 1 Aug 2013 11:56:58 +0200 Message-Id: <0D3FF051-CBBF-4D3F-A27E-58BD30205D1C@hopcount.ca> References: , <51FA2D0F.8000904@teamaol.com> <201308011752552177052@cnnic.cn> To: Guangqing Deng X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmPkzWt2oWY1NjlfhjMdZwPMYupGo5ls4yye5j7t7EqfTN/v0XRhHm54IXeppfag8wsZpq8 Cc: dnsop Subject: Re: [DNSOP] Meeting time this afternoon? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:57:44 -0000 --Apple-Mail=_7366A80D-35B5-4455-926D-2B2C80062E3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2013-08-01, at 11:52, Guangqing Deng wrote: > It seems that the slides of DNSOP WG are still not available on = website yet. Hope such slides can be posted before meeting time. As one of the people guilty for not sending slides to the chairs = earlier, I apologise. But Tim has my slides now, and I am sure they will = appear directly. Will do better next time. Joe --Apple-Mail=_7366A80D-35B5-4455-926D-2B2C80062E3D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlH6MOsACgkQNI8MvYZSOixOzwCggdY9/fzw/d0OEK9asJuly9yV ucsAoLMDGz2NYex3plZxP82Ty9iIalGq =6Y/V -----END PGP SIGNATURE----- --Apple-Mail=_7366A80D-35B5-4455-926D-2B2C80062E3D-- From tim.wicinski@teamaol.com Thu Aug 1 02:59:13 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBD021F9E6A for ; Thu, 1 Aug 2013 02:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-5z04reCrGf for ; Thu, 1 Aug 2013 02:59:09 -0700 (PDT) Received: from omr-m09.mx.aol.com (omr-m09.mx.aol.com [64.12.143.82]) by ietfa.amsl.com (Postfix) with ESMTP id B27D521F938E for ; Thu, 1 Aug 2013 02:59:08 -0700 (PDT) Received: from aoldtcmei32.ad.aol.aoltw.net (aoldtcmei32.office.aol.com [10.180.121.111]) by omr-m09.mx.aol.com (Outbound Mail Relay) with ESMTP id B52F2700865FE; Thu, 1 Aug 2013 05:59:06 -0400 (EDT) Received: from tjw.local (172.17.8.193) by aoldtcmei32.ad.aol.aoltw.net (10.180.121.111) with Microsoft SMTP Server id 14.3.123.3; Thu, 1 Aug 2013 05:59:06 -0400 Message-ID: <51FA3168.10604@teamaol.com> Date: Thu, 1 Aug 2013 11:59:04 +0200 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: Joe Abley , Guangqing Deng References: , <51FA2D0F.8000904@teamaol.com> <201308011752552177052@cnnic.cn> <0D3FF051-CBBF-4D3F-A27E-58BD30205D1C@hopcount.ca> In-Reply-To: <0D3FF051-CBBF-4D3F-A27E-58BD30205D1C@hopcount.ca> Content-Type: multipart/alternative; boundary="------------050301040703020508000305" X-Originating-IP: [172.17.8.193] Cc: dnsop Subject: Re: [DNSOP] Meeting time this afternoon? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:59:14 -0000 --------------050301040703020508000305 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I was not going to be one to point fingers, but yes, they will all be up very shortly, including all the extras I've received. tim On 8/1/13 11:56 AM, Joe Abley wrote: > On 2013-08-01, at 11:52, Guangqing Deng wrote: > >> It seems that the slides of DNSOP WG are still not available on website yet. Hope such slides can be posted before meeting time. > As one of the people guilty for not sending slides to the chairs earlier, I apologise. But Tim has my slides now, and I am sure they will appear directly. Will do better next time. > > > Joe > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --------------050301040703020508000305 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I was not going to be one to point fingers, but yes, they will all be up very shortly, including all the extras I've received. tim

On 8/1/13 11:56 AM, Joe Abley wrote:

On 2013-08-01, at 11:52, Guangqing Deng <dengguangqing@cnnic.cn> wrote:

It seems that the slides of DNSOP WG are still not available on website yet. Hope such slides can be posted before meeting time.

As one of the people guilty for not sending slides to the chairs earlier, I apologise. But Tim has my slides now, and I am sure they will appear directly. Will do better next time.


Joe

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--------------050301040703020508000305-- From tim.wicinski@teamaol.com Thu Aug 1 04:21:53 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7830221F9E6B for ; Thu, 1 Aug 2013 04:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+hZqY+DsWFE for ; Thu, 1 Aug 2013 04:21:49 -0700 (PDT) Received: from omr-m04.mx.aol.com (omr-m04.mx.aol.com [64.12.143.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD9F21F9306 for ; Thu, 1 Aug 2013 04:21:40 -0700 (PDT) Received: from aoldtcmei32.ad.aol.aoltw.net (aoldtcmei32.office.aol.com [10.180.121.111]) by omr-m04.mx.aol.com (Outbound Mail Relay) with ESMTP id 07543700000B4; Thu, 1 Aug 2013 07:21:38 -0400 (EDT) Received: from tjw.local (172.17.8.193) by aoldtcmei32.ad.aol.aoltw.net (10.180.121.111) with Microsoft SMTP Server id 14.3.123.3; Thu, 1 Aug 2013 07:21:37 -0400 Message-ID: <51FA44C0.4050304@teamaol.com> Date: Thu, 1 Aug 2013 13:21:36 +0200 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: Jay Daley , Paul Hoffman References: <77772FDC-CF32-4797-BB79-EABE559BA97E@nzrs.net.nz> <7B662C88-D969-4586-A01F-5D36E5B8DA53@vpnc.org> <58D17552-D4DD-45FC-9975-236D61635347@nzrs.net.nz> In-Reply-To: <58D17552-D4DD-45FC-9975-236D61635347@nzrs.net.nz> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.8.193] Cc: dnsop WG Subject: Re: [DNSOP] dnsxml - A standard XML representation of DNS data X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:21:53 -0000 Jay I agree it's just "formats" and therefore it's just 'a simple bit of code', I tend to find the XML specifications get a bit heavy, and what I liked in Stephane's draft is that it has a very lightweight feel to it. (I will mention that the IESG is looking for reviewers for draft-manderson-rdns-xml-01 in case anyone feels extra motivated to assist in this). tim On 7/31/13 10:01 AM, Jay Daley wrote: > Hi Paul > > On 31/07/2013, at 7:53 PM, Paul Hoffman wrote: > >> Please also see draft-bortzmeyer-dns-json. JSON encoders and parsers are lighter-weight than XML ones, and for the data in question (everything DNS), it seems like JSON might be a better text format for the use cases (particularly logging). > I'm aware of Stephane's draft as noted in my original email but I haven't had a chance to read it. I will though. > > Rather than picking a winner between JSON and XML I've always found it prudent to recognise that the two have different characteristics that support different uses. Not only can JSON and XML co-exist but also, if needed, the JSON can be derived from the XML via XSLT: > > http://controlfreak.net/xml-to-json-in-xslt-a-toolkit/ > > cheers > Jay > >> --Paul Hoffman >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > From jay@nzrs.net.nz Thu Aug 1 04:50:19 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8881921F9A38 for ; Thu, 1 Aug 2013 04:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i12mlWTqsWGZ for ; Thu, 1 Aug 2013 04:50:11 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id F340F21F9967 for ; Thu, 1 Aug 2013 04:50:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 046CC4B24F1; Thu, 1 Aug 2013 23:50:07 +1200 (NZST) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3qFBEI8GP+W; Thu, 1 Aug 2013 23:50:06 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 8E40D4B243C; Thu, 1 Aug 2013 23:50:06 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <51FA44C0.4050304@teamaol.com> Date: Thu, 1 Aug 2013 23:50:06 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <832EBD76-826E-4905-A09C-8B4325430E7A@nzrs.net.nz> References: <77772FDC-CF32-4797-BB79-EABE559BA97E@nzrs.net.nz> <7B662C88-D969-4586-A01F-5D36E5B8DA53@vpnc.org> <58D17552-D4DD-45FC-9975-236D61635347@nzrs.net.nz> <51FA44C0.4050304@teamaol.com> To: Tim Wicinski X-Mailer: Apple Mail (2.1508) Cc: dnsop WG , Paul Hoffman Subject: Re: [DNSOP] dnsxml - A standard XML representation of DNS data X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:50:19 -0000 On 1/08/2013, at 11:21 PM, Tim Wicinski = wrote: > Jay >=20 > I agree it's just "formats" and therefore it's just 'a simple bit of = code', I tend to find the XML specifications get a bit heavy, and what I = liked in Stephane's draft is that it has a very lightweight feel to it. XML, especially in the IETF context, gets heavy because people use = xml-schema or relaxng to define schemas to define and validate the XML. = JSON is not yet at that stage and so seems lighter, but that's generally = due to simpler functionality. When JSON schema is readily available I'm = sure the differences will diminish. > (I will mention that the IESG is looking for reviewers for = draft-manderson-rdns-xml-01 in case anyone feels extra motivated to = assist in this). There's so little to it I'm happy to review and will do soon. Jay >=20 > tim >=20 >=20 > On 7/31/13 10:01 AM, Jay Daley wrote: >> Hi Paul >>=20 >> On 31/07/2013, at 7:53 PM, Paul Hoffman = wrote: >>=20 >>> Please also see draft-bortzmeyer-dns-json. JSON encoders and parsers = are lighter-weight than XML ones, and for the data in question = (everything DNS), it seems like JSON might be a better text format for = the use cases (particularly logging). >> I'm aware of Stephane's draft as noted in my original email but I = haven't had a chance to read it. I will though. >>=20 >> Rather than picking a winner between JSON and XML I've always found = it prudent to recognise that the two have different characteristics that = support different uses. Not only can JSON and XML co-exist but also, if = needed, the JSON can be derived from the XML via XSLT: >>=20 >> http://controlfreak.net/xml-to-json-in-xslt-a-toolkit/ >>=20 >> cheers >> Jay >>=20 >>> --Paul Hoffman >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From terry.manderson@icann.org Thu Aug 1 04:53:12 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A1321E80CF for ; Thu, 1 Aug 2013 04:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYu8bhzGf6JW for ; Thu, 1 Aug 2013 04:53:06 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id A533A21F9DC9 for ; Thu, 1 Aug 2013 04:52:57 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 1 Aug 2013 04:52:54 -0700 From: Terry Manderson To: Tim Wicinski , Jay Daley , Paul Hoffman Date: Thu, 1 Aug 2013 04:52:49 -0700 Thread-Topic: [DNSOP] dnsxml - A standard XML representation of DNS data Thread-Index: Ac6OraeSdcQzQGlaT7K6xTsTuCYKUw== Message-ID: In-Reply-To: <51FA44C0.4050304@teamaol.com> 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 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3458238769_51659862" MIME-Version: 1.0 Cc: dnsop WG Subject: Re: [DNSOP] dnsxml - A standard XML representation of DNS data X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:53:12 -0000 --B_3458238769_51659862 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Tim and all, On 1/08/13 9:21 PM, "Tim Wicinski" wrote: >Jay > >I agree it's just "formats" and therefore it's just 'a simple bit of >code', Code is always changeable so long at there is solid motivation to do so. >I tend to find the XML specifications get a bit heavy, and what I >liked in Stephane's draft is that it has a very lightweight feel to it. Yes, XML can sometimes be a heavy solution, but also has a set of positives. It really depends on the implementation in which it is being used. Classic "it depends" response - sorry! ;) > >(I will mention that the IESG is looking for reviewers for >draft-manderson-rdns-xml-01 in case anyone feels extra motivated to >assist in this). Love to iterate this, draft-manderson-rdns-xml-01 was submitted via the rfc-ise as it really is a specific item targeted at a provisioning portion of the DNS hierarchy that has been in production for a number of years. The draft is more to allow the transparency of ICANN operations in such areas that makes sense with the hope that it can provide information to other folk looking to implement similar systems, or spark the thought processes in others that might come up with viable improvements. Cheers Terry --B_3458238769_51659862 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFMw3NYZcNEWuiUzC2fZFWNWmludLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMDgwMTExNTI0OVowDQYJKoZIhvcNAQEBBQAEggEAPp9ph8pZ zHnIfZxdi1bDsD5HzkScoyw0n2k4TWVYuvOCxeKxjMVVLg3ROGFWetFDRTYXO6nRBf9SHmfy FAdx++Gn7pS8cmhDEgLN1bBeXr534Tndij1P6yVg7S0lJ9WxvgzKJDVt7K9pE02uv4bcfziG wsPg3T4mocIdy+oeZlQ5tv05YDRjd+RVt+SRjilm82C2akgbK1Sc76myVSzJlFbnGkEl3gVz dVDhH/F/QAyKBqXmrDin7RJMAGHKjfrWLDIUbRlNleEmYpQNUmRx1ev5m9NMXqqeispJppVc h33MPiGH98jjKuS7H3KoBYrY7BHSHfu0OGGFD/skibawEQ== --B_3458238769_51659862-- From tim.wicinski@teamaol.com Fri Aug 2 03:15:15 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C308711E8257 for ; Fri, 2 Aug 2013 03:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6InB0DOc9pW for ; Fri, 2 Aug 2013 03:15:11 -0700 (PDT) Received: from omr-d05.mx.aol.com (omr-d05.mx.aol.com [205.188.109.202]) by ietfa.amsl.com (Postfix) with ESMTP id C593521E809C for ; Fri, 2 Aug 2013 03:15:08 -0700 (PDT) Received: from AOLDTCMEI34.ad.aol.aoltw.net (aoldtcmei34.office.aol.com [10.180.121.151]) by omr-d05.mx.aol.com (Outbound Mail Relay) with ESMTP id C6A9670007CD9 for ; Fri, 2 Aug 2013 06:15:07 -0400 (EDT) Received: from tjw.local (172.17.8.193) by AOLDTCMEI34.ad.aol.aoltw.net (10.180.121.151) with Microsoft SMTP Server id 14.3.123.3; Fri, 2 Aug 2013 06:15:07 -0400 Message-ID: <51FB86AA.7030500@teamaol.com> Date: Fri, 2 Aug 2013 12:15:06 +0200 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: dnsop WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.8.193] Subject: [DNSOP] Draft DNSOP Meeting Minutes X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:15:15 -0000 Hi Draft minutes from Thursday meeting are available http://www.ietf.org/proceedings/87/minutes/minutes-87-dnsop . Please let the chairs know if find something incorrectly recorded. Thanks to Olaf for the note taking. tim From tim.wicinski@teamaol.com Fri Aug 2 03:59:55 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FC321E832F for ; Fri, 2 Aug 2013 03:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4ar8Wx6Ltzy for ; Fri, 2 Aug 2013 03:59:51 -0700 (PDT) Received: from omr-m06.mx.aol.com (omr-m06.mx.aol.com [64.12.143.80]) by ietfa.amsl.com (Postfix) with ESMTP id B195E11E8241 for ; Fri, 2 Aug 2013 03:59:39 -0700 (PDT) Received: from aoldtcmei32.ad.aol.aoltw.net (aoldtcmei32.office.aol.com [10.180.121.111]) by omr-m06.mx.aol.com (Outbound Mail Relay) with ESMTP id 98ED37003165E for ; Fri, 2 Aug 2013 06:59:35 -0400 (EDT) Received: from tjw.local (172.17.8.193) by aoldtcmei32.ad.aol.aoltw.net (10.180.121.111) with Microsoft SMTP Server id 14.3.123.3; Fri, 2 Aug 2013 06:59:35 -0400 Message-ID: <51FB9116.8070809@teamaol.com> Date: Fri, 2 Aug 2013 12:59:34 +0200 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: dnsop WG Content-Type: multipart/alternative; boundary="------------060204040101040309050208" X-Originating-IP: [172.17.8.193] Subject: [DNSOP] DNSOP slides fully updated X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:59:55 -0000 --------------060204040101040309050208 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit All, I have pushed up all the slides and materials for IETF 87. You can find them all here: http://tools.ietf.org/wg/dnsop/agenda Particular, I point out all the interesting stuff we never got around to, such as: DNSSEC Roadblock Avoidance using PCP to trigger dynamic DNS updates DNS No Response Issue Root Zone KSK Roll DNSSEC side effect, Increase in DS Queries I wanted to point out the the outside draft brought in by Cathy Zhou from the PCP group http://tools.ietf.org/id/draft-deng-pcp-ddns-03.txt http://tools.ietf.org/agenda/87/slides/slides-87-dnsop-4.pdf This is mostly DDNS updates and is more of an Informational document. I was hoping we can pass over the document and provide some operational insight. Additionally, I'll start sending out some emails to verify adopting documents in the working group, per the meeting. I'll send them out in emails based on how they were presented, instead of all in one email to prevent cross talk. I believe the consensus from the meetings was we confirm the adoptions. tim --------------060204040101040309050208 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit All,

I have pushed up all the slides and materials for IETF 87. You can find them all here:

http://tools.ietf.org/wg/dnsop/agenda

Particular, I point out all the interesting stuff we never got around to, such as:

DNSSEC Roadblock Avoidance
using PCP to trigger dynamic DNS updates
DNS No Response Issue
Root Zone KSK Roll
DNSSEC side effect, Increase in DS Queries

I wanted to point out the the outside draft brought in by Cathy Zhou from the PCP group
    http://tools.ietf.org/id/draft-deng-pcp-ddns-03.txt
    http://tools.ietf.org/agenda/87/slides/slides-87-dnsop-4.pdf

This is mostly DDNS updates and is more of an Informational document. I was hoping we can pass over the document and provide some operational insight.

Additionally, I'll start sending out some emails to verify adopting documents in the working group, per the meeting. I'll send them out in emails based on how they were presented, instead of all in one email to prevent cross talk. I believe the consensus from the meetings was we confirm the adoptions.

tim
--------------060204040101040309050208-- From jay@nzrs.net.nz Mon Aug 12 15:06:15 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4AD21E8054 for ; Mon, 12 Aug 2013 15:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2z5OR9sP8yb for ; Mon, 12 Aug 2013 15:06:11 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id C5C6521F9EB6 for ; Mon, 12 Aug 2013 15:06:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 66A604B5200 for ; Tue, 13 Aug 2013 10:06:07 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlAnSj+o1qfa for ; Tue, 13 Aug 2013 10:06:00 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 388834B4F03 for ; Tue, 13 Aug 2013 10:06:00 +1200 (NZST) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <92F4C715-FF72-4CEE-9C17-134932228F13@nzrs.net.nz> Date: Tue, 13 Aug 2013 10:05:59 +1200 To: dnsop WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DNSOP] Review of draft-manderson-rdns-xml-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:06:16 -0000 Firstly, just to confirm that I've read the previous email from Terry = Manderson that this draft was published more for reasons of transparency = and starting a conversation than anything else. So here are my comments = in light of that: 1. There were a number of places in this draft where I found myself = asking "why didn't they just use EPP?". For example: - it's a registry provisioning protocol - it's a registry provisioning protocol for NS and DS records! - it has a feature for requests to be queued and a message list to be = polled 2. Unless I'm being dumb (and my RelaxNG is not very good) I can't see = any definition of either - responses to non-queued requests - errors other than the implicit standard HTTP response/error codes. 3. It's too tightly bound to the underlying HTTP interface. The = response/errors is one example, another is the queue element field: # The HTTP method used to update attribute method { "PUT" | "DELETE" }, That would be better as a logical operation code (i.e. Add, Delete) that = were mapped onto HTTP operations.=20 4. Some of the key data elements that need to be provisioning are = defined the most loosely - name the rdata field. So overall I'm pretty surprised that this path was chosen in 2011 rather = than EPP which the rest of the known universe uses for this sort of = thing. I realise ICANN is very much taken with lightweight REST but = this seems to be forcing the solution onto every problem, even then = solved ones. However, this is indeed ICANN's choice, it is a trivial = protocol and is working in production. But what it isn't is a candidate = for becoming an RFC. If the authors are interested in doing this in EPP then I would be = willing to help. cheers Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From jabley@hopcount.ca Mon Aug 12 15:58:05 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597DB11E80DC for ; Mon, 12 Aug 2013 15:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grqkQMyaDreo for ; Mon, 12 Aug 2013 15:58:04 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5B25311E80E4 for ; Mon, 12 Aug 2013 15:58:00 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so10415663oag.2 for ; Mon, 12 Aug 2013 15:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=cUtWjx2gQWmD/ho5OEPVW9vvJCd1E0gqPvWyo7Bbez0=; b=eHq+N+ERGF4EWIgHVXxr3/mwZ73i56J5geOFr6Zm2ldUTg94YFsQ6oGb+N/9E3WViY 2FxVkxagxsyMyJNgMVjhmx7DSRMN2Ataag1WI/cpVmUMC5qVOrTdqSPRQRsi4h9Hdv4M 97Fc6tGKYf2YCPGGJ609GpGd6t3ZgRa5zeLIA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:from:mime-version:in-reply-to:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=cUtWjx2gQWmD/ho5OEPVW9vvJCd1E0gqPvWyo7Bbez0=; b=iBjPTYKwFzW6X2djABgu8Ycr0ZZE9+CLXMs4sQdxgsvPtag8cKVrVEv+DWpBaC1OsO eWEFaJ7gMXS7YqhTPac/K3qoR0qygMakWOBmFGwW/qAbk81HpGZjHqEb1DRDCMqlIXGg GXGENUpvTBWwMRALcX6dp0WcMEqGJeo/UpAteg35ZmmEtvSJnO432Hmz8EGEPf41dFAD wZFZk4L3mDmaIl8us+aTf5Cmu29iTwAYowEQ8HtY7tcwSjIMse4f/iUDMQqV6BDZHHuH QDGYMDsqLNeZE9hGoTBiBfht2W3/1uv7rum8noLsg/HqDjKptRcYloyIjNwnONWgvLy+ +HZw== X-Gm-Message-State: ALoCoQnVtWNtGLNMfrxnvnmVqYwgeu7W+ixLSs4HJ/VI0wi7Rar1vt10l8/pc4NPibftYvy7pD+l X-Received: by 10.60.84.205 with SMTP id b13mr1239571oez.61.1376348280521; Mon, 12 Aug 2013 15:58:00 -0700 (PDT) References: <92F4C715-FF72-4CEE-9C17-134932228F13@nzrs.net.nz> From: Joe Abley Mime-Version: 1.0 (1.0) In-Reply-To: <92F4C715-FF72-4CEE-9C17-134932228F13@nzrs.net.nz> Date: Mon, 12 Aug 2013 18:57:58 -0400 Message-ID: <8247861913252083991@unknownmsgid> To: Jay Daley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsop WG Subject: Re: [DNSOP] Review of draft-manderson-rdns-xml-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:58:05 -0000 Hi Jay, I'm not sure I understand your conclusion. Why do you think this running system should not be documented in an RFC? If it was a private-use protocol being used for private purposes, I could see what you're getting at. However, it's neither: it's a protocol in use between different organisations being used to support an aspect of public infrastructure (the reverse DNS trees). I don't agree that there's nothing to be gained by documenting it (I realise that's not exactly what you wrote, but it could be read that way) and to me, the RFC series is a plausible place for that to happen. What am I missing? (ObDisclaimer: Terry and I work together, but this is a personal perspective; he's big and ugly enough to fight his own battles :-) Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-08-12, at 18:06, Jay Daley wrote: > Firstly, just to confirm that I've read the previous email from Terry Man= derson that this draft was published more for reasons of transparency and s= tarting a conversation than anything else. So here are my comments in ligh= t of that: > > 1. There were a number of places in this draft where I found myself aski= ng "why didn't they just use EPP?". For example: > > - it's a registry provisioning protocol > - it's a registry provisioning protocol for NS and DS records! > - it has a feature for requests to be queued and a message list to be pol= led > > > 2. Unless I'm being dumb (and my RelaxNG is not very good) I can't see a= ny definition of either > > - responses to non-queued requests > - errors > > other than the implicit standard HTTP response/error codes. > > > 3. It's too tightly bound to the underlying HTTP interface. The respons= e/errors is one example, another is the queue element field: > > # The HTTP method used to update > attribute method { "PUT" | "DELETE" }, > > That would be better as a logical operation code (i.e. Add, Delete) that = were mapped onto HTTP operations. > > 4. Some of the key data elements that need to be provisioning are define= d the most loosely - name the rdata field. > > So overall I'm pretty surprised that this path was chosen in 2011 rather = than EPP which the rest of the known universe uses for this sort of thing. = I realise ICANN is very much taken with lightweight REST but this seems to= be forcing the solution onto every problem, even then solved ones. Howeve= r, this is indeed ICANN's choice, it is a trivial protocol and is working i= n production. But what it isn't is a candidate for becoming an RFC. > > If the authors are interested in doing this in EPP then I would be willin= g to help. > > cheers > Jay > > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > linkedin: www.linkedin.com/in/jaydaley > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From jay@nzrs.net.nz Mon Aug 12 16:28:57 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FC921F8FB4 for ; Mon, 12 Aug 2013 16:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLxIydZrU30P for ; Mon, 12 Aug 2013 16:28:53 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95121F8FF8 for ; Mon, 12 Aug 2013 16:28:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 43BF94B54B2; Tue, 13 Aug 2013 11:28:50 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU5IuTRANqqx; Tue, 13 Aug 2013 11:28:43 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 080914B53B2; Tue, 13 Aug 2013 11:28:42 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <8247861913252083991@unknownmsgid> Date: Tue, 13 Aug 2013 11:28:41 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B4EAB28-0301-474D-9F87-2BC49E55DB01@nzrs.net.nz> References: <92F4C715-FF72-4CEE-9C17-134932228F13@nzrs.net.nz> <8247861913252083991@unknownmsgid> To: Joe Abley X-Mailer: Apple Mail (2.1508) Cc: dnsop WG Subject: Re: [DNSOP] Review of draft-manderson-rdns-xml-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 23:28:57 -0000 On 13/08/2013, at 10:57 AM, Joe Abley wrote: > Hi Jay, >=20 > I'm not sure I understand your conclusion. Why do you think this > running system should not be documented in an RFC? >=20 > If it was a private-use protocol being used for private purposes, I > could see what you're getting at. However, it's neither: it's a > protocol in use between different organisations being used to support > an aspect of public infrastructure (the reverse DNS trees). I'm not sure how you can describe this as anything other than a private = protocol. Yes it is part of the public infrastructure but then there are = a myriad of private EPP extensions out there that also work on the = public infrastructure and yet would equally not be suitable for an RFC. = So I don't think the 'public infrastructure' argument holds water. For it to be an RFC I would hope that meets a decent threshold, namely: 1. there is at least some sense of architectural positioning in = relation to other protocols. This draft doesn't have that as it seems = to do a small part of an otherwise perfectly good protocol, EPP, without = any reference/recognition of how the two fit together. 2. there is a relatively clean separation of layers. This is not the = case with this draft as it tightly binds onto HTTP. 3. it is a public protocol. For this to be a public protocol the rules = are pretty clear - two implementations in different contexts. AFAICT = this has only one server implementation and multiple clients in the same = context. While 2. can be fixed I'm not sure 1. and 3. can be. > I don't agree that there's nothing to be gained by documenting it (I > realise that's not exactly what you wrote, but it could be read that > way) and to me, the RFC series is a plausible place for that to > happen. There is every benefit to this being documented, I am glad that it is = and would not wish that to change. However using the RFC process for a = private protocol is inappropriate and it would be better if there was a = web site had a section that documented all the ICANN private protocols, = in much the same way many TLD operators do. > What am I missing? I really do not mean to cause any offence by this so apologies in = advance if I do, but is this a case of ICANN mistaking its position = here? Yes you are the excellent operator of a key part of the public = infrastructure but that doesn't mean that every protocol you develop = related to your technical function automatically becomes an RFC when = documented to a sufficient standard. cheers Jay >=20 > (ObDisclaimer: Terry and I work together, but this is a personal > perspective; he's big and ugly enough to fight his own battles :-) >=20 >=20 > Joe >=20 > Aue Te Ariki! He toki ki roto taku mahuna! >=20 > On 2013-08-12, at 18:06, Jay Daley wrote: >=20 >> Firstly, just to confirm that I've read the previous email from Terry = Manderson that this draft was published more for reasons of transparency = and starting a conversation than anything else. So here are my comments = in light of that: >>=20 >> 1. There were a number of places in this draft where I found myself = asking "why didn't they just use EPP?". For example: >>=20 >> - it's a registry provisioning protocol >> - it's a registry provisioning protocol for NS and DS records! >> - it has a feature for requests to be queued and a message list to be = polled >>=20 >>=20 >> 2. Unless I'm being dumb (and my RelaxNG is not very good) I can't = see any definition of either >>=20 >> - responses to non-queued requests >> - errors >>=20 >> other than the implicit standard HTTP response/error codes. >>=20 >>=20 >> 3. It's too tightly bound to the underlying HTTP interface. The = response/errors is one example, another is the queue element field: >>=20 >> # The HTTP method used to update >> attribute method { "PUT" | "DELETE" }, >>=20 >> That would be better as a logical operation code (i.e. Add, Delete) = that were mapped onto HTTP operations. >>=20 >> 4. Some of the key data elements that need to be provisioning are = defined the most loosely - name the rdata field. >>=20 >> So overall I'm pretty surprised that this path was chosen in 2011 = rather than EPP which the rest of the known universe uses for this sort = of thing. I realise ICANN is very much taken with lightweight REST but = this seems to be forcing the solution onto every problem, even then = solved ones. However, this is indeed ICANN's choice, it is a trivial = protocol and is working in production. But what it isn't is a candidate = for becoming an RFC. >>=20 >> If the authors are interested in doing this in EPP then I would be = willing to help. >>=20 >> cheers >> Jay >>=20 >> -- >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >> linkedin: www.linkedin.com/in/jaydaley >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From terry.manderson@icann.org Mon Aug 12 16:59:29 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6A621F9D9A for ; Mon, 12 Aug 2013 16:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV5O5lRCD6u4 for ; Mon, 12 Aug 2013 16:59:24 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id E032E21F9BF3 for ; Mon, 12 Aug 2013 16:59:23 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 12 Aug 2013 16:59:23 -0700 From: Terry Manderson To: Jay Daley , dnsop WG Date: Mon, 12 Aug 2013 16:59:20 -0700 Thread-Topic: [DNSOP] Review of draft-manderson-rdns-xml-01 Thread-Index: Ac6Xt/dzXq0ovekJR0uGnkANfsWs6Q== Message-ID: In-Reply-To: <92F4C715-FF72-4CEE-9C17-134932228F13@nzrs.net.nz> 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 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3459232760_64899443" MIME-Version: 1.0 Subject: Re: [DNSOP] Review of draft-manderson-rdns-xml-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 23:59:29 -0000 --B_3459232760_64899443 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Jay, I'll try to answer your questions, but the intent was to solicit reviews for the RFC-ISE. If you would like to be a reviewer in that direction please do so! On 13/08/13 8:05 AM, "Jay Daley" wrote: >Firstly, just to confirm that I've read the previous email from Terry >Manderson that this draft was published more for reasons of transparency >and starting a conversation than anything else. So here are my comments >in light of that: > >1. There were a number of places in this draft where I found myself >asking "why didn't they just use EPP?". For example: > >- it's a registry provisioning protocol >- it's a registry provisioning protocol for NS and DS records! >- it has a feature for requests to be queued and a message list to be >polled While it's nice to assume that everyone should use some particular protocol for a solution, sometimes business desires overtake any particular technical position. EPP was considered, and this document should not be "why we didn't use EPP", but the end consideration was that the objects in question did not fall into the classical registry/registrar approach as the rights of assignment of the overarching objects (the IP address blocks) fall in a process and policy that sits on a level well above the provisioning of DNSSEC records. Also EPP, while extensible, was also considered waaaaaay to heavy for the slim function that was being targeted. > > >2. Unless I'm being dumb (and my RelaxNG is not very good) I can't see >any definition of either > >- responses to non-queued requests >- errors > >other than the implicit standard HTTP response/error codes. Correct, the service is a RESTFUL application, and with that the HTTP error codes are considered the most atomic feature, and the item that should be passed back first and foremost. > > >3. It's too tightly bound to the underlying HTTP interface. The >response/errors is one example, another is the queue element field: > ># The HTTP method used to update > attribute method { "PUT" | "DELETE" }, > >That would be better as a logical operation code (i.e. Add, Delete) that >were mapped onto HTTP operations. "too tightly"? I think "intended". :-) While it is possible to abstract such items in the XML, the underlying statement is that this system will not (ever) operate on anything other than HTTPS. It's also note worthy that the HTTP method describes precisely the operation undertaken. > > >4. Some of the key data elements that need to be provisioning are >defined the most loosely - name the rdata field. Yes. The RDATA is one part I was never really super-duper ecstatic about. But it stuck. (perfect was the enemy of good) > >So overall I'm pretty surprised that this path was chosen in 2011 rather >than EPP which the rest of the known universe uses for this sort of >thing. I realise ICANN is very much taken with lightweight REST but this >seems to be forcing the solution onto every problem, even then solved >ones. However, this is indeed ICANN's choice, it is a trivial protocol >and is working in production. But what it isn't is a candidate for >becoming an RFC. I think, Jay, you might be one step removed from what the problem was. It wasn't "how can we use EPP here", nor was it "how can we use REST there". In terms of a candidate becoming an RFC, please cast your eyes over http://www.rfc-editor.org/indsubs.html and if you still feel that way, drop me a personal note and we can discuss why/why-not offline. > >If the authors are interested in doing this in EPP then I would be >willing to help. The system is implemented, it has been for a number of years, and operates precisely as designed. Should someone, amongst the 'customers' of the system, request ICANN to make this system EPP and provide good reason - then I will certainly put you on the top on my "to call" list. Cheers Terry --B_3459232760_64899443 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFEVyXDoC8okETxoAZAKRH306maOSMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMDgxMjIzNTkyMFowDQYJKoZIhvcNAQEBBQAEggEAUCc8F5vo cHKlgtiZGweR+4KK9PPpC7U39cTqrdHsvTNB3Ekh2TSo6vYT4VcedYerhJijJCaFaFWwVgpK gfhSXR7Rrsfx9S+QYBoZtcPnloeb/eA+8lX5zwg1P1zN1o4kjBJ/0LYdbr3w1MFmHtDXcNEk 6mbLz7juvaQ5LBA5seP7sMLimI2h5RDSleKh7QXBXlHNy3dXOkgg+tsvoPYfnylcbuo0H/Kw 45pFh9eya3zSY3iQfa5dDiAaLwRVcu+di3iAhtrRD5vqmy518QAiWldioEPREfQXUUIwxc2g 6DWord4R2tg5GjpHe8DaaifZ4DCWFM3VCOdehe+1A10D9g== --B_3459232760_64899443-- From ggm@algebras.org Mon Aug 12 17:04:24 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F1511E80F0 for ; Mon, 12 Aug 2013 17:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY+Wc0G4OSH1 for ; Mon, 12 Aug 2013 17:04:21 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 04E9111E80ED for ; Mon, 12 Aug 2013 17:04:20 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id up15so7302011pbc.26 for ; Mon, 12 Aug 2013 17:04:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VZJ+XCgSXu00qAM3L3rDNwtNJTO6aTl2gTkhUPYFsXQ=; b=YjN0XD/N2Bt06U5wFaWZWl/+Scfqc1qzeK/0KieADduQlSQpzjQm/2QU1sDb0ATkKX QJISqKe7o2CROHjoIFGD8LPwaWpv699YQ3xlEnLxyQ1CQlRyoQPkpmMmHZXRYUARnktn rYUzgcawRAhNycT55fG6fuA/jLjDKwqev8rACTXK4YTDQ/t8b+GSEyj00hc+QVFyt74a dLfxsXnYgdnuXp9ikh3qSE46pJ3H2p3wiC7RcTE9ZjTjvg1LL8tpeFzx7RoQvOZx6Hfy wTd0h3Y7uN08wKBQ/UKmoNbmQz1dEyQJ994xlUHPF+psmlpOf6J2VNmRfm6iYVymQob1 Eb0Q== X-Gm-Message-State: ALoCoQkHjOD9WGYAC5ZIdXWgaNKTETUelje9psTFh0X1sBgU3SwoYPo/2aKBH5IEVyjgg3vkyl0m MIME-Version: 1.0 X-Received: by 10.66.163.199 with SMTP id yk7mr1539868pab.136.1376352260619; Mon, 12 Aug 2013 17:04:20 -0700 (PDT) Received: by 10.70.19.98 with HTTP; Mon, 12 Aug 2013 17:04:20 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:b135:e004:f9ed:5af3] In-Reply-To: <9B4EAB28-0301-474D-9F87-2BC49E55DB01@nzrs.net.nz> References: <92F4C715-FF72-4CEE-9C17-134932228F13@nzrs.net.nz> <8247861913252083991@unknownmsgid> <9B4EAB28-0301-474D-9F87-2BC49E55DB01@nzrs.net.nz> Date: Tue, 13 Aug 2013 10:04:20 +1000 Message-ID: From: George Michaelson To: Jay Daley Content-Type: multipart/alternative; boundary=047d7b86e54094949704e3c8fbbc Cc: dnsop WG , Joe Abley Subject: Re: [DNSOP] Review of draft-manderson-rdns-xml-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 00:04:25 -0000 --047d7b86e54094949704e3c8fbbc Content-Type: text/plain; charset=ISO-8859-1 My personal view, from deep time, is that this protocol was offered into the process facing upwards, as a result of an applications REST interface which was developed in APNIC facing downwards. Terry may have a different perspective but thats my sense: we had this working in-house as a lightweight mechanism to solve a specific problem and it happened to be a good fit for a very similar problem facing our parents in reverse-DNS provisioniong. We have frequently discussed EPP for Internet Number Resources (INR) in the RIR system, and never found it a good fit. Ed Lewis demonstrated extensions at an APNIC meeting in my deep memory. The critique is: its hugely complex, and based on binary prototcols in ways we don't find tractable. The positives are that many holders of INR have an investment in EPP to do their provisioning for customers with domain names. The break point is that while the provisioning investment has been made, its different people inside the INR holding entity, and the current number holders are more familiar with textual update mechanisms like RPSL, whois objects, and REST. I think EPP's time window to be deployed has come and gone. thats just my personal opinion. -G On Tue, Aug 13, 2013 at 9:28 AM, Jay Daley wrote: > > On 13/08/2013, at 10:57 AM, Joe Abley wrote: > > > Hi Jay, > > > > I'm not sure I understand your conclusion. Why do you think this > > running system should not be documented in an RFC? > > > > If it was a private-use protocol being used for private purposes, I > > could see what you're getting at. However, it's neither: it's a > > protocol in use between different organisations being used to support > > an aspect of public infrastructure (the reverse DNS trees). > > I'm not sure how you can describe this as anything other than a private > protocol. Yes it is part of the public infrastructure but then there are a > myriad of private EPP extensions out there that also work on the public > infrastructure and yet would equally not be suitable for an RFC. So I > don't think the 'public infrastructure' argument holds water. > > For it to be an RFC I would hope that meets a decent threshold, namely: > > 1. there is at least some sense of architectural positioning in relation > to other protocols. This draft doesn't have that as it seems to do a small > part of an otherwise perfectly good protocol, EPP, without any > reference/recognition of how the two fit together. > > 2. there is a relatively clean separation of layers. This is not the > case with this draft as it tightly binds onto HTTP. > > 3. it is a public protocol. For this to be a public protocol the rules > are pretty clear - two implementations in different contexts. AFAICT this > has only one server implementation and multiple clients in the same context. > > While 2. can be fixed I'm not sure 1. and 3. can be. > > > I don't agree that there's nothing to be gained by documenting it (I > > realise that's not exactly what you wrote, but it could be read that > > way) and to me, the RFC series is a plausible place for that to > > happen. > > There is every benefit to this being documented, I am glad that it is and > would not wish that to change. However using the RFC process for a > private protocol is inappropriate and it would be better if there was a web > site had a section that documented all the ICANN private protocols, in much > the same way many TLD operators do. > > > What am I missing? > > I really do not mean to cause any offence by this so apologies in advance > if I do, but is this a case of ICANN mistaking its position here? Yes you > are the excellent operator of a key part of the public infrastructure but > that doesn't mean that every protocol you develop related to your technical > function automatically becomes an RFC when documented to a sufficient > standard. > > cheers > Jay > > > > > > > (ObDisclaimer: Terry and I work together, but this is a personal > > perspective; he's big and ugly enough to fight his own battles :-) > > > > > > Joe > > > > Aue Te Ariki! He toki ki roto taku mahuna! > > > > On 2013-08-12, at 18:06, Jay Daley wrote: > > > >> Firstly, just to confirm that I've read the previous email from Terry > Manderson that this draft was published more for reasons of transparency > and starting a conversation than anything else. So here are my comments in > light of that: > >> > >> 1. There were a number of places in this draft where I found myself > asking "why didn't they just use EPP?". For example: > >> > >> - it's a registry provisioning protocol > >> - it's a registry provisioning protocol for NS and DS records! > >> - it has a feature for requests to be queued and a message list to be > polled > >> > >> > >> 2. Unless I'm being dumb (and my RelaxNG is not very good) I can't see > any definition of either > >> > >> - responses to non-queued requests > >> - errors > >> > >> other than the implicit standard HTTP response/error codes. > >> > >> > >> 3. It's too tightly bound to the underlying HTTP interface. The > response/errors is one example, another is the queue element field: > >> > >> # The HTTP method used to update > >> attribute method { "PUT" | "DELETE" }, > >> > >> That would be better as a logical operation code (i.e. Add, Delete) > that were mapped onto HTTP operations. > >> > >> 4. Some of the key data elements that need to be provisioning are > defined the most loosely - name the rdata field. > >> > >> So overall I'm pretty surprised that this path was chosen in 2011 > rather than EPP which the rest of the known universe uses for this sort of > thing. I realise ICANN is very much taken with lightweight REST but this > seems to be forcing the solution onto every problem, even then solved ones. > However, this is indeed ICANN's choice, it is a trivial protocol and is > working in production. But what it isn't is a candidate for becoming an > RFC. > >> > >> If the authors are interested in doing this in EPP then I would be > willing to help. > >> > >> cheers > >> Jay > >> > >> -- > >> Jay Daley > >> Chief Executive > >> .nz Registry Services (New Zealand Domain Name Registry Limited) > >> desk: +64 4 931 6977 > >> mobile: +64 21 678840 > >> linkedin: www.linkedin.com/in/jaydaley > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > linkedin: www.linkedin.com/in/jaydaley > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --047d7b86e54094949704e3c8fbbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

My personal view, from deep time, is that this protocol wa= s offered into the process facing upwards, as a result of an applications R= EST interface which was developed in APNIC facing downwards. Terry may have= a different perspective but thats my sense: we had this working in-house a= s a lightweight mechanism to solve a specific problem and it happened to be= a good fit for a very similar problem facing our parents in reverse-DNS pr= ovisioniong.

We have frequently discussed EPP for Internet Number Resourc= es (INR) in the RIR system, and never found it a good fit. Ed Lewis demonst= rated extensions at an APNIC meeting in my deep memory. The critique is: it= s hugely complex, and based on binary prototcols in ways we don't find = tractable. The positives are that many holders of INR have an investment in= EPP to do their provisioning for customers with domain names. The break po= int is that while the provisioning investment has been made, its different = people inside the INR holding entity, and the current number holders are mo= re familiar with textual update mechanisms like RPSL, whois objects, and RE= ST.

I think EPP's time window to be deployed has come a= nd gone. thats just my personal opinion.

-G

<= div>