Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBmLb-0000jV-DL; Tue, 30 Jan 2007 01:20:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBmLZ-0000jK-Uw for peppermint@ietf.org; Tue, 30 Jan 2007 01:20:01 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBmLY-0007Ki-KU for peppermint@ietf.org; Tue, 30 Jan 2007 01:20:01 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0U6Jslm031309 for ; Tue, 30 Jan 2007 01:19:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PEPPERMINT] new BoF proposal Date: Tue, 30 Jan 2007 08:19:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] new BoF proposal Thread-Index: AcdDC0Dz81DdNwmoTKK6DZe/P8REuQBKyAIg References: <6F5BC580-3C9C-44EB-839D-3004CFAC2250@hxr.us> From: "Romascanu, Dan \(Dan\)" To: "Andrew Newton" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Andy Bierman X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org =20 =20 > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > The final work > product(s) from this working group will be based upon XML. =20 > Additionally, > bias will be given to re-using either EPP, HTTP/REST,=20 > HTTP/XML-RPC, or HTTP/SOAP. >=20 I would suggest that we add NETCONF to the list of possible technologies to consider for re-use.=20 Dan _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdqe-0001St-Uh; Mon, 29 Jan 2007 16:15:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdqd-0001SE-PW; Mon, 29 Jan 2007 16:15:31 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBdqb-0007Vi-7Z; Mon, 29 Jan 2007 16:15:31 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l0TLFEeS020981; Mon, 29 Jan 2007 13:15:22 -0800 From: "Richard Shockey" To: , , Date: Mon, 29 Jan 2007 16:15:00 -0500 Message-ID: <011001c743ea$8d53b4f0$67201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0111_01C743C0.A47DACF0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdD5yT2a/a8URTkTpisJWeWrU35bwAA0uTQ X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Subject: [PEPPERMINT] FYI - -D ACTION:draft-newton-peppermint-problem-statement-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0111_01C743C0.A47DACF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, January 29, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-newton-peppermint-problem-statement-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Provisioning Extensions in Peering Registries for > Multimedia Interconnection (PEPPERMINT) Problem Statement > Author(s) : A. Newton > Filename : draft-newton-peppermint-problem-statement-00.txt > Pages : 13 > Date : 2007-1-29 > > This document contains descriptions of the problems faced by > operators and participants of multimedia interconnection (i.e. SIP) > peering registries with respect to identity provisioning. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-newton-peppermint-problem- > statement-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-newton-peppermint-problem-statement-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-newton-peppermint-problem-statement- > 00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_0111_01C743C0.A47DACF0 Content-Type: Message/External-body; name="ATT00146.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00146.dat" Content-Type: text/plain Content-ID: <2007-1-29110404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-newton-peppermint-problem-statement-00.txt ------=_NextPart_000_0111_01C743C0.A47DACF0 Content-Type: Message/External-body; name="draft-newton-peppermint-problem-statement-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-newton-peppermint-problem-statement-00.txt" Content-Type: text/plain Content-ID: <2007-1-29110404.I-D@ietf.org> ------=_NextPart_000_0111_01C743C0.A47DACF0 Content-Type: text/plain; name="ATT00149.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00149.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0111_01C743C0.A47DACF0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint ------=_NextPart_000_0111_01C743C0.A47DACF0-- Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBEtJ-0001Xj-6h; Sun, 28 Jan 2007 13:36:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBEtI-0001XZ-8X for peppermint@ietf.org; Sun, 28 Jan 2007 13:36:36 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBEtG-0006co-Ui for peppermint@ietf.org; Sun, 28 Jan 2007 13:36:36 -0500 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 28 Jan 2007 13:35:55 -0500 id 0158811A.45BCED0C.000024D2 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6F5BC580-3C9C-44EB-839D-3004CFAC2250@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: peppermint@ietf.org From: Andrew Newton Date: Sun, 28 Jan 2007 13:36:29 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.6 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [PEPPERMINT] new BoF proposal X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org All, A tightened up version of the PEPPERMINT BoF proposal has been formulated. The major changes since the last version are: 1) some language has been changed or eliminated that was construed to give PEPPERMINT a larger scope than intended, and 2) the input documents are listed. The text is below. Comments, questions, and suggestions welcomed. -andy Peppermint BOF Provisioning Extensions in Peering Registries for Multimedia INTerconnection. Mailing Lists: BOF chairs: Andrew Newton [andy@hxr.us] Richard Shockey [rich.shockey@neustar.biz] Temporary Area Directorate: Real Time Applications (RAI) Ultimate Area Directorate: TBD BOF Purpose. The ENUM and SPEERMINT working groups are working on various aspects of Multi Media Interconnection. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across domain boundaries. It is clear from discussions in both working groups that Multi-Media Interconnection will require address of record data to be provisioned among administrative domains outside the normal scope of establishing a SIP session. The purpose of the BOF is to determine the need and scope for such data exchanges, what existing protocols need to be adapted to meet those needs and the appropriate schema and queries are needed to facilitate such exchanges. The IETF has in the past done significant work on data exchanges among various administrative entities. In particular the PROVREG working group developed various schema and query mechanisms to facilitate the exchange of data among domain name registries and registrars. The ENUM Working group has adapted PROVREG working group protocols to develop RFC 4114, which facilitates the provisioning of ENUM data in the DNS tree. However, there has been little adoption of RFC 4114, and many in the operator community require both data models and protocol features not found in RFC 4114. The proposed PEPPERMINT working group will build upon the knowledge gained from those efforts, and the intent of this proposed working group is to find a provisioning solution for peering as defined by SPEERMINT. The final work product(s) from this working group will be based upon XML. Additionally, bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or HTTP/SOAP. Proposed Deliverables: 1) Requirements for SPEERMINT data exchange. 2) Provisioning of SPEERMINT data registries. 3) Provisioning of SPEERMINT/ENUM data caches. Input Documents: 1) PEPPERMINT Problem Statement draft-newton-peppermint-problem-statement-00.txt 2) E.164 Number Provisioning Requirements - Data Set Requirements draft-schwartz-peppermint-e164-provisioning-data-set-00.txt 3) ENUM Registry Interface Requirements draft-lewis-peppermint-enum-reg-if-00.txt _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBEoE-0006lF-TT; Sun, 28 Jan 2007 13:31:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBEoD-0006kl-SI for peppermint@ietf.org; Sun, 28 Jan 2007 13:31:21 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBEoC-0002TP-Ms for peppermint@ietf.org; Sun, 28 Jan 2007 13:31:21 -0500 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 28 Jan 2007 13:30:39 -0500 id 0158811A.45BCEBCF.00002391 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: peppermint@ietf.org From: Andrew Newton Date: Sun, 28 Jan 2007 13:31:12 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.2 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [PEPPERMINT] draft-newton-peppermint-problem-statement-00 X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org All, I've written a draft describing the problem to which PEPPERMINT is to be applied. Of course, this is simply my opinion and holds no more weight than the opinion of others. But I had received several private inquiries about the nature of PEPPERMINT, so I decided to write a draft to explain things to those not in the SIP peering community. And for those of us in the SIP peering community, hopefully this will help align our goals. Since the draft won't show up in the repository until Monday afternoon at best, I've posted the HTML version on-line: http:// ecotroph.net/~anewton/draft-newton-peppermint-problem-statement-00.html -andy _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB0f8-0007Em-Si; Sat, 27 Jan 2007 22:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB0f6-0007Ee-Po for PEPPERMINT@ietf.org; Sat, 27 Jan 2007 22:25:00 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB0f3-00060H-Bk for PEPPERMINT@ietf.org; Sat, 27 Jan 2007 22:25:00 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l0S3L8o5022785; Sat, 27 Jan 2007 19:21:14 -0800 From: "Richard Shockey" To: "'Drage, Keith \(Keith\)'" , "'Creighton, Tom'" , References: <45AEC6EF95942140888406588E1A6602C9A771@PACDCEXCMB04.cable.comcast.com> <5D1A7985295922448D5550C94DE29180B88193@DEEXC1U01.de.lucent.com> Subject: RE: [PEPPERMINT] PEPPERMINT BoF? Date: Sat, 27 Jan 2007 22:20:58 -0500 Message-ID: <027401c7428b$553b8580$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <5D1A7985295922448D5550C94DE29180B88193@DEEXC1U01.de.lucent.com> Thread-Index: AcdBfI61kcLMUFoURQCPNf5USC6BbAAJ+PdgADmvCQA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org To my knowledge the IESG has not yet met to approve the BOF schedules yet. > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Friday, January 26, 2007 6:50 PM > To: Creighton, Tom; PEPPERMINT@ietf.org > Subject: RE: [PEPPERMINT] PEPPERMINT BoF? > > The information on all deadline dates for IETF#68 is here. > > http://www.ietf.org/meetings/68-cutoff_dates.html > > We have not yet reached the date when the draft agenda is published, and > even then it is still subject to change up to the last minute. > > > Regards > > Keith > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: 26 January 2007 19:03 > > To: PEPPERMINT@ietf.org > > Subject: [PEPPERMINT] PEPPERMINT BoF? > > > > Has a tentative date been set for the PEPPERMINT BoF? > > > > Regards, > > > > Tom > > > > _______________________________________________ > > PEPPERMINT mailing list > > PEPPERMINT@ietf.org > > https://www1.ietf.org/mailman/listinfo/peppermint > > > > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www1.ietf.org/mailman/listinfo/peppermint _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAapm-0002ny-H5; Fri, 26 Jan 2007 18:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAapl-0002ns-P3 for PEPPERMINT@ietf.org; Fri, 26 Jan 2007 18:50:17 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAapk-0007hu-CC for PEPPERMINT@ietf.org; Fri, 26 Jan 2007 18:50:17 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0QNoAcA010116; Fri, 26 Jan 2007 17:50:10 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 17:50:10 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 00:50:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PEPPERMINT] PEPPERMINT BoF? Date: Sat, 27 Jan 2007 00:50:07 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180B88193@DEEXC1U01.de.lucent.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602C9A771@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] PEPPERMINT BoF? Thread-Index: AcdBfI61kcLMUFoURQCPNf5USC6BbAAJ+Pdg References: <45AEC6EF95942140888406588E1A6602C9A771@PACDCEXCMB04.cable.comcast.com> From: "Drage, Keith \(Keith\)" To: "Creighton, Tom" , X-OriginalArrivalTime: 26 Jan 2007 23:50:08.0950 (UTC) FILETIME=[B6226D60:01C741A4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org The information on all deadline dates for IETF#68 is here. http://www.ietf.org/meetings/68-cutoff_dates.html We have not yet reached the date when the draft agenda is published, and even then it is still subject to change up to the last minute. Regards Keith=20 > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com]=20 > Sent: 26 January 2007 19:03 > To: PEPPERMINT@ietf.org > Subject: [PEPPERMINT] PEPPERMINT BoF? >=20 > Has a tentative date been set for the PEPPERMINT BoF? >=20 > Regards, >=20 > Tom >=20 > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www1.ietf.org/mailman/listinfo/peppermint >=20 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWM4-0002h6-5l; Fri, 26 Jan 2007 14:03:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWM3-0002h0-13 for peppermint@ietf.org; Fri, 26 Jan 2007 14:03:19 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWLx-0004k2-Lh for peppermint@ietf.org; Fri, 26 Jan 2007 14:03:19 -0500 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.29881578; Fri, 26 Jan 2007 14:02:44 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 14:02:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jan 2007 14:02:42 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602C9A771@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PEPPERMINT BoF? Thread-Index: AcdBfI61kcLMUFoURQCPNf5USC6BbA== From: "Creighton, Tom" To: X-OriginalArrivalTime: 26 Jan 2007 19:02:43.0506 (UTC) FILETIME=[8F0C8120:01C7417C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [PEPPERMINT] PEPPERMINT BoF? X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org Has a tentative date been set for the PEPPERMINT BoF? Regards, Tom _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3yf-0003UB-PR; Thu, 25 Jan 2007 07:45:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3ye-0003U5-TL for peppermint@ietf.org; Thu, 25 Jan 2007 07:45:16 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA3yd-0005ja-IZ for peppermint@ietf.org; Thu, 25 Jan 2007 07:45:16 -0500 Received: from [192.168.1.101] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id l0PCZoje063859; Thu, 25 Jan 2007 07:35:51 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF0701ADD8A1@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF0701ADD8A1@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Thu, 25 Jan 2007 07:45:07 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.57 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: peppermint@ietf.org, Edward Lewis X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org At 7:22 -0500 1/25/07, Hollenbeck, Scott wrote: >One concrete suggestion, Ed: right now the draft reads like a >requirements document. If you're trying to describe your own >implementation experience, you should change the title and text to >reflect that goal. Taken in that context there's a lot of information >in the document that could help us avoid "has anyone tried?" questions. What I want to do is present a requirements document. I'm saying that it is based on our experiences to help explain away why it may not be all encompassing, i.e., why it may not have requirements that others have stumbled across in their experience. I don't really want to describe our experience, but base a requirements document on it for starters. There's a sensitive issue in the IETF of people coming to a WG with an assembled solution and being perceived as asking for rubber stamp approval. I think the document would get along better as being based on a broader set of experience than we have at an "individual -00" (i.e., just ours) but I had to start somewhere. I think raising up "has anyone tried?" questions would be good. I think that would help in vetting the final solution, for what ever value of $final is used. Referring to my pat answer...if this work gets a WG and the requirements document I've submitted gets adopted, it will no longer be merely a reflection of just our experience. Until then though, I want to ground it only in the reality of our experience as opposed to supplementing our experience with hypothetical issues. I should add that our implementation probably fails to meet at least one of the requirements. I picked one requirement up from reading mail exchanged after we were in the testing phase for what we have. If there is other experience to draw from, great. We just haven't gone seeking other opinions because our project goal was more of "solving a need" we see at hand than "creating a standard." In the sense that "creating a standard" for the exercise of "creating a standard" is more or less a waste of time, I think that the "need" has to precede the "standard." BTW - when I flip between "we" and "I" here I am differentiating between me as the author of the document and we as in the team of developers doing the work. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3cR-0007q5-5a; Thu, 25 Jan 2007 07:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3cQ-0007pU-0y for peppermint@ietf.org; Thu, 25 Jan 2007 07:22:18 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA3cO-0007p0-PH for peppermint@ietf.org; Thu, 25 Jan 2007 07:22:17 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id l0PCMGCY002117; Thu, 25 Jan 2007 07:22:16 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 07:22:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Date: Thu, 25 Jan 2007 07:22:57 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF0701ADD8A1@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Thread-Index: Acc/+FYpbk2NI8xqQwi7enwAGWHk1QAgqlAQ From: "Hollenbeck, Scott" To: "Edward Lewis" X-OriginalArrivalTime: 25 Jan 2007 12:22:12.0396 (UTC) FILETIME=[70FA5EC0:01C7407B] X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: peppermint@ietf.org X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 > Sent: Wednesday, January 24, 2007 3:43 PM > To: Hollenbeck, Scott > Cc: Andrew Newton; peppermint@ietf.org > Subject: RE: [PEPPERMINT] comments on=20 > draft-lewis-peppermint-enum-ref-if-00 >=20 > At 7:37 -0500 1/24/07, Hollenbeck, Scott wrote: >=20 > >Disclaimer: I'm the author of EPP. I have a bias. >=20 > Disclaimer: I was one of the co-chairs of provreg. "Shooting down"=20 > the product of your erstwhile WG isn't that delightful. (I should=20 > add that Scott did all the work in the group.) >=20 > >Indeed. It's already being used in ENUM contexts. The=20 > country code 1 > >user ENUM trial, for example, is using EPP. > > > >I'd like to see any analysis of data wrapping protocol to include a > >discussion of the issues associated with tunneling data re-using HTTP > >and port 80. The Security Considerations section would be a=20 > good place > >to add text. Let's discuss the software engineering and deployment > >issues associated with adding HTTP and SOAP software layers,=20 > too. It's > >not as simple as "build on top of SOAP", folks. >=20 > Before writing this draft, we had an internal meeting/discussion on=20 > this debate. [snip] One concrete suggestion, Ed: right now the draft reads like a requirements document. If you're trying to describe your own implementation experience, you should change the title and text to reflect that goal. Taken in that context there's a lot of information in the document that could help us avoid "has anyone tried?" questions. -Scott- _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qLn-0006WB-Fu; Wed, 24 Jan 2007 17:12:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qLm-0006Uh-UU for peppermint@ietf.org; Wed, 24 Jan 2007 17:12:14 -0500 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qLJ-0003Cz-Hk for peppermint@ietf.org; Wed, 24 Jan 2007 17:11:46 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Date: Thu, 25 Jan 2007 00:11:41 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550201F4CA@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Thread-index: AcdABJ/2fThc1VtaRtyCHTnGMv8YUQ== From: "David Schwartz" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2077582780==" Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. --===============2077582780== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74004.A1BA6428" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74004.A1BA6428 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am curious. =20 If ENUM is the mechanism of choice (as opposed to redirect) how can the querying party pass information in the query as to who he is? What is I want to present different information depending on "who is asking"?=20 =20 Surely the answer is not "Check which IP the request originated from", since this forces end user querying as opposed to VSP querying.=20 =20 David ------_=_NextPart_001_01C74004.A1BA6428 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am curious.

 

If ENUM is the mechanism of choice (as opposed to = redirect) how can the querying party pass information in the query as to who he = is? What is I want to present different information depending on “who is = asking”?

 

Surely the answer is not “Check which IP the = request originated from”, since this forces end user querying as opposed = to VSP querying.

 

David

