From speermint-bounces@ietf.org Wed Jan 03 17:23:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EVR-0002yZ-Up; Wed, 03 Jan 2007 17:22:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EVQ-0002yP-DJ; Wed, 03 Jan 2007 17:22:44 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2EVO-0007Ko-55; Wed, 03 Jan 2007 17:22: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, 03 Jan 2007 17:21:56 -0500 id 0158845C.459C2C84.00001B32 In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A6065501C086A4@isr-jlm-mail.Kayote.com> References: <1DDB0D3CC4E7F14FAE946361C0A6065501C086A4@isr-jlm-mail.Kayote.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C026ED6-14B5-4064-AD46-11E98A247775@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] FW: Preliminary BOF proposals due soon Date: Wed, 3 Jan 2007 17:22:19 -0500 To: speermint@ietf.org, enum@ietf.org, ietf-provreg@cafax.se X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: David Schwartz , Jon Peterson X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Alright, now that the holidays are over it is time to get moving on SIP peering provisioning. We have requested and received an ietf.org mailing list for PEPPERMINT. The list info can be found here: https://www1.ietf.org/mailman/listinfo/peppermint A BoF proposal is forthcoming in a day or two. -andy On Dec 19, 2006, at 11:26 AM, David Schwartz wrote: > I am 85% finished on an a draft describing requirements we have > accumulated at XConnect. Hope to have this out by the end of the year. > > David > > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Tuesday, December 19, 2006 5:38 PM > To: 'Andrew Newton'; 'Livingood, Jason'; 'David Meyer'; > speermint@ietf.org > Cc: 'RAI ADs' > Subject: [Speermint] FW: Preliminary BOF proposals due soon > > > > Andrew Newton and I will be proposing a BOF on SPEERMINT Provisioning > issues > for IETF 68 in Prague. > > If anyone has topic or is considering producing drafts related to > provisioning issues please let Andy or I know. > >> -----Original Message----- >> From: IETF Chair [mailto:chair@ietf.org] >> Sent: Tuesday, December 19, 2006 3:39 AM >> To: IETF Announcement list >> Subject: Preliminary BOF proposals due soon >> >> As for the previous IETF, we're asking for preliminary BOF proposals > to be >> sent to the appropriate Area Director a little earlier, by January >> 15. >> Even sooner would be better! >> >> Full list of dates: >> http://www.ietf.org/meetings/68-cutoff_dates.html >> >> BOF wiki: >> http://www1.tools.ietf.org/bof/trac/wiki >> >> Hints: >> http://tools.ietf.org/html/draft-narten-successful-bof >> >> Brian Carpenter >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 08 17:28:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42xt-0002co-Jd; Mon, 08 Jan 2007 17:27:37 -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 Cc: speermint@ietf.org, peppermint@ietf.org Subject: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C73374.318D16EB-- From speermint-bounces@ietf.org Tue Jan 09 06:23:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4F47-00068x-Jm; 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 Subject: Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt 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 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 09 09:30:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4HzD-00025M-4k; Tue, 09 Jan 2007 09:29:59 -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'" Subject: RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt 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 Cc: speermint@ietf.org, peppermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 09 10:09:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ibi-0001de-VA; Tue, 09 Jan 2007 10:09:46 -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 Subject: RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt 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 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 10 13:13:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hwL-00064e-AM; 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 Subject: Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt 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 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Jan 13 13:26:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5nZi-0006ei-8A; Sat, 13 Jan 2007 13:25:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5aVu-0005tc-LS; Fri, 12 Jan 2007 23:29:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5aVs-0002bo-Bi; Fri, 12 Jan 2007 23:29:06 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2007 20:29:03 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0D4T2Ia012932; Fri, 12 Jan 2007 20:29:02 -0800 Received: from [192.168.1.9] (sjc-vpn7-387.cisco.com [10.21.145.131]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0D4T2nF020709; Fri, 12 Jan 2007 20:29:02 -0800 (PST) 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: rai@ietf.org, avt@ietf.org, ECRIT , enum@ietf.org, mmusic@ietf.org, sigtran@ietf.org, simple@ietf.org, geopriv@ietf.org, ieprep@ietf.org, SIP , sipping@ietf.org, speechsc@ietf.org, speermint@ietf.org, xcon@ietf.org, RAI Chairs , RAI Discuss From: Cullen Jennings Date: Fri, 12 Jan 2007 20:28:52 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=484; t=1168662542; x=1169526542; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20New=20RAI=20mailing=20list=20formed |Sender:=20; bh=oy9hMDTAd3CLwx2VjaSlGDIiUGc4zeKQTh4WxAq1xfU=; b=nzE6bx99AfmpN9XXdKKYeMzdSrPYLU0XznGtkrDuKY24XeITEuEnaaVR9hz7VFmVb9njtbTr 5VVkwN8evTl13ZapqifDuRHeokxVdDOoFkvhoDOAduovqFL7TFD5fRZC; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Sat, 13 Jan 2007 13:25:53 -0500 Cc: Subject: [Speermint] New RAI mailing list formed X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Please don't reply to this message so you don't cross post to all the groups. A new mailing list for announcement and discussion of general topics of interest to RAI Area has been created. The list is rai@ietf.org You can subscribe at: https://www1.ietf.org/mailman/listinfo/rai Or by sending email with a body containing "subscribe" to rai- request@ietf.org Please do subscribe to it so you can find announcements for things like RAI BOFs. Thanks, Cullen & Jon _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 15 13:10:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6WGx-0007MH-3b; Mon, 15 Jan 2007 13:09:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6WGw-0007M7-8U for speermint@ietf.org; Mon, 15 Jan 2007 13:09:30 -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 1H6WGk-0004rP-Jj for speermint@ietf.org; Mon, 15 Jan 2007 13:09:30 -0500 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.29528061; Mon, 15 Jan 2007 13:08:55 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 13:08:55 -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, 15 Jan 2007 13:08:55 -0500 Message-ID: <45AEC6EF95942140888406588E1A66025AC0B0@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Definition: PSP Thread-Index: Acc2ivFTR42ySufkT5qUgPj1nOk0jgBWVDpgADqnFpA= From: "Livingood, Jason" To: X-OriginalArrivalTime: 15 Jan 2007 18:08:55.0340 (UTC) FILETIME=[385E36C0:01C738D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Speermint] New Definition: PSP X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org All - David has proposed adding some text to the Terminology draft (see below). If anyone has proposed changes to this text, please discuss/propose here. Thanks! Jason=20 ________________________________ From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 Sent: Sunday, January 14, 2007 9:18 AM To: Livingood, Jason Cc: David Meyer Subject: RE: San Diego Notes Hi Jason - thanks for the reminder. Here is my take on it... "A Peering Service Provider (or PSP) is an entity that facilitates inter-VSP communication though implementation of peering functions, either directly or indirectly, on behalf of VSPs. This set of functions defines the peering policy dimensions available to the VSPs and may include location, interoperability, security, trust, routing and cost management." Cheers, David ________________________________ From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Friday, January 12, 2007 10:48 PM To: David Schwartz Cc: David Meyer Subject: San Diego Notes David - I was going through my notes from San Diego and see that you suggested we needed a new term, Peering Services Provider, and that you volunteered to submit this text to Dave. I also noted that you said that a PSP and a VSP were not mutually exclusive, if that helps. If you'd like to suggest the addition of this term, I suggest you do so ASAP as we'd like to close the terminology draft. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 22 07:36:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8yPF-0002FO-O1; 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 Subject: RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt 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 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 22 08:08:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8yts-0007Oa-4C; 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 Subject: RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt 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 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 22 16:57:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H97A8-0004xH-GY; Mon, 22 Jan 2007 16:57:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H97A7-0004xC-S9 for speermint@ietf.org; Mon, 22 Jan 2007 16:57:11 -0500 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H97A5-0002s8-Hv for speermint@ietf.org; Mon, 22 Jan 2007 16:57:11 -0500 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l0MLuxLT029441 for ; Mon, 22 Jan 2007 21:57:00 GMT Subject: [Speermint] Policies...policies...policies From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Mon, 22 Jan 2007 15:04:47 -0700 Message-Id: <1169503488.17141.28.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Okay, so in San Diego, I was asked, again, to put together a draft on policies, more specifically, the Policy Function. Since, I introduced the Policy Function in the original architecture, I heartily agreed. Recently, I decided to spend some time seriously putting this draft together. First, I spent several hours attempting to identify the problem I was going to solve by writing this draft....then several more hours...then a couple more. I re-wrote the abstract several times over, and made it about as far as the introduction. To be honest, I think the Policy Function is still a reasonable idea; however, I do not think there are currently any problems, which can be solved by it. Instead of trying to create a problem, and then write a solution to that problem; I would like to suggest this idea is put on hold. Through my toiling over potential problems, I came up with a list of policies that might be necessarily solved by some dynamic mechanism: Session limits - A peer may want to notify another peer of the number of sessions compared with a limit defined by a policy; in the same way, a peer may request an update as to the number of sessions compared to the limit. Assuming this truly is a problem (which I can debate with myself on), I think this is a potential general SIP issue, and an event package should possibly be introduced in relation to the Overload work being done in SIPPING. ...this should not be addressed here. LF Route changes - A peer may want to update IP addresses associated with it's AoR for peering on an LF. The LF would subscribe to the PF for a "route-modify" event package. First, I don't think this is necessary. The only SIP case would be while utilizing a redirect server, so this would be potentially introduced as a SIP event package and not a SPEERMINT issue. Since, the preferred routing mechanism is ENUM (or other), I think this would be solving a "maybe" problem on a "yesterday" routing method. Second, utilizing ENUM, this would be a DNS change and completely outside the scope of SIP. All other policy cases, would almost always be resolved through "paper" negotiations and have nothing to do with SPEERMINT introducing any new functions or dynamic methodologies. Also, I couldn't think of any specific peering policies, which aren't already negotiated by every SIP/telecom vendor when setting up a new service agreement. So, this would be restating the obvious...is that necessary. So, my thought is....I came up with the idea of a Policy Function, and right now; I think it is a dumb idea. At some point down the road, it may be necessary...and if/when we come to that, maybe I'll write a draft on it. Until then, I agree with the WG chairs, this simply is unnecessary. Thoughts? --Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 25 16:34:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HACE4-0007nD-Uw; Thu, 25 Jan 2007 16:33:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HACE3-0007n6-G5 for speermint@ietf.org; Thu, 25 Jan 2007 16:33:43 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HACE2-0005id-6N for speermint@ietf.org; Thu, 25 Jan 2007 16:33: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 Subject: RE: [Speermint] Policies...policies...policies Date: Thu, 25 Jan 2007 16:33:24 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3B9DC@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policies...policies...policies Thread-Index: Acc+cIEj274L4WD/RdikHXwWXs9YFwCV55iA From: "Livingood, Jason" To: "Daryl Malas" , X-OriginalArrivalTime: 25 Jan 2007 21:33:24.0463 (UTC) FILETIME=[71774FF0:01C740C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sounds good & your suggestion is accepted. I applaud you for saying you don't think work is needed as well, that is not always the case. I think we will end up owing you a beer in Prague given the time you put into it. ;-) Jason=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Monday, January 22, 2007 5:05 PM > To: speermint@ietf.org > Subject: [Speermint] Policies...policies...policies >=20 > Okay, so in San Diego, I was asked, again, to put together a=20 > draft on policies, more specifically, the Policy Function. =20 > Since, I introduced the Policy Function in the original=20 > architecture, I heartily agreed. > Recently, I decided to spend some time seriously putting this=20 > draft together. First, I spent several hours attempting to=20 > identify the problem I was going to solve by writing this=20 > draft....then several more hours...then a couple more. I=20 > re-wrote the abstract several times over, and made it about=20 > as far as the introduction. >=20 > To be honest, I think the Policy Function is still a=20 > reasonable idea; however, I do not think there are currently=20 > any problems, which can be solved by it. Instead of trying=20 > to create a problem, and then write a solution to that=20 > problem; I would like to suggest this idea is put on hold. >=20 > Through my toiling over potential problems, I came up with a=20 > list of policies that might be necessarily solved by some=20 > dynamic mechanism: >=20 > Session limits - A peer may want to notify another peer of=20 > the number of sessions compared with a limit defined by a=20 > policy; in the same way, a peer may request an update as to=20 > the number of sessions compared to the limit. Assuming this=20 > truly is a problem (which I can debate with myself on), I=20 > think this is a potential general SIP issue, and an event=20 > package should possibly be introduced in relation to the=20 > Overload work being done in SIPPING. ...this should not be=20 > addressed here. >=20 > LF Route changes - A peer may want to update IP addresses=20 > associated with it's AoR for peering on an LF. The LF would=20 > subscribe to the PF for a "route-modify" event package. =20 > First, I don't think this is > necessary. The only SIP case would be while utilizing a redirect > server, so this would be potentially introduced as a SIP=20 > event package and not a SPEERMINT issue. Since, the=20 > preferred routing mechanism is ENUM (or other), I think this=20 > would be solving a "maybe" problem on a "yesterday" routing=20 > method. Second, utilizing ENUM, this would be a DNS change=20 > and completely outside the scope of SIP. >=20 > All other policy cases, would almost always be resolved=20 > through "paper" > negotiations and have nothing to do with SPEERMINT=20 > introducing any new functions or dynamic methodologies. =20 > Also, I couldn't think of any specific peering policies,=20 > which aren't already negotiated by every SIP/telecom vendor=20 > when setting up a new service agreement. So, this would be=20 > restating the obvious...is that necessary. >=20 > So, my thought is....I came up with the idea of a Policy=20 > Function, and right now; I think it is a dumb idea. At some=20 > point down the road, it may be necessary...and if/when we=20 > come to that, maybe I'll write a draft on it. Until then, I=20 > agree with the WG chairs, this simply is unnecessary. >=20 > Thoughts? >=20 > --Daryl=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 26 09:52:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASQY-0008Id-Kx; Fri, 26 Jan 2007 09:51:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASQW-0008IQ-R5 for speermint@ietf.org; Fri, 26 Jan 2007 09:51:40 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASQV-0008EV-DY for speermint@ietf.org; Fri, 26 Jan 2007 09:51:40 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l0QEpcPO028930 for ; Fri, 26 Jan 2007 06:51:38 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l0QEpcI5028929 for speermint@ietf.org; Fri, 26 Jan 2007 06:51:38 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 26 Jan 2007 06:51:38 -0800 From: David Meyer To: speermint@ietf.org Message-ID: <20070126145138.GA28915@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Speermint] FYI -- Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0082626486==" Errors-To: speermint-bounces@ietf.org --===============0082626486== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: ietf-secretariat@ietf.org Date: January 25, 2007 9:00:02 PM PST To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF =20 Meeting in Prague, Czech Republic There are two (2) Internet-Draft cutoff dates for the 68th IETF Meeting in Prague, Czech Republic: February 26th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 26th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 19th at 9:00 AM ET. March 5th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, March 5th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 19th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant =20 dates for the 68th IETF Meeting can be found at http://www.ietf.org/=20 meetings/cutoff_dates_68.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFuhV6ORgD1qCZ2KcRAnvaAJ4sWFukW4rjU0rE2q9mVrCLjJK/xACcDXOy 8xVN/XvLk9lX17jayoORVEs= =CcZ0 -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- --===============0082626486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0082626486==-- From speermint-bounces@ietf.org Fri Jan 26 16:08:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYI1-0006DJ-1H; Fri, 26 Jan 2007 16:07:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYHz-0006Cx-7R for speermint@ietf.org; Fri, 26 Jan 2007 16:07:15 -0500 Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAYHw-0007W1-G3 for speermint@ietf.org; Fri, 26 Jan 2007 16:07:15 -0500 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l0QL7A703652 for ; Fri, 26 Jan 2007 16:07:10 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007012616072815151 for ; Fri, 26 Jan 2007 16:07:28 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Jan 2007 16:07:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 26 Jan 2007 16:07:30 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Directory assistance draft/peering for services Thread-Index: AcdBjf17qYnzfr1SR4ukhhdR6ZT1ZA== From: "Haluska, John J" To: X-OriginalArrivalTime: 26 Jan 2007 21:07:29.0522 (UTC) FILETIME=[FD0FE520:01C7418D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Subject: [Speermint] Directory assistance draft/peering for services X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0956712750==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0956712750== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7418E.03661DD2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7418E.03661DD2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hello all,=20 =20 I am seeking comments on draft-haluska-sipping-directory-assistance-01.txt, which I've already posted to the SIPPING ML and gotten some comments on. I was thinking that the SPEERMINT WG might have the expertise to help answer some specific questions I have, and perhaps for general comments as well. =20 First, to make a long story short, what this draft is basically trying to accomplish is to specify how existing SIP mechanisms can be used to implement Information Services, which include Directory Assistance. This would promote interoperability, would facilitate connectivity via SIP as an alternative to TDM, and would facilitate the development of more advanced services.=20 =20 Why post this to SPEERMINT? DA services are often provided as a wholesale service, and therefore calls could potentially traverse multiple providers between the caller and the DA provider. The DA provider needs to know the identities of at least the caller's "home provider" and the "last-hop" provider before the DA provider. These are used to influence call processing (e.g. branded services/announcements) in a number of ways, as well as to facilitate accounting. I am thinking that providers involved in peering might have reasons to care about the various providers a call may have traversed. =20 1. Currently, the draft specifies that the "home provider" would insert a P-Asserted-Identity header using the domain-name format, so that the home provider's identity could determined from the domain name. Assuming that the providers involved agree, does this seem reasonable? This seems to make sense, especially given the fact that SBCs can break SIP Identity, as pointed out in the recent SIP identity coexistence draft. =20 2. For the "last-hop" provider, we are specifying that the DA provider would keep a list of values of "Via" headers from boxes from which it would expect to receive calls, so that based on the Via value we can determine who sent in the call. =20 3. We are thinking it might be necessary to know the identity of some other providers which are neither the home provider nor the last-hop, and thinking that SIP History-Info could be used for this. =20 Has anyone encountered the need to do this in a peering environment, or otherwise? =20 Does the use of SIP History-Info for this seem appropriate? =20 Does this seem like it would be generally useful for SPEERMINT? =20 =20 =20 4. The DA provider needs to know the calling terminal's capabilities and characteristics, so it would know whether sending e.g. a text message or initiating a multimedia session (e.g. to play a video clip) is possible. For identifying the caller's terminal capabilities and characteristics, we plan to specify the use of RFC 3840 (indicating UA capabilities in SIP) when it is supported - it is not in the current revision of the draft. Where it is not supported, the session either needs to do without this information, or some lookup (e.g. HSS in an IMS environment) could be done. =20 =20 5. In addition to these questions, I've been wondering whether anyone has thought about how the SPEERMINT architecture might be used for peering for the purpose of providing services, rather than only for providing call terminations? I'm wondering how well something like this would mesh with/benefit from what the SPEERMINT WG is trying to do. If some arrangement existed whereby many VSPs might be served by multiple DA providers (or providers of other types of services), then something more complex than simple bilateral agreements would be needed.=20 =20 Note that in a thread on the SIPPING ML (between 9 Jan and 15 Jan 2007) there seemed to be some recognition that at least some of what's in the draft might be more widely applicable than just this service.=20 =20 Note that we do plan to reduce the scope of the draft in the next revision - it will not normatively define an architecture (it will still describe one for the purposes of discussion) and concentrate more on identifying existing SIP mechanisms for conveying the required information, and will include additional call flows.=20 =20 =20 Thanks much =20 =20 John Haluska ------_=_NextPart_001_01C7418E.03661DD2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Hello all,

 