------_=_NextPart_001_01C74004.A1BA6428-- --===============2077582780== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint --===============2077582780==-- Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oy4-00046j-4q; Wed, 24 Jan 2007 15:43:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oy3-00046d-K0 for peppermint@ietf.org; Wed, 24 Jan 2007 15:43:39 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9oy2-0008Up-56 for peppermint@ietf.org; Wed, 24 Jan 2007 15:43:39 -0500 Received: from [10.31.32.33] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id l0OKYH8S059467; Wed, 24 Jan 2007 15:34:18 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF0701A7B35B@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF0701A7B35B@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Wed, 24 Jan 2007 15:43:27 -0500 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: peppermint@ietf.org X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org At 7:37 -0500 1/24/07, Hollenbeck, Scott wrote: >Disclaimer: I'm the author of EPP. I have a bias. Disclaimer: I was one of the co-chairs of provreg. "Shooting down" the product of your erstwhile WG isn't that delightful. (I should add that Scott did all the work in the group.) >Indeed. It's already being used in ENUM contexts. The country code 1 >user ENUM trial, for example, is using EPP. > >I'd like to see any analysis of data wrapping protocol to include a >discussion of the issues associated with tunneling data re-using HTTP >and port 80. The Security Considerations section would be a good place >to add text. Let's discuss the software engineering and deployment >issues associated with adding HTTP and SOAP software layers, too. It's >not as simple as "build on top of SOAP", folks. Before writing this draft, we had an internal meeting/discussion on this debate. The reason our implementors eschewed EPP was the experience of having to build and maintain client tool kits for our EPP-using customers. That was a big factor to them. (The implementors have experience in both EPP and SOAP.) Also, the customers for the ENUM work had no real familiarity with EPP but did know SOAP. In going over the discussion and knowing I would have to commit this to paper, my verbal summary was that the separating factors are factors not usually important in IETF discussions. Our preference for SOAP over EPP was based on software engineering and software management workload. Not just in-house but also what was either reported by or sensed from our client partners. There isn't a major protocol-engineering detail that differentiates the two approaches, and sure, you could use XML schema extensions over EPP. And if you look at the protocol aspects, you could more or less call it a draw. Depending on your metrics, you could decide in favor of EPP. (Or SOAP.) As far as the tunneling over HTTP, etc., that was considered. In this context, there was no fear of it and in fact a familiarity with it. I don't think it would be productive to be too detailed on this item until we get a bit more steam on being a WG. I'll leave it as is at this point. The -00 of the document reflects our experience in getting our hands dirty on this. Once we go "WG" our experience is just one opinion to cover. For the time being, we can only truthfully document from our own experience. >This isn't as simple as "EPP vs. SOAP". You could, for example, carry >the EPP data structures in SOAP instead of streaming them over TCP as >described in RFC 3734. Not that I'm advocating that, but it illustrates >my point. And I wanted this to be the next point after my response. The draft picks on the EPP vs. SOAP angle because that is the one "debate" we see looming, and it is one we obviously choose a side on when building our implementation and conducted our testing. I am agreeing that is isn't that simple a choice. It's just that it was this choice was worth documenting. As predicted, there's a discussion already rising on this. >If this document is intended to describe interface requirements it >shouldn't focus on one protocol or the other. It should describe the >*requirements* for the provisioning protocol interface. We can debate >which tools best meet the requirements when we get there. The first line of section 5 should cue that in. Up until section 5 any bias is unintentional. After that, we are talking about our experience and the one fairly significant design choice we made. >We should also consider the possibility of obsoleting and replacing RFC >4114 if it's proving to be inadequate. Heck, it's only a *Proposed* >standard. If implementation experience demonstrates that it's >inadequate, well, that's why we have a multi-stage standards track. I don't think that there's any overt desire to make RFC 4114 sleep with the fishes. For instance, there may be places where "legacy" favors EPP. Perhaps if we go "WG" then a decision on what to do about RFC 4114's lack of adoption ought to be in the charter. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oaH-0000a7-Ld; Wed, 24 Jan 2007 15:19:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oaH-0000Zi-2Z for peppermint@ietf.org; Wed, 24 Jan 2007 15:19:05 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9oaF-0000kY-O3 for peppermint@ietf.org; Wed, 24 Jan 2007 15:19:05 -0500 Received: from [10.31.32.33] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id l0OK9nZ0059345; Wed, 24 Jan 2007 15:09:50 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <9450E37B-E089-4F85-B74D-DE7992E19256@hxr.us> References: <15AD0157-402D-4BF1-B420-98977845BE01@hxr.us> <02F027E8-91B9-4FD0-92B5-56EADFF2E5AD@hxr.us> <9450E37B-E089-4F85-B74D-DE7992E19256@hxr.us> Date: Wed, 24 Jan 2007 15:16:56 -0500 To: Andrew Newton From: Edward Lewis Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.57 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: peppermint@ietf.org, Edward Lewis X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org At 12:07 -0500 1/24/07, Andrew Newton wrote: >On Jan 24, 2007, at 11:51 AM, Edward Lewis wrote: >> But I don't really want to spend a long time trying to find >>something better just because we should. > >Wow! I'm not sure if I need to clarify something...if we can cobble together a solution that meets the requirements from existing technologies we should do that. I think trying to reinvent a technology (e.g., a means to convey bytes from one place to another) is waste of time unless the technology is truly in need of reinventing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lb7-0008EM-K7; Wed, 24 Jan 2007 12:07:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lb6-0008ED-9y for peppermint@ietf.org; Wed, 24 Jan 2007 12:07:44 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9lb5-0005DA-45 for peppermint@ietf.org; Wed, 24 Jan 2007 12:07:44 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 24 Jan 2007 12:07:03 -0500 id 0158836D.45B79237.00004F07 In-Reply-To: References: <15AD0157-402D-4BF1-B420-98977845BE01@hxr.us> <02F027E8-91B9-4FD0-92B5-56EADFF2E5AD@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9450E37B-E089-4F85-B74D-DE7992E19256@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Date: Wed, 24 Jan 2007 12:07:37 -0500 To: Edward Lewis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: peppermint@ietf.org X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org On Jan 24, 2007, at 11:51 AM, Edward Lewis wrote: > Publication rules - I mean the ability to say "give this NAPTR set > to carrier A", "give this to B", and give this back to me when I > ask. Probably more simply put, "here's the NAPTR set for external > consumption and here's the NAPTR set I want to see in my own DNS." Though in the end we will have to flesh this out some more, I now understand what you are talking about. It is a very good consideration. > But I don't really want to spend a long time trying to find > something better just because we should. Wow! -andy _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lLm-0000RQ-2E; Wed, 24 Jan 2007 11:51:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lLj-0000QW-Ko for peppermint@ietf.org; Wed, 24 Jan 2007 11:51:52 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9lLi-0002il-8D for peppermint@ietf.org; Wed, 24 Jan 2007 11:51:51 -0500 Received: from [10.31.32.33] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id l0OGgV2p058292; Wed, 24 Jan 2007 11:42:31 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <02F027E8-91B9-4FD0-92B5-56EADFF2E5AD@hxr.us> References: <15AD0157-402D-4BF1-B420-98977845BE01@hxr.us> <02F027E8-91B9-4FD0-92B5-56EADFF2E5AD@hxr.us> Date: Wed, 24 Jan 2007 11:51:40 -0500 To: Andrew Newton From: Edward Lewis Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.57 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: peppermint@ietf.org, Edward Lewis X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org The message quoting is all messed up here...so I'll resort to top posting. I think it's pretty clear we want to convey what's in a NAPTR. For what we don't have a NAPTR for, there's the (some would say "unenviable" but that is not for this argument) fallback of the TXT. From our experience, that is all that we have seen the need to be able to convey. Perhaps that is all we want to have, but I wasn't willing yet to say that we don't need to include, NS records. Publication rules - I mean the ability to say "give this NAPTR set to carrier A", "give this to B", and give this back to me when I ask. Probably more simply put, "here's the NAPTR set for external consumption and here's the NAPTR set I want to see in my own DNS." As far as a requirement for "expensive to operate" apparently you've not seen DNS. ;) For the requirements that would lead to (or away from) XML, I can't think of any others. We worked in XML because it was a standard and it wasn't ASN.1. (Without trying to drag in too much context from other work, I'm thinking of the IRIS vs. LDAP bake off in the CRISP WG. It took too long for the WG to finalize what seemed to be a snap of a decision.) As far as "MUST support legacy systems that use SOAP" inferring "MUST use SOAP" I think the first observation is that if a revolutionary approach is developed that requires the tossing aside of all legacy systems then this work is in vain. I think an explicit goal should be that this work builds on what's in place today. What's there now isn't the problem, the problem is what we want to interconnect them in a new way or ways. I will admit that I unabashedly would support "just going with SOAP" towards a solution because it seems to be the easiest path to a solution. If there is a better alternative, I'd be open to that, but if there is a ready and apparent one. But I don't really want to spend a long time trying to find something better just because we should. As I mentioned in the pat answer - other's experiences will be welcomed to the draft once the draft's "authorship" passes to a WG. As an individual submission it is based on our experiences. As a WG document it would reflect a broader base of opinion. Until then though, it would be foolhardy of me to try play down SOAP - that is until there is a compelling alternative. I guess I am saying take this document for consideration as a reflection of our experiences. I would be willing to accrete other lessons learned into the document. What I don't want to do is write a document that is too general or too close to basic research. If it's only the case that there might be something better than SOAP, how is that going to help a requirements document? Section 5 is decidedly not "requirements" but a reflection on our experience in making the choice. Maybe this gets dropped from a requirements document and finds it way into a document on implementation decisions - those kept and those discarded. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kj9-0003SE-Ci; Wed, 24 Jan 2007 11:11:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kj8-0003Ru-7a for peppermint@ietf.org; Wed, 24 Jan 2007 11:11:58 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kj4-00087i-Tp for peppermint@ietf.org; Wed, 24 Jan 2007 11:11:58 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 24 Jan 2007 11:11:08 -0500 id 01588192.45B7851C.00003E06 In-Reply-To: References: <15AD0157-402D-4BF1-B420-98977845BE01@hxr.us> Mime-Version: 1.0 Message-Id: <02F027E8-91B9-4FD0-92B5-56EADFF2E5AD@hxr.us> From: Andrew Newton Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Date: Wed, 24 Jan 2007 11:11:43 -0500 To: Edward Lewis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: peppermint@ietf.org X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1172585503==" Errors-To: peppermint-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1172585503== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-15880-1169655077-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-15880-1169655077-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 24, 2007, at 10:50 AM, Edward Lewis wrote: > >So, we need to be able to provision a list of 256 octet length > ASCII strings? And since, conceivably, all DNS RR types can be > used in DDDS, this is probably overkill as requirements go. Or way > to general. > Answering the question, "no." As before "be able to convey" is not > the same as "convey." The difference between MUST implement and MUST deploy is not the issue. Since your requirement is that the protocol MUST be able to convey anything "conceivable", there is a large amount of room for subjective differences of opinion. > >> 3.1.5 MUST be able to express the publication rules for any > registered > >> data. > >> > >> o For data that differs upon the querier, such as the difference > between > >> contacts and address-of-records in SIP. > > > >This needs a better explanation. > > RFC 3764. - Does that help? Well, it narrows the scope. But I still don't know what you mean by "publication rules." > >> 3.2.1 ... > >> 3.2.2 ... > >I have no problem with IRIs or dictating UTF-8 or XML. None of us > wants to spend time sifting through obscure technologies. But > wrapping this stuff in Mom & Apple Pie language just lends the > requirement to very subjective interpretations. > I don't understand the comment, the latter part that is. I doubt anybody will offer a proposal claiming to meet the requirements of "flimsy", "difficult to implement", and "expensive to operate". Language like "robust" and "scalable" are highly subjective. If your intent is to narrow the solution space, but forthcoming about it. > >> 5 EPP Protocol > >> > >Stating that SOAP MUST be the mechanism of choice is wrong on a > few levels. > > I don't think that was ever said, "MUST" that is. MUST support the "legacy" systems that use SOAP is an implication that SOAP MUST be used. This is my basis of objection. I'm not advocating against SOAP, but if the requirement is that we have to use it because certain people don't want to change any of their code, that is the equivalent of a rubber stamp. -andy --=_zeke.ecotroph.net-15880-1169655077-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Jan 24, 2007, at 10:= 50 AM, Edward Lewis wrote:

<= BLOCKQUOTE type=3D"cite">
>So, we need to be = able to provision a list of 256 octet length ASCII strings?=A0 And since,= conceivably, all DNS RR types can be used in DDDS, this is probably over= kill as requirements go.=A0 Or way to general.
Answering th= e question, "no." As before "be able to convey" is not the same as "conve= y."

<= /DIV>
The difference between MUST implement and MUST deploy is not th= e issue.=A0 Since your requirement is that the protocol MUST be able to c= onvey anything "conceivable", there is a large amount of room for subject= ive differences of opinion.

>> 3.1.5 MUST be able to express the pub= lication rules for any registered
>> data.
>>
>&g= t; o For data that differs upon the querier, such as the difference betwe= en
>> contacts and address-of-records in SIP.
>
= >This needs a better explanation.

=A0RFC 3764= . - Does that help?

Well, it narrows the scope.=A0 But I still don'= t know what you mean by "publication rules."

>> 3.2.1 ...
= >> 3.2.2 ...
>I have no problem with IRIs or dictating= UTF-8 or XML.=A0 None of us wants to spend time sifting through obscure = technologies.=A0 But wrapping this stuff in Mom & Apple Pie language = just lends the requirement to very subjective interpretations.
<= DIV>I don't understand the comment, the latter part that is.
=

I doub= t anybody will offer a proposal claiming to meet the requirements of "fli= msy", "difficult to implement", and "expensive to operate".=A0 Language l= ike "robust" and "scalable" are highly subjective.=A0 If your intent is t= o narrow the solution space, but forthcoming about it.

>> 5 EPP Prot= ocol
>>
>Stating that SOAP MUST be the mecha= nism of choice is wrong on a few levels.

I don't= think that was ever said, "MUST" that is.
=
MUST support the "legacy= " systems that use SOAP is an implication that SOAP MUST be used.=A0 This= is my basis of objection.=A0 I'm not advocating against SOAP, but if the= requirement is that we have to use it because certain people don't want = to change any of their code, that is the equivalent of a rubber stamp.
-andy
--=_zeke.ecotroph.net-15880-1169655077-0001-2-- --===============1172585503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint --===============1172585503==-- Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kOR-0006J1-1x; Wed, 24 Jan 2007 10:50:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kOP-0006Ip-QS for peppermint@ietf.org; Wed, 24 Jan 2007 10:50:33 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kON-0003Ps-Ke for peppermint@ietf.org; Wed, 24 Jan 2007 10:50:33 -0500 Received: from [10.31.32.33] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id l0OFfBHM057975; Wed, 24 Jan 2007 10:41:12 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <15AD0157-402D-4BF1-B420-98977845BE01@hxr.us> References: <15AD0157-402D-4BF1-B420-98977845BE01@hxr.us> Date: Wed, 24 Jan 2007 10:50:28 -0500 To: Andrew Newton From: Edward Lewis Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: peppermint@ietf.org X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0618230690==" Errors-To: peppermint-bounces@ietf.org --===============0618230690== Content-Type: multipart/alternative; boundary="============_-1042468664==_ma============" --============_-1042468664==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 21:17 -0500 1/23/07, Andrew Newton wrote: >Other comments in-line: >> 3.1.1 ... >Even if we are strictly talking about ENUM, I question the need for >this. I would think the decisions for things like weight and >priority on NAPTR records should not be left up to every entity >provisioning into the registry. The important phrase is "be able to." This does not mean "MUST convey" the values. >> 3.1.2 ... >So, we need to be able to provision a list of 256 octet length ASCII >strings? And since, conceivably, all DNS RR types can be used in >DDDS, this is probably overkill as requirements go. Or way to >general. Answering the question, "no." As before "be able to convey" is not the same as "convey." >> 3.1.5 MUST be able to express the publication rules for any registered >> data. >> >> o For data that differs upon the querier, such as the difference between >> contacts and address-of-records in SIP. > >This needs a better explanation. RFC 3764. - Does that help? >> 3.1.6 ... > >Does this mean that each transaction must have unique identifier? Yeah, well that is what was in mind. But if there is another way it should/could be considered >> 3.1.7 SHOULD follow any applicable standards. >> >> o Public standards are hardier than internally developed solutions. > >Ummm.... Yeah, I know this sounds too basic to be written. But this came up once in a call. One group I talked to questioned the logic of including all the NAPTR information when all that was needed was an TN to URI mapping. Once I mentioned "we want to follow standards" they quickly came to agree. >> 3.2.1 ... >> 3.2.2 ... >I have no problem with IRIs or dictating UTF-8 or XML. None of us >wants to spend time sifting through obscure technologies. But >wrapping this stuff in Mom & Apple Pie language just lends the >requirement to very subjective interpretations. I don't understand the comment, the latter part that is. >If the intent is to replicate DNS AXFR or IXFR functionality, why >not just use DNS? Not replicate, support and probably be optimized for. The assumption for ENUM is that it be via DNS, but why limit options. >> 5 EPP Protocol >> >Stating that SOAP MUST be the mechanism of choice is wrong on a few levels. I don't think that was ever said, "MUST" that is. >First, I've run into far more XML-over-FTP or CSV-over-FTP >provisioning systems than I have SOAP. So, there are plenty of >"legacy" systems that aren't SOAP based. I suppose then that I ought to add a requirement for an interactive (as opposed to batch-oriented file transfers.) >Second, SOAP was not the first protocol with implementations that >did stub-method code generation. It isn't magic, and saying "just >use SOAP" does not mean provisioning systems will write themselves. > >There is always business logic and database interaction that must be >managed. In my experience, getting the XML on and off the wire is a >very small part the software that must be written. > >Also, as has been mentioned, there is some adoption of EPP. Here's my pat answer and then I'll explain: "If a WG is formed and this document is accepted as WG document, I would be happy (if appointed editor) to include the experiences and trade-off analysis of others." What I mean is that these requirements are based on our experience (that being me and developers here) in working with EPP and SOAP. (We do have some FTP based systems too, but they weren't part of the process.) I hope that the requirements per se do not say "MUST be SOAP" but from our practical experience, SOAP appears to us to be the way to go. 'Course, that's not a requirement but a statement on the solution. For the record, when we tested a SOAP based solution to this with other organizations, no one objected or expressed any concern about the choice. This doesn't mean that SOAP is necessarily the best solution, but based on our experience it seems to be the best choice. The requirements are not meant to be stacked towards any solution. But if they are, I will plead it is an accident of history. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch. --============_-1042468664==_ma============ Content-Type: text/html; charset="us-ascii" Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-r
At 21:17 -0500 1/23/07, Andrew Newton wrote:

>Other comments in-line:
>> 3.1.1 ...

>Even if we are strictly talking about ENUM, I question the need for this.  I would think the decisions for things like weight and priority on NAPTR records should not be left up to every entity provisioning into the registry.
The important phrase is "be able to."  This does not mean "MUST convey" the values.

>> 3.1.2 ...

>So, we need to be able to provision a list of 256 octet length ASCII strings?  And since, conceivably, all DNS RR types can be used in DDDS, this is probably overkill as requirements go.  Or way to general.
Answering the question, "no." As before "be able to convey" is not the same as "convey."

>> 3.1.5 MUST be able to express the publication rules for any registered
>> data.
>>
>> o For data that differs upon the querier, such as the difference between
>> contacts and address-of-records in SIP.
>
>This needs a better explanation.

 RFC 3764. - Does that help?

>> 3.1.6 ...
>
>Does this mean that each transaction must have unique identifier?

Yeah, well that is what was in mind.  But if there is another way it should/could be considered

>> 3.1.7 SHOULD follow any applicable standards.
>>
>> o Public standards are hardier than internally developed solutions.
>
>Ummm....

Yeah, I know this sounds too basic to be written.  But this came up once in a call.  One group I talked to questioned the logic of including all the NAPTR information when all that was needed was an TN to URI mapping.  Once I mentioned "we want to follow standards" they quickly came to agree.

>> 3.2.1 ...
>> 3.2.2 ...
>I have no problem with IRIs or dictating UTF-8 or XML.  None of us wants to spend time sifting through obscure technologies.  But wrapping this stuff in Mom & Apple Pie language just lends the requirement to very subjective interpretations.
I don't understand the comment, the latter part that is.

>If the intent is to replicate DNS AXFR or IXFR functionality, why not just use DNS?

Not replicate, support and probably be optimized for.  The assumption for ENUM is that it be via DNS, but why limit options.

>> 5 EPP Protocol
>>
>Stating that SOAP MUST be the mechanism of choice is wrong on a few levels.

I don't think that was ever said, "MUST" that is.

>First, I've run into far more XML-over-FTP or CSV-over-FTP provisioning systems than I have SOAP.  So, there are plenty of "legacy" systems that aren't SOAP based.

I suppose then that I ought to add a requirement for an interactive (as opposed to batch-oriented file transfers.)

>Second, SOAP was not the first protocol with implementations that did stub-method code generation.  It isn't magic, and saying "just use SOAP" does not mean provisioning systems will write themselves.  
>
>There is always business logic and database interaction that must be managed.  In my experience, getting the XML on and off the wire is a very small part the software that must be written.
>
>Also, as has been mentioned, there is some adoption of EPP.

Here's my pat answer and then I'll explain:

"If a WG is formed and this document is accepted as WG document, I would be happy (if appointed editor) to include the experiences and trade-off analysis of others."