I  am seeking comments on draft-haluska-sipping-directory-assistance-01.txt, which I’ve = already posted to the SIPPING ML and gotten some comments on. I was thinking = that the SPEERMINT WG might have the expertise to help answer some specific = questions I have, and perhaps for general comments as = well.

 

First, to make a long story short, what this draft is basically trying to accomplish is to specify how existing SIP mechanisms = can be used to implement Information Services, which include Directory = Assistance. This would promote interoperability, would facilitate connectivity via = SIP as an alternative to TDM, and would facilitate the development of more = advanced services.

 

Why post this to SPEERMINT? DA services are often = provided as a wholesale service, and therefore calls could potentially traverse = multiple providers between the caller and the DA provider. The DA provider needs = to know the identities of at least the caller’s “home = provider” and the “last-hop” provider before the DA provider. These are = used to influence call processing (e.g. branded services/announcements) in a = number of ways, as well as to facilitate accounting. I am thinking that providers involved in peering might have reasons to care about the various = providers a call may have traversed.

 

1. Currently, the draft specifies that the = “home provider” would insert a P-Asserted-Identity header using the = domain-name format, so that the home provider’s identity could determined from = the domain name.  Assuming that the providers involved agree, does this = seem reasonable? This seems to make sense, especially given the fact that = SBCs can break SIP Identity, as pointed out in the recent SIP identity = coexistence draft.

 

2. For the “last-hop” provider, we are specifying that the DA provider would keep a list of values of “Via” headers from boxes from which it would expect to = receive calls, so that based on the Via value we can determine who sent in the = call.

 

3. We are thinking it might be necessary to know the identity of some other providers which are neither the home provider nor = the last-hop, and thinking that SIP History-Info could be used for = this.

 

         =    Has anyone encountered the need to do this in a peering environment, or otherwise?

 

         =    Does the use of SIP History-Info for this seem = appropriate?

 

         =    Does this seem like it would be generally useful for = SPEERMINT?

 

 

 

4. The DA provider needs to know the calling terminal’s capabilities and characteristics, so it  would = know whether sending e.g. a text message or initiating a multimedia session = (e.g. to play a video clip) is possible. For identifying the caller’s = terminal capabilities and characteristics, we plan to specify  the use of = RFC 3840 (indicating UA capabilities in SIP) when it is supported – it is = not in the current revision of the draft. Where it is not supported, the = session either needs to do without this information, or some lookup (e.g. HSS in an  IMS environment) could be done.

 

 

5. In addition to these questions, I’ve been = wondering whether anyone has thought about how the SPEERMINT architecture might be = used for peering for the purpose of providing services, rather than only for providing call terminations?  I’m wondering how well = something like this would mesh with/benefit from what the SPEERMINT WG is trying to do. = If some arrangement existed whereby many  VSPs might be served by = multiple DA providers (or providers of other types of services), then something more complex than simple bilateral agreements would be needed. =

 

Note that in a thread on the SIPPING ML (between 9 = Jan and 15 Jan 2007) there seemed to be some recognition that at least some of what’s in the draft might be more widely applicable than just this service.

 

Note that we do plan to reduce the scope of the draft = in the next revision – it will not normatively define an architecture (it = will still describe one for the purposes of discussion) and concentrate more = on identifying existing SIP mechanisms for conveying the required = information, and will include additional call flows.

 

 

Thanks much

 

 

John Haluska

------_=_NextPart_001_01C7418E.03661DD2-- --===============0956712750== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0956712750==-- From speermint-bounces@ietf.org Sun Jan 28 23:41:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBOJY-0001uL-Pi; Sun, 28 Jan 2007 23:40:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBOJX-0001qm-19 for speermint@ietf.org; Sun, 28 Jan 2007 23:40:19 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBOJR-0006xD-Qg for speermint@ietf.org; Sun, 28 Jan 2007 23:40:19 -0500 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.29780107; Sun, 28 Jan 2007 23:39:52 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Jan 2007 23:39:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 28 Jan 2007 23:39:51 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602C9A8B6@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Agenda Items - IETF-68 - Prague Thread-Index: AcdDK/NzfFADB2auRlCy79thm0/ChQ== From: "Livingood, Jason" To: X-OriginalArrivalTime: 29 Jan 2007 04:39:52.0312 (UTC) FILETIME=[84407780:01C7435F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Speermint] Call for Agenda Items - IETF-68 - Prague X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1764351060==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1764351060== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7435F.83F8D786" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7435F.83F8D786 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please send Dave and I any requested items for the agenda. If there are any new drafts or other work you would like to see on the agenda, please advise. =20 We should have updated milestones to discuss on the list soon - working them out with the ADs now. This will be part of any overall revised view of how to make progress with our work. =20 Regards Jason ------_=_NextPart_001_01C7435F.83F8D786 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please = send Dave and=20 I any requested items for the agenda.  If there are any new drafts = or other=20 work you would like to see on the agenda, please = advise.
 
We = should have=20 updated milestones to discuss on the list soon - working them out with = the ADs=20 now.  This will be part of any overall revised view of how to make = progress=20 with our work.
 
Regards
Jason
------_=_NextPart_001_01C7435F.83F8D786-- --===============1764351060== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1764351060==-- From speermint-bounces@ietf.org Mon Jan 29 16:16:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdqe-0001Sa-Oi; 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: [Speermint] FYI - -D ACTION:draft-newton-peppermint-problem-statement-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------=_NextPart_000_0111_01C743C0.A47DACF0--