What I mean is that these requirements are based on our experience (that being me and developers here) in working with EPP and SOAP.  (We do have some FTP based systems too, but they weren't part of the process.)  I hope that the requirements per se do not say "MUST be SOAP" but from our practical experience,  SOAP appears to us to be the way to go.  'Course, that's not a requirement but a statement on the solution.

For the record, when we tested a SOAP based solution to this with other organizations, no one objected or expressed any concern about the choice.  This doesn't mean that SOAP is necessarily the best solution, but based on our experience it seems to be the best choice.

The requirements are not meant to be stacked towards any solution.  But if they are, I will plead it is an accident of history.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.
--============_-1042468664==_ma============-- --===============0618230690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint --===============0618230690==-- Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9hMV-0004p9-UZ; Wed, 24 Jan 2007 07:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9hMU-0004nd-WE for peppermint@ietf.org; Wed, 24 Jan 2007 07:36:23 -0500 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9hMU-0000rY-Jw for peppermint@ietf.org; Wed, 24 Jan 2007 07:36:22 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id l0OD66jm027417; Wed, 24 Jan 2007 08:06:06 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:36:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Date: Wed, 24 Jan 2007 07:37:08 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF0701A7B35B@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <15AD0157-402D-4BF1-B420-98977845BE01@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 Thread-Index: Acc/XdSCig7/9gdXTZqb1x1I2jAZ4wAU4Crg From: "Hollenbeck, Scott" To: "Andrew Newton" , X-OriginalArrivalTime: 24 Jan 2007 12:36:21.0826 (UTC) FILETIME=[40DD5A20:01C73FB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Tuesday, January 23, 2007 9:17 PM > To: peppermint@ietf.org > Subject: [PEPPERMINT] comments on=20 > draft-lewis-peppermint-enum-ref-if-00 Disclaimer: I'm the author of EPP. I have a bias. [snip] > > 5 EPP Protocol > > > > Breaking from requirements, there has been some consideration to EPP > > extensions for ENUM [RFC4114], and why it has not been=20 > adopted and why > > a requirements document is now being produced to cover what would > > seemingly be addressed by that solution. > > > > There are two reasons for EPP not being adopted. One is=20 > that it isn't > > compatible with legacy participants. The other reason is that it > > requires more implementation work. > > > > Legacy participants have an existing base of software development =20 > > built > > around SOAP/XML and WSDL, and are familiar with TLS. =20 > Approaches to =20 > > ENUM > > registry interfaces that use these tools will blend more easily into > > the software products already in use to manage telephone numbers. > > > > The use of SOAP permits automatic generation of software to=20 > handle the > > client side of the exchange. Domain name registries had to provide > > software tool kits to give to registrars to match this=20 > functionality. > > When a change is made to EPP, there will be a lot of software =20 > > exchanged. > > > > From experience with both EPP and SOAP based approaches to registry > > software, the SOAP based approach is much easier on the software > > engineering process. The difference between the approaches is not =20 > > seen > > in a protocol analysis, but in an analysis of software engineering. >=20 > Stating that SOAP MUST be the mechanism of choice is wrong on a few =20 > levels. >=20 > First, I've run into far more XML-over-FTP or CSV-over-FTP =20 > provisioning systems than I have SOAP. So, there are plenty of =20 > "legacy" systems that aren't SOAP based. >=20 > Second, SOAP was not the first protocol with implementations=20 > that did =20 > stub-method code generation. It isn't magic, and saying "just use =20 > SOAP" does not mean provisioning systems will write themselves. =20 > There is always business logic and database interaction that must be =20 > managed. In my experience, getting the XML on and off the wire is a =20 > very small part the software that must be written. >=20 > Also, as has been mentioned, there is some adoption of EPP. Indeed. It's already being used in ENUM contexts. The country code 1 user ENUM trial, for example, is using EPP. I'd like to see any analysis of data wrapping protocol to include a discussion of the issues associated with tunneling data re-using HTTP and port 80. The Security Considerations section would be a good place to add text. Let's discuss the software engineering and deployment issues associated with adding HTTP and SOAP software layers, too. It's not as simple as "build on top of SOAP", folks. This isn't as simple as "EPP vs. SOAP". You could, for example, carry the EPP data structures in SOAP instead of streaming them over TCP as described in RFC 3734. Not that I'm advocating that, but it illustrates my point. If this document is intended to describe interface requirements it shouldn't focus on one protocol or the other. It should describe the *requirements* for the provisioning protocol interface. We can debate which tools best meet the requirements when we get there. We should also consider the possibility of obsoleting and replacing RFC 4114 if it's proving to be inadequate. Heck, it's only a *Proposed* standard. If implementation experience demonstrates that it's inadequate, well, that's why we have a multi-stage standards track. -Scott- _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Xha-0001fa-OL; Tue, 23 Jan 2007 21:17:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9XhZ-0001fM-LC for peppermint@ietf.org; Tue, 23 Jan 2007 21:17:29 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9XhT-00044z-Ji for peppermint@ietf.org; Tue, 23 Jan 2007 21:17:29 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 23 Jan 2007 21:16:44 -0500 id 015880C9.45B6C18C.00007273 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <15AD0157-402D-4BF1-B420-98977845BE01@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: peppermint@ietf.org From: Andrew Newton Date: Tue, 23 Jan 2007 21:17:18 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org I've reviewed this draft. Though it touches on non-ENUM points, it is very centered on ENUM. In general, I would like to see a consideration for a more general query mechanism. Yes, ENUM will be used by many entities, but redirect servers are also quite common. Other comments in-line: > 3.1.1 MUST be able to covey all of the information required for a DNS > NAPTR resource record. Even if we are strictly talking about ENUM, I question the need for this. I would think the decisions for things like weight and priority on NAPTR records should not be left up to every entity provisioning into the registry. > 3.1.2 MUST be able to convey all of the information required for a > DNS TXT > resource record or any other record type that can conceivably be > used in > DDDS. So, we need to be able to provision a list of 256 octet length ASCII strings? And since, conceivably, all DNS RR types can be used in DDDS, this is probably overkill as requirements go. Or way to general. > 3.1.5 MUST be able to express the publication rules for any registered > data. > > o For data that differs upon the querier, such as the difference > between > contacts and address-of-records in SIP. This needs a better explanation. > 3.1.6 MUST provide a means of tracking individual commands. > > o Each command has to be identifiable for later actions. The > interface is > not involved in tracking. Does this mean that each transaction must have unique identifier? > 3.1.7 SHOULD follow any applicable standards. > > o Public standards are hardier than internally developed solutions. Ummm.... > 3.2.1 MUST use an encoding method that is robust, easy to design and > troubleshoot, and is capable of supporting IRI's. > > o Easy to design and troubleshoot lends itself to mechanisms that > are text > based as opposed to binary or hexadecimal. Internationalization is > important, for now at least host names might be in non-ASCII and > sooner > or later other parts of a URI may also be. > > 3.2.2 SHOULD use a widely recognized standard. > > o Avoiding specifically developed mechanisms. I have no problem with IRIs or dictating UTF-8 or XML. None of us wants to spend time sifting through obscure technologies. But wrapping this stuff in Mom & Apple Pie language just lends the requirement to very subjective interpretations. > 4.2 SHOULD be able to populate a DNS zone transfer message, once the > SOA RR is included. > > o A DNS AXFR or IXFR consist of a zone's SOA resource record, > followed by > a list of resource records, and followed by another copy of the SOA > resource record. The SOA resource record has parameters best set > by the > resolution system, so that is left to the client-side of this > interface. > But all of the rest of the zone transfer data ought to be able to be > pulled from the formats exchanged over this interface. If the intent is to replicate DNS AXFR or IXFR functionality, why not just use DNS? > 5 EPP Protocol > > Breaking from requirements, there has been some consideration to EPP > extensions for ENUM [RFC4114], and why it has not been adopted and why > a requirements document is now being produced to cover what would > seemingly be addressed by that solution. > > There are two reasons for EPP not being adopted. One is that it isn't > compatible with legacy participants. The other reason is that it > requires more implementation work. > > Legacy participants have an existing base of software development > built > around SOAP/XML and WSDL, and are familiar with TLS. Approaches to > ENUM > registry interfaces that use these tools will blend more easily into > the software products already in use to manage telephone numbers. > > The use of SOAP permits automatic generation of software to handle the > client side of the exchange. Domain name registries had to provide > software tool kits to give to registrars to match this functionality. > When a change is made to EPP, there will be a lot of software > exchanged. > > From experience with both EPP and SOAP based approaches to registry > software, the SOAP based approach is much easier on the software > engineering process. The difference between the approaches is not > seen > in a protocol analysis, but in an analysis of software engineering. Stating that SOAP MUST be the mechanism of choice is wrong on a few levels. First, I've run into far more XML-over-FTP or CSV-over-FTP provisioning systems than I have SOAP. So, there are plenty of "legacy" systems that aren't SOAP based. Second, SOAP was not the first protocol with implementations that did stub-method code generation. It isn't magic, and saying "just use SOAP" does not mean provisioning systems will write themselves. There is always business logic and database interaction that must be managed. In my experience, getting the XML on and off the wire is a very small part the software that must be written. Also, as has been mentioned, there is some adoption of EPP. -andy _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Wm7-0004eT-9s; Tue, 23 Jan 2007 20:18:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Wm6-0004eM-6U for peppermint@ietf.org; Tue, 23 Jan 2007 20:18:06 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Wm4-0005xH-Kl for peppermint@ietf.org; Tue, 23 Jan 2007 20:18:06 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 23 Jan 2007 20:17:23 -0500 id 015880C9.45B6B3A3.000068A2 Mime-Version: 1.0 To: peppermint@ietf.org Message-Id: <64F1D562-A166-4A83-B660-2D52371BCC74@hxr.us> References: From: Andrew Newton Date: Tue, 23 Jan 2007 20:17:57 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Subject: [PEPPERMINT] Fwd: I-D ACTION:draft-lewis-peppermint-enum-reg-if-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1867838972==" Errors-To: peppermint-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1867838972== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-26788-1169601447-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-26788-1169601447-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit FYI Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: January 23, 2007 3:50:01 PM EST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-lewis-peppermint-enum-reg-if-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : ENUM Registry Interface Requirements > Author(s) : E. Lewis > Filename : draft-lewis-peppermint-enum-reg-if-00.txt > Pages : > Date : 2007-1-23 > > An ENUM registry interacts with various elements to maintain what is > essentially a telephone number to uniform (or a more modern version) > resource identifier. The interfaces needed are identified in this > requirements document, as well as the requirements for the more > generic > interfaces. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lewis-peppermint-enum-reg- > if-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-lewis-peppermint-enum-reg-if-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-lewis-peppermint-enum-reg-if-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-1-23122525.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --=_zeke.ecotroph.net-26788-1169601447-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3 FYI

Begin forwarded = message:

Date: J= anuary 23, 2007 3:50:01 PM EST
Subject: I-D ACTION:draft-lewis-peppermint-enum-r= eg-if-00.txt=A0
Reply-To: internet-drafts@ietf.org

= A New Internet-Draft is available from the on-line Internet-Drafts=A0
directori= es.


=09Title=09=09: ENUM Registry Interface Requirements
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; marg= in-left: 0px; ">= =09Author(s)=09: E. Lewis
=09Filename=09: draft-lewis-peppermint-enum-r= eg-if-00.txt
=09Pages=09=09:=A0
=09Date=09=09<= /SPAN>: 2007-1-23

=09=

An ENUM= registry interacts with various elements to maintain what is
essentially a telephone number to uniform (or a more modern ve= rsion)
resource identifier.=A0 The interfaces needed are identified in this
requirements document, as well as the requirements for= the more generic
interfaces.



A URL for = this Internet-Draft is:
http://www= .ietf.org/internet-drafts/draft-lewis-peppermint-enum-reg-if-00.txt

To remo= ve yourself from the I-D Announcement list, send a message to=A0
i-d-announce-request@ietf.org with t= he word unsubscribe in the body of=A0=
the message.=A0
to change your subscription settings.
=

Internet-Dr= afts are also available by anonymous FTP. Login with the=A0
username "anonymous= " and a password of your e-mail address. After=A0
logging in, type "cd internet= -drafts" and then=A0
"get draft-lewis-peppermint-enum-reg-if-00.txt".

A list of Inter= net-Drafts directories can be found in

<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; marg= in-left: 0px; ">Internet-Drafts can also be obtained by e-mail.

Send a message = to:
In the body type:
=09"FILE /int= ernet-drafts/draft-lewis-peppermint-enum-reg-if-00.txt".

=09

NOTE:=09The mail server at ietf.org can return t= he document in
=09MIME-encoded form by using the "mpack" uti= lity.=A0 To use this
=09= feature, insert the command "ENCODING mime" before the "FILE"
=09command.=A0 To d= ecode the response(s), you will need "munpack" or
<= SPAN class=3D"Apple-tab-span" style=3D"white-space:pre">=09a MIME-= compliant mail reader.=A0 Di= fferent MIME-compliant mail readers
=09exhibit different beh= avior, especially when dealing with
=09"multipart" MIME mess= ages (i.e. documents which have been split
=09up into multip= le messages), so check your local documentation on
= =09how to= manipulate these messages.

<= /DIV>
Below is the data which will enable a MIME complian= t mail reader
implementation to automatically retri= eve the ASCII version of the
Internet-Draft.
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; marg= in-left: 0px; ">Content-Type: text/plain

_______________________________________________
I-D-Announce mailing list
<= BR> --=_zeke.ecotroph.net-26788-1169601447-0001-2-- --===============1867838972== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint --===============1867838972==-- Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8yts-0007Oj-9Q; Mon, 22 Jan 2007 08:07:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ytr-0007OS-Nt; Mon, 22 Jan 2007 08:07:51 -0500 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8ytq-0005Xq-3T; Mon, 22 Jan 2007 08:07:51 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jan 2007 15:07:44 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550201EDB7@isr-jlm-mail.Kayote.com> In-Reply-To: <20070110181221.GA17060@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt Thread-index: Acc04uCQqpBPY4WuQTKd3jEz+XQkngAEoFcA From: "David Schwartz" To: "Otmar Lendl" X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: speermint@ietf.org, peppermint@ietf.org Subject: [PEPPERMINT] RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org Hi Otmar I think the problem is that of an unclear definition. The current definition of length is "This field is used for expanding ranges to individual unique numbers". The wording I would add is as follows... "This value is an exact match and is used for expanding ranges to complete number sets. In areas of the world where non NANP type numbering plans exist there may be a need for multiple "exact" length records to account for all possibilities:". With that said I am not completely averse to exchanging "exact" length with two alternate fields: minLength and maxLength. All I was trying to say was that anything you can do with those two can be done with 1 exact length field as well. David -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Wednesday, January 10, 2007 8:12 PM To: David Schwartz Cc: Andrew Newton; Richard Shockey; speermint@ietf.org; peppermint@ietf.org Subject: Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt On 2007/01/09 16:01, David Schwartz wrote: > Hi Otmar. David, > In general, the assumption I made in the draft was that ranges cover a > factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6 > than the numbers provisioned are 123450, 123451, ... 123459.=20 Sound fine as long as you can assume you know the length of the number. > The problem > you raise regarding the numbering plans in Germany is not new to me and > brings up the question that often arises in database architecture, > namely that of width (or length) of a record Vs the depth or table size. > Specifically, how complicated do we want to make each provisioning > record at the expense of not writing another record.=20 Oh, I'm not even there yet. What bothers me is the implicit assumption that we're dealing with sets of numbers, and not sets of prefixes.=20 In other words, I'd prefer to first get consensus on what a typical database scheme of such a registry might look like. Once we have that, we can start to talk about how to provision records into that database. As you mention, a single provisioning record might get expanded into multiple records in the database. On the other hand, any rule we want to store in the DB must also be possible to provision in some way. > While at one extreme is the prospect of provisioning each number > individually and not using ranges, it is possible using the mechanism I > proposed to combine individual numbers with ranges and take advantage of > "DeactivationDate" field that allows me to port individual values as > well as sub-ranges out of larger 10X ranges and arrive at the resolution > we desire. I think I understand your scheme and I think it is very reasonable for sets of fixed-length numbers. It's just that I don't think that "sets of fixed-length numbers" is all we're going to need. E.g. yes, you can use that scheme to announce a route to the full NANP area with Activate... 1,true,11 // equivalent to adding 1XXXXXXXXXX but how do you do a route to Austria? This way? 43,true,15 // equivalent to adding 43XXXXXXXXXXXXXX Is this record supposed to match 436624669 which is not 15 digits long? Or do I also need to provision the following: 43,true,9 Or, to take the example from my last mail: What should Telekom Austria provision into your system to announce that they serve +43 1 50564616 plus all set of possible extensions behind that number? /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8yPF-0002FX-T1; Mon, 22 Jan 2007 07:36:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8yPE-0002FF-LC; Mon, 22 Jan 2007 07:36:12 -0500 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8yPC-0000oE-5y; Mon, 22 Jan 2007 07:36:12 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jan 2007 14:35:50 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550201EDA0@isr-jlm-mail.Kayote.com> In-Reply-To: <000001c733fa$60be6700$673918ac@gvnw.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt Thread-index: Accz+pveykrG1nZJRYe3gH2cUoZMdwA+umWw From: "David Schwartz" To: "T. Martin" , "Andrew Newton" , "Richard Shockey" X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: speermint@ietf.org, peppermint@ietf.org Subject: [PEPPERMINT] RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org Hi Terry > I would suggest you qualify the definition of an E.164 number as defined=20 > by ITU E.123. And indicate what will be included in the field number > Were to get the correct notation information: > http://www.itu.int/rec/T-REC-E.123-200102-I/E > The definition should include: > Each assigned number contains a country code (CC), a national destination > code (NDC), and a subscriber number (SN). There can be up to 15 digits in=20 > an E.164 number. The E.164 plan was originally developed by the=20 > International Telecommunication Union (ITU). Agreed. > I have another question:=20 > Where do you get the time and date information? So the only field where this is really an issue is "CreationDatetime". If no value is entered the provisioning server enters the current time, otherwise the provisioning client needs to enter the value for this. Specifically, one thing this draft did not address was the data set for the provisioning response (which will hopefully be included in the next version). One of the fields that must be returned is the creation date time field. When provisioning a number for the first time, the provisioning client leaves the "CreationDatetime" field empty and the server enters the current time. This time is returned to the client and upon any subsequent modification of this record this date time should be used. David _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ISD-0005BA-GX; Wed, 17 Jan 2007 16:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ISC-0005B5-62 for peppermint@ietf.org; Wed, 17 Jan 2007 16:36:20 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ISA-0001Xq-W8 for peppermint@ietf.org; Wed, 17 Jan 2007 16:36:20 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 17 Jan 2007 16:35:43 -0500 id 01588460.45AE96AF.00001B5D Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1D1631BF-AE9F-4BA5-B708-D255DD8D23B4@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: peppermint@ietf.org From: Andrew Newton Date: Wed, 17 Jan 2007 16:36:17 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [PEPPERMINT] test X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org pls ignore _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6s4c-0003I8-N8; Tue, 16 Jan 2007 12:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6s4c-0003I3-Dl for peppermint@ietf.org; Tue, 16 Jan 2007 12:26:14 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6s4b-0003Ep-2V for peppermint@ietf.org; Tue, 16 Jan 2007 12:26:14 -0500 Received: from [10.1.1.226] (dhcp226.dhcp.erkkila.org [::ffff:10.1.1.226]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Tue, 16 Jan 2007 17:26:10 +0000 id 002101F4.45AD0AB2.00006B90 Message-ID: <45AD0B0A.2020002@erkkila.org> Date: Tue, 16 Jan 2007 17:27:38 +0000 From: Paul Erkkila User-Agent: Thunderbird 2.0b1 (X11/20061206) MIME-Version: 1.0 To: Otmar Lendl , David Schwartz , Andrew Newton , Richard Shockey , peppermint@ietf.org References: <20070109112236.GA9374@nic.at> <1DDB0D3CC4E7F14FAE946361C0A6065501E50FD7@isr-jlm-mail.Kayote.com> <20070110181221.GA17060@nic.at> In-Reply-To: <20070110181221.GA17060@nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [PEPPERMINT] Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org My thoughts on this discussion. - Adapting this data to fit the "common" database case *may* be very difficult . I think separating communication of the data and using it should be left separate. - The "extreme" case as David named it where a fully expanded route list is transmitted is actually the easiest to adopt case. It can be converted to pretty much any format. (This is covered by the Range flag in the draft). - Any format compression such as the range flag and length field as proposed really needs to cover the entire namespace. As much as I love the NANP ignoring the requirements of variable plan implementors like Austria (no kangaroos) seems like a bad idea. Would it be horribly evil to allow regular expression like syntax in the value field? Expansions would be bounded by E164, and the rules allowed can be modified to reduce complexity errors that David is concerned about, purely for example: - Matches and expansions on numbers only (E164) - Expansion just inside the E164 space (E164: no 17 digit numbers) - Can make all values here inclusive (positive) and not allow negation operations. (complexity) - All expansion is done on the right side (complexity) The answer to Telecom Austria announcing "+43 1 50564616" could then be 4315056461[6][0-9]* (pick a favorite syntax). A value with no syntax sugar would just be the standard value. This seems to cover the number/prefix issue, as well as the length variation issue (inside of e164). -pee Otmar Lendl wrote: > On 2007/01/09 16:01, David Schwartz wrote: >> Hi Otmar. > > David, > >> In general, the assumption I made in the draft was that ranges cover a >> factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6 >> than the numbers provisioned are 123450, 123451, ... 123459. > > Sound fine as long as you can assume you know the length of the number. > >> The problem >> you raise regarding the numbering plans in Germany is not new to me and >> brings up the question that often arises in database architecture, >> namely that of width (or length) of a record Vs the depth or table size. >> Specifically, how complicated do we want to make each provisioning >> record at the expense of not writing another record. > > Oh, I'm not even there yet. What bothers me is the implicit assumption that > we're dealing with sets of numbers, and not sets of prefixes. > > In other words, I'd prefer to first get consensus on what a typical > database scheme of such a registry might look like. > > Once we have that, we can start to talk about how to provision records > into that database. As you mention, a single provisioning record > might get expanded into multiple records in the database. On the > other hand, any rule we want to store in the DB must also be possible > to provision in some way. > >> While at one extreme is the prospect of provisioning each number >> individually and not using ranges, it is possible using the mechanism I >> proposed to combine individual numbers with ranges and take advantage of >> "DeactivationDate" field that allows me to port individual values as >> well as sub-ranges out of larger 10X ranges and arrive at the resolution >> we desire. > > I think I understand your scheme and I think it is very reasonable > for sets of fixed-length numbers. > > It's just that I don't think that "sets of fixed-length numbers" is > all we're going to need. > > E.g. yes, you can use that scheme to announce a route to the > full NANP area with > > Activate... > 1,true,11 // equivalent to adding 1XXXXXXXXXX > > but how do you do a route to Austria? This way? > > 43,true,15 // equivalent to adding 43XXXXXXXXXXXXXX > > Is this record supposed to match 436624669 which is not 15 digits long? > Or do I also need to provision the following: > > 43,true,9 > > Or, to take the example from my last mail: What should Telekom Austria > provision into your system to announce that they serve +43 1 50564616 > plus all set of possible extensions behind that number? > > /ol _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hwL-00064Y-70; Wed, 10 Jan 2007 13:12:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hwK-00064Q-P7; Wed, 10 Jan 2007 13:12:44 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hwG-0003Nu-Aw; Wed, 10 Jan 2007 13:12:44 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 220934C3F1; Wed, 10 Jan 2007 19:12:22 +0100 (CET) Date: Wed, 10 Jan 2007 19:12:22 +0100 From: Otmar Lendl To: David Schwartz Message-ID: <20070110181221.GA17060@nic.at> Mail-Followup-To: Otmar Lendl , David Schwartz , Andrew Newton , Richard Shockey , speermint@ietf.org, peppermint@ietf.org References: <20070109112236.GA9374@nic.at> <1DDB0D3CC4E7F14FAE946361C0A6065501E50FD7@isr-jlm-mail.Kayote.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A6065501E50FD7@isr-jlm-mail.Kayote.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: speermint@ietf.org, peppermint@ietf.org Subject: [PEPPERMINT] Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org On 2007/01/09 16:01, David Schwartz wrote: > Hi Otmar. David, > In general, the assumption I made in the draft was that ranges cover a > factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6 > than the numbers provisioned are 123450, 123451, ... 123459. Sound fine as long as you can assume you know the length of the number. > The problem > you raise regarding the numbering plans in Germany is not new to me and > brings up the question that often arises in database architecture, > namely that of width (or length) of a record Vs the depth or table size. > Specifically, how complicated do we want to make each provisioning > record at the expense of not writing another record. Oh, I'm not even there yet. What bothers me is the implicit assumption that we're dealing with sets of numbers, and not sets of prefixes. In other words, I'd prefer to first get consensus on what a typical database scheme of such a registry might look like. Once we have that, we can start to talk about how to provision records into that database. As you mention, a single provisioning record might get expanded into multiple records in the database. On the other hand, any rule we want to store in the DB must also be possible to provision in some way. > While at one extreme is the prospect of provisioning each number > individually and not using ranges, it is possible using the mechanism I > proposed to combine individual numbers with ranges and take advantage of > "DeactivationDate" field that allows me to port individual values as > well as sub-ranges out of larger 10X ranges and arrive at the resolution > we desire. I think I understand your scheme and I think it is very reasonable for sets of fixed-length numbers. It's just that I don't think that "sets of fixed-length numbers" is all we're going to need. E.g. yes, you can use that scheme to announce a route to the full NANP area with Activate... 1,true,11 // equivalent to adding 1XXXXXXXXXX but how do you do a route to Austria? This way? 43,true,15 // equivalent to adding 43XXXXXXXXXXXXXX Is this record supposed to match 436624669 which is not 15 digits long? Or do I also need to provision the following: 43,true,9 Or, to take the example from my last mail: What should Telekom Austria provision into your system to announce that they serve +43 1 50564616 plus all set of possible extensions behind that number? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4OKT-0008Ir-9V; Tue, 09 Jan 2007 16:16:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4OKR-0008IR-C4 for peppermint@ietf.org; Tue, 09 Jan 2007 16:16:19 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4OKP-0007pg-VB for peppermint@ietf.org; Tue, 09 Jan 2007 16:16:19 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l09LGAJQ027195 for ; Tue, 9 Jan 2007 13:16:18 -0800 From: "Richard Shockey" To: Date: Tue, 9 Jan 2007 16:16:26 -0500 Message-ID: <011401c73433$6fddc5d0$f3201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0115_01C73409.870C51B0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc0L9l4hv06ul4oR6GCvPDFbEIoYgAA4W8A X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [PEPPERMINT] FW: I-D ACTION:draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0115_01C73409.870C51B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, January 09, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-schwartz-peppermint-e164-provisioning-data-set- > 00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : E.164 Number Provisioning - Data Set Requirements > Author(s) : D. Schwartz, E. Katz > Filename : draft-schwartz-peppermint-e164-provisioning-data-set- > 00.txt > Pages : > Date : 2007-1-9 > > This document outlines which information should be captured when > E.164 numbers are provisioned within a central registry. This > document is not a specification but rather a set of information > which, when associated with an addressable entity can assist in > applying policy to subsequent queries. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-schwartz-peppermint-e164- > provisioning-data-set-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-schwartz-peppermint-e164-provisioning-data-set-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schwartz-peppermint-e164-provisioning- > data-set-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_0115_01C73409.870C51B0 Content-Type: Message/External-body; name="draft-schwartz-peppermint-e164-provisioning-data-set-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-schwartz-peppermint-e164-provisioning-data-set-00.txt" Content-Type: text/plain Content-ID: <2007-1-9143637.I-D@ietf.org> ------=_NextPart_000_0115_01C73409.870C51B0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint ------=_NextPart_000_0115_01C73409.870C51B0-- Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ibj-0001dn-3m; Tue, 09 Jan 2007 10:09:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ibh-0001dL-FB; Tue, 09 Jan 2007 10:09:45 -0500 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Ibf-0001TZ-QX; Tue, 09 Jan 2007 10:09:45 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jan 2007 17:09:41 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A6065501E50FD7@isr-jlm-mail.Kayote.com> In-Reply-To: <20070109112236.GA9374@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt Thread-index: Accz4H0M3DyBhfbvRS+S+yemdm/2HAAFPWyA From: "David Schwartz" To: "Otmar Lendl" X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: speermint@ietf.org, peppermint@ietf.org Subject: [PEPPERMINT] RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org Hi Otmar. In general, the assumption I made in the draft was that ranges cover a factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6 than the numbers provisioned are 123450, 123451, ... 123459. The problem you raise regarding the numbering plans in Germany is not new to me and brings up the question that often arises in database architecture, namely that of width (or length) of a record Vs the depth or table size. Specifically, how complicated do we want to make each provisioning record at the expense of not writing another record.=20 I contend and I may be wrong that while it is possible to add minLength, maxLength, numberOfValuesInRange, etc, to cover ALL possible scenarios, this obfuscates and complicates the processing of each record to the point where it is more prone to errors.=20 If on the other hand we simplify the record at the expense of adding more records, while the upload time is perhaps increased (negligible) the complexity is reduced and the errors that creep in to the system are reduced as well. While at one extreme is the prospect of provisioning each number individually and not using ranges, it is possible using the mechanism I proposed to combine individual numbers with ranges and take advantage of "DeactivationDate" field that allows me to port individual values as well as sub-ranges out of larger 10X ranges and arrive at the resolution we desire. If we take Germany as an example, suppose the number range I want to provision is the 257 numbers starting with +4936628411 and going to +493662841257. The way I would accomplish this with the mechanism proposed in the draft using the "pattern|range|length" tuple is as follows. Activate... 493662841,true,12 // equivalent to adding 493662841XXX Deactivate... 4936628413,true,12 // equivalent to removing 4936628413XX 4936628414,true,12 // equivalent to removing 4936628414XX 4936628415,true,12 // equivalent to removing 4936628415XX 4936628416,true,12 // equivalent to removing 4936628416XX 4936628417,true,12 // equivalent to removing 4936628417XX 4936628418,true,12 // equivalent to removing 4936628418XX 4936628419,true,12 // equivalent to removing 4936628419XX 4936628410,true,12 // equivalent to removing 4936628410XX 49366284126,true,12 // equivalent to removing 49366284126X 49366284127,true,12 // equivalent to removing 49366284127X 49366284128,true,12 // equivalent to removing 49366284128X 49366284129,true,12 // equivalent to removing 49366284129X 493662841258,false,12 // equivalent to removing 493662841258 493662841259,false,12 // equivalent to removing 493662841259 While I may have left out a record or two you get the point. 15 records and you have clearly defined the range. While I could come up with a scheme to do this in one record I felt that in light of the amount of provisioning errors that we have seen in the field (with an even simpler data set) I prefer to make porting in and out of ranges explicit and thus reduce the chance of error. Cheers, D. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, January 09, 2007 1:23 PM To: David Schwartz Cc: Andrew Newton; Richard Shockey; speermint@ietf.org; peppermint@ietf.org Subject: Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt On 2007/01/08 23:01, David Schwartz wrote: >=20 > I just submitted a 00 draft on provisioning data sets. Thanks for the input, here is the first question: >=20 > o Static Information >=20 > The data in this category relates to the identification, ownership > and general validity of the number. >=20 > 1. Value >=20 > The value is the resource that is being sought. This value > may be a fully qualified E.164 number (e.g. 12127775555), or > alternatively, the value may be a number representing a range > of numbers (e.g. 1212777). In this latter case the "length" > field defined below is needed to establish the limits of the > number range. >=20 > 2. Range >=20 > This and the next field are used to assist in resolving ranges > into individual and unique valid E.164 numbers. The Range > field is a Boolean value, which indicates whether the resource > specified in the "Value" field is a range that needs to be > expanded out to the "length" number of digits, or > alternatively, an individual number that does not require > further manipulation. >=20 > 3. Length >=20 > This field is used for expanding ranges to individual unique > numbers. I can see how this works for blocks of numbers in countries with=20 closed numbering plans. How this is supposed to work in Germany or Austria, I don't know. The problem is that "expanding ranges to individual unique numbers" is a fool's errand in the context of open numbering plans. There are no "ranges" assigned to corporate PBXs, they get prefixes (=3Dpilot = numbers, "Kopfnummern") to which the PBX admin appends extensions according to their own taste. e.g.: the enum.at office in Vienna has +4315056416 (=3D 10 digits). = We're completely free to use the remaining 5 digits of the E.164 standard as we wish. We don't even need to use a fixed length, we could use -0, -1X, -2XX, -3XXX, -4XXXX, or any other scheme. Thus:=20 * "Length" needs to be a range. * Expanding such a "block" into individual numbers turns a simple ISDN BRI customer into more than 100,000 DB entries. -- In a more generic sense, you want to handle prefix-based in any case, e.g. how else are you going to communicate that you offer termination to London numbers, other than by saying route to +4420XXXXXXXX ?=20 In that case, too, you don't want to translate that single route into 10^8 =3D 100 million individual routes. Summary: Do we want to provision individual numbers, or are we aiming at generalized prefix-based routes (with numbers as special cases)? /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IFE-0000Cb-Ep; Tue, 09 Jan 2007 09:46:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4HzC-00025B-5e; Tue, 09 Jan 2007 09:29:58 -0500 Received: from cmsout01.mbox.net ([165.212.64.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Hz0-0006I8-6V; Tue, 09 Jan 2007 09:29:58 -0500 Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by cmsout01.mbox.net (Postfix) with ESMTP id 45F5478319; Tue, 9 Jan 2007 14:29:38 +0000 (GMT) Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.31J) with ESMTP id 269LaiodI0076M01; Tue, 09 Jan 2007 14:29:35 GMT Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.31J) with ESMTP id 268LaiodG0084M01; Tue, 09 Jan 2007 14:29:32 GMT X-USANET-Routed: 10 gwsout-cmsarchive C:mx.usa.net:25 gvnw.com@archiving.usa.net X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from cmsapps02.cms.usa.net [165.212.11.138] by cmsout01.mbox.net via smtad (C8.MAIN.3.32M); Tue, 09 Jan 2007 14:29:32 GMT X-USANET-Source: 165.212.11.138 IN tmartin@gvnw.com cmsapps02.cms.usa.net X-USANET-MsgId: XID516LaiodG9486X01 Received: from tmartin2 [65.90.128.46] by cmsapps02.cms.usa.net (ASMTP/tmartin@gvnw.com) via mtad (C8.MAIN.3.31J) with ESMTP id 932LaiodC0143M38; Tue, 09 Jan 2007 14:29:29 GMT From: "T. Martin" To: "'David Schwartz'" , "'Andrew Newton'" , "'Richard Shockey'" Date: Tue, 9 Jan 2007 06:28:01 -0800 Message-ID: <000001c733fa$60be6700$673918ac@gvnw.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A6065501E50E14@isr-jlm-mail.Kayote.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Z-USANET-MsgId: XID932LaiodE0143X38 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-Mailman-Approved-At: Tue, 09 Jan 2007 09:46:31 -0500 Cc: speermint@ietf.org, peppermint@ietf.org Subject: [PEPPERMINT] RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org Dave I would suggest you qualify the definition of an E.164 number as defined = by ITU E.123. And indicate what will be included in the field number Were to get the correct notation information: http://www.itu.int/rec/T-REC-E.123-200102-I/E The definition should include: Each assigned number contains a country code (CC), a national = destination code (NDC), and a subscriber number (SN). There can be up to 15 digits = in an E.164 number. The E.164 plan was originally developed by the = International Telecommunication Union (ITU). I have another question:=20 Where do you get the time and date information? Terry Martin=20 GVNW Consulting Inc Senior Consultant phone:503.612.4400 fax 503.612.4401 cell 503.318.8909 -----Original Message----- From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 Sent: Monday, January 08, 2007 2:27 PM To: Andrew Newton; Richard Shockey Cc: speermint@ietf.org; peppermint@ietf.org Subject: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt Hi I just submitted a 00 draft on provisioning data sets. Until it shows up on the ID tracker you can use this version. Cheers, David=20 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4F47-00068r-Gb; Tue, 09 Jan 2007 06:22:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4F46-00068j-Pi; Tue, 09 Jan 2007 06:22:50 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4F44-00053c-BF; Tue, 09 Jan 2007 06:22:50 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 2EB504C3E0; Tue, 9 Jan 2007 12:22:37 +0100 (CET) Date: Tue, 9 Jan 2007 12:22:37 +0100 From: Otmar Lendl To: David Schwartz Message-ID: <20070109112236.GA9374@nic.at> Mail-Followup-To: Otmar Lendl , David Schwartz , Andrew Newton , Richard Shockey , speermint@ietf.org, peppermint@ietf.org References: <1DDB0D3CC4E7F14FAE946361C0A6065501E50E14@isr-jlm-mail.Kayote.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A6065501E50E14@isr-jlm-mail.Kayote.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: speermint@ietf.org, peppermint@ietf.org Subject: [PEPPERMINT] Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org On 2007/01/08 23:01, David Schwartz wrote: > > I just submitted a 00 draft on provisioning data sets. Thanks for the input, here is the first question: > > o Static Information > > The data in this category relates to the identification, ownership > and general validity of the number. > > 1. Value > > The value is the resource that is being sought. This value > may be a fully qualified E.164 number (e.g. 12127775555), or > alternatively, the value may be a number representing a range > of numbers (e.g. 1212777). In this latter case the "length" > field defined below is needed to establish the limits of the > number range. > > 2. Range > > This and the next field are used to assist in resolving ranges > into individual and unique valid E.164 numbers. The Range > field is a Boolean value, which indicates whether the resource > specified in the "Value" field is a range that needs to be > expanded out to the "length" number of digits, or > alternatively, an individual number that does not require > further manipulation. > > 3. Length > > This field is used for expanding ranges to individual unique > numbers. I can see how this works for blocks of numbers in countries with closed numbering plans. How this is supposed to work in Germany or Austria, I don't know. The problem is that "expanding ranges to individual unique numbers" is a fool's errand in the context of open numbering plans. There are no "ranges" assigned to corporate PBXs, they get prefixes (=pilot numbers, "Kopfnummern") to which the PBX admin appends extensions according to their own taste. e.g.: the enum.at office in Vienna has +4315056416 (= 10 digits). We're completely free to use the remaining 5 digits of the E.164 standard as we wish. We don't even need to use a fixed length, we could use -0, -1X, -2XX, -3XXX, -4XXXX, or any other scheme. Thus: * "Length" needs to be a range. * Expanding such a "block" into individual numbers turns a simple ISDN BRI customer into more than 100,000 DB entries. -- In a more generic sense, you want to handle prefix-based in any case, e.g. how else are you going to communicate that you offer termination to London numbers, other than by saying route to +4420XXXXXXXX ? In that case, too, you don't want to translate that single route into 10^8 = 100 million individual routes. Summary: Do we want to provision individual numbers, or are we aiming at generalized prefix-based routes (with numbers as special cases)? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H43R0-0001Lr-UC; Mon, 08 Jan 2007 17:57:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42xs-0002cS-8F; Mon, 08 Jan 2007 17:27:36 -0500 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H42xr-00055v-3V; Mon, 08 Jan 2007 17:27:36 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C73374.318D16EB" Date: Tue, 9 Jan 2007 00:27:25 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A6065501E50E14@isr-jlm-mail.Kayote.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-schwartz-peppermint-e164-provisioning-data-set-00.txt Thread-index: Accw64syBzzSkqrtSb6S0TiBsiVqmgAAOILAAKHcQoA= From: "David Schwartz" To: "Andrew Newton" , "Richard Shockey" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 X-Mailman-Approved-At: Mon, 08 Jan 2007 17:57:41 -0500 Cc: speermint@ietf.org, peppermint@ietf.org Subject: [PEPPERMINT] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C73374.318D16EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I just submitted a 00 draft on provisioning data sets. Until it shows up on the ID tracker you can use this version. Cheers, David=20 ------_=_NextPart_001_01C73374.318D16EB Content-Type: text/plain; name="Peppermint provisioning Version 00.txt" Content-Transfer-Encoding: base64 Content-Description: Peppermint provisioning Version 00.txt Content-Disposition: attachment; filename="Peppermint provisioning Version 00.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIFNjaHdhcnR6DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBLYXlvdGUgTmV0d29ya3MNCkludGVuZGVkIHN0YXR1czog SW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRS4gS2F0eg0K RXhwaXJlczogSnVseSA1LCAyMDA3ICAgICAgICAgICAgICAgICAgICAgICAgICAgWENvbm5lY3Qg R2xvYmFsIE5ldHdvcmtzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCiANCg0KICAgICAgICAgICBFLjE2NCBO dW1iZXIgUHJvdmlzaW9uaW5nIC0gRGF0YSBTZXQgUmVxdWlyZW1lbnRzDQogICAgICBkcmFmdC1z Y2h3YXJ0ei1wZXBwZXJtaW50LWUxNjQtcHJvdmlzaW9uaW5nLWRhdGEtc2V0LTAwLnR4dA0KDQpT dGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFm dCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQg b3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUg YmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVj b21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0 aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0 cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQog ICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlk IGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQog ICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVz cy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nl c3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0K DQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJl IGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEp1bHkgNSwgMjAwNy4NCg0KQ29weXJp Z2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA3 KS4NCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBvdXRsaW5lcyB3aGljaCBpbmZvcm1h dGlvbiBzaG91bGQgYmUgY2FwdHVyZWQgd2hlbg0KICAgRS4xNjQgbnVtYmVycyBhcmUgcHJvdmlz aW9uZWQgd2l0aGluIGEgY2VudHJhbCByZWdpc3RyeS4gIFRoaXMNCiAgIGRvY3VtZW50IGlzIG5v dCBhIHNwZWNpZmljYXRpb24gYnV0IHJhdGhlciBhIHNldCBvZiBpbmZvcm1hdGlvbg0KICAgd2hp Y2gsIHdoZW4gYXNzb2NpYXRlZCB3aXRoIGFuIGFkZHJlc3NhYmxlIGVudGl0eSBjYW4gYXNzaXN0 IGluDQogICBhcHBseWluZyBwb2xpY3kgdG8gc3Vic2VxdWVudCBxdWVyaWVzLg0KDQoNCg0KDQoN ClNjaHdhcnR6ICYgS2F0eiAgICAgICAgICAgRXhwaXJlcyBKdWx5IDUsIDIwMDcgICAgICAgICAg ICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBFLjE2NCBwcm92aXNp b25pbmcgZGF0YSBzZXQgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KVGFibGUgb2YgQ29udGVu dHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAyLiAgU2NvcGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMNCiAgIDMuICBQcm92aXNpb25p bmcgSW5mb3JtYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0K ICAgNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA3DQogICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcNCiAgIDYuICBBY2tub3dsZWRnZW1lbnRz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNw0KICAgNy4g IFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA4DQogICAgIDcuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCiAgICAgNy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl bmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOA0KICAgQXV0aG9ycycg QWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA4DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzICAu IC4gLiAuIC4gLiAuIC4gLiAuIDkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTY2h3YXJ0eiAmIEthdHog ICAgICAgICAgIEV4cGlyZXMgSnVseSA1LCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgRS4xNjQgcHJvdmlzaW9uaW5nIGRhdGEgc2V0ICAg ICAgICAgIEphbnVhcnkgMjAwNw0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgV2hlbiB3cml0 aW5nIHJ1bGUgYmFzZWQgZW5naW5lcyB0byBwcm92aWRlIGZpbHRlcmVkIGFjY2VzcyB0byBFLjE2 NA0KICAgZGF0YSBpdCBpcyBvZnRlbiBuZWNlc3NhcnkgdG8gaGF2ZSBtb3JlIGluZm9ybWF0aW9u IGF2YWlsYWJsZSBmb3IgdGhlDQogICBxdWVyeSB0aGFuIGp1c3QgdGhlIGFkZHJlc3Mgb2YgcmVj b3JkIChBT1IpIHRoYXQgY29ycmVzcG9uZHMgdG8gYQ0KICAgcGFydGljdWxhciBudW1iZXIuICBU aGlzIGFkZGl0aW9uYWwgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgdGhlDQogICBzdWJqZWN0IG9m IHRoaXMgZHJhZnQgZG9jdW1lbnQuICBUaGUgZGF0YSBzZXQgaW4gdGhpcyBkb2N1bWVudCBjYW4g LQ0KICAgYW5kIHNob3VsZCBiZSAtIGV4dGVuZGVkIGFuZCBpcyBpbnRlbmRlZCB0byBzcHVyIGRp c2N1c3Npb24gdGhhdCB3aWxsDQogICByZXN1bHQgaW4gYSBjb21wbGV0ZSBzZXQuDQoNCg0KMi4g IFNjb3BlDQoNCiAgIFRoaXMgZG9jdW1lbnQgZm9jdXNlcyBvbiB0aGUgc3VwcG9ydGluZyBkYXRh IHNldCB0aGF0IGlzIHJlcXVpcmVkIHRvDQogICBwcm9wZXJseSBwcm92aXNpb25pbmcgRS4xNjQg bnVtYmVycy4gIEEgZGlzY3Vzc2lvbiBvZiB0aGUgbWVjaGFuaXNtDQogICB0byB0cmFuc2ZlciBv ciB1cGxvYWQgdGhpcyBkYXRhIHRvIHRoZSByZWdpc3RyeSBvciB0aGUgcHJvdG9jb2xzIHVzZWQN CiAgIGZvciB0aGlzIHB1cnBvc2UgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50 Lg0KDQoNCjMuICBQcm92aXNpb25pbmcgSW5mb3JtYXRpb24NCg0KICAgVGhlIHByb3Zpc2lvbmlu ZyBkYXRhIGNhbiBiZSBicm9rZW4gZG93biBpbnRvIHR3byBjYXRlZ29yaWVzOiBzdGF0aWMNCiAg IGFuZCBkeW5hbWljLiAgU3RhdGljIGluZm9ybWF0aW9uIGlzIHRoYXQgd2hpY2ggaXMgYXNzb2Np YXRlZCB3aXRoIHRoZQ0KICAgb3duZXIgb2YgdGhlIHJlc291cmNlIGFuZCByZW1haW5zIGNvbnN0 YW50IGZyb20gcXVlcnkgdG8gcXVlcnkuDQogICBEeW5hbWljIGluZm9ybWF0aW9uIGlzIHRoYXQg d2hpY2ggY2FuIGJlIGZhY3RvcmVkIGludG8gInByb2ZpbGVzIiBvcg0KICAgdmlld3Mgb2YgdGhl IGRhdGEsIGVhY2ggd2l0aCBwb3RlbnRpYWxseSBkaWZmZXJlbnQgZGF0YS4NCg0KICAgbyAgU3Rh dGljIEluZm9ybWF0aW9uDQoNCiAgICAgIFRoZSBkYXRhIGluIHRoaXMgY2F0ZWdvcnkgcmVsYXRl cyB0byB0aGUgaWRlbnRpZmljYXRpb24sIG93bmVyc2hpcA0KICAgICAgYW5kIGdlbmVyYWwgdmFs aWRpdHkgb2YgdGhlIG51bWJlci4NCg0KICAgICAgMS4gIFZhbHVlDQoNCiAgICAgICAgICBUaGUg dmFsdWUgaXMgdGhlIHJlc291cmNlIHRoYXQgaXMgYmVpbmcgc291Z2h0LiAgVGhpcyB2YWx1ZQ0K ICAgICAgICAgIG1heSBiZSBhIGZ1bGx5IHF1YWxpZmllZCBFLjE2NCBudW1iZXIgKGUuZy4gMTIx Mjc3NzU1NTUpLCBvcg0KICAgICAgICAgIGFsdGVybmF0aXZlbHksIHRoZSB2YWx1ZSBtYXkgYmUg YSBudW1iZXIgcmVwcmVzZW50aW5nIGEgcmFuZ2UNCiAgICAgICAgICBvZiBudW1iZXJzIChlLmcu IDEyMTI3NzcpLiAgSW4gdGhpcyBsYXR0ZXIgY2FzZSB0aGUgImxlbmd0aCINCiAgICAgICAgICBm aWVsZCBkZWZpbmVkIGJlbG93IGlzIG5lZWRlZCB0byBlc3RhYmxpc2ggdGhlIGxpbWl0cyBvZiB0 aGUNCiAgICAgICAgICBudW1iZXIgcmFuZ2UuDQoNCiAgICAgIDIuICBSYW5nZQ0KDQogICAgICAg ICAgVGhpcyBhbmQgdGhlIG5leHQgZmllbGQgYXJlIHVzZWQgdG8gYXNzaXN0IGluIHJlc29sdmlu ZyByYW5nZXMNCiAgICAgICAgICBpbnRvIGluZGl2aWR1YWwgYW5kIHVuaXF1ZSB2YWxpZCBFLjE2 NCBudW1iZXJzLiAgVGhlIFJhbmdlDQogICAgICAgICAgZmllbGQgaXMgYSBCb29sZWFuIHZhbHVl LCB3aGljaCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgcmVzb3VyY2UNCiAgICAgICAgICBzcGVjaWZp ZWQgaW4gdGhlICJWYWx1ZSIgZmllbGQgaXMgYSByYW5nZSB0aGF0IG5lZWRzIHRvIGJlDQogICAg ICAgICAgZXhwYW5kZWQgb3V0IHRvIHRoZSAibGVuZ3RoIiBudW1iZXIgb2YgZGlnaXRzLCBvcg0K DQoNCg0KU2Nod2FydHogJiBLYXR6ICAgICAgICAgICBFeHBpcmVzIEp1bHkgNSwgMjAwNyAgICAg ICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEUuMTY0IHBy b3Zpc2lvbmluZyBkYXRhIHNldCAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0KDQogICAgICAgICAg YWx0ZXJuYXRpdmVseSwgYW4gaW5kaXZpZHVhbCBudW1iZXIgdGhhdCBkb2VzIG5vdCByZXF1aXJl DQogICAgICAgICAgZnVydGhlciBtYW5pcHVsYXRpb24uDQoNCiAgICAgIDMuICBMZW5ndGgNCg0K ICAgICAgICAgIFRoaXMgZmllbGQgaXMgdXNlZCBmb3IgZXhwYW5kaW5nIHJhbmdlcyB0byBpbmRp dmlkdWFsIHVuaXF1ZQ0KICAgICAgICAgIG51bWJlcnMuDQoNCiAgICAgIDQuICBDcmVhdGlvbkRh dGVUaW1lDQoNCiAgICAgICAgICBUaGUgdmFsdWUgIkNyZWF0aW9uRGF0ZVRpbWUiIHJlZmVycyB0 byB0aGUgZGF0ZSBvbiB3aGljaCB0aGlzDQogICAgICAgICAgcmVzb3VyY2Ugd2FzIGZpcnN0IHBy b3Zpc2lvbmVkIGJ5IHRoaXMgc2VydmljZSBwcm92aWRlci4gIElmDQogICAgICAgICAgdGhlIGRh dGUgZG9lcyBub3QgbWF0Y2ggdGhlIGN1cnJlbnQgZGF0ZSBhbmQgdGltZSB0aGlzIHJlY29yZA0K ICAgICAgICAgIGNvbnRhaW5zIG1vZGlmaWNhdGlvbnMgdG8gYW4gZXhpc3RpbmcgVmFsdWUuICBJ ZiB0aGUgZGF0ZSBkb2VzDQogICAgICAgICAgbWF0Y2ggdGhlIGN1cnJlbnQgZGF0ZSB0aGFuIHRo aXMgaXMgYSBuZXcgcmVjb3JkLg0KDQogICAgICAgICAgKyAgVGltZVpvbmUNCg0KICAgICAgICAg ICAgIEFsbCBEYXRlVGltZSBmaWVsZHMgbXVzdCBpbmNsdWRlIFRpbWVab25lIGluZm9ybWF0aW9u IGZvcg0KICAgICAgICAgICAgIG5vcm1hbGl6YXRpb24uDQoNCiAgICAgIDUuICBUeXBlDQoNCiAg ICAgICAgICBUaGVyZSBpcyB2YWx1ZSBpbiBrbm93aW5nIHdoYXQgdHlwZSBvZiByZXNvdXJjZSB0 aGlzIGlzIChlLmcuDQogICAgICAgICAgcmVzaWRlbnRpYWwsIGNhbGwgc2hvcCwgZXRjKS4gIERp ZmZlcmVudCB0eXBlcyBvZiByZXNvdXJjZXMNCiAgICAgICAgICBoYXZlIGRpZmZlcmVudCB1c2Fn ZSBwYXR0ZXJucyBhbmQgY2FwdHVyaW5nIHRoaXMgaW5mb3JtYXRpb24NCiAgICAgICAgICBjYW4g YXNzaXN0IGluIGRldmVsb3BpbmcgZnJhdWQgZGV0ZWN0aW9uIGVuZ2luZXMNCg0KICAgICAgNi4g IFByaXZhY3kNCg0KICAgICAgICAgIFRoaXMgZmllbGQgaXMgYSBmbGFnIGluZGljYXRpbmcgd2hl dGhlciB0aGlzIG51bWJlciBpcw0KICAgICAgICAgIHB1YmxpY2x5IGF2YWlsYWJsZSB0byBhbnlv bmUgb3Igd2hldGhlciB0aGVyZSBoYXMgdG8gYmUgYQ0KICAgICAgICAgIHByZWRldGVybWluZWQg cG9saWN5IGluIHBsYWNlIGluIG9yZGVyIGZvciB0aGUgbnVtYmVyIHRvIGJlDQogICAgICAgICAg Z2l2ZW4gb3V0DQoNCiAgICAgIDcuICBPd25lcnNoaXANCg0KICAgICAgICAgIFRoZSBPd25lcnNo aXAgZmllbGQgY29uc2lzdHMgb2YgYWRkaXRpb25hbCBzdWJmaWVsZHMgZGVmaW5pbmcNCiAgICAg ICAgICB0aGUgb3duZXJzaGlwIG9mIHRoZSBwcm92aXNpb25lZCBlMTY0IHJlc291cmNlLiAgQXQg YW55IGdpdmVuDQogICAgICAgICAgdGltZSB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgIm93bmVycyIg b2YgYSBnaXZlbiByZXNvdXJjZS4gIFRoZQ0KICAgICAgICAgIHRocmVlIGxldmVscyBkZXNjcmli ZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgQ2FycmllciBvZiBSZWNvcmQsDQogICAgICAgICAgU2Vy dmljZSBQcm92aWRlciBhbmQgRW5kIFVzZXIuICBTaW5jZSBpdCBpcyBxdWl0ZSBwb3NzaWJsZQ0K ICAgICAgICAgIHRoYXQgdGhlc2UgYXJlIHRocmVlIGRpc3RpbmN0IGVudGl0aWVzIHRoZXkgYWxs IG11c3QgYmUNCiAgICAgICAgICBzcGVjaWZpZWQgZm9yIHRoZSBwcm92aXNpb25lZCByZXNvdXJj ZS4gIFNpbmNlIHJlZ3VsYXRvcnkNCiAgICAgICAgICBpc3N1ZXMgYWxsb3cgZm9yIG93bmVyc2hp cCB0cmFuc2ZlciB0byBhbmQgZnJvbSBkaWZmZXJlbnQNCiAgICAgICAgICBTZXJ2aWNlUHJvdmlk ZXJzLCBlYWNoIFNlcnZpY2VQcm92aWRlciBmaWVsZCBtdXN0IGJlIHF1YWxpZmllZA0KICAgICAg ICAgIHZpYSBhY3RpdmF0aW9uIGRhdGVzLg0KDQoNCg0KDQpTY2h3YXJ0eiAmIEthdHogICAgICAg ICAgIEV4cGlyZXMgSnVseSA1LCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgRS4xNjQgcHJvdmlzaW9uaW5nIGRhdGEgc2V0ICAgICAgICAg IEphbnVhcnkgMjAwNw0KDQoNCiAgICAgICAgICArICBDYXJyaWVyT2ZSZWNvcmQNCg0KICAgICAg ICAgICAgIEFzIGRlZmluZWQgaW4gWzJdIHRoZSBDYXJyaWVyIG9mIFJlY29yZCBpcyB0eXBpY2Fs bHkgYQ0KICAgICAgICAgICAgIHNlcnZpY2UgcHJvdmlkZXIgdGhhdCBpcyBhdXRob3JpemVkIHRv IGlzc3VlIEUuMTY0IG51bWJlcnMNCiAgICAgICAgICAgICBmb3IgdGhlIHByb3Zpc2lvbmluZyBv ZiBQU1ROIHNlcnZpY2UgdW5kZXIgdGhlIGF1dGhvcml0eSBvZg0KICAgICAgICAgICAgIGEgTmF0 aW9uYWwgUmVndWxhdG9yeSBBdXRob3JpdHkgKE5SQSkuDQoNCiAgICAgICAgICArICBTZXJ2aWNl UHJvdmlkZXINCg0KICAgICAgICAgICAgIFRoZSBTZXJ2aWNlUHJvdmlkZXIgZmllbGQgaW5kaWNh dGVzIHRoZSBwYXJ0eSB0aGF0ICJzZWxscyINCiAgICAgICAgICAgICB0aGUgcmVzb3VyY2UgdG8g dGhlIGVuZCB1c2VyLiAgU2VydmljZVByb3ZpZGVyIGZpZWxkIGlzDQogICAgICAgICAgICAgc3Vi amVjdCB0byBkYXRlcyBhcyBkZWZpbmVkIGJlbG93Lg0KDQogICAgICAgICAgICAgLSAgQWN0aXZh dGlvbkRhdGVUaW1lDQoNCiAgICAgICAgICAgICAgICBUaGVyZSBhcmUgbWFueSByZWFzb25zIHdo eSBpdCBpcyBwb3NzaWJsZSBmb3IgYSBudW1iZXINCiAgICAgICAgICAgICAgICB0byBiZSBwcm92 aXNpb25lZCBidXQgbm90IHlldCBhY3RpdmUuICBGb3IgZXhhbXBsZSwNCiAgICAgICAgICAgICAg ICBjb25zaWRlciB0aGUgc2l0dWF0aW9uIGluIHdoaWNoIGEgc2VydmljZSBwcm92aWRlcg0KICAg ICAgICAgICAgICAgIHByb3Zpc2lvbnMgYSBudW1iZXIgcmFuZ2UsIGJ1dCBhY3RpdmF0ZXMgb25s eSB0aGUgYWN0dWFsDQogICAgICAgICAgICAgICAgbnVtYmVycyB0aGF0IGhhdmUgYmVlbiAic29s ZCIgdG8gY3VzdG9tZXJzLiAgVGhlDQogICAgICAgICAgICAgICAgZXhpc3RhbmNlIG9mIGFuICJB Y3RpdmF0aW9uRGF0ZVRpbWUiIGZpZWxkIHdvdWxkIGVuYWJsZQ0KICAgICAgICAgICAgICAgIHRo ZSBzZXJ2aWNlIHRvIGFjdGl2YXRlIG9ubHkgYSBzaW5nbGUgbnVtYmVyIG9yIHJhbmdlIG9mDQog ICAgICAgICAgICAgICAgbnVtYmVycyBhdCBzb21lIGZ1dHVyZSB0aW1lLg0KDQogICAgICAgICAg ICAgLSAgRGVhY3RpdmF0aW9uRGF0ZVRpbWUNCg0KICAgICAgICAgICAgICAgIFNpbWlsYXIgdG8g dGhlIEFjdGl2YXRpb25EYXRlVGltZSBmaWVsZCBkZXNjcmliZWQgYWJvdmUsDQogICAgICAgICAg ICAgICAgYSBEZWFjdGl2YXRpb25EYXRlVGltZSBmaWVsZCBjb3VsZCBiZSB1c2VkIHRvIHBvcnQN CiAgICAgICAgICAgICAgICBudW1iZXJzIHRvIGEgZGlmZmVyZW50IHByb3ZpZGVyIHRvIGNvbXBs eSB3aXRoIHJlZ2lvbmFsDQogICAgICAgICAgICAgICAgbnVtYmVyIHBvcnRhYmlsaXR5IHJlcXVp cmVtZW50cy4NCg0KICAgICAgICAgICAgIC0gIFRpbWVab25lDQoNCiAgICAgICAgICAgICAgICBB bGwgRGF0ZVRpbWUgZmllbGRzIG11c3QgaW5jbHVkZSBUaW1lWm9uZSBpbmZvcm1hdGlvbg0KICAg ICAgICAgICAgICAgIGZvciBub3JtYWxpemF0aW9uLg0KDQogICAgICAgICAgKyAgRW5kVXNlcg0K DQogICAgICAgICAgICAgVGhlIEVuZFVzZXIgZmllbGQgaW5kaWNhdGVzIHRoZSB1c2VyIHRvIHdo aWNoIHRoaXMgbnVtYmVyDQogICAgICAgICAgICAgd2FzIHByb3Zpc2lvbmVkLiAgTm90ZSB0aGF0 IHRoZXJlIGNhbiBiZSBzdWJmaWVsZHMNCiAgICAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhl IEVuZFVzZXIgdGhhdCBwcm92aWRlIG1vcmUgaW5mb3JtYXRpb24NCiAgICAgICAgICAgICBhYm91 dCB0aGlzIHVzZXIuICBPbmx5IG9uZSBzdWNoIGZpZWxkIChFbmRVc2VyVGltZVpvbmUpIGlzDQog ICAgICAgICAgICAgcHJlc2VudGVkIGhlcmUgYXMgaXQgaXMgdXNlZnVsIHdoZW4gY3JlYXRpbmcg dXNlciBiYXNlZA0KICAgICAgICAgICAgIHBvbGljeSBlbmdpbmVzLg0KDQogICAgICAgICAgICAg LSAgRW5kVXNlclRpbWVab25lDQoNCiAgICAgICAgICAgICAgICBLbm93aW5nIHRoZSB0aW1lIHpv bmUgb2YgdGhlIHVzZXIgdG8gd2hpY2ggdGhpcyBudW1iZXINCg0KDQoNClNjaHdhcnR6ICYgS2F0 eiAgICAgICAgICAgRXhwaXJlcyBKdWx5IDUsIDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSA1 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBFLjE2NCBwcm92aXNpb25pbmcgZGF0YSBzZXQg ICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgICAgICAgICAgIGlzIHByb3Zpc2lvbmVk IGNhbiBhc3Npc3QgaW4gZGV2ZWxvcGluZyByZWNlaXZpbmcgdXNlcg0KICAgICAgICAgICAgICAg IHRpbWUgYmFzZWQgcG9saWN5DQoNCiAgIG8gIER5bmFtaWMgSW5mb3JtYXRpb24NCg0KICAgICAg VGhlIGRhdGEgaW4gdGhpcyBzZWN0aW9uIGJlbG9uZ3MgaW4gYSBjYXRlZ29yeSB0aGF0IGlzIGRl cGVuZGVudA0KICAgICAgb24gIndobyBpcyBhc2tpbmciLiAgU29tZSBvZiB0aGUgcHJvdmlzaW9u ZWQgaW5mb3JtYXRpb24gaW4gdGhpcw0KICAgICAgc2VjdGlvbiBpcyBxdWVyeWluZyBwYXJ0eSBk ZXBlbmRlbnQgd2hpbGUgb3RoZXIgaW5mb3JtYXRpb24gaXMNCiAgICAgIHF1ZXJpZWQgZGF0YSBk ZXBlbmRlbnQuICBFYWNoIHNldCBvZiAiZHluYW1pYyIgaW5mb3JtYXRpb24gaXMNCiAgICAgIGdy b3VwZWQgaW50byBhICJwcm9maWxlIiBvciAidmlldyIgYW5kIHRoZXJlIGFyZSBwb3RlbnRpYWxs eSBtYW55DQogICAgICBwcm9maWxlcyBmb3IgZWFjaCBzdGF0aWMgcmVzb3VyY2UgcmVjb3JkLiAg U3BlY2lmaWNhbGx5LCB0aGVyZSBpcw0KICAgICAgYWx3YXlzIGF0IGxlYXN0IG9uZSBwcm9maWxl IGZvciBlYWNoIHN0YXRpYyByZWNvcmQgcmVwcmVzZW50aW5nDQogICAgICB0aGUgImRlZmF1bHQi IGJlaGF2aW9yIGFuZCAwIG9yIG1vcmUgInNwZWNpYWxpemVkIiBwcm9maWxlcyB0aGF0DQogICAg ICBvdmVycmlkZSB0aGUgZGVmYXVsdCBwcm9maWxlIGZvciByZXF1ZXN0cyB0aGF0IG1hdGNoIHRo ZSBjcml0ZXJpYQ0KICAgICAgb2YgdGhlIHByb2ZpbGUuDQoNCiAgICAgICogIFByb2ZpbGUNCg0K ICAgICAgICAgKyAgUXVlcnlEYXRhSW5mb3JtYXRpb24NCg0KICAgICAgICAgICAgMS4gIFZhbGlk aXR5DQoNCiAgICAgICAgICAgICAgICBUaGUgdmFsaWRpdHkgZmllbGQgaXMgdXNlZCB0byBkZWZp bmUgYSB3aW5kb3cgaW4gd2hpY2gNCiAgICAgICAgICAgICAgICB0aGlzIHByb2ZpbGUgaXMgYWN0 aXZlLiAgVGhlIGZvbGxvd2luZyB0aHJlZSBzdWJmaWVsZHMNCiAgICAgICAgICAgICAgICBwcm92 aWRlIGhpZ2hlciByZXNvbHV0aW9uIGZvciB0aGlzIGZpZWxkLg0KDQogICAgICAgICAgICAgICAg byAgU3RhcnREYXRlVGltZQ0KDQogICAgICAgICAgICAgICAgbyAgU3RvcERhdGVUaW1lDQoNCiAg ICAgICAgICAgICAgICBvICBUaW1lWm9uZQ0KDQogICAgICAgICAgICAyLiAgQWRkcmVzc09mUmVj b3JkDQoNCiAgICAgICAgICAgICAgICBUaGUgQU9SIGZpZWxkIGRvY3VtZW50cyB0aGUgYWN0dWFs IGxvY2F0aW9uIGluZm9ybWF0aW9uDQogICAgICAgICAgICAgICAgZm9yIHRoZSBhc3NvY2lhdGVk IHJlc291cmNlLiAgVGhlIGZvbGxvd2luZyB0d28NCiAgICAgICAgICAgICAgICBzdWJjYXRlZ29y aWVzIGFyZSBwcm92aWRlZCBmb3IgYWRkaXRpb25hbCBmbGV4aWJpbGl0eS4NCg0KICAgICAgICAg ICAgICAgIG8gIFJlZ2V4DQoNCiAgICAgICAgICAgICAgICBvICBUZXJtaW5hdGlvbkRvbWFpbg0K DQogICAgICAgICArICBRdWVyeWluZ1BhcnR5SW5mb3JtYXRpb24NCg0KICAgICAgICAgICAgMS4g IFF1ZXJ5RnJvbUxvY2F0aW9uDQoNCiAgICAgICAgICAgICAgICBUaGlzIGluY2x1ZGVzIGJvdGgg YSB1c2VyIGlkIGFzIHdlbGwgYXMgYW4gSVAvcyBmcm9tDQogICAgICAgICAgICAgICAgd2hlcmUg dGhlIHF1ZXJpZXMgd2lsbCBlbWFuYXRlLg0KDQoNCg0KU2Nod2FydHogJiBLYXR6ICAgICAgICAg ICBFeHBpcmVzIEp1bHkgNSwgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgIEUuMTY0IHByb3Zpc2lvbmluZyBkYXRhIHNldCAgICAgICAgICBK YW51YXJ5IDIwMDcNCg0KDQogICAgICAgICAgICAgICAgbyAgUXVlcnlVc2VySUQNCg0KICAgICAg ICAgICAgICAgIG8gIFF1ZXJ5VXNlckFkZHJlc3MNCg0KICAgICAgICAgICAgMi4gIFF1ZXJ5TWVj aGFuaXNtDQoNCiAgICAgICAgICAgICAgICBEZXBlbmRpbmcgb24gdGhlIHF1ZXJ5IG1lY2hhbmlz bSB1c2VkLCBpdCBtYXkgYmUgbW9yZQ0KICAgICAgICAgICAgICAgIGFkdmFudGFnZW91cyB0byBy ZXNvbHZlIHRvIGEgZGlmZmVyZW50IEFPUi4gIEZvcg0KICAgICAgICAgICAgICAgIGV4YW1wbGUs IGRlcGVuZGluZyBvbiB3aGljaCBwcm90b2NvbCBpcyB1c2VkLCBpdCBtaWdodA0KICAgICAgICAg ICAgICAgIGJlIHBvc3NpYmxlIHRvIHByb3ZpZGUgbW9yZSBleHRlbnNpdmUgcm91dGluZw0KICAg ICAgICAgICAgICAgIGluZm9ybWF0aW9uLiAgQWx0ZXJuYXRpdmVseSwgdGhlIHJlZ2lzdHJ5IG1h eSBjaG9vc2UgdG8NCiAgICAgICAgICAgICAgICBzZW5kIGRpZmZlcmVudCBpbmZvcm1hdGlvbiBi YWNrIHRvIHRoZSBxdWVyeWluZyBwYXJ0eQ0KICAgICAgICAgICAgICAgIGRlcGVuZGluZyBvbiB0 aGUgc2VjdXJpdHkgb2YgdGhlIHF1ZXJ5IGNvbW11bmljYXRpb24NCiAgICAgICAgICAgICAgICBw YXRoLiAgVGhpcyBzdWJzZWN0aW9uIGRlbGluZWF0ZXMgdGhlc2UgY29uc2lkZXJhdGlvbnMuDQoN CiAgICAgICAgICAgICAgICBvICBRdWVyeVR5cGUNCg0KICAgICAgICAgICAgICAgICAgIFRoZXJl IGFyZSBtYW55IHByb3RvY29scyB0aGF0IGNhbiBiZSB1c2VkIHRvIHBlcmZvcm0NCiAgICAgICAg ICAgICAgICAgICB0aGUgcXVlcnkuICBXaGlsZSBFTlVNIGlzIG9uZSBvZiB0aGUgbW9yZSBwb3B1 bGFyDQogICAgICAgICAgICAgICAgICAgcHJvdG9jb2xzIHRoZXJlIGlzIG5vIHJlYXNvbiBvdGhl ciBwcm90b2NvbHMgKGUuZy4NCiAgICAgICAgICAgICAgICAgICBTSVAgMzAyKSBjYW5ub3QgYmUg dXNlZCBhcyB3ZWxsLiAgVGh1cyB0aGUgVHlwZSBvZg0KICAgICAgICAgICAgICAgICAgIFF1ZXJ5 IGZpZWxkIGluZGljYXRlcyB3aGljaCBwcm90b2NvbCB3aWxsIGJlIHVzZWQgZm9yDQogICAgICAg ICAgICAgICAgICAgdGhpcyBwcm9maWxlLg0KDQogICAgICAgICAgICAgICAgbyAgUXVlcnlTZWN1 cml0eQ0KDQogICAgICAgICAgICAgICAgICAgSXQgaXMgaW1wb3J0YW50IHRvIHNlY3VyZSB0aGUg bG9jYXRpb24gbG9va3VwIHByb2Nlc3MNCiAgICAgICAgICAgICAgICAgICBlc3BlY2lhbGx5IGlm IHRoZSBsb29rdXAgaXMgcmVtb3RlLiAgVGhpcyBTZWN1cml0eQ0KICAgICAgICAgICAgICAgICAg IGZpZWxkIHdvdWxkIGluY2x1ZGUgdmFsdWVzIHN1Y2ggYXMgIj1JUFNlYyJbMV0NCg0KDQo0LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5v IG5ldyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCg0KDQo1LiAgSUFOQSBDb25zaWRlcmF0aW9u cw0KDQogICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgbm8gbmV3IHJlcXVpcmVtZW50cyBvbiBJQU5B IG5hbWVzcGFjZXMNCiAgIFtSRkMyNDM0XS4NCg0KDQo2LiAgQWNrbm93bGVkZ2VtZW50cw0KDQog ICBUaGlzIGRvY3VtZW50IGlzIGJhc2VkIGluIHBhcnQgb24gY29udHJpYnV0aW9ucyBtYWRlIGJ5 IEJyb2NoYQ0KICAgU3Ryb3VzLCBEYXZpZCBLb3BwZWwsIE9mZXIgTWl6cmFjaGksIE1pa2UgR3J5 bmJlcmcgYW5kIFlhZWwgQmVybGluZ2VyDQogICBvZiBLYXlvdGUgTmV0d29ya3MgYW5kIE5hdGFu IFRpZWZlbmJydW4gb2YgWENvbm5lY3QgR2xvYmFsIE5ldHdvcmtzLg0KDQoNCg0KDQpTY2h3YXJ0 eiAmIEthdHogICAgICAgICAgIEV4cGlyZXMgSnVseSA1LCAyMDA3ICAgICAgICAgICAgICAgICAg W1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgRS4xNjQgcHJvdmlzaW9uaW5nIGRh dGEgc2V0ICAgICAgICAgIEphbnVhcnkgMjAwNw0KDQoNCjcuICBSZWZlcmVuY2VzDQoNCjcuMS4g ICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbMV0gIEtlbnQsIFMuIGFuZCBSLiBBdGtpbnNv biwgIlNlY3VyaXR5IEFyY2hpdGVjdHVyZSBmb3IgdGhlDQogICAgICAgIEludGVybmV0IFByb3Rv Y29sIiwgUkZDIDI0MDEsIE5vdmVtYmVyIDE5OTguDQoNCjcuMi4gICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzDQoNCiAgIFsyXSAgTGluZCwgUy4gYW5kIFAuIFBmYXV0eiwgIkluZnJhc3RydWN0dXJl IEVOVU0gUmVxdWlyZW1lbnRzIiwNCiAgICAgICAgIGRyYWZ0LWlldGYtZW51bS1pbmZyYXN0cnVj dHVyZS1lbnVtLXJlcXMtMDMudHh0LCBBdWd1c3QgMjAwNi4NCg0KDQpBdXRob3JzJyBBZGRyZXNz ZXMNCg0KICAgRGF2aWQgU2Nod2FydHoNCiAgIEtheW90ZSBOZXR3b3Jrcw0KICAgTWFsY2hhIFRl Y2hub2xvZ3kgUGFyaw0KICAgQnVpbGRpbmcgIyAxDQogICBKZXJ1c2FsZW0gIDkwOTYxDQogICBJ c3JhZWwNCg0KICAgUGhvbmU6ICs5NzIgNTIgMzQ3IDQ2NTYNCiAgIEVtYWlsOiBkYXZpZC5zY2h3 YXJ0ekBrYXlvdGUuY29tDQogICBVUkk6ICAgd3d3LmtheW90ZS5jb20NCg0KDQogICBFbGkgS2F0 eg0KICAgWENvbm5lY3QgR2xvYmFsIE5ldHdvcmtzDQogICAxIEJhbGxhcmRzIExhbmUNCiAgIExv bmRvbiAgTjMgMUxRDQogICBVbml0ZWQgS2luZ2RvbQ0KDQogICBQaG9uZTogKzQ0ICgwKSA4NzAg Nzk0IDk5OTANCiAgIEZheDogICArNDQgKDApIDg3MCA3OTQgOTk5MQ0KICAgRW1haWw6IGVrYXR6 QHhjb25uZWN0Lm5ldA0KICAgVVJJOiAgIHd3dy54Y29ubmVjdC5uZXQNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpTY2h3YXJ0eiAmIEthdHogICAgICAgICAgIEV4cGlyZXMgSnVseSA1LCAy MDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg RS4xNjQgcHJvdmlzaW9uaW5nIGRhdGEgc2V0ICAgICAgICAgIEphbnVhcnkgMjAwNw0KDQoNCkZ1 bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBT b2NpZXR5ICgyMDA3KS4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdo dHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFu ZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxs IHRoZWlyIHJpZ2h0cy4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBU SEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9S IElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJ TlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElF UywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBB TlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJ TEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMg T0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0K DQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlv biByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFs IFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRv DQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xv Z3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2gg YW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBh dmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkg aW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0 aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBk b2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29w aWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBh bnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRo ZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vu c2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdo dHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2Fu IGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVy ZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMs IHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAg IHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRv IGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1h dGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KQWNrbm93bGVk Z21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgcHJvdmlk ZWQgYnkgdGhlIElFVEYNCiAgIEFkbWluaXN0cmF0aXZlIFN1cHBvcnQgQWN0aXZpdHkgKElBU0Ep Lg0KDQoNCg0KDQoNClNjaHdhcnR6ICYgS2F0eiAgICAgICAgICAgRXhwaXJlcyBKdWx5IDUsIDIw MDcgICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0K ------_=_NextPart_001_01C73374.318D16EB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint ------_=_NextPart_001_01C73374.318D16EB-- Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3taj-0000Nl-FM; Mon, 08 Jan 2007 07:27:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3taj-0000Nf-4T for peppermint@ietf.org; Mon, 08 Jan 2007 07:27:05 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3tag-0002ab-Ft for peppermint@ietf.org; Mon, 08 Jan 2007 07:27:05 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 08 Jan 2007 07:26:24 -0500 id 01588001.45A23870.00002C22 In-Reply-To: <20070108095558.GA11859@nic.at> References: <035A6FCC-9D8F-49DA-AA44-266D60E469A2@hxr.us> <20070108095558.GA11859@nic.at> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [PEPPERMINT] First pass at a BoF proposal Date: Mon, 8 Jan 2007 07:26:52 -0500 To: Otmar Lendl X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: peppermint@ietf.org X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1817031720==" Errors-To: peppermint-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1817031720== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-11300-1168259191-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-11300-1168259191-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 8, 2007, at 4:55 AM, Otmar Lendl wrote: > Do I read this correctly that you want to include? > > * Carriers provisioning numbers into a peering fabric's DB (the > "registry") Yes. > * Redistribution of that DB into each carrier's real-time routing DB This work could be used for this, but the primary motivation is different from my understanding. Peering fabrics tend to offer their members local cache's of the DB. Today, the syncing of that cache requires custom protocols and software. > Do you also envision direct carrier<->carrier interactions without > a third party acting as the registry? > > Or do you think that this will just be a special case? I do, as this happens today. And I'm not sure it is much different than the other interactions. In SPEERMINT terms, this is direct peering. -andy --=_zeke.ecotroph.net-11300-1168259191-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Jan 8, 2007, at 4:55= AM, Otmar Lendl wrote:

Do I read = this correctly that you want to include?


<= /P>

* Carriers provisioning numb= ers into a peering fabric's DB (the "registry")=A0


Yes.

* Redistribution of that DB into each carrier's real-time routing= DB


This work could be used for this, but the primary motivation is = different from my understanding.=A0 Peering fabrics tend to offer their m= embers local cache's of the DB.=A0 Today, the syncing of that cache requi= res custom protocols and software.

Do you also envision direct carrier&= lt;->carrier interactions without

a third party acting as the registry?=A0


Or do you think that this will just be a= special case?


I do, as this happens today.=A0 And I'm not sure it = is much different than the other interactions.=A0 In SPEERMINT terms, thi= s is direct peering.

-andy

<= /HTML> --=_zeke.ecotroph.net-11300-1168259191-0001-2-- --===============1817031720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint --===============1817031720==-- Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3sVi-00031t-Ug; Mon, 08 Jan 2007 06:17:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3sVh-00031i-Al for peppermint@ietf.org; Mon, 08 Jan 2007 06:17:49 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3sVN-0001u7-TO for peppermint@ietf.org; Mon, 08 Jan 2007 06:17:49 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 13F9E4C3D5; Mon, 8 Jan 2007 12:17:25 +0100 (CET) Date: Mon, 8 Jan 2007 12:17:25 +0100 From: Otmar Lendl To: peppermint@ietf.org Subject: Re: [PEPPERMINT] While we wait on the drafts Message-ID: <20070108111724.GB11859@nic.at> Mail-Followup-To: Otmar Lendl , peppermint@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org On 2007/01/05 18:01, Andrew Newton wrote: > > As I stated in the SPEERMINT meeting in San Diego, there seems to be > near zero deployment of RFC 4114. And almost every single time I've > asked about it, the response has been "What is RFC 4114?" In the > interest of understanding why RFC 4114 might not meet the > requirements for SIP peering provisioning, how many people have > implemented and/or deployed RFC 4114? The Austrian I-ENUM trial as run by enum.at uses EPP + RFC4114 as the provisioning interface. Personally, my love for RFC4114 is limited. EPP is fine for incremental changes, and I think we found a decent way to use EPP in the +43 user-ENUM provisioning. I see three flaws with 4114: * The key is the domain, not the number. IMHO the provisioning protocol should reflect the fact that we're dealing primarily with E.164 numbers. Yes, maybe the end-result of that provisioning is an ENUM-style domain, but that could just as well be a SIP redirect server or some other mechanism. * Reliance on the NAPTR format. As above: If all you are ever going to produce is an ENUM zone, then yes: that may be ok and gives you full control over the resulting NAPTR record. Once again, if you consider other query protols other than DNS/ENUM, then 4114 is too specific. * No simple way to specify number-ranges or prefixes. You can work-around using wildcard domain-names for prefixes, but things like +1 555 123 4444 -- +1 555 123 4532 can only be done by enumerating all numbers in that range. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3rEj-00005c-8m; Mon, 08 Jan 2007 04:56:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3rEh-000056-Gi for peppermint@ietf.org; Mon, 08 Jan 2007 04:56:11 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3rEg-00047F-8A for peppermint@ietf.org; Mon, 08 Jan 2007 04:56:11 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id EE0764C3D5; Mon, 8 Jan 2007 10:55:58 +0100 (CET) Date: Mon, 8 Jan 2007 10:55:58 +0100 From: Otmar Lendl To: peppermint@ietf.org Subject: Re: [PEPPERMINT] First pass at a BoF proposal Message-ID: <20070108095558.GA11859@nic.at> Mail-Followup-To: Otmar Lendl , peppermint@ietf.org References: <035A6FCC-9D8F-49DA-AA44-266D60E469A2@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <035A6FCC-9D8F-49DA-AA44-266D60E469A2@hxr.us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org A question regarding the charter: On 2007/01/05 18:01, Andrew Newton wrote: > > It is clear from discussions in both working groups that Multi-Media > Interconnection will require various forms of data to be exchanged among > administrative domains outside the normal scope of establishing a SIP > session. > > Such data exchanges might be provisioning of various forms of Registries > containing mappings of phone numbers to URI, policies surrounding the > admission to points of network interconnection and the distribution of > Registry data to various types of databases. Do I read this correctly that you want to include? * Carriers provisioning numbers into a peering fabric's DB (the "registry") * Redistribution of that DB into each carrier's real-time routing DB Do you also envision direct carrier<->carrier interactions without a third party acting as the registry? Or do you think that this will just be a special case? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uJN-0006Wy-4G; Fri, 05 Jan 2007 14:01:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uJL-0006Wk-Tf for peppermint@ietf.org; Fri, 05 Jan 2007 14:01:03 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2uJK-0004kv-GX for peppermint@ietf.org; Fri, 05 Jan 2007 14:01:03 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l05J0ob4024931; Fri, 5 Jan 2007 11:00:56 -0800 From: "Richard Shockey" To: "'Andrew Newton'" , "'Adam Uzelac'" Subject: RE: [PEPPERMINT] While we wait on the drafts Date: Fri, 5 Jan 2007 14:00:39 -0500 Message-ID: <01df01c730fb$cb8eb3c0$87201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accw9dRI+XTHlToJQ1yLxuYMjKDfhwABd/Mg In-Reply-To: <616C1097-57B9-4EDE-9A7A-7CAD0A0CF172@hxr.us> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: peppermint@ietf.org, 'David Schwartz' X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org > It is possible that both features could be achieved with the same > mechanism. > > >> What about a model that follows a "per query" methodology? There > >> would > >> be some minor upfront provisioning that would ensure that a > >> preexisting > >> contractual or trust relationship exists, but then query the > >> catalog of > >> your peers for reachability of the intended target. I realize > >> there are > >> scaling issues involved, but it's realistic that this model would > >> exist, > >> no? > > > > Of course .. some folks will not want to cache the catalog/registry > > and > > others will simply want a per dip model. The issue will be then > > what are the > > appropriate per dip query mechanisms and do we want to limit the > > scope of > > acceptable models limit discussion to just RFC 3761 (DNS) and SIP > > Redirect? > > I'd prefer we leave the actual mechanism for the query out of scope. Its certainly a topic for discussion but in principal I agree with you. > > -andy _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tdY-00074k-47; Fri, 05 Jan 2007 13:17:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tdX-00074T-4m for peppermint@ietf.org; Fri, 05 Jan 2007 13:17:51 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tdV-0001BO-Sx for peppermint@ietf.org; Fri, 05 Jan 2007 13:17:51 -0500 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 05 Jan 2007 13:17:17 -0500 id 015884BC.459E962D.00003542 In-Reply-To: <018801c730f0$cf7fc510$87201f0a@cis.neustar.com> References: <018801c730f0$cf7fc510$87201f0a@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <616C1097-57B9-4EDE-9A7A-7CAD0A0CF172@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [PEPPERMINT] While we wait on the drafts Date: Fri, 5 Jan 2007 13:17:45 -0500 To: Richard Shockey , Adam Uzelac X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: peppermint@ietf.org, David Schwartz X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org In-line... On Jan 5, 2007, at 12:42 PM, Richard Shockey wrote: > > NeuStar has not implemented 4114 for that matter though we have > implemented > EPP in our normal domain name registry operations. > > >> -----Original Message----- >> From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] >> >> Andy - If you are asking for a show of hands as to who has or hasn't >> implemented/deployed 4114 - you can put Global Crossing as a company >> that has NOT. I was. Thanks for understanding the obtuseness of the request. For the record, SunRocket has not implemented 4114 (we'd be doing client- side), but have given it consideration and would have implemented it if any of our partners had. >> As for the provisioning models that you put forth, is >> there not room for a hybrid environment? I think there has to be a >> combination of the 2 models to achieve a practical implementation. >> There must be an "entire catalog" download/upload to start before any >> delta model can be realized. But to do a full download of the >> catalog >> at a regular interval would be unruly. Yes, there is room for a hybrid model. But in Model 1, there is no exact need for a model 2 style start up. Startup is simply a truck- load of additions. However, I think it reasonable that normal operations would be model 1 and startup and checkpoints/resyncs would be model 2. > We would assume a incremental update of changes to the entire > cached catalog > " aka registry" would be a MUST. So why doesn't 4114 meet your needs? As far as MUST/SHOULD language goes, I'd like to see both models (and their hybrid) be a MUST implement. Must deploy is a different matter. And while I'm reciting my wish list, I'd like to see a couple of protocol features: Model 1 Transactions) It would be nice to group the deltas into discrete transactions, similar to SQL transactions. If one fails, they all fail. Model 2 Chunking) With a reasonably sized catalog, the number of octets in the catalog (especially if it uses XML) can get quite cumbersome. Typical octet counting mechanisms (such as EPP or plain HTTP POST) would then require an enormous buffer. It would be better if the catalog could be sent in chunks or different, sequential messages. It is possible that both features could be achieved with the same mechanism. >> What about a model that follows a "per query" methodology? There >> would >> be some minor upfront provisioning that would ensure that a >> preexisting >> contractual or trust relationship exists, but then query the >> catalog of >> your peers for reachability of the intended target. I realize >> there are >> scaling issues involved, but it's realistic that this model would >> exist, >> no? > > Of course .. some folks will not want to cache the catalog/registry > and > others will simply want a per dip model. The issue will be then > what are the > appropriate per dip query mechanisms and do we want to limit the > scope of > acceptable models limit discussion to just RFC 3761 (DNS) and SIP > Redirect? I'd prefer we leave the actual mechanism for the query out of scope. -andy _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t5W-0001Fb-WF; Fri, 05 Jan 2007 12:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t5V-0001FU-MV for peppermint@ietf.org; Fri, 05 Jan 2007 12:42:41 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2t5U-0000eR-6k for peppermint@ietf.org; Fri, 05 Jan 2007 12:42:41 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l05HgL4F008336; Fri, 5 Jan 2007 09:42:27 -0800 From: "Richard Shockey" To: "'Uzelac, Adam'" , "'Andrew Newton'" , Subject: RE: [PEPPERMINT] While we wait on the drafts Date: Fri, 5 Jan 2007 12:42:01 -0500 Message-ID: <018801c730f0$cf7fc510$87201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accw64syBzzSkqrtSb6S0TiBsiVqmgAAOILAAADiKIA= In-Reply-To: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: 'David Schwartz' X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org NeuStar has not implemented 4114 for that matter though we have implemented EPP in our normal domain name registry operations. > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, January 05, 2007 12:22 PM > To: Andrew Newton; peppermint@ietf.org > Cc: David Schwartz > Subject: RE: [PEPPERMINT] While we wait on the drafts > > Andy - If you are asking for a show of hands as to who has or hasn't > implemented/deployed 4114 - you can put Global Crossing as a company > that has NOT. As for the provisioning models that you put forth, is > there not room for a hybrid environment? I think there has to be a > combination of the 2 models to achieve a practical implementation. > There must be an "entire catalog" download/upload to start before any > delta model can be realized. But to do a full download of the catalog > at a regular interval would be unruly. We would assume a incremental update of changes to the entire cached catalog " aka registry" would be a MUST. > > What about a model that follows a "per query" methodology? There would > be some minor upfront provisioning that would ensure that a preexisting > contractual or trust relationship exists, but then query the catalog of > your peers for reachability of the intended target. I realize there are > scaling issues involved, but it's realistic that this model would exist, > no? Of course .. some folks will not want to cache the catalog/registry and others will simply want a per dip model. The issue will be then what are the appropriate per dip query mechanisms and do we want to limit the scope of acceptable models limit discussion to just RFC 3761 (DNS) and SIP Redirect? > > -AU > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Friday, January 05, 2007 12:04 PM > > To: peppermint@ietf.org > > Cc: David Schwartz > > Subject: [PEPPERMINT] While we wait on the drafts > > > > David Schwartz is producing an I-D with his take on > > requirements for a SIP peering provisioning protocol. And > > I've been told privately of one other in the works. But to > > get the discussions started, I'd like to share my > > observations in this space. > > > > As I stated in the SPEERMINT meeting in San Diego, there > > seems to be near zero deployment of RFC 4114. And almost > > every single time I've asked about it, the response has been > > "What is RFC 4114?" In the interest of understanding why RFC > > 4114 might not meet the requirements for SIP peering > > provisioning, how many people have implemented and/or > > deployed RFC 4114? > > > > From what I've seen with the proprietary solutions, there > > appear to be two different models used in the industry: > > > > Model 1) This is very similar to how RFC 4114 and EPP work, > > though the mechanisms differ (usually they are flat files > > sent using FTP). > > The exchange is all about deltas, any additions or deletions > > since the last transaction. > > > > Model 2) This is the "entire catalog" approach. In each > > transaction, every "address" (e.g. telephone # or SIP URI) is given. > > > > From a client perspective (or a provisioner's perspective... > > we need a term for that), model 2 is easier even though it > > obviously consumes more bandwidth. However, from the server > > perspective (or the provisionee's perspective... again, we > > need a term), I would think this is cumbersome, as the > > tracking of the changes occurs on that side of the > > transaction. When you extract the business considerations, > > tracking the changes may not be important... but we have to > > work within the confines of the real world here where > > charging, customer service, etc. do exist. > > > > The opposite is true for Model 1. More processing and > > attention must be paid by the client. > > > > And though Model 1 is similar in operation to EPP, EPP's > > genesis in the domain name space doesn't exactly make it a > > perfect fit for VSPs with multiple peers. In the > > registrar/registry domain name world of EPP, a registrar will > > only have one registry with which to provision any one > > instance of a domain name. In other words, a registry only > > ever deals with one registry when it must do something with > > "example.org". > > > > But for VSPs peered with multiple partners, this breaks down. > > Each "address" (again, a phone # or SIP URI or whatever) > > could be provisioned with each partner. This means deltas > > for each relationship must be tracked. > > > > Comments and opinions welcome.... > > > > -andy > > > > _______________________________________________ > > PEPPERMINT mailing list > > PEPPERMINT@ietf.org > > https://www1.ietf.org/mailman/listinfo/peppermint > > > > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www1.ietf.org/mailman/listinfo/peppermint _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t2I-0000Ts-RN; Fri, 05 Jan 2007 12:39:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t2H-0000Tj-B7 for peppermint@ietf.org; Fri, 05 Jan 2007 12:39:21 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2t2G-00059L-1N for peppermint@ietf.org; Fri, 05 Jan 2007 12:39:21 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 05 Jan 2007 12:38:49 -0500 id 015884B9.459E8D29.00002B35 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <035A6FCC-9D8F-49DA-AA44-266D60E469A2@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: peppermint@ietf.org From: Andrew Newton Date: Fri, 5 Jan 2007 12:39:16 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.6 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [PEPPERMINT] First pass at a BoF proposal X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org FYI... this is the preliminary BoF proposal that has been submitted. Peppermint BOF Provisioning Extensions in Peering Registries for Multimedia INTerconnection. Mailing Lists: BOF chairs: Andrew Newton [andy@hxr.us] Richard Shockey [rich.shockey@neustar.biz] Temporary Area Directorate: Real Time Applications (RAI) Ultimate Area Directorate: TBD BOF Purpose. The ENUM and SPEERMINT working groups are working on various aspects of Multi Media Interconnection. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across domain boundaries. It is clear from discussions in both working groups that Multi-Media Interconnection will require various forms of data to be exchanged among administrative domains outside the normal scope of establishing a SIP session. Such data exchanges might be provisioning of various forms of Registries containing mappings of phone numbers to URI, policies surrounding the admission to points of network interconnection and the distribution of Registry data to various types of databases. The purpose of the BOF is to determine the need and scope for such data exchanges, what existing protocols need to be adapted to meet those needs and the appropriate schema and queries are needed to facilitate such exchanges. The IETF has in the past done significant work on data exchanges among various administrative entities. In particular the PROVREG working group developed various schema and query mechanisms to facilitate the exchange of data among domain name registries and registrars. The ENUM Working group has adapted PROVREG working group protocols to develop RFC 4114, which facilitates the provisioning of ENUM data in the DNS tree. However, there has been little adoption of RFC 4114, and many of the participants of the SPEERMINT working group require both data models and protocol features not found in RFC 4114. The proposed PEPPERMINT working group will build upon the knowledge gained from those efforts, and the intent of this proposed working group is to find a provisioning solution for peering as defined by SPEERMINT. The final work product(s) from this working group will be based upon XML. Additionally, bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or HTTP/SOAP. Proposed Deliverables Requirements for SPEERMINT data exchange. Provisioning of SPEERMINT data registries. Provisioning of SPEERMINT/ENUM data caches. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2smC-0001ym-Ou; Fri, 05 Jan 2007 12:22:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2smB-0001yb-Hg for peppermint@ietf.org; Fri, 05 Jan 2007 12:22:43 -0500 Received: from unknown-141-roc.globalcrossing.com ([209.130.177.141] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2smA-0003eQ-7C for peppermint@ietf.org; Fri, 05 Jan 2007 12:22:43 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id DA21AE96D9; Fri, 5 Jan 2007 12:22:35 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 12:22:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PEPPERMINT] While we wait on the drafts Date: Fri, 5 Jan 2007 12:22:27 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] While we wait on the drafts Thread-Index: Accw64syBzzSkqrtSb6S0TiBsiVqmgAAOILA From: "Uzelac, Adam" To: "Andrew Newton" , X-OriginalArrivalTime: 05 Jan 2007 17:22:35.0787 (UTC) FILETIME=[177E95B0:01C730EE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: David Schwartz X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org Andy - If you are asking for a show of hands as to who has or hasn't implemented/deployed 4114 - you can put Global Crossing as a company that has NOT. As for the provisioning models that you put forth, is there not room for a hybrid environment? I think there has to be a combination of the 2 models to achieve a practical implementation. There must be an "entire catalog" download/upload to start before any delta model can be realized. But to do a full download of the catalog at a regular interval would be unruly. =20 What about a model that follows a "per query" methodology? There would be some minor upfront provisioning that would ensure that a preexisting contractual or trust relationship exists, but then query the catalog of your peers for reachability of the intended target. I realize there are scaling issues involved, but it's realistic that this model would exist, no? -AU > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Friday, January 05, 2007 12:04 PM > To: peppermint@ietf.org > Cc: David Schwartz > Subject: [PEPPERMINT] While we wait on the drafts >=20 > David Schwartz is producing an I-D with his take on=20 > requirements for a SIP peering provisioning protocol. And=20 > I've been told privately of one other in the works. But to=20 > get the discussions started, I'd like to share my=20 > observations in this space. >=20 > As I stated in the SPEERMINT meeting in San Diego, there=20 > seems to be near zero deployment of RFC 4114. And almost=20 > every single time I've asked about it, the response has been=20 > "What is RFC 4114?" In the interest of understanding why RFC=20 > 4114 might not meet the requirements for SIP peering=20 > provisioning, how many people have implemented and/or=20 > deployed RFC 4114? >=20 > From what I've seen with the proprietary solutions, there=20 > appear to be two different models used in the industry: >=20 > Model 1) This is very similar to how RFC 4114 and EPP work,=20 > though the mechanisms differ (usually they are flat files=20 > sent using FTP). =20 > The exchange is all about deltas, any additions or deletions=20 > since the last transaction. >=20 > Model 2) This is the "entire catalog" approach. In each=20 > transaction, every "address" (e.g. telephone # or SIP URI) is given. >=20 > From a client perspective (or a provisioner's perspective...=20 > we need a term for that), model 2 is easier even though it=20 > obviously consumes more bandwidth. However, from the server=20 > perspective (or the provisionee's perspective... again, we=20 > need a term), I would think this is cumbersome, as the=20 > tracking of the changes occurs on that side of the=20 > transaction. When you extract the business considerations,=20 > tracking the changes may not be important... but we have to=20 > work within the confines of the real world here where=20 > charging, customer service, etc. do exist. >=20 > The opposite is true for Model 1. More processing and=20 > attention must be paid by the client. >=20 > And though Model 1 is similar in operation to EPP, EPP's=20 > genesis in the domain name space doesn't exactly make it a=20 > perfect fit for VSPs with multiple peers. In the=20 > registrar/registry domain name world of EPP, a registrar will=20 > only have one registry with which to provision any one=20 > instance of a domain name. In other words, a registry only=20 > ever deals with one registry when it must do something with=20 > "example.org". >=20 > But for VSPs peered with multiple partners, this breaks down.=20 > Each "address" (again, a phone # or SIP URI or whatever)=20 > could be provisioned with each partner. This means deltas=20 > for each relationship must be tracked. >=20 > Comments and opinions welcome.... >=20 > -andy >=20 > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www1.ietf.org/mailman/listinfo/peppermint >=20 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sU9-000208-Vi; Fri, 05 Jan 2007 12:04:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sU9-000202-4S for peppermint@ietf.org; Fri, 05 Jan 2007 12:04:05 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2sU7-00021F-Pp for peppermint@ietf.org; Fri, 05 Jan 2007 12:04:05 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 05 Jan 2007 12:03:22 -0500 id 015884C6.459E84DA.000021B2 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Fri, 5 Jan 2007 12:03:47 -0500 To: peppermint@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: David Schwartz Subject: [PEPPERMINT] While we wait on the drafts X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org David Schwartz is producing an I-D with his take on requirements for a SIP peering provisioning protocol. And I've been told privately of one other in the works. But to get the discussions started, I'd like to share my observations in this space. As I stated in the SPEERMINT meeting in San Diego, there seems to be near zero deployment of RFC 4114. And almost every single time I've asked about it, the response has been "What is RFC 4114?" In the interest of understanding why RFC 4114 might not meet the requirements for SIP peering provisioning, how many people have implemented and/or deployed RFC 4114? From what I've seen with the proprietary solutions, there appear to be two different models used in the industry: Model 1) This is very similar to how RFC 4114 and EPP work, though the mechanisms differ (usually they are flat files sent using FTP). The exchange is all about deltas, any additions or deletions since the last transaction. Model 2) This is the "entire catalog" approach. In each transaction, every "address" (e.g. telephone # or SIP URI) is given. From a client perspective (or a provisioner's perspective... we need a term for that), model 2 is easier even though it obviously consumes more bandwidth. However, from the server perspective (or the provisionee's perspective... again, we need a term), I would think this is cumbersome, as the tracking of the changes occurs on that side of the transaction. When you extract the business considerations, tracking the changes may not be important... but we have to work within the confines of the real world here where charging, customer service, etc. do exist. The opposite is true for Model 1. More processing and attention must be paid by the client. And though Model 1 is similar in operation to EPP, EPP's genesis in the domain name space doesn't exactly make it a perfect fit for VSPs with multiple peers. In the registrar/registry domain name world of EPP, a registrar will only have one registry with which to provision any one instance of a domain name. In other words, a registry only ever deals with one registry when it must do something with "example.org". But for VSPs peered with multiple partners, this breaks down. Each "address" (again, a phone # or SIP URI or whatever) could be provisioned with each partner. This means deltas for each relationship must be tracked. Comments and opinions welcome.... -andy _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2H5s-0007Jy-Se; Wed, 03 Jan 2007 20:08:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2H5r-0007Jt-VX for peppermint@ietf.org; Wed, 03 Jan 2007 20:08:31 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2H5p-00050S-Ju for peppermint@ietf.org; Wed, 03 Jan 2007 20:08:31 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l0418Sej021454 for ; Wed, 3 Jan 2007 17:08:33 -0800 From: "Richard Shockey" To: Date: Wed, 3 Jan 2007 20:08:16 -0500 Message-ID: <004b01c72f9c$d1ca7ae0$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccvnNATBmuNcB/DQIWFHtoUZgVNJw== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 2.4 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [PEPPERMINT] test X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org test Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint