From speermint-bounces@ietf.org Wed Mar 01 09:04:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERw1-0007uq-L4; Wed, 01 Mar 2006 09:04:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERvz-0007uM-Id for speermint@ietf.org; Wed, 01 Mar 2006 09:04:07 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERvz-0006kv-ET for speermint@ietf.org; Wed, 01 Mar 2006 09:04:07 -0500 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FERvw-0003fW-Lo for speermint@ietf.org; Wed, 01 Mar 2006 09:04:07 -0500 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id 2B23684E810 for ; Wed, 1 Mar 2006 14:04:02 +0000 (UTC) Received: from mail70-ash-R.bigfish.com (unknown [172.18.2.1]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id 2977084E5E5 for ; Wed, 1 Mar 2006 14:04:02 +0000 (UTC) Received: from mail70-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail70-ash-R.bigfish.com (Postfix) with ESMTP id 2000A46E992 for ; Wed, 1 Mar 2006 14:04:02 +0000 (UTC) X-BigFish: V Received: by mail70-ash (MessageSwitch) id 1141221841912214_6073; Wed, 1 Mar 2006 14:04:01 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail70-ash.bigfish.com (Postfix) with ESMTP id B71D546E559 for ; Wed, 1 Mar 2006 14:04:01 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k21E41MX027031 for ; Wed, 1 Mar 2006 08:04:01 -0600 (CST) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k21E41903113 for ; Wed, 1 Mar 2006 08:04:01 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 08:03:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C63D38.FB86DC69" Date: Wed, 1 Mar 2006 08:03:56 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E05C8F54F@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: A New Draft for SPEERMINT Thread-Index: AcY41HZUnoDhKKFQTHiKDUYTPXqQbAACD6sgARbO1CA= From: "Khan, Sohel Q [CTO]" To: X-OriginalArrivalTime: 01 Mar 2006 14:03:59.0972 (UTC) FILETIME=[FD0F0240:01C63D38] X-Spam-Score: -2.6 (--) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Subject: [Speermint] A New Draft for SPEERMINT 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_01C63D38.FB86DC69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I submitted a new draft (draft-khan-ip-serv-peer-arch-00.txt) titled "IP Service (Voice and Multimedia) Peering Architecture" for the SPEERMINT. This is a first version of the draft. The draft represents my opinion only; I would adjust the draft as per your comments and suggestions. I do not know whether I will be able to present the draft in Dallas. The draft will be posted in IETF before Dallas meeting. Enclosed please find the draft. Thank you, Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel ------_=_NextPart_001_01C63D38.FB86DC69 Content-Type: text/plain; name="draft-khan-ip-serv-peer-arch-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-khan-ip-serv-peer-arch-00.txt Content-Disposition: attachment; filename="draft-khan-ip-serv-peer-arch-00.txt" DQpTcGVlcm1pbnQgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTb2hlbCBLaGFuLCBTcHJpbnQNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYi4gMjYsIDMwMDYNCkV4cGlyZXM6IEF1Z3Vz dCAyNiwgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAkJCQkgICAgCSAgICAgIA0KDQpJUCBTZXJ2aWNlIChW b2ljZSBhbmQgTXVsdGltZWRpYSkgUGVlcmluZyBBcmNoaXRlY3R1cmUgDQogICAgICAgICAgICAg ICAgZHJhZnQta2hhbi1pcC1zZXJ2LXBlZXItYXJjaC0wMC50eHQNCg0KU3RhdHVzIG9mIHRoaXMg TWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBzdWJq ZWN0IHRvIGFsbCBwcm92aXNpb25zDQogICBvZiBzZWN0aW9uIDMgb2YgUkZDIDM2NjcuICBCeSBz dWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2gNCiAgIGF1dGhvciByZXByZXNlbnRz IHRoYXQgYW55IGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2YNCiAgIHdo aWNoIGhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFu ZCBhbnkgb2YNCiAgIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWUgYXdhcmUgd2lsbCBiZSBkaXNjbG9z ZWQsIGluIGFjY29yZGFuY2Ugd2l0aA0KICAgUkZDIDM2NjguDQoNCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90 ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcw0KICAgSW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBt YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg YXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8x aWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93 IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBdWd1 c3QgMjYsIDIwMDYuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUg SW50ZXJuZXQgU29jaWV0eSAoMjAwNikuIA0KDQpJbnRlbGxlY3R1YWwgcHJvcGVydHkgcmlnaHRz IChJUFIpIHN0YXRlbWVudA0KDQpCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVh Y2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkgYXBwbGljYWJsZSANCnBhdGVudCBvciBvdGhl ciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2ls bCBiZSANCmRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcyBhd2Fy ZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gDQphY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJD UCA3OS4NCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBwaWN0b3JpYWxseSBkZXBpY3Rz IElQIFNlcnZpY2UgKFZvaWNlICsgTXVsdGltZWRpYSkgcHJvdmlkZXIgDQpuZXR3b3JrIGZ1bmN0 aW9uYWwgY29tcG9uZW50cywgcGVlcmluZyBpbnRlcmZhY2UgZnVuY3Rpb25zLCBhbmQgYW4gSVAg U2VydmljZSANCihWTSkgcHJvdmlkZXJzkiBwZWVyaW5nIHJlZmVyZW5jZSBhcmNoaXRlY3R1cmUu IFRoZSBkcmFmdCBhbHNvIGNhbGxzIGZvciANCmRldmVsb3Bpbmcgc2VwYXJhdGUgcmVxdWlyZW1l bnRzIGZvciBkaWZmZXJlbnQgdHlwZXMgb2YgcGVlcmluZy4gDQoNCiANClNvaGVsIEtoYW4gICAg ICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDYgICAgICAgICAgICAgICAgIAlbUGFnZSAxXQ0KDQpJ bnRlcm5ldC1EcmFmdCAgICBJUCBTZXJ2aWNlIChWTSkgUGVlcmluZyBBcmNoaXRlY3R1cmUgICAg ICAgICAgICAgRmViLiAyNiwgMjAwNg0KDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4g IEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgMw0KICAgMi4gIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgMy4gIERlZmluaXRpb25zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgNC4gIElQ IFNlcnZpY2UgKFZvaWNlICsgTXVsdGltZWRpYSkgUHJvdmlkZXIgTmV0d29yay4gLiAuIC4gLiAu IC4gLiAgIDQNCiAgIDUuICBQZWVyaW5nIEludGVyZmFjZSBGdW5jdGlvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgIDYuICBSZWZlcmVuY2UgSVAgU2VydmljZSAo Vk0pIFByb3ZpZGVyIFBlZXJpbmcgQXJjaGl0ZWN0dXJlIC4gLiAuIC4gIDYNCiAgIDcgICBUeXBl IG9mIHBlZXJpbmcgSW50ZXJmYWNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDcNCiAgIDguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCiAgIDkuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCiAgIDEwLiAgQWNrbm93 bGVkZ2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LjgNCiAgIDExLiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLjgNCiAgICAgICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCiAgICAgICBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIDkN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpTb2hlbCBLaGFuICAgICAgIEV4cGlyZXMgQXVndXN0IDI2LCAyMDA2ICAg ICAgICAgICAgICAgICAJW1BhZ2UgMl0NCg0KSW50ZXJuZXQtRHJhZnQgICAgSVAgU2VydmljZSAo Vk0pIFBlZXJpbmcgQXJjaGl0ZWN0dXJlICAgICAgICAgICAgIEZlYi4gMjYsIDIwMDYNCg0KDQoN Cg0KMS4gIEludHJvZHVjdGlvbg0KDQpUaGlzIGRvY3VtZW50IHBpY3RvcmlhbGx5IGRlcGljdHMg SVAgU2VydmljZSAoVm9pY2UrTXVsdGltZWRpYSkgcHJvdmlkZXIgbmV0d29yayANCmZ1bmN0aW9u YWwgY29tcG9uZW50cywgcGVlcmluZyBpbnRlcmZhY2UgZnVuY3Rpb25zLCBhbmQgYW4gSVAgU2Vy dmljZSAoVk0pIA0KcHJvdmlkZXJzkiBwZWVyaW5nIHJlZmVyZW5jZSBhcmNoaXRlY3R1cmUuIFRo ZSBkb2N1bWVudCBicmluZ3MgYXR0ZW50aW9uIG9mIA0KZGlmZmVyZW50IHR5cGVzIG9mIHBlZXJp bmcgaW50ZXJmYWNlcyBhbmQgY2FsbHMgZm9yIGRldmVsb3Bpbmcgc2VwYXJhdGUgDQpyZXF1aXJl bWVudHMgZm9yIGRpZmZlcmVudCB0eXBlcyBvZiBwZWVyaW5nIGludGVyZmFjZXMuDQoNClRoZSBv YmplY3RpdmUgb2YgdGhpcyBkcmFmdCBpcyB0byBicmluZyBhdHRlbnRpb24gb2YgY3VycmVudCBu ZXR3b3JrIGZ1bmN0aW9uYWwgDQpjb21wb25lbnRzIGluIHRoZSBJUCBTZXJ2aWNlIChWTSkgcGVl cmluZyBkaXNjdXNzaW9uLiANCg0KMi4gIFRlcm1pbm9sb2d5DQoNCiAgIA0KICAgSW4gdGhpcyBk b2N1bWVudCwgdGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsDQog ICAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVO REVEIiwgIk5PVA0KICAgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgYXJlIHRv IGJlIGludGVycHJldGVkIGFzDQogICBkZXNjcmliZWQgaW4gWzddIGFuZCBpbmRpY2F0ZSByZXF1 aXJlbWVudCBsZXZlbHMgZm9yIGNvbXBsaWFudA0KICAgaW1wbGVtZW50YXRpb25zLg0KDQoNCg0K My4wIERlZmluaXRpb25zDQoNCjMuMSBJUCBTZXJ2aWNlIChWb2ljZSArIE11bHRpbWVkaWEpIFBy b3ZpZGVyDQogDQogIEFuIElQIFNlcnZpY2UgKFZvaWNlICsgTXVsdGltZWRpYSkgcHJvdmlkZXIg aXMgYW4gZW50aXR5IHRoYXQgcHJvdmlkZXMgSVAgDQpjZW50cmljIHZvaWNlIGFuZCBtdWx0aW1l ZGlhIHNlcnZpY2VzLiAgRXhhbXBsZXMgb2Ygc2VydmljZXMgYXJlIFNJUCBwcm9jZXNzaW5nIA0K YW5kIHRyYW5zcG9ydCwgbWVkaWEgcHJvY2Vzc2luZyBhbmQgdHJhbnNwb3J0LCBzZWN1cml0eSBh bmQgcG9saWN5IA0KaW1wbGVtZW50YXRpb24sIGFuZCBlbWVyZ2luZyBhcHBsaWNhdGlvbiBzdXBw b3J0LiBFbmQgdXNlcnMgb2YgYW4gSVAgU2VydmljZSANCihWTSkgcHJvdmlkZXIgbWF5IHVzZSBQ U1ROLCBJUCBXaXJlbGVzcywgbm9uLUlQIHdpcmVsZXNzLCBhbmQgU0lQLWJhc2VkIGRldmljZXMu DQoNCg0KMy4yIFBlZXJpbmcNCg0KVGhpcyBkb2N1bWVudCBhZGhlcmVzIHRvIHRoZSBwZWVyaW5n IGRlZmluaXRpb25zIG9mIElFVEYgZHJhZnQgWzRdIFNlY3Rpb24gMy42Lg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNClNvaGVsIEtoYW4gICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDYg ICAgICAgICAgICAgICAgIAlbUGFnZSAzXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICBJUCBTZXJ2aWNl IChWTSkgUGVlcmluZyBBcmNoaXRlY3R1cmUgICAgICAgICAgICAgRmViLiAyNiwgMjAwNg0KDQoN CjQuMCBJUCBTZXJ2aWNlIChWb2ljZSArIE11bHRpbWVkaWEpIFByb3ZpZGVyIE5ldHdvcmsNCg0K ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUCBTZXJ2aWNlIFBy b3ZpZGVyIE5ldHdvcmsNCiAgIC8gLS0tLS0tLS0tLVwgICAgICAgICAgICAgLy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cICAgICAgICAgICANCiAgIHwgICAgICAgICAgIHwgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICArLS0t LS0rDQogICB8ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgCQkrLS0tLS0tLS0tLS0r ICAgIHwgPC0tLT58IElQICAgfA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAg CSAJfEFwcGxpY2F0aW9ufCAgICB8IDwuLi4+fCBwaG9uZXwNCiAgIHwgICAgICAgICAgIHwgICAg ICAgICAgICAgfCAgIC4uIC4gLiAuIC4uIAl8ICBTZXJ2ZXJzLCB8ICAgIHwgICAgICArLS0tLS0t Kw0KICAgfCAgICAgICA8LS0tfC0tLS0tLS0tLS0tLS18LS0+LlBlZXJpbmcgIC4gICAgfCBEYXRh YmFzZXMgfCAgICB8DQogICB8ICAgICAgIDwuLi4uLi4uLi4uLi4uLi4uLnwuPiAuSW50ZXJmYWNl LiAgICArLS0tLS0tLS0tLS0rICAgIHwNCiAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgfCAg IC5GdW5jdGlvbnMuICAgICAgICAgICAgICAgICAgICAgfCAgICArLS0tLS0tLS0rDQogICB8ICAg ICAgICAgICB8ICAgICAgICAgICAgIHwgICAuLiAuIC4gLiAuLiAgICArLS0tLS0tLS0tLS0rICAg IHw8LS0+fFdpcmVsZXNzfA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgfCBTSVAgICAgICAgfCAgICB8PC4uPnwgIElQICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgIHwgICBQZWVyICAgIHwgICAgICAgICAgICAg fCAgICstLS0tLS0tLS0rICAgIHwgUHJveGllcyAgIHwgICAgfCAgICB8TmV0d29yayB8ICAgICAg IA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgfCBQcml2YXRlIHwgICAgKy0tLS0t LS0tLS0tKyAgICB8ICAgICstLS0tLS0tLSsgDQogICB8IFByb3ZpZGVyICB8ICAgICAgICAgICAg IHwgICB8IEVOVU0gICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgIHwg ICAgICAgICAgICAgfCAgICstLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLSsgICAgfCAgICANCiAg IHwgICAgICAgICAgIHwgIAkgICAgIHwJCSAgICAgICAgfFNJUCBVQXMgICAgIHwgICB8ICAgICAg ICAgIA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgfEIy QlVBcyAgICAgIHwgICB8DQogICB8ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0rICAgIHwgDQogICB8ICAgICAgICAgICB8ICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tK3wgICAgICAgKy0tLS0rDQogICB8 ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICArLS0tLS0tLS0rICAgICAgICAgICB8 TUdDRnw8SVNVUD4gfCAgICB8ICANCiAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg ICAgIHwgSVAgICAgIHwgICAgICAgICAgICstLS0rfCAgICAgICB8ICAgIHwNCiAgIHwgICAgICAg ICAgIHwgICAgICAgICAgICAgfCAgICAgICAgIHwgUm91dGVyc3wgICAgICAgICAgICstLS0rfCAg ICAgICB8UFNUTnwgICAgIA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAg Ky0tLS0tLS0tKyAgICAgICAgICAgfE1HIHx8PFRETT4gIHwgICAgfA0KICAgfCAgICAgICAgICAg fCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSt8ICAgICAg ICstLS0tKw0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIFwtLS0tLS0tLS0tLS8gICAgICAgICAg ICAgXC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLw0KICAgICAgICAgDQogLS0t IE1lZGlhIChSVFAvSVApDQogLi4uIFNpZ25hbCAoU0lQKSAgIA0KDQogICAgICAgICAgICBGaWd1 cmUgMTogTmV0d29yayBBcmNoaXRlY3R1cmUgb2YgYW4gSVAgU2VydmljZSAoVk0pIFByb3ZpZGVy IA0KDQogICAgIA0KQW4gSVAgU2VydmljZSBwcm92aWRlciAoVk0pIG5ldHdvcmsgY29udGFpbnMg ZnVuY3Rpb25zIG9mIFNJUC9TSVBQSU5HL1NJTVBMRSANCnJlbGF0ZWQgUkZDcyBpbiBnZW5lcmFs IGFuZCBSRkMzMjYxWzFdIGluIHBhcnRpY3VsYXIuIEV4YW1wbGVzIG9mIHRoZXNlIA0KZnVuY3Rp b25zIGFyZSBTSVAgUHJveGllcywgU0lQIFVBLCBhbmQgQjJCVUEuIEluIGFkZGl0aW9uLCB0aGUg SVAgU2VydmljZSANCnByb3ZpZGVyIG5ldHdvcmsgY29udGFpbnMgSVAgUm91dGVycywgQXBwbGlj YXRpb24gc2VydmVycywgYW5kIGRhdGFiYXNlcy4gVG8gDQpmYWNpbGl0YXRlIGludGVyZmFjZSB3 aXRoIFBTVE4gbmV0d29yaywgYSBTZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmsgY29udGFpbnMgDQpN ZWRpYSBHYXRld2F5IENvbnRyb2wgRnVuY3Rpb24gKE1HQ0YpIGFuZCBNZWRpYSBHYXRld2F5IChN RykuIFRoZSBuZXR3b3JrIG1heSANCmFsc28gY29udGFpbiBwcml2YXRlIEVOVU0uDQoNCkFuIElQ IFNlcnZpY2UgKFZNKSBwcm92aWRlciBpbnRlcmNvbm5lY3RzIHdpdGggb3RoZXIgSVAgU2Vydmlj ZSAoVk0pIHByb3ZpZGVycyANCndpdGggYSBwZWVyaW5nIGludGVyZmFjZSBmdW5jdGlvbnMuIA0K DQoNCg0KDQoNCg0KU29oZWwgS2hhbiAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNiwgMjAwNiAgICAg ICAgICAgICAgICAgCVtQYWdlIDRdDQoNCkludGVybmV0LURyYWZ0ICAgIElQIFNlcnZpY2UgKFZN KSBQZWVyaW5nIEFyY2hpdGVjdHVyZSAgICAgICAgICAgICBGZWIuIDI2LCAyMDA2DQoNCjUuMCBQ ZWVyaW5nIEludGVyZmFjZSBGdW5jdGlvbnMNCg0KDQogICAgICAgICAgICAgICAuLi4uLi4uLi4u Li4gLiAuIC4uIA0KICAgICAgICAgICAgICAgLiArLS0tLS0tKyAuICAgICAgIC4gDQogICAgICAg ICAgICAgICAuIHwgIEFGICB8IC4gICAgICAgLiANCiAgICAgICAgICAgICAgIC4gKy0tLS0tLSsg LiAgUyAgICAuICAgIA0KICAgICAgICAgICAgICAgLiAgICAgICAgICAuICAgICAgIC4gIA0KICAg ICAgICAgICAgICAgLiArLS0tLS0tKyAuICBFICAgIC4gIA0KICAgICAgICAgICAgICAgLiB8ICBT RiAgfCAuICAgICAgIC4NCiAgICAgICAgICAgICAgIC4gKy0tLS0tLSsgLiAgQyAgICAuICANCiAg ICAgICAgICAgICAgIC4gICAgICAgICAgLiAgICAgICAuICANCiAgICAgICAgICAgICAgIC4gKy0t LS0tLSsgLiAgVSAgICAuDQogICAgICAgICAgICAgICAuIHwgIFRGICB8IC4gICAgICAgLg0KICAg ICAgICAgICAgICAgLiArLS0tLS0tKyAuICBSICAgIC4NCiAgICAgICAgICAgICAgIC4gICAgICAg ICAgLiAgICAgICAuDQogICAgICAgICAgICAgICAuICstLS0tLS0rIC4gIEkgICAgLg0KICAgICAg ICAgICAgICAgLiB8ICBNRiAgfCAuICAgICAgIC4NCiAgICAgICAgICAgICAgIC4gKy0tLS0tLSsg LiAgVCAgICAuDQogICAgICAgICAgICAgICAuICAgICAgICAgIC4gICAgICAgLg0KICAgICAgICAg ICAgICAgLiArLS0tLS0tKyAuICBZICAgIC4NCiAgICAgICAgICAgICAgIC4gfCBPRiAgIHwgLiAg ICAgICAuDQogICAgICAgICAgICAgICAuICstLS0tLS0rIC4gICAgICAgLg0KICAgICAgICAgICAg ICAgLi4uLi4uLi4uLi4uIC4uIC4uIC4NCiAgICAgICAgICAgICBGaWd1cmUgMjogUGVlcmluZyBJ bnRlcmZhY2UgZnVuY3Rpb25zDQoNCkFuIElQIFNlcnZpY2UgcGVlcmluZyBpbnRlcmZhY2UgY2Fu IGJlIGRpdmlkZWQgaW50byBmaXZlIHBsYW5lczogYXBwbGljYXRpb24sIA0Kc2lnbmFsaW5nLCBt ZWRpYSwgdHJhZmZpYyBlbmdpbmVlcmluZywgYW5kIG9wZXJhdGlvbi1tYW5hZ2VtZW50LiBUaGlz IGRvY3VtZW50IGRlZmluZXMgDQptb2R1bGVzIHBlcmZvcm1pbmcgdGhlc2UgaW50ZXJmYWNlcyBh cyBBcHBsaWNhdGlvbiBGdW5jdGlvbiAoQVApLCBTaWduYWxpbmcgDQpGdW5jdGlvbiAoU0YpLCBN ZWRpYSBGdW5jdGlvbiAoTUYpLCBUcmFmZmljIEVuZ2luZWVyaW5nIEZ1bmN0aW9uIChURiksIGFu ZCANCk9wZXJhdGlvbiAmIE1hbmFnZW1lbnQgRnVuY3Rpb24gKE9GKS4gTm90ZSB0aGF0IHRoZSBz ZWN1cml0eSBpcyBhc3NvY2lhdGVkIHdpdGggDQphbGwgdGhlc2UgZnVuY3Rpb25zLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU29oZWwgS2hhbiAgICAgICBFeHBp cmVzIEF1Z3VzdCAyNiwgMjAwNiAgICAgICAgICAgICAgICAgCVtQYWdlIDVdDQoNCkludGVybmV0 LURyYWZ0ICAgIElQIFNlcnZpY2UgKFZNKSBQZWVyaW5nIEFyY2hpdGVjdHVyZSAgICAgICAgICAg ICBGZWIuIDI2LCAyMDA2DQoNCg0KDQoNCjYuMCBSZWZlcmVuY2UgSVAgU2VydmljZSAoVk0pIFBy b3ZpZGVyIFBlZXJpbmcgQXJjaGl0ZWN0dXJlDQoNCiAgDQoNCg0KICAgKy0tLS0tLS0rICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rDQog ICB8ICBJUCAgIHwgICAgICAgICAgIC0tLS0tLS0gICAgICAgICAgICAgICAgLS0tLS0tLSAgICAg ICAgICB8ICBJUCAgIHwNCiAgIHwgcGhvbmUgfCA8LS0tLS0tPiAvICAgICAgIFwgICAgICAgICAg ICAgIC8gICAgICAgXCA8LS0tLS0tPnwgcGhvbmUgfA0KICAgKy0tLS0tLS0rICAgICAgICAgfCAg ICAgICAgQUYgLi4uLi4uLi4uLi5BRiAgICAgICAgfCAgICAgICAgKy0tLS0tLS0rDQoJCSAgICAg fCAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIAkJICAgICAgICAgfCAgIElQ ICAgU0YuLi4uLi4uLi4uLlNGICAgSVAgICAgfCAgICAgICAgDQogICArLS0tLS0tLS0rICAgICAg ICB8IFNlcnZpY2UgfCAgICAgICAgICAgIHwgU2VydmljZSB8ICAgICAgICArLS0tLS0tLS0rICAg ICANCiAgIHxXaXJlbGVzc3wgICAgICAgIHxQcm92aWRlciBNRiAuLi4uLi4uLi5NRiBQcm92aWRl cnwgICAgICAgIHxXaXJlbGVzc3wNCiAgIHxOZXR3b3JrIHwgPC0tLS0tPnwgICAgICAgICB8ICAg ICAgICAgICAgfCAgICAgICAgIHw8LS0tLS0+IHxOZXR3b3JrIHwNCiAgICstLS0tLS0tLSsgICAg ICAgIHwgICAgQSAgICBURiAuLi4uLi4uICBURiAgICAgQiAgIHwgICAgICAgICstLS0tLS0tLSsN CiAgICstLS0tLS0rICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgIHwg ICAgICAgICAgKy0tLS0tLSsNCiAgIHwgICAgICB8IDwtLS0tLS0tPk1HICAgICAgICBPRiAuLi4u Li4uLiBPRiAgICAgICAgICA8LS0tLS0tLT4gfCAgICAgIHwNCiAgIHwgUFNUTiB8ICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgfCBQU1ROIHwNCiAg IHwgICAgICB8IDwtLS0tLS0tPiBcICAgICAgIC8gICAgICAgICAgICAgIFwgICAgICAgLyA8LS0t LS0tLT4gfCAgICAgIHwNCiAgICstLS0tLS0rICAgIFNTNyAgICAgLS0tLS0tLSAgICAgICAgICAg ICAgICAtLS0tLS0tICAgICBTUzcgICAgKy0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgIEZpZ3VyZSAzOiBSZWZlcmVuY2UgUGVlcmluZyBBcmNoaXRlY3R1cmUNCg0K DQpUaGUgU0YgcGVyZm9ybXMgTGF5ZXIgNSBwZWVyaW5nIGZ1bmN0aW9ucyBpLmUuLCBTSVAgc2ln bmFsaW5nIGFuZCBjb250cm9sIA0KZnVuY3Rpb25zIGF0IHRoZSBpbnRlcmNvbm5lY3QgaW50ZXJm YWNlLiBBIHBvc3NpYmxlIGV4YW1wbGUgb2YgYSBTRiBpcyBhIFNJUCANClByb3h5IG9yIGEgU0lQ IEIyQlVBLiANCg0KQSBNRiBtYXkgdHJhbnNmb3JtIHZvaWNlIHBheWxvYWQgZnJvbSBvbmUgY29k aW5nIChlLmcuLCBHLjcxMSkgdG8gYW5vdGhlciAoZS5nLiwgDQpFdlJDKS4gDQoNClRoZSBURiBw ZXJmb3JtcyB0aGUgdHJhZmZpYyBlbmdpbmVlcmluZyBhbmQgTGF5ZXIgMyBmdW5jdGlvbnMuIEFu IGV4YW1wbGUgb2YgYSANClRGIGlzIHRoZSBzZXNzaW9uIGFkbWlzc2lvbiBjb250cm9sIChTQUMp LCB3aGljaCBpcyBhbmFsb2dvdXMgdG8gdGhlIHdlbGwga25vd24gDQpDYWxsIEFkbWlzc2lvbiBD b250cm9sIChDQUMpLiBBbm90aGVyIGV4YW1wbGUgaXMgdGhlIGV4Y2hhbmdlIG9mIHJvdXRpbmcg DQppbmZvcm1hdGlvbiBiZXR3ZWVuIHR3byBwcm92aWRlcnMgYW5kIGltcGxlbWVudGF0aW9uIG9m IHRoZSBCb3JkZXIgR2F0ZXdheSANClByb3RvY29sKEJHUClbUkZDMTc3MV1bM10uDQoNCg0KQW4g QUYgaXMgYSBzcGVjaWFsIGZ1bmN0aW9uIHRoYXQgY29udGFpbnMgYmktbGF0ZXJhbGx5IGRpc2Ns b3NlZCBpbmZvcm1hdGlvbiANCmFib3V0IHRoZSBhcHBsaWNhdGlvbiBzZXJ2ZXJzIGFuZCBkYXRh YmFzZXMgb2YgZWFjaCBJUCBzZXJ2aWNlIHByb3ZpZGVyLiBBbiANCmV4YW1wbGUgb2YgdGhpcyBm dW5jdGlvbiBpcyB0byBhbGxvdyBhIHNlc3Npb24gdG8gc2VsZWN0IGEgYmV0dGVyIHN1aXRlZCAN CmFwcGxpY2F0aW9uIHNlcnZlciBmcm9tIGEgc2V0IG9mIGFwcGxpY2F0aW9uIHNlcnZlcnMgbG9j YXRlZCBpbnNpZGUgYm90aCBzZXJ2aWNlIA0KcHJvdmlkZXJzJyBuZXR3b3JrLg0KDQoNCg0KDQoN ClNvaGVsIEtoYW4gICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDYgICAgICAgICAgICAgICAg IAlbUGFnZSA2XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICBJUCBTZXJ2aWNlIChWTSkgUGVlcmluZyBB cmNoaXRlY3R1cmUgICAgICAgICAgICAgRmViLiAyNiwgMjAwNg0KDQoNCg0KDQpTb21lIGV4YW1w bGVzIG9mIGFib3ZlIGZ1bmN0aW9ucyBhcmUgcHJlc2VudGVkIGluIHRoZSBmb2xsb3dpbmcgdGFi bGU6IA0KDQogICBGdW5jdGlvbnMgCQkJCQlFeGFtcGxlcw0KICAgDQpTaWduYWxpbmcgRnVuY3Rp b24gKFNGKQlTSVAgUHJveHksIEIyQlVBLCBTZXNzaW9uIEFkbWlzc2lvbiBDb250cm9sIChTQUMp LCANCgkJCQlTSVAgSW50ZXJvcGVyYWJpbGl0eSwgU0lQIERlbmlhbCBvZiBTZXJ2aWNlIChEb1Mp IA0KCQkJCXByb3RlY3Rpb24sIFNJUCBUb3BvbG9neSBIaWRpbmcgKFRISUcpLCBhbmQgU0lQIA0K CQkJCXNlY3VyaXR5LCBwcml2YWN5IGFuZCBlbmNyeXB0aW9uLg0KDQpNZWRpYSBGdW5jdGlvbiAg ICAoTUYpCVRyYW5zY29kaW5nLCBkYXRhIGludGVncml0eSwgbWVkaWEgc2VjdXJpdHksIHByaXZh Y3kgYW5kICAgICAgDQplbmNyeXB0aW9uLiANCg0KVEUgRnVuY3Rpb24gICAgICAgKFRGKQlSb3V0 aW5nIHByb3RvY29sIGhhcm1vbml6YXRpb24sIFZQTiBtZWRpYXRpb24sIHNlc3Npb24gDQphZG1p c3Npb24gcG9saWN5IGVuZm9yY2VtZW50LCByYXRlIHNoYXBpbmcsIGJhbmR3aWR0aCANCmJyb2tl ciwgYmFuZHdpZHRoIHRoZWZ0IHByb3RlY3Rpb24sIGRhdGEgaW50ZWdyaXR5LCANCnRyYW5zY29k aW5nLCBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24gKE5BVCkNCg0KDQpPJk0gRnVuY3Rpb24g ICAgKE9GKSAgICBDQUxFQSBpbXBsZW1lbnRhdGlvbjsgYWNjb3VudGluZywgYmlsbGluZyBhbmQJ DQoJCQkgICAgICBvcGVyYXRpb25hbCBkYXRhIG1lZGlhdGlvbi4NCg0KQXBwbGljYXRpb24gRnVu Y3Rpb24gKEFGKSAgQW4gaW50ZXJ3b3JraW5nIHNlcnZpY2UgYnJva2VyICAgICAgICAgICAgIA0K DQogDQpOb3RlIHRoYXQgdGhlcmUgbWF5IGJlIG92ZXJsYXBwaW5nIG9mIGZ1bmN0aW9uIGJldHdl ZW4gTUYgYW5kIFRGLiBUaGUgc2VjdXJpdHkgDQppcyBhc3NvY2lhdGVkIHdpdGggYWxsIGZ1bmN0 aW9ucy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNv aGVsIEtoYW4gICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDYgICAgICAgICAgICAgICAgIAlb UGFnZSA3XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICBJUCBTZXJ2aWNlIChWTSkgUGVlcmluZyBBcmNo aXRlY3R1cmUgICAgICAgICAgICAgRmViLiAyNiwgMjAwNg0KDQoNCjcuMCBUeXBlIG9mIHBlZXJp bmcgSW50ZXJmYWNlcw0KDQogICBSZXF1aXJlbWVudHMgb2YgUGVlcmluZyBJbnRlcmZhY2VzIHZh cnkgZGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9mIA0KaW50ZXJjb25uZWN0aW9uLiBUd28gbGFyZ2Ug SVAgc2VydmljZSBwcm92aWRlciBoYXZpbmcgZXF1YWwgb3IgYWxtb3N0IGVxdWFsIA0KbmV0d29y ayBmdW5jdGlvbmFsIGNvbXBvbmVudHMgbWF5IHBlZXIgYXMgbmV0d29yay1uZXR3b3JrIGludGVy ZmFjZSAoTk5JKS4gDQpIb3dldmVyLCBhIHNtYWxsIGVudGVycHJpc2UgbWF5IHJlbHkgb24gbWFu eSBzZXJ2aWNlcyBvciBuZXR3b3JrIGZ1bmN0aW9ucyBvZiBhIA0KbGFyZ2UgSVAgc2VydmljZSBw cm92aWRlci4gVGh1cywgdGhlIHBlZXJpbmcgcmVxdWlyZW1lbnRzIGJldHdlZW4gdGhlIGFjY2Vz cy1uZXR3b3JrIA0KaW50ZXJmYWNlcyAoQU5JKSBtYXkgYmUgZGlmZmVyZW50IGZyb20gdGhvc2Ug b2YgbmV0d29yay1uZXR3b3JrIGludGVyZmFjZXMuIA0KU2ltaWxhcmx5LCB3aGVuIGEgdXNlciBh Z2VudCAoZS5nLiwgbGFwdG9wKSBwZWVycyB3aXRoIGEgbmV0d29yayAoZS5nLiwgV2lyZWxlc3Mg DQpJUCBwcm92aWRlciksIHRoZSB1c2VyLW5ldHdvcmsgaW50ZXJmYWNlIChVTkkpIHJlcXVpcmVt ZW50cyBtYXkgYWxzbyBiZSBkaWZmZXJlbnQgDQpmcm9tIHRob3NlIG9mIHRoZSBOTkkgYW5kIEFO SS4gUmVxdWlyZW1lbnRzIGZvciB0aGVzZSBpbnRlcmZhY2VzIG5lZWQgdG8gYmUgDQpzZXBhcmF0 ZWx5IGFkZHJlc3NlZC4gVGhpcyBkb2N1bWVudCBhc3N1bWVzIHRoYXQgdGhlIHAycCBTSVAgaXMg b3V0c2lkZSB0aGUgDQpzY29wZSBvZiBTUEVFUk1JTlQuDQoNCg0KOC4wIFNlY3VyaXR5IA0KDQog ICBNYW55IG9mIHRoZSBmdW5jdGlvbnMgdGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaGF2ZSBpbXBv cnRhbnQgc2VjdXJpdHkNCiAgIGFuZCBwcml2YWN5IGltcGxpY2F0aW9ucy4gIElmIHRoZSBJRVRG IGRlY2lkZXMgdG8gZGV2ZWxvcCBzdGFuZGFyZA0KICAgbWVjaGFuaXNtcyB0byBhZGRyZXNzIHRo b3NlIGZ1bmN0aW9ucywgc2VjdXJpdHkgYW5kIHByaXZhY3ktcmVsYXRlZA0KICAgYXNwZWN0cyB3 aWxsIG5lZWQgdG8gYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uLg0KDQo3LiAgSUFOQSBDb25z aWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IGhhcyBubyBJQU5BIGNvbnNpZGVyYXRpb25z Lg0KDQo4LiAgQWNrbm93bGVkZ2VzDQoNCiAgIFRoaXMgZHJhZnQgcmVwcm9kdWNlcyBzb21lIGlu Zm9ybWF0aW9uIG9mIHRoZSBJRVRGIGRyYWZ0IGRyYWZ0LXNvaGVsLXNpcHBpbmctDQpzLWJjLWNv bmNlcHQtYXJjaC0wMC50eHQsIEp1bHkgMTQsIDIwMDUgYW5kIFBUU0MtU0FDLTIwMDUtMjEzIFs1 XS4NCiANCg0KOS4gIFJlZmVyZW5jZXMNCg0KICAgWzFdICBSb3NlbmJlcmcsIEouLCBTY2h1bHpy aW5uZSwgSC4sIENhbWFyaWxsbywgRy4sIEpvaG5zdG9uLCBBLiwNCiAgICAgICAgUGV0ZXJzb24s IEouLCBTcGFya3MsIFIuLCBIYW5kbGV5LCBNLiBhbmQgRS4gU2Nob29sZXIsICJTSVA6DQogICAg ICAgIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCIsIFJGQyAzMjYxLCBKdW5lIDIwMDIuDQog ICBbMl0gIFNjaHVsenJpbm5lLCBILiwgQ2FzbmVyLCBTLiwgRnJlZGVyaWNrLCBSLiBhbmQgVi4g SmFjb2Jzb24sDQogICAgICAgICJSVFA6IEEgVHJhbnNwb3J0IFByb3RvY29sIGZvciBSZWFsLVRp bWUgQXBwbGljYXRpb25zIiwgU1REIDY0LA0KICAgICAgICBSRkMgMzU1MCwgSnVseSAyMDAzLg0K ICAgWzNdIFJla2h0ZXIsIFkuIGFuZCBULiBMaSwgk0EgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wg NCAoQkdQLTQplCwgUkZDIDE3NzEsIA0KICAgICAgIE1hcmNoLCAxOTk1Lg0KICAgWzRdIE1leWVy LCBELiwgk1NQRUVSTUlOVCBSZXF1aXJlbWVudHMgYW5kIFRlcm1pbm9sb2d5lCwgZHJhZnQtaWV0 Zi0NCnNwZWVybWludC1yZXFzLWFuZC10ZXJtaW5vbG9neS0wMS50eHQsIEZlYi4gMTcsIDIwMDYu DQogICBbNV0gS2hhbiwgU29oZWwsICJFeGFtcGxlIENvbmNlcHR1YWwgUmVhbGl6YXRpb24gb2Yg Uy9CQ3MiLCANCiAgICAgICBQVFNDLVNBQy0yMDA1LTIxMywgQVRJUy1QVFNDLCBKdW5lLCAyMDA1 Lg0KDQoNCg0KDQoNCg0KU29oZWwgS2hhbiAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNiwgMjAwNiAg ICAgICAgICAgICAgICAgCVtQYWdlIDddDQoNCkludGVybmV0LURyYWZ0ICAgIElQIFNlcnZpY2Ug KFZNKSBQZWVyaW5nIEFyY2hpdGVjdHVyZSAgICAgICAgICAgICBGZWIuIDI2LCAyMDA2DQoNCg0K QXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIFNvaGVsIEtoYW4sIFBoLkQuDQogICBUZWNobm9sb2d5 IFN0cmF0ZWdpc3QNCiAgIFNwcmludA0KICAgNjIyMCBTcHJpbnQgUGFya3dheQ0KICAgT3Zlcmxh bmQgUGFyaywgS1MgNjYyNTENCiAgIFUuUy5BDQoNCiAgIA0KSW50ZWxsZWN0dWFsIFByb3BlcnR5 IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhl IHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0 cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRv IHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGlu DQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5k ZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBk b2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZm b3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUg cHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJl DQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNj bG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5j ZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4N CiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lv biBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50 ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZy b20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8g YnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0 ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1h eSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAg dGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVU RiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0K DQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBh cmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwg VEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZ IChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJ TkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElN UExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFU IFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0Ug QU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJ VFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KQ29weXJpZ2h0IFN0 YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4g IFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5k IHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBhcyBzZXQg Zm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNClNv aGVsIEtoYW4gICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDYgICAgICAgICAgICAgICAgIAlb UGFnZSA3XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICBJUCBTZXJ2aWNlIChWTSkgUGVlcmluZyBBcmNo aXRlY3R1cmUgICAgICAgICAgICAgRmViLiAyNiwgMjAwNg0KDQoNCg== ------_=_NextPart_001_01C63D38.FB86DC69 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_01C63D38.FB86DC69-- From speermint-bounces@ietf.org Thu Mar 02 02:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEiKk-0005fV-Av; Thu, 02 Mar 2006 02:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEiKi-0005bF-Nr for speermint@ietf.org; Thu, 02 Mar 2006 02:34:44 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEiKc-0000DB-Br for speermint@ietf.org; Thu, 02 Mar 2006 02:34:44 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id D64BB1A3D1; Thu, 2 Mar 2006 08:34:35 +0100 (CET) Date: Thu, 2 Mar 2006 08:34:35 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] [Fwd: I-D ACTION:draft-lendl-domain-policy-ddds-00.txt] Message-ID: <20060302073435.GA32526@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <4403EBB8.3000607@enum.at> <20060228110026.GA32292@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060228110026.GA32292@nic.at> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 2006/02/28 12:02, Otmar Lendl wrote: > > Another I-D is winding its way through the ID-queue and describes > the federation concept. > It's finally through: -------------- Title : Federations for the Domain Policy DDDS Application Author(s) : O. Lendl Filename : draft-lendl-speermint-federations-00.txt Pages : 7 Date : 2006-3-1 This documents defines the policy-type for federations within the Domain Policy DDDS Application. Using this policy-type domain-owners can announce their membership in a federation and thus their willingness to accept incoming communications according to the rules of that federation. Such federations can be used to establish selective peerings e.g. in the Voice over IP and Instant Messaging space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-speermint-federations-00.txt -------------- /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 Thu Mar 02 13:34:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEscw-0006xB-67; Thu, 02 Mar 2006 13:34:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEscv-0006wD-Kc for speermint@ietf.org; Thu, 02 Mar 2006 13:34:13 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEscu-0001Ys-A3 for speermint@ietf.org; Thu, 02 Mar 2006 13:34:13 -0500 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.17362582; Thu, 02 Mar 2006 13:33:41 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 13:33:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C63E27.D34B811F" Date: Thu, 2 Mar 2006 13:33:39 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A437@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D draft-bhatia-sip-peering-00.txt Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJg From: "Livingood, Jason" To: X-OriginalArrivalTime: 02 Mar 2006 18:33:41.0085 (UTC) FILETIME=[D42AA8D0:01C63E27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d99cba2a085c3987933aa34e30e85ab Subject: [Speermint] FW: I-D draft-bhatia-sip-peering-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_01C63E27.D34B811F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C63E27.D34B811F" ------_=_NextPart_002_01C63E27.D34B811F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI for the WG on this draft. This is on the tentative agenda at the Dallas meeting (should be finalized shortly). =20 Jason ________________________________ From: Medhavi Bhatia [mailto:mbhatia@nextone.com]=20 Sent: Sunday, February 26, 2006 12:44 AM To: internet-drafts@ietf.org Cc: dmm@1-4-5.net; Livingood, Jason Subject: I-D draft-bhatia-sip-peering-00.txt Abstract =20 The purpose of this document is to help the IETF community understand the route architectures being used today in SIP based peering environments and to outline a set of requirements based on the same for discussion within the community. =20 =20 ------_=_NextPart_002_01C63E27.D34B811F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI for the WG on this draft.  This is on = the=20 tentative agenda at the Dallas meeting (should be finalized=20 shortly).
 
Jason

From: Medhavi Bhatia=20 [mailto:mbhatia@nextone.com]
Sent: Sunday, February 26, 2006 = 12:44=20 AM
To: internet-drafts@ietf.org
Cc: dmm@1-4-5.net;=20 Livingood, Jason
Subject: I-D=20 draft-bhatia-sip-peering-00.txt

Abstract

 

   The purpose of this document is = to help the=20 IETF community understand

   the route architectures being = used today in=20 SIP based peering

   environments and to outline a set = of=20 requirements based on the same

   for discussion within the=20 community.

 

 

------_=_NextPart_002_01C63E27.D34B811F-- ------_=_NextPart_001_01C63E27.D34B811F Content-Type: text/plain; name="draft-bhatia-sip-peering-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-bhatia-sip-peering-00.txt Content-Disposition: attachment; filename="draft-bhatia-sip-peering-00.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTS4gQmhhdGlhDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE5leFRvbmUgQ29tbXVuaWNhdGlvbnMNCkV4cGlyZXM6IEF1Z3VzdCAz MCwgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyNiwgMjAwNg0K DQoNCiAgICAgICBSb3V0ZSBQb2xpY3kgYW5kIEFyY2hpdGVjdHVyZSBpbiBTSVAgUGVlcmluZyBF bnZpcm9ubWVudHMNCiAgICAgICAgICAgICAgICAgICAgZHJhZnQtYmhhdGlhLXNpcC1wZWVyaW5n LTAwLnR4dA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJ bnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBwbGlj YWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdh cmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBo ZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFu Y2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdv cmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3Jj ZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0K ICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMg SW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1 cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkN CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMg cmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y ayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRz IGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0 cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0 b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3VzdCAzMCwg MjAwNi4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5l dCBTb2NpZXR5ICgyMDA2KS4NCg0KQWJzdHJhY3QNCg0KICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBk b2N1bWVudCBpcyB0byBoZWxwIHRoZSBJRVRGIGNvbW11bml0eSB1bmRlcnN0YW5kDQogICB0aGUg cm91dGUgYXJjaGl0ZWN0dXJlcyBiZWluZyB1c2VkIHRvZGF5IGluIFNJUCBiYXNlZCBwZWVyaW5n DQogICBlbnZpcm9ubWVudHMgYW5kIHRvIG91dGxpbmUgYSBzZXQgb2YgcmVxdWlyZW1lbnRzIGJh c2VkIG9uIHRoZSBzYW1lDQogICBmb3IgZGlzY3Vzc2lvbiB3aXRoaW4gdGhlIGNvbW11bml0eS4N Cg0KDQoNCg0KDQoNCg0KDQpCaGF0aWEgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MzAsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgIHNpcC1wZWVyaW5nLXJvdXRlLXBvbGljeSAgICAgICAgICAgRmVicnVhcnkgMjAwNg0KDQoN ClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFRlcm1pbm9sb2d5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQog ICAzLiAgR2VuZXJhbCBDYWxsIEZsb3cgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDQNCiAgIDQuICBSb3V0aW5nIEFyY2hpdGVjdHVyZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICA0LjEuICBVc2Ugb2YgRWRnZSBQ cm94aWVzIGFuZCBTZXNzaW9uIEJvcmRlciBDb250cm9sbGVycyAuIC4gLiAuICA2DQogICA1LiAg UmVxdWlyZW1lbnRzIGZvciByb3V0ZSBwb2xpY3kgYW5kIGFyY2hpdGVjdHVyZSBmb3IgcGVlcmlu ZyAuIC4gIDYNCiAgICAgNS4xLiAgVHlwZSBvZiBvdXRnb2luZyBwZWVyICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICA1LjIuICBBZGRyZXNzaW5nIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgIDUuMy4gIEJ1 c2luZXNzIFJlcXVpcmVtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDgNCiAgICAgICA1LjMuMS4gIENvc3Qgb3IgUHJvZml0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAgIDUuMy4yLiAgU0xBcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgICAgNS4zLjMuICBCdW5k bGluZyBvZiBjYWxscyBmb3Igcm91dGUgZGV0ZXJtaW5hdGlvbiBwdXJwb3NlcyAuIC4gIDgNCiAg ICAgNS40LiAgTG9jYWwgTmV0d29yayBQb2xpY3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgOQ0KICAgICA1LjUuICBSZWd1bGF0b3J5IFJlcXVpcmVtZW50cyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA2LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDcuICBJ QU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgOQ0KICAgOC4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA5LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgOS4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg OQ0KICAgICA5LjIuICBJbmZvcm1hdGlvbmFsIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEwDQogICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgIEludGVsbGVjdHVhbCBQcm9w ZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQmhhdGlh ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDMwLCAyMDA2ICAgICAgICAgICAgICAg IFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBzaXAtcGVlcmluZy1yb3V0ZS1w b2xpY3kgICAgICAgICAgIEZlYnJ1YXJ5IDIwMDYNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAg IFRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gaGVscCB0aGUgSUVURiBjb21tdW5p dHkgdW5kZXJzdGFuZA0KICAgdGhlIHJvdXRlIGFyY2hpdGVjdHVyZXMgYmVpbmcgdXNlZCB0b2Rh eSBpbiBTSVBbMV0gYmFzZWQgcGVlcmluZw0KICAgZW52aXJvbm1lbnRzIGFuZCB0byBvdXRsaW5l IGEgc2V0IG9mIHJlcXVpcmVtZW50cyBiYXNlZCBvbiB0aGUgc2FtZQ0KICAgZm9yIGRpc2N1c3Np b24gd2l0aGluIHRoZSBjb21tdW5pdHkuDQoNCiAgIFRoZSBkb2N1bWVudCBhbHNvIHByb3ZpZGVz IGFuIG92ZXJ2aWV3IG9mIHRoZSB0eXBlcyBvZiBTSVAgc2VydmljZQ0KICAgcHJvdmlkZXJzIGlu dm9sdmVkIGluIHBlZXJpbmcgZm9yIGEgdHlwaWNhbCBTSVAgY2FsbCBhbmQgdGhlIHBvbGljeSwN CiAgIG1ldGhvZHMgYW5kIGFyY2hpdGVjdHVyZSB1c2VkIGZvciBwZWVyaW5nLg0KDQoNCjIuICBU ZXJtaW5vbG9neQ0KDQogICBFYWNoIG9mIHRoZSB0eXBlcyBvZiBTZXJ2aWNlIFByb3ZpZGVycyBk ZWZpbmVkIGJlbG93IGFyZSB3cnQgYQ0KICAgc3Vic2NyaWJlciB3aG8gb3JpZ2luYXRlcyBvciB0 ZXJtaW5hdGVzIGEgU0lQIGNhbGwsIGFzIHNob3duIGluDQogICBGaWd1cmUgMS4NCg0KICAgICAg U2VydmljZSBQcm92aWRlciAoU1ApOiBXZSB1c2UgdGhlIHRlcm0gU2VydmljZSBQcm92aWRlciBp biB0aGlzDQogICAgICBkb2N1bWVudCB0byByZWZlciB0byBhIFNJUCBTZXJ2aWNlIFByb3ZpZGVy WzNdLiAgVGhlIGluZGl2aWR1YWwNCiAgICAgIHR5cGVzIG9mIFNQcyBhcmUgZGVmaW5lZCBiZWxv dy4NCg0KICAgICAgICAgQ29yZSBTUDogQW4gU1Agd2hpY2ggaXMgcmVzcG9uc2libGUgZm9yIGFw cGx5aW5nIHRoZQ0KICAgICAgICAgc3Vic2NyaWJlcidzIHBvbGljeSBmb3IgdGVybWluYXRpb24g b3Igb3JpZ2luYXRpb24gc2VydmljZXMuDQogICAgICAgICBUaGUgY29yZSBTUCBpcyB0eXBpY2Fs bHkgYWxzbyB0aGUgcmVnaXN0cmFyIGZvciB0aGUgdXNlciBhbmQvb3INCiAgICAgICAgIGlzIGF3 YXJlIG9mIHRoZSBjdXJyZW50IEEtTy1SIGJpbmRpbmdzWzFdIG9mIHRoZSB1c2VyLg0KDQogICAg ICAgICBBY2Nlc3MgU1A6IEFuIFNQIHdoaWNoIGFjdHMgYXMgdGhlIGZpcnN0IGhvcCBiZXR3ZWVu IHRoZQ0KICAgICAgICAgc3Vic2NyaWJlciBhbmQgdGhlIENvcmUgU1AuDQoNCiAgICAgICAgIElu dGVyY29ubmVjdCBTUDogQW4gU1Agd2hpY2ggaXMgbm90IHRoZSBDb3JlIG9yIEFjY2VzcyBTUCBh bmQNCiAgICAgICAgIHN0aWxsIGxpZXMgaW4gdGhlIGNhbGwgcGF0aC4NCg0KICAgICAgT3JpZ2lu YXRpb24gU1A6IFRoZSBDb3JlIFNQIGZvciB0aGUgY2FsbCBvcmlnaW5hdG9yLg0KDQogICAgICBU ZXJtaW5hdGlvbiBTUDogVGhlIENvcmUgU1AgZm9yIHRoZSBjYWxsIHRlcm1pbmF0aW9uLg0KDQog ICAgICBBcHBsaWNhdGlvbiBTUCAoQVNQKTogQSBDb3JlIFNQIHdoaWNoIGRvZXMgbm90IHByb3Zp ZGUgdGhlIEFjY2Vzcw0KICAgICAgU1AgZnVuY3Rpb24uDQoNCiAgICAgIERvd25zdHJlYW0gU1Ag KGFsc28gY2FsbGVkIGRvd25zdHJlYW0gcGVlcik6IE5leHQgaG9wIFNQIHdydCB0aGUNCiAgICAg IGRpcmVjdGlvbiBvZiBTSVAgZGlhbG9nIGNyZWF0aW9uIHJlcXVlc3QuDQoNCiAgICAgIFVwc3Ry ZWFtIFNQIChhbHNvIGNhbGxlZCB1cHN0cmVhbSBwZWVyKTogUHJldmlvdXMgaG9wIFNQIHdydCB0 aGUNCiAgICAgIGRpcmVjdGlvbiBvZiBTSVAgZGlhbG9nIGNyZWF0aW9uIHJlcXVlc3QuDQoNCg0K DQoNCg0KDQpCaGF0aWEgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMzAsIDIwMDYg ICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIHNpcC1w ZWVyaW5nLXJvdXRlLXBvbGljeSAgICAgICAgICAgRmVicnVhcnkgMjAwNg0KDQoNCiAgICAgIFJl Z2lzdHJ5OiBBIGRvbWFpbiBzZXJ2ZXIgd2hpY2ggZmFjaWxpdGF0ZXMgU0lQIHBlZXJpbmcgaW5k aXJlY3RseQ0KICAgICAgYnkgcHJvdmlkaW5nIGFkZHJlc3MgbG9jYXRpb24gc2VydmljZXMgYW5k L29yIHBvbGljeS4NCg0KICAgICAgTm90ZSB0aGF0IGFuIFNQIG1heSBzaW11bHRhbmVvdXNseSBw ZXJmb3JtIG1vcmUgdGhhbiBvbmUgcm9sZQ0KICAgICAgaWRlbnRpZmllZCBhYm92ZSBpbiBhIHNp bmdsZSBTSVAgY2FsbCBhbmQgdGhlcmVieSBiZSBhc3NvY2lhdGVkDQogICAgICB3aXRoIG1vcmUg dGhhbiBvbmUgdHlwZSBhYm92ZS4gIEluIHRoaXMgZG9jdW1lbnQsIHdoZXJlIHdlIGFuYWx5emUN CiAgICAgIHBlZXJpbmcgYmV0d2VlbiBTUHMsIHdlIG9ubHkgbG9vayBhdCB0aGUgZm9sbG93aW5n IGNhc2U6DQoNCiAgICAgICAgIFRoZSBPcmlnaW5hdGlvbiBTUCBpcyBkaWZmZXJlbnQgZnJvbSB0 aGUgVGVybWluYXRpb24gU1AsIGV4Y2VwdA0KICAgICAgICAgaW4gdGhlIGNhc2Ugb3V0bGluZWQg aW4gU2VjdGlvbiA1LjUuDQoNCiAgICAgIFNlc3Npb24gQm9yZGVyIENvbnRyb2xsZXI6IEEgU0lQ IEJhY2sgdG8gQmFjayBVQVsxXSB0eXBpY2FsbHkNCiAgICAgIGRlcGxveWVkIGF0IHRoZSBTSVAg bmV0d29yayBlZGdlIHRvIGVuZm9yY2UgcGVlcmluZyBwb2xpY2llcy4NCg0KDQozLiAgR2VuZXJh bCBDYWxsIEZsb3cNCg0KDQogICArLS0tKyAgIC9+fn5+fn5cICAgIC9+fn5+XCAgICAvfn5+fn5+ flwgICAgL35+fn5cICAgIC9+fn5+fn5cICAgKy0tLSsNCiAgIHwgTyB8LT4oQWNjZXNzLU8pLT4o Q29yZS1PKS0+KEludGVyY29ubiktPihDb3JlLVQpLT4oQWNjZXNzLVQpLT58IFQgfA0KICAgKy0t LSsgICBcfn5+fn5+LyAgICBcfn5+fi8gICAgXH5+fn5+fn4vICAgIFx+fn5+LyAgICBcfn5+fn5+ LyAgICstLS0rDQoNCg0KICAgRmlndXJlIDE6IEdlbmVyYWwgQ2FsbCBGbG93IGZvciBQZWVyaW5n DQoNCiAgIEZpZ3VyZSAxIGRlc2NyaWJlcyBhIGZ1bmN0aW9uYWwgcmF0aGVyIHRoYW4gYSBwaHlz aWNhbCBzZXR1cCBmb3IgYQ0KICAgY29tcGxldGUgcGVlci10by1wZWVyIGNhbGwuICBBbGwgU1Bz IGV4Y2VwdCB0aGUgQ29yZSBTUHMgYXJlDQogICBjb25zaWRlcmVkIG9wdGlvbmFsIGZvciB0aGUg cHVycG9zZXMgb2YgdGhpcyBkb2N1bWVudC4gIFRoZSBhcnJvd3MNCiAgIGluZGljYXRlIFNJUCBt ZXNzYWdpbmcgb25seS4NCg0KICAgVGhlIGNhbGwgaXMgb3JpZ2luYXRlZCBhdCBjYWxsaW5nIHBh cnR5ICJPIiwgKGNhbGxlZCB0aGUNCiAgICJPcmlnaW5hdGlvbiIgaW4gdGhpcyBkb2N1bWVudCkg YW5kIHRlcm1pbmF0ZXMgYXQgY2FsbGVkIHBhcnR5ICJUIg0KICAgKGNhbGxlZCB0aGUgIlRlcm1p bmF0aW9uIiBpbiB0aGlzIGRvY3VtZW50KS4gIFQgbWF5IGJlIGEgc3Vic2NyaWJlciwNCiAgIGNv bnRhY3QgY2VudGVyLCBFOTExIG9wZXJhdG9yIGV0Yy4gIFRoZSBmaXJzdCBob3AgYW5kIHRoZSBs YXN0IGhvcCBvZg0KICAgdGhlIGNhbGwgaW4gRmlndXJlIDEgcGFzcyB0aHJvdWdoIFNQcyBwcm92 aWRpbmcgTDUgKGluIG91ciBjYXNlIFNJUCkNCiAgIGFjY2VzcyB0byB0aGUgb3JpZ2luYXRpb24g YW5kIHRlcm1pbmF0aW9uIGFuZCBhcmUgY2FsbGVkIEFjY2Vzcy1PIGFuZA0KICAgQWNjZXNzLVQg cmVzcGVjdGl2ZWx5LiAgSW4gbW9zdCBjYXNlcyB0aGVzZSBTUHMgd2lsbCBhbHNvIHByb3ZpZGUg dGhlDQogICBwaHlzaWNhbCBhY2Nlc3MgdG8gdGhlIG9yaWdpbmF0aW9uIGFuZCB0ZXJtaW5hdGlv biBkZXZpY2VzLiAgVGhlDQogICBBY2Nlc3MgU1AgZnVuY3Rpb24gaXMgbm90IG9wdGlvbmFsLiAg V2hpbGUgYSBzZXBhcmF0ZSBBY2Nlc3MgU1AgbWF5DQogICBub3QgZXhpc3QsIHRoZSBmdW5jdGlv biBtYXkgYmUgYWJzb3JiZWQgYnkgdGhlIGNvcnJlc3BvbmRpbmcgQ29yZSBTUC4NCg0KICAgT25l IHBvaW50IHRvIG5vdGUgYWJvdXQgdGhlIEFjY2VzcyBTUCBpcyB0aGF0IHRoZXJlIG1heSBiZSBt b3JlIHRoYW4NCiAgIG9uZSBBY2Nlc3MgU1Agd2hlbiB0ZXJtaW5hdGluZyBjYWxscyB0byB0aGUg c3Vic2NyaWJlci4gIFRoaXMgY2hvaWNlDQogICBpcyB0eXBpY2FsbHkgZGljdGF0ZWQgYnkgdGhl IHN1YnNjcmliZXIgb3Igc3Vic2NyaWJlciBwb2xpY3kgYXQgdGhlDQogICBDb3JlIFNQLiAgVGhl IENvcmUgU1AgbWF5IGZvcmsgb3IgaHVudCB0aGUgc3Vic2NyaWJlciB1c2luZyB0aGVzZQ0KICAg QWNjZXNzIFNQcy4NCg0KICAgSW4gRmlndXJlIDEsIHRoZSBvcmlnaW5hdGlvbidzIENvcmUgU1Ag aXMgcmVmZXJyZWQgdG8gYXMgIkNvcmUtTyIgU1ANCg0KDQoNCkJoYXRpYSAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAzMCwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgc2lwLXBlZXJpbmctcm91dGUtcG9saWN5ICAgICAgICAg ICBGZWJydWFyeSAyMDA2DQoNCg0KICAgYW5kIHRoZSB0ZXJtaW5hdGlvbnMgQ29yZSBTUCBpcyBy ZWZlcnJlZCB0byBhcyAiQ29yZS1UIiBTUC4NCg0KICAgVW5saWtlIHRoZSBBY2Nlc3MgU1AsIHRo ZSBJbnRlcmNvbm5lY3QgU1AgZnVuY3Rpb24gaXMgdHJ1bHkgb3B0aW9uYWwuDQogICBNb3N0IElu dGVyY29ubmVjdCBTUHMgZXhpc3QgYmVjYXVzZSBpdCBpcyBvcGVyYXRpb25hbGx5IG9yDQogICBj b21tZXJjaWFsbHkgZGlmZmljdWx0IGZvciB0aGUgQ29yZSBTUHMgdG8gY29ubmVjdCBkaXJlY3Rs eS4gIFNvbWUNCiAgIEludGVyY29ubmVjdCBTUHMgYWxzbyBwcm92aWRlICJvbmUgcG9pbnQgY29u bmVjdGl2aXR5IiB3aGVyZSB0aGV5DQogICBwcm92aWRlIHZhbHVlIGFkZGVkIHNlcnZpY2VzIGxp a2Ugb25lIHBvaW50IG9mIG1hbmFnZWQgcGh5c2ljYWwNCiAgIGFjY2VzcywgYmlsbGluZyBhbmQg aW50ZXJ3b3JraW5nLiAgVGhlcmUgbWF5IGJlIG1vcmUgdGhhbiBvbmUNCiAgIEludGVyY29ubmVj dCBTUCBpbiB0aGUgZnVsbCBjYWxsIGZsb3cuICBBbiBJbnRlcmNvbm5lY3QgU1AgbWF5IGFsc28N CiAgIHNpdCBiZXR3ZWVuIHRoZSBBY2Nlc3MgU1BzIGFuZCB0aGUgQ29yZSBTUCwgZXNzZW50aWFs bHkgbWFraW5nIHRoZQ0KICAgQ29yZSBTUCBsb3dlciBsYXllciBhZ25vc3RpYyAodGhlIENvcmUg U1AgY2FuIGJlIGVxdWF0ZWQgbW9yZSB3aXRoIGFuDQogICBBU1AgYXQgdGhhdCBwb2ludCkuDQoN CiAgIFNpbWlsYXIgdG8gdGhlIGF2YWlsYWJsZSBjaG9pY2Ugb2YgQWNjZXNzIFNQcywgdGhlcmUg bWF5IGJlIG1vcmUgdGhhbg0KICAgb25lIEludGVyY29ubmVjdCBTUCB0byB3aGljaCB0aGUgQ29y ZSBTUCBjb3VsZCBjaG9vc2UgdG8gaGFuZC1vZmYgdGhlDQogICBjYWxsLiAgSG93ZXZlciB1bmxp a2UgdGhlIGNhc2Ugb2YgQWNjZXNzIFNQcywgdGhpcyBjaG9pY2UgaXMgc3RyaWN0bHkNCiAgIGRp Y3RhdGVkIGJ5IHRoZSBjb3JlIFNQcyBsb2NhbCBwb2xpY3kuDQoNCg0KNC4gIFJvdXRpbmcgQXJj aGl0ZWN0dXJlcw0KDQogICBUaGUgZ2VuZXJhbCBjYWxsIGZsb3cgZGVwaWN0ZWQgYWJvdmUgeWll bGRzIHRoZSBmb2xsb3dpbmcgZ2VuZXJhbA0KICAgY2xhc3NpZmljYXRpb24gb2YgcGVlcmluZyBh cmNoaXRlY3R1cmVzIGluIHVzZToNCg0KICAgMS4gIERpcmVjdCBQZWVyaW5nOiBEaXJlY3QgUGVl cmluZyBpcyB0aGUgcGVlcmluZyBiZXR3ZWVuIENvcmUtTyBhbmQNCiAgICAgICBDb3JlLVQgd2l0 aG91dCBhbnkgb3RoZXIgU0lQIFNQIGluIHRoZSBtaWRkbGUuICBJdCB0eXBpY2FsbHkNCiAgICAg ICB0YWtlcyBvbmUgb2YgdHdvIGZvcm1zIGRlcGVuZGluZyBvbiBob3cgc29tZSBwYXJ0IG9mIHRo ZSBwZWVyaW5nDQogICAgICAgcG9saWN5IG1heSBiZSBwcm92aXNpb25lZDoNCg0KICAgICAgICAg IEZlZGVyYXRpb246IEEgZmVkZXJhdGlvbiBpcyB0eXBpY2FsbHkgYSBzZXQgb2YgU1BzIHdoaWNo IGFyZQ0KICAgICAgICAgIHRlcm1pbmF0aW5nIGNhbGxzIHRvIGVhY2ggb3RoZXIgdXNpbmcgc29t ZSB3ZWxsIGtub3duDQogICAgICAgICAgbWVjaGFuaXNtcyBmb3Igc2V0dGxlbWVudCwgYWRkcmVz cyBsb2NhdGlvbiBhbmQgc29tZSBvdGhlcg0KICAgICAgICAgIGNvbW1vbiBhZG1pbmlzdHJhdGl2 ZSBwb2xpY2llcy4gIEluIG1vc3QgY2FzZXMgdGhlIHBlZXJpbmcgU1BzDQogICAgICAgICAgYXJl IGNvbm5lY3RlZCB0byBhIHRydXN0ZWQgcHJpdmF0ZSBuZXR3b3JrIGFuZCB0cnVzdCBhbGwgY2Fs bHMNCiAgICAgICAgICB0ZXJtaW5hdGluZyBvbiB0aGVtIG92ZXIgdGhpcyBuZXR3b3JrLg0KDQog ICAgICAgICAgICAgRmVkZXJhdGlvbnMgdHlwaWNhbGx5IHVzZSBFTlVNIGFzIHRoZSByZWdpc3Ry eSBkYXRhYmFzZQ0KICAgICAgICAgICAgIChvd25lZCBieSB0aGUgZmVkZXJhdGlvbiBvciBhIHRy dXN0ZWQgdGhpcmQgcGFydHkpIHRvDQogICAgICAgICAgICAgcHJvdmlkZSBhZGRyZXNzIGxvY2F0 aW9uIHNlcnZpY2VzIGFuZCBhcHBsaWNhdGlvbnMgbGlrZQ0KICAgICAgICAgICAgIG51bWJlciBw b3J0YWJpbGl0eS4gIE90aGVyIGFzcGVjdHMgb2YgdGhlIHJvdXRpbmcgcG9saWN5DQogICAgICAg ICAgICAgKGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUpIGFyZSBpbXBsZW1lbnRlZCB1c2luZyBl ZGdlDQogICAgICAgICAgICAgcHJveGllcyBvciBzZXNzaW9uIGJvcmRlciBjb250cm9sbGVycyAo U2VjdGlvbiA0LjEpLg0KDQogICAgICAgICAgTG9jYWwgUG9saWN5OiBUaGUgcGVlcmluZyBTUHMg bWF5IHByb3Zpc2lvbiByb3V0ZXMgdG8gZWFjaA0KICAgICAgICAgIG90aGVyIHVzaW5nIGxvY2Fs IHBvbGljeSBhbmQgb25seSBhY2NlcHQgY2FsbHMgZnJvbSBwYXJ0bmVycw0KICAgICAgICAgIHBy b3Zpc2lvbmVkIGluIGxvY2FsIHBvbGljeS4NCg0KDQoNCg0KDQpCaGF0aWEgICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMzAsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgIHNpcC1wZWVyaW5nLXJvdXRlLXBvbGljeSAgICAgICAg ICAgRmVicnVhcnkgMjAwNg0KDQoNCg0KICAgMi4gIFBlZXJpbmcgdGhyb3VnaCBJbnRlcmNvbm5l Y3QgU1BzOiBJbiBtb3N0IGNhc2VzIHRoaXMgbW9kZWwgaXMNCiAgICAgICB1c2VkIHdoZW4gdGhl IENvcmUtTyBTUCBwcmVmZXJzIG5vdCB0byBkaXJlY3RseSBjb25uZWN0IHRvIGENCiAgICAgICBD b3JlLVQgU1AgZHVlIHRvIGJ1c2luZXNzIHJlYXNvbnMuICBGb3IgZXhhbXBsZSwgdGhlIENvcmUt VCBTUA0KICAgICAgIG1heSBiZSB0b28gc21hbGwsIG1ha2luZyB0aGUgcmVsYXRpb25zaGlwIGV4 cGVuc2l2ZSBmb3IgdGhlDQogICAgICAgQ29yZS1PIFNQIG9yIHZpY2UtdmVyc2EuICBBbiBJbnRl cmNvbm5lY3QgU1AgbWF5IGFsc28gYmUgdXNlZA0KICAgICAgIGJldHdlZW4gdGhlIGFjY2VzcyBT UHMgYW5kIHRoZSBjb3JyZXNwb25kaW5nIENvcmUgU1BzIGR1ZSB0bw0KICAgICAgIHNpbWlsYXIg cmVhc29ucy4NCg0KICAgICAgICAgIEl0IHNob3VsZCBiZSB3b3J0aCBub3RpbmcgdGhhdCBhbiBJ bnRlcmNvbm5lY3QgU1AgbWF5IHVzZSBhbg0KICAgICAgICAgIEVOVU0gUmVnaXN0cnkgZGF0YWJh c2UgdG8gcHJvdmlkZSBhZGRyZXNzIGxvY2F0aW9uIHNlcnZpY2VzIGFzDQogICAgICAgICAgd2Vs bC4gIFRoaXMgY291bGQgYmUgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgc2ltdWx0YW5lb3VzIHVz ZQ0KICAgICAgICAgIG9mIEVOVU0gYXQgb3RoZXIgcG9pbnRzIG9mIHRoZSBjYWxsIGZvciBhZGRy ZXNzIGxvY2F0aW9uDQogICAgICAgICAgKHVzdWFsbHkgUHJpdmF0ZSBFTlVNWzNdIGlzIHVzZWQp Lg0KDQogICAzLiAgQWNjZXNzIFBlZXJpbmc6IEFjY2VzcyBQZWVyaW5nIG1heSB0eXBpY2FsbHkg YmUgdXNlZCB3aGVuIHRoZQ0KICAgICAgIHN1YnNjcmliZXIgcm9hbXMgdG8gYSBwbGFjZSB0aGUg Q29yZSBTUCBkb2VzIG5vdCBvZmZlciBzZXJ2aWNlIG9yDQogICAgICAgaXMgdXNpbmcgYSBMYXll ciA1IChTSVApIGF3YXJlIFNQIHRvIGNvbm5lY3QgdG8gaXRzIENvcmUgU1ANCiAgICAgICAod2hp Y2ggbWF5IGJlIGFuIEFTUCBvciBjb250ZW50IHByb3ZpZGVyKS4NCg0KICAgICAgICAgIFRoZSBs b2NhdGlvbiBvZiB0aGUgQ29yZSBTUCBpcyB1c3VhbGx5IGJhc2VkIG9uIEROUy4gIEluIHRoaXMN CiAgICAgICAgICBjYXNlIHRoZSBBY2Nlc3MgU1AgaXMgdHJ5aW5nIHRvIGxvY2F0ZSB0aGUgb3Jp Z2luYXRpb25zIENvcmUNCiAgICAgICAgICBTUCByYXRoZXIgdGhhbiB0aGUgdGVybWluYXRpb24n cyBDb3JlIFNQIChjb21wYXJlIHdpdGggdGhlIHVzZQ0KICAgICAgICAgIG9mIEVOVU0pLg0KDQo0 LjEuICBVc2Ugb2YgRWRnZSBQcm94aWVzIGFuZCBTZXNzaW9uIEJvcmRlciBDb250cm9sbGVycw0K DQogICBFZGdlIFByb3hpZXMgLyBTZXNzaW9uIEJvcmRlciBDb250cm9sbGVycyBhcmUgcXVpdGUg d2lkZWx5IHVzZWQgZm9yDQogICBpbXBsZW1lbnRpbmcgdGhlIHJvdXRlIHBvbGljaWVzIGluIFNJ UCBwZWVyaW5nIGVudmlyb25tZW50cyAoYXMNCiAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50 KS4gIEZ1bmN0aW9ucyBvZiBTQkNzIG5vdCByZWxhdGVkIHRvIHJvdXRlDQogICBwb2xpY3kgYXJl IG5vdCB0aGUgc3ViamVjdCBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBJbiBzb21lIGNhc2VzLCB0 aGUgRWRnZSBQcm94eS9TQkMgbWF5IGFsc28gdXNlIG1lZGlhIHN0ZWVyaW5nIChvcg0KICAgcm91 dGluZykgd2hlbiBwZWVyaW5nIHdpdGggYW5vdGhlciBTUCBpbiB3aGljaCBjYXNlIG1lZGlhIGFz c29jaWF0ZWQNCiAgIHdpdGggdGhlIHNlc3Npb24gaXMgY291cGxlZCBhbG9uZyB3aXRoIHRoZSBw YXRoIHRha2VuIGJ5IFNJUA0KICAgc2lnbmFsaW5nICh0aGUgcGVlcmluZyBTUHMgZ2VuZXJhbGx5 IG5lZWQgdG8gaGF2ZSBhIGNvbW1vbg0KICAgdW5kZXJzdGFuZGluZyBvbiByZXF1aXJlZCBuZXR3 b3JrIHJlc291cmNlcyBhbmQgUW9TIGZvciBtZWRpYSkuDQogICBXaGlsZSB0aGVyZSBtYXkgYmUg b3RoZXIgcmVxdWlyZW1lbnRzIGZvciBjb3VwbGluZyBtZWRpYSBhbmQNCiAgIHNpZ25hbGluZywg d2Ugd2lsbCBvbmx5IGxvb2sgYXQgdGhvc2UgYWZmZWN0aW5nIHJvdXRlIHBvbGljeSBpbiB0aGlz DQogICBkb2N1bWVudC4gIFNlZSBTZWN0aW9uIDUuMy4yIGZvciB0aGVzZSByZXF1aXJlbWVudHMu ICBVbmxlc3MgcmVxdWlyZWQNCiAgIGZvciBhbm90aGVyIGFwcGxpY2F0aW9uIChsaWtlIFFvUyBv ciByZWd1bGF0b3J5KSwgbWVkaWEgc3RlZXJpbmcgbWF5DQogICBiZSBhdm9pZGVkLCBlc3BlY2lh bGx5IHdoZW4gU1BzIHJvdXRlIHBvbGljeSBpcyBub3QgYWZmZWN0ZWQgYnkgdGhlDQogICBpbmZv cm1hdGlvbiBnYXRoZXJlZCB0aHJvdWdoIG1lZGlhIGV4YW1pbmF0aW9uIG9yIHRoZSBzYW1lDQog ICBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgdGhyb3VnaCBvdGhlciByZWxpYWJsZSBtZWFucy4N Cg0KDQo1LiAgUmVxdWlyZW1lbnRzIGZvciByb3V0ZSBwb2xpY3kgYW5kIGFyY2hpdGVjdHVyZSBm b3IgcGVlcmluZw0KDQoNCg0KDQpCaGF0aWEgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMzAsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgIHNpcC1wZWVyaW5nLXJvdXRlLXBvbGljeSAgICAgICAgICAgRmVicnVhcnkgMjAwNg0K DQoNCiAgIEluIHRoaXMgc2VjdGlvbiB3ZSBsb29rIGF0IHJlcXVpcmVtZW50cyBhbmQgZmFjdG9y cyB3aGljaCBhZmZlY3QNCiAgIHJvdXRlIHBvbGljeSBhbmQgYXJjaGl0ZWN0dXJlIHVzZWQgZm9y IHBlZXJpbmcuICBXZSBmaXJzdCBlbnVtZXJhdGUNCiAgIHNvbWUgb2YgdGhlIGZhY3RvcnMgYW5k IHRoZW4gZG8gYSBtb3JlIGluLWRlcHRoIGFuYWx5c2lzOg0KDQogICAxLiAgVHlwZSBvZiBvdXRn b2luZyBwZWVyOiBGb3IgZXhhbXBsZSwgd2hldGhlciB0aGUgY2FsbCBpcyBoYW5kZWQNCiAgICAg ICBvZmYgdG8gdGhlIENvcmUtVCBTUCBvciBhbiBJbnRlcmNvbm5lY3QgU1AuDQogICAyLiAgQWRk cmVzc2luZzogV2hldGhlciB0aGUgYWRkcmVzcyBvZiByZWNvcmQgb2YgdGhlIHRlcm1pbmF0aW9u IGlzDQogICAgICAgYW4gRS4xNjQgYWRkcmVzcyBvciBhIGdlbmVyaWMgQU9SIChlLmcgZm9vQGJh ci5jb20pDQogICAzLiAgQnVzaW5lc3MgcmVhc29uczogRm9yIGV4YW1wbGUsIGFueSBjb3N0cyBh biBTUCBtdXN0IHBheSB0bw0KICAgICAgIHRlcm1pbmF0ZSB0aGUgY2FsbCB0aHJvdWdoIGEgZ2l2 ZW4gcGVlci4gIFRoZSBTUCBtYXkgYWxzbyBiZQ0KICAgICAgIHJlcXVpcmVkIHRvIGZ1bGZpbGwg YW55IHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50cyBvbiBiZWhhbGYgb2YNCiAgICAgICBzdWJzY3Jp YmVyIHBvbGljeSBvciBsZXZlbCBvZiBzZXJ2aWNlLg0KICAgNC4gIExvY2FsIE5ldHdvcmsgUG9s aWN5OiBBIFNQIG1heSBoYXZlIHRvIGFiaWRlIGJ5IGxvY2FsIHBvbGljeQ0KICAgICAgIGFwcGxp Y2FibGUgdG8gbmV0d29yayBhc3NldHMsIGJhbmR3aWR0aCBlbmdpbmVlcmluZywgc2VjdXJpdHkN CiAgICAgICBldGMuDQogICA1LiAgUmVndWxhdG9yeSByZXF1aXJlbWVudHM6IEZvciBleGFtcGxl LCBpbiB0aGUgVS5TIEVxdWFsIEFjY2VzcyBhbmQNCiAgICAgICBMYXdmdWwgSW50ZXJjZXB0IG1h eSBnb3Zlcm4gc29tZSBhc3BlY3RzIG9mIGNhbGwgcm91dGluZy4gIFRoZQ0KICAgICAgIHByaW9y aXR5IG9mIHRoZSBjYWxsLCBmb3IgZXhhbXBsZSBFOTExIG9yIEdFVFMgKEdvdmVybm1lbnQNCiAg ICAgICBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb25zIFNlcnZpY2UpIGNhbGxzIGluIHRoZSBV LlMuDQoNCiAgIE90aGVyIGZhY3RvcnMsIGZvciBleGFtcGxlLCAoaSkgcGh5c2ljYWwgZGV2aWNl IChsZWdhY3kvd2lyZWxlc3MvDQogICBjZWxsL3NpcCkgdXNlZCBieSB0ZXJtaW5hdGlvbiBvciBv cmlnaW5hdGlvbiBvciAoaWkpIHRoZSB0eXBlIG9mDQogICBpbmNvbWluZyBwZWVyIChDb3JlLU8g b3IgSW50ZXJjb25uZWN0IFNQKSBkbyBub3Qgc2VlbSB0byBhZmZlY3Qgcm91dGUNCiAgIHBvbGlj eSB0byBhIGdyZWF0IGV4dGVudC4NCg0KICAgV2Ugbm93IGludmVzdGlnYXRlIHNvbWUgb2YgdGhl c2UgaW4gZ3JlYXRlciBkZXRhaWwuDQoNCjUuMS4gIFR5cGUgb2Ygb3V0Z29pbmcgcGVlcg0KDQog ICBUaGUgdHlwZSBvZiBvdXRnb2luZyBwZWVyIChDb3JlIHYvcyBJbnRlcmNvbm5lY3QpIGFmZmVj dHMgdGhlIHBvbGljeQ0KICAgaW4gYXQgbGVhc3QgdHdvIHdheXM6IEZpcnN0LCBpdCBhZmZlY3Rz IGhvdyBhbiBTUCB3b3VsZCBoYW5kbGUNCiAgIGV4Y2VwdGlvbiBzaXR1YXRpb25zIHdoZW4gYXR0 ZW1wdGluZyB0byB0ZXJtaW5hdGUgYSBjYWxsIHRvIHRoZSBwZWVyLg0KICAgRm9yIGV4YW1wbGUs IGlmIHRoZSBjYWxsIGZhaWxzLCB0aGUgU1AgY291bGQgYXR0ZW1wdCB0byBodW50IGluIGNhc2UN CiAgIHRoZSBwZWVyIHdhcyBhbiBJbnRlcmNvbm5lY3QgU1AuICBUaGlzIG1heSBub3QgYmUgbmVj ZXNzYXJ5IHdoZW4gdGhlDQogICBwZWVyIGlzIHRoZSB0ZXJtaW5hdGlvbidzIGNvcmUtVCBTUCAo d2hvIG1heSBrbm93IHRoZSBzdWJzY3JpYmVyJ3MNCiAgIGJ1c3kgc3RhdHVzKS4gIFNlY29uZCwg dGhpcyBhbHNvIGFmZmVjdHMgaG93IGFkZHJlc3MgbG9jYXRpb24gbWF5IGJlDQogICBkb25lLiAg SW4gbW9zdCBjYXNlcyB3aGVuIHRlcm1pbmF0aW5nIGNhbGxzIGRpcmVjdGx5IHRvIHRoZQ0KICAg dGVybWluYXRpb24ncyBDb3JlIFNQLCBFTlVNIGlzIHZpYWJsZS4gIFRoaXMgaXMgbGVzcyB0aGUg Y2FzZSB3aGVuDQogICBoYW5kaW5nIG9mZiB0aGUgY2FsbHMgdG8gYW4gSW50ZXJjb25uZWN0IFNQ Lg0KDQo1LjIuICBBZGRyZXNzaW5nDQoNCiAgIFRoZSB0eXBlIG9mIEEtTy1SIGZvciB0aGUgdGVy bWluYXRpb24gbWF5IGFsc28gYWZmZWN0IHdoYXQga2luZCBvZg0KICAgYWRkcmVzcyBsb2NhdGlv biBzZXJ2aWNlIGlzIHVzZWQuICBBZGRyZXNzIGxvY2F0aW9uIGlzIGRvbmUgdHlwaWNhbGx5DQog ICBiYXNlZCBvbiB0aGUgZm9sbG93aW5nIGZvdXIgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSB0ZXJt aW5hdGlvbidzIEFPUi4NCiAgIEluIGVhY2ggY2FzZSwgd2UgbGlzdCB0aGUgbW9zdCBjb21tb24g YWRkcmVzcyBsb2NhdGlvbiBtZXRob2QgdXNlZC4NCg0KDQoNCg0KDQpCaGF0aWEgICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMzAsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgN10N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIHNpcC1wZWVyaW5nLXJvdXRlLXBvbGljeSAgICAg ICAgICAgRmVicnVhcnkgMjAwNg0KDQoNCiAgIDEuICBGdWxsIEUuMTY0OiBFTlVNIG9yIFNQJ3Mg bG9jYWwgcG9saWN5IG1heSBiZSB1c2VkLg0KICAgMi4gIEUuMTY0IHByZWZpeGVzOiBTUHMgbG9j YWwgcG9saWN5IGlzIGdlbmVyYWxseSB1c2VkLg0KICAgMy4gIEZ1bGwgQS1PLVI6IFRoaXMgaXMg cmFyZWx5IHVzZWQgZm9yIHJvdXRpbmcgaW4gYSBwZWVyaW5nDQogICAgICAgZW52aXJvbm1lbnQu DQogICA0LiAgRG9tYWluIG9mIEEtTy1SOiBETlMgU1JWIG9yIFNQcyBsb2NhbCBwb2xpY3kgbWF5 IGJlIHVzZWQuDQoNCjUuMy4gIEJ1c2luZXNzIFJlcXVpcmVtZW50cw0KDQogICBUaGUgU1BzIGJ1 c2luZXNzIHJlcXVpcmVtZW50cyBoYXZlIHRoZSBtb3N0IGRlY2lkZWQgaW1wYWN0IG9uIHRoZQ0K ICAgcm91dGUgcG9saWN5IGFuZCBhcmNoaXRlY3R1cmUuICBXZSBoYXZlIHRyaWVkIHRvIGJyZWFr IGRvd24gdGhlDQogICBidXNpbmVzcyByZXF1aXJlbWVudHMgaW4gdGhlIGZvbGxvd2luZyBjYXRl Z29yaWVzIGFuZCB0aGUgbWV0aG9kcw0KICAgdXNlZCBpbiBlYWNoIGNhc2U6DQoNCjUuMy4xLiAg Q29zdCBvciBQcm9maXQNCg0KICAgVGhpcyBpcyBhcHBsaWNhYmxlIG1vc3Qgb2YgdGhlIHRpbWUg d2hlbiBhIGNhbGwgaXMgYmVpbmcgaGFuZGVkIG9mZg0KICAgdG8gYW4gSW50ZXJjb25uZWN0IG5l dHdvcmsgYW5kIHRoZXJlIGFyZSBtdWx0aXBsZSBjaG9pY2VzLiAgVGhlIFNQDQogICB3aWxsIHRy eSB0byBwcmlvcml0aXplICJyb3V0ZXMiIG9yIHVzZSBvdGhlciBjcml0ZXJpYSBsaWtlICJ0aW1l IG9mDQogICBkYXkgcm91dGluZyIgYmFzZWQgb24gYnVzaW5lc3MgYWdyZWVtZW50cyBlc3RhYmxp c2hlZCB3aXRoIHRoZSBwZWVycw0KICAgYW5kL29yIGtub3duIHRyYWZmaWMgcGF0dGVybnMgdG8g dGhlICJyZWdpb24iIHdoZXJlIHRoZSB0ZXJtaW5hdGlvbg0KICAgYmVsb25ncy4NCg0KNS4zLjIu ICBTTEFzDQoNCiAgIFRoZXJlIGFyZSBzZXZlcmFsIGtpbmRzIG9mIFNMQXMgd2hpY2ggYW4gU1Ag bWF5IGhhdmUgZWl0aGVyIHdpdGggdGhlDQogICBzdWJzY3JpYmVyIG9yIHRoZSBwZWVyIGhhbmRp bmcgb2ZmIHRoZSBjYWxsIHRvIHRoZSBTUCBpbiBxdWVzdGlvbi4NCiAgIEhlcmUgd2Ugd2lsbCBi cmllZmx5IGRlc2NyaWJlIFFvUyBhbmQgU2VjdXJpdHkgYmFzZWQgU0xBcy4NCg0KNS4zLjIuMS4g IFFvUw0KDQogICBBbiBTUCBtYXkgdXNlIG9uZSBvciBtb3JlIG1lYXN1cmVzIG9mIG5ldHdvcmsg cXVhbGl0eSwgZm9yIGV4YW1wbGUNCiAgIEFTUiAoQW5zd2VyIFNlaXp1cmUgUmF0aW8pWzRdLCBQ REQgKFBvc3QgRGlhbCBEZWxheSkgb3IgbWVkaWENCiAgIGluZm9ybWF0aW9uIChsaWtlIHBhY2tl dCBsb3NzLCBqaXR0ZXIsIGxhdGVuY3ksIE1PU1s1XSkgdG8gY2hvb3NlDQogICBiZXR3ZWVuIGRp ZmZlcmVudCBwZWVycyBmb3IgY2FsbCBoYW5kb2ZmLg0KDQo1LjMuMi4yLiAgU2VjdXJpdHkNCg0K ICAgVGhlIGNhcGFiaWxpdGllcyBvZiBkb3duc3RyZWFtIHBlZXJzIHRvIHRyYW5zbWl0IHVzZXIg aWRlbnRpdHlbMl0NCiAgIHNlY3VyZWx5LCBlbmNyeXB0IHNpZ25hbGluZyAoZS5nIFRMUykgYW5k IGhlbHAgaW4gU1BBTSBwcmV2ZW50aW9uIG1heQ0KICAgYWxzbyBiZSB1c2VkIHRvIGRldGVybWlu ZSB3aGljaCBwZWVyIHRvIGhhbmQgb2ZmIHRoZSBjYWxsIHRvLg0KDQo1LjMuMy4gIEJ1bmRsaW5n IG9mIGNhbGxzIGZvciByb3V0ZSBkZXRlcm1pbmF0aW9uIHB1cnBvc2VzDQoNCiAgIEluIHNvbWUg Y2FzZXMgdGhlIGRvd25zdHJlYW0gcGVlciBtYXkgcmVxdWlyZSBncm91cGluZyBvZiBjYWxscyBi YXNlZA0KICAgb24gc2VydmljZSBjbGFzc2VzIG9yIHNpbWlsYXIgY3JpdGVyaWEuICBTUCBwZWVy cyBtYXkgcGFzcyB0aGlzDQogICBpbmZvcm1hdGlvbiB0b3dhcmRzIGVhY2ggb3RoZXIgdXNpbmcg aWRlbnRpZmllcnMgbGlrZSBDSUMgY29kZXMsDQogICBUcnVuayBHcm91cHMgZXRjLiAgVGhlc2Ug aWRlbnRpZmllcnMgYXJlIHRoZW4gaW50ZXJwcmV0ZWQgYXMgc2VydmljZQ0KICAgaWRlbnRpZmll cnMgb3Igcm91dGUgaWRlbnRpZmllcnMgaW4gdGhlIFNQIG5ldHdvcmsgZm9yIHJvdXRpbmcuDQoN Cg0KDQpCaGF0aWEgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMzAsIDIwMDYgICAg ICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIHNpcC1wZWVy aW5nLXJvdXRlLXBvbGljeSAgICAgICAgICAgRmVicnVhcnkgMjAwNg0KDQoNCjUuNC4gIExvY2Fs IE5ldHdvcmsgUG9saWN5DQoNCiAgIExvY2FsIG5ldHdvcmsgcG9saWN5IHJlbGF0ZWQgdG8gYWRt aXNzaW9uIGNvbnRyb2wsIGZvciBleGFtcGxlLA0KICAgcG9saWNpZXMgcmVsYXRlZCB0byBuZXR3 b3JrIGFuZC9vciBsaW5rIGJhbmR3aWR0aCwgZXF1aXBtZW50DQogICBjYXBhY2l0eS9zY2FsZSBl dGMgbWF5IGFmZmVjdCB3aGljaCBwZWVyKHMpIGFyZSBjaG9zZW4gZm9yIGNhbGwNCiAgIGhhbmRv ZmYuDQoNCjUuNS4gIFJlZ3VsYXRvcnkgUmVxdWlyZW1lbnRzDQoNCiAgIEVhY2ggY291bnRyeSBn ZW5lcmFsbHkgaGFzIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzIGVxdWl2YWxlbnQgdG8NCiAgIEU5 MTEsIENBTEVBIG9yIEVxdWFsIEFjY2Vzcy4gIEluIHNvbWUgY2FzZXMgYW4gU1AgbWF5IGFsc28g YmUNCiAgIHJlcXVpcmVkIHRvIHNhdGlzZnkgdGhlc2UgcmVxdWlyZW1lbnRzLiAgRm9yIGV4YW1w bGUgRXF1YWwgQWNjZXNzIGlzDQogICBhIExFQyAoTG9jYWwgRXhjaGFuZ2UgQ2FycmllcikgcmVx dWlyZW1lbnQgYW5kIGFuIFNQIG9wZXJhdGluZyBhcyBhbg0KICAgTEVDIG1heSBiZSByZXF1aXJl ZCB0byBhbGxvdyB0aGUgc3Vic2NyaWJlciBoaXMvaGVyIGNob2ljZSBvZiBJWEMNCiAgIChJbnRl cmVYY2hhbmdlIENhcnJpZXIpIGZvciBjZXJ0YWluIHNldCBvZiBjYWxscy4gIEluIGVzc2VuY2Us IHRoZXNlDQogICByZXF1aXJlbWVudHMgbWF5IGFmZmVjdCByb3V0ZSBwb2xpY3kgZm9yIHBlZXJp bmcgd2hlcmUgdGhlIGRvd25zdHJlYW0NCiAgIHBlZXIgaXMgY2hvc2VuIGJhc2VkIG9uIG9yaWdp bmF0aW9uJ3MgcG9saWN5LiAgSW4gdGhpcyBjYXNlLCB0aGUNCiAgIENvcmUtTyBhbmQgQ29yZS1U IG1heSBiZSBvbmUgYW5kIHRoZSBzYW1lIFNQIHdobyBwZWVyIHRocm91Z2ggYW4NCiAgIEludGVy Y29ubmVjdCBTUCBvZiB0aGUgb3JpZ2luYXRpb24ncyBjaG9pY2UuDQoNCiAgIFJlZ3VsYXRvcnkg cmVxdWlyZW1lbnRzIG1heSBnZW5lcmFsbHkgbGVhZCB0byBjYWxscyBiZWluZyBibG9ja2VkIG9y DQogICByb3V0ZWQgdGhyb3VnaCBzcGVjaWZpYyBwYXRocyBhcyB3ZWxsLiAgSXQgaXMgcXVpdGUg cG9zc2libGUgdGhhdA0KICAgcmVndWxhdG9yeSByZXF1aXJlbWVudHMgd2lsbCBhZmZlY3QgYSBz bWFsbCBwZXJjZW50YWdlIG9mIFNJUCBiYXNlZA0KICAgcGVlcmluZyBpbiB0aGUgZnV0dXJlLg0K DQoNCjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQoNCjcuICBJQU5BIENvbnNpZGVyYXRp b25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgaGFzIG5vIElBTkEgY29uc2lkZXJhdGlvbnMuDQoNCg0K OC4gIEFja25vd2xlZGdlbWVudHMNCg0KICAgU3BlY2lhbCB0aGFua3MgdG8gQW5kcmV3IENvbGJ5 IGFuZCBCb2IgTmF0YWxlIGZvciB0aGVpciB2YWx1YWJsZQ0KICAgY29tbWVudHMgb24gdGhpcyBk cmFmdCB2ZXJzaW9uLg0KDQoNCjkuICBSZWZlcmVuY2VzDQoNCjkuMS4gIE5vcm1hdGl2ZSBSZWZl cmVuY2VzDQoNCiAgIFsxXSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBDYW1hcmls bG8sIEcuLCBKb2huc3RvbiwgQS4sDQogICAgICAgIFBldGVyc29uLCBKLiwgU3BhcmtzLCBSLiwg SGFuZGxleSwgTS4sIGFuZCBFLiBTY2hvb2xlciwgIlNJUDoNCiAgICAgICAgU2Vzc2lvbiBJbml0 aWF0aW9uIFByb3RvY29sIiwgUkZDIDMyNjEsIEp1bmUgMjAwMi4NCg0KDQoNCg0KQmhhdGlhICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDMwLCAyMDA2ICAgICAgICAgICAgICAgIFtQ YWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBzaXAtcGVlcmluZy1yb3V0ZS1wb2xp Y3kgICAgICAgICAgIEZlYnJ1YXJ5IDIwMDYNCg0KDQogICBbMl0gIFBldGVyc29uLCBKLiBhbmQg Qy4gSmVubmluZ3MsICJFbmhhbmNlbWVudHMgZm9yIEF1dGhlbnRpY2F0ZWQNCiAgICAgICAgSWRl bnRpdHkgTWFuYWdlbWVudCBpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp IiwNCiAgICAgICAgSS1EIGRyYWZ0LWlldGYtc2lwLWlkZW50aXR5LTA2LCBPY3RvYmVyIDIwMDUu DQoNCiAgIFszXSAgTWV5ZXIsIEQuLCAiU1BFRVJNSU5UIFJlcXVpcmVtZW50cyBhbmQgVGVybWlu b2xvZ3kiLA0KICAgICAgICBJLUQgZHJhZnQtaWV0Zi1zcGVlcm1pbnQtcmVxcy1hbmQtdGVybWlu b2xvZ3ktMDAsIEZlYnJ1YXJ5IDIwMDYuDQoNCjkuMi4gIEluZm9ybWF0aW9uYWwgUmVmZXJlbmNl cw0KDQogICBbNF0gICJJVFUgRS40MTEgSW50ZXJuYXRpb25hbCBOZXR3b3JrIE1hbmFnZW1lbnQi LCBNYXJjaCAyMDAwLg0KDQogICBbNV0gICJJVFUgUC44NjIgUGVyY2VwdHVhbCBFdmFsdWF0aW9u IG9mIFNwZWVjaCBRdWFsaXR5IChQRVNRKSIsDQogICAgICAgIEZlYnJ1YXJ5IDIwMDEuDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KQmhhdGlhICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDMw LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICBzaXAtcGVlcmluZy1yb3V0ZS1wb2xpY3kgICAgICAgICAgIEZlYnJ1YXJ5IDIwMDYNCg0KDQpB dXRob3IncyBBZGRyZXNzDQoNCiAgIE1lZGhhdmkgQmhhdGlhDQogICBOZXhUb25lIENvbW11bmlj YXRpb25zDQogICAxMDEgT3JjaGFyZCBSaWRnZSBEcml2ZQ0KICAgR2FpdGhlcnNidXJnLCBNRCAg MjA4NzgNCiAgIFVTDQoNCiAgIEVtYWlsOiBtYmhhdGlhQG5leHRvbmUuY29tDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpCaGF0aWEgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MzAsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgIHNpcC1wZWVyaW5nLXJvdXRlLXBvbGljeSAgICAgICAgICAgRmVicnVhcnkgMjAwNg0KDQoN CkludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8g cG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVs bGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xh aW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0 ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRv IHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBu b3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1h ZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJ bmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBp biBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoN CiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlh dCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxl LCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJh bCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRh cnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0 aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkg YXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFu eSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5 cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0 YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1 aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUg aW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkRp c2NsYWltZXIgb2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lz IGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMN CiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5E IFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FS UkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRF RCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5GT1JNQVRJT04gSEVS RUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJB TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ T1NFLg0KDQoNCkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50 ZXJuZXQgU29jaWV0eSAoMjAwNikuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRo ZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwg YW5kDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBh bGwgdGhlaXIgcmlnaHRzLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRo ZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIElu dGVybmV0IFNvY2lldHkuDQoNCg0KDQoNCkJoYXRpYSAgICAgICAgICAgICAgICAgICBFeHBpcmVz IEF1Z3VzdCAzMCwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0K ------_=_NextPart_001_01C63E27.D34B811F 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_01C63E27.D34B811F-- From speermint-bounces@ietf.org Thu Mar 02 13:42:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEskh-00016c-Ac; Thu, 02 Mar 2006 13:42:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEskg-00016X-2D for speermint@ietf.org; Thu, 02 Mar 2006 13:42:14 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEske-00023W-Fe for speermint@ietf.org; Thu, 02 Mar 2006 13:42:14 -0500 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.17362934; Thu, 02 Mar 2006 13:41:43 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 13:41:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C63E28.F30A2FBB" Date: Thu, 2 Mar 2006 13:41:42 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A43A@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-khan-ip-serv-peer-arch-00 Thread-Index: AcYuVzDueBeIXn7ARwKNsvLbjhodcgNUSdzQAKATRIA= X-Priority: 1 Priority: Urgent Importance: high From: "Livingood, Jason" To: X-OriginalArrivalTime: 02 Mar 2006 18:41:43.0066 (UTC) FILETIME=[F3731FA0:01C63E28] X-Spam-Score: 0.1 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Subject: [Speermint] draft-khan-ip-serv-peer-arch-00 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_01C63E28.F30A2FBB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also FYI. This may be added to the draft agenda, TBD shortly. =20 Jason PS - Please note that all of the previous I-Ds, as well as this one, are in the I-D editor's queue. Posting here to give folks some extra time in advance of the meeting to read all of these new documents. ------_=_NextPart_001_01C63E28.F30A2FBB Content-Type: text/plain; name="draft-khan-ip-serv-peer-arch-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-khan-ip-serv-peer-arch-00.txt Content-Disposition: attachment; filename="draft-khan-ip-serv-peer-arch-00.txt" DQpTcGVlcm1pbnQgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTb2hlbCBLaGFuLCBTcHJpbnQNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYi4gMjYsIDMwMDYNCkV4cGlyZXM6IEF1Z3Vz dCAyNiwgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAkJCQkgICAgCSAgICAgIA0KDQpJUCBTZXJ2aWNlIChW b2ljZSBhbmQgTXVsdGltZWRpYSkgUGVlcmluZyBBcmNoaXRlY3R1cmUgDQogICAgICAgICAgICAg ICAgZHJhZnQta2hhbi1pcC1zZXJ2LXBlZXItYXJjaC0wMC50eHQNCg0KU3RhdHVzIG9mIHRoaXMg TWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBzdWJq ZWN0IHRvIGFsbCBwcm92aXNpb25zDQogICBvZiBzZWN0aW9uIDMgb2YgUkZDIDM2NjcuICBCeSBz dWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2gNCiAgIGF1dGhvciByZXByZXNlbnRz IHRoYXQgYW55IGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2YNCiAgIHdo aWNoIGhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFu ZCBhbnkgb2YNCiAgIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWUgYXdhcmUgd2lsbCBiZSBkaXNjbG9z ZWQsIGluIGFjY29yZGFuY2Ugd2l0aA0KICAgUkZDIDM2NjguDQoNCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90 ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcw0KICAgSW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBt YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg YXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8x aWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93 IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBdWd1 c3QgMjYsIDIwMDYuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUg SW50ZXJuZXQgU29jaWV0eSAoMjAwNikuIA0KDQpJbnRlbGxlY3R1YWwgcHJvcGVydHkgcmlnaHRz IChJUFIpIHN0YXRlbWVudA0KDQpCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVh Y2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkgYXBwbGljYWJsZSANCnBhdGVudCBvciBvdGhl ciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2ls bCBiZSANCmRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcyBhd2Fy ZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gDQphY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJD UCA3OS4NCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBwaWN0b3JpYWxseSBkZXBpY3Rz IElQIFNlcnZpY2UgKFZvaWNlICsgTXVsdGltZWRpYSkgcHJvdmlkZXIgDQpuZXR3b3JrIGZ1bmN0 aW9uYWwgY29tcG9uZW50cywgcGVlcmluZyBpbnRlcmZhY2UgZnVuY3Rpb25zLCBhbmQgYW4gSVAg U2VydmljZSANCihWTSkgcHJvdmlkZXJzkiBwZWVyaW5nIHJlZmVyZW5jZSBhcmNoaXRlY3R1cmUu IFRoZSBkcmFmdCBhbHNvIGNhbGxzIGZvciANCmRldmVsb3Bpbmcgc2VwYXJhdGUgcmVxdWlyZW1l bnRzIGZvciBkaWZmZXJlbnQgdHlwZXMgb2YgcGVlcmluZy4gDQoNCiANClNvaGVsIEtoYW4gICAg ICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDYgICAgICAgICAgICAgICAgIAlbUGFnZSAxXQ0KDQpJ bnRlcm5ldC1EcmFmdCAgICBJUCBTZXJ2aWNlIChWTSkgUGVlcmluZyBBcmNoaXRlY3R1cmUgICAg ICAgICAgICAgRmViLiAyNiwgMjAwNg0KDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4g IEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgMw0KICAgMi4gIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgMy4gIERlZmluaXRpb25zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgNC4gIElQ IFNlcnZpY2UgKFZvaWNlICsgTXVsdGltZWRpYSkgUHJvdmlkZXIgTmV0d29yay4gLiAuIC4gLiAu IC4gLiAgIDQNCiAgIDUuICBQZWVyaW5nIEludGVyZmFjZSBGdW5jdGlvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgIDYuICBSZWZlcmVuY2UgSVAgU2VydmljZSAo Vk0pIFByb3ZpZGVyIFBlZXJpbmcgQXJjaGl0ZWN0dXJlIC4gLiAuIC4gIDYNCiAgIDcgICBUeXBl IG9mIHBlZXJpbmcgSW50ZXJmYWNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDcNCiAgIDguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCiAgIDkuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCiAgIDEwLiAgQWNrbm93 bGVkZ2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LjgNCiAgIDExLiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLjgNCiAgICAgICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCiAgICAgICBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIDkN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpTb2hlbCBLaGFuICAgICAgIEV4cGlyZXMgQXVndXN0IDI2LCAyMDA2ICAg ICAgICAgICAgICAgICAJW1BhZ2UgMl0NCg0KSW50ZXJuZXQtRHJhZnQgICAgSVAgU2VydmljZSAo Vk0pIFBlZXJpbmcgQXJjaGl0ZWN0dXJlICAgICAgICAgICAgIEZlYi4gMjYsIDIwMDYNCg0KDQoN Cg0KMS4gIEludHJvZHVjdGlvbg0KDQpUaGlzIGRvY3VtZW50IHBpY3RvcmlhbGx5IGRlcGljdHMg SVAgU2VydmljZSAoVm9pY2UrTXVsdGltZWRpYSkgcHJvdmlkZXIgbmV0d29yayANCmZ1bmN0aW9u YWwgY29tcG9uZW50cywgcGVlcmluZyBpbnRlcmZhY2UgZnVuY3Rpb25zLCBhbmQgYW4gSVAgU2Vy dmljZSAoVk0pIA0KcHJvdmlkZXJzkiBwZWVyaW5nIHJlZmVyZW5jZSBhcmNoaXRlY3R1cmUuIFRo ZSBkb2N1bWVudCBicmluZ3MgYXR0ZW50aW9uIG9mIA0KZGlmZmVyZW50IHR5cGVzIG9mIHBlZXJp bmcgaW50ZXJmYWNlcyBhbmQgY2FsbHMgZm9yIGRldmVsb3Bpbmcgc2VwYXJhdGUgDQpyZXF1aXJl bWVudHMgZm9yIGRpZmZlcmVudCB0eXBlcyBvZiBwZWVyaW5nIGludGVyZmFjZXMuDQoNClRoZSBv YmplY3RpdmUgb2YgdGhpcyBkcmFmdCBpcyB0byBicmluZyBhdHRlbnRpb24gb2YgY3VycmVudCBu ZXR3b3JrIGZ1bmN0aW9uYWwgDQpjb21wb25lbnRzIGluIHRoZSBJUCBTZXJ2aWNlIChWTSkgcGVl cmluZyBkaXNjdXNzaW9uLiANCg0KMi4gIFRlcm1pbm9sb2d5DQoNCiAgIA0KICAgSW4gdGhpcyBk b2N1bWVudCwgdGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsDQog ICAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVO REVEIiwgIk5PVA0KICAgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgYXJlIHRv IGJlIGludGVycHJldGVkIGFzDQogICBkZXNjcmliZWQgaW4gWzddIGFuZCBpbmRpY2F0ZSByZXF1 aXJlbWVudCBsZXZlbHMgZm9yIGNvbXBsaWFudA0KICAgaW1wbGVtZW50YXRpb25zLg0KDQoNCg0K My4wIERlZmluaXRpb25zDQoNCjMuMSBJUCBTZXJ2aWNlIChWb2ljZSArIE11bHRpbWVkaWEpIFBy b3ZpZGVyDQogDQogIEFuIElQIFNlcnZpY2UgKFZvaWNlICsgTXVsdGltZWRpYSkgcHJvdmlkZXIg aXMgYW4gZW50aXR5IHRoYXQgcHJvdmlkZXMgSVAgDQpjZW50cmljIHZvaWNlIGFuZCBtdWx0aW1l ZGlhIHNlcnZpY2VzLiAgRXhhbXBsZXMgb2Ygc2VydmljZXMgYXJlIFNJUCBwcm9jZXNzaW5nIA0K YW5kIHRyYW5zcG9ydCwgbWVkaWEgcHJvY2Vzc2luZyBhbmQgdHJhbnNwb3J0LCBzZWN1cml0eSBh bmQgcG9saWN5IA0KaW1wbGVtZW50YXRpb24sIGFuZCBlbWVyZ2luZyBhcHBsaWNhdGlvbiBzdXBw b3J0LiBFbmQgdXNlcnMgb2YgYW4gSVAgU2VydmljZSANCihWTSkgcHJvdmlkZXIgbWF5IHVzZSBQ U1ROLCBJUCBXaXJlbGVzcywgbm9uLUlQIHdpcmVsZXNzLCBhbmQgU0lQLWJhc2VkIGRldmljZXMu DQoNCg0KMy4yIFBlZXJpbmcNCg0KVGhpcyBkb2N1bWVudCBhZGhlcmVzIHRvIHRoZSBwZWVyaW5n IGRlZmluaXRpb25zIG9mIElFVEYgZHJhZnQgWzRdIFNlY3Rpb24gMy42Lg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNClNvaGVsIEtoYW4gICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDYg ICAgICAgICAgICAgICAgIAlbUGFnZSAzXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICBJUCBTZXJ2aWNl IChWTSkgUGVlcmluZyBBcmNoaXRlY3R1cmUgICAgICAgICAgICAgRmViLiAyNiwgMjAwNg0KDQoN CjQuMCBJUCBTZXJ2aWNlIChWb2ljZSArIE11bHRpbWVkaWEpIFByb3ZpZGVyIE5ldHdvcmsNCg0K ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUCBTZXJ2aWNlIFBy b3ZpZGVyIE5ldHdvcmsNCiAgIC8gLS0tLS0tLS0tLVwgICAgICAgICAgICAgLy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cICAgICAgICAgICANCiAgIHwgICAgICAgICAgIHwgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICArLS0t LS0rDQogICB8ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgCQkrLS0tLS0tLS0tLS0r ICAgIHwgPC0tLT58IElQICAgfA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAg CSAJfEFwcGxpY2F0aW9ufCAgICB8IDwuLi4+fCBwaG9uZXwNCiAgIHwgICAgICAgICAgIHwgICAg ICAgICAgICAgfCAgIC4uIC4gLiAuIC4uIAl8ICBTZXJ2ZXJzLCB8ICAgIHwgICAgICArLS0tLS0t Kw0KICAgfCAgICAgICA8LS0tfC0tLS0tLS0tLS0tLS18LS0+LlBlZXJpbmcgIC4gICAgfCBEYXRh YmFzZXMgfCAgICB8DQogICB8ICAgICAgIDwuLi4uLi4uLi4uLi4uLi4uLnwuPiAuSW50ZXJmYWNl LiAgICArLS0tLS0tLS0tLS0rICAgIHwNCiAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgfCAg IC5GdW5jdGlvbnMuICAgICAgICAgICAgICAgICAgICAgfCAgICArLS0tLS0tLS0rDQogICB8ICAg ICAgICAgICB8ICAgICAgICAgICAgIHwgICAuLiAuIC4gLiAuLiAgICArLS0tLS0tLS0tLS0rICAg IHw8LS0+fFdpcmVsZXNzfA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgfCBTSVAgICAgICAgfCAgICB8PC4uPnwgIElQICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgIHwgICBQZWVyICAgIHwgICAgICAgICAgICAg fCAgICstLS0tLS0tLS0rICAgIHwgUHJveGllcyAgIHwgICAgfCAgICB8TmV0d29yayB8ICAgICAg IA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgfCBQcml2YXRlIHwgICAgKy0tLS0t LS0tLS0tKyAgICB8ICAgICstLS0tLS0tLSsgDQogICB8IFByb3ZpZGVyICB8ICAgICAgICAgICAg IHwgICB8IEVOVU0gICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgIHwg ICAgICAgICAgICAgfCAgICstLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLSsgICAgfCAgICANCiAg IHwgICAgICAgCSAgIHwgIAkgICAgIHwJCSAgICAgIHxTSVAgVUFzICAgICB8ICAgfCAgICAgICAg ICANCiAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHxCMkJV QXMgICAgICB8ICAgfA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tKyAgICB8IA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSt8ICAgICAgICstLS0tKw0KICAgfCAg ICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgfE1H Q0Z8PElTVVA+IHwgICAgfCAgDQogICB8ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAg ICB8IElQICAgICB8ICAgICAgICAgICArLS0tK3wgICAgICAgfCAgICB8DQogICB8ICAgICAgICAg ICB8ICAgICAgICAgICAgIHwgICAgICAgICB8IFJvdXRlcnN8ICAgICAgICAgICArLS0tK3wgICAg ICAgfFBTVE58ICAgICANCiAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICst LS0tLS0tLSsgICAgICAgICAgIHxNRyB8fDxURE0+ICB8ICAgIHwNCiAgIHwgICAgICAgICAgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0rfCAgICAgICAr LS0tLSsNCiAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICBcLS0tLS0tLS0tLS0vICAgICAgICAgICAg IFwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS8NCiAgICAgICAgIA0KIC0tLSBN ZWRpYSAoUlRQL0lQKQ0KIC4uLiBTaWduYWwgKFNJUCkgICANCg0KICAgICAgICAgICAgRmlndXJl IDE6IE5ldHdvcmsgQXJjaGl0ZWN0dXJlIG9mIGFuIElQIFNlcnZpY2UgKFZNKSBQcm92aWRlciAN Cg0KICAgICANCkFuIElQIFNlcnZpY2UgcHJvdmlkZXIgKFZNKSBuZXR3b3JrIGNvbnRhaW5zIGZ1 bmN0aW9ucyBvZiBTSVAvU0lQUElORy9TSU1QTEUgDQpyZWxhdGVkIFJGQ3MgaW4gZ2VuZXJhbCBh bmQgUkZDMzI2MVsxXSBpbiBwYXJ0aWN1bGFyLiBFeGFtcGxlcyBvZiB0aGVzZSANCmZ1bmN0aW9u cyBhcmUgU0lQIFByb3hpZXMsIFNJUCBVQSwgYW5kIEIyQlVBLiBJbiBhZGRpdGlvbiwgdGhlIElQ IFNlcnZpY2UgDQpwcm92aWRlciBuZXR3b3JrIGNvbnRhaW5zIElQIFJvdXRlcnMsIEFwcGxpY2F0 aW9uIHNlcnZlcnMsIGFuZCBkYXRhYmFzZXMuIFRvIA0KZmFjaWxpdGF0ZSBpbnRlcmZhY2Ugd2l0 aCBQU1ROIG5ldHdvcmssIGEgU2VydmljZSBwcm92aWRlciBuZXR3b3JrIGNvbnRhaW5zIA0KTWVk aWEgR2F0ZXdheSBDb250cm9sIEZ1bmN0aW9uIChNR0NGKSBhbmQgTWVkaWEgR2F0ZXdheSAoTUcp LiBUaGUgbmV0d29yayBtYXkgDQphbHNvIGNvbnRhaW4gcHJpdmF0ZSBFTlVNLg0KDQpBbiBJUCBT ZXJ2aWNlIChWTSkgcHJvdmlkZXIgaW50ZXJjb25uZWN0cyB3aXRoIG90aGVyIElQIFNlcnZpY2Ug KFZNKSBwcm92aWRlcnMgDQp3aXRoIGEgcGVlcmluZyBpbnRlcmZhY2UgZnVuY3Rpb25zLiANCg0K DQoNCg0KDQoNClNvaGVsIEtoYW4gICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDYgICAgICAg ICAgICAgICAgIAlbUGFnZSA0XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICBJUCBTZXJ2aWNlIChWTSkg UGVlcmluZyBBcmNoaXRlY3R1cmUgICAgICAgICAgICAgRmViLiAyNiwgMjAwNg0KDQo1LjAgUGVl cmluZyBJbnRlcmZhY2UgRnVuY3Rpb25zDQoNCg0KICAgICAgICAgICAgICAgLi4uLi4uLi4uLi4u IC4gLiAuLiANCiAgICAgICAgICAgICAgIC4gKy0tLS0tLSsgLiAgICAgICAuIA0KICAgICAgICAg ICAgICAgLiB8ICBBRiAgfCAuICAgICAgIC4gDQogICAgICAgICAgICAgICAuICstLS0tLS0rIC4g IFMgICAgLiAgICANCiAgICAgICAgICAgICAgIC4gICAgICAgICAgLiAgICAgICAuICANCiAgICAg ICAgICAgICAgIC4gKy0tLS0tLSsgLiAgRSAgICAuICANCiAgICAgICAgICAgICAgIC4gfCAgU0Yg IHwgLiAgICAgICAuDQogICAgICAgICAgICAgICAuICstLS0tLS0rIC4gIEMgICAgLiAgDQogICAg ICAgICAgICAgICAuICAgICAgICAgIC4gICAgICAgLiAgDQogICAgICAgICAgICAgICAuICstLS0t LS0rIC4gIFUgICAgLg0KICAgICAgICAgICAgICAgLiB8ICBURiAgfCAuICAgICAgIC4NCiAgICAg ICAgICAgICAgIC4gKy0tLS0tLSsgLiAgUiAgICAuDQogICAgICAgICAgICAgICAuICAgICAgICAg IC4gICAgICAgLg0KICAgICAgICAgICAgICAgLiArLS0tLS0tKyAuICBJICAgIC4NCiAgICAgICAg ICAgICAgIC4gfCAgTUYgIHwgLiAgICAgICAuDQogICAgICAgICAgICAgICAuICstLS0tLS0rIC4g IFQgICAgLg0KICAgICAgICAgICAgICAgLiAgICAgICAgICAuICAgICAgIC4NCiAgICAgICAgICAg ICAgIC4gKy0tLS0tLSsgLiAgWSAgICAuDQogICAgICAgICAgICAgICAuIHwgT0YgICB8IC4gICAg ICAgLg0KICAgICAgICAgICAgICAgLiArLS0tLS0tKyAuICAgICAgIC4NCiAgICAgICAgICAgICAg IC4uLi4uLi4uLi4uLiAuLiAuLiAuDQogICAgICAgICAgICAgRmlndXJlIDI6IFBlZXJpbmcgSW50 ZXJmYWNlIGZ1bmN0aW9ucw0KDQpBbiBJUCBTZXJ2aWNlIHBlZXJpbmcgaW50ZXJmYWNlIGNhbiBi ZSBkaXZpZGVkIGludG8gZml2ZSBwbGFuZXM6IGFwcGxpY2F0aW9uLCANCnNpZ25hbGluZywgbWVk aWEsIHJvdXRpbmcsIGFuZCBvcGVyYXRpb24tbWFuYWdlbWVudC4gVGhpcyBkb2N1bWVudCBkZWZp bmVzIA0KbW9kdWxlcyBwZXJmb3JtaW5nIHRoZXNlIGludGVyZmFjZXMgYXMgQXBwbGljYXRpb24g RnVuY3Rpb24gKEFQKSwgU2lnbmFsaW5nIA0KRnVuY3Rpb24gKFNGKSwgTWVkaWEgRnVuY3Rpb24g KE1GKSwgVHJhZmZpYyBFbmdpbmVlcmluZyBGdW5jdGlvbiAoVEYpLCBhbmQgDQpPcGVyYXRpb24g JiBNYW5hZ2VtZW50IEZ1bmN0aW9uIChPRikuIE5vdGUgdGhhdCB0aGUgc2VjdXJpdHkgaXMgYXNz b2NpYXRlZCB3aXRoIA0KYWxsIHRoZXNlIGZ1bmN0aW9ucy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNClNvaGVsIEtoYW4gICAgICAgRXhwaXJlcyBBdWd1c3QgMjYs IDIwMDYgICAgICAgICAgICAgICAgIAlbUGFnZSA1XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICBJUCBT ZXJ2aWNlIChWTSkgUGVlcmluZyBBcmNoaXRlY3R1cmUgICAgICAgICAgICAgRmViLiAyNiwgMjAw Ng0KDQoNCg0KDQo2LjAgUmVmZXJlbmNlIElQIFNlcnZpY2UgKFZNKSBQcm92aWRlciBQZWVyaW5n IEFyY2hpdGVjdHVyZQ0KDQogIA0KDQoNCiAgICstLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tKw0KICAgfCAgSVAgICB8ICAg ICAgICAgICAtLS0tLS0tICAgICAgICAgICAgICAgIC0tLS0tLS0gICAgICAgICAgfCAgSVAgICB8 DQogICB8IHBob25lIHwgPC0tLS0tLT4gLyAgICAgICBcICAgICAgICAgICAgICAvICAgICAgIFwg PC0tLS0tLT58IHBob25lIHwNCiAgICstLS0tLS0tKyAgICAgICAgIHwgICAgICAgIEFGIC4uLi4u Li4uLi4uQUYgICAgICAgIHwgICAgICAgICstLS0tLS0tKw0KCQkJICAgfCAgICAgICAgIHwgICAg ICAgICAgICB8ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAg ICAgICAgICB8ICAgICAgICAgfA0KICAgIAkJICAgICAgICAgfCAgIElQICAgU0YuLi4uLi4uLi4u LlNGICAgSVAgICAgfCAgICAgICAgDQogICArLS0tLS0tLS0rICAgICAgICB8IFNlcnZpY2UgfCAg ICAgICAgICAgIHwgU2VydmljZSB8ICAgICAgICArLS0tLS0tLS0rICAgICANCiAgIHxXaXJlbGVz c3wgICAgICAgIHxQcm92aWRlciBNRiAuLi4uLi4uLi5NRiBQcm92aWRlcnwgICAgICAgIHxXaXJl bGVzc3wNCiAgIHxOZXR3b3JrIHwgPC0tLS0tPnwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgIHw8LS0tLS0+IHxOZXR3b3JrIHwNCiAgICstLS0tLS0tLSsgICAgICAgIHwgICAgQSAgICBU RiAuLi4uLi4uICBURiAgICAgQiAgIHwgICAgICAgICstLS0tLS0tLSsNCiAgICstLS0tLS0rICAg ICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgKy0tLS0t LSsNCiAgIHwgICAgICB8IDwtLS0tLS0tPk1HICAgICAgICBPRiAuLi4uLi4uLiBPRiAgICAgICAg ICA8LS0tLS0tLT4gfCAgICAgIHwNCiAgIHwgUFNUTiB8ICAgICAgICAgIHwgICAgICAgICB8ICAg ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgfCBQU1ROIHwNCiAgIHwgICAgICB8IDwtLS0t LS0tPiBcICAgICAgIC8gICAgICAgICAgICAgIFwgICAgICAgLyA8LS0tLS0tLT4gfCAgICAgIHwN CiAgICstLS0tLS0rICAgIFNTNyAgICAgLS0tLS0tLSAgICAgICAgICAgICAgICAtLS0tLS0tICAg ICBTUzcgICAgKy0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgIEZp Z3VyZSAzOiBSZWZlcmVuY2UgUGVlcmluZyBBcmNoaXRlY3R1cmUNCg0KDQpUaGUgU0YgcGVyZm9y bXMgTGF5ZXIgNSBwZWVyaW5nIGZ1bmN0aW9ucyBpLmUuLCBTSVAgc2lnbmFsaW5nIGFuZCBjb250 cm9sIA0KZnVuY3Rpb25zIGF0IHRoZSBpbnRlcmNvbm5lY3QgaW50ZXJmYWNlLiBBIHBvc3NpYmxl IGV4YW1wbGUgb2YgYSBTRiBpcyBhIFNJUCANClByb3h5IG9yIGEgU0lQIEIyQlVBLiANCg0KQSBN RiBtYXkgdHJhbnNmb3JtIHZvaWNlIHBheWxvYWQgZnJvbSBvbmUgY29kaW5nIChlLmcuLCBHLjcx MSkgdG8gYW5vdGhlciAoZS5nLiwgDQpFdlJDKS4gDQoNClRoZSBURiBwZXJmb3JtcyB0aGUgdHJh ZmZpYyBlbmdpbmVlcmluZyBhbmQgTGF5ZXIgMyBmdW5jdGlvbnMuIEFuIGV4YW1wbGUgb2YgYSAN ClRGIGlzIHRoZSBzZXNzaW9uIGFkbWlzc2lvbiBjb250cm9sIChTQUMpLCB3aGljaCBpcyBhbmFs b2dvdXMgdG8gdGhlIHdlbGwga25vd24gDQpDYWxsIEFkbWlzc2lvbiBDb250cm9sIChDQUMpLiBB bm90aGVyIGV4YW1wbGUgaXMgdGhlIGV4Y2hhbmdlIG9mIHJvdXRpbmcgDQppbmZvcm1hdGlvbiBi ZXR3ZWVuIHR3byBwcm92aWRlcnMgYW5kIGltcGxlbWVudGF0aW9uIG9mIHRoZSBCb3JkZXIgR2F0 ZXdheSANClByb3RvY29sKEJHUClbUkZDMTc3MV1bM10uDQoNCg0KQW4gQUYgaXMgYSBzcGVjaWFs IGZ1bmN0aW9uIHRoYXQgY29udGFpbnMgYmktbGF0ZXJhbGx5IGRpc2Nsb3NlZCBpbmZvcm1hdGlv biANCmFib3V0IHRoZSBhcHBsaWNhdGlvbiBzZXJ2ZXJzIGFuZCBkYXRhYmFzZXMgb2YgZWFjaCBJ UCBzZXJ2aWNlIHByb3ZpZGVyLiBBbiANCmV4YW1wbGUgb2YgdGhpcyBmdW5jdGlvbiBpcyB0byBh bGxvdyBhIHNlc3Npb24gdG8gc2VsZWN0IGEgYmV0dGVyIHN1aXRlZCANCmFwcGxpY2F0aW9uIHNl cnZlciBmcm9tIGEgc2V0IG9mIGFwcGxpY2F0aW9uIHNlcnZlcnMgbG9jYXRlZCBpbnNpZGUgYm90 aCBzZXJ2aWNlIA0KcHJvdmlkZXJzIG5ldHdvcmsuDQoNCg0KDQoNCg0KU29oZWwgS2hhbiAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyNiwgMjAwNiAgICAgICAgICAgICAgICAgCVtQYWdlIDZdDQoNCklu dGVybmV0LURyYWZ0ICAgIElQIFNlcnZpY2UgKFZNKSBQZWVyaW5nIEFyY2hpdGVjdHVyZSAgICAg ICAgICAgICBGZWIuIDI2LCAyMDA2DQoNCg0KDQoNClNvbWUgZXhhbXBsZXMgb2YgYWJvdmUgZnVu Y3Rpb25zIGFyZSBwcmVzZW50ZWQgaW4gdGhlIGZvbGxvd2luZyB0YWJsZTogDQoNCiAgIEZ1bmN0 aW9ucyAJCQkJCUV4YW1wbGVzDQogICANClNpZ25hbGluZyBGdW5jdGlvbiAoU0YpCVNJUCBQcm94 eSwgQjJCVUEsIFNlc3Npb24gQWRtaXNzaW9uIENvbnRyb2wgKFNBQyksIA0KCQkJCVNJUCBJbnRl cm9wZXJhYmlsaXR5LCBTSVAgRGVuaWFsIG9mIFNlcnZpY2UgKERvUykgDQoJCQkJcHJvdGVjdGlv biwgU0lQIFRvcG9sb2d5IEhpZGluZyAoVEhJRyksIGFuZCBTSVAgDQoJCQkJc2VjdXJpdHksIHBy aXZhY3kgYW5kIGVuY3J5cHRpb24uDQoNCk1lZGlhIEZ1bmN0aW9uICAgIChNRikJVHJhbnNjb2Rp bmcsIGRhdGEgaW50ZWdyaXR5LCBtZWRpYSBzZWN1cml0eSwgcHJpdmFjeSBhbmQgICAgICANCmVu Y3J5cHRpb24uIA0KDQpURSBGdW5jdGlvbiAgICAgICAoVEYpCVJvdXRpbmcgcHJvdG9jb2wgaGFy bW9uaXphdGlvbiwgVlBOIG1lZGlhdGlvbiwgc2Vzc2lvbiANCmFkbWlzc2lvbiBwb2xpY3kgZW5m b3JjZW1lbnQsIHJhdGUgc2hhcGluZywgYmFuZHdpZHRoIA0KYnJva2VyLCBiYW5kd2lkdGggdGhl ZnQgcHJvdGVjdGlvbiwgZGF0YSBpbnRlZ3JpdHksIA0KdHJhbnNjb2RpbmcsIE5ldHdvcmsgQWRk cmVzcyBUcmFuc2xhdGlvbiAoTkFUKQ0KDQoNCk8mTSBGdW5jdGlvbiAgICAoT0YpICAgIENBTEVB IGltcGxlbWVudGF0aW9uOyBhY2NvdW50aW5nLCBiaWxsaW5nIGFuZAkNCgkJCSAgICAgIG9wZXJh dGlvbmFsIGRhdGEgbWVkaWF0aW9uLg0KDQpBcHBsaWNhdGlvbiBGdW5jdGlvbiAoQUYpICBBbiBp bnRlcndvcmtpbmcgc2VydmljZSBicm9rZXIgICAgICAgICAgICAgDQoNCiANCk5vdGUgdGhhdCB0 aGVyZSBtYXkgYmUgb3ZlcmxhcHBpbmcgb2YgZnVuY3Rpb24gYmV0d2VlbiBNRiBhbmQgVEYuIFRo ZSBzZWN1cml0eSANCmlzIGFzc29jaWF0ZWQgd2l0aCBhbGwgZnVuY3Rpb25zLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU29oZWwgS2hhbiAgICAgICBF eHBpcmVzIEF1Z3VzdCAyNiwgMjAwNiAgICAgICAgICAgICAgICAgCVtQYWdlIDddDQoNCkludGVy bmV0LURyYWZ0ICAgIElQIFNlcnZpY2UgKFZNKSBQZWVyaW5nIEFyY2hpdGVjdHVyZSAgICAgICAg ICAgICBGZWIuIDI2LCAyMDA2DQoNCg0KNy4wIFR5cGUgb2YgcGVlcmluZyBJbnRlcmZhY2VzDQoN CiAgIFJlcXVpcmVtZW50cyBvZiBQZWVyaW5nIEludGVyZmFjZXMgdmFyeSBkZXBlbmRpbmcgb24g dGhlIHR5cGUgb2YgDQppbnRlcmNvbm5lY3Rpb24uIFR3byBsYXJnZSBJUCBzZXJ2aWNlIHByb3Zp ZGVyIGhhdmluZyBlcXVhbCBvciBhbG1vc3QgZXF1YWwgDQpuZXR3b3JrIGZ1bmN0aW9uYWwgY29t cG9uZW50cyBtYXkgcGVlciBhcyBuZXR3b3JrLW5ldHdvcmsgaW50ZXJmYWNlIChOTkkpLiANCkhv d2V2ZXIsIGEgc21hbGwgZW50ZXJwcmlzZSBtYXkgcmVseSBvbiBtYW55IHNlcnZpY2VzIG9yIG5l dHdvcmsgZnVuY3Rpb25zIG9mIGEgDQpsYXJnZSBJUCBzZXJ2aWNlIHByb3ZpZGVyLiBUaGUgcGVl cmluZyByZXF1aXJlbWVudHMgYmV0d2VlbiB0aGUgYWNjZXNzLW5ldHdvcmsgDQppbnRlcmZhY2Vz IChBTkkpIG1heSBiZSBkaWZmZXJlbnQgZnJvbSB0aG9zZSBvZiBuZXR3b3JrLW5ldHdvcmsgaW50 ZXJmYWNlcy4gDQpTaW1pbGFybHksIHdoZW4gYSB1c2VyIGFnZW50IChlLmcuLCBsYXB0b3ApIHBl ZXJzIHdpdGggYSBuZXR3b3JrIChlLmcuLCBXaXJlbGVzcyANCnByb3ZpZGVyKSwgdGhlIHVzZXIt bmV0d29yayBpbnRlcmZhY2UgKFVOSSkgcmVxdWlyZW1lbnRzIG1heSBhbHNvIGJlIGRpZmZlcmVu dCANCmZyb20gdGhvc2Ugb2YgdGhlIE5OSSBhbmQgQU5JLiBSZXF1aXJlbWVudHMgZm9yIHRoZXNl IGludGVyZmFjZXMgbmVlZCB0byBiZSANCnNlcGFyYXRlbHkgYWRkcmVzc2VkLiBUaGlzIGRvY3Vt ZW50IGFzc3VtZXMgdGhhdCB0aGUgcDJwIFNJUCBpcyBvdXRzaWRlIHRoZSANCnNjb3BlIG9mIFNQ RUVSTUlOVC4NCg0KDQo4LjAgU2VjdXJpdHkgDQoNCiAgIE1hbnkgb2YgdGhlIGZ1bmN0aW9ucyB0 aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBoYXZlIGltcG9ydGFudCBzZWN1cml0eQ0KICAgYW5kIHBy aXZhY3kgaW1wbGljYXRpb25zLiAgSWYgdGhlIElFVEYgZGVjaWRlcyB0byBkZXZlbG9wIHN0YW5k YXJkDQogICBtZWNoYW5pc21zIHRvIGFkZHJlc3MgdGhvc2UgZnVuY3Rpb25zLCBzZWN1cml0eSBh bmQgcHJpdmFjeS1yZWxhdGVkDQogICBhc3BlY3RzIHdpbGwgbmVlZCB0byBiZSB0YWtlbiBpbnRv IGNvbnNpZGVyYXRpb24uDQoNCjcuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9j dW1lbnQgaGFzIG5vIElBTkEgY29uc2lkZXJhdGlvbnMuDQoNCjguICBBY2tub3dsZWRnZXMNCg0K ICAgVGhpcyBkcmFmdCByZXByb2R1Y2VzIHNvbWUgaW5mb3JtYXRpb24gb2YgdGhlIElFVEYgZHJh ZnQgZHJhZnQtc29oZWwtc2lwcGluZy0NCnMtYmMtY29uY2VwdC1hcmNoLTAwLnR4dCwgSnVseSAx NCwgMjAwNSBhbmQgUFRTQy1TQUMtMjAwNS0yMTMgWzVdLg0KIA0KDQo5LiAgUmVmZXJlbmNlcw0K DQogICBbMV0gIFJvc2VuYmVyZywgSi4sIFNjaHVsenJpbm5lLCBILiwgQ2FtYXJpbGxvLCBHLiwg Sm9obnN0b24sIEEuLA0KICAgICAgICBQZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4sIEhhbmRsZXks IE0uIGFuZCBFLiBTY2hvb2xlciwgIlNJUDoNCiAgICAgICAgU2Vzc2lvbiBJbml0aWF0aW9uIFBy b3RvY29sIiwgUkZDIDMyNjEsIEp1bmUgMjAwMi4NCiAgIFsyXSAgU2NodWx6cmlubmUsIEguLCBD YXNuZXIsIFMuLCBGcmVkZXJpY2ssIFIuIGFuZCBWLiBKYWNvYnNvbiwNCiAgICAgICAgIlJUUDog QSBUcmFuc3BvcnQgUHJvdG9jb2wgZm9yIFJlYWwtVGltZSBBcHBsaWNhdGlvbnMiLCBTVEQgNjQs DQogICAgICAgIFJGQyAzNTUwLCBKdWx5IDIwMDMuDQogICBbM10gUmVraHRlciwgWS4gYW5kIFQu IExpLCCTQSBCb3JkZXIgR2F0ZXdheSBQcm90b2NvbCA0IChCR1AtNCmULCBSRkMgMTc3MSwgDQog ICAgICAgTWFyY2gsIDE5OTUuDQogICBbNF0gTWV5ZXIsIEQuLCCTU1BFRVJNSU5UIFJlcXVpcmVt ZW50cyBhbmQgVGVybWlub2xvZ3mULCBkcmFmdC1pZXRmLQ0Kc3BlZXJtaW50LXJlcXMtYW5kLXRl cm1pbm9sb2d5LTAxLnR4dCwgRmViLiAxNywgMjAwNi4NCiAgIFs1XSBLaGFuLCBTb2hlbCwgIkV4 YW1wbGUgQ29uY2VwdHVhbCBSZWFsaXphdGlvbiBvZiBTL0JDcyIsIA0KICAgICAgIFBUU0MtU0FD LTIwMDUtMjEzLCBBVElTLVBUU0MsIEp1bmUsIDIwMDUuDQoNCg0KDQoNCg0KDQpTb2hlbCBLaGFu ICAgICAgIEV4cGlyZXMgQXVndXN0IDI2LCAyMDA2ICAgICAgICAgICAgICAgICAJW1BhZ2UgN10N Cg0KSW50ZXJuZXQtRHJhZnQgICAgSVAgU2VydmljZSAoVk0pIFBlZXJpbmcgQXJjaGl0ZWN0dXJl ICAgICAgICAgICAgIEZlYi4gMjYsIDIwMDYNCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAg U29oZWwgS2hhbiwgUGguRC4NCiAgIFNwcmludA0KICAgNjIyMCBTcHJpbnQgUGFya3dheQ0KICAg T3ZlcmxhbmQgUGFyaywgS1MgNjYyNTENCiAgIFUuUy5BDQoNCiAgIA0KSW50ZWxsZWN0dWFsIFBy b3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRp bmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5 IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0 YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3Jp YmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vu c2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7 IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRl bnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBv biB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMg Y2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQ UiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFz c3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQg b2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVy bWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1w bGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFp bmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFy dHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMg b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0 aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVu dA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0 aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KRGlzY2xhaW1lciBvZiBWYWxp ZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhl cmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklC VVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNP UkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQog ICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNT IE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5G UklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFO VEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KQ29weXJp Z2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgy MDA1KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5z ZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBh cyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMu DQoNCg0KU29oZWwgS2hhbiAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNiwgMjAwNiAgICAgICAgICAg ICAgICAgCVtQYWdlIDddDQoNCkludGVybmV0LURyYWZ0ICAgIElQIFNlcnZpY2UgKFZNKSBQZWVy aW5nIEFyY2hpdGVjdHVyZSAgICAgICAgICAgICBGZWIuIDI2LCAyMDA2DQoNCg0K ------_=_NextPart_001_01C63E28.F30A2FBB 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_01C63E28.F30A2FBB-- From speermint-bounces@ietf.org Thu Mar 02 14:38:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtcd-0008MW-Qf; Thu, 02 Mar 2006 14:37:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtcc-0008MR-4U for speermint@ietf.org; Thu, 02 Mar 2006 14:37:58 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEtcb-0004UG-KO for speermint@ietf.org; Thu, 02 Mar 2006 14:37:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt Date: Thu, 2 Mar 2006 20:41:55 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48A8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVY= From: "Stastny Richard" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 Folks, =20 I am a bit confused by this draft. =20 >The purpose of this document is to help the IETF community understand=20 > the route architectures being used today in SIP based peering > environments and to outline a set of requirements based on the same > for discussion within the community =20 Is this IMS in stealth mode? The abstract should clearly state: =20 The purpose of this draft is to help the IETF community understand IMS = .. =20 In particular I have problems with the following para: =20 "The call is originated at calling party "O", (called the "Origination" in this document) and terminates at called party "T" (called the "Termination" in this document). T may be a subscriber, contact center, E911 operator etc. The first hop and the last hop of the call in Figure 1 pass through SPs providing L5 (in our case SIP) access to the origination and termination and are called Access-O and Access-T respectively. In most cases these SPs will also provide the physical access to the origination and termination devices. The Access SP function is not optional. While a separate Access SP may not exist, the function may be absorbed by the corresponding Core SP." A Core SP ALWAYS needs an Access SP if he is not providing the access=20 by itself? In L5? And then we also have Interconnect SP =3D Transit What happened to the SIP Trapeziod? and may I remember on the req draft "3.6.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network"." The next problem I have with section =20 "5.2. Addressing The type of A-O-R for the termination may also affect what kind of address location service is used. Address location is done typically based on the following four characteristics of the termination's AOR. In each case, we list the most common address location method used. 1. Full E.164: ENUM or SP's local policy may be used. 2. E.164 prefixes: SPs local policy is generally used. 3. Full A-O-R: This is rarely used for routing in a peering environment. 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." =20 Within SPEERMINT only Call Routing Data (CRD) are used E.164 numbers are not CRD, they are also not A-o-R,=20 E.164 numbers are names so E.164 number is out of scope in SPEERMENT And IMHO completely off is the idea to introduce carrier selection within VoIP =20 " For example Equal Access is a LEC (Local Exchange Carrier) requirement and an SP operating as an LEC may be required to allow the subscriber his/her choice of IXC (IntereXchange Carrier) for certain set of calls. In essence, these requirements may affect route policy for peering where the downstream peer is chosen based on origination's policy. In this case, the Core-O and Core-T may be one and the same SP who peer through an Interconnect SP of the origination's choice." =20 I have an headache =20 Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Do 02.03.2006 19:33 An: speermint@ietf.org Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt FYI for the WG on this draft. This is on the tentative agenda at the = Dallas meeting (should be finalized shortly). =20 Jason ________________________________ From: Medhavi Bhatia [mailto:mbhatia@nextone.com]=20 Sent: Sunday, February 26, 2006 12:44 AM To: internet-drafts@ietf.org Cc: dmm@1-4-5.net; Livingood, Jason Subject: I-D draft-bhatia-sip-peering-00.txt Abstract =20 The purpose of this document is to help the IETF community understand the route architectures being used today in SIP based peering environments and to outline a set of requirements based on the same for discussion within the community. =20 =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 02 15:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEu95-00033r-Ba; Thu, 02 Mar 2006 15:11:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEu93-00033m-Pk for speermint@ietf.org; Thu, 02 Mar 2006 15:11:29 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEu90-0005bs-17 for speermint@ietf.org; Thu, 02 Mar 2006 15:11:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C63E28.07677364" Date: Thu, 2 Mar 2006 13:35:07 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A438@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-natale-sip-voip-requirements-00.txt Thread-Index: AcY7kmxyeEurtH21QV21y8t1P5pjEwClXuYw From: "Livingood, Jason" To: X-OriginalArrivalTime: 02 Mar 2006 18:35:07.0349 (UTC) FILETIME=[07958050:01C63E28] X-Spam-Score: 0.2 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 Subject: [Speermint] FW: draft-natale-sip-voip-requirements-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_01C63E28.07677364 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C63E28.07677364" ------_=_NextPart_002_01C63E28.07677364 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI #2, also on the draft agenda. =20 Jason =20 ------_=_NextPart_002_01C63E28.07677364 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI #2, also on the draft = agenda.
 
Jason

 
------_=_NextPart_002_01C63E28.07677364-- ------_=_NextPart_001_01C63E28.07677364 Content-Type: text/plain; name="draft-natale-sip-voip-requirements-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-natale-sip-voip-requirements-00.txt Content-Disposition: attachment; filename="draft-natale-sip-voip-requirements-00.txt" DQoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCLk5hdGFsZSANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBOZXhUb25lIENvbW11bmljYXRpb25zIA0KRXhwaXJlczog QXVndXN0IDI4LCAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZl YnJ1YXJ5IDIwMDYgDQogDQogDQogICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQLWJhc2Vk IFZvSVAgSW50ZXJjb25uZWN0aW9uIA0KICAgICAgICAgICAgICBkcmFmdC1uYXRhbGUtc2lwLXZv aXAtcmVxdWlyZW1lbnRzLTAwLnR4dCANCiANClN0YXR1cyBvZiB0aGlzIE1lbW8gDQogDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkgDQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdo aWNoIGhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIA0KICAgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3Nl ZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcyBhd2FyZSANCiAgIHdpbGwgYmUg ZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4gDQogICAg DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZyBUYXNrIA0KICAgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgDQogICBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuIA0KICAgIA0KICAg SW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzIA0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgDQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCANCiAgIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDQogICAgDQog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQg DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuIA0KICAgIA0K ICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBh Y2Nlc3NlZCBhdCANCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KICAgIA0K ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBdWd1c3QgMjEsIDIwMDYuIA0K IA0KQ29weXJpZ2h0IE5vdGljZSANCiANCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDIwMDYpLiANCiANCkFic3RyYWN0IA0KIA0KICAgVGhpcyBpcyBhbiBpbml0aWFsIGRy YWZ0IGZvciBjb25zaWRlcmF0aW9uIGJ5IHRoZSBTUEVFUk1JTlQgV0cgYXMgYSANCiAgIGNhbmRp ZGF0ZSBmb3IgdGhlIGNoYXJ0ZXJlZCB3b3JrIGl0ZW0gZGVhbGluZyB3aXRoICJ0aGUgbWluaW11 bSBzZXQgb2YgDQogICByZXF1aXJlbWVudHMgZm9yIFNJUC1iYXNlZCBWb0lQIGludGVyY29ubmVj dGlvbiAoQkNQKSIsIGR1ZSBpbiBNYXJjaCANCiAgIDIwMDcuICBJbiBpdHMgcHJlc2VudCBmb3Jt LCB0aGlzIGRyYWZ0IGlzIGludGVuZGVkIHNvbGVseSB0byBwcm92aWRlIGEgDQogICBiYXNpcyBm b3IgV0cgZGlzY3Vzc2lvbiBhYm91dCByZXF1aXJlbWVudHMgc2VsZWN0aW9uLiAgQXMgc3VjaCwg aXQgaXMgDQogICBwcmltYXJpbHkgc3RydWN0dXJhbCBhbmQgZGVzY3JpcHRpdmUgaW4gbmF0dXJl LCBsZWF2aW5nIHByZXNjcmlwdGl2ZSANCiAgIGNvbnRlbnQgdG8gbGF0ZXIgcmV2aXNpb25zIGRy aXZlbiBieSBXRyBjb25zZW5zdXMuIA0KIA0KIA0KIA0KIA0KTmF0YWxlICAgICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAyOCwgMjAwNiAgICAgICAgICAgW1BhZ2UgMV0gDA0KCgoKSW50ZXJuZXQg RHJhZnQgIFNJUC1CYXNlZCBWb0lQIFBlZXJpbmcgUmVxdWlyZW1lbnRzICBGZWIgMjAwNiANCiAN CiANCiANCiANCiANCiANCiANClRhYmxlIG9mIENvbnRlbnRzIA0KIA0KMS4gSW50cm9kdWN0aW9u ICAgNCANCjIuIFRlcm1pbm9sb2d5ICAgNSANCiAgICAgIDIuMSBWb0lQIFBlZXJpbmcgQXJjaGl0 ZWN0dXJlcyAgIDUgDQogICAgICAyLjIgRGlyZWN0IFBlZXJpbmcgICA1IA0KICAgICAgMi4zIElu dGVyY29ubmVjdCBQZWVyaW5nICAgNiANCiAgICAgIDIuNCBBY2Nlc3MgUGVlcmluZyAgIDYgDQoz LiBSZXF1aXJlbWVudHMgQ2F0YWxvZ3VlICAgNiANCiAgICAgIDMuMSAwLjAwMDAgIEdlbmVyYWwg UmVxdWlyZW1lbnRzICAgNiANCiAgICAgIDMuMiAwLjEwMDAgIFBlZXJpbmcgQXJjaGl0ZWN0dXJl cyAgIDYgDQogICAgICAzLjMgMC4xMTAwICBTZWN1cml0eSAgIDYgDQogICAgICAzLjQgMC4xMjAw ICBSZXNpbGllbmN5ICAgNiANCiAgICAgIDMuNSAwLjEzMDAgIFBlcmZvcm1hbmNlICAgNiANCiAg ICAgIDMuNiAwLjE0MDAgIFNjYWxhYmlsaXR5ICAgNiANCiAgICAgIDMuNyAwLjIwMDAgIFBlZXJp bmcgQWdyZWVtZW50cyAgIDYgDQogICAgICAzLjggMC4yMTAwICBSZWd1bGF0b3J5IFJlcXVpcmVt ZW50cyAgIDcgDQogICAgICAzLjkgMC4yMTEwICBFcXVhbCBBY2Nlc3MgICA3IA0KICAgICAgMy4x MCAwLjIxMjAgIExhd2Z1bCBJbnRlcmNlcHQgICA3IA0KICAgICAgMy4xMSAwLjIxMzAgIE51bWJl ciBQb3J0YWJpbGl0eSAgIDcgDQogICAgICAzLjEyIDAuMjE1MCAgUFNUTiBJbnRlcmZhY2VzICAg NyANCiAgICAgIDMuMTMgMC4yMjAwICBUcmFmZmljIEV4Y2hhbmdlIEZhY2lsaXRhdGlvbiAgIDcg DQogICAgICAzLjE0IDAuMjMwMCAgRXh0ZW5zaWJpbGl0eSB0byBOZXcgUGVlcmluZyBFbnRpdGll cyAgIDcgDQogICAgICAzLjE1IDAuMjQwMCAgU2VydmljZSBJbmRlcGVuZGVuY2UgICA3IA0KICAg ICAgMy4xNiAwLjI1MDAgIEZlYXR1cmUgVHJhbnNwYXJlbmN5ICAgNyANCiAgICAgIDMuMTcgMC4z MDAwICBTZXJ2aWNlIERpc2NvdmVyeSAgIDcgDQogICAgICAzLjE4IDAuNDAwMCAgU2VydmljZSBM b2NhdGlvbiAgIDcgDQogICAgICAzLjE5IDAuNTAwMCAgU2lnbmFsaW5nIChTSVAsIFJGQyAzMjYx KSAgIDcgDQogICAgICAzLjIwIDAuNTEwMCAgU0lQIEV4dGVuc2lvbnMgICA3IA0KICAgICAgMy4y MSAwLjYwMDAgIFByb3h5IEZ1bmN0aW9ucyAgIDcgDQogICAgICAzLjIyIDAuNzAwMCAgQWRkcmVz c2luZyAgIDcgDQogICAgICAzLjIzIDAuODAwMCAgUm91dGluZyAoUG9saWN5LUJhc2VkLCBUcnVz dCBSZWxhdGlvbnNoaXBzKSAgIDcgDQogICAgICAzLjI0IDAuODEwMCAgU2lnbmFsaW5nIFJvdXRp bmcgICA3IA0KICAgICAgMy4yNSAwLjgyMDAgIE1lZGlhIFJvdXRpbmcgICA3IA0KICAgICAgMy4y NiAwLjgzMDAgIENhbGwgUm91dGluZyAgIDcgDQogICAgICAzLjI3IDAuODQwMCAgU2Vzc2lvbiBS b3V0aW5nICAgNyANCiAgICAgIDMuMjggMC45MDAwICBUcmFuc3BvcnQgICA3IA0KICAgICAgMy4y OSAxLjAwMDAgIE5ldHdvcmsgQXJjaGl0ZWN0dXJlICAgNyANCiANCiANCk5hdGFsZSAgICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAyOCwgMjAwNiAgICAgICAgICAgIFtQYWdlIDJdIAwNCgoKCklu dGVybmV0IERyYWZ0ICBTSVAtQmFzZWQgVm9JUCBQZWVyaW5nIFJlcXVpcmVtZW50cyAgRmViIDIw MDYgDQogICAgICAzLjMwIDEuMTAwMCAgUmVmZXJlbmNlIEFyY2hpdGVjdHVyZSAgIDggDQogICAg ICAzLjMxIDEuMTEwMCAgVHJhbnNwb3J0ICh1ZHAsIHRjcCwgc2N0cCkgICA4IA0KICAgICAgMy4z MiAxLjEyMDAgIEFkZHJlc3NpbmcgICA4IA0KICAgICAgMy4zMyAxLjEzMDAgIEROUyAoU1JWKSBi YXNlZCBSZXF1aXJlbWVudHMgICA4IA0KICAgICAgMy4zNCAxLjE0MDAgIEFkYXB0aXZlIFJvdXRp bmcgICA4IA0KICAgICAgMy4zNSAxLjE1MDAgIEhhaXJwaW4gaGFuZGxpbmcgICA4IA0KICAgICAg My4zNiAxLjE2MDAgIEZvcmtpbmcgdi9zIE5vbiBGb3JraW5nICAgOCANCiAgICAgIDMuMzcgMS4y MDAwICBFcnJvciBIYW5kbGluZyBSZXF1aXJlbWVudHMgICA4IA0KICAgICAgMy4zOCAxLjIxMDAg IEludGVycHJldGF0aW9uIG9mIEVycm9yIENvZGVzICAgOCANCiAgICAgIDMuMzkgMS4zMDAwICBN ZWRpYSBSZXNvdXJjZXMgICA4IA0KICAgICAgMy40MCAxLjMxMDAgIENvZGVjIFN1cHBvcnQgICA4 IA0KICAgICAgMy40MSAxLjMyMDAgIE1lZGlhIFByb2Nlc3NpbmcgICA4IA0KICAgICAgMy40MiAx LjUwMDAgIEludGVyd29ya2luZyAgIDggDQogICAgICAzLjQzIDEuNTEwMCAgQ2FsbGVyL0NhbGxl ZSBQcmVmZXJlbmNlcyBNaXNtYXRjaCAgIDggDQogICAgICAzLjQ0IDEuNTIwMCAgVHJhbnNjb2Rp bmcgICA4IA0KICAgICAgMy40NSAxLjYwMDAgIENhbGwgRGl2ZXJzaW9uIGFuZCBGb3J3YXJkaW5n ICAgOCANCiAgICAgIDMuNDYgMi4wMDAwICBPcGVyYXRpb25zIE1hbmFnZW1lbnQgICA4IA0KICAg ICAgMy40NyAyLjEwMDAgIE9wZXJhdGlvbmFsIE1lYXN1cmVtZW50cyAgIDggDQogICAgICAzLjQ4 IDIuMTEwMCAgSW50ZXJjb25uZWN0IFBlcmZvcm1hbmNlICAgOCANCiAgICAgIDMuNDkgMi4xMjAw ICBBcHBsaWNhdGlvbiBQZXJmb3JtYW5jZSAgIDggDQogICAgICAzLjUwIDIuMTMwMCAgQ3VzdG9t ZXIgUGVyY2VwdGlvbiBvZiBTZXJ2aWNlIFBlcmZvcm1hbmNlICAgOCANCiAgICAgIDMuNTEgMi4x NDAwICBFbmdpbmVlcmluZyBPcGVyYXRpb25zIFJlcG9ydHMgICA4IA0KICAgICAgMy41MiAyLjE1 MDAgIEJ1c2luZXNzIE9wZXJhdGlvbnMgUmVwb3J0cyAgIDkgDQogICAgICAzLjUzIDIuMTYwMCAg SVAgZGVzdGluYXRpb25zICAgOSANCiAgICAgIDMuNTQgMi4xNjEwICBSb3V0ZXMvYnJlYWtvdXRz IHdpdGhpbiBJUCBkZXN0aW5hdGlvbnMgICA5IA0KICAgICAgMy41NSAyLjIwMDAgIE5ldHdvcmsg YW5kIFN5c3RlbXMgTWFuYWdlbWVudCAgIDkgDQogICAgICAzLjU2IDIuMjEwMCAgQ29udHJvbCBQ b2ludHMgICA5IA0KICAgICAgMy41NyAyLjIyMDAgIEFsYXJtcyAgIDkgDQogICAgICAzLjU4IDIu MjMwMCAgUHJvdmlzaW9uaW5nICAgOSANCiAgICAgIDMuNTkgMi4yNDAwICBDZW50cmFsaXplZCBN YW5hZ2VtZW50ICAgOSANCiAgICAgIDMuNjAgMi4yNTAwICBEaXN0cmlidXRlZCBNYW5hZ2VtZW50 ICAgOSANCiAgICAgIDMuNjEgMi4zMDAwICBTZXNzaW9uIE1hbmFnZW1lbnQgICA5IA0KICAgICAg My42MiAyLjcwMDAgIEludGVybmF0aW9uYWwgT3BlcmF0aW9ucyBTdXBwb3J0ICAgOSANCiAgICAg IDMuNjMgMi44MDAwICBJbnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIE5PQy9PU1MvQlNTIEZ1bmN0 aW9ucyAgIDkgDQogICAgICAzLjY0IDIuOTAwMCAgTGVnYWN5IFBlZXJpbmcgQWdyZWVtZW50cyAg IDkgDQogICAgICAzLjY1IDMuMDAwMCAgUGFydGl0aW9uaW5nICAgOSANCiAgICAgIDMuNjYgMy4x MDAwICBTZWdtZW50YXRpb24vQ2xhc3NpZmljYXRpb24gb2YgU2Vzc2lvbnMgICA5IA0KICAgICAg My42NyAzLjIwMDAgIFNlZ21lbnRhdGlvbi9DbGFzc2lmaWNhdGlvbiBvZiBUcmFmZmljICAgOSAN CiAgICAgIDMuNjggMy4zMDAwICBOdW1iZXJpbmcgUGxhbnMgICA5IA0KICAgICAgMy42OSA0LjAw MDAgIEFjY291bnRpbmcgICA5IA0KICAgICAgMy43MCA0LjEwMDAgIENhbGwgQWNjb3VudGluZyAg IDkgDQogICAgICAzLjcxIDQuMTEwMCAgQ0RSIEdlbmVyYXRpb24gICA5IA0KICAgICAgMy43MiA0 LjEyMDAgIENEUiBTdG9yYWdlICAgOSANCiAgICAgIDMuNzMgNC4xMzAwICBDRFIgUmV0cmlldmFs ICAgOSANCiAgICAgIDMuNzQgNC4xNDAwICBDRFIgU3RyZWFtaW5nICAgMTAgDQogDQogDQpOYXRh bGUgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjgsIDIwMDYgICAgICAgICAgICBbUGFnZSAz XSAMDQoKCgpJbnRlcm5ldCBEcmFmdCAgU0lQLUJhc2VkIFZvSVAgUGVlcmluZyBSZXF1aXJlbWVu dHMgIEZlYiAyMDA2IA0KICAgICAgMy43NSA0LjE1MDAgIENEUiBSZXBvcnRpbmcgICAxMCANCiAg ICAgIDMuNzYgNC4xNjAwICAzcmQtUGFydHkgQ0RSIFN1cHBvcnQgICAxMCANCiAgICAgIDMuNzcg NC4yMDAwICBTZXNzaW9uIEFjY291bnRpbmcgICAxMCANCiAgICAgIDMuNzggNC4zMDAwICBCaWxs aW5nICAgMTAgDQogICAgICAzLjc5IDUuMDAwMCAgU0xBcyAgIDEwIA0KICAgICAgMy44MCA1LjEw MDAgIFNMQSBEZWZpbml0aW9uICAgMTAgDQogICAgICAzLjgxIDUuMjAwMCAgU0xBIEVuZm9yY2Vt ZW50ICAgMTAgDQogICAgICAzLjgyIDUuMjEwMCAgRGlmZlNydiAgIDEwIA0KICAgICAgMy44MyA1 LjIxMTAgIFBvbGljaW5nICAgMTAgDQogICAgICAzLjg0IDUuMjEyMCAgUmUtbWFya2luZyAgIDEw IA0KICAgICAgMy44NSA1LjMwMDAgIFF1YWxpdHkgb2YgU2VydmljZSAoUW9TKSAgIDEwIA0KICAg ICAgMy44NiA1LjMxMDAgIFNlcnZpY2UgUXVhbGl0eSBNZXRyaWNzICAgMTAgDQogICAgICAzLjg3 IDUuMzIwMCAgU2VydmljZSBRdWFsaXR5IFJlcG9ydGluZyAgIDEwIA0KICAgICAgMy44OCA1LjQw MDAgIENhbGwgQWRtaXNzaW9uIENvbnRyb2wgICAxMCANCiAgICAgIDMuODkgNS41MDAwICBTZXNz aW9uIGFkbWlzc2lvbiBjb250cm9sICAgMTAgDQogICAgICAzLjkwIDYuMDAwMCAgU2VjdXJpdHkg ICAxMCANCiAgICAgIDMuOTEgNi4xMDAwICBQcmV2ZW50IERlbmlhbCBvZiBTZXJ2aWNlIEF0dGFj a3MgICAxMCANCiAgICAgIDMuOTIgNi4xMTAwICBQcmV2ZW50IFNQQU0gb3ZlciBJbnRlcm5ldCBU ZWxlcGhvbnkgKFNQSVQpICAgMTAgDQogICAgICAzLjkzIDYuMTIwMCAgUHJldmVudCBTZXJ2aWNl IEFidXNlICAgMTAgDQogICAgICAzLjk0IDYuMTMwMCAgUHJldmVudCBTZXJ2aWNlIFRoZWZ0ICAg MTAgDQogICAgICAzLjk1IDYuMjAwMCAgVG9wb2xvZ3kgSGlkaW5nICAgMTAgDQogICAgICAzLjk2 IDYuMzAwMCAgU2VydmljZSBFbmZvcmNlbWVudCAgIDExIA0KICAgICAgMy45NyA2LjQwMDAgIFNl Y3VyaXR5IFByb3RvY29scyAgIDExIA0KICAgICAgMy45OCA2LjQxMDAgIEF1dGhlbnRpY2F0aW9u ICAgMTEgDQogICAgICAzLjk5IDYuNDIwMCAgRW5jcnlwdGlvbiAgIDExIA0KICAgICAgMy4xMDAg Ni41MDAwICBQcml2YWN5IFJlcXVpcmVtZW50cyAgIDExIA0KICAgICAgMy4xMDEgNi41MTAwICBJ ZGVudGl0eSBSZXF1aXJlbWVudHMgICAxMSANCiAgICAgIDMuMTAyIDYuNTIwMCAgU3Vic2NyaWJl ciBEYXRhIFByb3RlY3Rpb24gICAxMSANCiAgICAgIDMuMTAzIDYuNjAwMCAgU0RQIHRhbXBlcmlu ZyAgIDExIA0KNC4gUmVxdWlyZW1lbnRzIHRvIFBlZXJpbmcgQXJjaGl0ZWN0dXJlIE1hcHBpbmcg ICAxMSANCjUuIEFja25vd2xlZGdtZW50cyAgIDExIA0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgICAxMiANCjcuIElBTkEgQ29uc2lkZXJhdGlvbnMgICAxMiANCjguIFJlZmVyZW5jZXMgICAx MiANCiAgICAgIDguMSBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgIDEyIA0KICAgICAgOC4yIEluZm9y bWF0aW9uYWwgUmVmZXJlbmNlcyAgIDEyIA0KOS4gQXV0aG9yJ3MgQWRkcmVzc2VzICAgMTIgDQox MC4gRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50ICAgMTMgDQoxMS4gSW50ZWxsZWN0dWFsIFByb3Bl cnR5ICAgMTMgDQoxMi4gQWNrbm93bGVkZ21lbnQgICAxNCANCiANCiANCjEuIA0gIEludHJvZHVj dGlvbiANCiANCgogDQogDQpOYXRhbGUgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjgsIDIw MDYgICAgICAgICAgICBbUGFnZSA0XSAMDQoKCgpJbnRlcm5ldCBEcmFmdCAgU0lQLUJhc2VkIFZv SVAgUGVlcmluZyBSZXF1aXJlbWVudHMgIEZlYiAyMDA2IA0KICAgVGhlIFNQRUVSTUlOVCBXRyBh ZGRyZXNzZXMgdGhlIHVzZSBvZiB0aGUgU0lQIHNpZ25hbGluZyBwcm90b2NvbCB0byANCiAgIGVu YWJsZSByZWFsLXRpbWUgc2Vzc2lvbiBwZWVyaW5nIGJldHdlZW4gdHdvIG9yIG1vcmUgYWRtaW5p c3RyYXRpdmUgDQogICBkb21haW5zIG92ZXIgSVAgbmV0d29ya3MuICBUbyBhY2hpZXZlIHRoZSBr aW5kIG9mIHJlYWwtdGltZSBzZXNzaW9uIA0KICAgcGVlcmluZyBpbnRlbmRlZCwgYm90aCBzaWdu YWxpbmcgYW5kIG1lZGlhIGZsb3dzIG11c3QgYmUgdGFrZW4gaW50byANCiAgIGNvbnNpZGVyYXRp b24uICBXaGlsZSB0aGUgbG9uZy10ZXJtIGdvYWwgaXMgdG8gc3VwcG9ydCBhIHZhcmlldHkgb2Yg DQogICAicmljaCBtZWRpYSIgKG11bHRpbWVkaWEpIGFwcGxpY2F0aW9ucywgdGhlIGluaXRpYWwg Zm9jdXMgaXMgb24gU0lQLQ0KICAgYmFzZWQgVm9pY2Ugb3ZlciBJUCAoVm9JUCkuIA0KICAgIA0K ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHJlcXVpcmVtZW50cyB0byBlbmFibGUgU0lQLWJhc2Vk IFZvSVAgcGVlcmluZyANCiAgIGFtb25nIHR3byBvciBtb3JlIGFkbWluaXN0cmF0aXZlIGRvbWFp bnMuICBWYWxpZCBwZWVyaW5nIHJlbGF0aW9uc2hpcHMgDQogICBleGlzdCBpbiBtdWx0aXBsZSBh cmNoaXRlY3R1cmVzLiAgU2VjdGlvbiAzIG91dGxpbmVzIHRoZSBjb2xsZWN0aW9uIG9mIA0KICAg YWxsIHJlcXVpcmVtZW50cyB0aGF0IG1pZ2h0IGluZGl2aWR1YWxseSBhcHBseSB0byBhbnkgYXBw bGljYWJsZSANCiAgIHBlZXJpbmcgYXJjaGl0ZWN0dXJlLiAgU2VjdGlvbiA0IHByZXNlbnRzIGEg dGFidWxhciB2aWV3IG9mIHN1YnNldCANCiAgIGFwcGxpY2FiaWxpdHkgaW4gd2hpY2ggdGhlIHJv d3MgYXJlIHRoZSBjb2xsZWN0aW9uIG9mIHJlcXVpcmVtZW50cyBhbmQgDQogICB0aGUgY29sdW1u cyBhcmUgdGhlIHBlZXJpbmcgYXJjaGl0ZWN0dXJlIGFsdGVybmF0aXZlcy4gDQogDQoyLiANICBU ZXJtaW5vbG9neSANCiANCiAgIEluIHRoaXMgZG9jdW1lbnQsIHRoZSBrZXkgd29yZHMgJ01VU1Qn LCAnTVVTVCBOT1QnLCAnUkVRVUlSRUQnLCAgICANCiAgICdTSEFMTCcsICdTSEFMTCBOT1QnLCAn U0hPVUxEJywgJ1NIT1VMRCBOT1QnLCAnUkVDT01NRU5ERUQnLCAnTUFZJywgYW5kIA0KICAgJ09Q VElPTkFMJyBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtS RkMyMTE5XSBhbmQgDQogICBpbmRpY2F0ZSByZXF1aXJlbWVudCBsZXZlbHMgZm9yIGNvbXBsaWFu dCBTSVAgaW1wbGVtZW50YXRpb25zLiANCiAgICANCjIuMSANICBWb0lQIFBlZXJpbmcgQXJjaGl0 ZWN0dXJlcyANCiANCiAgIFRoZSB0YXhvbm9teSBhbmQgZGVmaW5pdGlvbnMgZm9yIHByZXNlbnRl ZCBpbiB0aGlzIHNlY3Rpb24gYW5kIHVzZWQgaW4gDQogICBsYXRlciBzZWN0aW9ucyBvZiB0aGlz IGRvY3VtZW50IGNvbWUgZnJvbSBkcmFmdC1iaGF0aWEtc2lwLXBlZXJpbmctDQogICAwMC50eHQg KHdvcmsgaW4gcHJvZ3Jlc3MpLiBbMV0gDQogICAgDQogICBUaGUgZm9sbG93aW5nIGZpZ3VyZSBj b21lcyBmcm9tIHRoYXQgZG9jdW1lbnQgYW5kIHByb3ZpZGVzIGVzc2VudGlhbCANCiAgIHJlZmVy ZW5jZSB0ZXJtaW5vbG9neTogDQogDQogICArLS0tKyAgIC9+fn5+fn5cICAgIC9+fn5+XCAgICAv fn5+fn5+flwgICAgL35+fn5cICAgIC9+fn5+fn5cICAgKy0tLSsgDQogICB8IE8gfC0+KEFjY2Vz cy1PKS0+KENvcmUtTyktPihJbnRlcmNvbm4pLT4oQ29yZS1UKS0+KEFjY2Vzcy1UKS0+fCBUIHwg DQogICArLS0tKyAgIFx+fn5+fn4vICAgIFx+fn5+LyAgICBcfn5+fn5+fi8gICAgXH5+fn4vICAg IFx+fn5+fn4vICAgKy0tLSsgDQogDQogDQogDQogDQoyLjIgDSAgRGlyZWN0IFBlZXJpbmcgDQog DQogICBEaXJlY3QgUGVlcmluZyBpcyB0aGUgcGVlcmluZyBiZXR3ZWVuIENvcmUtTyBhbmQgQ29y ZS1UIHdpdGhvdXQgYW55IA0KICAgb3RoZXIgVm9JUCBTUCBpbiB0aGUgbWlkZGxlLiAgSXQgdHlw aWNhbGx5IHRha2VzIHR3byBmb3JtcyBkZXBlbmRpbmcgb24gDQogICBob3cgc29tZSBwYXJ0IG9m IHRoZSBwZWVyaW5nIHBvbGljeSBtYXkgYmUgcHJvdmlzaW9uZWQsIEZlZGVyYXRpb24gb3IgDQog ICBsb2NhbCBwb2xpY3kuIA0KIA0KIA0KTmF0YWxlICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0 IDI4LCAyMDA2ICAgICAgICAgICAgW1BhZ2UgNV0gDA0KCgoKSW50ZXJuZXQgRHJhZnQgIFNJUC1C YXNlZCBWb0lQIFBlZXJpbmcgUmVxdWlyZW1lbnRzICBGZWIgMjAwNiANCiAgICANCjIuMyANICBJ bnRlcmNvbm5lY3QgUGVlcmluZyANCiANCiAgIEluIG1vc3QgY2FzZXMgdGhpcyBtb2RlbCBpcyB1 c2VkIHdoZW4gdGhlIG9yaWdpbmF0aW9uIFNQIGRvZXMgbm90IA0KICAgcHJlZmVyIHRvIGRpcmVj dGx5IGNvbm5lY3QgdG8gYSB0ZXJtaW5hdGlvbiBTUCBkdWUgdG8gYnVzaW5lc3MgcmVhc29ucy4g IA0KICAgSW50ZXJjb25uZWN0IFNQIG1heSBhbHNvIGJlIHVzZWQgYmV0d2VlbiB0aGUgYWNjZXNz IFNQIGFuZCB0aGUgQ29yZSBTUCANCiAgIGR1ZSB0byBzaW1pbGFyIHJlYXNvbnMuIA0KIA0KMi40 IA0gIEFjY2VzcyBQZWVyaW5nIA0KIA0KICAgQWNjZXNzIFBlZXJpbmcgbWF5IHR5cGljYWxseSBi ZSB1c2VkIHdoZW4gdGhlIHN1YnNjcmliZXIgcm9hbXMgdG8gYSANCiAgIHBsYWNlIHRoZSBDb3Jl IFNQIGRvZXMgbm90IG9mZmVyIHNlcnZpY2Ugb3IgaXMgdXNpbmcgYSBMYXllciA1IGF3YXJlIFNQ IA0KICAgdG8gY29ubmVjdCB0byBpdHMgQ29yZSBTUCAod2hpY2ggbWF5IGJlIGFuIEFTUCBvciBj b250ZW50IHByb3ZpZGVyKS4gDQogDQozLiANICBSZXF1aXJlbWVudHMgQ2F0YWxvZ3VlIA0KIA0K ICAgRWFjaCBjYW5kaWRhdGUgcmVxdWlyZW1lbnRzIGlzIHByZXNlbnRlZCBpbiBhIHNlcGFyYXRl IHN1YnNlY3Rpb24uICBJbiANCiAgIGFkZGl0aW9uIHRvIHRoZSBzdWJzZWN0aW9uIG51bWJlciwg YW4gb3JkZXJlZCBudW1lcmljIHJlcXVpcmVtZW50IElEIA0KICAgYW5kIGEgcmVxdWlyZW1lbnQg dGl0bGUgYXJlIHVzZWQgdG8gaWRlbnRpZnkgZWFjaCByZXF1aXJlbWVudC4gIFRoZSANCiAgIG51 bWVyaWMgcmVxdWlyZW1lbnQgSUQgb3JkZXJpbmcgaXMgaW50ZW5kZWQgdG8gY29udmV5IHRlbnRh dGl2ZSBkZWdyZWVzIA0KICAgb2YgYm90aCBhc3NvY2lhdGlvbiBhbmQsIHdoZXJlIGFwcHJvcHJp YXRlLCBoaWVyYXJjaHkuIA0KICAgIA0KICAgRGVzY3JpcHRpdmUgYW5kIHByZXNjcmlwdGl2ZSB0 ZXh0IHdpbGwgYmUgYWRkZWQgaW4gZnV0dXJlIHZlcnNpb25zIG9mIA0KICAgdGhpcyBkb2N1bWVu dCwgb25jZSB0aGUgV0cgaGFzIHJlYWNoZWQgY29uc2Vuc3VzIG9uIHRoZSBzcGVjaWZpYyBzZXQg b2YgDQogICByZXF1aXJlbWVudHMgdG8gYmUgaW5jbHVkZWQuIA0KICAgIA0KICAgQWxzbywgcmVx dWlyZW1lbnRzIHN0YXRlbWVudHMgaW4gWzJdIG11c3QgYmUgcmVjb25jaWxlZCB3aXRoIHRoaXMg YW5kIA0KICAgb3RoZXIgZG9jdW1lbnRzLiAgQXQgcHJlc2VudCwgdGhlIGludGVuZGVkIGNvbnRl eHQgb2YgdGhvc2UgDQogICByZXF1aXJlbWVudHMgaXMgdW5jbGVhciAtLSBpLmUuLCBpbnRlbmRl ZCB0byBndWlkZSBXRyB3b3JrIG9yIGFjdHVhbCANCiAgIHBlZXJpbmcgb3BlcmF0aW9ucz8gDQog DQozLjEgDSAgMC4wMDAwICBHZW5lcmFsIFJlcXVpcmVtZW50cyANCiANCjMuMiANICAwLjEwMDAg IFBlZXJpbmcgQXJjaGl0ZWN0dXJlcyANCiANCjMuMyANICAwLjExMDAgIFNlY3VyaXR5IA0KIA0K My40IA0gIDAuMTIwMCAgUmVzaWxpZW5jeSANCiANCjMuNSANICAwLjEzMDAgIFBlcmZvcm1hbmNl IA0KIA0KMy42IA0gIDAuMTQwMCAgU2NhbGFiaWxpdHkgDQogDQozLjcgDSAgMC4yMDAwICBQZWVy aW5nIEFncmVlbWVudHMgDQogDQogDQogDQpOYXRhbGUgICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjgsIDIwMDYgICAgICAgICAgICBbUGFnZSA2XSAMDQoKCgpJbnRlcm5ldCBEcmFmdCAgU0lQ LUJhc2VkIFZvSVAgUGVlcmluZyBSZXF1aXJlbWVudHMgIEZlYiAyMDA2IA0KMy44IA0gIDAuMjEw MCAgUmVndWxhdG9yeSBSZXF1aXJlbWVudHMgDQogDQozLjkgDSAgMC4yMTEwICBFcXVhbCBBY2Nl c3MgDQogDQozLjEwIA0gICAwLjIxMjAgIExhd2Z1bCBJbnRlcmNlcHQgDQogDQozLjExIA0gICAw LjIxMzAgIE51bWJlciBQb3J0YWJpbGl0eSANCiANCjMuMTIgDSAgIDAuMjE1MCAgUFNUTiBJbnRl cmZhY2VzIA0KIA0KMy4xMyANICAgMC4yMjAwICBUcmFmZmljIEV4Y2hhbmdlIEZhY2lsaXRhdGlv biANCiANCjMuMTQgDSAgIDAuMjMwMCAgRXh0ZW5zaWJpbGl0eSB0byBOZXcgUGVlcmluZyBFbnRp dGllcyANCiANCjMuMTUgDSAgIDAuMjQwMCAgU2VydmljZSBJbmRlcGVuZGVuY2UgDQogDQozLjE2 IA0gICAwLjI1MDAgIEZlYXR1cmUgVHJhbnNwYXJlbmN5IA0KIA0KMy4xNyANICAgMC4zMDAwICBT ZXJ2aWNlIERpc2NvdmVyeSANCiANCjMuMTggDSAgIDAuNDAwMCAgU2VydmljZSBMb2NhdGlvbiAN CiANCjMuMTkgDSAgIDAuNTAwMCAgU2lnbmFsaW5nIChTSVAsIFJGQyAzMjYxKSANCiANCjMuMjAg DSAgIDAuNTEwMCAgU0lQIEV4dGVuc2lvbnMgDQogDQozLjIxIA0gICAwLjYwMDAgIFByb3h5IEZ1 bmN0aW9ucyANCiANCjMuMjIgDSAgIDAuNzAwMCAgQWRkcmVzc2luZyANCiANCjMuMjMgDSAgIDAu ODAwMCAgUm91dGluZyAoUG9saWN5LUJhc2VkLCBUcnVzdCBSZWxhdGlvbnNoaXBzKSANCiANCjMu MjQgDSAgIDAuODEwMCAgU2lnbmFsaW5nIFJvdXRpbmcgDQogDQozLjI1IA0gICAwLjgyMDAgIE1l ZGlhIFJvdXRpbmcgDQogDQozLjI2IA0gICAwLjgzMDAgIENhbGwgUm91dGluZyANCiANCjMuMjcg DSAgIDAuODQwMCAgU2Vzc2lvbiBSb3V0aW5nIA0KIA0KMy4yOCANICAgMC45MDAwICBUcmFuc3Bv cnQgDQogDQozLjI5IA0gICAxLjAwMDAgIE5ldHdvcmsgQXJjaGl0ZWN0dXJlIA0KIA0KCiANCiAN Ck5hdGFsZSAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOCwgMjAwNiAgICAgICAgICAgIFtQ YWdlIDddIAwNCgoKCkludGVybmV0IERyYWZ0ICBTSVAtQmFzZWQgVm9JUCBQZWVyaW5nIFJlcXVp cmVtZW50cyAgRmViIDIwMDYgDQozLjMwIA0gICAxLjEwMDAgIFJlZmVyZW5jZSBBcmNoaXRlY3R1 cmUgDQogDQozLjMxIA0gICAxLjExMDAgIFRyYW5zcG9ydCAodWRwLCB0Y3AsIHNjdHApIA0KIA0K My4zMiANICAgMS4xMjAwICBBZGRyZXNzaW5nIA0KIA0KMy4zMyANICAgMS4xMzAwICBETlMgKFNS VikgYmFzZWQgUmVxdWlyZW1lbnRzIA0KIA0KMy4zNCANICAgMS4xNDAwICBBZGFwdGl2ZSBSb3V0 aW5nIA0KIA0KMy4zNSANICAgMS4xNTAwICBIYWlycGluIGhhbmRsaW5nIA0KIA0KMy4zNiANICAg MS4xNjAwICBGb3JraW5nIHYvcyBOb24gRm9ya2luZyANCiANCjMuMzcgDSAgIDEuMjAwMCAgRXJy b3IgSGFuZGxpbmcgUmVxdWlyZW1lbnRzIA0KIA0KMy4zOCANICAgMS4yMTAwICBJbnRlcnByZXRh dGlvbiBvZiBFcnJvciBDb2RlcyANCiANCjMuMzkgDSAgIDEuMzAwMCAgTWVkaWEgUmVzb3VyY2Vz IA0KIA0KMy40MCANICAgMS4zMTAwICBDb2RlYyBTdXBwb3J0IA0KIA0KMy40MSANICAgMS4zMjAw ICBNZWRpYSBQcm9jZXNzaW5nIA0KIA0KMy40MiANICAgMS41MDAwICBJbnRlcndvcmtpbmcgDQog DQozLjQzIA0gICAxLjUxMDAgIENhbGxlci9DYWxsZWUgUHJlZmVyZW5jZXMgTWlzbWF0Y2ggDQog DQozLjQ0IA0gICAxLjUyMDAgIFRyYW5zY29kaW5nIA0KIA0KMy40NSANICAgMS42MDAwICBDYWxs IERpdmVyc2lvbiBhbmQgRm9yd2FyZGluZyANCiANCjMuNDYgDSAgIDIuMDAwMCAgT3BlcmF0aW9u cyBNYW5hZ2VtZW50IA0KIA0KMy40NyANICAgMi4xMDAwICBPcGVyYXRpb25hbCBNZWFzdXJlbWVu dHMgDQogDQozLjQ4IA0gICAyLjExMDAgIEludGVyY29ubmVjdCBQZXJmb3JtYW5jZSANCiANCjMu NDkgDSAgIDIuMTIwMCAgQXBwbGljYXRpb24gUGVyZm9ybWFuY2UgDQogDQozLjUwIA0gICAyLjEz MDAgIEN1c3RvbWVyIFBlcmNlcHRpb24gb2YgU2VydmljZSBQZXJmb3JtYW5jZSANCiANCjMuNTEg DSAgIDIuMTQwMCAgRW5naW5lZXJpbmcgT3BlcmF0aW9ucyBSZXBvcnRzIA0KIA0KCiANCiANCk5h dGFsZSAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOCwgMjAwNiAgICAgICAgICAgIFtQYWdl IDhdIAwNCgoKCkludGVybmV0IERyYWZ0ICBTSVAtQmFzZWQgVm9JUCBQZWVyaW5nIFJlcXVpcmVt ZW50cyAgRmViIDIwMDYgDQozLjUyIA0gICAyLjE1MDAgIEJ1c2luZXNzIE9wZXJhdGlvbnMgUmVw b3J0cyANCiANCjMuNTMgDSAgIDIuMTYwMCAgSVAgZGVzdGluYXRpb25zIA0KIA0KMy41NCANICAg Mi4xNjEwICBSb3V0ZXMvYnJlYWtvdXRzIHdpdGhpbiBJUCBkZXN0aW5hdGlvbnMgDQogDQozLjU1 IA0gICAyLjIwMDAgIE5ldHdvcmsgYW5kIFN5c3RlbXMgTWFuYWdlbWVudCANCiANCjMuNTYgDSAg IDIuMjEwMCAgQ29udHJvbCBQb2ludHMgDQogDQozLjU3IA0gICAyLjIyMDAgIEFsYXJtcyANCiAN CjMuNTggDSAgIDIuMjMwMCAgUHJvdmlzaW9uaW5nIA0KIA0KMy41OSANICAgMi4yNDAwICBDZW50 cmFsaXplZCBNYW5hZ2VtZW50IA0KIA0KMy42MCANICAgMi4yNTAwICBEaXN0cmlidXRlZCBNYW5h Z2VtZW50IA0KIA0KMy42MSANICAgMi4zMDAwICBTZXNzaW9uIE1hbmFnZW1lbnQgDQogDQozLjYy IA0gICAyLjcwMDAgIEludGVybmF0aW9uYWwgT3BlcmF0aW9ucyBTdXBwb3J0IA0KIA0KMy42MyAN ICAgMi44MDAwICBJbnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIE5PQy9PU1MvQlNTIEZ1bmN0aW9u cyANCiANCjMuNjQgDSAgIDIuOTAwMCAgTGVnYWN5IFBlZXJpbmcgQWdyZWVtZW50cyANCiANCjMu NjUgDSAgIDMuMDAwMCAgUGFydGl0aW9uaW5nIA0KIA0KMy42NiANICAgMy4xMDAwICBTZWdtZW50 YXRpb24vQ2xhc3NpZmljYXRpb24gb2YgU2Vzc2lvbnMgDQogDQozLjY3IA0gICAzLjIwMDAgIFNl Z21lbnRhdGlvbi9DbGFzc2lmaWNhdGlvbiBvZiBUcmFmZmljIA0KIA0KMy42OCANICAgMy4zMDAw ICBOdW1iZXJpbmcgUGxhbnMgDQogDQozLjY5IA0gICA0LjAwMDAgIEFjY291bnRpbmcgDQogDQoz LjcwIA0gICA0LjEwMDAgIENhbGwgQWNjb3VudGluZyANCiANCjMuNzEgDSAgIDQuMTEwMCAgQ0RS IEdlbmVyYXRpb24gDQogDQozLjcyIA0gICA0LjEyMDAgIENEUiBTdG9yYWdlIA0KIA0KMy43MyAN ICAgNC4xMzAwICBDRFIgUmV0cmlldmFsIA0KIA0KCiANCiANCk5hdGFsZSAgICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAyOCwgMjAwNiAgICAgICAgICAgIFtQYWdlIDldIAwNCgoKCkludGVybmV0 IERyYWZ0ICBTSVAtQmFzZWQgVm9JUCBQZWVyaW5nIFJlcXVpcmVtZW50cyAgRmViIDIwMDYgDQoz Ljc0IA0gICA0LjE0MDAgIENEUiBTdHJlYW1pbmcgDQogDQozLjc1IA0gICA0LjE1MDAgIENEUiBS ZXBvcnRpbmcgDQogDQozLjc2IA0gICA0LjE2MDAgIDNyZC1QYXJ0eSBDRFIgU3VwcG9ydCANCiAN CjMuNzcgDSAgIDQuMjAwMCAgU2Vzc2lvbiBBY2NvdW50aW5nIA0KIA0KMy43OCANICAgNC4zMDAw ICBCaWxsaW5nIA0KIA0KMy43OSANICAgNS4wMDAwICBTTEFzIA0KIA0KMy44MCANICAgNS4xMDAw ICBTTEEgRGVmaW5pdGlvbiANCiANCjMuODEgDSAgIDUuMjAwMCAgU0xBIEVuZm9yY2VtZW50IA0K IA0KMy44MiANICAgNS4yMTAwICBEaWZmU3J2IA0KIA0KMy44MyANICAgNS4yMTEwICBQb2xpY2lu ZyANCiANCjMuODQgDSAgIDUuMjEyMCAgUmUtbWFya2luZyANCiANCjMuODUgDSAgIDUuMzAwMCAg UXVhbGl0eSBvZiBTZXJ2aWNlIChRb1MpIA0KIA0KMy44NiANICAgNS4zMTAwICBTZXJ2aWNlIFF1 YWxpdHkgTWV0cmljcyANCiANCjMuODcgDSAgIDUuMzIwMCAgU2VydmljZSBRdWFsaXR5IFJlcG9y dGluZyAgDQogDQozLjg4IA0gICA1LjQwMDAgIENhbGwgQWRtaXNzaW9uIENvbnRyb2wgDQogDQoz Ljg5IA0gICA1LjUwMDAgIFNlc3Npb24gYWRtaXNzaW9uIGNvbnRyb2wgDQogDQozLjkwIA0gICA2 LjAwMDAgIFNlY3VyaXR5IA0KIA0KMy45MSANICAgNi4xMDAwICBQcmV2ZW50IERlbmlhbCBvZiBT ZXJ2aWNlIEF0dGFja3MgDQogDQozLjkyIA0gICA2LjExMDAgIFByZXZlbnQgU1BBTSBvdmVyIElu dGVybmV0IFRlbGVwaG9ueSAoU1BJVCkgDQogDQozLjkzIA0gICA2LjEyMDAgIFByZXZlbnQgU2Vy dmljZSBBYnVzZSANCiANCjMuOTQgDSAgIDYuMTMwMCAgUHJldmVudCBTZXJ2aWNlIFRoZWZ0IA0K IA0KMy45NSANICAgNi4yMDAwICBUb3BvbG9neSBIaWRpbmcgDQogDQogDQogDQpOYXRhbGUgICAg ICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjgsIDIwMDYgICAgICAgICAgICBbUGFnZSANCjEwXSAM DQoKCgpJbnRlcm5ldCBEcmFmdCAgU0lQLUJhc2VkIFZvSVAgUGVlcmluZyBSZXF1aXJlbWVudHMg IEZlYiAyMDA2IA0KMy45NiANICAgNi4zMDAwICBTZXJ2aWNlIEVuZm9yY2VtZW50IA0KIA0KMy45 NyANICAgNi40MDAwICBTZWN1cml0eSBQcm90b2NvbHMgDQogDQozLjk4IA0gICA2LjQxMDAgIEF1 dGhlbnRpY2F0aW9uIA0KIA0KMy45OSANICAgNi40MjAwICBFbmNyeXB0aW9uIA0KIA0KMy4xMDAg DSAgICA2LjUwMDAgIFByaXZhY3kgUmVxdWlyZW1lbnRzIA0KIA0KMy4xMDEgDSAgICA2LjUxMDAg IElkZW50aXR5IFJlcXVpcmVtZW50cyANCiANCjMuMTAyIA0gICAgNi41MjAwICBTdWJzY3JpYmVy IERhdGEgUHJvdGVjdGlvbiANCiANCjMuMTAzIA0gICAgNi42MDAwICBTRFAgdGFtcGVyaW5nIA0K IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KNC4gDSAgUmVxdWlyZW1lbnRzIHRv IFBlZXJpbmcgQXJjaGl0ZWN0dXJlIE1hcHBpbmcgDQogDQogICBJbiBhIGZ1dHVyZSB2ZXJzaW9u IG9mIHRoaXMgZG9jdW1lbnQsIHRoaXMgc2VjdGlvbiB3aWxsIHByZXNlbnQgYW4gDQogICBBU0NJ SS1hcnQgdGFibGUgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIGxpc3RlZCBhcyByb3cgaGVhZGluZ3Mg YW5kIHRoZSANCiAgIHBlZXJpbmcgYXJjaGl0ZWN0dXJlcyBsaXN0ZWQgYXMgY29sdW1uIGhlYWRp bmdzLiAgU29tZSBzY2hlbWUgc3VjaCBhcyANCiAgIHRoZSBmb2xsb3dpbmcgKFRCRCBieSBXRyBj b25zZW5zdXMpIHdpbGwgYmUgdXNlZCB0byBkZW5vdGUgDQogICBhcHBsaWNhYmlsaXR5OiANCiAg ICANCiAgIE0gPSBNYW5kYXRvcnkgDQogICBSID0gUmVjb21tZW5kZWQgDQogICBPID0gT3B0aW9u YWwgDQogICBYID0gTm90IGFwcGxpY2FibGUgDQogDQogDQo1LiANICBBY2tub3dsZWRnbWVudHMg DQogDQoKIA0KIA0KTmF0YWxlICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA2ICAg ICAgICAgICAgW1BhZ2UgDQoxMV0gDA0KCgoKSW50ZXJuZXQgRHJhZnQgIFNJUC1CYXNlZCBWb0lQ IFBlZXJpbmcgUmVxdWlyZW1lbnRzICBGZWIgMjAwNiANCiAgIFRoZSBldmVudHVhbCBsaXN0IHdp bGwgbGlrZWx5IGJlIGxvbmcgYXMgd2UgYW50aWNpcGF0ZSBzdWJzdGFudGlhbCBXRyANCiAgIGFu ZCAoaG9wZWZ1bGx5KSBpbmR1c3RyeSBpbnB1dCBvbiB0aGlzIGRvY3VtZW50IGJlZm9yZSBpdCBy ZWFjaGVzIEJDUCANCiAgIHF1YWxpdHkuICBUaGUgcmVsZXZhbnQgZHJhZnRzIGJ5IERhdmUgTWV5 ZXIgYW5kIE1lZGhhdmkgQmhhdGlhIGhhdmUgDQogICBiZWVuIHZlcnkgaGVscGZ1bCBldmVuIGF0 IHRoaXMgZWFybHkgc3RhZ2UuIA0KIA0KIA0KNi4gDSAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg DQogDQogICBUaGlzIGRvY3VtZW50IHdpbGwgbGlrZWx5IG5vdCBpbnRyb2R1Y2UgYW55IG5ldyBz ZWN1cml0eSANCiAgIGNvbnNpZGVyYXRpb25zLCBidXQgaW5kaXZpZHVhbCByZXF1aXJlbWVudHMg d2lsbCB0b3VjaCB1cG9uIGtub3duIA0KICAgdnVsbmVyYWJpbGl0aWVzIGFuZCByZWNvbW1lbmQg c29sdXRpb25zIGZyb20gZXhpc3RpbmcgcHJhY3RpY2UuIA0KIA0KIA0KNy4gDSAgSUFOQSBDb25z aWRlcmF0aW9ucyANCiANCiAgIFRoaXMgZG9jdW1lbnQgY3JlYXRlcyBubyBuZXcgcmVxdWlyZW1l bnRzIG9uIElBTkEgbmFtZXNwYWNlcyBbUkZDMjQzNF0uIA0KIA0KOC4gDSAgUmVmZXJlbmNlcyAN CiANCjguMSANICBOb3JtYXRpdmUgUmVmZXJlbmNlcyANCiANCiAgIFtSRkMyMTE5XSAgQnJhZG5l ciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIA0KICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3IA0K IA0KOC4yIA0gIEluZm9ybWF0aW9uYWwgUmVmZXJlbmNlcyANCiANCiAgIFtSRkMyNDM0XSAgTmFy dGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4gDQog ICAgICAgICAgICAgIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwgQkNQIDI2 LCBSRkMgMjQzNCwgDQogICAgICAgICAgICAgIE9jdG9iZXIgMTk5OC4gDQogDQogICBbMV0gICAg ICAgIEJoYXRpYSwgTS4sICJSZXF1aXJlbWVudHMgZm9yIFJvdXRlIFBvbGljeSBhbmQgQXJjaGl0 ZWN0dXJlIA0KICAgICAgICAgICAgICBpbiBTSVAgYmFzZWQgUGVlcmluZyIsIGRyYWZ0LWJoYXRp YS1zaXAtcGVlcmluZy0wMC50eHQgDQogICAgICAgICAgICAgICh3b3JrIGluIHByb2dyZXNzKSwg RmVicnVhcnkgMjAwNi4gDQogDQogICBbMl0gICAgICAgIE1leWVyLCBELiwgIiBTUEVFUk1JTlQg UmVxdWlyZW1lbnRzIGFuZCBUZXJtaW5vbG9neSIsIA0KICAgICAgICAgICAgICBkcmFmdC1pZXRm LXNwZWVybWludC1yZXFzLWFuZC10ZXJtaW5vbG9neS0wMS50eHQgKHdvcmsgaW4gIA0KICAgICAg ICAgICAgICBwcm9ncmVzcyksIEZlYnJ1YXJ5IDIwMDYuIA0KIA0KIA0KOS4gDSAgQXV0aG9yJ3Mg QWRkcmVzc2VzIA0KIA0KICAgQm9iIE5hdGFsZSANCiAgIE5leFRvbmUgQ29tbXVuaWNhdGlvbnMg DQogICAxMDEgT3JjaGFyZCBSaWRnZSBEciANCiANCiANCk5hdGFsZSAgICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAyOCwgMjAwNiAgICAgICAgICAgIFtQYWdlIA0KMTJdIAwNCgoKCkludGVybmV0 IERyYWZ0ICBTSVAtQmFzZWQgVm9JUCBQZWVyaW5nIFJlcXVpcmVtZW50cyAgRmViIDIwMDYgDQog ICBHYWl0aGVyc2J1cmcgTUQgMjA4NzggVVNBIA0KICAgRW1haWw6IGJuYXRhbGVAbmV4dG9uZS5j b20gDQogDQoxMC4gDSAgRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50IA0KIA0KICAgQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuIA0KIA0KICAgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgDQogICBj b250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUg YXV0aG9ycyANCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLiANCiANCiAgIFRoaXMgZG9jdW1l bnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBh biANCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElP TiBIRS9TSEUgUkVQUkVTRU5UUyANCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhF IElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCANCiAgIEVOR0lORUVSSU5HIFRBU0sg Rk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgDQogICBJ TkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0Yg VEhFIA0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMg T1IgQU5ZIElNUExJRUQgDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gDQogDQogDQoxMS4gDSAgSW50ZWxsZWN0dWFs IFByb3BlcnR5IA0KIA0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRo ZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmln aHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8gDQogICBwZXJ0YWlu IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVk IGluIA0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNl IHVuZGVyIHN1Y2ggcmlnaHRzIA0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsg bm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIA0KICAgbWFkZSBhbnkgaW5kZXBlbmRl bnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uIA0KICAg b24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRz IGNhbiBiZSANCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LiANCiANCiAgIENvcGllcyBv ZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55IA0K ICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJl c3VsdCBvZiBhbiANCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ug b3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZiANCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRz IGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIA0KICAgc3BlY2lmaWNhdGlvbiBjYW4g YmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0IA0KICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuIA0KIA0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50 ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueSANCiAgIGNvcHlyaWdo dHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkg DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJl ZCB0byBpbXBsZW1lbnQgDQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGlu Zm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0IA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuIA0KIA0KIA0K IA0KTmF0YWxlICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA2ICAgICAgICAgICAg W1BhZ2UgDQoxM10gDA0KCgoKSW50ZXJuZXQgRHJhZnQgIFNJUC1CYXNlZCBWb0lQIFBlZXJpbmcg UmVxdWlyZW1lbnRzICBGZWIgMjAwNiANCiANCjEyLiANICBBY2tub3dsZWRnbWVudCANCiANCiAg IEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRl ZCBieSB0aGUgDQogICBJbnRlcm5ldCBTb2NpZXR5LiANCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCiANCiANCk5hdGFsZSAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAy OCwgMjAwNiAgICAgICAgICAgIFtQYWdlIA0KMTRdIAw= ------_=_NextPart_001_01C63E28.07677364 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_01C63E28.07677364-- From speermint-bounces@ietf.org Thu Mar 02 17:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvt2-0002KR-DQ; Thu, 02 Mar 2006 17:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvt1-0002KM-9H for speermint@ietf.org; Thu, 02 Mar 2006 17:03:03 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvt0-0007VF-U1 for speermint@ietf.org; Thu, 02 Mar 2006 17:03:03 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 17:02:56 -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] FW: I-D draft-bhatia-sip-peering-00.txt Date: Thu, 2 Mar 2006 17:02:55 -0500 Message-ID: <8812D8156467224C9E9739E513037EF12A11AB@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasA== From: "Medhavi Bhatia" To: "Stastny Richard" , "Livingood, Jason" , X-OriginalArrivalTime: 02 Mar 2006 22:02:56.0666 (UTC) FILETIME=[0FE047A0:01C63E45] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 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 Hi Richard, Sorry about the headache... Hopefully my answers below will help :)=20 Thanks for the quick read anyway. Cheers, Medhavi. >=20 > >The purpose of this document is to help the IETF community understand >=20 > > the route architectures being used today in SIP based peering >=20 > > environments and to outline a set of requirements based on the same >=20 > > for discussion within the community >=20 >=20 >=20 > Is this IMS in stealth mode? The intent of the draft is to describe what is deployed and the requirements driving that. We can choose to ignore or accept some of them based on WG discussion.=20 (IMHO - I don't think IMS is deployed anywhere :) >=20 > The abstract should clearly state: >=20 >=20 >=20 > The purpose of this draft is to help the IETF community understand IMS .. >=20 >=20 >=20 > In particular I have problems with the following para: >=20 >=20 >=20 > "The call is originated at calling party "O", (called the > "Origination" in this document) and terminates at called party "T" > (called the "Termination" in this document). T may be a subscriber, > contact center, E911 operator etc. The first hop and the last hop of > the call in Figure 1 pass through SPs providing L5 (in our case SIP) > access to the origination and termination and are called Access-O and > Access-T respectively. In most cases these SPs will also provide the > physical access to the origination and termination devices. The > Access SP function is not optional. While a separate Access SP may > not exist, the function may be absorbed by the corresponding Core SP." >=20 > A Core SP ALWAYS needs an Access SP if he is not providing the access > by itself? In L5? >=20 It says three things: (a) Access SP is mandatory (b) Access SP "may" provide physical access (c) Access SP can be absorbed within the Core SP. Maybe the language can be improved, but I think we capture the case you are talking about - an ASP (Vonage) like scenario! > And then we also have Interconnect SP =3D Transit >=20 > What happened to the SIP Trapeziod? >=20 SIP Trapezoid is captured, since the Interconnect SP is optional (first para on pg 4).=20 However, I think there could be a special section devoted to that. Note that in no way the draft is supposed to be prescriptive or designed to ignore the trapezoid. Sorry if it sounds=20 confusing - we can fix that problem... Also, Note that Inteconnect SPs today don't map to "Transit" as defined in requirements draft.=20 > and may I remember on the req draft >=20 > "3.6.2. Layer 5 Peering >=20 > Layer 5 peering refers to interconnection of two service providers > for the purposes of SIP signaling. Note that in the layer 5 peering > case, there is no intervening network. That is, for purposes of this > discussion, there is no such thing as a "Layer 5 Transit Network"." >=20 > The next problem I have with section >=20 I think maybe the draft needs to clarify that Interconnect SP is not the same as Transit. We can try to do this if lot of people feel the same and it really affects the routing architecture selection (IMHO - it should not have any effect) in the end. >=20 >=20 > "5.2. Addressing >=20 > The type of A-O-R for the termination may also affect what kind of > address location service is used. Address location is done typically > based on the following four characteristics of the termination's AOR. > In each case, we list the most common address location method used. >=20 >=20 > 1. Full E.164: ENUM or SP's local policy may be used. > 2. E.164 prefixes: SPs local policy is generally used. > 3. Full A-O-R: This is rarely used for routing in a peering > environment. > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." >=20 >=20 >=20 > Within SPEERMINT only Call Routing Data (CRD) are used >=20 > E.164 numbers are not CRD, they are also not A-o-R, >=20 > E.164 numbers are names >=20 > so E.164 number is out of scope in SPEERMENT >=20 I am not sure what I need to fix, but we can address it after WG discussion. >=20 > And IMHO completely off is the idea to introduce > carrier selection within VoIP >=20 > " For example Equal Access is > a LEC (Local Exchange Carrier) requirement and an SP operating as an > LEC may be required to allow the subscriber his/her choice of IXC > (IntereXchange Carrier) for certain set of calls. In essence, these > requirements may affect route policy for peering where the downstream > peer is chosen based on origination's policy. In this case, the > Core-O and Core-T may be one and the same SP who peer through an > Interconnect SP of the origination's choice." >=20 Equal Access gives a headache to anyone dealing with VoIP :). I think it is good to know what some VoIP SPs are dealing with especially when we are starting discussions in the WG. As the draft says in the last para - it is possible that this may affect only a minor set of deployments in the end. Time will tell. Also, Equal Access is simply an example (I can't promise if there are not a host of other scenarios out there). Thanks, Medhavi. > I have an headache >=20 > Richard >=20 > ________________________________ >=20 > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Gesendet: Do 02.03.2006 19:33 > An: speermint@ietf.org > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt >=20 >=20 > FYI for the WG on this draft. This is on the tentative agenda at the Dallas meeting (should > be finalized shortly). >=20 > Jason >=20 > ________________________________ >=20 > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Sunday, February 26, 2006 12:44 AM > To: internet-drafts@ietf.org > Cc: dmm@1-4-5.net; Livingood, Jason > Subject: I-D draft-bhatia-sip-peering-00.txt >=20 >=20 >=20 > Abstract >=20 >=20 >=20 > The purpose of this document is to help the IETF community understand >=20 > the route architectures being used today in SIP based peering >=20 > environments and to outline a set of requirements based on the same >=20 > for discussion within the community. >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 02 18:16:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx1w-0001rZ-Mu; Thu, 02 Mar 2006 18:16:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx1w-0001r1-2p for speermint@ietf.org; Thu, 02 Mar 2006 18:16:20 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEx1t-0002xp-3H for speermint@ietf.org; Thu, 02 Mar 2006 18:16:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 00:20:15 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48AA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Access SP was: ( I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAEHSa/ From: "Stastny Richard" To: "Medhavi Bhatia" , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: Subject: [Speermint] Access SP was: ( I-D draft-bhatia-sip-peering-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 Hi Medhavi, =20 I think we should discuss the three topics separate I will respond to the others tomorrow (not because of the headache ;-), but it is after midnight here already. =20 First I consider your draft very useful, particularly the Figure 1, and also your definitions, to clarify the scope and also some issues within SPEERMINT =20 Regarding Access SP, my prime questiion is about your statement: =20 >It says three things: (a) Access SP is mandatory (b) Access SP "may" = provide >physical access (c) Access SP can be absorbed within the Core SP. Maybe = the >language can be improved, but I think we capture the case you = aretalking >about - an ASP (Vonage) like scenario! Why is Access SP mandatory and how does it capture the Vonage scenario We are talking L5 and SIP proxies, or do I misunderstand here something In IMS there is of course an outbound proxy in the visited (access) = network, with Vonage and others there is not. Could you please clarify =20 cheers =20 Richard =20 =20 ________________________________ Von: Medhavi Bhatia [mailto:mbhatia@nextone.com] Gesendet: Do 02.03.2006 23:02 An: Stastny Richard; Livingood, Jason; speermint@ietf.org Betreff: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt Hi Richard, Sorry about the headache... Hopefully my answers below will help :) Thanks for the quick read anyway. Cheers, Medhavi. > > >The purpose of this document is to help the IETF community understand > > > the route architectures being used today in SIP based peering > > > environments and to outline a set of requirements based on the same > > > for discussion within the community > > > > Is this IMS in stealth mode? The intent of the draft is to describe what is deployed and the requirements driving that. We can choose to ignore or accept some of them based on WG discussion. (IMHO - I don't think IMS is deployed anywhere :) > > The abstract should clearly state: > > > > The purpose of this draft is to help the IETF community understand IMS .. > > > > In particular I have problems with the following para: > > > > "The call is originated at calling party "O", (called the > "Origination" in this document) and terminates at called party "T" > (called the "Termination" in this document). T may be a subscriber, > contact center, E911 operator etc. The first hop and the last hop of > the call in Figure 1 pass through SPs providing L5 (in our case SIP) > access to the origination and termination and are called Access-O and > Access-T respectively. In most cases these SPs will also provide the > physical access to the origination and termination devices. The > Access SP function is not optional. While a separate Access SP may > not exist, the function may be absorbed by the corresponding Core SP." > > A Core SP ALWAYS needs an Access SP if he is not providing the access > by itself? In L5? > It says three things: (a) Access SP is mandatory (b) Access SP "may" provide physical access (c) Access SP can be absorbed within the Core SP. Maybe the language can be improved, but I think we capture the case you are talking about - an ASP (Vonage) like scenario! > And then we also have Interconnect SP =3D Transit > > What happened to the SIP Trapeziod? > SIP Trapezoid is captured, since the Interconnect SP is optional (first para on pg 4). However, I think there could be a special section devoted to that. Note that in no way the draft is supposed to be prescriptive or designed to ignore the trapezoid. Sorry if it sounds confusing - we can fix that problem... Also, Note that Inteconnect SPs today don't map to "Transit" as defined in requirements draft. > and may I remember on the req draft > > "3.6.2. Layer 5 Peering > > Layer 5 peering refers to interconnection of two service providers > for the purposes of SIP signaling. Note that in the layer 5 peering > case, there is no intervening network. That is, for purposes of this > discussion, there is no such thing as a "Layer 5 Transit Network"." > > The next problem I have with section > I think maybe the draft needs to clarify that Interconnect SP is not the same as Transit. We can try to do this if lot of people feel the same and it really affects the routing architecture selection (IMHO - it should not have any effect) in the end. > > > "5.2. Addressing > > The type of A-O-R for the termination may also affect what kind of > address location service is used. Address location is done typically > based on the following four characteristics of the termination's AOR. > In each case, we list the most common address location method used. > > > 1. Full E.164: ENUM or SP's local policy may be used. > 2. E.164 prefixes: SPs local policy is generally used. > 3. Full A-O-R: This is rarely used for routing in a peering > environment. > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > E.164 numbers are not CRD, they are also not A-o-R, > > E.164 numbers are names > > so E.164 number is out of scope in SPEERMENT > I am not sure what I need to fix, but we can address it after WG discussion. > > And IMHO completely off is the idea to introduce > carrier selection within VoIP > > " For example Equal Access is > a LEC (Local Exchange Carrier) requirement and an SP operating as an > LEC may be required to allow the subscriber his/her choice of IXC > (IntereXchange Carrier) for certain set of calls. In essence, these > requirements may affect route policy for peering where the downstream > peer is chosen based on origination's policy. In this case, the > Core-O and Core-T may be one and the same SP who peer through an > Interconnect SP of the origination's choice." > Equal Access gives a headache to anyone dealing with VoIP :). I think it is good to know what some VoIP SPs are dealing with especially when we are starting discussions in the WG. As the draft says in the last para - it is possible that this may affect only a minor set of deployments in the end. Time will tell. Also, Equal Access is simply an example (I can't promise if there are not a host of other scenarios out there). Thanks, Medhavi. > I have an headache > > Richard > > ________________________________ > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Gesendet: Do 02.03.2006 19:33 > An: speermint@ietf.org > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > FYI for the WG on this draft. This is on the tentative agenda at the Dallas meeting (should > be finalized shortly). > > Jason > > ________________________________ > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Sunday, February 26, 2006 12:44 AM > To: internet-drafts@ietf.org > Cc: dmm@1-4-5.net; Livingood, Jason > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > Abstract > > > > The purpose of this document is to help the IETF community understand > > the route architectures being used today in SIP based peering > > environments and to outline a set of requirements based on the same > > for discussion within the community. > > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 00:36:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF2xf-0003cl-Kf; Fri, 03 Mar 2006 00:36:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF2xf-0003b5-2B for speermint@ietf.org; Fri, 03 Mar 2006 00:36:19 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF2xd-00048M-J5 for speermint@ietf.org; Fri, 03 Mar 2006 00:36:19 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 00:36:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 00:36:16 -0500 Message-ID: <8812D8156467224C9E9739E513037EF12A130D@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Access SP was: ( I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAEHSa/AA03KlA= From: "Medhavi Bhatia" To: "Stastny Richard" , "Livingood, Jason" , X-OriginalArrivalTime: 03 Mar 2006 05:36:17.0022 (UTC) FILETIME=[648D39E0:01C63E84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: Subject: [Speermint] RE: Access SP was: ( I-D draft-bhatia-sip-peering-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 Richard, I believe this is a bug. I have gone through the section 3 and seems like para 1 (which states access SPs are optional) offers the correct position. I will need to fix para 2 (acknowledging I probably confused myself in the earlier reply). Only the Core SPs are mandatory and in the ASP model, they need to be necessarily different to be in scope of the WG I believe. Cheers, Medhavi. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 02, 2006 6:20 PM > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > Subject: Access SP was: ( I-D draft-bhatia-sip-peering-00.txt) >=20 > Hi Medhavi, >=20 > I think we should discuss the three topics separate > I will respond to the others tomorrow > (not because of the headache ;-), but it is after midnight here already. >=20 > First I consider your draft very useful, particularly the Figure 1, > and also your definitions, > to clarify the scope and also some issues within SPEERMINT >=20 > Regarding Access SP, my prime questiion is about your statement: >=20 > >It says three things: (a) Access SP is mandatory (b) Access SP "may" provide > >physical access (c) Access SP can be absorbed within the Core SP. Maybe the > >language can be improved, but I think we capture the case you aretalking > >about - an ASP (Vonage) like scenario! >=20 > Why is Access SP mandatory and how does it capture the Vonage scenario > We are talking L5 and SIP proxies, or do I misunderstand here something >=20 > In IMS there is of course an outbound proxy in the visited (access) network, > with Vonage and others there is not. >=20 > Could you please clarify >=20 > cheers >=20 > Richard >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > Von: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Gesendet: Do 02.03.2006 23:02 > An: Stastny Richard; Livingood, Jason; speermint@ietf.org > Betreff: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt >=20 >=20 >=20 > Hi Richard, >=20 > Sorry about the headache... > Hopefully my answers below will help :) > Thanks for the quick read anyway. >=20 > Cheers, > Medhavi. >=20 > > > > >The purpose of this document is to help the IETF community understand > > > > > the route architectures being used today in SIP based peering > > > > > environments and to outline a set of requirements based on the > same > > > > > for discussion within the community > > > > > > > > Is this IMS in stealth mode? >=20 > The intent of the draft is to describe what is deployed and the > requirements driving that. We can choose to ignore or accept some of > them based on WG discussion. >=20 > (IMHO - I don't think IMS is deployed anywhere :) >=20 > > > > The abstract should clearly state: > > > > > > > > The purpose of this draft is to help the IETF community understand IMS > .. > > > > > > > > In particular I have problems with the following para: > > > > > > > > "The call is originated at calling party "O", (called the > > "Origination" in this document) and terminates at called party "T" > > (called the "Termination" in this document). T may be a subscriber, > > contact center, E911 operator etc. The first hop and the last hop > of > > the call in Figure 1 pass through SPs providing L5 (in our case SIP) > > access to the origination and termination and are called Access-O > and > > Access-T respectively. In most cases these SPs will also provide > the > > physical access to the origination and termination devices. The > > Access SP function is not optional. While a separate Access SP may > > not exist, the function may be absorbed by the corresponding Core > SP." > > > > A Core SP ALWAYS needs an Access SP if he is not providing the access > > by itself? In L5? > > >=20 > It says three things: (a) Access SP is mandatory (b) Access SP "may" > provide > physical access (c) Access SP can be absorbed within the Core SP. Maybe > the > language can be improved, but I think we capture the case you are > talking > about - an ASP (Vonage) like scenario! >=20 > > And then we also have Interconnect SP =3D Transit > > > > What happened to the SIP Trapeziod? > > >=20 > SIP Trapezoid is captured, since the Interconnect SP is optional (first > para on pg 4). > However, I think there could be a special section devoted to that. Note > that in no way > the draft is supposed to be prescriptive or designed to ignore the > trapezoid. Sorry if it sounds > confusing - we can fix that problem... >=20 > Also, Note that Inteconnect SPs today don't map to "Transit" as defined > in requirements > draft. >=20 > > and may I remember on the req draft > > > > "3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 > peering > > case, there is no intervening network. That is, for purposes of > this > > discussion, there is no such thing as a "Layer 5 Transit Network"." > > > > The next problem I have with section > > >=20 > I think maybe the draft needs to clarify that Interconnect SP is not the > same as Transit. > We can try to do this if lot of people feel the same and it really > affects the routing > architecture selection (IMHO - it should not have any effect) in the > end. >=20 > > > > > > "5.2. Addressing > > > > The type of A-O-R for the termination may also affect what kind of > > address location service is used. Address location is done > typically > > based on the following four characteristics of the termination's > AOR. > > In each case, we list the most common address location method used. > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > 2. E.164 prefixes: SPs local policy is generally used. > > 3. Full A-O-R: This is rarely used for routing in a peering > > environment. > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > E.164 numbers are names > > > > so E.164 number is out of scope in SPEERMENT > > >=20 > I am not sure what I need to fix, but we can address it after WG > discussion. >=20 > > > > And IMHO completely off is the idea to introduce > > carrier selection within VoIP > > > > " For example Equal Access is > > a LEC (Local Exchange Carrier) requirement and an SP operating as > an > > LEC may be required to allow the subscriber his/her choice of IXC > > (IntereXchange Carrier) for certain set of calls. In essence, > these > > requirements may affect route policy for peering where the > downstream > > peer is chosen based on origination's policy. In this case, the > > Core-O and Core-T may be one and the same SP who peer through an > > Interconnect SP of the origination's choice." > > >=20 > Equal Access gives a headache to anyone dealing with VoIP :). I think it > is good to know what some VoIP SPs are dealing with especially when we > are starting discussions in the WG. As the draft says in the last para > - it is > possible that this may affect only a minor set of deployments in the > end. Time > will tell. Also, Equal Access is simply an example (I can't promise if > there > are not a host of other scenarios out there). >=20 > Thanks, > Medhavi. >=20 >=20 >=20 > > I have an headache > > > > Richard > > > > ________________________________ > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Gesendet: Do 02.03.2006 19:33 > > An: speermint@ietf.org > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > FYI for the WG on this draft. This is on the tentative agenda at the > Dallas meeting (should > > be finalized shortly). > > > > Jason > > > > ________________________________ > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Sunday, February 26, 2006 12:44 AM > > To: internet-drafts@ietf.org > > Cc: dmm@1-4-5.net; Livingood, Jason > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > Abstract > > > > > > > > The purpose of this document is to help the IETF community > understand > > > > the route architectures being used today in SIP based peering > > > > environments and to outline a set of requirements based on the same > > > > for discussion within the community. > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > 3/1/2006 > > >=20 >=20 >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 03:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF65q-0005q9-W4; Fri, 03 Mar 2006 03:56:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF65p-0005jq-K8 for speermint@ietf.org; Fri, 03 Mar 2006 03:56:57 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FF65m-0003N5-Oc for speermint@ietf.org; Fri, 03 Mar 2006 03:56:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 10:00:45 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DF0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Phone numbers (was I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAYS7Ug From: "Stastny Richard" To: "Medhavi Bhatia" , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: Subject: [Speermint] Phone numbers (was I-D draft-bhatia-sip-peering-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 > > Within SPEERMINT only Call Routing Data (CRD) are used > > E.164 numbers are not CRD, they are also not A-o-R, > > E.164 numbers are names > > so E.164 number is out of scope in SPEERMENT >=20 > I am not sure what I need to fix, but we can address it after WG > discussion. Routing between SPEERMINT (VoIP) SP is done only with SIP URIs (this is also specified in IMS 3GPP TS 123.228, any public user identity given by a phone number MUST be translated first to an SIP URI) The basic question for SPEERMINT therefore is: is there any difference in routing and/or policy if the original requested end-point was given by a phone number. Note: there are E.164 numbers and non-E.164 numbers If yes, we may run into the same header field problem as it is currently discussed in ECRIT. We may need an phone (E.164) number marker. An additional remark: in Infrastructure ENUM, the Core-T SP (I like your definitions, they are very helpful) is always the SP hosting the E.164 number, in User ENUM this need not to be the case Is there then a difference in policy and/or routing if the SIP URI is derived from User ENUM or=20 Infrastructure ENUM? Do we need two different markers? Any thoughts? Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, March 02, 2006 11:03 PM > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt >=20 > Hi Richard, >=20 > Sorry about the headache... > Hopefully my answers below will help :) > Thanks for the quick read anyway. >=20 > Cheers, > Medhavi. >=20 > > > > >The purpose of this document is to help the IETF community understand > > > > > the route architectures being used today in SIP based peering > > > > > environments and to outline a set of requirements based on the > same > > > > > for discussion within the community > > > > > > > > Is this IMS in stealth mode? >=20 > The intent of the draft is to describe what is deployed and the > requirements driving that. We can choose to ignore or accept some of > them based on WG discussion. >=20 > (IMHO - I don't think IMS is deployed anywhere :) >=20 > > > > The abstract should clearly state: > > > > > > > > The purpose of this draft is to help the IETF community understand IMS > .. > > > > > > > > In particular I have problems with the following para: > > > > > > > > "The call is originated at calling party "O", (called the > > "Origination" in this document) and terminates at called party "T" > > (called the "Termination" in this document). T may be a subscriber, > > contact center, E911 operator etc. The first hop and the last hop > of > > the call in Figure 1 pass through SPs providing L5 (in our case SIP) > > access to the origination and termination and are called Access-O > and > > Access-T respectively. In most cases these SPs will also provide > the > > physical access to the origination and termination devices. The > > Access SP function is not optional. While a separate Access SP may > > not exist, the function may be absorbed by the corresponding Core > SP." > > > > A Core SP ALWAYS needs an Access SP if he is not providing the access > > by itself? In L5? > > >=20 > It says three things: (a) Access SP is mandatory (b) Access SP "may" > provide > physical access (c) Access SP can be absorbed within the Core SP. Maybe > the > language can be improved, but I think we capture the case you are > talking > about - an ASP (Vonage) like scenario! >=20 > > And then we also have Interconnect SP =3D Transit > > > > What happened to the SIP Trapeziod? > > >=20 > SIP Trapezoid is captured, since the Interconnect SP is optional (first > para on pg 4). > However, I think there could be a special section devoted to that. Note > that in no way > the draft is supposed to be prescriptive or designed to ignore the > trapezoid. Sorry if it sounds > confusing - we can fix that problem... >=20 > Also, Note that Inteconnect SPs today don't map to "Transit" as defined > in requirements > draft. >=20 > > and may I remember on the req draft > > > > "3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 > peering > > case, there is no intervening network. That is, for purposes of > this > > discussion, there is no such thing as a "Layer 5 Transit Network"." > > > > The next problem I have with section > > >=20 > I think maybe the draft needs to clarify that Interconnect SP is not the > same as Transit. > We can try to do this if lot of people feel the same and it really > affects the routing > architecture selection (IMHO - it should not have any effect) in the > end. >=20 > > > > > > "5.2. Addressing > > > > The type of A-O-R for the termination may also affect what kind of > > address location service is used. Address location is done > typically > > based on the following four characteristics of the termination's > AOR. > > In each case, we list the most common address location method used. > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > 2. E.164 prefixes: SPs local policy is generally used. > > 3. Full A-O-R: This is rarely used for routing in a peering > > environment. > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > E.164 numbers are names > > > > so E.164 number is out of scope in SPEERMENT > > >=20 > I am not sure what I need to fix, but we can address it after WG > discussion. >=20 > > > > And IMHO completely off is the idea to introduce > > carrier selection within VoIP > > > > " For example Equal Access is > > a LEC (Local Exchange Carrier) requirement and an SP operating as > an > > LEC may be required to allow the subscriber his/her choice of IXC > > (IntereXchange Carrier) for certain set of calls. In essence, > these > > requirements may affect route policy for peering where the > downstream > > peer is chosen based on origination's policy. In this case, the > > Core-O and Core-T may be one and the same SP who peer through an > > Interconnect SP of the origination's choice." > > >=20 > Equal Access gives a headache to anyone dealing with VoIP :). I think it > is good to know what some VoIP SPs are dealing with especially when we > are starting discussions in the WG. As the draft says in the last para > - it is > possible that this may affect only a minor set of deployments in the > end. Time > will tell. Also, Equal Access is simply an example (I can't promise if > there > are not a host of other scenarios out there). >=20 > Thanks, > Medhavi. >=20 >=20 >=20 > > I have an headache > > > > Richard > > > > ________________________________ > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Gesendet: Do 02.03.2006 19:33 > > An: speermint@ietf.org > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > FYI for the WG on this draft. This is on the tentative agenda at the > Dallas meeting (should > > be finalized shortly). > > > > Jason > > > > ________________________________ > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Sunday, February 26, 2006 12:44 AM > > To: internet-drafts@ietf.org > > Cc: dmm@1-4-5.net; Livingood, Jason > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > Abstract > > > > > > > > The purpose of this document is to help the IETF community > understand > > > > the route architectures being used today in SIP based peering > > > > environments and to outline a set of requirements based on the same > > > > for discussion within the community. > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > 3/1/2006 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 04:37:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6is-0002yw-52; Fri, 03 Mar 2006 04:37:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6iq-0002yr-A8 for speermint@ietf.org; Fri, 03 Mar 2006 04:37:16 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FF6ip-0004sS-30 for speermint@ietf.org; Fri, 03 Mar 2006 04:37:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 10:41:14 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DF1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intercon SP (was I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAYuVRQ From: "Stastny Richard" To: "Medhavi Bhatia" , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: Subject: [Speermint] Intercon SP (was I-D draft-bhatia-sip-peering-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 >=20 > I think maybe the draft needs to clarify that Interconnect SP is not the > same as Transit. > We can try to do this if lot of people feel the same and it really > affects the routing > architecture selection (IMHO - it should not have any effect) in the > end. I agree that we need to discuss this and clarify (which will not be easy ;-) I know that currently Interconnect SP (on L5) are existing and providing a kind of clearing house function regarding call routing (some also provide ENUM) and also providing policy services. Some also provide L3 transit, some not. To complicate issues further, some work as proxies (as in your Figure 1), some as redirect servers. GSMA is planning to introduce such Intercon proxies within their GRX/IPX network (called hub/IPX proxies) (Note GRX/IPX is also always a mediastream transit network) Additional remark: what is missing in your scenario is the connection of enterprises, that is Os and Ts having networks and proxies on their own. Back to ENUM: There is an additional problem lurking in these complicated scenarios (I am somewhat referring back here to my previous e-mail on phone numbers) The assumption in User ENUM is that you get back the AoR out of ENUM =3D the Core-T the user defined to provide VoIP services=20 for him (not necessarily the provider=20 hosting the number) The assumption in Infrastructure ENUM (as currently defined in ENUM WG, not private ENUMs) that you get back either also the AoR of the SP provider hosting the number, which is translated with SRV and DNS to the ingress border element of the Core-T, or directly the ingress element This is ok if Core-O is querying Infrastructure ENUM and no Intercon is involved So what is the mechanism to involve an Intercon SP? One scenario I could imagine is the following A Core-O is querying Infrastructure ENUM, but finds out via the policy records that he has no direct peering with the Core-T. He may now forward the call to an Intercon SP which is providing connectivity to the Core-T. He may have some choices. How is the Intercon SP announcing which Core-Ts he is able to terminate? This could of course be done by the Core-T in the policy records giving the Intercon SP in his federation list. The question I have now is does the Core-O=20 provider signal to the Intercon already the information derived from Infrastructure ENUM (=3D the Core-T URI) or does he give again the E.164 number and the Intercon SP is querying Infrastructure ENUM again. This may not sound complicated if we assume only one global Infrastructure ENUM, but if we take into account that we may also interwork with private ENUMs? Example: GSMA decides to be reachable also from the=20 Internet, but in public Infrastructure ENUM only the ingress border elements from IPX are entered. This requires a second ENUM query within IPX, which in turn requires the original E.164 number to be kept. Since I am currently also dealing with the header field nightmare in SIP and IMS, we may need to make the e.g. P-Called-Party-ID Header from RFC 3455 mandatory. Cheers Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, March 02, 2006 11:03 PM > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt >=20 > Hi Richard, >=20 > Sorry about the headache... > Hopefully my answers below will help :) > Thanks for the quick read anyway. >=20 > Cheers, > Medhavi. >=20 > > > > >The purpose of this document is to help the IETF community understand > > > > > the route architectures being used today in SIP based peering > > > > > environments and to outline a set of requirements based on the > same > > > > > for discussion within the community > > > > > > > > Is this IMS in stealth mode? >=20 > The intent of the draft is to describe what is deployed and the > requirements driving that. We can choose to ignore or accept some of > them based on WG discussion. >=20 > (IMHO - I don't think IMS is deployed anywhere :) >=20 > > > > The abstract should clearly state: > > > > > > > > The purpose of this draft is to help the IETF community understand IMS > .. > > > > > > > > In particular I have problems with the following para: > > > > > > > > "The call is originated at calling party "O", (called the > > "Origination" in this document) and terminates at called party "T" > > (called the "Termination" in this document). T may be a subscriber, > > contact center, E911 operator etc. The first hop and the last hop > of > > the call in Figure 1 pass through SPs providing L5 (in our case SIP) > > access to the origination and termination and are called Access-O > and > > Access-T respectively. In most cases these SPs will also provide > the > > physical access to the origination and termination devices. The > > Access SP function is not optional. While a separate Access SP may > > not exist, the function may be absorbed by the corresponding Core > SP." > > > > A Core SP ALWAYS needs an Access SP if he is not providing the access > > by itself? In L5? > > >=20 > It says three things: (a) Access SP is mandatory (b) Access SP "may" > provide > physical access (c) Access SP can be absorbed within the Core SP. Maybe > the > language can be improved, but I think we capture the case you are > talking > about - an ASP (Vonage) like scenario! >=20 > > And then we also have Interconnect SP =3D Transit > > > > What happened to the SIP Trapeziod? > > >=20 > SIP Trapezoid is captured, since the Interconnect SP is optional (first > para on pg 4). > However, I think there could be a special section devoted to that. Note > that in no way > the draft is supposed to be prescriptive or designed to ignore the > trapezoid. Sorry if it sounds > confusing - we can fix that problem... >=20 > Also, Note that Inteconnect SPs today don't map to "Transit" as defined > in requirements > draft. >=20 > > and may I remember on the req draft > > > > "3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 > peering > > case, there is no intervening network. That is, for purposes of > this > > discussion, there is no such thing as a "Layer 5 Transit Network"." > > > > The next problem I have with section > > >=20 > I think maybe the draft needs to clarify that Interconnect SP is not the > same as Transit. > We can try to do this if lot of people feel the same and it really > affects the routing > architecture selection (IMHO - it should not have any effect) in the > end. >=20 > > > > > > "5.2. Addressing > > > > The type of A-O-R for the termination may also affect what kind of > > address location service is used. Address location is done > typically > > based on the following four characteristics of the termination's > AOR. > > In each case, we list the most common address location method used. > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > 2. E.164 prefixes: SPs local policy is generally used. > > 3. Full A-O-R: This is rarely used for routing in a peering > > environment. > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > E.164 numbers are names > > > > so E.164 number is out of scope in SPEERMENT > > >=20 > I am not sure what I need to fix, but we can address it after WG > discussion. >=20 > > > > And IMHO completely off is the idea to introduce > > carrier selection within VoIP > > > > " For example Equal Access is > > a LEC (Local Exchange Carrier) requirement and an SP operating as > an > > LEC may be required to allow the subscriber his/her choice of IXC > > (IntereXchange Carrier) for certain set of calls. In essence, > these > > requirements may affect route policy for peering where the > downstream > > peer is chosen based on origination's policy. In this case, the > > Core-O and Core-T may be one and the same SP who peer through an > > Interconnect SP of the origination's choice." > > >=20 > Equal Access gives a headache to anyone dealing with VoIP :). I think it > is good to know what some VoIP SPs are dealing with especially when we > are starting discussions in the WG. As the draft says in the last para > - it is > possible that this may affect only a minor set of deployments in the > end. Time > will tell. Also, Equal Access is simply an example (I can't promise if > there > are not a host of other scenarios out there). >=20 > Thanks, > Medhavi. >=20 >=20 >=20 > > I have an headache > > > > Richard > > > > ________________________________ > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Gesendet: Do 02.03.2006 19:33 > > An: speermint@ietf.org > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > FYI for the WG on this draft. This is on the tentative agenda at the > Dallas meeting (should > > be finalized shortly). > > > > Jason > > > > ________________________________ > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Sunday, February 26, 2006 12:44 AM > > To: internet-drafts@ietf.org > > Cc: dmm@1-4-5.net; Livingood, Jason > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > Abstract > > > > > > > > The purpose of this document is to help the IETF community > understand > > > > the route architectures being used today in SIP based peering > > > > environments and to outline a set of requirements based on the same > > > > for discussion within the community. > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > 3/1/2006 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 05:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7CB-0006eE-PX; Fri, 03 Mar 2006 05:07:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7CA-0006dA-Um for speermint@ietf.org; Fri, 03 Mar 2006 05:07:34 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FF7CA-0005j6-2h for speermint@ietf.org; Fri, 03 Mar 2006 05:07:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 11:11:32 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DF3@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Equal Access (was I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2w From: "Stastny Richard" To: "Medhavi Bhatia" , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: Subject: [Speermint] Equal Access (was I-D draft-bhatia-sip-peering-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 > > " For example Equal Access is > > a LEC (Local Exchange Carrier) requirement and an SP operating as > an > > LEC may be required to allow the subscriber his/her choice of IXC > > (IntereXchange Carrier) for certain set of calls. In essence, > these > > requirements may affect route policy for peering where the > downstream > > peer is chosen based on origination's policy. In this case, the > > Core-O and Core-T may be one and the same SP who peer through an > > Interconnect SP of the origination's choice." > > >=20 > Equal Access gives a headache to anyone dealing with VoIP :). I think it > is good to know what some VoIP SPs are dealing with especially when we > are starting discussions in the WG. As the draft says in the last para > - it is > possible that this may affect only a minor set of deployments in the > end. Time > will tell. Also, Equal Access is simply an example (I can't promise if > there > are not a host of other scenarios out there). The major problem with Equal Access is that this cannot be solved in SPEERMINT, because it is a national regulatory matter. In Europe it is part of the remedies to telcos having significant market power (SMP). It is also a typical PSTN issue. So it depends first on a decision in which market VoIP is placed. If you put VoIP which is a PSTN substitution into the fixed-line voice market, the existing remedies for SMP providers such as carrier selection apply. A typical candidate is VoB provided bundled with BB-access, e.g. a XDSL access with a terminal adapter and a normal phone or an XDSL with an IP-phone. This raises may questions such as: if you are able to unbundle your access and are able to choose another DSL provider, to you still need carrier selection? Is carrier selection only valid for voice and voice related services, especially if the selected carrier still has only access via the PSTN? What if you switch during a call to video? What does carrier selection imply with IP Interconnect? L5 Interconnect or also L3 transit? A very nice example is if Core-O and Core-T is the same, e.g. running on the same server, do you still have to provide carrier selection if the call is now forced via the PSTN? Etc. etc. Cheers Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, March 02, 2006 11:03 PM > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt >=20 > Hi Richard, >=20 > Sorry about the headache... > Hopefully my answers below will help :) > Thanks for the quick read anyway. >=20 > Cheers, > Medhavi. >=20 > > > > >The purpose of this document is to help the IETF community understand > > > > > the route architectures being used today in SIP based peering > > > > > environments and to outline a set of requirements based on the > same > > > > > for discussion within the community > > > > > > > > Is this IMS in stealth mode? >=20 > The intent of the draft is to describe what is deployed and the > requirements driving that. We can choose to ignore or accept some of > them based on WG discussion. >=20 > (IMHO - I don't think IMS is deployed anywhere :) >=20 > > > > The abstract should clearly state: > > > > > > > > The purpose of this draft is to help the IETF community understand IMS > .. > > > > > > > > In particular I have problems with the following para: > > > > > > > > "The call is originated at calling party "O", (called the > > "Origination" in this document) and terminates at called party "T" > > (called the "Termination" in this document). T may be a subscriber, > > contact center, E911 operator etc. The first hop and the last hop > of > > the call in Figure 1 pass through SPs providing L5 (in our case SIP) > > access to the origination and termination and are called Access-O > and > > Access-T respectively. In most cases these SPs will also provide > the > > physical access to the origination and termination devices. The > > Access SP function is not optional. While a separate Access SP may > > not exist, the function may be absorbed by the corresponding Core > SP." > > > > A Core SP ALWAYS needs an Access SP if he is not providing the access > > by itself? In L5? > > >=20 > It says three things: (a) Access SP is mandatory (b) Access SP "may" > provide > physical access (c) Access SP can be absorbed within the Core SP. Maybe > the > language can be improved, but I think we capture the case you are > talking > about - an ASP (Vonage) like scenario! >=20 > > And then we also have Interconnect SP =3D Transit > > > > What happened to the SIP Trapeziod? > > >=20 > SIP Trapezoid is captured, since the Interconnect SP is optional (first > para on pg 4). > However, I think there could be a special section devoted to that. Note > that in no way > the draft is supposed to be prescriptive or designed to ignore the > trapezoid. Sorry if it sounds > confusing - we can fix that problem... >=20 > Also, Note that Inteconnect SPs today don't map to "Transit" as defined > in requirements > draft. >=20 > > and may I remember on the req draft > > > > "3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 > peering > > case, there is no intervening network. That is, for purposes of > this > > discussion, there is no such thing as a "Layer 5 Transit Network"." > > > > The next problem I have with section > > >=20 > I think maybe the draft needs to clarify that Interconnect SP is not the > same as Transit. > We can try to do this if lot of people feel the same and it really > affects the routing > architecture selection (IMHO - it should not have any effect) in the > end. >=20 > > > > > > "5.2. Addressing > > > > The type of A-O-R for the termination may also affect what kind of > > address location service is used. Address location is done > typically > > based on the following four characteristics of the termination's > AOR. > > In each case, we list the most common address location method used. > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > 2. E.164 prefixes: SPs local policy is generally used. > > 3. Full A-O-R: This is rarely used for routing in a peering > > environment. > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > E.164 numbers are names > > > > so E.164 number is out of scope in SPEERMENT > > >=20 > I am not sure what I need to fix, but we can address it after WG > discussion. >=20 > > > > And IMHO completely off is the idea to introduce > > carrier selection within VoIP > > > > " For example Equal Access is > > a LEC (Local Exchange Carrier) requirement and an SP operating as > an > > LEC may be required to allow the subscriber his/her choice of IXC > > (IntereXchange Carrier) for certain set of calls. In essence, > these > > requirements may affect route policy for peering where the > downstream > > peer is chosen based on origination's policy. In this case, the > > Core-O and Core-T may be one and the same SP who peer through an > > Interconnect SP of the origination's choice." > > >=20 > Equal Access gives a headache to anyone dealing with VoIP :). I think it > is good to know what some VoIP SPs are dealing with especially when we > are starting discussions in the WG. As the draft says in the last para > - it is > possible that this may affect only a minor set of deployments in the > end. Time > will tell. Also, Equal Access is simply an example (I can't promise if > there > are not a host of other scenarios out there). >=20 > Thanks, > Medhavi. >=20 >=20 >=20 > > I have an headache > > > > Richard > > > > ________________________________ > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Gesendet: Do 02.03.2006 19:33 > > An: speermint@ietf.org > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > FYI for the WG on this draft. This is on the tentative agenda at the > Dallas meeting (should > > be finalized shortly). > > > > Jason > > > > ________________________________ > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Sunday, February 26, 2006 12:44 AM > > To: internet-drafts@ietf.org > > Cc: dmm@1-4-5.net; Livingood, Jason > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > Abstract > > > > > > > > The purpose of this document is to help the IETF community > understand > > > > the route architectures being used today in SIP based peering > > > > environments and to outline a set of requirements based on the same > > > > for discussion within the community. > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > 3/1/2006 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 08:18:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFABI-00048J-ET; Fri, 03 Mar 2006 08:18:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFABH-00048E-C9 for speermint@ietf.org; Fri, 03 Mar 2006 08:18:51 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFABG-0004qK-Vd for speermint@ietf.org; Fri, 03 Mar 2006 08:18:51 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id A78DC1A3C1; Fri, 3 Mar 2006 14:18:45 +0100 (CET) Date: Fri, 3 Mar 2006 14:18:45 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt Message-ID: <20060303131845.GA30487@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <6EEEACD9D7F52940BEE26F5467C02C7302A3A437@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3A437@PACDCEXCMB01.cable.comcast.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 > > Network Working Group M. Bhatia > Internet-Draft NexTone Communications > Expires: August 30, 2006 February 26, 2006 > This draft is quite helpful as it provides clarificatons concerning the terminology and describes some setups. Some questions, though: > 2. Terminology > Service Provider (SP): We use the term Service Provider in this > document to refer to a SIP Service Provider[3]. The individual > types of SPs are defined below. > > Access SP: An SP which acts as the first hop between the > subscriber and the Core SP. Is this Access SP role restricted to the SIP layer or is it implied that this Access SP also is the layer 3 access provider for "O"? > 4. Routing Architectures > > 1. Direct Peering: > > Federation: A federation is typically a set of SPs which are > terminating calls to each other using some well known > mechanisms for settlement, address location and some other > common administrative policies. In most cases the peering SPs > are connected to a trusted private network and trust all calls > terminating on them over this network. > > Federations typically use ENUM as the registry database > (owned by the federation or a trusted third party) to > provide address location services and applications like > number portability. Other aspects of the routing policy > (as described in Section 5) are implemented using edge > proxies or session border controllers (Section 4.1). This use of "Federation" fits in very well with my definition of draft-lendl-speermint-federations-00. Good. Federations can only use ENUM if routing is based on E.164 numbers. If we ever switch to direct URI dialing, then ENUM cannot be used within a federation. Btw, draft-lendl-domain-policy-ddds-00 provides a solution for selecting the right federation for a call and thus enables SPs to be part of multiple federations. > > 5. Requirements for route policy and architecture for peering > > 2. Addressing: Whether the address of record of the termination is > an E.164 address or a generic AOR (e.g foo@bar.com) IMHO: We should not design a system which does assume that E.164 numbers are available as routing information. /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 Fri Mar 03 08:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAi0-0004tR-MK; Fri, 03 Mar 2006 08:52:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAi0-0004tM-CW for speermint@ietf.org; Fri, 03 Mar 2006 08:52:40 -0500 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFAhz-000615-TT for speermint@ietf.org; Fri, 03 Mar 2006 08:52:40 -0500 Received: from moe.nextone.local ([192.168.15.39]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 08:52:39 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 08:52:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <8812D8156467224C9E9739E513037EF12A13BD@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regulatory requirements [was Re: Equal Access...] Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAAf+fcA= From: "Bob Natale" To: "Stastny Richard" X-OriginalArrivalTime: 03 Mar 2006 13:52:39.0232 (UTC) FILETIME=[BC21D400:01C63EC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: speermint@ietf.org Subject: [Speermint] Regulatory requirements [was Re: Equal Access...] 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 Richard, Concerning this observation from you (below): "The major problem with Equal Access is that this cannot be solved in SPEERMINT, because it is a national regulatory matter." We will have to take at least a summary position, in our Requirements BCP document, wrt regulatory requirements. I guess the possibilities include: - Try to exclude everything that is (typically?) subject to such regulation? - Try to include ? - Deal with it on a case by case basis? - Ignore this aspect for any otherwise necessary requirement and prescribe what we determine is best, leaving affected SPs and users to sort the matter out locally? - Something else...? Cheers, BobN -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Friday, March 03, 2006 5:12 AM To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org Subject: [Speermint] Equal Access (was I-D draft-bhatia-sip-peering-00.txt) > > " For example Equal Access is > > a LEC (Local Exchange Carrier) requirement and an SP operating as > an > > LEC may be required to allow the subscriber his/her choice of IXC > > (IntereXchange Carrier) for certain set of calls. In essence, > these > > requirements may affect route policy for peering where the > downstream > > peer is chosen based on origination's policy. In this case, the > > Core-O and Core-T may be one and the same SP who peer through an > > Interconnect SP of the origination's choice." > > >=20 > Equal Access gives a headache to anyone dealing with VoIP :). I think it > is good to know what some VoIP SPs are dealing with especially when we > are starting discussions in the WG. As the draft says in the last para > - it is > possible that this may affect only a minor set of deployments in the=20 > end. Time will tell. Also, Equal Access is simply an example (I can't=20 > promise if there are not a host of other scenarios out there). The major problem with Equal Access is that this cannot be solved in SPEERMINT, because it is a national regulatory matter. In Europe it is part of the remedies to telcos having significant market power (SMP). It is also a typical PSTN issue. So it depends first on a decision in which market VoIP is placed. If you put VoIP which is a PSTN substitution into the fixed-line voice market, the existing remedies for SMP providers such as carrier selection apply. A typical candidate is VoB provided bundled with BB-access, e.g. a XDSL access with a terminal adapter and a normal phone or an XDSL with an IP-phone. This raises may questions such as: if you are able to unbundle your access and are able to choose another DSL provider, to you still need carrier selection? Is carrier selection only valid for voice and voice related services, especially if the selected carrier still has only access via the PSTN? What if you switch during a call to video? What does carrier selection imply with IP Interconnect? L5 Interconnect or also L3 transit? A very nice example is if Core-O and Core-T is the same, e.g. running on the same server, do you still have to provide carrier selection if the call is now forced via the PSTN? Etc. etc. Cheers Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, March 02, 2006 11:03 PM > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt >=20 > Hi Richard, >=20 > Sorry about the headache... > Hopefully my answers below will help :) Thanks for the quick read=20 > anyway. >=20 > Cheers, > Medhavi. >=20 > > > > >The purpose of this document is to help the IETF community understand > > > > > the route architectures being used today in SIP based peering > > > > > environments and to outline a set of requirements based on the > same > > > > > for discussion within the community > > > > > > > > Is this IMS in stealth mode? >=20 > The intent of the draft is to describe what is deployed and the=20 > requirements driving that. We can choose to ignore or accept some of=20 > them based on WG discussion. >=20 > (IMHO - I don't think IMS is deployed anywhere :) >=20 > > > > The abstract should clearly state: > > > > > > > > The purpose of this draft is to help the IETF community understand IMS > .. > > > > > > > > In particular I have problems with the following para: > > > > > > > > "The call is originated at calling party "O", (called the > > "Origination" in this document) and terminates at called party "T" > > (called the "Termination" in this document). T may be a subscriber, > > contact center, E911 operator etc. The first hop and the last hop > of > > the call in Figure 1 pass through SPs providing L5 (in our case SIP) > > access to the origination and termination and are called Access-O > and > > Access-T respectively. In most cases these SPs will also provide > the > > physical access to the origination and termination devices. The > > Access SP function is not optional. While a separate Access SP may > > not exist, the function may be absorbed by the corresponding Core > SP." > > > > A Core SP ALWAYS needs an Access SP if he is not providing the access > > by itself? In L5? > > >=20 > It says three things: (a) Access SP is mandatory (b) Access SP "may" > provide > physical access (c) Access SP can be absorbed within the Core SP. Maybe > the > language can be improved, but I think we capture the case you are=20 > talking about - an ASP (Vonage) like scenario! >=20 > > And then we also have Interconnect SP =3D Transit > > > > What happened to the SIP Trapeziod? > > >=20 > SIP Trapezoid is captured, since the Interconnect SP is optional (first > para on pg 4). > However, I think there could be a special section devoted to that. Note > that in no way > the draft is supposed to be prescriptive or designed to ignore the=20 > trapezoid. Sorry if it sounds confusing - we can fix that problem... >=20 > Also, Note that Inteconnect SPs today don't map to "Transit" as defined > in requirements > draft. >=20 > > and may I remember on the req draft > > > > "3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 > peering > > case, there is no intervening network. That is, for purposes of > this > > discussion, there is no such thing as a "Layer 5 Transit Network"." > > > > The next problem I have with section > > >=20 > I think maybe the draft needs to clarify that Interconnect SP is not the > same as Transit. > We can try to do this if lot of people feel the same and it really=20 > affects the routing architecture selection (IMHO - it should not have=20 > any effect) in the end. >=20 > > > > > > "5.2. Addressing > > > > The type of A-O-R for the termination may also affect what kind of > > address location service is used. Address location is done > typically > > based on the following four characteristics of the termination's > AOR. > > In each case, we list the most common address location method used. > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > 2. E.164 prefixes: SPs local policy is generally used. > > 3. Full A-O-R: This is rarely used for routing in a peering > > environment. > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > E.164 numbers are names > > > > so E.164 number is out of scope in SPEERMENT > > >=20 > I am not sure what I need to fix, but we can address it after WG=20 > discussion. >=20 > > > > And IMHO completely off is the idea to introduce carrier selection=20 > > within VoIP > > > > " For example Equal Access is > > a LEC (Local Exchange Carrier) requirement and an SP operating as > an > > LEC may be required to allow the subscriber his/her choice of IXC > > (IntereXchange Carrier) for certain set of calls. In essence, > these > > requirements may affect route policy for peering where the > downstream > > peer is chosen based on origination's policy. In this case, the > > Core-O and Core-T may be one and the same SP who peer through an > > Interconnect SP of the origination's choice." > > >=20 > Equal Access gives a headache to anyone dealing with VoIP :). I think it > is good to know what some VoIP SPs are dealing with especially when we > are starting discussions in the WG. As the draft says in the last para > - it is > possible that this may affect only a minor set of deployments in the=20 > end. Time will tell. Also, Equal Access is simply an example (I can't=20 > promise if there are not a host of other scenarios out there). >=20 > Thanks, > Medhavi. >=20 >=20 >=20 > > I have an headache > > > > Richard > > > > ________________________________ > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Gesendet: Do 02.03.2006 19:33 > > An: speermint@ietf.org > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > FYI for the WG on this draft. This is on the tentative agenda at the > Dallas meeting (should > > be finalized shortly). > > > > Jason > > > > ________________________________ > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Sunday, February 26, 2006 12:44 AM > > To: internet-drafts@ietf.org > > Cc: dmm@1-4-5.net; Livingood, Jason > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > Abstract > > > > > > > > The purpose of this document is to help the IETF community > understand > > > > the route architectures being used today in SIP based peering > > > > environments and to outline a set of requirements based on the same > > > > for discussion within the community. > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > 3/1/2006 > > _______________________________________________ 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 Fri Mar 03 09:09:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAy1-0001iN-G6; Fri, 03 Mar 2006 09:09:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAy0-0001hK-NV for speermint@ietf.org; Fri, 03 Mar 2006 09:09:12 -0500 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFAy0-0006UQ-72 for speermint@ietf.org; Fri, 03 Mar 2006 09:09:12 -0500 Received: from moe.nextone.local ([192.168.15.39]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 09:09:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 09:09:03 -0500 Message-ID: <8812D8156467224C9E9739E513037EF12A13E0@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise Peering [was Re: Intercon SP...] Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAYuVRQAApFirA= From: "Bob Natale" To: "Stastny Richard" X-OriginalArrivalTime: 03 Mar 2006 14:09:11.0819 (UTC) FILETIME=[0BC295B0:01C63ECC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Cc: speermint@ietf.org Subject: [Speermint] Enterprise Peering [was Re: Intercon SP...] 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 Richard: Concerning your observation (below): "Additional remark: what is missing in your scenario is the connection of enterprises, that is Os and Ts having networks and proxies on their own."=20 I had the same thought when I first read Medhavi's draft, but then concluded that, from the architectural context outlined in that draft, the "Enterprise Peering" case was simply an instance of "Direct Peering" between "Core SPs". If that is an accurate and acceptable interpretation, then we could address any functional or operational differences for the enterprise case in the Requirements BCP. (Currently I anticipate the need for some degree of differentiation even if only any two or more of Access SP, Interconnect SP (by whatever name), and Core SP remain valid via WG consensus.) Cheers, BobN -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Friday, March 03, 2006 4:41 AM To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org Subject: [Speermint] Intercon SP (was I-D draft-bhatia-sip-peering-00.txt) >=20 > I think maybe the draft needs to clarify that Interconnect SP is not the > same as Transit. > We can try to do this if lot of people feel the same and it really=20 > affects the routing architecture selection (IMHO - it should not have=20 > any effect) in the end. I agree that we need to discuss this and clarify (which will not be easy ;-) I know that currently Interconnect SP (on L5) are existing and providing a kind of clearing house function regarding call routing (some also provide ENUM) and also providing policy services. Some also provide L3 transit, some not. To complicate issues further, some work as proxies (as in your Figure 1), some as redirect servers. GSMA is planning to introduce such Intercon proxies within their GRX/IPX network (called hub/IPX proxies) (Note GRX/IPX is also always a mediastream transit network) Additional remark: what is missing in your scenario is the connection of enterprises, that is Os and Ts having networks and proxies on their own. Back to ENUM: There is an additional problem lurking in these complicated scenarios (I am somewhat referring back here to my previous e-mail on phone numbers) The assumption in User ENUM is that you get back the AoR out of ENUM =3D the Core-T the user defined to provide VoIP services for him (not necessarily the provider hosting the number) The assumption in Infrastructure ENUM (as currently defined in ENUM WG, not private ENUMs) that you get back either also the AoR of the SP provider hosting the number, which is translated with SRV and DNS to the ingress border element of the Core-T, or directly the ingress element This is ok if Core-O is querying Infrastructure ENUM and no Intercon is involved So what is the mechanism to involve an Intercon SP? One scenario I could imagine is the following A Core-O is querying Infrastructure ENUM, but finds out via the policy records that he has no direct peering with the Core-T. He may now forward the call to an Intercon SP which is providing connectivity to the Core-T. He may have some choices. How is the Intercon SP announcing which Core-Ts he is able to terminate? This could of course be done by the Core-T in the policy records giving the Intercon SP in his federation list. The question I have now is does the Core-O provider signal to the Intercon already the information derived from Infrastructure ENUM (=3D = the Core-T URI) or does he give again the E.164 number and the Intercon SP is querying Infrastructure ENUM again. This may not sound complicated if we assume only one global Infrastructure ENUM, but if we take into account that we may also interwork with private ENUMs? Example: GSMA decides to be reachable also from the Internet, but in public Infrastructure ENUM only the ingress border elements from IPX are entered. This requires a second ENUM query within IPX, which in turn requires the original E.164 number to be kept. Since I am currently also dealing with the header field nightmare in SIP and IMS, we may need to make the e.g. P-Called-Party-ID Header from RFC 3455 mandatory. Cheers Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, March 02, 2006 11:03 PM > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt >=20 > Hi Richard, >=20 > Sorry about the headache... > Hopefully my answers below will help :) Thanks for the quick read=20 > anyway. >=20 > Cheers, > Medhavi. >=20 > > > > >The purpose of this document is to help the IETF community understand > > > > > the route architectures being used today in SIP based peering > > > > > environments and to outline a set of requirements based on the > same > > > > > for discussion within the community > > > > > > > > Is this IMS in stealth mode? >=20 > The intent of the draft is to describe what is deployed and the=20 > requirements driving that. We can choose to ignore or accept some of=20 > them based on WG discussion. >=20 > (IMHO - I don't think IMS is deployed anywhere :) >=20 > > > > The abstract should clearly state: > > > > > > > > The purpose of this draft is to help the IETF community understand IMS > .. > > > > > > > > In particular I have problems with the following para: > > > > > > > > "The call is originated at calling party "O", (called the > > "Origination" in this document) and terminates at called party "T" > > (called the "Termination" in this document). T may be a subscriber, > > contact center, E911 operator etc. The first hop and the last hop > of > > the call in Figure 1 pass through SPs providing L5 (in our case SIP) > > access to the origination and termination and are called Access-O > and > > Access-T respectively. In most cases these SPs will also provide > the > > physical access to the origination and termination devices. The > > Access SP function is not optional. While a separate Access SP may > > not exist, the function may be absorbed by the corresponding Core > SP." > > > > A Core SP ALWAYS needs an Access SP if he is not providing the access > > by itself? In L5? > > >=20 > It says three things: (a) Access SP is mandatory (b) Access SP "may" > provide > physical access (c) Access SP can be absorbed within the Core SP. Maybe > the > language can be improved, but I think we capture the case you are=20 > talking about - an ASP (Vonage) like scenario! >=20 > > And then we also have Interconnect SP =3D Transit > > > > What happened to the SIP Trapeziod? > > >=20 > SIP Trapezoid is captured, since the Interconnect SP is optional (first > para on pg 4). > However, I think there could be a special section devoted to that. Note > that in no way > the draft is supposed to be prescriptive or designed to ignore the=20 > trapezoid. Sorry if it sounds confusing - we can fix that problem... >=20 > Also, Note that Inteconnect SPs today don't map to "Transit" as defined > in requirements > draft. >=20 > > and may I remember on the req draft > > > > "3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 > peering > > case, there is no intervening network. That is, for purposes of > this > > discussion, there is no such thing as a "Layer 5 Transit Network"." > > > > The next problem I have with section > > >=20 > I think maybe the draft needs to clarify that Interconnect SP is not the > same as Transit. > We can try to do this if lot of people feel the same and it really=20 > affects the routing architecture selection (IMHO - it should not have=20 > any effect) in the end. >=20 > > > > > > "5.2. Addressing > > > > The type of A-O-R for the termination may also affect what kind of > > address location service is used. Address location is done > typically > > based on the following four characteristics of the termination's > AOR. > > In each case, we list the most common address location method used. > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > 2. E.164 prefixes: SPs local policy is generally used. > > 3. Full A-O-R: This is rarely used for routing in a peering > > environment. > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > E.164 numbers are names > > > > so E.164 number is out of scope in SPEERMENT > > >=20 > I am not sure what I need to fix, but we can address it after WG=20 > discussion. >=20 > > > > And IMHO completely off is the idea to introduce carrier selection=20 > > within VoIP > > > > " For example Equal Access is > > a LEC (Local Exchange Carrier) requirement and an SP operating as > an > > LEC may be required to allow the subscriber his/her choice of IXC > > (IntereXchange Carrier) for certain set of calls. In essence, > these > > requirements may affect route policy for peering where the > downstream > > peer is chosen based on origination's policy. In this case, the > > Core-O and Core-T may be one and the same SP who peer through an > > Interconnect SP of the origination's choice." > > >=20 > Equal Access gives a headache to anyone dealing with VoIP :). I think it > is good to know what some VoIP SPs are dealing with especially when we > are starting discussions in the WG. As the draft says in the last para > - it is > possible that this may affect only a minor set of deployments in the=20 > end. Time will tell. Also, Equal Access is simply an example (I can't=20 > promise if there are not a host of other scenarios out there). >=20 > Thanks, > Medhavi. >=20 >=20 >=20 > > I have an headache > > > > Richard > > > > ________________________________ > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Gesendet: Do 02.03.2006 19:33 > > An: speermint@ietf.org > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > FYI for the WG on this draft. This is on the tentative agenda at the > Dallas meeting (should > > be finalized shortly). > > > > Jason > > > > ________________________________ > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Sunday, February 26, 2006 12:44 AM > > To: internet-drafts@ietf.org > > Cc: dmm@1-4-5.net; Livingood, Jason > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > Abstract > > > > > > > > The purpose of this document is to help the IETF community > understand > > > > the route architectures being used today in SIP based peering > > > > environments and to outline a set of requirements based on the same > > > > for discussion within the community. > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > 3/1/2006 > > _______________________________________________ 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 Fri Mar 03 09:34:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBMS-0001K7-1g; Fri, 03 Mar 2006 09:34:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBMR-0001HZ-8K for speermint@ietf.org; Fri, 03 Mar 2006 09:34:27 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFBMQ-0007Ww-58 for speermint@ietf.org; Fri, 03 Mar 2006 09:34:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 15:38:22 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DF6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regulatory requirements [was Re: Equal Access...] Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAAf+fcAAAUAuQA== From: "Stastny Richard" To: "Bob Natale" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Cc: speermint@ietf.org Subject: [Speermint] RE: Regulatory requirements [was Re: Equal Access...] 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 Bob, I think before we make such decisions, we should first clarify what we are talking about. Equal Access aka Carrier selection is basically a PSTN construct, allowing the end-user to order the originating (access) network which long-distance network (transit) to use (with the intrinsic assumption that you cannot select your access network - if you can, an CLEC normally does not have to provide carrier selection. And you of course cannot select the terminating network. The basic idea is to provide competition in tariffs You have either pre-selection and/or call-by-call In case of call-by-call you select the carier by dialling CAC + CIC =3D numbers If we now introduce carrier selection within SPEERMINT, we face some problems A. Simple solution: Carrier selection is only valid for calls on the PSTN, so if you dial a CAC, you force the call to the PSTN and use the same regime. B. If we extend carrier selection also to IP=20 Interconect, we face a lot of definition problems 1. What IS a Carrier? An L5 intercon SP or a L3=20 transit provider. Do you force an Intercon SP even if you could reach the core-T direct? 2. What is the reason. charging? Are there charges? Which one? Termination charges, transit charges,May there be brokers with different termination charges Or may the reason now be selection of QoS networks? 3. Routing in SPEERMINT is done via SIP URIs Numbers have already be translated into SIP URIs How do you select a carrier? Can you force a route in SIP. What is the UA input equivalent to CAC + CIC? Do we use the same CICs? Note that CICs are normally=20 nationally defined. Do we need global CICs? ITU-T will happily revive the discussion about this ;-) Etc My proposal is to first discuss the basic problems we have with IP interconnect Note: nobody knows up-to-now if end-user will really request carrier selection on IP. Cheers Richard > -----Original Message----- > From: Bob Natale [mailto:bnatale@nextone.com] > Sent: Friday, March 03, 2006 2:53 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: Regulatory requirements [was Re: Equal Access...] >=20 > Hi Richard, >=20 > Concerning this observation from you (below): > "The major problem with Equal Access is that this cannot be solved in > SPEERMINT, because it is a national regulatory matter." >=20 > We will have to take at least a summary position, in our Requirements > BCP document, wrt regulatory requirements. >=20 > I guess the possibilities include: > - Try to exclude everything that is (typically?) subject to such > regulation? > - Try to include ? > - Deal with it on a case by case basis? > - Ignore this aspect for any otherwise necessary requirement and > prescribe what we determine is best, leaving affected SPs and users to > sort the matter out locally? > - Something else...? >=20 > Cheers, > BobN >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 03, 2006 5:12 AM > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > Subject: [Speermint] Equal Access (was I-D > draft-bhatia-sip-peering-00.txt) >=20 > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we >=20 > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I can't > > promise if there are not a host of other scenarios out there). >=20 > The major problem with Equal Access is that this cannot be solved in > SPEERMINT, because it is a national regulatory matter. >=20 > In Europe it is part of the remedies to telcos having significant market > power (SMP). It is also a typical PSTN issue. So it depends first on a > decision in which market VoIP is placed. If you put VoIP which is a PSTN > substitution into the fixed-line voice market, the existing remedies for > SMP providers such as carrier selection apply. >=20 > A typical candidate is VoB provided bundled with BB-access, e.g. a XDSL > access with a terminal adapter and a normal phone or an XDSL with an > IP-phone. >=20 > This raises may questions such as: > if you are able to unbundle your access and are able to choose another > DSL provider, to you still need carrier selection? >=20 > Is carrier selection only valid for voice and voice related services, > especially if the selected carrier still has only access via the PSTN? > What if you switch during a call to video? >=20 > What does carrier selection imply with IP Interconnect? > L5 Interconnect or also L3 transit? >=20 > A very nice example is if Core-O and Core-T is the same, e.g. running on > the same server, do you still have to provide carrier selection if the > call is now forced via the PSTN? >=20 > Etc. etc. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) Thanks for the quick read > > anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are > > talking about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the > > trapezoid. Sorry if it sounds confusing - we can fix that problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing architecture selection (IMHO - it should not have > > any effect) in the end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce carrier selection > > > within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we >=20 > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I can't > > promise if there are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > >=20 > _______________________________________________ > 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 Fri Mar 03 09:45:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBWk-0006My-An; Fri, 03 Mar 2006 09:45:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBWj-0006MR-38 for speermint@ietf.org; Fri, 03 Mar 2006 09:45:05 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFBWg-0007wz-Fu for speermint@ietf.org; Fri, 03 Mar 2006 09:45:05 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1141397022!7156242!20 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20950 invoked from network); 3 Mar 2006 14:45:00 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 3 Mar 2006 14:45:00 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 43F8A544001EEDC8; Fri, 3 Mar 2006 09:44:59 -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] RE: Regulatory requirements [was Re: Equal Access...] Date: Fri, 3 Mar 2006 09:44:58 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C454B97@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4DF6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Regulatory requirements [was Re: Equal Access...] Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAAf+fcAAAUAuQAAAs6kw From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , "Bob Natale" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d Cc: speermint@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 I tend to agree with Richard - let's keep the core focus on service provider (L5) peering. Carrier selection is something different and may more properly be handled in other fora better attuned to PSTN issues which, as Richard points out, have national variations. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Friday, March 03, 2006 9:38 AM To: Bob Natale Cc: speermint@ietf.org Subject: [Speermint] RE: Regulatory requirements [was Re: Equal Access...] Hi Bob, I think before we make such decisions, we should first clarify what we are talking about. Equal Access aka Carrier selection is basically a PSTN construct, allowing the end-user to order the originating (access) network which long-distance network (transit) to use (with the intrinsic assumption that you cannot select your access network - if you can, an CLEC normally does not have to provide carrier selection. And you of course cannot select the terminating network. The basic idea is to provide competition in tariffs You have either pre-selection and/or call-by-call In case of call-by-call you select the carier by dialling CAC + CIC =3D numbers If we now introduce carrier selection within SPEERMINT, we face some problems A. Simple solution: Carrier selection is only valid for calls on the PSTN, so if you dial a CAC, you force the call to the PSTN and use the same regime. B. If we extend carrier selection also to IP=20 Interconect, we face a lot of definition problems 1. What IS a Carrier? An L5 intercon SP or a L3=20 transit provider. Do you force an Intercon SP even if you could reach the core-T direct? 2. What is the reason. charging? Are there charges? Which one? Termination charges, transit charges,May there be brokers with different termination charges Or may the reason now be selection of QoS networks? 3. Routing in SPEERMINT is done via SIP URIs Numbers have already be translated into SIP URIs How do you select a carrier? Can you force a route in SIP. What is the UA input equivalent to CAC + CIC? Do we use the same CICs? Note that CICs are normally=20 nationally defined. Do we need global CICs? ITU-T will happily revive the discussion about this ;-) Etc My proposal is to first discuss the basic problems we have with IP interconnect Note: nobody knows up-to-now if end-user will really request carrier selection on IP. Cheers Richard > -----Original Message----- > From: Bob Natale [mailto:bnatale@nextone.com] > Sent: Friday, March 03, 2006 2:53 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: Regulatory requirements [was Re: Equal Access...] >=20 > Hi Richard, >=20 > Concerning this observation from you (below): > "The major problem with Equal Access is that this cannot be solved in > SPEERMINT, because it is a national regulatory matter." >=20 > We will have to take at least a summary position, in our Requirements > BCP document, wrt regulatory requirements. >=20 > I guess the possibilities include: > - Try to exclude everything that is (typically?) subject to such > regulation? > - Try to include ? > - Deal with it on a case by case basis? > - Ignore this aspect for any otherwise necessary requirement and > prescribe what we determine is best, leaving affected SPs and users to > sort the matter out locally? > - Something else...? >=20 > Cheers, > BobN >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 03, 2006 5:12 AM > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > Subject: [Speermint] Equal Access (was I-D > draft-bhatia-sip-peering-00.txt) >=20 > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we >=20 > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I can't > > promise if there are not a host of other scenarios out there). >=20 > The major problem with Equal Access is that this cannot be solved in > SPEERMINT, because it is a national regulatory matter. >=20 > In Europe it is part of the remedies to telcos having significant market > power (SMP). It is also a typical PSTN issue. So it depends first on a > decision in which market VoIP is placed. If you put VoIP which is a PSTN > substitution into the fixed-line voice market, the existing remedies for > SMP providers such as carrier selection apply. >=20 > A typical candidate is VoB provided bundled with BB-access, e.g. a XDSL > access with a terminal adapter and a normal phone or an XDSL with an > IP-phone. >=20 > This raises may questions such as: > if you are able to unbundle your access and are able to choose another > DSL provider, to you still need carrier selection? >=20 > Is carrier selection only valid for voice and voice related services, > especially if the selected carrier still has only access via the PSTN? > What if you switch during a call to video? >=20 > What does carrier selection imply with IP Interconnect? > L5 Interconnect or also L3 transit? >=20 > A very nice example is if Core-O and Core-T is the same, e.g. running on > the same server, do you still have to provide carrier selection if the > call is now forced via the PSTN? >=20 > Etc. etc. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) Thanks for the quick read > > anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are > > talking about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the > > trapezoid. Sorry if it sounds confusing - we can fix that problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing architecture selection (IMHO - it should not have > > any effect) in the end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce carrier selection > > > within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we >=20 > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I can't > > promise if there are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > >=20 > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 09:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBen-0001uS-AV; Fri, 03 Mar 2006 09:53:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBem-0001r7-8n for speermint@ietf.org; Fri, 03 Mar 2006 09:53:24 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFBek-0008Br-0l for speermint@ietf.org; Fri, 03 Mar 2006 09:53:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 15:57:20 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DF7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise Peering [was Re: Intercon SP...] Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAYuVRQAApFirAAAY1T4A== From: "Stastny Richard" To: "Bob Natale" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: speermint@ietf.org Subject: [Speermint] RE: Enterprise Peering [was Re: Intercon SP...] 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 Bob, > I had the same thought when I first read Medhavi's draft, but then > concluded that, from the architectural context outlined in that draft, > the "Enterprise Peering" case was simply an instance of "Direct Peering" > between "Core SPs". I fear this is not so simple. First we have to clarify if an enterprise can be a core SP on its own and what are the minimum requirements=20 to be one. Second, we also need to consider that some enterprises (e.g. small ones) do not want to be a core SP on its own. ECMA (dealing in Europe with PBX issues (they specified e.g. QSIG) presented at the last ETSI TISPAN meeting their view on Next Generation Corporate Networks (NGCN) They presented five scenarios, containing everything between direct peering and using SP for interconnect Of course the also want both: some traffic is exchanged via direct peering (e.g. within the enterprise and also within federations, some traffic is going via Core-SPs So I think we have to use both models: an NGCN as core -SP and also an NGCN connected via access SP and core SP Cheers Richard > -----Original Message----- > From: Bob Natale [mailto:bnatale@nextone.com] > Sent: Friday, March 03, 2006 3:09 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: Enterprise Peering [was Re: Intercon SP...] >=20 > Hi Richard: >=20 > Concerning your observation (below): > "Additional remark: what is missing in your scenario is the connection > of enterprises, that is Os and Ts having networks and proxies on their > own." >=20 > I had the same thought when I first read Medhavi's draft, but then > concluded that, from the architectural context outlined in that draft, > the "Enterprise Peering" case was simply an instance of "Direct Peering" > between "Core SPs". >=20 > If that is an accurate and acceptable interpretation, then we could > address any functional or operational differences for the enterprise > case in the Requirements BCP. (Currently I anticipate the need for some > degree of differentiation even if only any two or more of Access SP, > Interconnect SP (by whatever name), and Core SP remain valid via WG > consensus.) >=20 > Cheers, > BobN >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 03, 2006 4:41 AM > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > Subject: [Speermint] Intercon SP (was I-D > draft-bhatia-sip-peering-00.txt) >=20 > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing architecture selection (IMHO - it should not have > > any effect) in the end. >=20 > I agree that we need to discuss this and clarify (which will not be easy > ;-) >=20 > I know that currently Interconnect SP (on L5) are existing and providing > a kind of clearing house function regarding call routing (some also > provide ENUM) and also providing policy services. >=20 > Some also provide L3 transit, some not. >=20 > To complicate issues further, some work as proxies (as in your Figure > 1), some as redirect servers. >=20 > GSMA is planning to introduce such Intercon proxies within their GRX/IPX > network (called hub/IPX proxies) (Note GRX/IPX is also always a > mediastream transit network) >=20 > Additional remark: what is missing in your scenario is the connection of > enterprises, that is Os and Ts having networks and proxies on their own. >=20 > Back to ENUM: >=20 > There is an additional problem lurking in these complicated scenarios (I > am somewhat referring back here to my previous e-mail on phone numbers) >=20 > The assumption in User ENUM is that you get back the AoR out of ENUM = =3D > the Core-T the user defined to provide VoIP services for him (not > necessarily the provider hosting the number) >=20 > The assumption in Infrastructure ENUM (as currently defined in ENUM WG, > not private ENUMs) that you get back either also the AoR of the SP > provider hosting the number, which is translated with SRV and DNS to the > ingress border element of the Core-T, or directly the ingress element >=20 > This is ok if Core-O is querying Infrastructure ENUM and no Intercon is > involved >=20 > So what is the mechanism to involve an Intercon SP? >=20 > One scenario I could imagine is the following A Core-O is querying > Infrastructure ENUM, but finds out via the policy records that he has no > direct peering with the Core-T. >=20 > He may now forward the call to an Intercon SP which is providing > connectivity to the Core-T. He may have some choices. >=20 > How is the Intercon SP announcing which Core-Ts he is able to terminate? >=20 > This could of course be done by the Core-T in the policy records giving > the Intercon SP in his federation list. >=20 > The question I have now is does the Core-O provider signal to the > Intercon already the information derived from Infrastructure ENUM (=3D the > Core-T URI) or does he give again the E.164 number and the Intercon SP > is querying Infrastructure ENUM again. >=20 > This may not sound complicated if we assume only one global > Infrastructure ENUM, but if we take into account that we may also > interwork with private ENUMs? >=20 > Example: >=20 > GSMA decides to be reachable also from the Internet, but in public > Infrastructure ENUM only the ingress border elements from IPX are > entered. This requires a second ENUM query within IPX, which in turn > requires the original > E.164 number to be kept. >=20 > Since I am currently also dealing with the header field nightmare in SIP > and IMS, we may need to make the e.g. P-Called-Party-ID Header from RFC > 3455 mandatory. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) Thanks for the quick read > > anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are > > talking about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the > > trapezoid. Sorry if it sounds confusing - we can fix that problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing architecture selection (IMHO - it should not have > > any effect) in the end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce carrier selection > > > within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we >=20 > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I can't > > promise if there are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > >=20 > _______________________________________________ > 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 Fri Mar 03 09:55:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBh3-0003Z8-GJ; Fri, 03 Mar 2006 09:55:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBh3-0003Z3-46 for speermint@ietf.org; Fri, 03 Mar 2006 09:55:45 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBh2-0008Di-GA for speermint@ietf.org; Fri, 03 Mar 2006 09:55:45 -0500 Received: from moe.nextone.local ([192.168.15.39]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 09:55:44 -0500 Content-class: urn:content-classes:message Subject: RE: [Speermint] RE: Regulatory requirements [was Re: Equal Access...] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 09:55:36 -0500 Message-ID: <8812D8156467224C9E9739E513037EF12A144C@moe.nextone.local> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Regulatory requirements [was Re: Equal Access...] Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAAf+fcAAAUAuQAAAs6kwAAB8nuA= From: "Bob Natale" To: "Pfautz, Penn L, NEO" , "Stastny Richard" X-OriginalArrivalTime: 03 Mar 2006 14:55:44.0113 (UTC) FILETIME=[8C18D610:01C63ED2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 Cc: speermint@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 Guys, I understand your position re the specific topic of carrier selection within equal access. I changed the subject header on purpose: We need to consider the *general* case of regulatory requirements in the context of the Requirements BCP charter item. The best I can deduce from your responses so far is that we'll go with the 3rd alternative I identified below: Namely, we'll deal with that broader question on a case by case basis...? Cheers, BobN -----Original Message----- From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]=20 Sent: Friday, March 03, 2006 9:45 AM To: Stastny Richard; Bob Natale Cc: speermint@ietf.org Subject: RE: [Speermint] RE: Regulatory requirements [was Re: Equal Access...] I tend to agree with Richard - let's keep the core focus on service provider (L5) peering. Carrier selection is something different and may more properly be handled in other fora better attuned to PSTN issues which, as Richard points out, have national variations. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, March 03, 2006 9:38 AM To: Bob Natale Cc: speermint@ietf.org Subject: [Speermint] RE: Regulatory requirements [was Re: Equal Access...] Hi Bob, I think before we make such decisions, we should first clarify what we are talking about. Equal Access aka Carrier selection is basically a PSTN construct, allowing the end-user to order the originating (access) network which long-distance network (transit) to use (with the intrinsic assumption that you cannot select your access network - if you can, an CLEC normally does not have to provide carrier selection. And you of course cannot select the terminating network. The basic idea is to provide competition in tariffs You have either pre-selection and/or call-by-call In case of call-by-call you select the carier by dialling CAC + CIC =3D numbers If we now introduce carrier selection within SPEERMINT, we face some problems A. Simple solution: Carrier selection is only valid for calls on the PSTN, so if you dial a CAC, you force the call to the PSTN and use the same regime. B. If we extend carrier selection also to IP Interconect, we face a lot of definition problems 1. What IS a Carrier? An L5 intercon SP or a L3 transit provider. Do you force an Intercon SP even if you could reach the core-T direct? 2. What is the reason. charging? Are there charges? Which one? Termination charges, transit charges,May there be brokers with different termination charges Or may the reason now be selection of QoS networks? 3. Routing in SPEERMINT is done via SIP URIs Numbers have already be translated into SIP URIs How do you select a carrier? Can you force a route in SIP. What is the UA input equivalent to CAC + CIC? Do we use the same CICs? Note that CICs are normally nationally defined. Do we need global CICs? ITU-T will happily revive the discussion about this ;-) Etc My proposal is to first discuss the basic problems we have with IP interconnect Note: nobody knows up-to-now if end-user will really request carrier selection on IP. Cheers Richard > -----Original Message----- > From: Bob Natale [mailto:bnatale@nextone.com] > Sent: Friday, March 03, 2006 2:53 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: Regulatory requirements [was Re: Equal Access...] >=20 > Hi Richard, >=20 > Concerning this observation from you (below): > "The major problem with Equal Access is that this cannot be solved in=20 > SPEERMINT, because it is a national regulatory matter." >=20 > We will have to take at least a summary position, in our Requirements=20 > BCP document, wrt regulatory requirements. >=20 > I guess the possibilities include: > - Try to exclude everything that is (typically?) subject to such=20 > regulation? > - Try to include ? > - Deal with it on a case by case basis? > - Ignore this aspect for any otherwise necessary requirement and=20 > prescribe what we determine is best, leaving affected SPs and users to > sort the matter out locally? > - Something else...? >=20 > Cheers, > BobN >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 03, 2006 5:12 AM > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > Subject: [Speermint] Equal Access (was I-D > draft-bhatia-sip-peering-00.txt) >=20 > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we >=20 > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I can't > > promise if there are not a host of other scenarios out there). >=20 > The major problem with Equal Access is that this cannot be solved in=20 > SPEERMINT, because it is a national regulatory matter. >=20 > In Europe it is part of the remedies to telcos having significant market > power (SMP). It is also a typical PSTN issue. So it depends first on a > decision in which market VoIP is placed. If you put VoIP which is a PSTN > substitution into the fixed-line voice market, the existing remedies for > SMP providers such as carrier selection apply. >=20 > A typical candidate is VoB provided bundled with BB-access, e.g. a XDSL > access with a terminal adapter and a normal phone or an XDSL with an=20 > IP-phone. >=20 > This raises may questions such as: > if you are able to unbundle your access and are able to choose another > DSL provider, to you still need carrier selection? >=20 > Is carrier selection only valid for voice and voice related services,=20 > especially if the selected carrier still has only access via the PSTN? > What if you switch during a call to video? >=20 > What does carrier selection imply with IP Interconnect? > L5 Interconnect or also L3 transit? >=20 > A very nice example is if Core-O and Core-T is the same, e.g. running on > the same server, do you still have to provide carrier selection if the > call is now forced via the PSTN? >=20 > Etc. etc. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) Thanks for the quick read=20 > > anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the=20 > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are=20 > > talking about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the=20 > > trapezoid. Sorry if it sounds confusing - we can fix that problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really=20 > > affects the routing architecture selection (IMHO - it should not have > > any effect) in the end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG=20 > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce carrier selection > > > within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we >=20 > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I can't > > promise if there are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > >=20 > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 11:08:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCpP-0007Bt-DN; Fri, 03 Mar 2006 11:08:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCpN-00076f-Nz for speermint@ietf.org; Fri, 03 Mar 2006 11:08:25 -0500 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFCpN-0002bJ-Dg for speermint@ietf.org; Fri, 03 Mar 2006 11:08:25 -0500 Received: from moe.nextone.local ([192.168.15.39]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 11:08:25 -0500 Content-class: urn:content-classes:message Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 11:08:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <8812D8156467224C9E9739E513037EF12A14E6@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt Thread-Index: AcY+xUckRl/LDghCTEKxgbyOmguo1AAFbpkA From: "Medhavi Bhatia" To: "Otmar Lendl" , X-OriginalArrivalTime: 03 Mar 2006 16:08:25.0101 (UTC) FILETIME=[B372CBD0:01C63EDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Hi Otmar, Thanks for comments. I have tried to provide some clarifications below. -Medhavi. > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Friday, March 03, 2006 8:19 AM > To: speermint@ietf.org > Subject: Re: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt >=20 > > > > Network Working Group M. Bhatia > > Internet-Draft NexTone Communications > > Expires: August 30, 2006 February 26, 2006 > > >=20 > This draft is quite helpful as it provides clarificatons concerning the > terminology and describes some setups. >=20 > Some questions, though: >=20 > > 2. Terminology >=20 > > Service Provider (SP): We use the term Service Provider in this > > document to refer to a SIP Service Provider[3]. The individual > > types of SPs are defined below. > > > > Access SP: An SP which acts as the first hop between the > > subscriber and the Core SP. >=20 > Is this Access SP role restricted to the SIP layer or is it implied > that this Access SP also is the layer 3 access provider for "O"? >=20 For purposes of this doc and given the WG scope, the Access SP (if one exists in the flow) is a L5 (sip aware) SP. The case where there is a layer 3 SP and is different from the Core SP or Access SP is probably not worth considering since there is no SIP peering involved between the Layer 3 SP and the access/core SPs (I also think that in most cases if the access SP exists, it will exist because it owns the layer 3). Also I realize that there may not be many access SPs (L5) today, but chances are that today's Layer 3 SPs will attempt to become tomorrow's Access SPs. > > 4. Routing Architectures > > > > 1. Direct Peering: > > > > Federation: A federation is typically a set of SPs which are > > terminating calls to each other using some well known > > mechanisms for settlement, address location and some other > > common administrative policies. In most cases the peering SPs > > are connected to a trusted private network and trust all calls > > terminating on them over this network. > > > > Federations typically use ENUM as the registry database > > (owned by the federation or a trusted third party) to > > provide address location services and applications like > > number portability. Other aspects of the routing policy > > (as described in Section 5) are implemented using edge > > proxies or session border controllers (Section 4.1). >=20 > This use of "Federation" fits in very well with my definition > of draft-lendl-speermint-federations-00. Good. >=20 > Federations can only use ENUM if routing is based on E.164 numbers. > If we ever switch to direct URI dialing, then ENUM cannot be used > within a federation. >=20 > Btw, draft-lendl-domain-policy-ddds-00 provides a solution for > selecting the right federation for a call and thus enables SPs > to be part of multiple federations. >=20 > > > > 5. Requirements for route policy and architecture for peering > > > > 2. Addressing: Whether the address of record of the termination is > > an E.164 address or a generic AOR (e.g foo@bar.com) >=20 > IMHO: We should not design a system which does assume that E.164 > numbers are available as routing information. >=20 I'd agree. I am thinking there will be a lot more discussion on how the presence of E.164 changes the situation (maybe dips into some legacy system). In practice the access SPs and core SPs may be providing SIP based access to legacy PSTN. I assume those scenarios are also in scope. Medhavi. > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 11:44:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDOd-0002WW-Dw; Fri, 03 Mar 2006 11:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDOb-0002Ua-Te for speermint@ietf.org; Fri, 03 Mar 2006 11:44:49 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFDOb-0004SA-BA for speermint@ietf.org; Fri, 03 Mar 2006 11:44:49 -0500 Received: from moe.nextone.local ([192.168.15.39]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 11:44:48 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 11:44:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <8812D8156467224C9E9739E513037EF12A151B@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intercon SP (was I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAYuVRQAA9wzBA= From: "Medhavi Bhatia" To: "Stastny Richard" , "Livingood, Jason" , X-OriginalArrivalTime: 03 Mar 2006 16:44:48.0884 (UTC) FILETIME=[C915A340:01C63EE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 Cc: Subject: [Speermint] RE: Intercon SP (was I-D draft-bhatia-sip-peering-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 Richard, You have raised some interesting problems below. I am sure there will be a lot of discussion around this. Anyway, my comments are below: -Medhavi. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 03, 2006 4:41 AM > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > Subject: Intercon SP (was I-D draft-bhatia-sip-peering-00.txt) >=20 > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing > > architecture selection (IMHO - it should not have any effect) in the > > end. >=20 > I agree that we need to discuss this and clarify > (which will not be easy ;-) >=20 > I know that currently Interconnect SP (on L5) are existing > and providing a kind of clearing house function regarding > call routing (some also provide ENUM) and also providing > policy services. >=20 > Some also provide L3 transit, some not. >=20 > To complicate issues further, some work as proxies > (as in your Figure 1), some as redirect servers. >=20 > GSMA is planning to introduce such Intercon proxies > within their GRX/IPX network (called hub/IPX proxies) > (Note GRX/IPX is also always a mediastream transit network) >=20 > Additional remark: what is missing in your scenario > is the connection of enterprises, that is Os and Ts > having networks and proxies on their own. >=20 I think this case is handled as long as the network which O has acts as its Core SP. In other words the SP in the middle is purely an Interconnect (I prefer inventing a new term such as IXP for these folks doing this). If the scenario is that O has a network but it is separate from Core-O (which is an SP), then that network may be classified as either Access SP or one of the IXPs in the middle.=20 In terms of requirements, this does raise the question how does an Enterprise advertise or announce the numbers. There are other requirements of course for direct or hosted services used by the enterprise (like some sort of controlled access control policies or B2B). > Back to ENUM: >=20 > There is an additional problem lurking in these > complicated scenarios (I am somewhat referring > back here to my previous e-mail on phone numbers) >=20 > The assumption in User ENUM is that you get > back the AoR out of ENUM =3D the Core-T > the user defined to provide VoIP services > for him (not necessarily the provider > hosting the number) >=20 > The assumption in Infrastructure ENUM (as > currently defined in ENUM WG, not private ENUMs) > that you get back either also the AoR of the SP > provider hosting the number, which is translated > with SRV and DNS to the ingress border element > of the Core-T, or directly the ingress element >=20 > This is ok if Core-O is querying Infrastructure > ENUM and no Intercon is involved >=20 > So what is the mechanism to involve an Intercon SP? >=20 > One scenario I could imagine is the following > A Core-O is querying Infrastructure ENUM, but > finds out via the policy records that he has > no direct peering with the Core-T. >=20 > He may now forward the call to an Intercon SP which > is providing connectivity to the Core-T. He may > have some choices. >=20 > How is the Intercon SP announcing which Core-Ts > he is able to terminate? >=20 I think this is a very important question for the WG. I was implicitly assuming some sort of private ENUM (hop by hop basis), but we need to answer all the questions you have below. I think the IPX (GRX folks) have this problem today. The Core-O does an ENUM dip and gets the IPX border element's domain address. Following this, the IPX border element is doing another ENUM dip to get to Core-T. The second option is that Core-O does the dip and gets the domain for Core-T. Now using business policies it decides that the best way to get to it is to get through the IXP (IPX :) it has an agreement with. The IXP then does the dip again to route the call to Core-T. The problem here is that there is local policy Core-O used to get to the IXP. I think some folks may say that we need not solve this problem in the WG given that the IXP may want to control that based on business arrangements. However I think there will be "free" or low cost or "better" IXPs who would want to enlist themselves in some sort of federation (I think you refer to this model as well). At best this should be another ENUM dip kept separate from the previous one (which is used by everyone). This ENUM dip would be done for the Core-T domain and the result will be the IXP list and the dip could be done to the IXP federation ENUM server. > This could of course be done by the Core-T in > the policy records giving the Intercon SP in > his federation list. >=20 > The question I have now is does the Core-O > provider signal to the Intercon already the > information derived from Infrastructure ENUM > (=3D the Core-T URI) or does he give again > the E.164 number and the Intercon SP is > querying Infrastructure ENUM again. >=20 > This may not sound complicated if we assume > only one global Infrastructure ENUM, but if we take > into account that we may also interwork with > private ENUMs? >=20 > Example: >=20 > GSMA decides to be reachable also from the > Internet, but in public Infrastructure ENUM > only the ingress border elements from IPX are > entered. This requires a second ENUM query > within IPX, which in turn requires the original > E.164 number to be kept. >=20 > Since I am currently also dealing with the > header field nightmare in SIP and IMS, we > may need to make the e.g. P-Called-Party-ID > Header from RFC 3455 mandatory. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) > > Thanks for the quick read anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are > > talking > > about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the > > trapezoid. Sorry if it sounds > > confusing - we can fix that problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing > > architecture selection (IMHO - it should not have any effect) in the > > end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce > > > carrier selection within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time > > will tell. Also, Equal Access is simply an example (I can't promise if > > there > > are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 12:54:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFETv-0005s7-Tn; Fri, 03 Mar 2006 12:54:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFESx-0003iQ-62 for speermint@ietf.org; Fri, 03 Mar 2006 12:53:23 -0500 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFEKA-0006Ez-DS for speermint@ietf.org; Fri, 03 Mar 2006 12:44:20 -0500 Received: from moe.nextone.local ([192.168.15.39]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 12:44:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 12:44:09 -0500 Message-ID: <8812D8156467224C9E9739E513037EF12A157F@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Equal Access (was I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAA6AVFA= From: "Medhavi Bhatia" To: "Stastny Richard" , "Livingood, Jason" , X-OriginalArrivalTime: 03 Mar 2006 17:44:14.0205 (UTC) FILETIME=[162E72D0:01C63EEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: Subject: [Speermint] RE: Equal Access (was I-D draft-bhatia-sip-peering-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 raises may questions such as: > if you are able to unbundle your access and are > able to choose another DSL provider, to you still > need carrier selection? My personal opinion is that it may not be not required for the case you have above. I think for the WG purposes, the solution we come with for the Interconnect SP problem (in the other thread we have on the WG list) may also be used to solve this. An Access SP or Core SP which needs to provide this to the subscriber for whatever reason treats the LD carrier as an Interconnect SP. The LD Carrier will need to do another lookup to get to Core-T (which may be same as Core-O in this case).=20 >=20 > Is carrier selection only valid for voice and voice > related services, especially if the selected carrier > still has only access via the PSTN? What if you switch > during a call to video? >=20 > What does carrier selection imply with IP Interconnect? > L5 Interconnect or also L3 transit? >=20 > A very nice example is if Core-O and Core-T is the > same, e.g. running on the same server, > do you still have to provide carrier selection > if the call is now forced via the PSTN? >=20 This scenario may exist. I have heard about it as a requirement in some VoIP deployments. Medhavi. > Etc. etc. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) > > Thanks for the quick read anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are > > talking > > about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the > > trapezoid. Sorry if it sounds > > confusing - we can fix that problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing > > architecture selection (IMHO - it should not have any effect) in the > > end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce > > > carrier selection within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time > > will tell. Also, Equal Access is simply an example (I can't promise if > > there > > are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 13:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEbM-00068O-J6; Fri, 03 Mar 2006 13:02:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEbK-00063w-MS for speermint@ietf.org; Fri, 03 Mar 2006 13:02:02 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFEbJ-0006yU-BW for speermint@ietf.org; Fri, 03 Mar 2006 13:02:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 19:05:59 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48AD@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intercon SP (was I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAYuVRQAA9wzBAAAviA2g== From: "Stastny Richard" To: "Medhavi Bhatia" , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 08582f3b796126054df71137d5cb69f8 Cc: Subject: [Speermint] RE: Intercon SP (was I-D draft-bhatia-sip-peering-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 Medhavi, =20 >I am sure there will be a lot of discussion around this =20 You can bet on this ;-) =20 >I think this case is handled as long as the network which O has acts as >its Core SP. In other words the SP in the middle is purely an >Interconnect (I prefer inventing a new term such as IXP for these folks >doing this). If the scenario is that O has a network but it is separate >from Core-O (which is an SP), then that network may be classified as >either Access SP or one of the IXPs in the middle. IMHO it is required to define the task of each SP in the chain exactly What are the tasks and purposes of an Access SP? Simple proxying Register and Invite messages between the o and the Core-O, Or are there additional functions? E.G providing emergency dial strings as currently discussed in ECRIT act as an Emergency Service Routing Proxy. What else? >In terms of requirements, this does raise the question how does an >Enterprise advertise or announce the numbers. There are other >requirements of course for direct or hosted services used by the >enterprise (like some sort of controlled access control policies or >B2B). Regarding E.164 numbers there is an intersting issue with Infratsructure ENUM. An enterprise may have e.g. a geo-number which is hosted by a Core-T. The enterprise may have in addition a=20 national corporate number or an 800 number assigned directly=20 to the enterprise by the NRA. The enterprise may decide now to host this number either with another SP or even point this number directly to his proxy, acting in this case as Core-T Regarding you answer below on different ENUM dips (private, IXP and global Infrastructure) one should alweay keep the prime purpose of Infrastructure ENUM in mind: saving admistrative cost (OPEX). The basic idea of ENUM is that the Core-T hosting the number is administrating his own numbers only and all other Core-O are querying these numbers If a Core-O is running and querying a private ENUM database, one has first to ask the question where are the data coming from? definitely not from the Core-T. Who is maintaing the data, if eg a number is ported in another country an now moving from one IXP to the other? cheers Richard ________________________________ Von: Medhavi Bhatia [mailto:mbhatia@nextone.com] Gesendet: Fr 03.03.2006 17:44 An: Stastny Richard; Livingood, Jason; speermint@ietf.org Betreff: RE: Intercon SP (was I-D draft-bhatia-sip-peering-00.txt) Richard, You have raised some interesting problems below. I am sure there will be a lot of discussion around this. Anyway, my comments are below: -Medhavi. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 03, 2006 4:41 AM > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > Subject: Intercon SP (was I-D draft-bhatia-sip-peering-00.txt) > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing > > architecture selection (IMHO - it should not have any effect) in the > > end. > > I agree that we need to discuss this and clarify > (which will not be easy ;-) > > I know that currently Interconnect SP (on L5) are existing > and providing a kind of clearing house function regarding > call routing (some also provide ENUM) and also providing > policy services. > > Some also provide L3 transit, some not. > > To complicate issues further, some work as proxies > (as in your Figure 1), some as redirect servers. > > GSMA is planning to introduce such Intercon proxies > within their GRX/IPX network (called hub/IPX proxies) > (Note GRX/IPX is also always a mediastream transit network) > > Additional remark: what is missing in your scenario > is the connection of enterprises, that is Os and Ts > having networks and proxies on their own. > I think this case is handled as long as the network which O has acts as its Core SP. In other words the SP in the middle is purely an Interconnect (I prefer inventing a new term such as IXP for these folks doing this). If the scenario is that O has a network but it is separate from Core-O (which is an SP), then that network may be classified as either Access SP or one of the IXPs in the middle. In terms of requirements, this does raise the question how does an Enterprise advertise or announce the numbers. There are other requirements of course for direct or hosted services used by the enterprise (like some sort of controlled access control policies or B2B). > Back to ENUM: > > There is an additional problem lurking in these > complicated scenarios (I am somewhat referring > back here to my previous e-mail on phone numbers) > > The assumption in User ENUM is that you get > back the AoR out of ENUM =3D the Core-T > the user defined to provide VoIP services > for him (not necessarily the provider > hosting the number) > > The assumption in Infrastructure ENUM (as > currently defined in ENUM WG, not private ENUMs) > that you get back either also the AoR of the SP > provider hosting the number, which is translated > with SRV and DNS to the ingress border element > of the Core-T, or directly the ingress element > > This is ok if Core-O is querying Infrastructure > ENUM and no Intercon is involved > > So what is the mechanism to involve an Intercon SP? > > One scenario I could imagine is the following > A Core-O is querying Infrastructure ENUM, but > finds out via the policy records that he has > no direct peering with the Core-T. > > He may now forward the call to an Intercon SP which > is providing connectivity to the Core-T. He may > have some choices. > > How is the Intercon SP announcing which Core-Ts > he is able to terminate? > I think this is a very important question for the WG. I was implicitly assuming some sort of private ENUM (hop by hop basis), but we need to answer all the questions you have below. I think the IPX (GRX folks) have this problem today. The Core-O does an ENUM dip and gets the IPX border element's domain address. Following this, the IPX border element is doing another ENUM dip to get to Core-T. The second option is that Core-O does the dip and gets the domain for Core-T. Now using business policies it decides that the best way to get to it is to get through the IXP (IPX :) it has an agreement with. The IXP then does the dip again to route the call to Core-T. The problem here is that there is local policy Core-O used to get to the IXP. I think some folks may say that we need not solve this problem in the WG given that the IXP may want to control that based on business arrangements. However I think there will be "free" or low cost or "better" IXPs who would want to enlist themselves in some sort of federation (I think you refer to this model as well). At best this should be another ENUM dip kept separate from the previous one (which is used by everyone). This ENUM dip would be done for the Core-T domain and the result will be the IXP list and the dip could be done to the IXP federation ENUM server. > This could of course be done by the Core-T in > the policy records giving the Intercon SP in > his federation list. > > The question I have now is does the Core-O > provider signal to the Intercon already the > information derived from Infrastructure ENUM > (=3D the Core-T URI) or does he give again > the E.164 number and the Intercon SP is > querying Infrastructure ENUM again. > > This may not sound complicated if we assume > only one global Infrastructure ENUM, but if we take > into account that we may also interwork with > private ENUMs? > > Example: > > GSMA decides to be reachable also from the > Internet, but in public Infrastructure ENUM > only the ingress border elements from IPX are > entered. This requires a second ENUM query > within IPX, which in turn requires the original > E.164 number to be kept. > > Since I am currently also dealing with the > header field nightmare in SIP and IMS, we > may need to make the e.g. P-Called-Party-ID > Header from RFC 3455 mandatory. > > Cheers > > Richard > > > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) > > Thanks for the quick read anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are > > talking > > about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the > > trapezoid. Sorry if it sounds > > confusing - we can fix that problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing > > architecture selection (IMHO - it should not have any effect) in the > > end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce > > > carrier selection within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time > > will tell. Also, Equal Access is simply an example (I can't promise if > > there > > are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 03 13:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFHj-0003S8-En; Fri, 03 Mar 2006 13:45:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFHi-0003QN-Sa for speermint@ietf.org; Fri, 03 Mar 2006 13:45:50 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFFHi-0000Lh-Br for speermint@ietf.org; Fri, 03 Mar 2006 13:45:50 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1141411428!8047622!46 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 312 invoked from network); 3 Mar 2006 18:45:49 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-121.messagelabs.com with SMTP; 3 Mar 2006 18:45:49 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 4401E007000CBEE4; Fri, 3 Mar 2006 13:45:48 -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] RE: Equal Access (was I-Ddraft-bhatia-sip-peering-00.txt) Date: Fri, 3 Mar 2006 12:45:48 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C348@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <8812D8156467224C9E9739E513037EF12A157F@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Equal Access (was I-D draft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAA6AVFAABADk0A== From: "Dolly, Martin C, ALABS" To: "Medhavi Bhatia" , "Stastny Richard" , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b 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 Hello, If this is a requirement, is it not a regional SDO requirement, and therefore, should be an input requirement from one of those regional SDOs? Cheers, Martin > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Friday, March 03, 2006 12:44 PM > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > Subject: [Speermint] RE: Equal Access (was > I-Ddraft-bhatia-sip-peering-00.txt) >=20 >=20 > > This raises may questions such as: > > if you are able to unbundle your access and are > > able to choose another DSL provider, to you still > > need carrier selection? >=20 > My personal opinion is that it may not be not required for=20 > the case you > have above. I think for the WG purposes, the solution we come with for > the Interconnect SP problem (in the other thread we have on=20 > the WG list) > may also be used to solve this. An Access SP or Core SP which needs to > provide this to the subscriber for whatever reason treats the=20 > LD carrier > as an Interconnect SP. The LD Carrier will need to do another=20 > lookup to > get to Core-T (which may be same as Core-O in this case).=20 >=20 > >=20 > > Is carrier selection only valid for voice and voice > > related services, especially if the selected carrier > > still has only access via the PSTN? What if you switch > > during a call to video? > >=20 > > What does carrier selection imply with IP Interconnect? > > L5 Interconnect or also L3 transit? > >=20 > > A very nice example is if Core-O and Core-T is the > > same, e.g. running on the same server, > > do you still have to provide carrier selection > > if the call is now forced via the PSTN? > >=20 >=20 > This scenario may exist. I have heard about it as a=20 > requirement in some > VoIP deployments. >=20 > Medhavi. >=20 > > Etc. etc. > >=20 > > Cheers > >=20 > > Richard > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Thursday, March 02, 2006 11:03 PM > > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > Hi Richard, > > > > > > Sorry about the headache... > > > Hopefully my answers below will help :) > > > Thanks for the quick read anyway. > > > > > > Cheers, > > > Medhavi. > > > > > > > > > > > >The purpose of this document is to help the IETF community > > understand > > > > > > > > > the route architectures being used today in SIP=20 > based peering > > > > > > > > > environments and to outline a set of requirements=20 > based on the > > > same > > > > > > > > > for discussion within the community > > > > > > > > > > > > > > > > Is this IMS in stealth mode? > > > > > > The intent of the draft is to describe what is deployed and the > > > requirements driving that. We can choose to ignore or=20 > accept some of > > > them based on WG discussion. > > > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > > > > > The purpose of this draft is to help the IETF community=20 > understand > > IMS > > > .. > > > > > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > > "Origination" in this document) and terminates at called party > "T" > > > > (called the "Termination" in this document). T may be a > > subscriber, > > > > contact center, E911 operator etc. The first hop and the last > hop > > > of > > > > the call in Figure 1 pass through SPs providing L5=20 > (in our case > > SIP) > > > > access to the origination and termination and are called > Access-O > > > and > > > > Access-T respectively. In most cases these SPs will also > provide > > > the > > > > physical access to the origination and termination=20 > devices. The > > > > Access SP function is not optional. While a separate=20 > Access SP > > may > > > > not exist, the function may be absorbed by the corresponding > Core > > > SP." > > > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > > access > > > > by itself? In L5? > > > > > > > > > > It says three things: (a) Access SP is mandatory (b)=20 > Access SP "may" > > > provide > > > physical access (c) Access SP can be absorbed within the Core SP. > > Maybe > > > the > > > language can be improved, but I think we capture the case you are > > > talking > > > about - an ASP (Vonage) like scenario! > > > > > > > And then we also have Interconnect SP =3D Transit > > > > > > > > What happened to the SIP Trapeziod? > > > > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > > (first > > > para on pg 4). > > > However, I think there could be a special section devoted to that. > > Note > > > that in no way > > > the draft is supposed to be prescriptive or designed to ignore the > > > trapezoid. Sorry if it sounds > > > confusing - we can fix that problem... > > > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > > defined > > > in requirements > > > draft. > > > > > > > and may I remember on the req draft > > > > > > > > "3.6.2. Layer 5 Peering > > > > > > > > Layer 5 peering refers to interconnection of two service > > providers > > > > for the purposes of SIP signaling. Note that in the layer 5 > > > peering > > > > case, there is no intervening network. That is, for purposes > of > > > this > > > > discussion, there is no such thing as a "Layer 5 Transit > > Network"." > > > > > > > > The next problem I have with section > > > > > > > > > > I think maybe the draft needs to clarify that=20 > Interconnect SP is not > > the > > > same as Transit. > > > We can try to do this if lot of people feel the same and it really > > > affects the routing > > > architecture selection (IMHO - it should not have any=20 > effect) in the > > > end. > > > > > > > > > > > > > > > "5.2. Addressing > > > > > > > > The type of A-O-R for the termination may also=20 > affect what kind > > of > > > > address location service is used. Address location is done > > > typically > > > > based on the following four characteristics of the > termination's > > > AOR. > > > > In each case, we list the most common address location method > > used. > > > > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > > 2. E.164 prefixes: SPs local policy is generally used. > > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > > environment. > > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may=20 > be used." > > > > > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > > > E.164 numbers are names > > > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > > > > I am not sure what I need to fix, but we can address it after WG > > > discussion. > > > > > > > > > > > And IMHO completely off is the idea to introduce > > > > carrier selection within VoIP > > > > > > > > " For example Equal Access is > > > > a LEC (Local Exchange Carrier) requirement and an SP=20 > operating > as > > > an > > > > LEC may be required to allow the subscriber his/her choice of > IXC > > > > (IntereXchange Carrier) for certain set of calls. =20 > In essence, > > > these > > > > requirements may affect route policy for peering where the > > > downstream > > > > peer is chosen based on origination's policy. In this case, > the > > > > Core-O and Core-T may be one and the same SP who peer through > an > > > > Interconnect SP of the origination's choice." > > > > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I > think > > it > > > is good to know what some VoIP SPs are dealing with=20 > especially when > we > > > are starting discussions in the WG. As the draft says in the last > > para > > > - it is > > > possible that this may affect only a minor set of=20 > deployments in the > > > end. Time > > > will tell. Also, Equal Access is simply an example (I=20 > can't promise > if > > > there > > > are not a host of other scenarios out there). > > > > > > Thanks, > > > Medhavi. > > > > > > > > > > > > > I have an headache > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > > Gesendet: Do 02.03.2006 19:33 > > > > An: speermint@ietf.org > > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > FYI for the WG on this draft. This is on the tentative=20 > agenda at > > the > > > Dallas meeting (should > > > > be finalized shortly). > > > > > > > > Jason > > > > > > > > ________________________________ > > > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > > Sent: Sunday, February 26, 2006 12:44 AM > > > > To: internet-drafts@ietf.org > > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > > > > > Abstract > > > > > > > > > > > > > > > > The purpose of this document is to help the IETF community > > > understand > > > > > > > > the route architectures being used today in SIP based peering > > > > > > > > environments and to outline a set of requirements=20 > based on the > > same > > > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > -- > > > > No virus found in this incoming message. > > > > Checked by AVG Free Edition. > > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > > 3/1/2006 > > > > > >=20 > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > 3/1/2006 > >=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 Sun Mar 05 04:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFq0t-00013B-PZ; Sun, 05 Mar 2006 04:58:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFq0r-0000vf-L8 for speermint@ietf.org; Sun, 05 Mar 2006 04:58:53 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFq0o-0008VP-Nn for speermint@ietf.org; Sun, 05 Mar 2006 04:58:53 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IVN00401FLH0H@siemenscomms.co.uk> for speermint@ietf.org; Sun, 05 Mar 2006 09:56:05 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IVN00G7QFLG7Q@siemenscomms.co.uk>; Sun, 05 Mar 2006 09:56:05 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 05 Mar 2006 09:58:48 +0000 Content-return: allowed Date: Sun, 05 Mar 2006 09:58:47 +0000 From: "Elwell, John" Subject: RE: [Speermint] RE: Enterprise Peering [was Re: Intercon SP...] To: Stastny Richard , Bob Natale Message-id: <50B1CBA96870A34799A506B2313F2667083B4668@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 64b72a8e61417554b4b727cb14e7034d Cc: speermint@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 Richard, Yes, and in the peering case the main difference between an enterprise as SP and a carrier as SP is that the enterprise SP provides service only to a limited community of users (e.g., within an organisation), rather than to the general public, and hence different regulatory considerations apply. Otherwise it has very similar technical characteristics. John > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 03 March 2006 14:57 > To: Bob Natale > Cc: speermint@ietf.org > Subject: [Speermint] RE: Enterprise Peering [was Re: Intercon SP...] > > Hi Bob, > > > I had the same thought when I first read Medhavi's draft, but then > > concluded that, from the architectural context outlined in > that draft, > > the "Enterprise Peering" case was simply an instance of "Direct > Peering" > > between "Core SPs". > > I fear this is not so simple. > > First we have to clarify if an enterprise can be a > core SP on its own and what are the minimum requirements > to be one. > > Second, we also need to consider that some enterprises > (e.g. small ones) do not want to be a core SP on its > own. > > ECMA (dealing in Europe with PBX issues (they specified > e.g. QSIG) presented at the last ETSI TISPAN meeting > their view on Next Generation Corporate Networks (NGCN) > > They presented five scenarios, containing everything between > direct peering and using SP for interconnect > > Of course the also want both: some traffic is exchanged > via direct peering (e.g. within the enterprise and also > within federations, some traffic is going via Core-SPs > > So I think we have to use both models: an NGCN as > core -SP and also an NGCN connected via access SP and > core SP > > Cheers > > Richard > > > -----Original Message----- > > From: Bob Natale [mailto:bnatale@nextone.com] > > Sent: Friday, March 03, 2006 3:09 PM > > To: Stastny Richard > > Cc: speermint@ietf.org > > Subject: Enterprise Peering [was Re: Intercon SP...] > > > > Hi Richard: > > > > Concerning your observation (below): > > "Additional remark: what is missing in your scenario is the > connection > > of enterprises, that is Os and Ts having networks and > proxies on their > > own." > > > > I had the same thought when I first read Medhavi's draft, but then > > concluded that, from the architectural context outlined in > that draft, > > the "Enterprise Peering" case was simply an instance of "Direct > Peering" > > between "Core SPs". > > > > If that is an accurate and acceptable interpretation, then we could > > address any functional or operational differences for the enterprise > > case in the Requirements BCP. (Currently I anticipate the need for > some > > degree of differentiation even if only any two or more of Access SP, > > Interconnect SP (by whatever name), and Core SP remain valid via WG > > consensus.) > > > > Cheers, > > BobN > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, March 03, 2006 4:41 AM > > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > > Subject: [Speermint] Intercon SP (was I-D > > draft-bhatia-sip-peering-00.txt) > > > > > > > > I think maybe the draft needs to clarify that > Interconnect SP is not > > the > > > same as Transit. > > > We can try to do this if lot of people feel the same and it really > > > affects the routing architecture selection (IMHO - it should not > have > > > any effect) in the end. > > > > I agree that we need to discuss this and clarify (which will not be > easy > > ;-) > > > > I know that currently Interconnect SP (on L5) are existing and > providing > > a kind of clearing house function regarding call routing (some also > > provide ENUM) and also providing policy services. > > > > Some also provide L3 transit, some not. > > > > To complicate issues further, some work as proxies (as in > your Figure > > 1), some as redirect servers. > > > > GSMA is planning to introduce such Intercon proxies within their > GRX/IPX > > network (called hub/IPX proxies) (Note GRX/IPX is also always a > > mediastream transit network) > > > > Additional remark: what is missing in your scenario is the > connection > of > > enterprises, that is Os and Ts having networks and proxies on their > own. > > > > Back to ENUM: > > > > There is an additional problem lurking in these complicated > scenarios > (I > > am somewhat referring back here to my previous e-mail on phone > numbers) > > > > The assumption in User ENUM is that you get back the AoR > out of ENUM = > > the Core-T the user defined to provide VoIP services for him (not > > necessarily the provider hosting the number) > > > > The assumption in Infrastructure ENUM (as currently defined in ENUM > WG, > > not private ENUMs) that you get back either also the AoR of the SP > > provider hosting the number, which is translated with SRV and DNS to > the > > ingress border element of the Core-T, or directly the > ingress element > > > > This is ok if Core-O is querying Infrastructure ENUM and no Intercon > is > > involved > > > > So what is the mechanism to involve an Intercon SP? > > > > One scenario I could imagine is the following A Core-O is querying > > Infrastructure ENUM, but finds out via the policy records > that he has > no > > direct peering with the Core-T. > > > > He may now forward the call to an Intercon SP which is providing > > connectivity to the Core-T. He may have some choices. > > > > How is the Intercon SP announcing which Core-Ts he is able to > terminate? > > > > This could of course be done by the Core-T in the policy records > giving > > the Intercon SP in his federation list. > > > > The question I have now is does the Core-O provider signal to the > > Intercon already the information derived from Infrastructure ENUM (= > the > > Core-T URI) or does he give again the E.164 number and the > Intercon SP > > is querying Infrastructure ENUM again. > > > > This may not sound complicated if we assume only one global > > Infrastructure ENUM, but if we take into account that we may also > > interwork with private ENUMs? > > > > Example: > > > > GSMA decides to be reachable also from the Internet, but in public > > Infrastructure ENUM only the ingress border elements from IPX are > > entered. This requires a second ENUM query within IPX, which in turn > > requires the original > > E.164 number to be kept. > > > > Since I am currently also dealing with the header field nightmare in > SIP > > and IMS, we may need to make the e.g. P-Called-Party-ID Header from > RFC > > 3455 mandatory. > > > > Cheers > > > > Richard > > > > > > > > > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Thursday, March 02, 2006 11:03 PM > > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > Hi Richard, > > > > > > Sorry about the headache... > > > Hopefully my answers below will help :) Thanks for the quick read > > > anyway. > > > > > > Cheers, > > > Medhavi. > > > > > > > > > > > >The purpose of this document is to help the IETF community > > understand > > > > > > > > > the route architectures being used today in SIP > based peering > > > > > > > > > environments and to outline a set of requirements > based on the > > > same > > > > > > > > > for discussion within the community > > > > > > > > > > > > > > > > Is this IMS in stealth mode? > > > > > > The intent of the draft is to describe what is deployed and the > > > requirements driving that. We can choose to ignore or > accept some of > > > them based on WG discussion. > > > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > > > > > The purpose of this draft is to help the IETF community > understand > > IMS > > > .. > > > > > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > > "Origination" in this document) and terminates at called party > "T" > > > > (called the "Termination" in this document). T may be a > > subscriber, > > > > contact center, E911 operator etc. The first hop and the last > hop > > > of > > > > the call in Figure 1 pass through SPs providing L5 > (in our case > > SIP) > > > > access to the origination and termination and are called > Access-O > > > and > > > > Access-T respectively. In most cases these SPs will also > provide > > > the > > > > physical access to the origination and termination > devices. The > > > > Access SP function is not optional. While a separate > Access SP > > may > > > > not exist, the function may be absorbed by the corresponding > Core > > > SP." > > > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > > access > > > > by itself? In L5? > > > > > > > > > > It says three things: (a) Access SP is mandatory (b) > Access SP "may" > > > provide > > > physical access (c) Access SP can be absorbed within the Core SP. > > Maybe > > > the > > > language can be improved, but I think we capture the case you are > > > talking about - an ASP (Vonage) like scenario! > > > > > > > And then we also have Interconnect SP = Transit > > > > > > > > What happened to the SIP Trapeziod? > > > > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > > (first > > > para on pg 4). > > > However, I think there could be a special section devoted to that. > > Note > > > that in no way > > > the draft is supposed to be prescriptive or designed to ignore the > > > trapezoid. Sorry if it sounds confusing - we can fix that > problem... > > > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > > defined > > > in requirements > > > draft. > > > > > > > and may I remember on the req draft > > > > > > > > "3.6.2. Layer 5 Peering > > > > > > > > Layer 5 peering refers to interconnection of two service > > providers > > > > for the purposes of SIP signaling. Note that in the layer 5 > > > peering > > > > case, there is no intervening network. That is, for purposes > of > > > this > > > > discussion, there is no such thing as a "Layer 5 Transit > > Network"." > > > > > > > > The next problem I have with section > > > > > > > > > > I think maybe the draft needs to clarify that > Interconnect SP is not > > the > > > same as Transit. > > > We can try to do this if lot of people feel the same and it really > > > affects the routing architecture selection (IMHO - it should not > have > > > any effect) in the end. > > > > > > > > > > > > > > > "5.2. Addressing > > > > > > > > The type of A-O-R for the termination may also > affect what kind > > of > > > > address location service is used. Address location is done > > > typically > > > > based on the following four characteristics of the > termination's > > > AOR. > > > > In each case, we list the most common address location method > > used. > > > > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > > 2. E.164 prefixes: SPs local policy is generally used. > > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > > environment. > > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may > be used." > > > > > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > > > E.164 numbers are names > > > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > > > > I am not sure what I need to fix, but we can address it after WG > > > discussion. > > > > > > > > > > > And IMHO completely off is the idea to introduce > carrier selection > > > > within VoIP > > > > > > > > " For example Equal Access is > > > > a LEC (Local Exchange Carrier) requirement and an SP > operating > as > > > an > > > > LEC may be required to allow the subscriber his/her choice of > IXC > > > > (IntereXchange Carrier) for certain set of calls. > In essence, > > > these > > > > requirements may affect route policy for peering where the > > > downstream > > > > peer is chosen based on origination's policy. In this case, > the > > > > Core-O and Core-T may be one and the same SP who peer through > an > > > > Interconnect SP of the origination's choice." > > > > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I > think > > it > > > is good to know what some VoIP SPs are dealing with > especially when > we > > > > > are starting discussions in the WG. As the draft says in the last > > para > > > - it is > > > possible that this may affect only a minor set of > deployments in the > > > end. Time will tell. Also, Equal Access is simply an example (I > can't > > > promise if there are not a host of other scenarios out there). > > > > > > Thanks, > > > Medhavi. > > > > > > > > > > > > > I have an headache > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > > Gesendet: Do 02.03.2006 19:33 > > > > An: speermint@ietf.org > > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > FYI for the WG on this draft. This is on the tentative > agenda at > > the > > > Dallas meeting (should > > > > be finalized shortly). > > > > > > > > Jason > > > > > > > > ________________________________ > > > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > > Sent: Sunday, February 26, 2006 12:44 AM > > > > To: internet-drafts@ietf.org > > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > > > > > Abstract > > > > > > > > > > > > > > > > The purpose of this document is to help the IETF community > > > understand > > > > > > > > the route architectures being used today in SIP based peering > > > > > > > > environments and to outline a set of requirements > based on the > > same > > > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > -- > > > > No virus found in this incoming message. > > > > Checked by AVG Free Edition. > > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > > 3/1/2006 > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Mar 06 17:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOEJ-0008P4-L9; Mon, 06 Mar 2006 17:31:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOEH-0008NG-BB for speermint@ietf.org; Mon, 06 Mar 2006 17:31:01 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNNB-0008EU-OZ for speermint@ietf.org; Mon, 06 Mar 2006 16:36:09 -0500 Received: from outbound-haw.frontbridge.com ([12.129.219.97] helo=outbound3-haw-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGMyr-0004wD-N4 for speermint@ietf.org; Mon, 06 Mar 2006 16:11:03 -0500 Received: from outbound3-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-haw-R.bigfish.com (Postfix) with ESMTP id 12A93143CADA for ; Mon, 6 Mar 2006 21:11:01 +0000 (UTC) Received: from mail36-haw-R.bigfish.com (unknown [192.168.51.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound3-haw.bigfish.com (Postfix) with ESMTP id 1042D143CAC3 for ; Mon, 6 Mar 2006 21:11:01 +0000 (UTC) Received: from mail36-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail36-haw-R.bigfish.com (Postfix) with ESMTP id EE98D42346D for ; Mon, 6 Mar 2006 21:11:00 +0000 (UTC) X-BigFish: V Received: by mail36-haw (MessageSwitch) id 1141679460866486_23946; Mon, 6 Mar 2006 21:11:00 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail36-haw.bigfish.com (Postfix) with ESMTP id B6F6D415961 for ; Mon, 6 Mar 2006 21:11:00 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k26LAxMX028512 for ; Mon, 6 Mar 2006 15:11:00 -0600 (CST) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k26LAx910249 for ; Mon, 6 Mar 2006 15:10:59 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 15:10:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Mar 2006 15:10:57 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E06049D61@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-khan-ip-serv-peer-arch-00.txt Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAYuVRQAA9wzBAAAviA2gCd3X5g From: "Khan, Sohel Q [CTO]" To: X-OriginalArrivalTime: 06 Mar 2006 21:10:59.0359 (UTC) FILETIME=[7777FAF0:01C64162] X-Spam-Score: -2.6 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Speermint] I-D ACTION:draft-khan-ip-serv-peer-arch-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 Please note that this draft has slightly different definition of a Service Provider. Please provide comment. I-D ACTION:draft-khan-ip-serv-peer-arch-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Service (Voice and Multimedia) Peering Architecture Author(s) : S. Khan Filename : draft-khan-ip-serv-peer-arch-00.txt Pages : 7 Date : 2006-3-3 =09 This document pictorially depicts IP Service (Voice + Multimedia) provider network functional components, peering interface functions, and an IP Service (VM) providers? peering reference architecture. The draft also calls for developing separate requirements for different types of peering.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-khan-ip-serv-peer-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-khan-ip-serv-peer-arch-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Mar 07 14:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGiKe-00022c-46; Tue, 07 Mar 2006 14:58:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGiKc-00021J-V1 for speermint@ietf.org; Tue, 07 Mar 2006 14:58:54 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGiKa-0000WH-7m for speermint@ietf.org; Tue, 07 Mar 2006 14:58:54 -0500 Received: from ([10.52.116.10]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.17475163; Tue, 07 Mar 2006 14:58:31 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 14:58:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] wg-business: Draft IETF 65 Agenda Date: Tue, 7 Mar 2006 14:58:30 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A4B1@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] wg-business: Draft IETF 65 Agenda Thread-Index: AcYuVzDueBeIXn7ARwKNsvLbjhodcgE1H20gACgipbAAlkokMAL/AhPw From: "Livingood, Jason" To: X-OriginalArrivalTime: 07 Mar 2006 19:58:30.0907 (UTC) FILETIME=[82009CB0:01C64221] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Here is the latest (and should be final) agenda for Dallas. http://www3.ietf.org/proceedings/06mar/agenda/speermint.txt Regards Dave & Jason=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Monday, February 20, 2006 8:57 AM > To: speermint@ietf.org > Subject: RE: [Speermint] wg-business: Draft IETF 65 Agenda >=20 > Our WG has been tentatively schedule on Monday afternoon. =20 > This is not yet confirmed, as the IETF 65 agenda is still in=20 > draft form (see http://www.ietf.org/meetings/agenda_65.txt). >=20 > MONDAY, March 20, 2006 > 1520-1720 Afternoon Session II >=20 > http://www3.ietf.org/proceedings/06mar/agenda/speermint.txt >=20 > Regards > Dave & Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 08 09:39:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzon-0002Dd-MS; Wed, 08 Mar 2006 09:39:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzom-0002DS-ER for speermint@ietf.org; Wed, 08 Mar 2006 09:39:12 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGzol-0003hd-1x for speermint@ietf.org; Wed, 08 Mar 2006 09:39:12 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k28EdAIB001434 for ; Wed, 8 Mar 2006 06:39:10 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k28EdAF4001433 for speermint@ietf.org; Wed, 8 Mar 2006 06:39:10 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 8 Mar 2006 06:39:10 -0800 From: David Meyer To: speermint@ietf.org Message-ID: <20060308143910.GA1413@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: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Speermint] Speermint agenda slides for IETF 65 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="===============1306127771==" Errors-To: speermint-bounces@ietf.org --===============1306127771== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Check out http://www.1-4-5.net/~dmm/IETF/IETF65/speermint Reflects the agenda Jason posted. Dave --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEDuyOORgD1qCZ2KcRAggEAJ9ekm4P/sLVCFJRVqyGkUZf0y7Y+wCfbZAu iEf+qL5OuR6op8BL2YwZlrY= =xuKg -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- --===============1306127771== 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 --===============1306127771==-- From speermint-bounces@ietf.org Wed Mar 08 12:32:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2Wr-0001G6-UT; Wed, 08 Mar 2006 12:32:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2Wr-0001FJ-Ae for speermint@ietf.org; Wed, 08 Mar 2006 12:32:53 -0500 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound2-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2Wq-0001JI-1F for speermint@ietf.org; Wed, 08 Mar 2006 12:32:53 -0500 Received: from outbound2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-res-R.bigfish.com (Postfix) with ESMTP id D445C3B8605; Wed, 8 Mar 2006 17:32:51 +0000 (UTC) Received: from mail45-res-R.bigfish.com (unknown [172.18.16.1]) by outbound2-res.bigfish.com (Postfix) with ESMTP id D320F3B7AA6; Wed, 8 Mar 2006 17:32:51 +0000 (UTC) Received: from mail45-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail45-res-R.bigfish.com (Postfix) with ESMTP id C744361A979; Wed, 8 Mar 2006 17:32:51 +0000 (UTC) X-BigFish: V Received: by mail45-res (MessageSwitch) id 1141839171673894_27896; Wed, 8 Mar 2006 17:32:51 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail45-res.bigfish.com (Postfix) with ESMTP id 87D4861A83B; Wed, 8 Mar 2006 17:32:51 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k28HWoMX014886; Wed, 8 Mar 2006 11:32:50 -0600 (CST) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k28HWnp18170; Wed, 8 Mar 2006 11:32:49 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 11:32:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Mar 2006 11:32:48 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E061019F9@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft-wing-session-auth-00: Media Session Authorization Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YA From: "Khan, Sohel Q [CTO]" To: , X-OriginalArrivalTime: 08 Mar 2006 17:32:49.0284 (UTC) FILETIME=[52008C40:01C642D6] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Speermint] Draft-wing-session-auth-00: Media Session Authorization 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 =20 Given that propagation delay added for so much end to end signaling/control message flows, would it be possible to shorten flows of Figure 7 by eliminating messages (10 to 13) and combining messages (9) and (14) together? If so, what are the implications of such elimination? Thank you. Sohel Khan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 08 12:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2jW-0005hG-US; Wed, 08 Mar 2006 12:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2jV-0005hB-Jn for speermint@ietf.org; Wed, 08 Mar 2006 12:45:57 -0500 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound2-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2jU-0001zB-Cp for speermint@ietf.org; Wed, 08 Mar 2006 12:45:57 -0500 Received: from outbound2-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-ash-R.bigfish.com (Postfix) with ESMTP id 5112C5BA895; Wed, 8 Mar 2006 17:45:56 +0000 (UTC) Received: from mail57-ash-R.bigfish.com (unknown [172.18.2.1]) by outbound2-ash.bigfish.com (Postfix) with ESMTP id 4FE525BA888; Wed, 8 Mar 2006 17:45:56 +0000 (UTC) Received: from mail57-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail57-ash-R.bigfish.com (Postfix) with ESMTP id 467F164B4D5; Wed, 8 Mar 2006 17:45:56 +0000 (UTC) X-BigFish: V Received: by mail57-ash (MessageSwitch) id 1141839956186801_3307; Wed, 8 Mar 2006 17:45:56 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail57-ash.bigfish.com (Postfix) with ESMTP id 0FBF364B4C1; Wed, 8 Mar 2006 17:45:56 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k28Hjt3D022511; Wed, 8 Mar 2006 11:45:55 -0600 (CST) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k28HjtH06349; Wed, 8 Mar 2006 11:45:55 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 11:45:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Mar 2006 11:45:53 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E06101A3F@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft-bhatia-sip-peering-00.txt Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAAB5oiA= From: "Khan, Sohel Q [CTO]" To: , X-OriginalArrivalTime: 08 Mar 2006 17:45:55.0070 (UTC) FILETIME=[265DF9E0:01C642D8] X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Speermint] Draft-bhatia-sip-peering-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 =20 Good draft. Couple of points: Chapter 2: I think a Service Provider can be an application provider, SIP transport and processing provider, media transport and processing provider ... (please see the definition in draft-khan-ip-serv-peer-arch-00.txt) Application SP: =20 I was thinking application SP as a application or content provider. Chapter 3: Instead of using term {O} or {T}, would it be possible to use UA-O and UA-T? Instead of "T may be a subscriber, contact center, E911 operator etc.", can we rewrite,=20 "T may be a subscriber, contact center, E911 operator, application server etc." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 08 16:24:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH698-0006kt-9H; Wed, 08 Mar 2006 16:24:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH697-0006kV-Hl for speermint@ietf.org; Wed, 08 Mar 2006 16:24:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH696-0007Ve-Ln for speermint@ietf.org; Wed, 08 Mar 2006 16:24:37 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2006 13:24:35 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="260555613:sNHT5378475026" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k28LOSYq002737; Wed, 8 Mar 2006 13:24:31 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 16:24:19 -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] RE: Enterprise Peering [was Re: Intercon SP...] Date: Wed, 8 Mar 2006 16:24:18 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3013145B7@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Enterprise Peering [was Re: Intercon SP...] Thread-Index: AcZAO4Ek0FwN4c1fRCy8QkzMtfQIWACuxfIA From: "Michael Hammer \(mhammer\)" To: "Elwell, John" , "Stastny Richard" , "Bob Natale" X-OriginalArrivalTime: 08 Mar 2006 21:24:19.0746 (UTC) FILETIME=[A95CD820:01C642F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bd14a31ed5bce9138736cf0e98bb014 Cc: speermint@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 Unless, of course your enterprise is higher education. :) Mike =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Sunday, March 05, 2006 4:59 AM > To: Stastny Richard; Bob Natale > Cc: speermint@ietf.org > Subject: RE: [Speermint] RE: Enterprise Peering [was Re:=20 > Intercon SP...] >=20 > Richard, >=20 > Yes, and in the peering case the main difference between an=20 > enterprise as SP and a carrier as SP is that the enterprise=20 > SP provides service only to a limited community of users=20 > (e.g., within an organisation), rather than to the general=20 > public, and hence different regulatory considerations apply. > Otherwise it has very similar technical characteristics. >=20 > John >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: 03 March 2006 14:57 > > To: Bob Natale > > Cc: speermint@ietf.org > > Subject: [Speermint] RE: Enterprise Peering [was Re: Intercon SP...] > >=20 > > Hi Bob, > >=20 > > > I had the same thought when I first read Medhavi's draft,=20 > but then=20 > > > concluded that, from the architectural context outlined in > > that draft, > > > the "Enterprise Peering" case was simply an instance of "Direct > > Peering" > > > between "Core SPs". > >=20 > > I fear this is not so simple. > >=20 > > First we have to clarify if an enterprise can be a core SP=20 > on its own=20 > > and what are the minimum requirements to be one. > >=20 > > Second, we also need to consider that some enterprises (e.g. small=20 > > ones) do not want to be a core SP on its own. > >=20 > > ECMA (dealing in Europe with PBX issues (they specified e.g. QSIG)=20 > > presented at the last ETSI TISPAN meeting their view on Next=20 > > Generation Corporate Networks (NGCN) > >=20 > > They presented five scenarios, containing everything between direct=20 > > peering and using SP for interconnect > >=20 > > Of course the also want both: some traffic is exchanged via direct=20 > > peering (e.g. within the enterprise and also within=20 > federations, some=20 > > traffic is going via Core-SPs > >=20 > > So I think we have to use both models: an NGCN as core -SP=20 > and also an=20 > > NGCN connected via access SP and core SP > >=20 > > Cheers > >=20 > > Richard > >=20 > > > -----Original Message----- > > > From: Bob Natale [mailto:bnatale@nextone.com] > > > Sent: Friday, March 03, 2006 3:09 PM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: Enterprise Peering [was Re: Intercon SP...] > > >=20 > > > Hi Richard: > > >=20 > > > Concerning your observation (below): > > > "Additional remark: what is missing in your scenario is the > > connection > > > of enterprises, that is Os and Ts having networks and > > proxies on their > > > own." > > >=20 > > > I had the same thought when I first read Medhavi's draft,=20 > but then=20 > > > concluded that, from the architectural context outlined in > > that draft, > > > the "Enterprise Peering" case was simply an instance of "Direct > > Peering" > > > between "Core SPs". > > >=20 > > > If that is an accurate and acceptable interpretation,=20 > then we could=20 > > > address any functional or operational differences for the=20 > enterprise=20 > > > case in the Requirements BCP. (Currently I anticipate=20 > the need for > > some > > > degree of differentiation even if only any two or more of=20 > Access SP,=20 > > > Interconnect SP (by whatever name), and Core SP remain=20 > valid via WG > > > consensus.) > > >=20 > > > Cheers, > > > BobN > > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Friday, March 03, 2006 4:41 AM > > > To: Medhavi Bhatia; Livingood, Jason; speermint@ietf.org > > > Subject: [Speermint] Intercon SP (was I-D > > > draft-bhatia-sip-peering-00.txt) > > >=20 > > > > > > > > I think maybe the draft needs to clarify that > > Interconnect SP is not > > > the > > > > same as Transit. > > > > We can try to do this if lot of people feel the same=20 > and it really=20 > > > > affects the routing architecture selection (IMHO - it should not > > have > > > > any effect) in the end. > > >=20 > > > I agree that we need to discuss this and clarify (which=20 > will not be > > easy > > > ;-) > > >=20 > > > I know that currently Interconnect SP (on L5) are existing and > > providing > > > a kind of clearing house function regarding call routing=20 > (some also=20 > > > provide ENUM) and also providing policy services. > > >=20 > > > Some also provide L3 transit, some not. > > >=20 > > > To complicate issues further, some work as proxies (as in > > your Figure > > > 1), some as redirect servers. > > >=20 > > > GSMA is planning to introduce such Intercon proxies within their > > GRX/IPX > > > network (called hub/IPX proxies) (Note GRX/IPX is also always a=20 > > > mediastream transit network) > > >=20 > > > Additional remark: what is missing in your scenario is the > > connection > > of > > > enterprises, that is Os and Ts having networks and=20 > proxies on their > > own. > > >=20 > > > Back to ENUM: > > >=20 > > > There is an additional problem lurking in these complicated > > scenarios > > (I > > > am somewhat referring back here to my previous e-mail on phone > > numbers) > > >=20 > > > The assumption in User ENUM is that you get back the AoR > > out of ENUM =3D > > > the Core-T the user defined to provide VoIP services for him (not=20 > > > necessarily the provider hosting the number) > > >=20 > > > The assumption in Infrastructure ENUM (as currently=20 > defined in ENUM > > WG, > > > not private ENUMs) that you get back either also the AoR=20 > of the SP=20 > > > provider hosting the number, which is translated with SRV=20 > and DNS to > > the > > > ingress border element of the Core-T, or directly the > > ingress element > > >=20 > > > This is ok if Core-O is querying Infrastructure ENUM and=20 > no Intercon > > is > > > involved > > >=20 > > > So what is the mechanism to involve an Intercon SP? > > >=20 > > > One scenario I could imagine is the following A Core-O is=20 > querying=20 > > > Infrastructure ENUM, but finds out via the policy records > > that he has > > no > > > direct peering with the Core-T. > > >=20 > > > He may now forward the call to an Intercon SP which is providing=20 > > > connectivity to the Core-T. He may have some choices. > > >=20 > > > How is the Intercon SP announcing which Core-Ts he is able to > > terminate? > > >=20 > > > This could of course be done by the Core-T in the policy records > > giving > > > the Intercon SP in his federation list. > > >=20 > > > The question I have now is does the Core-O provider signal to the=20 > > > Intercon already the information derived from=20 > Infrastructure ENUM (=3D > > the > > > Core-T URI) or does he give again the E.164 number and the > > Intercon SP > > > is querying Infrastructure ENUM again. > > >=20 > > > This may not sound complicated if we assume only one global=20 > > > Infrastructure ENUM, but if we take into account that we may also=20 > > > interwork with private ENUMs? > > >=20 > > > Example: > > >=20 > > > GSMA decides to be reachable also from the Internet, but=20 > in public=20 > > > Infrastructure ENUM only the ingress border elements from IPX are=20 > > > entered. This requires a second ENUM query within IPX,=20 > which in turn=20 > > > requires the original > > > E.164 number to be kept. > > >=20 > > > Since I am currently also dealing with the header field=20 > nightmare in > > SIP > > > and IMS, we may need to make the e.g. P-Called-Party-ID=20 > Header from > > RFC > > > 3455 mandatory. > > >=20 > > > Cheers > > >=20 > > > Richard > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > > Sent: Thursday, March 02, 2006 11:03 PM > > > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > Hi Richard, > > > > > > > > Sorry about the headache... > > > > Hopefully my answers below will help :) Thanks for the=20 > quick read=20 > > > > anyway. > > > > > > > > Cheers, > > > > Medhavi. > > > > > > > > > > > > > > >The purpose of this document is to help the IETF community > > > understand > > > > > > > > > > > the route architectures being used today in SIP > > based peering > > > > > > > > > > > environments and to outline a set of requirements > > based on the > > > > same > > > > > > > > > > > for discussion within the community > > > > > > > > > > > > > > > > > > > > Is this IMS in stealth mode? > > > > > > > > The intent of the draft is to describe what is deployed and the=20 > > > > requirements driving that. We can choose to ignore or > > accept some of > > > > them based on WG discussion. > > > > > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > > > > > > > > > The purpose of this draft is to help the IETF community > > understand > > > IMS > > > > .. > > > > > > > > > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > > > "Origination" in this document) and terminates at=20 > called party > > "T" > > > > > (called the "Termination" in this document). T may be a > > > subscriber, > > > > > contact center, E911 operator etc. The first hop=20 > and the last > > hop > > > > of > > > > > the call in Figure 1 pass through SPs providing L5 > > (in our case > > > SIP) > > > > > access to the origination and termination and are called > > Access-O > > > > and > > > > > Access-T respectively. In most cases these SPs will also > > provide > > > > the > > > > > physical access to the origination and termination > > devices. The > > > > > Access SP function is not optional. While a separate > > Access SP > > > may > > > > > not exist, the function may be absorbed by the corresponding > > Core > > > > SP." > > > > > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > > > access > > > > > by itself? In L5? > > > > > > > > > > > > > It says three things: (a) Access SP is mandatory (b) > > Access SP "may" > > > > provide > > > > physical access (c) Access SP can be absorbed within=20 > the Core SP. > > > Maybe > > > > the > > > > language can be improved, but I think we capture the=20 > case you are=20 > > > > talking about - an ASP (Vonage) like scenario! > > > > > > > > > And then we also have Interconnect SP =3D Transit > > > > > > > > > > What happened to the SIP Trapeziod? > > > > > > > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > > > (first > > > > para on pg 4). > > > > However, I think there could be a special section=20 > devoted to that. > > > Note > > > > that in no way > > > > the draft is supposed to be prescriptive or designed to=20 > ignore the=20 > > > > trapezoid. Sorry if it sounds confusing - we can fix that > > problem... > > > > > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > > > defined > > > > in requirements > > > > draft. > > > > > > > > > and may I remember on the req draft > > > > > > > > > > "3.6.2. Layer 5 Peering > > > > > > > > > > Layer 5 peering refers to interconnection of two service > > > providers > > > > > for the purposes of SIP signaling. Note that in=20 > the layer 5 > > > > peering > > > > > case, there is no intervening network. That is,=20 > for purposes > > of > > > > this > > > > > discussion, there is no such thing as a "Layer 5 Transit > > > Network"." > > > > > > > > > > The next problem I have with section > > > > > > > > > > > > > I think maybe the draft needs to clarify that > > Interconnect SP is not > > > the > > > > same as Transit. > > > > We can try to do this if lot of people feel the same=20 > and it really=20 > > > > affects the routing architecture selection (IMHO - it should not > > have > > > > any effect) in the end. > > > > > > > > > > > > > > > > > > > "5.2. Addressing > > > > > > > > > > The type of A-O-R for the termination may also > > affect what kind > > > of > > > > > address location service is used. Address location is done > > > > typically > > > > > based on the following four characteristics of the > > termination's > > > > AOR. > > > > > In each case, we list the most common address=20 > location method > > > used. > > > > > > > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > > > 2. E.164 prefixes: SPs local policy is generally used. > > > > > 3. Full A-O-R: This is rarely used for routing in=20 > a peering > > > > > environment. > > > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may > > be used." > > > > > > > > > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > > > > > E.164 numbers are names > > > > > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > > > > > > > I am not sure what I need to fix, but we can address it=20 > after WG=20 > > > > discussion. > > > > > > > > > > > > > > And IMHO completely off is the idea to introduce > > carrier selection > > > > > within VoIP > > > > > > > > > > " For example Equal Access is > > > > > a LEC (Local Exchange Carrier) requirement and an SP > > operating > > as > > > > an > > > > > LEC may be required to allow the subscriber=20 > his/her choice of > > IXC > > > > > (IntereXchange Carrier) for certain set of calls. =20 > > In essence, > > > > these > > > > > requirements may affect route policy for peering where the > > > > downstream > > > > > peer is chosen based on origination's policy. In=20 > this case, > > the > > > > > Core-O and Core-T may be one and the same SP who=20 > peer through > > an > > > > > Interconnect SP of the origination's choice." > > > > > > > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I > > think > > > it > > > > is good to know what some VoIP SPs are dealing with > > especially when > > we > > >=20 > > > > are starting discussions in the WG. As the draft says =20 > in the last > > > para > > > > - it is > > > > possible that this may affect only a minor set of > > deployments in the > > > > end. Time will tell. Also, Equal Access is simply an example (I > > can't > > > > promise if there are not a host of other scenarios out there). > > > > > > > > Thanks, > > > > Medhavi. > > > > > > > > > > > > > > > > > I have an headache > > > > > > > > > > Richard > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Livingood, Jason=20 > [mailto:Jason_Livingood@cable.comcast.com] > > > > > Gesendet: Do 02.03.2006 19:33 > > > > > An: speermint@ietf.org > > > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > > > > FYI for the WG on this draft. This is on the tentative > > agenda at > > > the > > > > Dallas meeting (should > > > > > be finalized shortly). > > > > > > > > > > Jason > > > > > > > > > > ________________________________ > > > > > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > > > Sent: Sunday, February 26, 2006 12:44 AM > > > > > To: internet-drafts@ietf.org > > > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > > > > > > > > > Abstract > > > > > > > > > > > > > > > > > > > > The purpose of this document is to help the IETF community > > > > understand > > > > > > > > > > the route architectures being used today in SIP=20 > based peering > > > > > > > > > > environments and to outline a set of requirements > > based on the > > > same > > > > > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > -- > > > > > No virus found in this incoming message. > > > > > Checked by AVG Free Edition. > > > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > > > 3/1/2006 > > > > > > > >=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 > >=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 Wed Mar 08 16:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Tz-00029R-Jz; Wed, 08 Mar 2006 16:46:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5jd-0000Pl-7H for speermint@ietf.org; Wed, 08 Mar 2006 15:58:17 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5jc-0002dD-Mb for speermint@ietf.org; Wed, 08 Mar 2006 15:58:16 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2006 12:58:17 -0800 X-IronPort-AV: i="4.02,176,1139212800"; d="scan'208"; a="1783186359:sNHT34686380" Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k28KwDYg020238; Wed, 8 Mar 2006 12:58:13 -0800 (PST) From: "Dan Wing" To: "'Khan, Sohel Q [CTO]'" , Date: Wed, 8 Mar 2006 12:58:13 -0800 Keywords: direct-to-dwing Message-ID: <0c4001c642f3$0472b3f0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAAbnonA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E061019F9@PLSWB08C.ad.sprint.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [Speermint] RE: Draft-wing-session-auth-00: Media Session Authorization 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 > Given that propagation delay added for so much end to end > signaling/control message flows, would it be possible to shorten flows > of Figure 7 There is no figure 7. I believe you're referring to figure 6 on page 9 of draft-wing-session-auth-00.txt. > by eliminating messages (10 to 13) and combining messages > (9) and (14) together? > > If so, what are the implications of such elimination? If Alice's network policy allows Alice to send UDP packets out of her network without any policy control you could eliminate messages 11, 12, 15, and 16. It isn't possible to eliminate message 10, as it contains the SDP answer -- that arrives as part of the SIP 183 message (unreliably) or the SIP 200 message. Message 9 (Alice's STUN response) and message 14 (Alice's STUN Request) are part of ICE. Alice can send her STUN response prior to receiving Bob's SDP answer. However, per ICE, Alice doesn't send her STUN Request until she receives Bob's SDP answer. You'll see those messages 9 (Alice's STUN Response) and 14 (Alice's STUN Request) are also shown in the simplified ICE flow in Figure 4. I expect the mechanics of this will be easier to follow with the slides that I'm presenting in Dallas -- with the ASCII call flow is awkward to follow. For example the ASCII art makes it seem there is delay in the system whereas an implementation could actually eliminate much of that delay. As a specific example, the ASCII art shows message 10 (containing Bob's SDP answer) is received by Alice's SIP proxy and then Alice's SIP proxy spends time communicating with Alice's Policy device (messages 11 and 12) before sending the message along to the Alice endpoint itself (message 13). However, as long as Alice's Policy device has received that communication sometime prior to Alice's Firewall doing its authorization check in message 15, the authorization will still work. A flow like this could be envisioned: ... | |(10) answer, token=B:b | | | |<----------------------------------------| |(11) answer, token=B:b | | | |<------------| | | | | |(12) new session, token=B:b| | | |............>| | | | |(13) OK | | | | |<............| | | |(14) STUN Request, token=B:b:A:a | | |========================================>X | | | |(15) token B:b:A:a ok? | | | |<............| | | | |(16) Yes | | The risk is of this flow is a race condition -- message 14 and 15 could occur before message 12 occurs. This race condition could be resolved by having the policy server only send a "no" in message 16 after waiting a "reasonable length of time" (a second, perhaps) for the possible arrival of message 12. However, this would require storing more state in the policy server if there is a flood of message 14's or spoofed message 14's which will never be authorized by any SIP proxy because there really isn't an signaled SIP call associated with that 5-tuple or with the token values. Hope that helps. -d _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 10 14:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHn3t-0001m7-Sl; Fri, 10 Mar 2006 14:14:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHn3s-0001lp-Is for speermint@ietf.org; Fri, 10 Mar 2006 14:14:04 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHn3s-0001F7-4i for speermint@ietf.org; Fri, 10 Mar 2006 14:14:04 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k2AJDtnT012176; Fri, 10 Mar 2006 11:13:55 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k2AJDpnG012174; Fri, 10 Mar 2006 11:13:51 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 10 Mar 2006 11:13:51 -0800 From: David Meyer To: Rohan Mahy Message-ID: <20060310191351.GA12158@1-4-5.net> References: <6a261fe69d90f684d5a9cc500b2d2643@ekabal.com> Mime-Version: 1.0 In-Reply-To: <6a261fe69d90f684d5a9cc500b2d2643@ekabal.com> 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: 37af5f8fbf6f013c5b771388e24b09e7 Cc: speermint@ietf.org Subject: [Speermint] Re: comments on terminology document 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="===============1259044796==" Errors-To: speermint-bounces@ietf.org --===============1259044796== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Rohan, Thanks for the comments. I'll work it all into the next rev. Dave On Thu, Mar 09, 2006 at 08:50:42AM -0800, Rohan Mahy wrote: > Hi, >=20 > I just read the -01 terminology document. I think we are making good=20 > progress here. I have 3 content comments and a bunch of NITS. >=20 > 1) I found the NAPTR discussion in Section 2 confusing. There will=20 > often be two NAPTR lookups, one for ENUM and another for selecting the=20 > SIP transport. From the diagram I can tell that the text is referring=20 > to the ENUM lookup only. I'd also refer to RFC3263 instead of=20 > describing the additional SIP DNS lookup steps. Proposed rewording: >=20 > In the case shown here, an E.164 number is used as a key by ENUM to=20 > retrieve a NAPTR record [RFC3404] from the DNS, which in turn resolved=20 > into a SIP URI. Call routing is based on the resulting SIP URI. The=20 > call routing step does not depend on the presence of an E.164 number;=20 > indeed, the resulting SIP URI may no longer even contain any numbers,=20 > and the SIP URI can be advertised in various other ways, such as on a=20 > web page. Finally, note that the subsequent lookup steps described in=20 > RFC 3263 [RFC3263] to find the next-hop SIP server from this URI are=20 > outside the scope of SPEERMINT. >=20 > 2) In Section 3.5 (2nd paragraph), its not obvious what an "ingress=20 > point" is in this context, or how this 2nd paragraph is related to the=20 > first. I'd remove it. Alternatively it could be reworded: >=20 > Note that as soon as a domain advertises SIP-specific DNS records=20 > (SIP+ or SIPS+ NAPTR records, or _sip or _sips SRV records), anyone can= =20 > discover SIP servers corresponding to the domain and send calls there. >=20 > 3) It seems like a lot of folks are interested in federation and=20 > carrier clubs. I think our first responsibility is direct peering, but= =20 > we should be flexible enough to accommodate federation without jumping=20 > through a lot of hoops. I like the new wording in 5.1 for example. I=20 > still think the definition of Layer 5 could be more accommodating. =20 > I've proposed some text below: >=20 > current wording in -01 > >3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 peering > > case, there is no intervening network. That is, for purposes of=20 > >this > > discussion, there is no such thing as a "Layer 5 Transit Network". >=20 > Proposed wording: > Layer 5 peering refers to interconnection of two service providers=A0for= =20 > the purposes of exchanging SIP signaling. Note that in the layer 5=20 > peering case, there is no requirement for any intervening "Layer 5=20 > Transit Network". Each service provider is expected to interconnect=20 > directly with other service providers, although a service provider is=20 > allowed to interconnect through another domain (ex: a federation) to=20 > act on its behalf. This document neither precludes nor encourages this=20 > behavior. >=20 >=20 >=20 > NITS: >=20 > spell out and reference first uses of SIP, ENUM, and SMTP > spell out VoIP, URI, and DNS on first use > s/Ip /IP /g > capitalize "MAC" in MAC address > reference split-DNS >=20 > Section 2 s/NAPTR recored/NAPTR record/ >=20 > Section 4.3 > s/VPN's/IPsec [ref] VPNs (Virtual Private Networks)/ >=20 > Section 4.4 (is this what was intended?) > s/Finally, note that ENUM is not constrained to carry only data (CDR)/ > Finally, note that ENUM is not constrained to carry only CRD data/ >=20 > s/an an/an/ >=20 > Section 5.1 > s/These start by a/These start as a/ >=20 > Section 5.5 > s/used route the/used to route the/ >=20 > thanks, > -rohan >=20 --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEEc/vORgD1qCZ2KcRAi9HAJ4mRuyt44IhZB0W4AjVfuMIj+5CtQCfVyT+ zbzwx606DTzfOcIikTIG988= =DdJQ -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- --===============1259044796== 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 --===============1259044796==-- From speermint-bounces@ietf.org Fri Mar 10 14:24:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHnDu-0002NI-AC; Fri, 10 Mar 2006 14:24:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHnDs-0002N1-I4 for speermint@ietf.org; Fri, 10 Mar 2006 14:24:24 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHnDs-0001Mt-1F for speermint@ietf.org; Fri, 10 Mar 2006 14:24:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Re: comments on terminology document Date: Fri, 10 Mar 2006 20:24:29 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48CC@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: comments on terminology document Thread-Index: AcZEd2CfTGOE9k7qQrePJizEhguURwAAOAR2 From: "Stastny Richard" To: "David Meyer" , "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: speermint@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 First, I like the proposed text from from Rohan regarding =20 > >3.6.2. Layer 5 Peering second, on the discussion on NAPTRs I would like to add that we may also have a third, etc. NAPTR lookup,=20 e.g. the proposed Policy NAPTRs, so we should always make clear what NAPTRs we are talking about regards Richard ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Fr 10.03.2006 20:13 An: Rohan Mahy Cc: speermint@ietf.org Betreff: [Speermint] Re: comments on terminology document Rohan, Thanks for the comments. I'll work it all into the next rev. Dave On Thu, Mar 09, 2006 at 08:50:42AM -0800, Rohan Mahy wrote: > Hi, > > I just read the -01 terminology document. I think we are making good > progress here. I have 3 content comments and a bunch of NITS. > > 1) I found the NAPTR discussion in Section 2 confusing. There will > often be two NAPTR lookups, one for ENUM and another for selecting the > SIP transport. From the diagram I can tell that the text is referring > to the ENUM lookup only. I'd also refer to RFC3263 instead of > describing the additional SIP DNS lookup steps. Proposed rewording: > > In the case shown here, an E.164 number is used as a key by ENUM to > retrieve a NAPTR record [RFC3404] from the DNS, which in turn resolved > into a SIP URI. Call routing is based on the resulting SIP URI. The > call routing step does not depend on the presence of an E.164 number; > indeed, the resulting SIP URI may no longer even contain any numbers, > and the SIP URI can be advertised in various other ways, such as on a > web page. Finally, note that the subsequent lookup steps described in > RFC 3263 [RFC3263] to find the next-hop SIP server from this URI are > outside the scope of SPEERMINT. > > 2) In Section 3.5 (2nd paragraph), its not obvious what an "ingress > point" is in this context, or how this 2nd paragraph is related to the > first. I'd remove it. Alternatively it could be reworded: > > Note that as soon as a domain advertises SIP-specific DNS records > (SIP+ or SIPS+ NAPTR records, or _sip or _sips SRV records), anyone = can > discover SIP servers corresponding to the domain and send calls there. > > 3) It seems like a lot of folks are interested in federation and > carrier clubs. I think our first responsibility is direct peering, = but > we should be flexible enough to accommodate federation without jumping > through a lot of hoops. I like the new wording in 5.1 for example. I > still think the definition of Layer 5 could be more accommodating.=20 > I've proposed some text below: > > current wording in -01 > >3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 = peering > > case, there is no intervening network. That is, for purposes of > >this > > discussion, there is no such thing as a "Layer 5 Transit Network". > > Proposed wording: > Layer 5 peering refers to interconnection of two service providers for > the purposes of exchanging SIP signaling. Note that in the layer 5 > peering case, there is no requirement for any intervening "Layer 5 > Transit Network". Each service provider is expected to interconnect > directly with other service providers, although a service provider is > allowed to interconnect through another domain (ex: a federation) to > act on its behalf. This document neither precludes nor encourages this > behavior. > > > > NITS: > > spell out and reference first uses of SIP, ENUM, and SMTP > spell out VoIP, URI, and DNS on first use > s/Ip /IP /g > capitalize "MAC" in MAC address > reference split-DNS > > Section 2 s/NAPTR recored/NAPTR record/ > > Section 4.3 > s/VPN's/IPsec [ref] VPNs (Virtual Private Networks)/ > > Section 4.4 (is this what was intended?) > s/Finally, note that ENUM is not constrained to carry only data (CDR)/ > Finally, note that ENUM is not constrained to carry only CRD data/ > > s/an an/an/ > > Section 5.1 > s/These start by a/These start as a/ > > Section 5.5 > s/used route the/used to route the/ > > thanks, > -rohan > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Mar 12 05:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIO7y-00042u-0o; Sun, 12 Mar 2006 05:48:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIO7x-00042l-DM for speermint@ietf.org; Sun, 12 Mar 2006 05:48:45 -0500 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIO7w-0007NV-H5 for speermint@ietf.org; Sun, 12 Mar 2006 05:48:45 -0500 Content-class: urn:content-classes:message Subject: RE: [Speermint] Re: comments on terminology document MIME-Version: 1.0 Date: Sun, 12 Mar 2006 12:48:56 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <1DDB0D3CC4E7F14FAE946361C0A6065558C4DC@isr-jlm-mail.Kayote.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: comments on terminology document Thread-Index: AcZEdtdR746xLHNmSDK9OGON28zf0QBQNGmA From: "David Schwartz" To: "David Meyer" , "Rohan Mahy" X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@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 David. Nice draft. Following up on Rohan's comment regarding carrier clubs or federations I = think that this document should actually have a definition of these as = well. The reason it is so important to have this definition appear in this = document is because I have seen many definitions cropping up that IMHO = confuse the matter and since this document is sort of a baseline it is = probably better that it is dealt with here.=20 Compare for example the definitions given for a federation in = "draft-ietf-sipping-trait-authz-02" (TRAIT) and = "draft-lendl-speermint-federations-00" (FEDS).=20 TRAIT defines a federation as "...a set of administrative domains that = implement common policies regarding the use and applicability of traits = for authorization decisions". FEDS on the other hand defines this same entity as "...a group of VoIP = service providers which * agree to receive calls from each other via SIP, * agree on a set of administrative rules for such calls (settlement, abuse-handling, ...), and * agree on specific rules for the technical details of the Interconnection". As can be seen, FEDS has a much narrower definition and since as Rohan = has pointed out we are "not precluding" connections via some sort of = intervening network it is possible to have federations where the peers = do not "agree" on policy with anyone other than the intervening network. = TRAIT is general enough to allow for this model while FEDS is not. Accepting the TRAIT definition and "base-lining" it is therefore more in = line with the current revisions to your document. (In general I feel that the TRAIT document should migrate over to the = SPEERMINT working group)=20 Any thoughts? David Schwartz . >=20 > 3) It seems like a lot of folks are interested in federation and=20 > carrier clubs. I think our first responsibility is direct peering, = but=20 > we should be flexible enough to accommodate federation without jumping = > through a lot of hoops. I like the new wording in 5.1 for example. I=20 > still think the definition of Layer 5 could be more accommodating. =20 > I've proposed some text below: >=20 > current wording in -01 > >3.6.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service providers > > for the purposes of SIP signaling. Note that in the layer 5 = peering > > case, there is no intervening network. That is, for purposes of=20 > >this > > discussion, there is no such thing as a "Layer 5 Transit Network". >=20 > Proposed wording: > Layer 5 peering refers to interconnection of two service = providers=A0for=20 > the purposes of exchanging SIP signaling. Note that in the layer 5=20 > peering case, there is no requirement for any intervening "Layer 5=20 > Transit Network". Each service provider is expected to interconnect=20 > directly with other service providers, although a service provider is=20 > allowed to interconnect through another domain (ex: a federation) to=20 > act on its behalf. This document neither precludes nor encourages this = > behavior. >=20 >=20 > thanks, > -rohan >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Mar 12 09:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIRnO-0002nZ-Na; Sun, 12 Mar 2006 09:43:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIRnO-0002nU-9b for speermint@ietf.org; Sun, 12 Mar 2006 09:43:46 -0500 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIRnK-0006XD-By for speermint@ietf.org; Sun, 12 Mar 2006 09:43:46 -0500 Content-class: urn:content-classes:message Subject: RE: [Speermint] Re: comments on terminology document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Mar 2006 16:43:39 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A6065558C55A@isr-jlm-mail.Kayote.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: comments on terminology document Thread-Index: AcZEdtdR746xLHNmSDK9OGON28zf0QBQNGmA From: "David Schwartz" To: "David Meyer" , "Rohan Mahy" X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: speermint@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 David. Upon further thought I believe we need to reexamine section 3.6.2. of draft-ietf-speermint-reqs-and-terminology-01.txt. Does the scope of the definition of Layer 5 peering presented really cover all of our use cases? Consider if you will the nature of social or referral networks. Assume that B is a friend to A and C. A would like to speak to C only C does not know or trust A is and it is only when B "introduces" A to C that A can speak directly to C. Note that this has nothing to do with how the signaling/media flows between A and C. In reality, peering networks have more in common with this example than we realize. At the end of the day, it is the business relationships comprising trust and policy that differentiate the Layer 5 peering problems from lower layer ones. The direct peering model and the one using an intermediary network are both use cases that need to be unified by a common peering model. The challenge for SPEERMINT is to define this model such that we have the tools to express peering for all its use cases. David Schwartz _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Mar 13 13:33:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrrU-0001t2-99; Mon, 13 Mar 2006 13:33:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrrS-0001sx-LI for speermint@ietf.org; Mon, 13 Mar 2006 13:33:42 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrrR-00004u-8j for speermint@ietf.org; Mon, 13 Mar 2006 13:33:42 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k2DIXWtN032499; Mon, 13 Mar 2006 10:33:32 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k2DIXSwS032498; Mon, 13 Mar 2006 10:33:28 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 13 Mar 2006 10:33:28 -0800 From: David Meyer To: David Schwartz Subject: Re: [Speermint] Re: comments on terminology document Message-ID: <20060313183328.GA32460@1-4-5.net> References: <1DDB0D3CC4E7F14FAE946361C0A6065558C4DC@isr-jlm-mail.Kayote.com> Mime-Version: 1.0 In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A6065558C4DC@isr-jlm-mail.Kayote.com> 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 Cc: Rohan Mahy , speermint@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: , Content-Type: multipart/mixed; boundary="===============0511543091==" Errors-To: speermint-bounces@ietf.org --===============0511543091== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 12, 2006 at 12:48:56PM +0200, David Schwartz wrote: > Hi David. >=20 > Nice draft. Thanks. Just surfacing after a brutal travel spin-cycle. > Following up on Rohan's comment regarding carrier clubs or federations I = think that this document should actually have a definition of these as well. >=20 > The reason it is so important to have this definition appear in this docu= ment is because I have seen many definitions cropping up that IMHO confuse = the matter and since this document is sort of a baseline it is probably bet= ter that it is dealt with here.=20 Agreed. > Compare for example the definitions given for a federation in "draft-ietf= -sipping-trait-authz-02" (TRAIT) and "draft-lendl-speermint-federations-00"= (FEDS).=20 >=20 > TRAIT defines a federation as "...a set of administrative domains that im= plement common policies regarding the use and applicability of traits for a= uthorization decisions". >=20 > FEDS on the other hand defines this same entity as "...a group of VoIP se= rvice providers which > * agree to receive calls from each other via SIP, > * agree on a set of administrative rules for such calls > (settlement, abuse-handling, ...), and > * agree on specific rules for the technical details of the > Interconnection". >=20 > As can be seen, FEDS has a much narrower definition and since as Rohan ha= s pointed out we are "not precluding" connections via some sort of interven= ing network it is possible to have federations where the peers do not "agre= e" on policy with anyone other than the intervening network. TRAIT is gener= al enough to allow for this model while FEDS is not. >=20 > Accepting the TRAIT definition and "base-lining" it is therefore more in = line with the current revisions to your document. >=20 > (In general I feel that the TRAIT document should migrate over to the SPE= ERMINT working group)=20 On first blush, seems reasonable. What does the WG think? Dave --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEFbr4ORgD1qCZ2KcRAttsAJ41NNKLIrwDQzjV2CA6HCe84GkDAwCfSn+i ehvaWUDLzWf9dfM6QKu+a/4= =yipr -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- --===============0511543091== 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 --===============0511543091==-- From speermint-bounces@ietf.org Mon Mar 13 13:53:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsAY-0004CS-MY; Mon, 13 Mar 2006 13:53:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsAX-0004CN-0e for speermint@ietf.org; Mon, 13 Mar 2006 13:53:25 -0500 Received: from outbound-kan.frontbridge.com ([63.161.60.23] helo=outbound2-kan-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIsAW-0000Pf-Jn for speermint@ietf.org; Mon, 13 Mar 2006 13:53:24 -0500 Received: from outbound2-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-kan-R.bigfish.com (Postfix) with ESMTP id 2320135FC1A; Mon, 13 Mar 2006 18:53:22 +0000 (UTC) Received: from mail28-kan-R.bigfish.com (unknown [172.18.7.1]) by outbound2-kan.bigfish.com (Postfix) with ESMTP id 153D135FC1D; Mon, 13 Mar 2006 18:53:22 +0000 (UTC) Received: from mail28-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail28-kan-R.bigfish.com (Postfix) with ESMTP id 0899E19AB6B; Mon, 13 Mar 2006 18:53:22 +0000 (UTC) X-BigFish: V Received: by mail28-kan (MessageSwitch) id 1142276001924068_16763; Mon, 13 Mar 2006 18:53:21 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail28-kan.bigfish.com (Postfix) with ESMTP id BEA4019B486; Mon, 13 Mar 2006 18:53:21 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k2DIrLlG001470; Mon, 13 Mar 2006 12:53:21 -0600 (CST) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2DIrKS14793; Mon, 13 Mar 2006 12:53:20 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 12:53:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: comments on terminology document Date: Mon, 13 Mar 2006 12:53:19 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E0636910F@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: comments on terminology document Thread-Index: AcZGzMHdtPi1/BjbQ/ep229vuBiMQAAAoNjg From: "Khan, Sohel Q [CTO]" To: "David Meyer" , "David Schwartz" X-OriginalArrivalTime: 13 Mar 2006 18:53:20.0791 (UTC) FILETIME=[65DEC270:01C646CF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Rohan Mahy , speermint@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 Yes, it will be a good idea to move draft-ietf-sipping-trait-authz-02 to SPEERMINT. =20 -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net]=20 Sent: Monday, March 13, 2006 12:33 PM To: David Schwartz Cc: Rohan Mahy; speermint@ietf.org Subject: Re: [Speermint] Re: comments on terminology document On Sun, Mar 12, 2006 at 12:48:56PM +0200, David Schwartz wrote: > Hi David. >=20 > Nice draft. Thanks. Just surfacing after a brutal travel spin-cycle. > Following up on Rohan's comment regarding carrier clubs or federations I think that this document should actually have a definition of these as well. >=20 > The reason it is so important to have this definition appear in this document is because I have seen many definitions cropping up that IMHO confuse the matter and since this document is sort of a baseline it is probably better that it is dealt with here.=20 Agreed. > Compare for example the definitions given for a federation in "draft-ietf-sipping-trait-authz-02" (TRAIT) and "draft-lendl-speermint-federations-00" (FEDS).=20 >=20 > TRAIT defines a federation as "...a set of administrative domains that implement common policies regarding the use and applicability of traits for authorization decisions". >=20 > FEDS on the other hand defines this same entity as "...a group of VoIP service providers which > * agree to receive calls from each other via SIP, > * agree on a set of administrative rules for such calls > (settlement, abuse-handling, ...), and > * agree on specific rules for the technical details of the > Interconnection". >=20 > As can be seen, FEDS has a much narrower definition and since as Rohan has pointed out we are "not precluding" connections via some sort of intervening network it is possible to have federations where the peers do not "agree" on policy with anyone other than the intervening network. TRAIT is general enough to allow for this model while FEDS is not. >=20 > Accepting the TRAIT definition and "base-lining" it is therefore more in line with the current revisions to your document. >=20 > (In general I feel that the TRAIT document should migrate over to the=20 > SPEERMINT working group) On first blush, seems reasonable. What does the WG think? Dave _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 15 09:23:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWul-0002Wr-RZ; Wed, 15 Mar 2006 09:23:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWuj-0002Wm-IY for speermint@ietf.org; Wed, 15 Mar 2006 09:23:50 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJWuj-0002sR-4A for speermint@ietf.org; Wed, 15 Mar 2006 09:23:49 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 168021A3D0; Wed, 15 Mar 2006 15:23:46 +0100 (CET) Date: Wed, 15 Mar 2006 15:23:46 +0100 From: Otmar Lendl To: David Schwartz Subject: Re: [Speermint] Re: comments on terminology document Message-ID: <20060315142346.GA12304@nic.at> Mail-Followup-To: Otmar Lendl , David Schwartz , David Meyer , Rohan Mahy , speermint@ietf.org References: <1DDB0D3CC4E7F14FAE946361C0A6065558C4DC@isr-jlm-mail.Kayote.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A6065558C4DC@isr-jlm-mail.Kayote.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Rohan Mahy , speermint@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 2006/03/12 11:03, David Schwartz wrote: > > Following up on Rohan's comment regarding carrier clubs or federations > I think that this document should actually have a definition of these > as well. > > The reason it is so important to have this definition appear in this > document is because I have seen many definitions cropping up that IMHO > confuse the matter and since this document is sort of a baseline it is > probably better that it is dealt with here. The concept of federations will be important. They are popping up in various concepts (e.g. IM federations), and I doubt that one definition will be suitable for all applications. > > Compare for example the definitions given for a federation > in "draft-ietf-sipping-trait-authz-02" (TRAIT) and > "draft-lendl-speermint-federations-00" (FEDS). > > TRAIT defines a federation as "...a set of administrative domains > that implement common policies regarding the use and applicability of > traits for authorization decisions". > > FEDS on the other hand defines this same entity as "...a group of VoIP service providers which > * agree to receive calls from each other via SIP, > * agree on a set of administrative rules for such calls > (settlement, abuse-handling, ...), and > * agree on specific rules for the technical details of the > Interconnection". > > As can be seen, FEDS has a much narrower definition and since as Rohan > has pointed out we are "not precluding" connections via some sort > of intervening network it is possible to have federations where the > peers do not "agree" on policy with anyone other than the intervening > network. TRAIT is general enough to allow for this model while FEDS is > not. My wording in FEDS may be ambiguous, but as one example shows I tried to include the options of having a layer 5 node in the middle in the definition of a federation: o Peering fabric based on SIP: A company sets up a SIP proxy which acts as a forwarding proxy between the SIP proxies of all participating VSPs. The group of these VSP form a federation whose technical rules state that calls have to be routed via that central proxy. In the context of draft-lendl-speermint-federations-00, the only important aspect of a federation is the notion that if VSP A is a member of the federations X and Y and VSP B is a member of Y and Z then A can use the federation-framework of Y to complete a call to B. At this level, the details of Y's inner working (direct SIP? proxied SIP? Public Internet? Private L3? QoS? TLS? Codecs? srtp?) is irrelevant. The TRAIT concept fits in nicely into draft-lendl-domain-policy-ddds-00. I see two ways of incorporating TRAITs there: a) if e.g. 10 universities trust each other's traits, then they can form a FEDS federation where the technical rules state that inter-university calls need to carry the trait "valid-user" (signed by one of the universities). b) assuming traits will be standardized as RFC9999, and the appropriate policy-types are introduced: $ORIGIN example.edu. ; order pref flags service regexp replacement IN NAPTR 10 10 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:9999!" . IN NAPTR 10 11 "U" "D2P+SIP:ca-list" "!^.*$!CACERT,THAWTE,XXXX!" . > Accepting the TRAIT definition and "base-lining" it is therefore more > in line with the current revisions to your document. I'm not sure whether that's a good idea. TRAIT addresses a different application than FEDS. Forcing a definition to suit both may have benefits in terminology but will dilute the applicability of the concepts regarding the respective use-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 Wed Mar 15 15:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcOz-0004bU-Kq; Wed, 15 Mar 2006 15:15:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcOy-0004bO-J5 for speermint@ietf.org; Wed, 15 Mar 2006 15:15:24 -0500 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJcOx-0005sy-Oe for speermint@ietf.org; Wed, 15 Mar 2006 15:15:24 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Re: comments on terminology document X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 15 Mar 2006 22:15:22 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550F40A1@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: comments on terminology document Thread-Index: AcZIPBONo1HAvmJTTsyvmRPBnjo4ngALp1WK References: <1DDB0D3CC4E7F14FAE946361C0A6065558C4DC@isr-jlm-mail.Kayote.com> <20060315142346.GA12304@nic.at> From: "David Schwartz" To: "Otmar Lendl" X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: Rohan Mahy , speermint@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: , Content-Type: multipart/mixed; boundary="===============1323523034==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1323523034== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6486D.303D485D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6486D.303D485D Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Otmar. =20 Nice hearing from you. =20 I guess what concerns me about the definition in your draft is the word = "agree". Various DA's can coexist in a federation without agreeing on = anything. They merely need to support a common set of rules so that they = can understand each others requirements. Agreement sound awfully close = to bilateral relationships and as I stated before that is just on use = case for a federation. Entities may federate and yet not agree to accept = direct traffic from each other for business, security, trust, protocol, = codec or just about any other reason.=20 =20 While there may definitely be more than one definition for a federation, = we should strive for a more general (supporting more use cases) = definition at the expense of the more restrictive one. =20 Cheers, =20 David Schwartz ________________________________ =EE=E0=FA: Otmar Lendl [mailto:lendl@nic.at] =F0=F9=EC=E7: =E3 15/03/2006 16:23 =E0=EC: David Schwartz =F2=E5=FA=F7 =EC=E9=E3=E9=F2=E4: David Meyer; Rohan Mahy; = speermint@ietf.org =F0=E5=F9=E0: Re: [Speermint] Re: comments on terminology document On 2006/03/12 11:03, David Schwartz wrote: > > Following up on Rohan's comment regarding carrier clubs or federations > I think that this document should actually have a definition of these > as well. > > The reason it is so important to have this definition appear in this > document is because I have seen many definitions cropping up that IMHO > confuse the matter and since this document is sort of a baseline it is > probably better that it is dealt with here. The concept of federations will be important. They are popping up in various concepts (e.g. IM federations), and I doubt that one definition will be suitable for all applications. > > Compare for example the definitions given for a federation > in "draft-ietf-sipping-trait-authz-02" (TRAIT) and > "draft-lendl-speermint-federations-00" (FEDS). > > TRAIT defines a federation as "...a set of administrative domains > that implement common policies regarding the use and applicability of > traits for authorization decisions". > > FEDS on the other hand defines this same entity as "...a group of VoIP = service providers which > * agree to receive calls from each other via SIP, > * agree on a set of administrative rules for such calls > (settlement, abuse-handling, ...), and > * agree on specific rules for the technical details of the > Interconnection". > > As can be seen, FEDS has a much narrower definition and since as Rohan > has pointed out we are "not precluding" connections via some sort > of intervening network it is possible to have federations where the > peers do not "agree" on policy with anyone other than the intervening > network. TRAIT is general enough to allow for this model while FEDS is > not. My wording in FEDS may be ambiguous, but as one example shows I tried to include the options of having a layer 5 node in the middle in the definition of a federation: o Peering fabric based on SIP: A company sets up a SIP proxy which acts as a forwarding proxy between the SIP proxies of all participating VSPs. The group of these VSP form a federation whose technical rules state that calls have to be routed via that central proxy. In the context of draft-lendl-speermint-federations-00, the only = important aspect of a federation is the notion that if VSP A is a member of the federations X and Y and VSP B is a member of Y and Z then A can use the federation-framework of Y to complete a call to B. At this level, the details of Y's inner working (direct SIP? proxied = SIP? Public Internet? Private L3? QoS? TLS? Codecs? srtp?) is irrelevant. The TRAIT concept fits in nicely into draft-lendl-domain-policy-ddds-00. I see two ways of incorporating TRAITs there: a) if e.g. 10 universities trust each other's traits, then they can form a FEDS federation where the technical rules state that = inter-university calls need to carry the trait "valid-user" (signed by one of the = universities). b) assuming traits will be standardized as RFC9999, and the appropriate policy-types are introduced: $ORIGIN example.edu. ; order pref flags service regexp replacement IN NAPTR 10 10 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:9999!" . IN NAPTR 10 11 "U" "D2P+SIP:ca-list" = "!^.*$!CACERT,THAWTE,XXXX!" . > Accepting the TRAIT definition and "base-lining" it is therefore more > in line with the current revisions to your document. I'm not sure whether that's a good idea. TRAIT addresses a different = application than FEDS. Forcing a definition to suit both may have benefits in = terminology but will dilute the applicability of the concepts regarding the = respective use-cases. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > ------_=_NextPart_001_01C6486D.303D485D Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Speermint] Re: comments on terminology document=0A= =0A= =0A=
=0A=
Hi = Otmar.
=0A=
 
=0A=
Nice hearing from = you.
=0A=
 
=0A=
I guess what concerns me = about the =0A= definition in your draft is the word "agree". Various DA's can coexist = in a =0A= federation without agreeing on anything. They merely need to support a = common =0A= set of rules so that they can understand each others requirements. = Agreement =0A= sound awfully close to bilateral relationships and as I stated before = that is =0A= just on use case for a federation. Entities may federate and yet = not agree =0A= to accept direct traffic from each other for business, security, trust, =0A= protocol, codec or just about any other reason. 
=0A=
 
=0A=
While there may definitely be = more than one =0A= definition for a federation, we should strive for a more general = (supporting =0A= more use cases) definition at the expense of the more restrictive =0A= one.
=0A=
 
=0A=
Cheers,
=0A=
 
=0A=
David Schwartz
=0A=
=0A=
=0A=
=0A=
=EE=E0=FA: Otmar = Lendl =0A= [mailto:lendl@nic.at]
=F0=F9=EC=E7: =E3 15/03/2006 = 16:23
=E0=EC: David =0A= Schwartz
=F2=E5=FA=F7 =EC=E9=E3=E9=F2=E4: David Meyer; Rohan = Mahy; =0A= speermint@ietf.org
=F0=E5=F9=E0: Re: [Speermint] Re: comments = on terminology =0A= document

=0A=
=0A=

On 2006/03/12 11:03, David Schwartz =0A= <David.Schwartz@Kayote.com> wrote:
>
> Following up on = Rohan's =0A= comment regarding carrier clubs or federations
> I think that this =0A= document should actually have a definition of these
> as =0A= well.
>
> The reason it is so important to have this = definition =0A= appear in this
> document is because I have seen many definitions = cropping =0A= up that IMHO
> confuse the matter and since this document is sort = of a =0A= baseline it is
> probably better that it is dealt with = here.

The =0A= concept of federations will be important. They are popping up
in = various =0A= concepts (e.g. IM federations), and I doubt that one
definition will = be =0A= suitable for all applications.

>
> Compare for example = the =0A= definitions given for a federation
> in =0A= "draft-ietf-sipping-trait-authz-02" (TRAIT) and
> =0A= "draft-lendl-speermint-federations-00" (FEDS).
>
> TRAIT = defines a =0A= federation as "...a set of administrative domains
> that implement = common =0A= policies regarding the use and applicability of
> traits for = authorization =0A= decisions".
>
> FEDS on the other hand defines this same = entity as =0A= "...a group of VoIP service providers =0A= which
>       *  agree to = receive calls =0A= from each other via SIP,
>       = *  =0A= agree on a set of administrative rules for such =0A= calls
>          = (settlement, =0A= abuse-handling, ...), and
>       = *  =0A= agree on specific rules for the technical details of =0A= the
>          =0A= Interconnection".
>
> As can be seen, FEDS has a much = narrower =0A= definition and since as Rohan
> has pointed out we are "not = precluding" =0A= connections via some sort
> of intervening network it is possible = to have =0A= federations where the
> peers do not "agree" on policy with anyone = other =0A= than the intervening
> network. TRAIT is general enough to allow = for this =0A= model while FEDS is
> not.

My wording in FEDS may be = ambiguous, but =0A= as one example shows I tried
to include the options of having a layer = 5 node =0A= in the middle in
the definition of a federation:

   = o  =0A= Peering fabric based on SIP: A company sets up a SIP proxy =0A= which
      acts as a forwarding proxy = between the =0A= SIP proxies of all
      participating = VSPs.  =0A= The group of these VSP form a = federation
      whose =0A= technical rules state that calls have to be routed via =0A= that
      central proxy.

In the = context of =0A= draft-lendl-speermint-federations-00, the only important
aspect of a =0A= federation is the notion that if VSP A is a member of
the federations = X and Y =0A= and VSP B is a member of Y and Z then A can use
the = federation-framework of Y =0A= to complete a call to B.

At this level, the details of Y's inner = working =0A= (direct SIP? proxied SIP?
Public Internet? Private L3? QoS? TLS? = Codecs? =0A= srtp?) is irrelevant.

The TRAIT concept fits in nicely into =0A= draft-lendl-domain-policy-ddds-00.
I see two ways of incorporating = TRAITs =0A= there:

a) if e.g. 10 universities trust each other's traits, then = they =0A= can
   form a FEDS federation where the technical rules = state that =0A= inter-university
   calls need to carry the trait = "valid-user" =0A= (signed by one of the universities).

b) assuming traits will be =0A= standardized as RFC9999, and the appropriate
   = policy-types are =0A= introduced:

   $ORIGIN =0A= example.edu.
      = ;      =0A= order pref flags service regexp =0A= replacement
       IN NAPTR 10 = 10   =0A= "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:9999!" =0A= .
       IN NAPTR 10 11   "U" =0A= "D2P+SIP:ca-list" "!^.*$!CACERT,THAWTE,XXXX!" .

> Accepting = the TRAIT =0A= definition and "base-lining" it is therefore more
> in line with = the =0A= current revisions to your document.

I'm not sure whether that's a = good =0A= idea. TRAIT addresses a different application
than FEDS. Forcing a = definition =0A= to suit both may have benefits in terminology
but will dilute the =0A= applicability of the concepts regarding the respective =0A= use-cases.

/ol
--
< Otmar Lendl (lendl@nic.at) | nic.at = Systems =0A= Engineer >

=0A= =0A= =0A= ------_=_NextPart_001_01C6486D.303D485D-- --===============1323523034== 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 --===============1323523034==-- From speermint-bounces@ietf.org Wed Mar 15 17:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJePx-0002zR-3D; Wed, 15 Mar 2006 17:24:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJePv-0002zM-TX for speermint@ietf.org; Wed, 15 Mar 2006 17:24:31 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJePt-0001ct-Ex for speermint@ietf.org; Wed, 15 Mar 2006 17:24:31 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 1AF071A3D0; Wed, 15 Mar 2006 23:24:27 +0100 (CET) Date: Wed, 15 Mar 2006 23:24:27 +0100 From: Otmar Lendl To: David Schwartz Subject: Re: [Speermint] Re: comments on terminology document Message-ID: <20060315222427.GJ28504@nic.at> Mail-Followup-To: Otmar Lendl , David Schwartz , David Meyer , Rohan Mahy , speermint@ietf.org References: <1DDB0D3CC4E7F14FAE946361C0A6065558C4DC@isr-jlm-mail.Kayote.com> <20060315142346.GA12304@nic.at> <1DDB0D3CC4E7F14FAE946361C0A606550F40A1@isr-jlm-mail.Kayote.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A606550F40A1@isr-jlm-mail.Kayote.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Rohan Mahy , speermint@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 David, [the Cc: via the speermint list didn't reach me yet, thus the extensive quote] On 2006/03/15 21:03, David Schwartz wrote: > Hi Otmar. > > Nice hearing from you. > > I guess what concerns me about the definition in your draft is the > word "agree". Various DA's can coexist in a federation without > agreeing on anything. They merely need to support a common set of > rules so that they can understand each others requirements. Agreement > sound awfully close to bilateral relationships and as I stated before > that is just on use case for a federation. Entities may federate and > yet not agree to accept direct traffic from each other for business, > security, trust, protocol, codec or just about any other reason. ?DA? I'm open to alternative wordings. The really critical thing for me is the following: If A and B are members of federation Y, then they can use some means (as defined in the rules of Y) to route calls to each other via SIP. (I don't care whether what SIP routings (direct or via a central proxy) a federation defines for its members. That's out of scope for my draft. It doesn't matter for the domain policy draft.) This doesn't necessarily mean they have a bilateral contract. They could have a contract with a central authority which defines how two members can connect to each other. As an example of that concept on a layer 3 exchange, look at the route servers operated by various internet exchanges (e.g. http://www.linx.net/www_public/our_services/other_services): Everybody peering with such a route server effectively peers with everybody else who peers with this server. A SIP-Layer transit network X is just another special case, as long as ALL customers of X can reach ALL other customers of X via the transit network X. The set of customers of X is a valid federation according to my definition. What doesn't work is selective peerings within a fabric: that way the fabric membership information is no longer enough to make the call routing decision. > While there may definitely be more than one definition for a > federation, we should strive for a more general (supporting more use > cases) definition at the expense of the more restrictive one. As I said, I'm open to wording suggestions. /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 Thu Mar 16 10:30:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuQf-000594-Hq; Thu, 16 Mar 2006 10:30:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuQe-00058z-Eu for speermint@ietf.org; Thu, 16 Mar 2006 10:30:20 -0500 Received: from pro22.abac.com ([66.226.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJuQe-0005c5-4P for speermint@ietf.org; Thu, 16 Mar 2006 10:30:20 -0500 Received: from jeremyb (bzq-25-94-33.cust.bezeqint.net [212.25.94.33]) (authenticated bits=0) by pro22.abac.com (8.13.4/8.13.4) with ESMTP id k2GFUDXU099140 for ; Thu, 16 Mar 2006 07:30:17 -0800 (PST) (envelope-from jeremyb@digitalshtick.com) From: "Jeremy Barkan \(DigitalShtick\)" To: Date: Thu, 16 Mar 2006 17:30:06 +0200 Message-ID: <009d01c6490e$84242950$1e6510ac@jeremyb> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <009801c6490d$f18474b0$1e6510ac@jeremyb> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Speermint] RE: comments on terminology document 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 and David, =A0 This discussion regarding the definition of federation is fundamental to = how we see the role of the federation, and not just terminology. =A0 >> Accepting the TRAIT definition and "base-lining" it is therefore more >> in line with the current revisions to your document. =A0 > I'm not sure whether that's a good idea. TRAIT addresses a different > application than FEDS. Forcing a definition to suit both may have = benefits > in terminology but will dilute the applicability of the concepts = regarding > the respective use-cases. =A0 The definition of a federation in the TRAITS draft is more like a = framework that would enable federations as described in FEDS [ a federation for = peer terminations ] to be a use case that would be expressible in the = framework. A key point in TRAITS is that federations are first and foremost a = common policy schema framework. >From the TRAITS draft: =A0 =93Domains that federate with one another agree on the syntax and = semantics of traits - without this consensus, trait-based authorization schemes would only be useful in an intradomain context.=94 =A0 =93A federation is defined as a set of administrative domains that = implement common policies regarding the use and applicability of traits for authorization decisions.=94 =A0 The use case in the TRAITS draft of =93Settlement for Services=94 is an interesting example. If we extend TRAITS beyond authorization, = wouldn=92t the peered termination examples in FEDS be better expressed in a TRAITS-like framework? TRAITS enables assertion of attributes and their policy requirements [the scope of those in the draft are authorization]. FEDS, = on the other hand, is limited to DNS expression for policy requirements. =A0 TRAITS also does not commit to a binding such as DNS, as in FEDS. TRAITS provides a framework that should be implemented at several levels. In = the FEDS example of call termination, the authorization/agreement flow could conceivably require elements at a higher protocol level than DNS.=20 =A0 Regards, =A0 Jeremy Barkan jeremyb at digitalshtick dot com DigitalShtick w/h +972 2 6728069 m +972 54 6321603 Shalom Yehdua 6/2 Jerusalem 93395 Israel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 17 13:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJiQ-0007It-O3; Fri, 17 Mar 2006 13:30:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJiP-0007IT-9X for speermint@ietf.org; Fri, 17 Mar 2006 13:30:21 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJiO-0000X4-OF for speermint@ietf.org; Fri, 17 Mar 2006 13:30:21 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FKJh3-0000rC-FL; Fri, 17 Mar 2006 12:29:56 -0600 From: "Brian Rosen" To: "'Medhavi Bhatia'" , "'Stastny Richard'" , "'Livingood, Jason'" , Subject: RE: [Speermint] RE: Equal Access (was I-Ddraft-bhatia-sip-peering-00.txt) Date: Fri, 17 Mar 2006 13:28:47 -0500 Message-ID: <000001c649f0$cd1b3990$6a201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAA6AVFACwrjPgA== In-Reply-To: <8812D8156467224C9E9739E513037EF12A157F@moe.nextone.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 Wading to the middle here... It seems to me that we would be wise to think about the ability to specify a transit network when there needs to be a transit network, and there is more than one available. If I have four networks, A, B1, B2 and C, where the networks peer in more than one place, then I may have a transit network: A -(p1)- B1 -(p2)- C \ / B2 and I may wish to instruct p1 to use either B1 or B2. I may do that for a variety of reasons. Brian -----Original Message----- From: Medhavi Bhatia [mailto:mbhatia@nextone.com] Sent: Friday, March 03, 2006 12:44 PM To: Stastny Richard; Livingood, Jason; speermint@ietf.org Subject: [Speermint] RE: Equal Access (was I-Ddraft-bhatia-sip-peering-00.txt) > This raises may questions such as: > if you are able to unbundle your access and are > able to choose another DSL provider, to you still > need carrier selection? My personal opinion is that it may not be not required for the case you have above. I think for the WG purposes, the solution we come with for the Interconnect SP problem (in the other thread we have on the WG list) may also be used to solve this. An Access SP or Core SP which needs to provide this to the subscriber for whatever reason treats the LD carrier as an Interconnect SP. The LD Carrier will need to do another lookup to get to Core-T (which may be same as Core-O in this case). > > Is carrier selection only valid for voice and voice > related services, especially if the selected carrier > still has only access via the PSTN? What if you switch > during a call to video? > > What does carrier selection imply with IP Interconnect? > L5 Interconnect or also L3 transit? > > A very nice example is if Core-O and Core-T is the > same, e.g. running on the same server, > do you still have to provide carrier selection > if the call is now forced via the PSTN? > This scenario may exist. I have heard about it as a requirement in some VoIP deployments. Medhavi. > Etc. etc. > > Cheers > > Richard > > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) > > Thanks for the quick read anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are > > talking > > about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP = Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the > > trapezoid. Sorry if it sounds > > confusing - we can fix that problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing > > architecture selection (IMHO - it should not have any effect) in the > > end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce > > > carrier selection within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time > > will tell. Also, Equal Access is simply an example (I can't promise if > > there > > are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 > _______________________________________________ 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 Fri Mar 17 13:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJuO-0008Fm-QU; Fri, 17 Mar 2006 13:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJuN-0008Fh-1X for speermint@ietf.org; Fri, 17 Mar 2006 13:42:43 -0500 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJuM-0000mi-5r for speermint@ietf.org; Fri, 17 Mar 2006 13:42:43 -0500 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id F3E8D903FAA; Fri, 17 Mar 2006 18:42:26 +0000 (UTC) Received: from mail56-ash-R.bigfish.com (unknown [172.18.2.1]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id D3796903DE8; Fri, 17 Mar 2006 18:42:26 +0000 (UTC) Received: from mail56-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail56-ash-R.bigfish.com (Postfix) with ESMTP id 6954C4A70B9; Fri, 17 Mar 2006 18:42:22 +0000 (UTC) X-BigFish: V Received: by mail56-ash (MessageSwitch) id 1142620942256411_14997; Fri, 17 Mar 2006 18:42:22 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail56-ash.bigfish.com (Postfix) with ESMTP id 27D264A6EAB; Fri, 17 Mar 2006 18:42:22 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k2HIgLcX019938; Fri, 17 Mar 2006 12:42:21 -0600 (CST) Received: from pdawg04a.ad.sprint.com (PDAWG04A.corp.sprint.com [10.122.2.37]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2HIgLA15706; Fri, 17 Mar 2006 12:42:21 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by pdawg04a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Mar 2006 12:42:21 -0600 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] RE: Equal Access (wasI-Ddraft-bhatia-sip-peering-00.txt) Date: Fri, 17 Mar 2006 12:42:19 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E067A99B3@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Equal Access (wasI-Ddraft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAA6AVFACwrjPgAABLvIg From: "Khan, Sohel Q [CTO]" To: , "Medhavi Bhatia" , "Stastny Richard" , "Livingood, Jason" , X-OriginalArrivalTime: 17 Mar 2006 18:42:21.0310 (UTC) FILETIME=[8670F1E0:01C649F2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b 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 I agree with Brian. We need to have more than one transit place. It can have two different scenarios: A -(p1)- B1 -(p2)- C \ / B2 A -(p1)--B1 --(p2)- C \ / B2 =20 Both p1 and p2 need to have options to select either B1 or B2. Sohel Khan -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, March 17, 2006 12:29 PM To: 'Medhavi Bhatia'; 'Stastny Richard'; 'Livingood, Jason'; speermint@ietf.org Subject: RE: [Speermint] RE: Equal Access (wasI-Ddraft-bhatia-sip-peering-00.txt) Wading to the middle here... It seems to me that we would be wise to think about the ability to specify a transit network when there needs to be a transit network, and there is more than one available. =20 If I have four networks, A, B1, B2 and C, where the networks peer in more than one place, then I may have a transit network: A -(p1)- B1 -(p2)- C \ / B2 and I may wish to instruct p1 to use either B1 or B2. I may do that for a variety of reasons. =20 Brian -----Original Message----- From: Medhavi Bhatia [mailto:mbhatia@nextone.com] Sent: Friday, March 03, 2006 12:44 PM To: Stastny Richard; Livingood, Jason; speermint@ietf.org Subject: [Speermint] RE: Equal Access (was I-Ddraft-bhatia-sip-peering-00.txt) > This raises may questions such as: > if you are able to unbundle your access and are able to choose another > DSL provider, to you still need carrier selection? My personal opinion is that it may not be not required for the case you have above. I think for the WG purposes, the solution we come with for the Interconnect SP problem (in the other thread we have on the WG list) may also be used to solve this. An Access SP or Core SP which needs to provide this to the subscriber for whatever reason treats the LD carrier as an Interconnect SP. The LD Carrier will need to do another lookup to get to Core-T (which may be same as Core-O in this case).=20 >=20 > Is carrier selection only valid for voice and voice related services,=20 > especially if the selected carrier still has only access via the PSTN? > What if you switch during a call to video? >=20 > What does carrier selection imply with IP Interconnect? > L5 Interconnect or also L3 transit? >=20 > A very nice example is if Core-O and Core-T is the same, e.g. running=20 > on the same server, do you still have to provide carrier selection if=20 > the call is now forced via the PSTN? >=20 This scenario may exist. I have heard about it as a requirement in some VoIP deployments. Medhavi. > Etc. etc. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) Thanks for the quick read=20 > > anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the=20 > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are=20 > > talking about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the=20 > > trapezoid. Sorry if it sounds confusing - we can fix that=20 > > problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really=20 > > affects the routing architecture selection (IMHO - it should not=20 > > have any effect) in the end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG=20 > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce carrier selection > > > within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I=20 > > can't promise if > > there > > are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 >=20 _______________________________________________ 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 17 14:14:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKP8-0006Qx-26; Fri, 17 Mar 2006 14:14:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKP6-0006QP-Nx for speermint@ietf.org; Fri, 17 Mar 2006 14:14:28 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKKP5-00027M-Ei for speermint@ietf.org; Fri, 17 Mar 2006 14:14:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] RE: Equal Access (wasI-Ddraft-bhatia-sip-peering-00.txt) Date: Fri, 17 Mar 2006 20:18:26 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48EC@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Equal Access (wasI-Ddraft-bhatia-sip-peering-00.txt) Thread-Index: AcY6l5Wcs3cU5YwcTvGw0Al8nv+FYgDkBeJgAAHNlVYAA8zasAAakj2wAA6AVFACwrjPgAABLvIgAAExjjU= From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" , , "Medhavi Bhatia" , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 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 Nice, but wong =20 BTW, the in Equel Access is not with p1 or p2 (this is anyway the case =20 It is with A =20 and how is the user doing this? He must do it in the request URI =20 entering sip:user@provider.net;cic=3D25 =20 or is this only possible dialing numbers? sip:10xxnumber@provider.net;user=3Ddialstring =20 Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: Fr 17.03.2006 19:42 An: br@brianrosen.net; Medhavi Bhatia; Stastny Richard; Livingood, = Jason; speermint@ietf.org Betreff: RE: [Speermint] RE: Equal Access = (wasI-Ddraft-bhatia-sip-peering-00.txt) I agree with Brian. We need to have more than one transit place. It can have two different scenarios: A -(p1)- B1 -(p2)- C \ / B2 A -(p1)--B1 --(p2)- C \ / B2 Both p1 and p2 need to have options to select either B1 or B2. Sohel Khan -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, March 17, 2006 12:29 PM To: 'Medhavi Bhatia'; 'Stastny Richard'; 'Livingood, Jason'; speermint@ietf.org Subject: RE: [Speermint] RE: Equal Access (wasI-Ddraft-bhatia-sip-peering-00.txt) Wading to the middle here... It seems to me that we would be wise to think about the ability to specify a transit network when there needs to be a transit network, and there is more than one available.=20 If I have four networks, A, B1, B2 and C, where the networks peer in more than one place, then I may have a transit network: A -(p1)- B1 -(p2)- C \ / B2 and I may wish to instruct p1 to use either B1 or B2. I may do that for a variety of reasons.=20 Brian -----Original Message----- From: Medhavi Bhatia [mailto:mbhatia@nextone.com] Sent: Friday, March 03, 2006 12:44 PM To: Stastny Richard; Livingood, Jason; speermint@ietf.org Subject: [Speermint] RE: Equal Access (was I-Ddraft-bhatia-sip-peering-00.txt) > This raises may questions such as: > if you are able to unbundle your access and are able to choose another > DSL provider, to you still need carrier selection? My personal opinion is that it may not be not required for the case you have above. I think for the WG purposes, the solution we come with for the Interconnect SP problem (in the other thread we have on the WG list) may also be used to solve this. An Access SP or Core SP which needs to provide this to the subscriber for whatever reason treats the LD carrier as an Interconnect SP. The LD Carrier will need to do another lookup to get to Core-T (which may be same as Core-O in this case). > > Is carrier selection only valid for voice and voice related services, > especially if the selected carrier still has only access via the PSTN? > What if you switch during a call to video? > > What does carrier selection imply with IP Interconnect? > L5 Interconnect or also L3 transit? > > A very nice example is if Core-O and Core-T is the same, e.g. running > on the same server, do you still have to provide carrier selection if > the call is now forced via the PSTN? > This scenario may exist. I have heard about it as a requirement in some VoIP deployments. Medhavi. > Etc. etc. > > Cheers > > Richard > > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, March 02, 2006 11:03 PM > > To: Stastny Richard; Livingood, Jason; speermint@ietf.org > > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > Hi Richard, > > > > Sorry about the headache... > > Hopefully my answers below will help :) Thanks for the quick read > > anyway. > > > > Cheers, > > Medhavi. > > > > > > > > >The purpose of this document is to help the IETF community > understand > > > > > > > the route architectures being used today in SIP based peering > > > > > > > environments and to outline a set of requirements based on the > > same > > > > > > > for discussion within the community > > > > > > > > > > > > Is this IMS in stealth mode? > > > > The intent of the draft is to describe what is deployed and the > > requirements driving that. We can choose to ignore or accept some of > > them based on WG discussion. > > > > (IMHO - I don't think IMS is deployed anywhere :) > > > > > > > > The abstract should clearly state: > > > > > > > > > > > > The purpose of this draft is to help the IETF community understand > IMS > > .. > > > > > > > > > > > > In particular I have problems with the following para: > > > > > > > > > > > > "The call is originated at calling party "O", (called the > > > "Origination" in this document) and terminates at called party "T" > > > (called the "Termination" in this document). T may be a > subscriber, > > > contact center, E911 operator etc. The first hop and the last hop > > of > > > the call in Figure 1 pass through SPs providing L5 (in our case > SIP) > > > access to the origination and termination and are called Access-O > > and > > > Access-T respectively. In most cases these SPs will also provide > > the > > > physical access to the origination and termination devices. The > > > Access SP function is not optional. While a separate Access SP > may > > > not exist, the function may be absorbed by the corresponding Core > > SP." > > > > > > A Core SP ALWAYS needs an Access SP if he is not providing the > access > > > by itself? In L5? > > > > > > > It says three things: (a) Access SP is mandatory (b) Access SP "may" > > provide > > physical access (c) Access SP can be absorbed within the Core SP. > Maybe > > the > > language can be improved, but I think we capture the case you are > > talking about - an ASP (Vonage) like scenario! > > > > > And then we also have Interconnect SP =3D Transit > > > > > > What happened to the SIP Trapeziod? > > > > > > > SIP Trapezoid is captured, since the Interconnect SP is optional > (first > > para on pg 4). > > However, I think there could be a special section devoted to that. > Note > > that in no way > > the draft is supposed to be prescriptive or designed to ignore the > > trapezoid. Sorry if it sounds confusing - we can fix that > > problem... > > > > Also, Note that Inteconnect SPs today don't map to "Transit" as > defined > > in requirements > > draft. > > > > > and may I remember on the req draft > > > > > > "3.6.2. Layer 5 Peering > > > > > > Layer 5 peering refers to interconnection of two service > providers > > > for the purposes of SIP signaling. Note that in the layer 5 > > peering > > > case, there is no intervening network. That is, for purposes of > > this > > > discussion, there is no such thing as a "Layer 5 Transit > Network"." > > > > > > The next problem I have with section > > > > > > > I think maybe the draft needs to clarify that Interconnect SP is not > the > > same as Transit. > > We can try to do this if lot of people feel the same and it really > > affects the routing architecture selection (IMHO - it should not > > have any effect) in the end. > > > > > > > > > > > "5.2. Addressing > > > > > > The type of A-O-R for the termination may also affect what kind > of > > > address location service is used. Address location is done > > typically > > > based on the following four characteristics of the termination's > > AOR. > > > In each case, we list the most common address location method > used. > > > > > > > > > 1. Full E.164: ENUM or SP's local policy may be used. > > > 2. E.164 prefixes: SPs local policy is generally used. > > > 3. Full A-O-R: This is rarely used for routing in a peering > > > environment. > > > 4. Domain of A-O-R: DNS SRV or SPs local policy may be used." > > > > > > > > > > > > Within SPEERMINT only Call Routing Data (CRD) are used > > > > > > E.164 numbers are not CRD, they are also not A-o-R, > > > > > > E.164 numbers are names > > > > > > so E.164 number is out of scope in SPEERMENT > > > > > > > I am not sure what I need to fix, but we can address it after WG > > discussion. > > > > > > > > And IMHO completely off is the idea to introduce carrier selection > > > within VoIP > > > > > > " For example Equal Access is > > > a LEC (Local Exchange Carrier) requirement and an SP operating as > > an > > > LEC may be required to allow the subscriber his/her choice of IXC > > > (IntereXchange Carrier) for certain set of calls. In essence, > > these > > > requirements may affect route policy for peering where the > > downstream > > > peer is chosen based on origination's policy. In this case, the > > > Core-O and Core-T may be one and the same SP who peer through an > > > Interconnect SP of the origination's choice." > > > > > > > Equal Access gives a headache to anyone dealing with VoIP :). I think > it > > is good to know what some VoIP SPs are dealing with especially when we > > are starting discussions in the WG. As the draft says in the last > para > > - it is > > possible that this may affect only a minor set of deployments in the > > end. Time will tell. Also, Equal Access is simply an example (I > > can't promise if > > there > > are not a host of other scenarios out there). > > > > Thanks, > > Medhavi. > > > > > > > > > I have an headache > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Gesendet: Do 02.03.2006 19:33 > > > An: speermint@ietf.org > > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > FYI for the WG on this draft. This is on the tentative agenda at > the > > Dallas meeting (should > > > be finalized shortly). > > > > > > Jason > > > > > > ________________________________ > > > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Sunday, February 26, 2006 12:44 AM > > > To: internet-drafts@ietf.org > > > Cc: dmm@1-4-5.net; Livingood, Jason > > > Subject: I-D draft-bhatia-sip-peering-00.txt > > > > > > > > > > > > Abstract > > > > > > > > > > > > The purpose of this document is to help the IETF community > > understand > > > > > > the route architectures being used today in SIP based peering > > > > > > environments and to outline a set of requirements based on the > same > > > > > > for discussion within the community. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: > > 3/1/2006 > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 > _______________________________________________ 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Mar 21 10:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiby-0008By-EN; Tue, 21 Mar 2006 10:17:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLibx-0008Bt-BX for speermint@ietf.org; Tue, 21 Mar 2006 10:17:29 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLibw-0003RX-1f for speermint@ietf.org; Tue, 21 Mar 2006 10:17:29 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 10:17:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Mar 2006 10:17:27 -0500 Message-ID: <8812D8156467224C9E9739E513037EF1419704@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bhatia-sip-peering-00 thread-index: AcZM+pCATBUH9iQCRk+MXf7BLvVPug== From: "Medhavi Bhatia" To: X-OriginalArrivalTime: 21 Mar 2006 15:17:27.0422 (UTC) FILETIME=[905D81E0:01C64CFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: "Livingood, Jason" Subject: [Speermint] draft-bhatia-sip-peering-00 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="===============0124521694==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0124521694== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64CFA.E759C896" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64CFA.E759C896 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks,=20 =20 Here are my suggestions for the next rev: =20 - Re-organize use cases and the corresponding architectures (direct, interconnect SP, federation etc). - Add new use cases for how interconnects/federations should be used when peering between two SPs - Add text to describe how/where policies should be applied (should/should not etc) in the use cases. - Add message flows for any confusing use cases =20 I think the document can be used for the WG items "architecture and message flows". =20 Comments/alternate ideas? =20 -Medhavi. ------_=_NextPart_001_01C64CFA.E759C896 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Here are my suggestions for the next = rev:

 

-        Re-organize use cases and = the corresponding architectures (direct, interconnect SP, federation = etc).

-        Add new use cases for how interconnects/federations should be used when peering between two = SPs

-        Add text to describe = how/where policies should be applied (should/should not etc) in the use = cases.

-        Add message flows for any confusing use cases

 

I think the document can be used for the WG items = “architecture and message flows”.

 

Comments/alternate ideas?

 

-Medhavi.

------_=_NextPart_001_01C64CFA.E759C896-- --===============0124521694== 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 --===============0124521694==-- From speermint-bounces@ietf.org Tue Mar 21 15:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnFn-00021j-BP; Tue, 21 Mar 2006 15:14:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnFm-00021e-So for speermint@ietf.org; Tue, 21 Mar 2006 15:14:54 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLnFm-00070b-FT for speermint@ietf.org; Tue, 21 Mar 2006 15:14:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 21:18:53 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4904@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions for Clarification Thread-Index: AcZNJKxxD0TgZv1yTmSF/g8Bxpoazg== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Speermint] Questions for Clarification 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 I have some questions for clarification regarding the SPEERMINT charter (or in ITU-T speak: Mr Chairman, I am confused) =20 "SPEERMINT focuses (on) architectures to identify, signal, and route delay-sensitive (real-time) communication sessions. These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks. Where these domains peer, or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations." First question: the term IP networks seems to need clarification: IP networks is a generic term valid for both the Internet and private (walled garden) IP networks, but =20 I had always the opinion that this is the INTERNET Engineering Task Force (IETF) and the PRIMARY goal is to define architectures to identify, signal and route ... sessions on the public INTERNET. =20 This does not prevent anybody to use these architectures and related=20 protocols also on private IP networks, as it is done with other = protocols and architectures (e.g. the DNS). But is is NOT the task of the IETF to define such architectures and protocols PRIMARILY for the use in private IP networks. =20 So I undersatnd that the primary goal of SPEERMINT is to enable peering between two or more administrative domains on the INTERNET. =20 and also to establich trust, security ans resistance to abuse and = attacks on the Internet. =20 I consider it therefore curious that some say the I-Ds = draft-lendl-domain-policy-ddds-00 and draft-lendl-speermint-federation-00 are out of scope. If these = drafts are out-of-scope then maybe somebody would be so nice to explain to me what is in scope = of SPEERMINT. =20 I am also confused about the statement from Rohan that nobody will use = this because no provider will make public to which federation he belongs to. =20 Since this drafts are modelled along the quite sucessful model of BGP = peering, I wonder. =20 Imagine yor airline has a frequent flyer program, but not disclosing = that it is part of=20 Star Alliance. =20 It is true that SPEERMINT is special (optional?) within the IETF, = because to peer between SIP proxies on the Internet all you need is SIP AoRs and RFC 3263 NAPTR = and SRV, and I also understand that the major problem of the VSP starts with the = SIP URI giving away their identity (some peering fabrics make a living on this ;-) =20 Nobody seems to have a problem with this with e-mail =20 Voice is really a special application, infecting anybody with = bell-headism =20 best regards =20 Richard =20 =20 =20 =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 22 11:49:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6WF-00028y-1n; Wed, 22 Mar 2006 11:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6WD-00026K-UE for speermint@ietf.org; Wed, 22 Mar 2006 11:49:09 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6WC-0007ct-Ez for speermint@ietf.org; Wed, 22 Mar 2006 11:49:09 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 79B6C1A3C0; Wed, 22 Mar 2006 17:49:06 +0100 (CET) Date: Wed, 22 Mar 2006 17:49:06 +0100 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20060322164906.GC19817@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Speermint] domain-policy-ddds-00: SPIT question 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 [I'm listening to the webcast from monday again, and try to answer a few question that came up during the presentaion of http://www3.ietf.org/proceedings/06mar/slides/speermint-3.ppt ] On slide 2 we stated that some SIP networks do not want to interconnect using the open Internet model (as in the email case) because of the fear of SPIT. Someone (I think Jonathan; the microphone discipline wasn't that good) remarked that he doubts that anybody can claim to have solved the SPIT problem. Thus, some clarifications: * I'm not talking about RFC-compliant, open SIP servers on the public Internet who are per definition interconnected. IMHO they don't need speermint. I try to cover them as a special case but they are not the focus of this draft. Please keep that in mind. * There are VoIP carriers who use SIP internally but refuse to accept calls from anybody over the Internet because they fear SPIT. * These VSPs *do* accept calls via the PSTN where there are solutions and policies in place which mitigate the problem of unsolicted calls. (DNC-lists, laws, tracking capabilities, ...) * Thus: If we want to get such VSPs to peer with each other using SIP we have to give them the means to open up their networks in a controlled and selective way. If it is a binary choice between "No IP-interconnect" and "accept calls from anybody on the Internet", then a significant number of VSPs will opt for "No IP-interconnect". Of course, manually configured peerings between two VSPs work in the meantime. But this runs into severe scalalibity problems very quickly. * Thus: If we can offer a solution which enables them to control with whom they peer then the SPIT problem is manageable. After all, contrary to email, you can shut down a SIP peering without affecting reachability as the calls fall back to the PSTN. Example: If a VSP opens up his SIP proxy to the set of other VSPs with whom he already has a PSTN/SS7 interconnect, then he does not introduce a new vector for SPIT into his network. Or: To much SPIT coming in from $country? Drop the SIP peering and let them call you via PSTN. The main difference to email is the following: Email (at least on the Internet) started out as a fully connected network: everybody talks to everybody. There is no backup if you block a transmission. Spam-filters usually work by elimitating unwanted communication. Voice is different: A lot of people used SIP to build islands of VoIP interconnected via the PSTN. For them, we're trying to establish direct communication paths. SPIT is controlled by only opening up to explicitly wanted communication partners. Back to the $country example: You can't just tell your customers that you won't accept any email from $country due to spam originating there, but you don't need to tell your customers whether that caller from $country reaches you via SIP or the PSTN. Summary: * Jonathan (or whoever that was) is correct that this draft does not solve the SPIT problem for the open SIP proxy case. * It is not designed to solve that problem. * It just offers a gradual path for SIP islands to start interconnecting to each other. SPIT is just one reason why VSPs will want to have that capability. There this still controversial? If yes, which points are disputed? /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 Wed Mar 22 12:38:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7HR-000514-5b; Wed, 22 Mar 2006 12:37:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7HQ-00050z-Cf for speermint@ietf.org; Wed, 22 Mar 2006 12:37:56 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7HO-0000zY-Ur for speermint@ietf.org; Wed, 22 Mar 2006 12:37:56 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 043E41A3C0; Wed, 22 Mar 2006 18:37:53 +0100 (CET) Date: Wed, 22 Mar 2006 18:37:53 +0100 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20060322173753.GD19817@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Speermint] domain-policy-ddds-00: federations 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 the second followup to monday's WG discussion on this draft.] Regarding the definition of "federation": The definition in draft-lendl-speermint-federations-00 has a simple focus: Call routing. A shared federation membership means I can reach the other VSP though that federation. This is just like IP networking 101 where we have the fact that two hosts in the same subnet can talk to each other directly. There the L3 routing logic contains the simple step: * Do I have an interface with an IP-address that lies in the same subnet as the destination adress? If yes, use rules of the L2 infrastructure of that interface to transport the packet. My federation definition does the same for SIP: * Am I a member of any federation where the destination is also a member? If yes, do whatever that federation proscribes to route the call. -- As I read draft-ietf-sipping-trait-authz-02 (btw, are there any other documents on TRAITS? I haven't found any.), the proposal there is to * embed cryptographic tokens into SIP messages which assert some attribute of the sender. E.g. "I'm a valid user of provider XXX", "I'm a student of XXX", "I can settle bills using YYY". * Members of a TRAITS federation honor each other's assertions. As I see it, TRAITS is a framework on how to communicate attributes and it will defined a concrete set of protocols how to authenticate message to build trust relationships. It's a "how to do something" idea. My federation definition doesn't care how federations authenticate members and how the trust is established. It's a "Can I use it to do X"- kind of definition. For all I care it can be a bunch of access lists on the firewall of the participating VSPs. A TRAITs federation can be used to implement a federation as defined in draft-lendl-speermint-federations-00. e.g. "all calls with the TRAIT "valid-user" signed by any member of this federation will be accepted over the public Internet by all other members of the federation." Not all TRAIT-federations are federations as defined in my draft. Just because members recognize each other's trait tags, this does not necessarily mean that they will accept calls from each other. On the other hand, using TRAITs is just one way of implementing a federation for sip peering. You can do that using a walled garden or TLS certs and without touching SIP headers. Further remarks: * The set of all open SIP servers on the public Internet fulfills the definition of a federation as well. * So does the set of two VSPs which have a private peering relationship. * I'm very much open to an alternative name for my federation concept. If that's what it takes to reduce the confusion, bring it on. Comments? /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 Wed Mar 22 23:22:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMHKj-0006AW-HL; Wed, 22 Mar 2006 23:22:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMHKi-00066r-6I for speermint@ietf.org; Wed, 22 Mar 2006 23:22:00 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMHKg-0005BK-OV for speermint@ietf.org; Wed, 22 Mar 2006 23:22:00 -0500 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.02) id A26706D4; Wed, 22 Mar 2006 23:21:59 -0500 From: "Patrick Melampy" To: , Subject: RE: [Speermint] Draft-wing-session-auth-00: Media Session Authorization Date: Wed, 22 Mar 2006 23:21:57 -0500 Message-ID: <004601c64e31$52fdda10$6701a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaA= In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E061019F9@PLSWB08C.ad.sprint.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 I have been studying this draft and have I think an important comment. The firewalls shown in the diagrams and described in the text should be replaced or further described as to their function. Specifically, most firewalls typically perform a NAT, and indeed a NAT at the edge of a carrier network would break the "natural routing" benefits of this proposal. I would suggest in text and diagrams to clarify the firewall as either a filter or a nat. I also would suggest discussing a few additional potential downsides to this approach. One would be that if "natural routing" is used, there will need to be a firewall-filter on each and every path that could support this route. Thus the downside is that for a large network with many physical peering interconnections, there would need to be a firewall-filter on every interface. I also would like to suggest an improvement to this architecture. That would be to optionally have the firewalls perform a NAT. In this mode, the STUN message would be NAT'ed on its way to the destination AFTER the policy look-up. This may allow the policy server to instantiate a translation before the STUN message is returned to its egress processing at the firewall-nat device. Advantages here would include being able to interwork with RFC1918 addressed devices in the network your interconnecting with. Additional advantages are that this would permit reduction of the number of physical interfaces requiring a firewall-nat since you could now use a /32 route to represent the entire destination network restricting that route to a handful of interconnect points. This would waste a real IP address, but it may well be worth it given the savings on the alternative of equipping every interface between the two networks. One minor suggestion would be to replace the references of "natural routing" with something that is more accurate. The reason for this is that I do not know what you mean by the opposite - unnatural routing. And then there is always the possibility of supernatural routing. Not being a routing expert I don't want to suggest a term here and I know what you mean is BGP4 or OSPF based packet forwarding mechanism. But I would suggest it could be more accurately defined. Finally - at the working group you presented a diagram showing BOB trying to talk to ALICE. I know that the values of the IETF are to not build any walled gardens -- but I worry that if BOB wanted to send a STUN packet or even a RTP packet to alice that wasn't part of the peering arrangement, then the packet would be dropped. This would in effect cause the path to not be used for best efforts uses. While this is good and desired for peering interconnect, if Natural Routing is used, the Natural Routers would have to be Super Natural Routers to figure out how to route around those stun and RTP messages being used by Google Talk or other service providers that Bob or Alice might want to use. _______________________________________________ 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 Thu Mar 23 05:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMN8l-0008Mj-Cz; Thu, 23 Mar 2006 05:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMN6h-0006A2-P1 for speermint@ietf.org; Thu, 23 Mar 2006 05:31:55 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMN3a-0003Du-5T for speermint@ietf.org; Thu, 23 Mar 2006 05:28:43 -0500 Received: from mah9.inode.at ([204.96.112.194]) by server (8.12.8/8.12.8) with SMTP id k2N91R2x010215; Thu, 23 Mar 2006 04:01:38 -0500 Message-Id: <7.0.1.0.2.20060323103555.038b9bb8@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 23 Mar 2006 11:28:29 +0100 To: "Stastny Richard" , From: Michael Haberler Subject: Re: [Speermint] Questions for Clarification In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4904@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C4904@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-73693FDA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 At 21:18 21.03.2006, Stastny Richard wrote: >I am also confused about the statement from Rohan that nobody will >use this because no >provider will make public to which federation he belongs to. I'd be very interested what people believe to be a viable alternative to runtime policy discovery - in particular visavis the fact that the draft-lendl-domain-policy-ddds-00 proposes to pubish a unique ID for a policy to enable runtime matching, but NOT requiring to publish what that policy ID actually stands for. In BGP speak this amounts to: "Here is my AS number. You might find that AS number tacked to other domains if you scan a lot of them, but no, we are not publishing our peering and transit relations in an RIR database". As for the BT example, saying that the sip.bt.com ingress point supports the BT IP interconnect policy, which is likely to be found on a BT website as their Reference Interconnect Offer in the first place. So much for the danger of "private parts exposure". I have a hard time believing we are back to static local configuration as the "preferred" solution, be that bilateral setup or "everything goes to my peering shop". Here's a paper exercise for you to tinker with alternatives: With SIP capabilites as they stand today, please emulate the GSM association - that's 600+ operators with some 23.000 interconnect agreements. In the first attempt, try to avoid the "big SIP hub" scenario for extra intellectual challenge. After done with defining pathetic access lists and local routing tables, I assume you're motivated to think about alternatives. Then again, if one has gobs of staff managing interconnect relations, that staff could well eventually be retrained to edit access control lists and tables. From a commercial point of view, there likely is a business case for the SIP hubs/peering providers. I think they have real value as SIP/RTP cleansing shops. I'm not sure that approach should be the IETF entropy solution to fabric discovery. And, while lashing out at the unsuitability of draft-lendl-domain-policy-ddds-00 for current service provider mindsets, keep in mind it does not limit itself to "carriers" - it does address groups of users, and in fact the user-service provider interface policy discovery problems just as well. Bonus value: it also includes "go to my peering shop" - besides keeping the end-to-end option open. -Michael _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 23 22:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMcvi-0008WQ-Sg; Thu, 23 Mar 2006 22:25:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMcvh-0008Ul-Ly for speermint@ietf.org; Thu, 23 Mar 2006 22:25:37 -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 1FMcvg-0000e8-90 for speermint@ietf.org; Thu, 23 Mar 2006 22:25:37 -0500 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.18016155; Thu, 23 Mar 2006 22:20:52 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 22:23:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Questions for Clarification Date: Thu, 23 Mar 2006 22:23:41 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A703@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Questions for Clarification Thread-Index: AcZNJKxxD0TgZv1yTmSF/g8BxpoazgBzJqMQ From: "Livingood, Jason" To: "Stastny Richard" , X-OriginalArrivalTime: 24 Mar 2006 03:23:42.0835 (UTC) FILETIME=[5A295C30:01C64EF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 > I consider it therefore curious that some say the I-Ds=20 > draft-lendl-domain-policy-ddds-00 and=20 > draft-lendl-speermint-federation-00 are out of scope. If=20 > these drafts are out-of-scope then maybe somebody would be so=20 > nice to explain to me what is in scope of SPEERMINT. It may be that they will be useful in time, but that we're not ready for them yet as a WG. The first WG session in Dallas produced some very interesting and varied drafts that covered a lot of ground. That there was not yet universal agreement on things as of yet, I think is quite natural. However, we're going to start to focus more on some of the immediate milestones of the WG so that we can generate some positive forward momentum. In addition, as I said in the WG session, we have to start off laying a strong foundation first before we can climb upward to more complex issues. We will get there in time... Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 24 00:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMeSj-00027l-Gy; Fri, 24 Mar 2006 00:03:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMeSh-00026k-N2 for speermint@ietf.org; Fri, 24 Mar 2006 00:03:47 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMeSg-0004nU-EZ for speermint@ietf.org; Fri, 24 Mar 2006 00:03:47 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 23 Mar 2006 21:03:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,124,1141632000"; d="scan'208"; a="538443962:sNHT22564860" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Mar 2006 00:03:44 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE579@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-bhatia-sip-peering-00.txt Thread-Index: AcZNJKxxD0TgZv1yTmSF/g8BxpoazgBzJqMQAALWuwA= From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Speermint] Comments on draft-bhatia-sip-peering-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 Hi, I haven't been following the discussions closely but so maybe some topics might have already being raised. I think this draft is a good starting point. It touches on many issues that need to be hashed out in detail. In my opinion the decomposed scenario (where signaling and media take different paths) is the one where the interaction between SIP and Layer 3-4 (as mentioned in the charter) is most important. I've been working on this area and it seems to me all "business issues" discussed in 5.3.X area actual technical issues to be solved. How does a policy decision point like a SBC/EdgeProxy convey the necessary information to a policy enforcement point like "peering" router? Or even more than one? Which information would be relayed (QoS, FW pinholes, NAT, etc)?=20 Is somebody going to jump and say MIDCOM? Diameter? Or maybe Megaco/H.248? How to reconcile such scenarios with the work done in TISPAN and IMS? I believe these are valid questions. I believe khan's draft touches the issue from an overall perspective. I remember someone made a comment about it seeming to be an IMS look alike, but the fact of the matter is that although the problem statements are different, the architecture (or device nomenclature?) used in 3GPP/TISPAN fits very well with the scenarios. I wonder if somebody is willing to work on a draft expanding on the technical issues for SIP<->Layer 3-4 interactions for a decomposed scenario (which encompasses the coupled scenario). I've started it but would not mind help with the writing. Regards, Reinaldo _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 24 09:58:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnkX-0006FA-H5; Fri, 24 Mar 2006 09:58:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnkW-0006EC-9J for speermint@ietf.org; Fri, 24 Mar 2006 09:58:48 -0500 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMnkV-0002vL-26 for speermint@ietf.org; Fri, 24 Mar 2006 09:58:48 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 09:58:46 -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] Comments on draft-bhatia-sip-peering-00.txt Date: Fri, 24 Mar 2006 09:58:41 -0500 Message-ID: <8812D8156467224C9E9739E513037EF145DD92@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on draft-bhatia-sip-peering-00.txt thread-index: AcZNJKxxD0TgZv1yTmSF/g8BxpoazgBzJqMQAALWuwAAFPFdoA== From: "Medhavi Bhatia" To: "Reinaldo Penno" , X-OriginalArrivalTime: 24 Mar 2006 14:58:46.0273 (UTC) FILETIME=[7358FF10:01C64F53] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Hi Reinaldo, >=20 > In my opinion the decomposed scenario (where signaling and media take > different paths) is the one where the interaction between SIP and Layer > 3-4 (as mentioned in the charter) is most important. >=20 I think this is in the charter of the WG, but the current draft touches on media only for making informative route decisions (really peer selection). There are good chances that this part of the solution will evolve as the SIP implementations/specs evolve. The focus of this draft is routing only and the related use cases. > I've been working on this area and it seems to me all "business issues" > discussed in 5.3.X area actual technical issues to be solved. How does > a policy decision point like a SBC/EdgeProxy convey the necessary > information to a policy enforcement point like "peering" router? Or even > more than one? Which information would be relayed (QoS, FW pinholes, > NAT, etc)? >=20 > Is somebody going to jump and say MIDCOM? Diameter? Or maybe > Megaco/H.248? >=20 My personal view is that these protocols are more for a master/slave control. In peering, this is really not the case and I don't think the carriers involved will actually like such a solution (interdomain MEGACO etc). > How to reconcile such scenarios with the work done in TISPAN and IMS? I > believe these are valid questions. I believe khan's draft touches the > issue from an overall perspective. I remember someone made a comment > about it seeming to be an IMS look alike, but the fact of the matter is > that although the problem statements are different, the architecture (or > device nomenclature?) used in 3GPP/TISPAN fits very well with the > scenarios. Those are good issues for the WG, but the context of this draft is fairly general to IETF. Unless IMS alters a use case or has a requirement which affects us (you may know more than I do...), I think we should keep the scope contained (however I am open to ideas based on how the WG may decide to move ahead). -Medhavi. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 24 11:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpP6-0003YA-L2; Fri, 24 Mar 2006 11:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpP5-0003Xq-E9 for speermint@ietf.org; Fri, 24 Mar 2006 11:44:47 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMpP3-0008K1-Ms for speermint@ietf.org; Fri, 24 Mar 2006 11:44:47 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 6D2A61A3D5; Fri, 24 Mar 2006 17:44:43 +0100 (CET) Date: Fri, 24 Mar 2006 17:44:43 +0100 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20060324164443.GA7580@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Speermint] domain-policy-ddds-00: Why DNS and not SIP 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 the third followup to monday's WG discussion on this draft.] There were two questions (Rohan and Jonathan) concerning why all this DNS busines is necessary and helpful. After all, there are mechnisms within SIP to reject calls and the "consent framework" can be used to establish fine-tuned access control. The reason we're not basing our solution on SIP is the following: When looking at the target audience for Speermint we found: * Some VSPs don't want to have their SIP proxies exposed to the public Internet fearing DoS and other attacks. They thus use firewalls to allow incoming SIP packets only from pre-approved addresses. * Most of the peering fabrics popping up at Internet Exchange Points use a private L2/3 infrastructure which is not reachable from the public Internet. * 3GPP and others (ETSI's NGN, the CableCos) are builing their interconnects on a private network seperated from the Internet. In these cases you can't use SIP to query whether they will accept calls from you. Sure, you can try but the most likely response will be a timeout. If you're lucky you'll get an ICMP error message. Maybe. Call-setup is a time-critical procedure. Callers don't tolerate gratuitous delays. So your choice is to either * use extremely short timeouts on the SIP try or * use an out-of-band (in terms of SIP) procedure. Furthermore, we have: * Some peering fabrics operate in a SIP-hub mode: All calls between participating VSPs are routed via a central SIP proxy. * Some peering fabrics require special TLS certs to be used to connect to the SIP proxies. !! In these cases you have to know the destination's federation !! affiliation before you can reach them via SIP. Some of these things could be solved via appropriate SRV records, e.g. have them point at the central SIP hub in the first example. This quickly breaks down if a VSP participates in a number of different peering fabrics. This could be a very realistic scenario in a few years. What should the SRV records look like for e.g. 3G-example.com which is reachable via the GRX (using the SIP hubs used therein), the VoIP- VLANs at VIX, LINX and DE-CIX (which may very well exist in a few years), plus from a selected set of IP-addresses over the public Internet? Comments? /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 Fri Mar 24 16:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtrS-0000YP-Cc; Fri, 24 Mar 2006 16:30:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtrQ-0000YK-VD for speermint@ietf.org; Fri, 24 Mar 2006 16:30:20 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMtrO-0003y0-Mh for speermint@ietf.org; Fri, 24 Mar 2006 16:30:20 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 24 Mar 2006 13:30:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,126,1141632000"; d="scan'208"; a="538602859:sNHT22849300" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Comments on draft-bhatia-sip-peering-00.txt Date: Fri, 24 Mar 2006 16:30:13 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE57E@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on draft-bhatia-sip-peering-00.txt Thread-Index: AcZNJKxxD0TgZv1yTmSF/g8BxpoazgBzJqMQAALWuwAAFPFdoAAOUDNQ From: "Reinaldo Penno" To: "Medhavi Bhatia" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 > > >=20 > My personal view is that these protocols are more for a master/slave > control. In peering, this is really not the case and I don't think the > carriers involved will actually like such a solution (interdomain MEGACO > etc). >=20 [[Reinaldo]]=20 It is not really interdomain. I guess the main point is how do you convey policy decision based on SIP URIs, domains, agreements and so forth to the devices that are going to handle the media "your" domain and the other. >=20 > > How to reconcile such scenarios with the work done in TISPAN and IMS? > I > > believe these are valid questions. I believe khan's draft touches the > > issue from an overall perspective. I remember someone made a comment > > about it seeming to be an IMS look alike, but the fact of the matter > is > > that although the problem statements are different, the architecture > (or > > device nomenclature?) used in 3GPP/TISPAN fits very well with the > > scenarios. >=20 > Those are good issues for the WG, but the context of this draft is > fairly general to IETF. Unless IMS alters a use case or has a > requirement which affects us (you may know more than I do...), I think > we should keep the scope contained (however I am open to ideas based on > how the WG may decide to move ahead). >=20 >=20 > -Medhavi. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Mar 27 19:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2Ka-0005rv-Cg; Mon, 27 Mar 2006 19:45:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2KZ-0005rq-7J for speermint@ietf.org; Mon, 27 Mar 2006 19:45:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO2KY-0005Jl-TQ for speermint@ietf.org; Mon, 27 Mar 2006 19:45:07 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 27 Mar 2006 16:45:07 -0800 X-IronPort-AV: i="4.03,136,1141632000"; d="scan'208"; a="1788913401:sNHT33766608" Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2S0j5Yg020192; Mon, 27 Mar 2006 16:45:06 -0800 (PST) From: "Dan Wing" To: "'Patrick Melampy'" , Subject: RE: [Speermint] Draft-wing-session-auth-00: Media Session Authorization Date: Mon, 27 Mar 2006 16:45:05 -0800 Keywords: direct-to-dwing Message-ID: <132201c65200$db2c9ed0$1e73150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <004601c64e31$52fdda10$6701a8c0@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 > I have been studying this draft and have I think an important > comment. The firewalls shown in the diagrams and described in the > text should be replaced or further described as to their function. > > Specifically, most firewalls typically perform a NAT, and indeed a > NAT at the edge of a carrier network would break the "natural > routing" benefits of this proposal. I agree. However, the reason ITSPs like to hide the IP address of remote endpoints is to hide the business relationship to the next-hop ITSP, and to force the RTP traffic to stay on their own network so they can charge for delivery of a service and to monitor that RTP traffic (such as for MOS monitoring). Not all businesses need or want to do that. > I would suggest in text and diagrams to clarify the firewall as > either a filter or a nat. > > I also would suggest discussing a few additional potential downsides > to this approach. One would be that if "natural routing" is used, > there will need to be a firewall-filter on each and every path that > could support this route. Thus the downside is that for a large > network with many physical peering interconnections, there would > need to be a firewall-filter on every interface. Ok. > I also would like to suggest an improvement to this architecture. > That would be to optionally have the firewalls perform a NAT. In > this mode, the STUN message would be NAT'ed on its way to the > destination AFTER the policy look-up. This may allow the policy > server to instantiate a translation before the STUN message is > returned to its egress processing at the firewall-nat device. > Advantages here would include being able to interwork with RFC1918 > addressed devices in the network your interconnecting with. > Additional advantages are that this would permit reduction of the > number of physical interfaces requiring a firewall-nat since you > could now use a /32 route to represent the entire destination > network restricting that route to a handful of interconnect points. > This would waste a real IP address, but it may well be worth it > given the savings on the alternative of equipping every interface > between the two networks. An implementor building a box that does both NAT functions and implements -wing-session-auth would very likely build such a box like that, yes. > One minor suggestion would be to replace the references of "natural > routing" with something that is more accurate. The reason for this > is that I do not know what you mean by the opposite - unnatural > routing. Routing from Alice directly to Bob, without sending IP packets to a media relay device or a media proxy device. Obviously if Alice or Bob have a NAT in front of them, you'll be sending the packets to the NAT, but that isn't avoidable. > And then there is always the possibility of supernatural > routing. Not being a routing expert I don't want to suggest a term > here and I know what you mean is BGP4 or OSPF based packet > forwarding mechanism. But I would suggest it could be more > accurately defined. Ok. > Finally - at the working group you presented a diagram showing BOB > trying to talk to ALICE. I know that the values of the IETF are to > not build any walled gardens -- but I worry that if BOB wanted to > send a STUN packet or even a RTP packet to alice that wasn't part of > the peering arrangement, then the packet would be dropped. > This > would in effect cause the path to not be used for best efforts uses. > While this is good and desired for peering interconnect, if Natural > Routing is used, the Natural Routers would have to be Super Natural > Routers to figure out how to route around those stun and RTP > messages being used by Google Talk or other service providers that > Bob or Alice might want to use. Unfortunately my SPEERMINT presentation poorly represented the value of -wing-session-auth to the SPEERMINT working group. The draft (and my presentation) describes how you might use media session authorization to completely deny UDP packets to or from an endpoint. That is the common firewall policy at many enterprises. Of course, for an ISP offering Internet connectivity, dropping UDP packets to or from an endpoint is not their standard policy. Instead, their standard policy is to permit such packets. Such an ISP may additionally wish to offer better QoS on the access link for UDP flows that are associated with flows that are signaled -- such as flows signaled via the mechanism described in -wing-session-policy. Thank you for reviewing my I-D and seeing the applicability of this technology to peering. -d _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Mar 28 16:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLpI-0002sz-Do; Tue, 28 Mar 2006 16:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLpH-0002nf-6f for speermint@ietf.org; Tue, 28 Mar 2006 16:34:07 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOLpE-00008o-SE for speermint@ietf.org; Tue, 28 Mar 2006 16:34:07 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 28 Mar 2006 13:34:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,140,1141632000"; d="scan'208"; a="536415018:sNHT27312052" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Mar 2006 16:34:03 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE58E@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on reqs-and-terminology-01 and policy-dds-00 (Peerign concepts and others..) Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeeg From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00 (Peerign concepts and others..) 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 Hello, I've been reading "reqs and terminology" and I would like to step back and ask some questions about some of the definitions. Peering: =3D=3D=3D=3D=3D=3D=3D=3D In layer 3 peering two routers exchange their routing tables, reach a steady state, and after that data packets can flow between the two domains. Layer 5 peering means, "interconnection of two service providers for the purposes of SIP signaling".=20 Making the inevitable comparison with layer 3 peering, there are some fundamental differences that I'm trying to reconcile. 1) In a traditional (a.k.a. layer 3) peering, both routers exchange all necessary routing information and enter a steady state. At this point, no other routes are exchanged and routers concentrate on forwarding packets. I know the WG is in the beginning, but it is not clear to me what pieces are needed for an equivalent functionality. For example: 1) Are the entities exchanging SIP signaling for the purpose of peering doing so on a _per call_ basis? Is there going to be some mechanism to exchange such information in bulk such as in a routing protocol? Maybe based on domain names or something similar? 2) The draft states that " A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI)." So, it seems to me that although the "layer 5 peering" is happening between the two entities exchanging SIP signaling, the peering point discovery is a result of a SRV query. But the draft also states that " SPEERMINT Working Group is focused on the use of such CRD." Draft peering-policy states that " This documents proposes the use of DNS entries to publish a SIP proxy's policy for accepting incoming calls" proposes DNS as a way of exchange polices. This begs the question of what are the two "peering" entities really doing besides exchange traditional SIP signaling? It seems the real _information peering_ (for the lack of a better term) is happening between DNS servers. All important information related to "peering" is coming from a DNS server which might as well be on your own domain (if your exchange DNS information).=20 In summary, it seems to me the whole architecture is quite a departure from layer 3 peering where the entities peering are the holders of the necessary information to allow data packets to flow. Here the entities peering publish their peering information to third party server which does the actual "peering" (exchange inter-domain information). Anyway, the idea of the mail is to try to clarify things. There is much emphasis on SIP but it seems DNS plays a more central role. Or maybe some SIP extension will be made to exchange peering policies? Policies and Independence of lower layers: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP exchange QoS and VPN information, performs discovery, etc. This implies that BGP indirectly (or directly) knows the capabilities of the transport layer (thus the name capability negotiation). So, although the mechanism to exchange the actual policies needs to be independent of the lower layers, there needs to be a way to input lower layer information into the devices exchanging the policies. Just like BGP has filters and priorities based on a myriad of options. So, maybe the wording should change a little. As far as 5.6 goes, it seems to me the policies can be quite complex. The experience of BGP tells us that in the end policies can be huge. So, if policies are going to be huge, what draft dds-00 states as a possibility=20 " If the simple boolean logic and the limited space in the DNS answers are insufficient for an application then a type of policy rule URIs can be defined which links to policy statements written in a fully featured policy description language like SAML [14] or XACML [15]." will actually going to be the rule. So, this begs the question of DNS is a good choice to publish peering policies.=20 Thanks, Reinaldo _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Mar 28 17:49:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOMzv-00039s-2u; Tue, 28 Mar 2006 17:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOMzs-0002zD-TZ for speermint@ietf.org; Tue, 28 Mar 2006 17:49:08 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOMzs-0002Mb-4v for speermint@ietf.org; Tue, 28 Mar 2006 17:49:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..) Date: Wed, 29 Mar 2006 00:53:07 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C493E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..) Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAOCTHM= From: "Stastny Richard" To: "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 Hi all, =20 Thank you Reinaldo for opening up the discussion on peering and = interconnect, after the shocked quiet period after the meeting ;-) =20 I agree with you that we have to step back (maybe even two steps) after = this Speermint meeting and reconsider what we want to achieve. =20 Lets reconsider what we are talking about: =20 Speermint is primarily about interconnecting sip proxies at L5 the L5 in SIP is a location service =20 two SP have the task to find out for their users (customers) the IP addresses to allow them to establish a session and finally exchange IP packets on L3. =20 We also could define this in another way: a SP is giving out to their customers a public user identity, in SIP also called an Address-of-Record. Note the term PUBLIC. =20 If I get a public user identity from a SP, I assume to be able to give = this to somebody else and he/she is able to reach me via a public communications network (note that I do not mention here the Internet, also a walled garden network such as Vonage is a public communications network)- Ok they are not giving out AoRs =20 So if I use this public user identity in any other public "network" accepting SIP URIs (in the definition of Speermint) or with any other=20 SP providing services for the public, I assume to be able to reach the user having this public user identity. And speermint is only talking about peering or interconnecting with SIP URIs (E.164 numbers need first to be translated to SIP URIs (AoRs) =20 The originating SP has NO CHOICE other then to Interconnect on L5 with the termination SP. We can do these games with "peering", "peering federations", etc. only as long as there is another choice, e.g. the PSTN for voice calls. =20 The terminating SP has a monopoly (or in EU terms, he has Significant Market Power (SMP) (which may imply some remidies, such as the requirement to interconnect! The terminating SP may reject incoming calls, but only on behalf (or by order) of the end-user. not on his own. =20 the terminating SP may belong to a federation or even more then one, but this is only shifting the problem, because then the SMP (monopoly) moves then to the federation. =20 A federation MAY be used for additional policies such as ADDITIONAL provision of end-to-end QoS or special peering (direct links on L3), but IMHO a call set-up via plain SIP may never be rejected, because of the originator has no other choice. =20 What could (should) be done by Speermint is defining a minimum set of requirements (profile) which are required to interconnect, (e.g. TLS, some level of certificates, asserted user identities, etc.) but if these are met, a terminating SP provider must accept a call in principle (the end-user may reject it finally, e.g. not accepting = calls from .biz or or from sip:dan@example.com or whatever) =20 I have something similar as the profile between SP and PBX in mind as created by the SIPForum. =20 If Speermint has achieved this, it may move on to more complicated=20 stuff, such as peering policy agreements providing additional SLAs eg on L3. =20 The either we want to enable a public communications network (and I cannot imagine something else in IETF) or not. If not Speermint is out of scope as a whole. =20 regards =20 Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Di 28.03.2006 23:34 An: speermint@ietf.org Betreff: [Speermint] Comments on reqs-and-terminology-01 and = policy-dds-00(Peerign concepts and others..) Hello, I've been reading "reqs and terminology" and I would like to step back and ask some questions about some of the definitions. Peering: =3D=3D=3D=3D=3D=3D=3D=3D In layer 3 peering two routers exchange their routing tables, reach a steady state, and after that data packets can flow between the two domains. Layer 5 peering means, "interconnection of two service providers for the purposes of SIP signaling". Making the inevitable comparison with layer 3 peering, there are some fundamental differences that I'm trying to reconcile. 1) In a traditional (a.k.a. layer 3) peering, both routers exchange all necessary routing information and enter a steady state. At this point, no other routes are exchanged and routers concentrate on forwarding packets. I know the WG is in the beginning, but it is not clear to me what pieces are needed for an equivalent functionality. For example: 1) Are the entities exchanging SIP signaling for the purpose of peering doing so on a _per call_ basis? Is there going to be some mechanism to exchange such information in bulk such as in a routing protocol? Maybe based on domain names or something similar? 2) The draft states that " A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI)." So, it seems to me that although the "layer 5 peering" is happening between the two entities exchanging SIP signaling, the peering point discovery is a result of a SRV query. But the draft also states that " SPEERMINT Working Group is focused on the use of such CRD." Draft peering-policy states that " This documents proposes the use of DNS entries to publish a SIP proxy's policy for accepting incoming calls" proposes DNS as a way of exchange polices. This begs the question of what are the two "peering" entities really doing besides exchange traditional SIP signaling? It seems the real _information peering_ (for the lack of a better term) is happening between DNS servers. All important information related to "peering" is coming from a DNS server which might as well be on your own domain (if your exchange DNS information). In summary, it seems to me the whole architecture is quite a departure from layer 3 peering where the entities peering are the holders of the necessary information to allow data packets to flow. Here the entities peering publish their peering information to third party server which does the actual "peering" (exchange inter-domain information). Anyway, the idea of the mail is to try to clarify things. There is much emphasis on SIP but it seems DNS plays a more central role. Or maybe some SIP extension will be made to exchange peering policies? Policies and Independence of lower layers: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP exchange QoS and VPN information, performs discovery, etc. This implies that BGP indirectly (or directly) knows the capabilities of the transport layer (thus the name capability negotiation). So, although the mechanism to exchange the actual policies needs to be independent of the lower layers, there needs to be a way to input lower layer information into the devices exchanging the policies. Just like BGP has filters and priorities based on a myriad of options. So, maybe the wording should change a little. As far as 5.6 goes, it seems to me the policies can be quite complex. The experience of BGP tells us that in the end policies can be huge. So, if policies are going to be huge, what draft dds-00 states as a possibility " If the simple boolean logic and the limited space in the DNS answers are insufficient for an application then a type of policy rule URIs can be defined which links to policy statements written in a fully featured policy description language like SAML [14] or XACML [15]." will actually going to be the rule. So, this begs the question of DNS is a good choice to publish peering policies. Thanks, Reinaldo _______________________________________________ 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 Tue Mar 28 18:18:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONRu-0003h3-5p; Tue, 28 Mar 2006 18:18:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONRt-0003gy-2B for speermint@ietf.org; Tue, 28 Mar 2006 18:18:05 -0500 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONRs-0004rj-DE for speermint@ietf.org; Tue, 28 Mar 2006 18:18:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..) Date: Wed, 29 Mar 2006 01:18:08 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A6065567B828@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..) Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZA= From: "David Schwartz" To: "Reinaldo Penno" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 Hi Reinaldo I am not sure the goal of SPEERMINT is to recreate L3 peering at L5. The = problem being solved is different in that L3 peering is always with a = fixed number of neighbors. These are stored as you mention in static = routing tables at each node and do not change from call to call. In = contrast, L5 peering is not necessarily static (unless you are talking = about a federation model). The destination is chosen only when the call = is made and may be to a peer that a given service provider/domain = administrator/node has never spoken to before.=20 Assuming DNS is used to find the peering node, the query is made on a = call by call basis. Now clearly, this DNS info can be cached at the = originating node but the cache still has a very different nature than = that of an L3 routing table. Policy is an entirely different issue (as is the case in L3) and it is = important to separate it out from the routing issue. The draft you = mention about pushing policy via DNS is dealing with one out of many = possible topologies - namely that of ad hoc federations. There was very = little discussion about policy at IETF 65 as the foundations of L5 = routing need to be cemented before the higher level policy issues can be = addressed. Cheers, David -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: =E2 28 =EE=F8=F5 2006 23:34 To: speermint@ietf.org Subject: [Speermint] Comments on reqs-and-terminology-01 and = policy-dds-00(Peerign concepts and others..) Hello, I've been reading "reqs and terminology" and I would like to step back and ask some questions about some of the definitions. Peering: =3D=3D=3D=3D=3D=3D=3D=3D In layer 3 peering two routers exchange their routing tables, reach a steady state, and after that data packets can flow between the two domains. Layer 5 peering means, "interconnection of two service providers for the purposes of SIP signaling".=20 Making the inevitable comparison with layer 3 peering, there are some fundamental differences that I'm trying to reconcile. 1) In a traditional (a.k.a. layer 3) peering, both routers exchange all necessary routing information and enter a steady state. At this point, no other routes are exchanged and routers concentrate on forwarding packets. I know the WG is in the beginning, but it is not clear to me what pieces are needed for an equivalent functionality. For example: 1) Are the entities exchanging SIP signaling for the purpose of peering doing so on a _per call_ basis? Is there going to be some mechanism to exchange such information in bulk such as in a routing protocol? Maybe based on domain names or something similar? 2) The draft states that " A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI)." So, it seems to me that although the "layer 5 peering" is happening between the two entities exchanging SIP signaling, the peering point discovery is a result of a SRV query. But the draft also states that " SPEERMINT Working Group is focused on the use of such CRD." Draft peering-policy states that " This documents proposes the use of DNS entries to publish a SIP proxy's policy for accepting incoming calls" proposes DNS as a way of exchange polices. This begs the question of what are the two "peering" entities really doing besides exchange traditional SIP signaling? It seems the real _information peering_ (for the lack of a better term) is happening between DNS servers. All important information related to "peering" is coming from a DNS server which might as well be on your own domain (if your exchange DNS information).=20 In summary, it seems to me the whole architecture is quite a departure from layer 3 peering where the entities peering are the holders of the necessary information to allow data packets to flow. Here the entities peering publish their peering information to third party server which does the actual "peering" (exchange inter-domain information). Anyway, the idea of the mail is to try to clarify things. There is much emphasis on SIP but it seems DNS plays a more central role. Or maybe some SIP extension will be made to exchange peering policies? Policies and Independence of lower layers: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP exchange QoS and VPN information, performs discovery, etc. This implies that BGP indirectly (or directly) knows the capabilities of the transport layer (thus the name capability negotiation). So, although the mechanism to exchange the actual policies needs to be independent of the lower layers, there needs to be a way to input lower layer information into the devices exchanging the policies. Just like BGP has filters and priorities based on a myriad of options. So, maybe the wording should change a little. As far as 5.6 goes, it seems to me the policies can be quite complex. The experience of BGP tells us that in the end policies can be huge. So, if policies are going to be huge, what draft dds-00 states as a possibility=20 " If the simple boolean logic and the limited space in the DNS answers are insufficient for an application then a type of policy rule URIs can be defined which links to policy statements written in a fully featured policy description language like SAML [14] or XACML [15]." will actually going to be the rule. So, this begs the question of DNS is a good choice to publish peering policies.=20 Thanks, Reinaldo _______________________________________________ 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 Tue Mar 28 18:48:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONvN-0006LY-Hr; Tue, 28 Mar 2006 18:48:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONvM-0006LS-KK for speermint@ietf.org; Tue, 28 Mar 2006 18:48:32 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONvL-0005XK-1W for speermint@ietf.org; Tue, 28 Mar 2006 18:48:32 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 28 Mar 2006 15:48:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,140,1141632000"; d="scan'208"; a="536439191:sNHT28173476" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..) Date: Tue, 28 Mar 2006 18:48:28 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE594@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..) Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIA== From: "Reinaldo Penno" To: "David Schwartz" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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 Hello David, Thanks for reading my lengthy email. Just to clarify things, I'm not = really advocating the recreation of the layer 3 peering model.=20 I was raising some questions based on the experience acquired on more = than 30 years of layer 3 peering. I understand they are different = problems (but they sure also have similarities).=20 During these 30 or so years of layer 3 peering and BGP, very similar = discussions already happened with just the names changed. "What if a new = peer/router comes along?", "Can we perform policy routing on a packet by = packet basis?", "Where BGP policies will come from?", "What if I want to = filter some packets based on 5-tuple?", etc, etc. You can change the = names to SIP, Proxy, DNS, and the questions become very similar. So, more to your email, although theoretically you can have any number = of VoIP peers (just like Layer 3 peers) it _seems_ to me based on = interconnection agreements and others, their identities and number will = be well known since configurations will need to be made (DNS, Sip = Proxies, etc, etc) before hand. So, although a call to a certain service = provider domain might never happen, all configurations must be in place = for that to happen. Is that a reasonable assumption? Just like two layer 3 peers might exchange routing tables but never = actually see a data packet for a while.=20 It begs the question why the two entities exchanging SIP signaling do = not exchange policy information themselves through some SIP = extension/new protocol/ and the role played by DNS. I'm not = advocating this model but it seems a pertinent question.=20 Regards, Reinaldo > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > Sent: Tuesday, March 28, 2006 3:18 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and = policy- > dds-00(Peerign concepts and others..) >=20 > Hi Reinaldo >=20 > I am not sure the goal of SPEERMINT is to recreate L3 peering at L5. = The > problem being solved is different in that L3 peering is always with a > fixed number of neighbors. These are stored as you mention in static > routing tables at each node and do not change from call to call. In > contrast, L5 peering is not necessarily static (unless you are talking > about a federation model). The destination is chosen only when the = call is > made and may be to a peer that a given service provider/domain > administrator/node has never spoken to before. >=20 > Assuming DNS is used to find the peering node, the query is made on a = call > by call basis. Now clearly, this DNS info can be cached at the = originating > node but the cache still has a very different nature than that of an = L3 > routing table. >=20 > Policy is an entirely different issue (as is the case in L3) and it is > important to separate it out from the routing issue. The draft you = mention > about pushing policy via DNS is dealing with one out of many possible > topologies - namely that of ad hoc federations. There was very little > discussion about policy at IETF 65 as the foundations of L5 routing = need > to be cemented before the higher level policy issues can be addressed. >=20 > Cheers, >=20 > David >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: =E2 28 =EE=F8=F5 2006 23:34 > To: speermint@ietf.org > Subject: [Speermint] Comments on reqs-and-terminology-01 and = policy-dds- > 00(Peerign concepts and others..) >=20 > Hello, >=20 > I've been reading "reqs and terminology" and I would like to step back > and ask some questions about some of the definitions. >=20 >=20 > Peering: > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > In layer 3 peering two routers exchange their routing tables, reach a > steady state, and after that data packets can flow between the two > domains. >=20 > Layer 5 peering means, "interconnection of two service providers for = the > purposes of SIP signaling". >=20 > Making the inevitable comparison with layer 3 peering, there are some > fundamental differences that I'm trying to reconcile. >=20 > 1) In a traditional (a.k.a. layer 3) peering, both routers exchange = all > necessary routing information and enter a steady state. At this point, > no other routes are exchanged and routers concentrate on forwarding > packets. >=20 > I know the WG is in the beginning, but it is not clear to me what = pieces > are needed for an equivalent functionality. For example: >=20 > 1) Are the entities exchanging SIP signaling for the purpose of = peering > doing so on a _per call_ basis? Is there going to be some mechanism = to > exchange such information in bulk such as in a routing protocol? Maybe > based on domain names or something similar? >=20 > 2) The draft states that " A > domain's ingress point can be thought of as the location pointed to > by the SRV record that resulted from the resolution of the CRD = (i.e., > a SIP URI)." >=20 > So, it seems to me that although the "layer 5 peering" is happening > between the two entities exchanging SIP signaling, the peering point > discovery is a result of a SRV query. But the draft also states that " > SPEERMINT Working Group is focused on the use of such CRD." >=20 > Draft peering-policy states that " This documents proposes the use of > DNS entries to publish a SIP proxy's policy for accepting incoming > calls" proposes DNS as a way of exchange polices. >=20 > This begs the question of what are the two "peering" entities really > doing besides exchange traditional SIP signaling? It seems the real > _information peering_ (for the lack of a better term) is happening > between DNS servers. All important information related to "peering" is > coming from a DNS server which might as well be on your own domain (if > your exchange DNS information). >=20 > In summary, it seems to me the whole architecture is quite a departure > from layer 3 peering where the entities peering are the holders of the > necessary information to allow data packets to flow. Here the entities > peering publish their peering information to third party server which > does the actual "peering" (exchange inter-domain information). >=20 >=20 > Anyway, the idea of the mail is to try to clarify things. There is = much > emphasis on SIP but it seems DNS plays a more central role. Or maybe > some SIP extension will be made to exchange peering policies? >=20 >=20 > Policies and Independence of lower layers: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP > exchange QoS and VPN information, performs discovery, etc. This = implies > that BGP indirectly (or directly) knows the capabilities of the > transport layer (thus the name capability negotiation). >=20 > So, although the mechanism to exchange the actual policies needs to be > independent of the lower layers, there needs to be a way to input = lower > layer information into the devices exchanging the policies. Just like > BGP has filters and priorities based on a myriad of options. So, maybe > the wording should change a little. >=20 > As far as 5.6 goes, it seems to me the policies can be quite complex. > The experience of BGP tells us that in the end policies can be huge. = So, > if policies are going to be huge, what draft dds-00 states as a > possibility >=20 > " If the simple boolean logic and the limited space in the DNS answers > are insufficient for an application then a type of policy rule URIs > can be defined which links to policy statements written in a fully > featured policy description language like SAML [14] or XACML [15]." >=20 > will actually going to be the rule. So, this begs the question of DNS = is > a good choice to publish peering policies. >=20 > Thanks, >=20 > Reinaldo >=20 > _______________________________________________ > 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 Tue Mar 28 19:56:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOOzI-0004H1-GG; Tue, 28 Mar 2006 19:56:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOOzH-0004Be-95 for speermint@ietf.org; Tue, 28 Mar 2006 19:56:39 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOOzG-0008Ak-RI for speermint@ietf.org; Tue, 28 Mar 2006 19:56:39 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 19:56:38 -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] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) Date: Tue, 28 Mar 2006 19:56:40 -0500 Message-ID: <8812D8156467224C9E9739E513037EF149D1DB@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) thread-index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAOCTHMABYK0MA== From: "Medhavi Bhatia" To: "Stastny Richard" , "Reinaldo Penno" , X-OriginalArrivalTime: 29 Mar 2006 00:56:38.0390 (UTC) FILETIME=[A272A960:01C652CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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 Hi Richard, >=20 > We also could define this in another way: a SP is giving out > to their customers a public user identity, in SIP also called > an Address-of-Record. Note the term PUBLIC. I think this is the wrong assumption given P2P SIP. Why can't the user have a unique public user identity and it not be linked to the SP at all (The SP may not be a VoIP SP). >=20 > If I get a public user identity from a SP, I assume to be able to give this > to somebody else and he/she is able to reach me via a public > communications network (note that I do not mention here > the Internet, also a walled garden network such as Vonage > is a public communications network)- Ok they are not giving out AoRs >=20 > So if I use this public user identity in any other public "network" > accepting SIP URIs (in the definition of Speermint) or with any other > SP providing services for the public, I assume to be able to reach the > user having this public user identity. And speermint is only talking > about peering or interconnecting with SIP URIs (E.164 numbers > need first to be translated to SIP URIs (AoRs) >=20 > The originating SP has NO CHOICE other then to Interconnect > on L5 with the termination SP. We can do these games with > "peering", "peering federations", etc. only as long as there > is another choice, e.g. the PSTN for voice calls. >=20 > The terminating SP has a monopoly (or in EU terms, he > has Significant Market Power (SMP) (which may imply > some remidies, such as the requirement to interconnect! >=20 > The terminating SP may reject incoming calls, but only > on behalf (or by order) of the end-user. not on his own. >=20 > the terminating SP may belong to a federation or even more > then one, but this is only shifting the problem, because then > the SMP (monopoly) moves then to the federation. >=20 > A federation MAY be used for additional policies such as > ADDITIONAL provision of end-to-end QoS or special peering > (direct links on L3), but IMHO a call set-up via plain SIP may never > be rejected, because of the originator has no other choice. >=20 > What could (should) be done by Speermint is defining a minimum > set of requirements (profile) which are required to interconnect, > (e.g. TLS, some level of certificates, asserted user identities, etc.) > but if these are met, a terminating SP provider must accept a call > in principle (the end-user may reject it finally, e.g. not accepting calls > from .biz or or from sip:dan@example.com or whatever) >=20 I think we should use this to set the minimum scope given the amount of confusion in the WG at this point. This can actually be done and I believe will be useful. -Medhavi. > I have something similar as the profile between SP and PBX in mind > as created by the SIPForum. >=20 > If Speermint has achieved this, it may move on to more complicated > stuff, such as peering policy agreements providing additional SLAs > eg on L3. >=20 > The either we want to enable a public communications network > (and I cannot imagine something else in IETF) or not. If > not Speermint is out of scope as a whole. >=20 > regards >=20 > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Di 28.03.2006 23:34 > An: speermint@ietf.org > Betreff: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign > concepts and others..) >=20 >=20 >=20 > Hello, >=20 > I've been reading "reqs and terminology" and I would like to step back > and ask some questions about some of the definitions. >=20 >=20 > Peering: > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > In layer 3 peering two routers exchange their routing tables, reach a > steady state, and after that data packets can flow between the two > domains. >=20 > Layer 5 peering means, "interconnection of two service providers for the > purposes of SIP signaling". >=20 > Making the inevitable comparison with layer 3 peering, there are some > fundamental differences that I'm trying to reconcile. >=20 > 1) In a traditional (a.k.a. layer 3) peering, both routers exchange all > necessary routing information and enter a steady state. At this point, > no other routes are exchanged and routers concentrate on forwarding > packets. >=20 > I know the WG is in the beginning, but it is not clear to me what pieces > are needed for an equivalent functionality. For example: >=20 > 1) Are the entities exchanging SIP signaling for the purpose of peering > doing so on a _per call_ basis? Is there going to be some mechanism to > exchange such information in bulk such as in a routing protocol? Maybe > based on domain names or something similar? >=20 > 2) The draft states that " A > domain's ingress point can be thought of as the location pointed to > by the SRV record that resulted from the resolution of the CRD (i.e., > a SIP URI)." >=20 > So, it seems to me that although the "layer 5 peering" is happening > between the two entities exchanging SIP signaling, the peering point > discovery is a result of a SRV query. But the draft also states that " > SPEERMINT Working Group is focused on the use of such CRD." >=20 > Draft peering-policy states that " This documents proposes the use of > DNS entries to publish a SIP proxy's policy for accepting incoming > calls" proposes DNS as a way of exchange polices. >=20 > This begs the question of what are the two "peering" entities really > doing besides exchange traditional SIP signaling? It seems the real > _information peering_ (for the lack of a better term) is happening > between DNS servers. All important information related to "peering" is > coming from a DNS server which might as well be on your own domain (if > your exchange DNS information). >=20 > In summary, it seems to me the whole architecture is quite a departure > from layer 3 peering where the entities peering are the holders of the > necessary information to allow data packets to flow. Here the entities > peering publish their peering information to third party server which > does the actual "peering" (exchange inter-domain information). >=20 >=20 > Anyway, the idea of the mail is to try to clarify things. There is much > emphasis on SIP but it seems DNS plays a more central role. Or maybe > some SIP extension will be made to exchange peering policies? >=20 >=20 > Policies and Independence of lower layers: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP > exchange QoS and VPN information, performs discovery, etc. This implies > that BGP indirectly (or directly) knows the capabilities of the > transport layer (thus the name capability negotiation). >=20 > So, although the mechanism to exchange the actual policies needs to be > independent of the lower layers, there needs to be a way to input lower > layer information into the devices exchanging the policies. Just like > BGP has filters and priorities based on a myriad of options. So, maybe > the wording should change a little. >=20 > As far as 5.6 goes, it seems to me the policies can be quite complex. > The experience of BGP tells us that in the end policies can be huge. So, > if policies are going to be huge, what draft dds-00 states as a > possibility >=20 > " If the simple boolean logic and the limited space in the DNS answers > are insufficient for an application then a type of policy rule URIs > can be defined which links to policy statements written in a fully > featured policy description language like SAML [14] or XACML [15]." >=20 > will actually going to be the rule. So, this begs the question of DNS is > a good choice to publish peering policies. >=20 > Thanks, >=20 > Reinaldo >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: 3/24/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Mar 28 20:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPF5-00057P-Ji; Tue, 28 Mar 2006 20:12:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPF4-00057K-AN for speermint@ietf.org; Tue, 28 Mar 2006 20:12:58 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOPF3-0000Se-QQ for speermint@ietf.org; Tue, 28 Mar 2006 20:12:58 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 20:12:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) Date: Tue, 28 Mar 2006 20:12:59 -0500 Message-ID: <8812D8156467224C9E9739E513037EF149D1E7@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) thread-index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+Dg From: "Medhavi Bhatia" To: "Reinaldo Penno" , "David Schwartz" , X-OriginalArrivalTime: 29 Mar 2006 01:12:57.0211 (UTC) FILETIME=[E9DEE4B0:01C652CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af 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 >=20 > It begs the question why the two entities exchanging SIP signaling do = not exchange policy > information themselves through some SIP extension/new protocol/ and the > role played by DNS. I'm not advocating this model but it seems a = pertinent question. I think peering in L3 must be basic, given how fundamental L3 is to the = internet. For SIP, TRIP provides functionality similar to BGP (only for = phone numbers though, I think). In my opinion, SIP peering ought to follow the email model. Once = location is done and basic requirements are satisfied at the SIP layer = (like identity etc), the call should be routable. As Richard said in the = earlier email, the destination SP may still reject or challenge the call = if it lacks either the basic requirements we agree to in the WG or some = extra requirements specific to the termination SP (Core-T in my ID). The = challenge is that in some cases there are going to be IXPs = (Interconnects) which sit in the middle due to commercial or regulatory = reasons. The location of an IXP, the provisioning of this IXP and the = Core-T SP are the architectural problems which this WG needs to solve as = well. -Medhavi. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > Sent: Tuesday, March 28, 2006 3:18 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and = policy- > > dds-00(Peerign concepts and others..) > > > > Hi Reinaldo > > > > I am not sure the goal of SPEERMINT is to recreate L3 peering at L5. = The > > problem being solved is different in that L3 peering is always with = a > > fixed number of neighbors. These are stored as you mention in static > > routing tables at each node and do not change from call to call. In > > contrast, L5 peering is not necessarily static (unless you are = talking > > about a federation model). The destination is chosen only when the = call is > > made and may be to a peer that a given service provider/domain > > administrator/node has never spoken to before. > > > > Assuming DNS is used to find the peering node, the query is made on = a call > > by call basis. Now clearly, this DNS info can be cached at the = originating > > node but the cache still has a very different nature than that of an = L3 > > routing table. > > > > Policy is an entirely different issue (as is the case in L3) and it = is > > important to separate it out from the routing issue. The draft you = mention > > about pushing policy via DNS is dealing with one out of many = possible > > topologies - namely that of ad hoc federations. There was very = little > > discussion about policy at IETF 65 as the foundations of L5 routing = need > > to be cemented before the higher level policy issues can be = addressed. > > > > Cheers, > > > > David > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: =E2 28 =EE=F8=F5 2006 23:34 > > To: speermint@ietf.org > > Subject: [Speermint] Comments on reqs-and-terminology-01 and = policy-dds- > > 00(Peerign concepts and others..) > > > > Hello, > > > > I've been reading "reqs and terminology" and I would like to step = back > > and ask some questions about some of the definitions. > > > > > > Peering: > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > In layer 3 peering two routers exchange their routing tables, reach = a > > steady state, and after that data packets can flow between the two > > domains. > > > > Layer 5 peering means, "interconnection of two service providers for = the > > purposes of SIP signaling". > > > > Making the inevitable comparison with layer 3 peering, there are = some > > fundamental differences that I'm trying to reconcile. > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers exchange = all > > necessary routing information and enter a steady state. At this = point, > > no other routes are exchanged and routers concentrate on forwarding > > packets. > > > > I know the WG is in the beginning, but it is not clear to me what = pieces > > are needed for an equivalent functionality. For example: > > > > 1) Are the entities exchanging SIP signaling for the purpose of = peering > > doing so on a _per call_ basis? Is there going to be some mechanism = to > > exchange such information in bulk such as in a routing protocol? = Maybe > > based on domain names or something similar? > > > > 2) The draft states that " A > > domain's ingress point can be thought of as the location pointed = to > > by the SRV record that resulted from the resolution of the CRD = (i.e., > > a SIP URI)." > > > > So, it seems to me that although the "layer 5 peering" is happening > > between the two entities exchanging SIP signaling, the peering point > > discovery is a result of a SRV query. But the draft also states that = " > > SPEERMINT Working Group is focused on the use of such CRD." > > > > Draft peering-policy states that " This documents proposes the use = of > > DNS entries to publish a SIP proxy's policy for accepting incoming > > calls" proposes DNS as a way of exchange polices. > > > > This begs the question of what are the two "peering" entities really > > doing besides exchange traditional SIP signaling? It seems the real > > _information peering_ (for the lack of a better term) is happening > > between DNS servers. All important information related to "peering" = is > > coming from a DNS server which might as well be on your own domain = (if > > your exchange DNS information). > > > > In summary, it seems to me the whole architecture is quite a = departure > > from layer 3 peering where the entities peering are the holders of = the > > necessary information to allow data packets to flow. Here the = entities > > peering publish their peering information to third party server = which > > does the actual "peering" (exchange inter-domain information). > > > > > > Anyway, the idea of the mail is to try to clarify things. There is = much > > emphasis on SIP but it seems DNS plays a more central role. Or maybe > > some SIP extension will be made to exchange peering policies? > > > > > > Policies and Independence of lower layers: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP > > exchange QoS and VPN information, performs discovery, etc. This = implies > > that BGP indirectly (or directly) knows the capabilities of the > > transport layer (thus the name capability negotiation). > > > > So, although the mechanism to exchange the actual policies needs to = be > > independent of the lower layers, there needs to be a way to input = lower > > layer information into the devices exchanging the policies. Just = like > > BGP has filters and priorities based on a myriad of options. So, = maybe > > the wording should change a little. > > > > As far as 5.6 goes, it seems to me the policies can be quite = complex. > > The experience of BGP tells us that in the end policies can be huge. = So, > > if policies are going to be huge, what draft dds-00 states as a > > possibility > > > > " If the simple boolean logic and the limited space in the DNS = answers > > are insufficient for an application then a type of policy rule = URIs > > can be defined which links to policy statements written in a = fully > > featured policy description language like SAML [14] or XACML = [15]." > > > > will actually going to be the rule. So, this begs the question of = DNS is > > a good choice to publish peering policies. > > > > Thanks, > > > > Reinaldo > > > > _______________________________________________ > > 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 >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: = 3/24/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Mar 28 20:30:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPWC-00081Z-7P; Tue, 28 Mar 2006 20:30:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPWA-00081P-IW for speermint@ietf.org; Tue, 28 Mar 2006 20:30:38 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOPW9-00012E-UV for speermint@ietf.org; Tue, 28 Mar 2006 20:30:38 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 28 Mar 2006 17:30:36 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,140,1141632000"; d="scan'208"; a="539508152:sNHT27162428" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) Date: Tue, 28 Mar 2006 20:30:34 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE595@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009A= From: "Reinaldo Penno" To: "Medhavi Bhatia" , "David Schwartz" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 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 Hello, I tend to agree that the email model sounds attractive except the delay = and business requirements of email and VoIP are quire different. Email is not delay sensitive, does not require any type of = prioritization and is not charged (or at least it wasn't). VoIP is exactly the opposite. VoIP (signaling and media) are delay = sensitive, need prioritization and will be billed. =20 I believe a call to a public number is (or should) always going to be = routable. I guess my main question is: is the general belief that VoIP = providers will just configure their proxy servers to talk to each other = in an email type model? No business agreements similar to PSTN/Wireless, = no charging, no extra billing for "roaming", etc? =20 My reply to David's email was more to the idea that you can install a = proxy server somewhere, point the "MX" to the next upstream "proxy = server" and be done with it? As VoIP takes off wouldn't some basic = regulatory issues, numbering schemes and others prevent such behavior?=20 These are not rhetoric questions; I really do not know the answer. Regards, Reinaldo > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Tuesday, March 28, 2006 5:13 PM > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 = andpolicy- > dds-00(Peerign concepts and others..) >=20 > > > > It begs the question why the two entities exchanging SIP signaling = do > not exchange policy > > information themselves through some SIP extension/new protocol/ name> and the > > role played by DNS. I'm not advocating this model but it seems a > pertinent question. >=20 > I think peering in L3 must be basic, given how fundamental L3 is to = the > internet. For SIP, TRIP provides functionality similar to BGP (only = for > phone numbers though, I think). >=20 > In my opinion, SIP peering ought to follow the email model. Once = location > is done and basic requirements are satisfied at the SIP layer (like > identity etc), the call should be routable. As Richard said in the = earlier > email, the destination SP may still reject or challenge the call if it > lacks either the basic requirements we agree to in the WG or some = extra > requirements specific to the termination SP (Core-T in my ID). The > challenge is that in some cases there are going to be IXPs = (Interconnects) > which sit in the middle due to commercial or regulatory reasons. The > location of an IXP, the provisioning of this IXP and the Core-T SP are = the > architectural problems which this WG needs to solve as well. >=20 > -Medhavi. >=20 > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > > Sent: Tuesday, March 28, 2006 3:18 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and > policy- > > > dds-00(Peerign concepts and others..) > > > > > > Hi Reinaldo > > > > > > I am not sure the goal of SPEERMINT is to recreate L3 peering at = L5. > The > > > problem being solved is different in that L3 peering is always = with a > > > fixed number of neighbors. These are stored as you mention in = static > > > routing tables at each node and do not change from call to call. = In > > > contrast, L5 peering is not necessarily static (unless you are = talking > > > about a federation model). The destination is chosen only when the > call is > > > made and may be to a peer that a given service provider/domain > > > administrator/node has never spoken to before. > > > > > > Assuming DNS is used to find the peering node, the query is made = on a > call > > > by call basis. Now clearly, this DNS info can be cached at the > originating > > > node but the cache still has a very different nature than that of = an > L3 > > > routing table. > > > > > > Policy is an entirely different issue (as is the case in L3) and = it is > > > important to separate it out from the routing issue. The draft you > mention > > > about pushing policy via DNS is dealing with one out of many = possible > > > topologies - namely that of ad hoc federations. There was very = little > > > discussion about policy at IETF 65 as the foundations of L5 = routing > need > > > to be cemented before the higher level policy issues can be = addressed. > > > > > > Cheers, > > > > > > David > > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: =E2 28 =EE=F8=F5 2006 23:34 > > > To: speermint@ietf.org > > > Subject: [Speermint] Comments on reqs-and-terminology-01 and = policy- > dds- > > > 00(Peerign concepts and others..) > > > > > > Hello, > > > > > > I've been reading "reqs and terminology" and I would like to step = back > > > and ask some questions about some of the definitions. > > > > > > > > > Peering: > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > In layer 3 peering two routers exchange their routing tables, = reach a > > > steady state, and after that data packets can flow between the two > > > domains. > > > > > > Layer 5 peering means, "interconnection of two service providers = for > the > > > purposes of SIP signaling". > > > > > > Making the inevitable comparison with layer 3 peering, there are = some > > > fundamental differences that I'm trying to reconcile. > > > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers = exchange > all > > > necessary routing information and enter a steady state. At this = point, > > > no other routes are exchanged and routers concentrate on = forwarding > > > packets. > > > > > > I know the WG is in the beginning, but it is not clear to me what > pieces > > > are needed for an equivalent functionality. For example: > > > > > > 1) Are the entities exchanging SIP signaling for the purpose of > peering > > > doing so on a _per call_ basis? Is there going to be some = mechanism > to > > > exchange such information in bulk such as in a routing protocol? = Maybe > > > based on domain names or something similar? > > > > > > 2) The draft states that " A > > > domain's ingress point can be thought of as the location = pointed to > > > by the SRV record that resulted from the resolution of the CRD > (i.e., > > > a SIP URI)." > > > > > > So, it seems to me that although the "layer 5 peering" is = happening > > > between the two entities exchanging SIP signaling, the peering = point > > > discovery is a result of a SRV query. But the draft also states = that " > > > SPEERMINT Working Group is focused on the use of such CRD." > > > > > > Draft peering-policy states that " This documents proposes the use = of > > > DNS entries to publish a SIP proxy's policy for accepting incoming > > > calls" proposes DNS as a way of exchange polices. > > > > > > This begs the question of what are the two "peering" entities = really > > > doing besides exchange traditional SIP signaling? It seems the = real > > > _information peering_ (for the lack of a better term) is happening > > > between DNS servers. All important information related to = "peering" is > > > coming from a DNS server which might as well be on your own domain = (if > > > your exchange DNS information). > > > > > > In summary, it seems to me the whole architecture is quite a = departure > > > from layer 3 peering where the entities peering are the holders of = the > > > necessary information to allow data packets to flow. Here the = entities > > > peering publish their peering information to third party server = which > > > does the actual "peering" (exchange inter-domain information). > > > > > > > > > Anyway, the idea of the mail is to try to clarify things. There is > much > > > emphasis on SIP but it seems DNS plays a more central role. Or = maybe > > > some SIP extension will be made to exchange peering policies? > > > > > > > > > Policies and Independence of lower layers: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today = BGP > > > exchange QoS and VPN information, performs discovery, etc. This > implies > > > that BGP indirectly (or directly) knows the capabilities of the > > > transport layer (thus the name capability negotiation). > > > > > > So, although the mechanism to exchange the actual policies needs = to be > > > independent of the lower layers, there needs to be a way to input > lower > > > layer information into the devices exchanging the policies. Just = like > > > BGP has filters and priorities based on a myriad of options. So, = maybe > > > the wording should change a little. > > > > > > As far as 5.6 goes, it seems to me the policies can be quite = complex. > > > The experience of BGP tells us that in the end policies can be = huge. > So, > > > if policies are going to be huge, what draft dds-00 states as a > > > possibility > > > > > > " If the simple boolean logic and the limited space in the DNS = answers > > > are insufficient for an application then a type of policy rule = URIs > > > can be defined which links to policy statements written in a = fully > > > featured policy description language like SAML [14] or XACML = [15]." > > > > > > will actually going to be the rule. So, this begs the question of = DNS > is > > > a good choice to publish peering policies. > > > > > > Thanks, > > > > > > Reinaldo > > > > > > _______________________________________________ > > > 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 > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: = 3/24/2006 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Mar 28 21:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOQPB-0006LU-SP; Tue, 28 Mar 2006 21:27:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOQPA-0006JR-OM for speermint@ietf.org; Tue, 28 Mar 2006 21:27:28 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOQPA-0003st-6P for speermint@ietf.org; Tue, 28 Mar 2006 21:27:28 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 21:27:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) Date: Tue, 28 Mar 2006 21:27:30 -0500 Message-ID: <8812D8156467224C9E9739E513037EF149D228@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) thread-index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009AAAcZysA== From: "Medhavi Bhatia" To: "Reinaldo Penno" , "David Schwartz" , X-OriginalArrivalTime: 29 Mar 2006 02:27:27.0933 (UTC) FILETIME=[52A0EED0:01C652D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb 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 Hi Reinaldo, > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, March 28, 2006 8:31 PM > To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 = andpolicy-dds-00(Peerign > concepts and others..) >=20 > Hello, >=20 > I tend to agree that the email model sounds attractive except the = delay and business > requirements of email and VoIP are quire different. >=20 > Email is not delay sensitive, does not require any type of = prioritization and is not charged > (or at least it wasn't). >=20 > VoIP is exactly the opposite. VoIP (signaling and media) are delay = sensitive, need > prioritization and will be billed. >=20 Good point. What we need is to separate the problem of peering into at = least two parts: terminating the call and the traffic itself (data = part). The email model applies only to the termination part. > I believe a call to a public number is (or should) always going to be = routable. I guess my > main question is: is the general belief that VoIP providers will just = configure their proxy > servers to talk to each other in an email type model? No business = agreements similar to > PSTN/Wireless, no charging, no extra billing for "roaming", etc? >=20 I agree those are issues. It would be good if we can work out something = which is generic (compared to IMS/PSTN specific). Maybe they are out of = scope since we are dealing with protocol and architecture issues in the = WG. The only aspect billing and roaming affect is that if all technical = requirements (e.g the ones this WG specifies) are satisfied, the peer = could still reject traffic (w/o consulting the destination user, in = Richard's terms) if the commercial relationship does not exist. I think = this is what hampers connectivity today. All these commercial = relationships exist because SPs want to be layer 5 aware (they cannot = seem to find a way to evolve their business models otherwise... :), = where only the origination SP (Core-O) and Core-T need to have a = commercial relationship. The roaming aspect again may be quite = artificial and could be questionable going forward... Just my personal = comments. -Medhavi. > My reply to David's email was more to the idea that you can install a = proxy server > somewhere, point the "MX" to the next upstream "proxy server" and be = done with it? As > VoIP takes off wouldn't some basic regulatory issues, numbering = schemes and others > prevent such behavior? >=20 > These are not rhetoric questions; I really do not know the answer. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Tuesday, March 28, 2006 5:13 PM > > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 = andpolicy- > > dds-00(Peerign concepts and others..) > > > > > > > > It begs the question why the two entities exchanging SIP signaling = do > > not exchange policy > > > information themselves through some SIP extension/new = protocol/ > name> and the > > > role played by DNS. I'm not advocating this model but it seems a > > pertinent question. > > > > I think peering in L3 must be basic, given how fundamental L3 is to = the > > internet. For SIP, TRIP provides functionality similar to BGP (only = for > > phone numbers though, I think). > > > > In my opinion, SIP peering ought to follow the email model. Once = location > > is done and basic requirements are satisfied at the SIP layer (like > > identity etc), the call should be routable. As Richard said in the = earlier > > email, the destination SP may still reject or challenge the call if = it > > lacks either the basic requirements we agree to in the WG or some = extra > > requirements specific to the termination SP (Core-T in my ID). The > > challenge is that in some cases there are going to be IXPs = (Interconnects) > > which sit in the middle due to commercial or regulatory reasons. The > > location of an IXP, the provisioning of this IXP and the Core-T SP = are the > > architectural problems which this WG needs to solve as well. > > > > -Medhavi. > > > > > > > > Regards, > > > > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > > > Sent: Tuesday, March 28, 2006 3:18 PM > > > > To: Reinaldo Penno; speermint@ietf.org > > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and > > policy- > > > > dds-00(Peerign concepts and others..) > > > > > > > > Hi Reinaldo > > > > > > > > I am not sure the goal of SPEERMINT is to recreate L3 peering at = L5. > > The > > > > problem being solved is different in that L3 peering is always = with a > > > > fixed number of neighbors. These are stored as you mention in = static > > > > routing tables at each node and do not change from call to call. = In > > > > contrast, L5 peering is not necessarily static (unless you are = talking > > > > about a federation model). The destination is chosen only when = the > > call is > > > > made and may be to a peer that a given service provider/domain > > > > administrator/node has never spoken to before. > > > > > > > > Assuming DNS is used to find the peering node, the query is made = on a > > call > > > > by call basis. Now clearly, this DNS info can be cached at the > > originating > > > > node but the cache still has a very different nature than that = of an > > L3 > > > > routing table. > > > > > > > > Policy is an entirely different issue (as is the case in L3) and = it is > > > > important to separate it out from the routing issue. The draft = you > > mention > > > > about pushing policy via DNS is dealing with one out of many = possible > > > > topologies - namely that of ad hoc federations. There was very = little > > > > discussion about policy at IETF 65 as the foundations of L5 = routing > > need > > > > to be cemented before the higher level policy issues can be = addressed. > > > > > > > > Cheers, > > > > > > > > David > > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: =E2 28 =EE=F8=F5 2006 23:34 > > > > To: speermint@ietf.org > > > > Subject: [Speermint] Comments on reqs-and-terminology-01 and = policy- > > dds- > > > > 00(Peerign concepts and others..) > > > > > > > > Hello, > > > > > > > > I've been reading "reqs and terminology" and I would like to = step back > > > > and ask some questions about some of the definitions. > > > > > > > > > > > > Peering: > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > In layer 3 peering two routers exchange their routing tables, = reach a > > > > steady state, and after that data packets can flow between the = two > > > > domains. > > > > > > > > Layer 5 peering means, "interconnection of two service providers = for > > the > > > > purposes of SIP signaling". > > > > > > > > Making the inevitable comparison with layer 3 peering, there are = some > > > > fundamental differences that I'm trying to reconcile. > > > > > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers = exchange > > all > > > > necessary routing information and enter a steady state. At this = point, > > > > no other routes are exchanged and routers concentrate on = forwarding > > > > packets. > > > > > > > > I know the WG is in the beginning, but it is not clear to me = what > > pieces > > > > are needed for an equivalent functionality. For example: > > > > > > > > 1) Are the entities exchanging SIP signaling for the purpose of > > peering > > > > doing so on a _per call_ basis? Is there going to be some = mechanism > > to > > > > exchange such information in bulk such as in a routing protocol? = Maybe > > > > based on domain names or something similar? > > > > > > > > 2) The draft states that " A > > > > domain's ingress point can be thought of as the location = pointed to > > > > by the SRV record that resulted from the resolution of the = CRD > > (i.e., > > > > a SIP URI)." > > > > > > > > So, it seems to me that although the "layer 5 peering" is = happening > > > > between the two entities exchanging SIP signaling, the peering = point > > > > discovery is a result of a SRV query. But the draft also states = that " > > > > SPEERMINT Working Group is focused on the use of such CRD." > > > > > > > > Draft peering-policy states that " This documents proposes the = use of > > > > DNS entries to publish a SIP proxy's policy for accepting = incoming > > > > calls" proposes DNS as a way of exchange polices. > > > > > > > > This begs the question of what are the two "peering" entities = really > > > > doing besides exchange traditional SIP signaling? It seems the = real > > > > _information peering_ (for the lack of a better term) is = happening > > > > between DNS servers. All important information related to = "peering" is > > > > coming from a DNS server which might as well be on your own = domain (if > > > > your exchange DNS information). > > > > > > > > In summary, it seems to me the whole architecture is quite a = departure > > > > from layer 3 peering where the entities peering are the holders = of the > > > > necessary information to allow data packets to flow. Here the = entities > > > > peering publish their peering information to third party server = which > > > > does the actual "peering" (exchange inter-domain information). > > > > > > > > > > > > Anyway, the idea of the mail is to try to clarify things. There = is > > much > > > > emphasis on SIP but it seems DNS plays a more central role. Or = maybe > > > > some SIP extension will be made to exchange peering policies? > > > > > > > > > > > > Policies and Independence of lower layers: > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today = BGP > > > > exchange QoS and VPN information, performs discovery, etc. This > > implies > > > > that BGP indirectly (or directly) knows the capabilities of the > > > > transport layer (thus the name capability negotiation). > > > > > > > > So, although the mechanism to exchange the actual policies needs = to be > > > > independent of the lower layers, there needs to be a way to = input > > lower > > > > layer information into the devices exchanging the policies. Just = like > > > > BGP has filters and priorities based on a myriad of options. So, = maybe > > > > the wording should change a little. > > > > > > > > As far as 5.6 goes, it seems to me the policies can be quite = complex. > > > > The experience of BGP tells us that in the end policies can be = huge. > > So, > > > > if policies are going to be huge, what draft dds-00 states as a > > > > possibility > > > > > > > > " If the simple boolean logic and the limited space in the DNS = answers > > > > are insufficient for an application then a type of policy = rule URIs > > > > can be defined which links to policy statements written in a = fully > > > > featured policy description language like SAML [14] or XACML = [15]." > > > > > > > > will actually going to be the rule. So, this begs the question = of DNS > > is > > > > a good choice to publish peering policies. > > > > > > > > Thanks, > > > > > > > > Reinaldo > > > > > > > > _______________________________________________ > > > > 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 > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: = 3/24/2006 > > > >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: = 3/24/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 29 04:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOWnE-0006fm-PB; Wed, 29 Mar 2006 04:16:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOWnE-0006fh-71 for speermint@ietf.org; Wed, 29 Mar 2006 04:16:44 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOWnC-0003Fw-VS for speermint@ietf.org; Wed, 29 Mar 2006 04:16:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Comments on reqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..) Date: Wed, 29 Mar 2006 11:20:44 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4E7F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..) Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAOCTHMABYK0MAARTGjA From: "Stastny Richard" To: "Medhavi Bhatia" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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 > > We also could define this in another way: a SP is giving out > > to their customers a public user identity, in SIP also called > > an Address-of-Record. Note the term PUBLIC. >=20 > I think this is the wrong assumption given P2P SIP. Why can't the user > have a unique public user identity and it not be linked to the SP at all > (The SP may not be a VoIP SP). Hi Medhavi, Good point, but there are more issues in one: 1. re: P2P SIP As I understood the P2P SIP BoF, one of the most feasible models in P2P SIP is that P2P domains interconnect with each other using SIP proxy peers and normal client-server SIP and DNS SRV RR=20 (RFC3263) to interwork. Therefore the global identities (AoRs) used will be sip:unique-user-within-p2p@p2pnetwork.net 2. re: user owned public user identity a. a user may run his own SIP server, and act as his own SP this has not been excluded in the speermint charter. IMHO he should be able to do so as long as he fulfils the minimum requirements. b. a user may also host his sip:user@domain.net with a SP this is BTW a MUST for enterprises (as it has been requested from ECMA at TISPAN for IMS. This will (or is already) causing a lot of headaches, especially if you use domain certificates e.g. for TLS and also certified user identities. This is definitely a must for spearmint to look at and create some kind of BCP. Cheers Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Wednesday, March 29, 2006 2:57 AM > To: Stastny Richard; Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Comments on reqs-and-terminology-01andpolicy-dds- > 00(Peerign concepts and others..) >=20 > Hi Richard, >=20 > > > > We also could define this in another way: a SP is giving out > > to their customers a public user identity, in SIP also called > > an Address-of-Record. Note the term PUBLIC. >=20 > I think this is the wrong assumption given P2P SIP. Why can't the user > have a unique public user identity and it not be linked to the SP at all > (The SP may not be a VoIP SP). >=20 > > > > If I get a public user identity from a SP, I assume to be able to give > this > > to somebody else and he/she is able to reach me via a public > > communications network (note that I do not mention here > > the Internet, also a walled garden network such as Vonage > > is a public communications network)- Ok they are not giving out AoRs > > > > So if I use this public user identity in any other public "network" > > accepting SIP URIs (in the definition of Speermint) or with any other > > SP providing services for the public, I assume to be able to reach the > > user having this public user identity. And speermint is only talking > > about peering or interconnecting with SIP URIs (E.164 numbers > > need first to be translated to SIP URIs (AoRs) > > > > The originating SP has NO CHOICE other then to Interconnect > > on L5 with the termination SP. We can do these games with > > "peering", "peering federations", etc. only as long as there > > is another choice, e.g. the PSTN for voice calls. > > > > The terminating SP has a monopoly (or in EU terms, he > > has Significant Market Power (SMP) (which may imply > > some remidies, such as the requirement to interconnect! > > > > The terminating SP may reject incoming calls, but only > > on behalf (or by order) of the end-user. not on his own. > > > > the terminating SP may belong to a federation or even more > > then one, but this is only shifting the problem, because then > > the SMP (monopoly) moves then to the federation. > > > > A federation MAY be used for additional policies such as > > ADDITIONAL provision of end-to-end QoS or special peering > > (direct links on L3), but IMHO a call set-up via plain SIP may never > > be rejected, because of the originator has no other choice. > > > > What could (should) be done by Speermint is defining a minimum > > set of requirements (profile) which are required to interconnect, > > (e.g. TLS, some level of certificates, asserted user identities, etc.) > > but if these are met, a terminating SP provider must accept a call > > in principle (the end-user may reject it finally, e.g. not accepting > calls > > from .biz or or from sip:dan@example.com or whatever) > > >=20 > I think we should use this to set the minimum scope given the amount of > confusion in the WG at this point. This can actually be done and I > believe will be useful. >=20 > -Medhavi. >=20 > > I have something similar as the profile between SP and PBX in mind > > as created by the SIPForum. > > > > If Speermint has achieved this, it may move on to more complicated > > stuff, such as peering policy agreements providing additional SLAs > > eg on L3. > > > > The either we want to enable a public communications network > > (and I cannot imagine something else in IETF) or not. If > > not Speermint is out of scope as a whole. > > > > regards > > > > Richard > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Di 28.03.2006 23:34 > > An: speermint@ietf.org > > Betreff: [Speermint] Comments on reqs-and-terminology-01 and > policy-dds-00(Peerign > > concepts and others..) > > > > > > > > Hello, > > > > I've been reading "reqs and terminology" and I would like to step back > > and ask some questions about some of the definitions. > > > > > > Peering: > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > In layer 3 peering two routers exchange their routing tables, reach a > > steady state, and after that data packets can flow between the two > > domains. > > > > Layer 5 peering means, "interconnection of two service providers for > the > > purposes of SIP signaling". > > > > Making the inevitable comparison with layer 3 peering, there are some > > fundamental differences that I'm trying to reconcile. > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers exchange > all > > necessary routing information and enter a steady state. At this point, > > no other routes are exchanged and routers concentrate on forwarding > > packets. > > > > I know the WG is in the beginning, but it is not clear to me what > pieces > > are needed for an equivalent functionality. For example: > > > > 1) Are the entities exchanging SIP signaling for the purpose of > peering > > doing so on a _per call_ basis? Is there going to be some mechanism > to > > exchange such information in bulk such as in a routing protocol? Maybe > > based on domain names or something similar? > > > > 2) The draft states that " A > > domain's ingress point can be thought of as the location pointed to > > by the SRV record that resulted from the resolution of the CRD > (i.e., > > a SIP URI)." > > > > So, it seems to me that although the "layer 5 peering" is happening > > between the two entities exchanging SIP signaling, the peering point > > discovery is a result of a SRV query. But the draft also states that " > > SPEERMINT Working Group is focused on the use of such CRD." > > > > Draft peering-policy states that " This documents proposes the use of > > DNS entries to publish a SIP proxy's policy for accepting incoming > > calls" proposes DNS as a way of exchange polices. > > > > This begs the question of what are the two "peering" entities really > > doing besides exchange traditional SIP signaling? It seems the real > > _information peering_ (for the lack of a better term) is happening > > between DNS servers. All important information related to "peering" is > > coming from a DNS server which might as well be on your own domain (if > > your exchange DNS information). > > > > In summary, it seems to me the whole architecture is quite a departure > > from layer 3 peering where the entities peering are the holders of the > > necessary information to allow data packets to flow. Here the entities > > peering publish their peering information to third party server which > > does the actual "peering" (exchange inter-domain information). > > > > > > Anyway, the idea of the mail is to try to clarify things. There is > much > > emphasis on SIP but it seems DNS plays a more central role. Or maybe > > some SIP extension will be made to exchange peering policies? > > > > > > Policies and Independence of lower layers: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP > > exchange QoS and VPN information, performs discovery, etc. This > implies > > that BGP indirectly (or directly) knows the capabilities of the > > transport layer (thus the name capability negotiation). > > > > So, although the mechanism to exchange the actual policies needs to be > > independent of the lower layers, there needs to be a way to input > lower > > layer information into the devices exchanging the policies. Just like > > BGP has filters and priorities based on a myriad of options. So, maybe > > the wording should change a little. > > > > As far as 5.6 goes, it seems to me the policies can be quite complex. > > The experience of BGP tells us that in the end policies can be huge. > So, > > if policies are going to be huge, what draft dds-00 states as a > > possibility > > > > " If the simple boolean logic and the limited space in the DNS answers > > are insufficient for an application then a type of policy rule URIs > > can be defined which links to policy statements written in a fully > > featured policy description language like SAML [14] or XACML [15]." > > > > will actually going to be the rule. So, this begs the question of DNS > is > > a good choice to publish peering policies. > > > > Thanks, > > > > Reinaldo > > > > _______________________________________________ > > 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 > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > 3/24/2006 > > >=20 > _______________________________________________ > 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 Wed Mar 29 06:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOYTP-0001eP-Dj; Wed, 29 Mar 2006 06:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOYTO-0001dh-0v for speermint@ietf.org; Wed, 29 Mar 2006 06:04:22 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOYTK-0007lY-84 for speermint@ietf.org; Wed, 29 Mar 2006 06:04:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Mar 2006 13:08:08 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4E83@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Billing, Accounting, Tariffing and Charging Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009AAAcZysAAQUy8A From: "Stastny Richard" To: "Medhavi Bhatia" , "Reinaldo Penno" , "David Schwartz" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 Cc: Subject: [Speermint] Billing, Accounting, Tariffing and Charging 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 > > These are not rhetoric questions; I really do not know the answer. Welcome to the club, you are not alone ;-) > > VoIP is exactly the opposite. VoIP (signaling and media) are delay > sensitive, need > > prioritization and will be billed. > > >=20 > Good point. What we need is to separate the problem of peering into at > least two parts: terminating the call and the traffic itself (data = part). > The email model applies only to the termination part. Hmmm, I think it is even more complicated. Terminology: Billing is between end-users and a SP (out of scope in spearmint) Accounting is between SP (in scope of spearmint?) Tariffing is the calculation of a charge for using a certain resource for a certain amount of time. I consider it also paradox that we are discussing accounting and charging, particularly termination charges (fees)=20 1. in a time even in the PSTN issues are moving to bill-and-keep 2. on an inappropriate layer (L5) A substantial part of the problems with VoIP peering derives not from trust, QoS, SPIT, etc. problems, but simply how to keep up the existing regime of termination fees. Especially mobile operators make a living on this. Where is this problem coming from on the PSTN? (Lets for a moment forget problems caused by reverse charging) In the PSTN there was originally an accounting regime based on cascading. The O-SP bills the O-user for the call (based on distance), and keeping part of it and=20 paying out part to the next (transit) SP.=20 This goes on until the destination (T-SP) is reached, which also gets a share. The implicit assumptions here are: the originator has the benefit of the call and also call set-up is in one direction and call signalling and the mediastream is traversing all networks in question. This principle is only broken with call forwarding and also with mobile roaming. In the US also the mobile T-user pays air-time, not so in Europe, hence the problems with mobile NP Note: in my remark to my previous post on terminating network monopoly (SMP), one may consider the termination fee also as a compensation for the remedy that a terminating network MUST accept any call. This regime was quite simple, but was more and more complicated over time by burdening it with additional issues such as subsidies, etc. as it is currently in the US. What does this imply now for VoIP peering or interconnect VoIP; RTC and IP separate signalling (L5) from transport (L3) It also separates the SP from the access Now taking into account some facts: 1. Although SIP signalling (call set-up) is directed from O to T, the mediastream is both ways and symmetric (so much for Whitacre, he may eventually blame Google Video, but not VoIP providers) 2. The cost for the mediastream is moving more and more to the ends (access), even in the PSTN (see the latest OFCOM report on distance gradients), and the access is already paid in some way or the other by the end-users. 3. So why is it necessary to charge termination fees to the O-user at all for SIGNALLING? There is one issue where termination fees may apply (although this is going away also - e.g. Voipbuster): if you connect to the PSTN. But this is out of scope in Speermint and in addition solutions exist here since years. My recommendation is that as long as speermint is dealing with L5 peering only, accounting i.e. termination fees should not be dealt with. Cheers Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Wednesday, March 29, 2006 4:28 AM > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Comments on = reqs-and-terminology-01andpolicy-dds- > 00(Peerign concepts and others..) >=20 > Hi Reinaldo, >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, March 28, 2006 8:31 PM > > To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 = andpolicy- > dds-00(Peerign > > concepts and others..) > > > > Hello, > > > > I tend to agree that the email model sounds attractive except the = delay > and business > > requirements of email and VoIP are quire different. > > > > Email is not delay sensitive, does not require any type of > prioritization and is not charged > > (or at least it wasn't). > > > > VoIP is exactly the opposite. VoIP (signaling and media) are delay > sensitive, need > > prioritization and will be billed. > > >=20 > Good point. What we need is to separate the problem of peering into at > least two parts: terminating the call and the traffic itself (data = part). > The email model applies only to the termination part. >=20 > > I believe a call to a public number is (or should) always going to = be > routable. I guess my > > main question is: is the general belief that VoIP providers will = just > configure their proxy > > servers to talk to each other in an email type model? No business > agreements similar to > > PSTN/Wireless, no charging, no extra billing for "roaming", etc? > > >=20 > I agree those are issues. It would be good if we can work out = something > which is generic (compared to IMS/PSTN specific). Maybe they are out = of > scope since we are dealing with protocol and architecture issues in = the > WG. The only aspect billing and roaming affect is that if all = technical > requirements (e.g the ones this WG specifies) are satisfied, the peer > could still reject traffic (w/o consulting the destination user, in > Richard's terms) if the commercial relationship does not exist. I = think > this is what hampers connectivity today. All these commercial > relationships exist because SPs want to be layer 5 aware (they cannot = seem > to find a way to evolve their business models otherwise... :), where = only > the origination SP (Core-O) and Core-T need to have a commercial > relationship. The roaming aspect again may be quite artificial and = could > be questionable going forward... Just my personal comments. >=20 > -Medhavi. >=20 > > My reply to David's email was more to the idea that you can install = a > proxy server > > somewhere, point the "MX" to the next upstream "proxy server" and be > done with it? As > > VoIP takes off wouldn't some basic regulatory issues, numbering = schemes > and others > > prevent such behavior? > > > > These are not rhetoric questions; I really do not know the answer. > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Tuesday, March 28, 2006 5:13 PM > > > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > andpolicy- > > > dds-00(Peerign concepts and others..) > > > > > > > > > > > It begs the question why the two entities exchanging SIP = signaling > do > > > not exchange policy > > > > information themselves through some SIP extension/new = protocol/ > > name> and the > > > > role played by DNS. I'm not advocating this model but it seems a > > > pertinent question. > > > > > > I think peering in L3 must be basic, given how fundamental L3 is = to > the > > > internet. For SIP, TRIP provides functionality similar to BGP = (only > for > > > phone numbers though, I think). > > > > > > In my opinion, SIP peering ought to follow the email model. Once > location > > > is done and basic requirements are satisfied at the SIP layer = (like > > > identity etc), the call should be routable. As Richard said in the > earlier > > > email, the destination SP may still reject or challenge the call = if it > > > lacks either the basic requirements we agree to in the WG or some > extra > > > requirements specific to the termination SP (Core-T in my ID). The > > > challenge is that in some cases there are going to be IXPs > (Interconnects) > > > which sit in the middle due to commercial or regulatory reasons. = The > > > location of an IXP, the provisioning of this IXP and the Core-T SP = are > the > > > architectural problems which this WG needs to solve as well. > > > > > > -Medhavi. > > > > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > > > > Sent: Tuesday, March 28, 2006 3:18 PM > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 = and > > > policy- > > > > > dds-00(Peerign concepts and others..) > > > > > > > > > > Hi Reinaldo > > > > > > > > > > I am not sure the goal of SPEERMINT is to recreate L3 peering = at > L5. > > > The > > > > > problem being solved is different in that L3 peering is always > with a > > > > > fixed number of neighbors. These are stored as you mention in > static > > > > > routing tables at each node and do not change from call to = call. > In > > > > > contrast, L5 peering is not necessarily static (unless you are > talking > > > > > about a federation model). The destination is chosen only when = the > > > call is > > > > > made and may be to a peer that a given service provider/domain > > > > > administrator/node has never spoken to before. > > > > > > > > > > Assuming DNS is used to find the peering node, the query is = made > on a > > > call > > > > > by call basis. Now clearly, this DNS info can be cached at the > > > originating > > > > > node but the cache still has a very different nature than that = of > an > > > L3 > > > > > routing table. > > > > > > > > > > Policy is an entirely different issue (as is the case in L3) = and > it is > > > > > important to separate it out from the routing issue. The draft = you > > > mention > > > > > about pushing policy via DNS is dealing with one out of many > possible > > > > > topologies - namely that of ad hoc federations. There was very > little > > > > > discussion about policy at IETF 65 as the foundations of L5 > routing > > > need > > > > > to be cemented before the higher level policy issues can be > addressed. > > > > > > > > > > Cheers, > > > > > > > > > > David > > > > > > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > Sent: =E2 28 =EE=F8=F5 2006 23:34 > > > > > To: speermint@ietf.org > > > > > Subject: [Speermint] Comments on reqs-and-terminology-01 and > policy- > > > dds- > > > > > 00(Peerign concepts and others..) > > > > > > > > > > Hello, > > > > > > > > > > I've been reading "reqs and terminology" and I would like to = step > back > > > > > and ask some questions about some of the definitions. > > > > > > > > > > > > > > > Peering: > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > In layer 3 peering two routers exchange their routing tables, > reach a > > > > > steady state, and after that data packets can flow between the = two > > > > > domains. > > > > > > > > > > Layer 5 peering means, "interconnection of two service = providers > for > > > the > > > > > purposes of SIP signaling". > > > > > > > > > > Making the inevitable comparison with layer 3 peering, there = are > some > > > > > fundamental differences that I'm trying to reconcile. > > > > > > > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers > exchange > > > all > > > > > necessary routing information and enter a steady state. At = this > point, > > > > > no other routes are exchanged and routers concentrate on > forwarding > > > > > packets. > > > > > > > > > > I know the WG is in the beginning, but it is not clear to me = what > > > pieces > > > > > are needed for an equivalent functionality. For example: > > > > > > > > > > 1) Are the entities exchanging SIP signaling for the purpose = of > > > peering > > > > > doing so on a _per call_ basis? Is there going to be some > mechanism > > > to > > > > > exchange such information in bulk such as in a routing = protocol? > Maybe > > > > > based on domain names or something similar? > > > > > > > > > > 2) The draft states that " A > > > > > domain's ingress point can be thought of as the location > pointed to > > > > > by the SRV record that resulted from the resolution of the = CRD > > > (i.e., > > > > > a SIP URI)." > > > > > > > > > > So, it seems to me that although the "layer 5 peering" is > happening > > > > > between the two entities exchanging SIP signaling, the peering > point > > > > > discovery is a result of a SRV query. But the draft also = states > that " > > > > > SPEERMINT Working Group is focused on the use of such CRD." > > > > > > > > > > Draft peering-policy states that " This documents proposes the = use > of > > > > > DNS entries to publish a SIP proxy's policy for accepting = incoming > > > > > calls" proposes DNS as a way of exchange polices. > > > > > > > > > > This begs the question of what are the two "peering" entities > really > > > > > doing besides exchange traditional SIP signaling? It seems the > real > > > > > _information peering_ (for the lack of a better term) is = happening > > > > > between DNS servers. All important information related to > "peering" is > > > > > coming from a DNS server which might as well be on your own = domain > (if > > > > > your exchange DNS information). > > > > > > > > > > In summary, it seems to me the whole architecture is quite a > departure > > > > > from layer 3 peering where the entities peering are the = holders of > the > > > > > necessary information to allow data packets to flow. Here the > entities > > > > > peering publish their peering information to third party = server > which > > > > > does the actual "peering" (exchange inter-domain information). > > > > > > > > > > > > > > > Anyway, the idea of the mail is to try to clarify things. = There is > > > much > > > > > emphasis on SIP but it seems DNS plays a more central role. Or > maybe > > > > > some SIP extension will be made to exchange peering policies? > > > > > > > > > > > > > > > Policies and Independence of lower layers: > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. = Today > BGP > > > > > exchange QoS and VPN information, performs discovery, etc. = This > > > implies > > > > > that BGP indirectly (or directly) knows the capabilities of = the > > > > > transport layer (thus the name capability negotiation). > > > > > > > > > > So, although the mechanism to exchange the actual policies = needs > to be > > > > > independent of the lower layers, there needs to be a way to = input > > > lower > > > > > layer information into the devices exchanging the policies. = Just > like > > > > > BGP has filters and priorities based on a myriad of options. = So, > maybe > > > > > the wording should change a little. > > > > > > > > > > As far as 5.6 goes, it seems to me the policies can be quite > complex. > > > > > The experience of BGP tells us that in the end policies can be > huge. > > > So, > > > > > if policies are going to be huge, what draft dds-00 states as = a > > > > > possibility > > > > > > > > > > " If the simple boolean logic and the limited space in the DNS > answers > > > > > are insufficient for an application then a type of policy = rule > URIs > > > > > can be defined which links to policy statements written in = a > fully > > > > > featured policy description language like SAML [14] or = XACML > [15]." > > > > > > > > > > will actually going to be the rule. So, this begs the question = of > DNS > > > is > > > > > a good choice to publish peering policies. > > > > > > > > > > Thanks, > > > > > > > > > > Reinaldo > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > -- > > > > No virus found in this incoming message. > > > > Checked by AVG Free Edition. > > > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > 3/24/2006 > > > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: = 3/24/2006 > > >=20 > _______________________________________________ > 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 Wed Mar 29 08:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOafr-0007Wa-I3; Wed, 29 Mar 2006 08:25:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOafp-0007W4-P9 for speermint@ietf.org; Wed, 29 Mar 2006 08:25:21 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOafp-0004K1-2b for speermint@ietf.org; Wed, 29 Mar 2006 08:25:21 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 08:25:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Wed, 29 Mar 2006 08:25:19 -0500 Message-ID: <8812D8156467224C9E9739E513037EF149D447@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging thread-index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009AAAcZysAAQUy8AAAc1UfA= From: "Bob Natale" To: "Stastny Richard" X-OriginalArrivalTime: 29 Mar 2006 13:25:20.0490 (UTC) FILETIME=[3A1B24A0:01C65334] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ba8529e77affe49b0f315db98a262ee Cc: speermint@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 =20 Hi Richard, 1. Your point about the possible relevance for SPEERMINT's scope of = accounting requirements, and not billing requirements, is well-taken and = will be reflected clearly in the next rev of the Requirements BCP draft. 2. Wrt your comment: "3. So why is it necessary to charge termination = fees to the O-user at all for SIGNALLING?": Might it not be true that some applications of value to the user might = involve signaling only, and not media per se? (I am thinking of certain = presence and notification apps...?) Cheers, BobN -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, March 29, 2006 6:08 AM To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; speermint@ietf.org Subject: [Speermint] Billing, Accounting, Tariffing and Charging > > These are not rhetoric questions; I really do not know the answer. Welcome to the club, you are not alone ;-) > > VoIP is exactly the opposite. VoIP (signaling and media) are delay > sensitive, need > > prioritization and will be billed. > > >=20 > Good point. What we need is to separate the problem of peering into at = > least two parts: terminating the call and the traffic itself (data = part). > The email model applies only to the termination part. Hmmm, I think it is even more complicated. Terminology: Billing is between end-users and a SP (out of scope in spearmint) = Accounting is between SP (in scope of spearmint?) Tariffing is the = calculation of a charge for using a certain resource for a certain = amount of time. I consider it also paradox that we are discussing accounting and = charging, particularly termination charges (fees) 1. in a time even in = the PSTN issues are moving to bill-and-keep 2. on an inappropriate layer = (L5) A substantial part of the problems with VoIP peering derives not from = trust, QoS, SPIT, etc. problems, but simply how to keep up the existing = regime of termination fees. Especially mobile operators make a living on this. Where is this problem coming from on the PSTN? (Lets for a moment forget problems caused by reverse charging) In the PSTN there was originally an accounting regime based on = cascading. The O-SP bills the O-user for the call (based on distance), = and keeping part of it and paying out part to the next (transit) SP.=20 This goes on until the destination (T-SP) is reached, which also gets a share. The implicit assumptions here are: the originator has the benefit of the = call and also call set-up is in one direction and call signalling and = the mediastream is traversing all networks in question. This principle is only broken with call forwarding and also with mobile = roaming. In the US also the mobile T-user pays air-time, not so in = Europe, hence the problems with mobile NP Note: in my remark to my previous post on terminating network monopoly = (SMP), one may consider the termination fee also as a compensation for = the remedy that a terminating network MUST accept any call. This regime was quite simple, but was more and more complicated over = time by burdening it with additional issues such as subsidies, etc. as = it is currently in the US. What does this imply now for VoIP peering or interconnect VoIP; RTC and IP separate signalling (L5) from transport (L3) It also = separates the SP from the access Now taking into account some facts: 1. Although SIP signalling (call set-up) is directed from O to T, the = mediastream is both ways and symmetric (so much for Whitacre, he may = eventually blame Google Video, but not VoIP providers) 2. The cost for the mediastream is moving more and more to the ends = (access), even in the PSTN (see the latest OFCOM report on distance = gradients), and the access is already paid in some way or the other by = the end-users. 3. So why is it necessary to charge termination fees to the O-user at = all for SIGNALLING? There is one issue where termination fees may apply (although this is = going away also - e.g. Voipbuster): if you connect to the PSTN. But this is out of scope in Speermint and in addition solutions exist = here since years. My recommendation is that as long as speermint is dealing with L5 = peering only, accounting i.e. termination fees should not be dealt with. Cheers Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Wednesday, March 29, 2006 4:28 AM > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Comments on=20 > reqs-and-terminology-01andpolicy-dds- > 00(Peerign concepts and others..) >=20 > Hi Reinaldo, >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, March 28, 2006 8:31 PM > > To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01=20 > > andpolicy- > dds-00(Peerign > > concepts and others..) > > > > Hello, > > > > I tend to agree that the email model sounds attractive except the=20 > > delay > and business > > requirements of email and VoIP are quire different. > > > > Email is not delay sensitive, does not require any type of > prioritization and is not charged > > (or at least it wasn't). > > > > VoIP is exactly the opposite. VoIP (signaling and media) are delay > sensitive, need > > prioritization and will be billed. > > >=20 > Good point. What we need is to separate the problem of peering into at = > least two parts: terminating the call and the traffic itself (data = part). > The email model applies only to the termination part. >=20 > > I believe a call to a public number is (or should) always going to=20 > > be > routable. I guess my > > main question is: is the general belief that VoIP providers will=20 > > just > configure their proxy > > servers to talk to each other in an email type model? No business > agreements similar to > > PSTN/Wireless, no charging, no extra billing for "roaming", etc? > > >=20 > I agree those are issues. It would be good if we can work out=20 > something which is generic (compared to IMS/PSTN specific). Maybe they = > are out of scope since we are dealing with protocol and architecture=20 > issues in the WG. The only aspect billing and roaming affect is that=20 > if all technical requirements (e.g the ones this WG specifies) are=20 > satisfied, the peer could still reject traffic (w/o consulting the=20 > destination user, in Richard's terms) if the commercial relationship=20 > does not exist. I think this is what hampers connectivity today. All=20 > these commercial relationships exist because SPs want to be layer 5=20 > aware (they cannot seem to find a way to evolve their business models=20 > otherwise... :), where only the origination SP (Core-O) and Core-T=20 > need to have a commercial relationship. The roaming aspect again may=20 > be quite artificial and could be questionable going forward... Just = my personal comments. >=20 > -Medhavi. >=20 > > My reply to David's email was more to the idea that you can install=20 > > a > proxy server > > somewhere, point the "MX" to the next upstream "proxy server" and be > done with it? As > > VoIP takes off wouldn't some basic regulatory issues, numbering=20 > > schemes > and others > > prevent such behavior? > > > > These are not rhetoric questions; I really do not know the answer. > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Tuesday, March 28, 2006 5:13 PM > > > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > andpolicy- > > > dds-00(Peerign concepts and others..) > > > > > > > > > > > It begs the question why the two entities exchanging SIP=20 > > > > signaling > do > > > not exchange policy > > > > information themselves through some SIP extension/new=20 > > > > protocol/ > > name> and the > > > > role played by DNS. I'm not advocating this model but it seems a > > > pertinent question. > > > > > > I think peering in L3 must be basic, given how fundamental L3 is=20 > > > to > the > > > internet. For SIP, TRIP provides functionality similar to BGP=20 > > > (only > for > > > phone numbers though, I think). > > > > > > In my opinion, SIP peering ought to follow the email model. Once > location > > > is done and basic requirements are satisfied at the SIP layer=20 > > > (like identity etc), the call should be routable. As Richard said=20 > > > in the > earlier > > > email, the destination SP may still reject or challenge the call=20 > > > if it lacks either the basic requirements we agree to in the WG or = > > > some > extra > > > requirements specific to the termination SP (Core-T in my ID). The = > > > challenge is that in some cases there are going to be IXPs > (Interconnects) > > > which sit in the middle due to commercial or regulatory reasons.=20 > > > The location of an IXP, the provisioning of this IXP and the=20 > > > Core-T SP are > the > > > architectural problems which this WG needs to solve as well. > > > > > > -Medhavi. > > > > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > > > > Sent: Tuesday, March 28, 2006 3:18 PM > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01=20 > > > > > and > > > policy- > > > > > dds-00(Peerign concepts and others..) > > > > > > > > > > Hi Reinaldo > > > > > > > > > > I am not sure the goal of SPEERMINT is to recreate L3 peering=20 > > > > > at > L5. > > > The > > > > > problem being solved is different in that L3 peering is always > with a > > > > > fixed number of neighbors. These are stored as you mention in > static > > > > > routing tables at each node and do not change from call to = call. > In > > > > > contrast, L5 peering is not necessarily static (unless you are > talking > > > > > about a federation model). The destination is chosen only when = > > > > > the > > > call is > > > > > made and may be to a peer that a given service provider/domain = > > > > > administrator/node has never spoken to before. > > > > > > > > > > Assuming DNS is used to find the peering node, the query is=20 > > > > > made > on a > > > call > > > > > by call basis. Now clearly, this DNS info can be cached at the > > > originating > > > > > node but the cache still has a very different nature than that = > > > > > of > an > > > L3 > > > > > routing table. > > > > > > > > > > Policy is an entirely different issue (as is the case in L3)=20 > > > > > and > it is > > > > > important to separate it out from the routing issue. The draft = > > > > > you > > > mention > > > > > about pushing policy via DNS is dealing with one out of many > possible > > > > > topologies - namely that of ad hoc federations. There was very > little > > > > > discussion about policy at IETF 65 as the foundations of L5 > routing > > > need > > > > > to be cemented before the higher level policy issues can be > addressed. > > > > > > > > > > Cheers, > > > > > > > > > > David > > > > > > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > Sent: =E2 28 =EE=F8=F5 2006 23:34 > > > > > To: speermint@ietf.org > > > > > Subject: [Speermint] Comments on reqs-and-terminology-01 and > policy- > > > dds- > > > > > 00(Peerign concepts and others..) > > > > > > > > > > Hello, > > > > > > > > > > I've been reading "reqs and terminology" and I would like to=20 > > > > > step > back > > > > > and ask some questions about some of the definitions. > > > > > > > > > > > > > > > Peering: > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > In layer 3 peering two routers exchange their routing tables, > reach a > > > > > steady state, and after that data packets can flow between the = > > > > > two domains. > > > > > > > > > > Layer 5 peering means, "interconnection of two service=20 > > > > > providers > for > > > the > > > > > purposes of SIP signaling". > > > > > > > > > > Making the inevitable comparison with layer 3 peering, there=20 > > > > > are > some > > > > > fundamental differences that I'm trying to reconcile. > > > > > > > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers > exchange > > > all > > > > > necessary routing information and enter a steady state. At=20 > > > > > this > point, > > > > > no other routes are exchanged and routers concentrate on > forwarding > > > > > packets. > > > > > > > > > > I know the WG is in the beginning, but it is not clear to me=20 > > > > > what > > > pieces > > > > > are needed for an equivalent functionality. For example: > > > > > > > > > > 1) Are the entities exchanging SIP signaling for the purpose=20 > > > > > of > > > peering > > > > > doing so on a _per call_ basis? Is there going to be some > mechanism > > > to > > > > > exchange such information in bulk such as in a routing = protocol? > Maybe > > > > > based on domain names or something similar? > > > > > > > > > > 2) The draft states that " A > > > > > domain's ingress point can be thought of as the location > pointed to > > > > > by the SRV record that resulted from the resolution of the=20 > > > > > CRD > > > (i.e., > > > > > a SIP URI)." > > > > > > > > > > So, it seems to me that although the "layer 5 peering" is > happening > > > > > between the two entities exchanging SIP signaling, the peering > point > > > > > discovery is a result of a SRV query. But the draft also=20 > > > > > states > that " > > > > > SPEERMINT Working Group is focused on the use of such CRD." > > > > > > > > > > Draft peering-policy states that " This documents proposes the = > > > > > use > of > > > > > DNS entries to publish a SIP proxy's policy for accepting=20 > > > > > incoming calls" proposes DNS as a way of exchange polices. > > > > > > > > > > This begs the question of what are the two "peering" entities > really > > > > > doing besides exchange traditional SIP signaling? It seems the > real > > > > > _information peering_ (for the lack of a better term) is=20 > > > > > happening between DNS servers. All important information=20 > > > > > related to > "peering" is > > > > > coming from a DNS server which might as well be on your own=20 > > > > > domain > (if > > > > > your exchange DNS information). > > > > > > > > > > In summary, it seems to me the whole architecture is quite a > departure > > > > > from layer 3 peering where the entities peering are the=20 > > > > > holders of > the > > > > > necessary information to allow data packets to flow. Here the > entities > > > > > peering publish their peering information to third party=20 > > > > > server > which > > > > > does the actual "peering" (exchange inter-domain information). > > > > > > > > > > > > > > > Anyway, the idea of the mail is to try to clarify things.=20 > > > > > There is > > > much > > > > > emphasis on SIP but it seems DNS plays a more central role. Or > maybe > > > > > some SIP extension will be made to exchange peering policies? > > > > > > > > > > > > > > > Policies and Independence of lower layers: > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting.=20 > > > > > Today > BGP > > > > > exchange QoS and VPN information, performs discovery, etc.=20 > > > > > This > > > implies > > > > > that BGP indirectly (or directly) knows the capabilities of=20 > > > > > the transport layer (thus the name capability negotiation). > > > > > > > > > > So, although the mechanism to exchange the actual policies=20 > > > > > needs > to be > > > > > independent of the lower layers, there needs to be a way to=20 > > > > > input > > > lower > > > > > layer information into the devices exchanging the policies.=20 > > > > > Just > like > > > > > BGP has filters and priorities based on a myriad of options.=20 > > > > > So, > maybe > > > > > the wording should change a little. > > > > > > > > > > As far as 5.6 goes, it seems to me the policies can be quite > complex. > > > > > The experience of BGP tells us that in the end policies can be > huge. > > > So, > > > > > if policies are going to be huge, what draft dds-00 states as=20 > > > > > a possibility > > > > > > > > > > " If the simple boolean logic and the limited space in the DNS > answers > > > > > are insufficient for an application then a type of policy=20 > > > > > rule > URIs > > > > > can be defined which links to policy statements written in=20 > > > > > a > fully > > > > > featured policy description language like SAML [14] or=20 > > > > > XACML > [15]." > > > > > > > > > > will actually going to be the rule. So, this begs the question = > > > > > of > DNS > > > is > > > > > a good choice to publish peering policies. > > > > > > > > > > Thanks, > > > > > > > > > > Reinaldo > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > -- > > > > No virus found in this incoming message. > > > > Checked by AVG Free Edition. > > > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > 3/24/2006 > > > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date:=20 > > 3/24/2006 > > >=20 > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 29 08:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObAm-0002Cb-PU; Wed, 29 Mar 2006 08:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObAl-0002CU-Qq for speermint@ietf.org; Wed, 29 Mar 2006 08:57:19 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FObAj-0005iF-KX for speermint@ietf.org; Wed, 29 Mar 2006 08:57:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Wed, 29 Mar 2006 16:01:16 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4E88@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009AAAcZysAAQUy8AAAc1UfAAAJn8EA== From: "Stastny Richard" To: "Bob Natale" X-Spam-Score: 0.0 (/) X-Scan-Signature: eee8f8a810071652260f5b6c3a710e46 Cc: speermint@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 Bob wrote: > 2. Wrt your comment: "3. So why is it necessary to charge termination > fees to the O-user at all for SIGNALLING?": > Might it not be true that some applications of value to the user might > involve signaling only, and not media per se? (I am thinking of = certain > presence and notification apps...?) Thanks for bringing this up, because I forgot to mention one very important issue in my elaboration: SIP is a session initiation protocol (!), end2end Therefore it is up to the end-user may decide what kind of application they use to communicate, voice, video, IM, etc. they also may change the media during communication. This is negotiated in the message body So how can the proxy at L5 signalling layers be involved in L3 charging if he does not (need to) know what kind of resources will be required at the access and transport layers, so how they can charge? This is even recognized in the 3GPP IMS architecture - see Camarillo/Garcia-Martin - The 3G IMS, in section 4.7 Message body page 63 - for the avoidance of doubt: "An important property of bodies is that they are transmitted end to end. This is, proxies do not need to parse the message body in order to route the message. In fact, the user agents may choose to encrypt the contents of the message body end to end. In this case, proxies would not even be able to tell which type of session is being established between both user agents." Although they seem to have completely forgotten this some sections later when the describe in section 7.4 the=20 IMS accounting architecture. So I wonder ... Cheers Richard > -----Original Message----- > From: Bob Natale [mailto:bnatale@nextone.com] > Sent: Wednesday, March 29, 2006 3:25 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging >=20 >=20 > Hi Richard, >=20 > 1. Your point about the possible relevance for SPEERMINT's scope of > accounting requirements, and not billing requirements, is well-taken = and > will be reflected clearly in the next rev of the Requirements BCP = draft. >=20 > 2. Wrt your comment: "3. So why is it necessary to charge termination > fees to the O-user at all for SIGNALLING?": > Might it not be true that some applications of value to the user might > involve signaling only, and not media per se? (I am thinking of = certain > presence and notification apps...?) >=20 > Cheers, > BobN >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 29, 2006 6:08 AM > To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; speermint@ietf.org > Subject: [Speermint] Billing, Accounting, Tariffing and Charging >=20 > > > These are not rhetoric questions; I really do not know the answer. >=20 > Welcome to the club, you are not alone ;-) >=20 > > > VoIP is exactly the opposite. VoIP (signaling and media) are delay > > sensitive, need > > > prioritization and will be billed. > > > > > > > Good point. What we need is to separate the problem of peering into = at > > least two parts: terminating the call and the traffic itself (data > part). > > The email model applies only to the termination part. >=20 > Hmmm, I think it is even more complicated. >=20 > Terminology: >=20 > Billing is between end-users and a SP (out of scope in spearmint) > Accounting is between SP (in scope of spearmint?) Tariffing is the > calculation of a charge for using a certain resource for a certain = amount > of time. >=20 > I consider it also paradox that we are discussing accounting and = charging, > particularly termination charges (fees) 1. in a time even in the PSTN > issues are moving to bill-and-keep 2. on an inappropriate layer (L5) >=20 > A substantial part of the problems with VoIP peering derives not from > trust, QoS, SPIT, etc. problems, but simply how to keep up the = existing > regime of termination fees. >=20 > Especially mobile operators make a living on this. >=20 > Where is this problem coming from on the PSTN? > (Lets for a moment forget problems caused by reverse > charging) >=20 > In the PSTN there was originally an accounting regime based on = cascading. > The O-SP bills the O-user for the call (based on distance), and = keeping > part of it and paying out part to the next (transit) SP. > This goes on until the destination > (T-SP) is reached, which also gets a share. >=20 > The implicit assumptions here are: the originator has the benefit of = the > call and also call set-up is in one direction and call signalling and = the > mediastream is traversing all networks in question. >=20 > This principle is only broken with call forwarding and also with = mobile > roaming. In the US also the mobile T-user pays air-time, not so in = Europe, > hence the problems with mobile NP >=20 > Note: in my remark to my previous post on terminating network monopoly > (SMP), one may consider the termination fee also as a compensation for = the > remedy that a terminating network MUST accept any call. >=20 > This regime was quite simple, but was more and more complicated over = time > by burdening it with additional issues such as subsidies, etc. as it = is > currently in the US. >=20 >=20 > What does this imply now for VoIP peering or interconnect >=20 > VoIP; RTC and IP separate signalling (L5) from transport (L3) It also > separates the SP from the access Now taking into account some facts: >=20 > 1. Although SIP signalling (call set-up) is directed from O to T, the > mediastream is both ways and symmetric (so much for Whitacre, he may > eventually blame Google Video, but not VoIP providers) >=20 > 2. The cost for the mediastream is moving more and more to the ends > (access), even in the PSTN (see the latest OFCOM report on distance > gradients), and the access is already paid in some way or the other by = the > end-users. >=20 > 3. So why is it necessary to charge termination fees to the O-user at = all > for SIGNALLING? >=20 > There is one issue where termination fees may apply (although this is > going away also - e.g. > Voipbuster): if you connect to the PSTN. >=20 > But this is out of scope in Speermint and in addition solutions exist = here > since years. >=20 > My recommendation is that as long as speermint is dealing with L5 = peering > only, accounting i.e. termination fees should not be dealt with. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Wednesday, March 29, 2006 4:28 AM > > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > Subject: RE: [Speermint] Comments on > > reqs-and-terminology-01andpolicy-dds- > > 00(Peerign concepts and others..) > > > > Hi Reinaldo, > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Tuesday, March 28, 2006 8:31 PM > > > To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > > andpolicy- > > dds-00(Peerign > > > concepts and others..) > > > > > > Hello, > > > > > > I tend to agree that the email model sounds attractive except the > > > delay > > and business > > > requirements of email and VoIP are quire different. > > > > > > Email is not delay sensitive, does not require any type of > > prioritization and is not charged > > > (or at least it wasn't). > > > > > > VoIP is exactly the opposite. VoIP (signaling and media) are delay > > sensitive, need > > > prioritization and will be billed. > > > > > > > Good point. What we need is to separate the problem of peering into = at > > least two parts: terminating the call and the traffic itself (data > part). > > The email model applies only to the termination part. > > > > > I believe a call to a public number is (or should) always going to > > > be > > routable. I guess my > > > main question is: is the general belief that VoIP providers will > > > just > > configure their proxy > > > servers to talk to each other in an email type model? No business > > agreements similar to > > > PSTN/Wireless, no charging, no extra billing for "roaming", etc? > > > > > > > I agree those are issues. It would be good if we can work out > > something which is generic (compared to IMS/PSTN specific). Maybe = they > > are out of scope since we are dealing with protocol and architecture > > issues in the WG. The only aspect billing and roaming affect is that > > if all technical requirements (e.g the ones this WG specifies) are > > satisfied, the peer could still reject traffic (w/o consulting the > > destination user, in Richard's terms) if the commercial relationship > > does not exist. I think this is what hampers connectivity today. All > > these commercial relationships exist because SPs want to be layer 5 > > aware (they cannot seem to find a way to evolve their business = models > > otherwise... :), where only the origination SP (Core-O) and Core-T > > need to have a commercial relationship. The roaming aspect again may > > be quite artificial and could be questionable going forward... Just = my > personal comments. > > > > -Medhavi. > > > > > My reply to David's email was more to the idea that you can = install > > > a > > proxy server > > > somewhere, point the "MX" to the next upstream "proxy server" and = be > > done with it? As > > > VoIP takes off wouldn't some basic regulatory issues, numbering > > > schemes > > and others > > > prevent such behavior? > > > > > > These are not rhetoric questions; I really do not know the answer. > > > > > > Regards, > > > > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > > Sent: Tuesday, March 28, 2006 5:13 PM > > > > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > andpolicy- > > > > dds-00(Peerign concepts and others..) > > > > > > > > > > > > > > It begs the question why the two entities exchanging SIP > > > > > signaling > > do > > > > not exchange policy > > > > > information themselves through some SIP extension/new > > > > > protocol/ > > > name> and the > > > > > role played by DNS. I'm not advocating this model but it seems = a > > > > pertinent question. > > > > > > > > I think peering in L3 must be basic, given how fundamental L3 is > > > > to > > the > > > > internet. For SIP, TRIP provides functionality similar to BGP > > > > (only > > for > > > > phone numbers though, I think). > > > > > > > > In my opinion, SIP peering ought to follow the email model. Once > > location > > > > is done and basic requirements are satisfied at the SIP layer > > > > (like identity etc), the call should be routable. As Richard = said > > > > in the > > earlier > > > > email, the destination SP may still reject or challenge the call > > > > if it lacks either the basic requirements we agree to in the WG = or > > > > some > > extra > > > > requirements specific to the termination SP (Core-T in my ID). = The > > > > challenge is that in some cases there are going to be IXPs > > (Interconnects) > > > > which sit in the middle due to commercial or regulatory reasons. > > > > The location of an IXP, the provisioning of this IXP and the > > > > Core-T SP are > > the > > > > architectural problems which this WG needs to solve as well. > > > > > > > > -Medhavi. > > > > > > > > > > > > > > Regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > -----Original Message----- > > > > > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > > > > > Sent: Tuesday, March 28, 2006 3:18 PM > > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > > > > > and > > > > policy- > > > > > > dds-00(Peerign concepts and others..) > > > > > > > > > > > > Hi Reinaldo > > > > > > > > > > > > I am not sure the goal of SPEERMINT is to recreate L3 = peering > > > > > > at > > L5. > > > > The > > > > > > problem being solved is different in that L3 peering is = always > > with a > > > > > > fixed number of neighbors. These are stored as you mention = in > > static > > > > > > routing tables at each node and do not change from call to = call. > > In > > > > > > contrast, L5 peering is not necessarily static (unless you = are > > talking > > > > > > about a federation model). The destination is chosen only = when > > > > > > the > > > > call is > > > > > > made and may be to a peer that a given service = provider/domain > > > > > > administrator/node has never spoken to before. > > > > > > > > > > > > Assuming DNS is used to find the peering node, the query is > > > > > > made > > on a > > > > call > > > > > > by call basis. Now clearly, this DNS info can be cached at = the > > > > originating > > > > > > node but the cache still has a very different nature than = that > > > > > > of > > an > > > > L3 > > > > > > routing table. > > > > > > > > > > > > Policy is an entirely different issue (as is the case in L3) > > > > > > and > > it is > > > > > > important to separate it out from the routing issue. The = draft > > > > > > you > > > > mention > > > > > > about pushing policy via DNS is dealing with one out of many > > possible > > > > > > topologies - namely that of ad hoc federations. There was = very > > little > > > > > > discussion about policy at IETF 65 as the foundations of L5 > > routing > > > > need > > > > > > to be cemented before the higher level policy issues can be > > addressed. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > David > > > > > > > > > > > > -----Original Message----- > > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Sent: =E2 28 =EE=F8=F5 2006 23:34 > > > > > > To: speermint@ietf.org > > > > > > Subject: [Speermint] Comments on reqs-and-terminology-01 and > > policy- > > > > dds- > > > > > > 00(Peerign concepts and others..) > > > > > > > > > > > > Hello, > > > > > > > > > > > > I've been reading "reqs and terminology" and I would like to > > > > > > step > > back > > > > > > and ask some questions about some of the definitions. > > > > > > > > > > > > > > > > > > Peering: > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > In layer 3 peering two routers exchange their routing = tables, > > reach a > > > > > > steady state, and after that data packets can flow between = the > > > > > > two domains. > > > > > > > > > > > > Layer 5 peering means, "interconnection of two service > > > > > > providers > > for > > > > the > > > > > > purposes of SIP signaling". > > > > > > > > > > > > Making the inevitable comparison with layer 3 peering, there > > > > > > are > > some > > > > > > fundamental differences that I'm trying to reconcile. > > > > > > > > > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers > > exchange > > > > all > > > > > > necessary routing information and enter a steady state. At > > > > > > this > > point, > > > > > > no other routes are exchanged and routers concentrate on > > forwarding > > > > > > packets. > > > > > > > > > > > > I know the WG is in the beginning, but it is not clear to me > > > > > > what > > > > pieces > > > > > > are needed for an equivalent functionality. For example: > > > > > > > > > > > > 1) Are the entities exchanging SIP signaling for the purpose > > > > > > of > > > > peering > > > > > > doing so on a _per call_ basis? Is there going to be some > > mechanism > > > > to > > > > > > exchange such information in bulk such as in a routing = protocol? > > Maybe > > > > > > based on domain names or something similar? > > > > > > > > > > > > 2) The draft states that " A > > > > > > domain's ingress point can be thought of as the location > > pointed to > > > > > > by the SRV record that resulted from the resolution of = the > > > > > > CRD > > > > (i.e., > > > > > > a SIP URI)." > > > > > > > > > > > > So, it seems to me that although the "layer 5 peering" is > > happening > > > > > > between the two entities exchanging SIP signaling, the = peering > > point > > > > > > discovery is a result of a SRV query. But the draft also > > > > > > states > > that " > > > > > > SPEERMINT Working Group is focused on the use of such CRD." > > > > > > > > > > > > Draft peering-policy states that " This documents proposes = the > > > > > > use > > of > > > > > > DNS entries to publish a SIP proxy's policy for accepting > > > > > > incoming calls" proposes DNS as a way of exchange polices. > > > > > > > > > > > > This begs the question of what are the two "peering" = entities > > really > > > > > > doing besides exchange traditional SIP signaling? It seems = the > > real > > > > > > _information peering_ (for the lack of a better term) is > > > > > > happening between DNS servers. All important information > > > > > > related to > > "peering" is > > > > > > coming from a DNS server which might as well be on your own > > > > > > domain > > (if > > > > > > your exchange DNS information). > > > > > > > > > > > > In summary, it seems to me the whole architecture is quite a > > departure > > > > > > from layer 3 peering where the entities peering are the > > > > > > holders of > > the > > > > > > necessary information to allow data packets to flow. Here = the > > entities > > > > > > peering publish their peering information to third party > > > > > > server > > which > > > > > > does the actual "peering" (exchange inter-domain = information). > > > > > > > > > > > > > > > > > > Anyway, the idea of the mail is to try to clarify things. > > > > > > There is > > > > much > > > > > > emphasis on SIP but it seems DNS plays a more central role. = Or > > maybe > > > > > > some SIP extension will be made to exchange peering = policies? > > > > > > > > > > > > > > > > > > Policies and Independence of lower layers: > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. > > > > > > Today > > BGP > > > > > > exchange QoS and VPN information, performs discovery, etc. > > > > > > This > > > > implies > > > > > > that BGP indirectly (or directly) knows the capabilities of > > > > > > the transport layer (thus the name capability negotiation). > > > > > > > > > > > > So, although the mechanism to exchange the actual policies > > > > > > needs > > to be > > > > > > independent of the lower layers, there needs to be a way to > > > > > > input > > > > lower > > > > > > layer information into the devices exchanging the policies. > > > > > > Just > > like > > > > > > BGP has filters and priorities based on a myriad of options. > > > > > > So, > > maybe > > > > > > the wording should change a little. > > > > > > > > > > > > As far as 5.6 goes, it seems to me the policies can be quite > > complex. > > > > > > The experience of BGP tells us that in the end policies can = be > > huge. > > > > So, > > > > > > if policies are going to be huge, what draft dds-00 states = as > > > > > > a possibility > > > > > > > > > > > > " If the simple boolean logic and the limited space in the = DNS > > answers > > > > > > are insufficient for an application then a type of policy > > > > > > rule > > URIs > > > > > > can be defined which links to policy statements written = in > > > > > > a > > fully > > > > > > featured policy description language like SAML [14] or > > > > > > XACML > > [15]." > > > > > > > > > > > > will actually going to be the rule. So, this begs the = question > > > > > > of > > DNS > > > > is > > > > > > a good choice to publish peering policies. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Reinaldo > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > -- > > > > > No virus found in this incoming message. > > > > > Checked by AVG Free Edition. > > > > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > 3/24/2006 > > > > > > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > > 3/24/2006 > > > > > > > _______________________________________________ > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 29 08:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObBW-0002TS-26; Wed, 29 Mar 2006 08:58:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObBU-0002Sg-K2 for speermint@ietf.org; Wed, 29 Mar 2006 08:58:04 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FObBS-0005jn-K1 for speermint@ietf.org; Wed, 29 Mar 2006 08:58:04 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2006 05:58:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,144,1141632000"; d="scan'208"; a="24710322:sNHT30272864" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2TDvuWi005522; Wed, 29 Mar 2006 08:58:01 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 08:57:58 -0500 Received: from [161.44.79.176] ([161.44.79.176]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 08:57:57 -0500 Message-ID: <442A9264.2030208@cisco.com> Date: Wed, 29 Mar 2006 08:57:56 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Natale Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging References: <8812D8156467224C9E9739E513037EF149D447@moe.nextone.local> In-Reply-To: <8812D8156467224C9E9739E513037EF149D447@moe.nextone.local> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Mar 2006 13:57:57.0895 (UTC) FILETIME=[C8CF7170:01C65338] X-Spam-Score: 0.0 (/) X-Scan-Signature: 953c1b32cb44691090e7eb33ccb290af Cc: Stastny Richard , speermint@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 Bob Natale wrote: > > Hi Richard, > > 1. Your point about the possible relevance for SPEERMINT's scope of accounting requirements, and not billing requirements, is well-taken and will be reflected clearly in the next rev of the Requirements BCP draft. > > 2. Wrt your comment: "3. So why is it necessary to charge termination fees to the O-user at all for SIGNALLING?": > Might it not be true that some applications of value to the user might involve signaling only, and not media per se? (I am thinking of certain presence and notification apps...?) What does that change? IMO it makes sense to charge for services actually rendered, and not for services the SP isn't involved in but wishes they could get some revenue from. The terminating proxy does render some identifiable services that could potentially be charged for: - supplying the AOR - processing (routing) requests to the AOR These are of value precisely because they eliminate the need for the end user to keep a UA online at all times, and because it permits the end user to dynamically associate UAs with the AOR, by providing a potentially recognized and trusted domain. This doesn't seem like stuff that justifies per-use charging, and the amount of charging that can be extracted for these basic services is probably limited, but its something. If an SP wants to charge more, then they will have to provide more services - ones that users are interested in paying for. Paul > Cheers, > BobN > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 29, 2006 6:08 AM > To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; speermint@ietf.org > Subject: [Speermint] Billing, Accounting, Tariffing and Charging > > >>>These are not rhetoric questions; I really do not know the answer. > > > Welcome to the club, you are not alone ;-) > > >>>VoIP is exactly the opposite. VoIP (signaling and media) are delay >> >>sensitive, need >> >>>prioritization and will be billed. >>> >> >>Good point. What we need is to separate the problem of peering into at >>least two parts: terminating the call and the traffic itself (data part). >>The email model applies only to the termination part. > > > Hmmm, I think it is even more complicated. > > Terminology: > > Billing is between end-users and a SP (out of scope in spearmint) Accounting is between SP (in scope of spearmint?) Tariffing is the calculation of a charge for using a certain resource for a certain amount of time. > > I consider it also paradox that we are discussing accounting and charging, particularly termination charges (fees) 1. in a time even in the PSTN issues are moving to bill-and-keep 2. on an inappropriate layer (L5) > > A substantial part of the problems with VoIP peering derives not from trust, QoS, SPIT, etc. problems, but simply how to keep up the existing regime of termination fees. > > Especially mobile operators make a living on this. > > Where is this problem coming from on the PSTN? > (Lets for a moment forget problems caused by reverse > charging) > > In the PSTN there was originally an accounting regime based on cascading. The O-SP bills the O-user for the call (based on distance), and keeping part of it and paying out part to the next (transit) SP. > This goes on until the destination > (T-SP) is reached, which also gets a share. > > The implicit assumptions here are: the originator has the benefit of the call and also call set-up is in one direction and call signalling and the mediastream is traversing all networks in question. > > This principle is only broken with call forwarding and also with mobile roaming. In the US also the mobile T-user pays air-time, not so in Europe, hence the problems with mobile NP > > Note: in my remark to my previous post on terminating network monopoly (SMP), one may consider the termination fee also as a compensation for the remedy that a terminating network MUST accept any call. > > This regime was quite simple, but was more and more complicated over time by burdening it with additional issues such as subsidies, etc. as it is currently in the US. > > > What does this imply now for VoIP peering or interconnect > > VoIP; RTC and IP separate signalling (L5) from transport (L3) It also separates the SP from the access Now taking into account some facts: > > 1. Although SIP signalling (call set-up) is directed from O to T, the mediastream is both ways and symmetric (so much for Whitacre, he may eventually blame Google Video, but not VoIP providers) > > 2. The cost for the mediastream is moving more and more to the ends (access), even in the PSTN (see the latest OFCOM report on distance gradients), and the access is already paid in some way or the other by the end-users. > > 3. So why is it necessary to charge termination fees to the O-user at all for SIGNALLING? > > There is one issue where termination fees may apply (although this is going away also - e.g. > Voipbuster): if you connect to the PSTN. > > But this is out of scope in Speermint and in addition solutions exist here since years. > > My recommendation is that as long as speermint is dealing with L5 peering only, accounting i.e. termination fees should not be dealt with. > > Cheers > > Richard > > > > > >>-----Original Message----- >>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] >>Sent: Wednesday, March 29, 2006 4:28 AM >>To: Reinaldo Penno; David Schwartz; speermint@ietf.org >>Subject: RE: [Speermint] Comments on >>reqs-and-terminology-01andpolicy-dds- >>00(Peerign concepts and others..) >> >>Hi Reinaldo, >> >> >>>-----Original Message----- >>>From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>Sent: Tuesday, March 28, 2006 8:31 PM >>>To: Medhavi Bhatia; David Schwartz; speermint@ietf.org >>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 >>>andpolicy- >> >>dds-00(Peerign >> >>>concepts and others..) >>> >>>Hello, >>> >>>I tend to agree that the email model sounds attractive except the >>>delay >> >>and business >> >>>requirements of email and VoIP are quire different. >>> >>>Email is not delay sensitive, does not require any type of >> >>prioritization and is not charged >> >>>(or at least it wasn't). >>> >>>VoIP is exactly the opposite. VoIP (signaling and media) are delay >> >>sensitive, need >> >>>prioritization and will be billed. >>> >> >>Good point. What we need is to separate the problem of peering into at >>least two parts: terminating the call and the traffic itself (data part). >>The email model applies only to the termination part. >> >> >>>I believe a call to a public number is (or should) always going to >>>be >> >>routable. I guess my >> >>>main question is: is the general belief that VoIP providers will >>>just >> >>configure their proxy >> >>>servers to talk to each other in an email type model? No business >> >>agreements similar to >> >>>PSTN/Wireless, no charging, no extra billing for "roaming", etc? >>> >> >>I agree those are issues. It would be good if we can work out >>something which is generic (compared to IMS/PSTN specific). Maybe they >>are out of scope since we are dealing with protocol and architecture >>issues in the WG. The only aspect billing and roaming affect is that >>if all technical requirements (e.g the ones this WG specifies) are >>satisfied, the peer could still reject traffic (w/o consulting the >>destination user, in Richard's terms) if the commercial relationship >>does not exist. I think this is what hampers connectivity today. All >>these commercial relationships exist because SPs want to be layer 5 >>aware (they cannot seem to find a way to evolve their business models >>otherwise... :), where only the origination SP (Core-O) and Core-T >>need to have a commercial relationship. The roaming aspect again may >>be quite artificial and could be questionable going forward... Just my personal comments. >> >>-Medhavi. >> >> >>>My reply to David's email was more to the idea that you can install >>>a >> >>proxy server >> >>>somewhere, point the "MX" to the next upstream "proxy server" and be >> >>done with it? As >> >>>VoIP takes off wouldn't some basic regulatory issues, numbering >>>schemes >> >>and others >> >>>prevent such behavior? >>> >>>These are not rhetoric questions; I really do not know the answer. >>> >>>Regards, >>> >>>Reinaldo >>> >>> >>>>-----Original Message----- >>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] >>>>Sent: Tuesday, March 28, 2006 5:13 PM >>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org >>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 >> >>andpolicy- >> >>>>dds-00(Peerign concepts and others..) >>>> >>>> >>>>>It begs the question why the two entities exchanging SIP >>>>>signaling >> >>do >> >>>>not exchange policy >>>> >>>>>information themselves through some SIP extension/new >>>>>protocol/>>> >>>>name> and the >>>> >>>>>role played by DNS. I'm not advocating this model but it seems a >>>> >>>>pertinent question. >>>> >>>>I think peering in L3 must be basic, given how fundamental L3 is >>>>to >> >>the >> >>>>internet. For SIP, TRIP provides functionality similar to BGP >>>>(only >> >>for >> >>>>phone numbers though, I think). >>>> >>>>In my opinion, SIP peering ought to follow the email model. Once >> >>location >> >>>>is done and basic requirements are satisfied at the SIP layer >>>>(like identity etc), the call should be routable. As Richard said >>>>in the >> >>earlier >> >>>>email, the destination SP may still reject or challenge the call >>>>if it lacks either the basic requirements we agree to in the WG or >>>>some >> >>extra >> >>>>requirements specific to the termination SP (Core-T in my ID). The >>>>challenge is that in some cases there are going to be IXPs >> >>(Interconnects) >> >>>>which sit in the middle due to commercial or regulatory reasons. >>>>The location of an IXP, the provisioning of this IXP and the >>>>Core-T SP are >> >>the >> >>>>architectural problems which this WG needs to solve as well. >>>> >>>>-Medhavi. >>>> >>>> >>>>>Regards, >>>>> >>>>>Reinaldo >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: David Schwartz [mailto:David.Schwartz@Kayote.com] >>>>>>Sent: Tuesday, March 28, 2006 3:18 PM >>>>>>To: Reinaldo Penno; speermint@ietf.org >>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 >>>>>>and >>>> >>>>policy- >>>> >>>>>>dds-00(Peerign concepts and others..) >>>>>> >>>>>>Hi Reinaldo >>>>>> >>>>>>I am not sure the goal of SPEERMINT is to recreate L3 peering >>>>>>at >> >>L5. >> >>>>The >>>> >>>>>>problem being solved is different in that L3 peering is always >> >>with a >> >>>>>>fixed number of neighbors. These are stored as you mention in >> >>static >> >>>>>>routing tables at each node and do not change from call to call. >> >>In >> >>>>>>contrast, L5 peering is not necessarily static (unless you are >> >>talking >> >>>>>>about a federation model). The destination is chosen only when >>>>>>the >>>> >>>>call is >>>> >>>>>>made and may be to a peer that a given service provider/domain >>>>>>administrator/node has never spoken to before. >>>>>> >>>>>>Assuming DNS is used to find the peering node, the query is >>>>>>made >> >>on a >> >>>>call >>>> >>>>>>by call basis. Now clearly, this DNS info can be cached at the >>>> >>>>originating >>>> >>>>>>node but the cache still has a very different nature than that >>>>>>of >> >>an >> >>>>L3 >>>> >>>>>>routing table. >>>>>> >>>>>>Policy is an entirely different issue (as is the case in L3) >>>>>>and >> >>it is >> >>>>>>important to separate it out from the routing issue. The draft >>>>>>you >>>> >>>>mention >>>> >>>>>>about pushing policy via DNS is dealing with one out of many >> >>possible >> >>>>>>topologies - namely that of ad hoc federations. There was very >> >>little >> >>>>>>discussion about policy at IETF 65 as the foundations of L5 >> >>routing >> >>>>need >>>> >>>>>>to be cemented before the higher level policy issues can be >> >>addressed. >> >>>>>>Cheers, >>>>>> >>>>>>David >>>>>> >>>>>>-----Original Message----- >>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>>>Sent: â 28 îøõ 2006 23:34 >>>>>>To: speermint@ietf.org >>>>>>Subject: [Speermint] Comments on reqs-and-terminology-01 and >> >>policy- >> >>>>dds- >>>> >>>>>>00(Peerign concepts and others..) >>>>>> >>>>>>Hello, >>>>>> >>>>>>I've been reading "reqs and terminology" and I would like to >>>>>>step >> >>back >> >>>>>>and ask some questions about some of the definitions. >>>>>> >>>>>> >>>>>>Peering: >>>>>>======== >>>>>> >>>>>>In layer 3 peering two routers exchange their routing tables, >> >>reach a >> >>>>>>steady state, and after that data packets can flow between the >>>>>>two domains. >>>>>> >>>>>>Layer 5 peering means, "interconnection of two service >>>>>>providers >> >>for >> >>>>the >>>> >>>>>>purposes of SIP signaling". >>>>>> >>>>>>Making the inevitable comparison with layer 3 peering, there >>>>>>are >> >>some >> >>>>>>fundamental differences that I'm trying to reconcile. >>>>>> >>>>>>1) In a traditional (a.k.a. layer 3) peering, both routers >> >>exchange >> >>>>all >>>> >>>>>>necessary routing information and enter a steady state. At >>>>>>this >> >>point, >> >>>>>>no other routes are exchanged and routers concentrate on >> >>forwarding >> >>>>>>packets. >>>>>> >>>>>>I know the WG is in the beginning, but it is not clear to me >>>>>>what >>>> >>>>pieces >>>> >>>>>>are needed for an equivalent functionality. For example: >>>>>> >>>>>>1) Are the entities exchanging SIP signaling for the purpose >>>>>>of >>>> >>>>peering >>>> >>>>>>doing so on a _per call_ basis? Is there going to be some >> >>mechanism >> >>>>to >>>> >>>>>>exchange such information in bulk such as in a routing protocol? >> >>Maybe >> >>>>>>based on domain names or something similar? >>>>>> >>>>>>2) The draft states that " A >>>>>> domain's ingress point can be thought of as the location >> >>pointed to >> >>>>>> by the SRV record that resulted from the resolution of the >>>>>>CRD >>>> >>>>(i.e., >>>> >>>>>> a SIP URI)." >>>>>> >>>>>>So, it seems to me that although the "layer 5 peering" is >> >>happening >> >>>>>>between the two entities exchanging SIP signaling, the peering >> >>point >> >>>>>>discovery is a result of a SRV query. But the draft also >>>>>>states >> >>that " >> >>>>>>SPEERMINT Working Group is focused on the use of such CRD." >>>>>> >>>>>>Draft peering-policy states that " This documents proposes the >>>>>>use >> >>of >> >>>>>>DNS entries to publish a SIP proxy's policy for accepting >>>>>>incoming calls" proposes DNS as a way of exchange polices. >>>>>> >>>>>>This begs the question of what are the two "peering" entities >> >>really >> >>>>>>doing besides exchange traditional SIP signaling? It seems the >> >>real >> >>>>>>_information peering_ (for the lack of a better term) is >>>>>>happening between DNS servers. All important information >>>>>>related to >> >>"peering" is >> >>>>>>coming from a DNS server which might as well be on your own >>>>>>domain >> >>(if >> >>>>>>your exchange DNS information). >>>>>> >>>>>>In summary, it seems to me the whole architecture is quite a >> >>departure >> >>>>>>from layer 3 peering where the entities peering are the >>>>>>holders of >> >>the >> >>>>>>necessary information to allow data packets to flow. Here the >> >>entities >> >>>>>>peering publish their peering information to third party >>>>>>server >> >>which >> >>>>>>does the actual "peering" (exchange inter-domain information). >>>>>> >>>>>> >>>>>>Anyway, the idea of the mail is to try to clarify things. >>>>>>There is >>>> >>>>much >>>> >>>>>>emphasis on SIP but it seems DNS plays a more central role. Or >> >>maybe >> >>>>>>some SIP extension will be made to exchange peering policies? >>>>>> >>>>>> >>>>>>Policies and Independence of lower layers: >>>>>>========================================== >>>>>> >>>>>>It seems sections 5.5 and 5.6 are _somewhat_ conflicting. >>>>>>Today >> >>BGP >> >>>>>>exchange QoS and VPN information, performs discovery, etc. >>>>>>This >>>> >>>>implies >>>> >>>>>>that BGP indirectly (or directly) knows the capabilities of >>>>>>the transport layer (thus the name capability negotiation). >>>>>> >>>>>>So, although the mechanism to exchange the actual policies >>>>>>needs >> >>to be >> >>>>>>independent of the lower layers, there needs to be a way to >>>>>>input >>>> >>>>lower >>>> >>>>>>layer information into the devices exchanging the policies. >>>>>>Just >> >>like >> >>>>>>BGP has filters and priorities based on a myriad of options. >>>>>>So, >> >>maybe >> >>>>>>the wording should change a little. >>>>>> >>>>>>As far as 5.6 goes, it seems to me the policies can be quite >> >>complex. >> >>>>>>The experience of BGP tells us that in the end policies can be >> >>huge. >> >>>>So, >>>> >>>>>>if policies are going to be huge, what draft dds-00 states as >>>>>>a possibility >>>>>> >>>>>>" If the simple boolean logic and the limited space in the DNS >> >>answers >> >>>>>> are insufficient for an application then a type of policy >>>>>>rule >> >>URIs >> >>>>>> can be defined which links to policy statements written in >>>>>>a >> >>fully >> >>>>>> featured policy description language like SAML [14] or >>>>>>XACML >> >>[15]." >> >>>>>>will actually going to be the rule. So, this begs the question >>>>>>of >> >>DNS >> >>>>is >>>> >>>>>>a good choice to publish peering policies. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Reinaldo >>>>>> >>>>>>_______________________________________________ >>>>>>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 >>>>> >>>>>-- >>>>>No virus found in this incoming message. >>>>>Checked by AVG Free Edition. >>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: >> >>3/24/2006 >> >>>-- >>>No virus found in this incoming message. >>>Checked by AVG Free Edition. >>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: >>>3/24/2006 >>> >> >>_______________________________________________ >>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 > > _______________________________________________ > 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 Wed Mar 29 09:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObEm-0004yg-VP; Wed, 29 Mar 2006 09:01:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObEl-0004yb-JW for speermint@ietf.org; Wed, 29 Mar 2006 09:01:27 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FObEj-0005qY-DS for speermint@ietf.org; Wed, 29 Mar 2006 09:01:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Wed, 29 Mar 2006 16:05:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4E89@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZTOV1DrVCPF5OBQqiLB25gXMjLHAAAG2Zg From: "Stastny Richard" To: "Paul Kyzivat" , "Bob Natale" X-Spam-Score: 0.0 (/) X-Scan-Signature: aaff5d7f1eb2bd23c778cdb1a9c777b3 Cc: speermint@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 Exactly Richard > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 29, 2006 3:58 PM > To: Bob Natale > Cc: Stastny Richard; speermint@ietf.org > Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging >=20 >=20 >=20 > Bob Natale wrote: > > > > Hi Richard, > > > > 1. Your point about the possible relevance for SPEERMINT's scope of > accounting requirements, and not billing requirements, is well-taken = and > will be reflected clearly in the next rev of the Requirements BCP = draft. > > > > 2. Wrt your comment: "3. So why is it necessary to charge = termination > fees to the O-user at all for SIGNALLING?": > > Might it not be true that some applications of value to the user = might > involve signaling only, and not media per se? (I am thinking of = certain > presence and notification apps...?) >=20 > What does that change? >=20 > IMO it makes sense to charge for services actually rendered, and not = for > services the SP isn't involved in but wishes they could get some = revenue > from. >=20 > The terminating proxy does render some identifiable services that = could > potentially be charged for: > - supplying the AOR > - processing (routing) requests to the AOR >=20 > These are of value precisely because they eliminate the need for the = end > user to keep a UA online at all times, and because it permits the end > user to dynamically associate UAs with the AOR, by providing a > potentially recognized and trusted domain. >=20 > This doesn't seem like stuff that justifies per-use charging, and the > amount of charging that can be extracted for these basic services is > probably limited, but its something. >=20 > If an SP wants to charge more, then they will have to provide more > services - ones that users are interested in paying for. >=20 > Paul >=20 > > Cheers, > > BobN > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, March 29, 2006 6:08 AM > > To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; = speermint@ietf.org > > Subject: [Speermint] Billing, Accounting, Tariffing and Charging > > > > > >>>These are not rhetoric questions; I really do not know the answer. > > > > > > Welcome to the club, you are not alone ;-) > > > > > >>>VoIP is exactly the opposite. VoIP (signaling and media) are delay > >> > >>sensitive, need > >> > >>>prioritization and will be billed. > >>> > >> > >>Good point. What we need is to separate the problem of peering into = at > >>least two parts: terminating the call and the traffic itself (data > part). > >>The email model applies only to the termination part. > > > > > > Hmmm, I think it is even more complicated. > > > > Terminology: > > > > Billing is between end-users and a SP (out of scope in spearmint) > Accounting is between SP (in scope of spearmint?) Tariffing is the > calculation of a charge for using a certain resource for a certain = amount > of time. > > > > I consider it also paradox that we are discussing accounting and > charging, particularly termination charges (fees) 1. in a time even in = the > PSTN issues are moving to bill-and-keep 2. on an inappropriate layer = (L5) > > > > A substantial part of the problems with VoIP peering derives not = from > trust, QoS, SPIT, etc. problems, but simply how to keep up the = existing > regime of termination fees. > > > > Especially mobile operators make a living on this. > > > > Where is this problem coming from on the PSTN? > > (Lets for a moment forget problems caused by reverse > > charging) > > > > In the PSTN there was originally an accounting regime based on > cascading. The O-SP bills the O-user for the call (based on distance), = and > keeping part of it and paying out part to the next (transit) SP. > > This goes on until the destination > > (T-SP) is reached, which also gets a share. > > > > The implicit assumptions here are: the originator has the benefit of = the > call and also call set-up is in one direction and call signalling and = the > mediastream is traversing all networks in question. > > > > This principle is only broken with call forwarding and also with = mobile > roaming. In the US also the mobile T-user pays air-time, not so in = Europe, > hence the problems with mobile NP > > > > Note: in my remark to my previous post on terminating network = monopoly > (SMP), one may consider the termination fee also as a compensation for = the > remedy that a terminating network MUST accept any call. > > > > This regime was quite simple, but was more and more complicated over > time by burdening it with additional issues such as subsidies, etc. as = it > is currently in the US. > > > > > > What does this imply now for VoIP peering or interconnect > > > > VoIP; RTC and IP separate signalling (L5) from transport (L3) It = also > separates the SP from the access Now taking into account some facts: > > > > 1. Although SIP signalling (call set-up) is directed from O to T, = the > mediastream is both ways and symmetric (so much for Whitacre, he may > eventually blame Google Video, but not VoIP providers) > > > > 2. The cost for the mediastream is moving more and more to the ends > (access), even in the PSTN (see the latest OFCOM report on distance > gradients), and the access is already paid in some way or the other by = the > end-users. > > > > 3. So why is it necessary to charge termination fees to the O-user = at > all for SIGNALLING? > > > > There is one issue where termination fees may apply (although this = is > going away also - e.g. > > Voipbuster): if you connect to the PSTN. > > > > But this is out of scope in Speermint and in addition solutions = exist > here since years. > > > > My recommendation is that as long as speermint is dealing with L5 > peering only, accounting i.e. termination fees should not be dealt = with. > > > > Cheers > > > > Richard > > > > > > > > > > > >>-----Original Message----- > >>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > >>Sent: Wednesday, March 29, 2006 4:28 AM > >>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > >>Subject: RE: [Speermint] Comments on > >>reqs-and-terminology-01andpolicy-dds- > >>00(Peerign concepts and others..) > >> > >>Hi Reinaldo, > >> > >> > >>>-----Original Message----- > >>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > >>>Sent: Tuesday, March 28, 2006 8:31 PM > >>>To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > >>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > >>>andpolicy- > >> > >>dds-00(Peerign > >> > >>>concepts and others..) > >>> > >>>Hello, > >>> > >>>I tend to agree that the email model sounds attractive except the > >>>delay > >> > >>and business > >> > >>>requirements of email and VoIP are quire different. > >>> > >>>Email is not delay sensitive, does not require any type of > >> > >>prioritization and is not charged > >> > >>>(or at least it wasn't). > >>> > >>>VoIP is exactly the opposite. VoIP (signaling and media) are delay > >> > >>sensitive, need > >> > >>>prioritization and will be billed. > >>> > >> > >>Good point. What we need is to separate the problem of peering into = at > >>least two parts: terminating the call and the traffic itself (data > part). > >>The email model applies only to the termination part. > >> > >> > >>>I believe a call to a public number is (or should) always going to > >>>be > >> > >>routable. I guess my > >> > >>>main question is: is the general belief that VoIP providers will > >>>just > >> > >>configure their proxy > >> > >>>servers to talk to each other in an email type model? No business > >> > >>agreements similar to > >> > >>>PSTN/Wireless, no charging, no extra billing for "roaming", etc? > >>> > >> > >>I agree those are issues. It would be good if we can work out > >>something which is generic (compared to IMS/PSTN specific). Maybe = they > >>are out of scope since we are dealing with protocol and architecture > >>issues in the WG. The only aspect billing and roaming affect is that > >>if all technical requirements (e.g the ones this WG specifies) are > >>satisfied, the peer could still reject traffic (w/o consulting the > >>destination user, in Richard's terms) if the commercial relationship > >>does not exist. I think this is what hampers connectivity today. All > >>these commercial relationships exist because SPs want to be layer 5 > >>aware (they cannot seem to find a way to evolve their business = models > >>otherwise... :), where only the origination SP (Core-O) and Core-T > >>need to have a commercial relationship. The roaming aspect again may > >>be quite artificial and could be questionable going forward... Just = my > personal comments. > >> > >>-Medhavi. > >> > >> > >>>My reply to David's email was more to the idea that you can install > >>>a > >> > >>proxy server > >> > >>>somewhere, point the "MX" to the next upstream "proxy server" and = be > >> > >>done with it? As > >> > >>>VoIP takes off wouldn't some basic regulatory issues, numbering > >>>schemes > >> > >>and others > >> > >>>prevent such behavior? > >>> > >>>These are not rhetoric questions; I really do not know the answer. > >>> > >>>Regards, > >>> > >>>Reinaldo > >>> > >>> > >>>>-----Original Message----- > >>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > >>>>Sent: Tuesday, March 28, 2006 5:13 PM > >>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > >>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > >> > >>andpolicy- > >> > >>>>dds-00(Peerign concepts and others..) > >>>> > >>>> > >>>>>It begs the question why the two entities exchanging SIP > >>>>>signaling > >> > >>do > >> > >>>>not exchange policy > >>>> > >>>>>information themselves through some SIP extension/new > >>>>>protocol/ >>>> > >>>>name> and the > >>>> > >>>>>role played by DNS. I'm not advocating this model but it seems a > >>>> > >>>>pertinent question. > >>>> > >>>>I think peering in L3 must be basic, given how fundamental L3 is > >>>>to > >> > >>the > >> > >>>>internet. For SIP, TRIP provides functionality similar to BGP > >>>>(only > >> > >>for > >> > >>>>phone numbers though, I think). > >>>> > >>>>In my opinion, SIP peering ought to follow the email model. Once > >> > >>location > >> > >>>>is done and basic requirements are satisfied at the SIP layer > >>>>(like identity etc), the call should be routable. As Richard said > >>>>in the > >> > >>earlier > >> > >>>>email, the destination SP may still reject or challenge the call > >>>>if it lacks either the basic requirements we agree to in the WG or > >>>>some > >> > >>extra > >> > >>>>requirements specific to the termination SP (Core-T in my ID). The > >>>>challenge is that in some cases there are going to be IXPs > >> > >>(Interconnects) > >> > >>>>which sit in the middle due to commercial or regulatory reasons. > >>>>The location of an IXP, the provisioning of this IXP and the > >>>>Core-T SP are > >> > >>the > >> > >>>>architectural problems which this WG needs to solve as well. > >>>> > >>>>-Medhavi. > >>>> > >>>> > >>>>>Regards, > >>>>> > >>>>>Reinaldo > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: David Schwartz [mailto:David.Schwartz@Kayote.com] > >>>>>>Sent: Tuesday, March 28, 2006 3:18 PM > >>>>>>To: Reinaldo Penno; speermint@ietf.org > >>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > >>>>>>and > >>>> > >>>>policy- > >>>> > >>>>>>dds-00(Peerign concepts and others..) > >>>>>> > >>>>>>Hi Reinaldo > >>>>>> > >>>>>>I am not sure the goal of SPEERMINT is to recreate L3 peering > >>>>>>at > >> > >>L5. > >> > >>>>The > >>>> > >>>>>>problem being solved is different in that L3 peering is always > >> > >>with a > >> > >>>>>>fixed number of neighbors. These are stored as you mention in > >> > >>static > >> > >>>>>>routing tables at each node and do not change from call to call. > >> > >>In > >> > >>>>>>contrast, L5 peering is not necessarily static (unless you are > >> > >>talking > >> > >>>>>>about a federation model). The destination is chosen only when > >>>>>>the > >>>> > >>>>call is > >>>> > >>>>>>made and may be to a peer that a given service provider/domain > >>>>>>administrator/node has never spoken to before. > >>>>>> > >>>>>>Assuming DNS is used to find the peering node, the query is > >>>>>>made > >> > >>on a > >> > >>>>call > >>>> > >>>>>>by call basis. Now clearly, this DNS info can be cached at the > >>>> > >>>>originating > >>>> > >>>>>>node but the cache still has a very different nature than that > >>>>>>of > >> > >>an > >> > >>>>L3 > >>>> > >>>>>>routing table. > >>>>>> > >>>>>>Policy is an entirely different issue (as is the case in L3) > >>>>>>and > >> > >>it is > >> > >>>>>>important to separate it out from the routing issue. The draft > >>>>>>you > >>>> > >>>>mention > >>>> > >>>>>>about pushing policy via DNS is dealing with one out of many > >> > >>possible > >> > >>>>>>topologies - namely that of ad hoc federations. There was very > >> > >>little > >> > >>>>>>discussion about policy at IETF 65 as the foundations of L5 > >> > >>routing > >> > >>>>need > >>>> > >>>>>>to be cemented before the higher level policy issues can be > >> > >>addressed. > >> > >>>>>>Cheers, > >>>>>> > >>>>>>David > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > >>>>>>Sent: =E2 28 =EE=F8=F5 2006 23:34 > >>>>>>To: speermint@ietf.org > >>>>>>Subject: [Speermint] Comments on reqs-and-terminology-01 and > >> > >>policy- > >> > >>>>dds- > >>>> > >>>>>>00(Peerign concepts and others..) > >>>>>> > >>>>>>Hello, > >>>>>> > >>>>>>I've been reading "reqs and terminology" and I would like to > >>>>>>step > >> > >>back > >> > >>>>>>and ask some questions about some of the definitions. > >>>>>> > >>>>>> > >>>>>>Peering: > >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>> > >>>>>>In layer 3 peering two routers exchange their routing tables, > >> > >>reach a > >> > >>>>>>steady state, and after that data packets can flow between the > >>>>>>two domains. > >>>>>> > >>>>>>Layer 5 peering means, "interconnection of two service > >>>>>>providers > >> > >>for > >> > >>>>the > >>>> > >>>>>>purposes of SIP signaling". > >>>>>> > >>>>>>Making the inevitable comparison with layer 3 peering, there > >>>>>>are > >> > >>some > >> > >>>>>>fundamental differences that I'm trying to reconcile. > >>>>>> > >>>>>>1) In a traditional (a.k.a. layer 3) peering, both routers > >> > >>exchange > >> > >>>>all > >>>> > >>>>>>necessary routing information and enter a steady state. At > >>>>>>this > >> > >>point, > >> > >>>>>>no other routes are exchanged and routers concentrate on > >> > >>forwarding > >> > >>>>>>packets. > >>>>>> > >>>>>>I know the WG is in the beginning, but it is not clear to me > >>>>>>what > >>>> > >>>>pieces > >>>> > >>>>>>are needed for an equivalent functionality. For example: > >>>>>> > >>>>>>1) Are the entities exchanging SIP signaling for the purpose > >>>>>>of > >>>> > >>>>peering > >>>> > >>>>>>doing so on a _per call_ basis? Is there going to be some > >> > >>mechanism > >> > >>>>to > >>>> > >>>>>>exchange such information in bulk such as in a routing protocol? > >> > >>Maybe > >> > >>>>>>based on domain names or something similar? > >>>>>> > >>>>>>2) The draft states that " A > >>>>>> domain's ingress point can be thought of as the location > >> > >>pointed to > >> > >>>>>> by the SRV record that resulted from the resolution of the > >>>>>>CRD > >>>> > >>>>(i.e., > >>>> > >>>>>> a SIP URI)." > >>>>>> > >>>>>>So, it seems to me that although the "layer 5 peering" is > >> > >>happening > >> > >>>>>>between the two entities exchanging SIP signaling, the peering > >> > >>point > >> > >>>>>>discovery is a result of a SRV query. But the draft also > >>>>>>states > >> > >>that " > >> > >>>>>>SPEERMINT Working Group is focused on the use of such CRD." > >>>>>> > >>>>>>Draft peering-policy states that " This documents proposes the > >>>>>>use > >> > >>of > >> > >>>>>>DNS entries to publish a SIP proxy's policy for accepting > >>>>>>incoming calls" proposes DNS as a way of exchange polices. > >>>>>> > >>>>>>This begs the question of what are the two "peering" entities > >> > >>really > >> > >>>>>>doing besides exchange traditional SIP signaling? It seems the > >> > >>real > >> > >>>>>>_information peering_ (for the lack of a better term) is > >>>>>>happening between DNS servers. All important information > >>>>>>related to > >> > >>"peering" is > >> > >>>>>>coming from a DNS server which might as well be on your own > >>>>>>domain > >> > >>(if > >> > >>>>>>your exchange DNS information). > >>>>>> > >>>>>>In summary, it seems to me the whole architecture is quite a > >> > >>departure > >> > >>>>>>from layer 3 peering where the entities peering are the > >>>>>>holders of > >> > >>the > >> > >>>>>>necessary information to allow data packets to flow. Here the > >> > >>entities > >> > >>>>>>peering publish their peering information to third party > >>>>>>server > >> > >>which > >> > >>>>>>does the actual "peering" (exchange inter-domain information). > >>>>>> > >>>>>> > >>>>>>Anyway, the idea of the mail is to try to clarify things. > >>>>>>There is > >>>> > >>>>much > >>>> > >>>>>>emphasis on SIP but it seems DNS plays a more central role. Or > >> > >>maybe > >> > >>>>>>some SIP extension will be made to exchange peering policies? > >>>>>> > >>>>>> > >>>>>>Policies and Independence of lower layers: > = >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>> > >>>>>>It seems sections 5.5 and 5.6 are _somewhat_ conflicting. > >>>>>>Today > >> > >>BGP > >> > >>>>>>exchange QoS and VPN information, performs discovery, etc. > >>>>>>This > >>>> > >>>>implies > >>>> > >>>>>>that BGP indirectly (or directly) knows the capabilities of > >>>>>>the transport layer (thus the name capability negotiation). > >>>>>> > >>>>>>So, although the mechanism to exchange the actual policies > >>>>>>needs > >> > >>to be > >> > >>>>>>independent of the lower layers, there needs to be a way to > >>>>>>input > >>>> > >>>>lower > >>>> > >>>>>>layer information into the devices exchanging the policies. > >>>>>>Just > >> > >>like > >> > >>>>>>BGP has filters and priorities based on a myriad of options. > >>>>>>So, > >> > >>maybe > >> > >>>>>>the wording should change a little. > >>>>>> > >>>>>>As far as 5.6 goes, it seems to me the policies can be quite > >> > >>complex. > >> > >>>>>>The experience of BGP tells us that in the end policies can be > >> > >>huge. > >> > >>>>So, > >>>> > >>>>>>if policies are going to be huge, what draft dds-00 states as > >>>>>>a possibility > >>>>>> > >>>>>>" If the simple boolean logic and the limited space in the DNS > >> > >>answers > >> > >>>>>> are insufficient for an application then a type of policy > >>>>>>rule > >> > >>URIs > >> > >>>>>> can be defined which links to policy statements written in > >>>>>>a > >> > >>fully > >> > >>>>>> featured policy description language like SAML [14] or > >>>>>>XACML > >> > >>[15]." > >> > >>>>>>will actually going to be the rule. So, this begs the question > >>>>>>of > >> > >>DNS > >> > >>>>is > >>>> > >>>>>>a good choice to publish peering policies. > >>>>>> > >>>>>>Thanks, > >>>>>> > >>>>>>Reinaldo > >>>>>> > >>>>>>_______________________________________________ > >>>>>>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 > >>>>> > >>>>>-- > >>>>>No virus found in this incoming message. > >>>>>Checked by AVG Free Edition. > >>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > >> > >>3/24/2006 > >> > >>>-- > >>>No virus found in this incoming message. > >>>Checked by AVG Free Edition. > >>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > >>>3/24/2006 > >>> > >> > >>_______________________________________________ > >>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 > > > > _______________________________________________ > > 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 Wed Mar 29 09:18:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObVZ-0004qV-C2; Wed, 29 Mar 2006 09:18:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObVY-0004qD-LU for speermint@ietf.org; Wed, 29 Mar 2006 09:18:48 -0500 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FObVX-0006XG-Qf for speermint@ietf.org; Wed, 29 Mar 2006 09:18:48 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 09:18:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Wed, 29 Mar 2006 09:18:45 -0500 Message-ID: <8812D8156467224C9E9739E513037EF149D4AE@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging thread-index: AcZTOSVrh3wcnDMuRQ2wxSPTIqNljQAAPi5g From: "Bob Natale" To: "Paul Kyzivat" X-OriginalArrivalTime: 29 Mar 2006 14:18:47.0328 (UTC) FILETIME=[B187CA00:01C6533B] X-Spam-Score: 0.0 (/) X-Scan-Signature: afddcc4f0dbd876d4009dc71857c6cc6 Cc: speermint@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 Paul, I'm not interested in charging (in the billing sense) wrt SPEERMINT, and = I don't presume to prejudge what SPs will attempt to charge (bill) for = in the future. (I expect to be negatively surprised. :) However, my point was that: - Pure signaling apps are likely to become more prevalent and more = valuable; Therefore, - SPEERMINT may need to cover the *accounting* requirements for such = traffic at all relevant points in the SPEERMINT peering architecture = (which is yet to be defined by this WG). Cheers, BobN -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, March 29, 2006 8:58 AM To: Bob Natale Cc: Stastny Richard; speermint@ietf.org Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging Bob Natale wrote: > =20 > Hi Richard, >=20 > 1. Your point about the possible relevance for SPEERMINT's scope of = accounting requirements, and not billing requirements, is well-taken and = will be reflected clearly in the next rev of the Requirements BCP draft. >=20 > 2. Wrt your comment: "3. So why is it necessary to charge termination = fees to the O-user at all for SIGNALLING?": > Might it not be true that some applications of value to the user might = > involve signaling only, and not media per se? (I am thinking of=20 > certain presence and notification apps...?) What does that change? IMO it makes sense to charge for services actually rendered, and not for = services the SP isn't involved in but wishes they could get some revenue = from. The terminating proxy does render some identifiable services that could = potentially be charged for: - supplying the AOR - processing (routing) requests to the AOR These are of value precisely because they eliminate the need for the end = user to keep a UA online at all times, and because it permits the end = user to dynamically associate UAs with the AOR, by providing a = potentially recognized and trusted domain. This doesn't seem like stuff that justifies per-use charging, and the = amount of charging that can be extracted for these basic services is = probably limited, but its something. If an SP wants to charge more, then they will have to provide more = services - ones that users are interested in paying for. Paul > Cheers, > BobN >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 29, 2006 6:08 AM > To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; speermint@ietf.org > Subject: [Speermint] Billing, Accounting, Tariffing and Charging >=20 >=20 >>>These are not rhetoric questions; I really do not know the answer. >=20 >=20 > Welcome to the club, you are not alone ;-) >=20 >=20 >>>VoIP is exactly the opposite. VoIP (signaling and media) are delay >> >>sensitive, need >> >>>prioritization and will be billed. >>> >> >>Good point. What we need is to separate the problem of peering into at = >>least two parts: terminating the call and the traffic itself (data = part). >>The email model applies only to the termination part. >=20 >=20 > Hmmm, I think it is even more complicated. >=20 > Terminology: >=20 > Billing is between end-users and a SP (out of scope in spearmint) = Accounting is between SP (in scope of spearmint?) Tariffing is the = calculation of a charge for using a certain resource for a certain = amount of time. >=20 > I consider it also paradox that we are discussing accounting and=20 > charging, particularly termination charges (fees) 1. in a time even in = > the PSTN issues are moving to bill-and-keep 2. on an inappropriate=20 > layer (L5) >=20 > A substantial part of the problems with VoIP peering derives not from = trust, QoS, SPIT, etc. problems, but simply how to keep up the existing = regime of termination fees. >=20 > Especially mobile operators make a living on this. >=20 > Where is this problem coming from on the PSTN? > (Lets for a moment forget problems caused by reverse > charging) >=20 > In the PSTN there was originally an accounting regime based on = cascading. The O-SP bills the O-user for the call (based on distance), = and keeping part of it and paying out part to the next (transit) SP.=20 > This goes on until the destination > (T-SP) is reached, which also gets a share. >=20 > The implicit assumptions here are: the originator has the benefit of = the call and also call set-up is in one direction and call signalling = and the mediastream is traversing all networks in question. >=20 > This principle is only broken with call forwarding and also with=20 > mobile roaming. In the US also the mobile T-user pays air-time, not so = > in Europe, hence the problems with mobile NP >=20 > Note: in my remark to my previous post on terminating network monopoly = (SMP), one may consider the termination fee also as a compensation for = the remedy that a terminating network MUST accept any call. >=20 > This regime was quite simple, but was more and more complicated over = time by burdening it with additional issues such as subsidies, etc. as = it is currently in the US. >=20 >=20 > What does this imply now for VoIP peering or interconnect >=20 > VoIP; RTC and IP separate signalling (L5) from transport (L3) It also = separates the SP from the access Now taking into account some facts: >=20 > 1. Although SIP signalling (call set-up) is directed from O to T, the=20 > mediastream is both ways and symmetric (so much for Whitacre, he may=20 > eventually blame Google Video, but not VoIP providers) >=20 > 2. The cost for the mediastream is moving more and more to the ends = (access), even in the PSTN (see the latest OFCOM report on distance = gradients), and the access is already paid in some way or the other by = the end-users. >=20 > 3. So why is it necessary to charge termination fees to the O-user at = all for SIGNALLING? >=20 > There is one issue where termination fees may apply (although this is = going away also - e.g. > Voipbuster): if you connect to the PSTN. >=20 > But this is out of scope in Speermint and in addition solutions exist = here since years. >=20 > My recommendation is that as long as speermint is dealing with L5 = peering only, accounting i.e. termination fees should not be dealt with. >=20 > Cheers >=20 > Richard >=20 >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] >>Sent: Wednesday, March 29, 2006 4:28 AM >>To: Reinaldo Penno; David Schwartz; speermint@ietf.org >>Subject: RE: [Speermint] Comments on >>reqs-and-terminology-01andpolicy-dds- >>00(Peerign concepts and others..) >> >>Hi Reinaldo, >> >> >>>-----Original Message----- >>>From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>Sent: Tuesday, March 28, 2006 8:31 PM >>>To: Medhavi Bhatia; David Schwartz; speermint@ietf.org >>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 >>>andpolicy- >> >>dds-00(Peerign >> >>>concepts and others..) >>> >>>Hello, >>> >>>I tend to agree that the email model sounds attractive except the=20 >>>delay >> >>and business >> >>>requirements of email and VoIP are quire different. >>> >>>Email is not delay sensitive, does not require any type of >> >>prioritization and is not charged >> >>>(or at least it wasn't). >>> >>>VoIP is exactly the opposite. VoIP (signaling and media) are delay >> >>sensitive, need >> >>>prioritization and will be billed. >>> >> >>Good point. What we need is to separate the problem of peering into at = >>least two parts: terminating the call and the traffic itself (data = part). >>The email model applies only to the termination part. >> >> >>>I believe a call to a public number is (or should) always going to be >> >>routable. I guess my >> >>>main question is: is the general belief that VoIP providers will just >> >>configure their proxy >> >>>servers to talk to each other in an email type model? No business >> >>agreements similar to >> >>>PSTN/Wireless, no charging, no extra billing for "roaming", etc? >>> >> >>I agree those are issues. It would be good if we can work out=20 >>something which is generic (compared to IMS/PSTN specific). Maybe they = >>are out of scope since we are dealing with protocol and architecture=20 >>issues in the WG. The only aspect billing and roaming affect is that=20 >>if all technical requirements (e.g the ones this WG specifies) are=20 >>satisfied, the peer could still reject traffic (w/o consulting the=20 >>destination user, in Richard's terms) if the commercial relationship=20 >>does not exist. I think this is what hampers connectivity today. All=20 >>these commercial relationships exist because SPs want to be layer 5=20 >>aware (they cannot seem to find a way to evolve their business models=20 >>otherwise... :), where only the origination SP (Core-O) and Core-T=20 >>need to have a commercial relationship. The roaming aspect again may=20 >>be quite artificial and could be questionable going forward... Just = my personal comments. >> >>-Medhavi. >> >> >>>My reply to David's email was more to the idea that you can install a >> >>proxy server >> >>>somewhere, point the "MX" to the next upstream "proxy server" and be >> >>done with it? As >> >>>VoIP takes off wouldn't some basic regulatory issues, numbering=20 >>>schemes >> >>and others >> >>>prevent such behavior? >>> >>>These are not rhetoric questions; I really do not know the answer. >>> >>>Regards, >>> >>>Reinaldo >>> >>> >>>>-----Original Message----- >>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] >>>>Sent: Tuesday, March 28, 2006 5:13 PM >>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org >>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 >> >>andpolicy- >> >>>>dds-00(Peerign concepts and others..) >>>> >>>> >>>>>It begs the question why the two entities exchanging SIP signaling >> >>do >> >>>>not exchange policy >>>> >>>>>information themselves through some SIP extension/new=20 >>>>>protocol/>>> >>>>name> and the >>>> >>>>>role played by DNS. I'm not advocating this model but it seems a >>>> >>>>pertinent question. >>>> >>>>I think peering in L3 must be basic, given how fundamental L3 is to >> >>the >> >>>>internet. For SIP, TRIP provides functionality similar to BGP (only >> >>for >> >>>>phone numbers though, I think). >>>> >>>>In my opinion, SIP peering ought to follow the email model. Once >> >>location >> >>>>is done and basic requirements are satisfied at the SIP layer (like=20 >>>>identity etc), the call should be routable. As Richard said in the >> >>earlier >> >>>>email, the destination SP may still reject or challenge the call if=20 >>>>it lacks either the basic requirements we agree to in the WG or some >> >>extra >> >>>>requirements specific to the termination SP (Core-T in my ID). The=20 >>>>challenge is that in some cases there are going to be IXPs >> >>(Interconnects) >> >>>>which sit in the middle due to commercial or regulatory reasons.=20 >>>>The location of an IXP, the provisioning of this IXP and the Core-T=20 >>>>SP are >> >>the >> >>>>architectural problems which this WG needs to solve as well. >>>> >>>>-Medhavi. >>>> >>>> >>>>>Regards, >>>>> >>>>>Reinaldo >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: David Schwartz [mailto:David.Schwartz@Kayote.com] >>>>>>Sent: Tuesday, March 28, 2006 3:18 PM >>>>>>To: Reinaldo Penno; speermint@ietf.org >>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and >>>> >>>>policy- >>>> >>>>>>dds-00(Peerign concepts and others..) >>>>>> >>>>>>Hi Reinaldo >>>>>> >>>>>>I am not sure the goal of SPEERMINT is to recreate L3 peering at >> >>L5. >> >>>>The >>>> >>>>>>problem being solved is different in that L3 peering is always >> >>with a >> >>>>>>fixed number of neighbors. These are stored as you mention in >> >>static >> >>>>>>routing tables at each node and do not change from call to call. >> >>In >> >>>>>>contrast, L5 peering is not necessarily static (unless you are >> >>talking >> >>>>>>about a federation model). The destination is chosen only when the >>>> >>>>call is >>>> >>>>>>made and may be to a peer that a given service provider/domain=20 >>>>>>administrator/node has never spoken to before. >>>>>> >>>>>>Assuming DNS is used to find the peering node, the query is made >> >>on a >> >>>>call >>>> >>>>>>by call basis. Now clearly, this DNS info can be cached at the >>>> >>>>originating >>>> >>>>>>node but the cache still has a very different nature than that=20 >>>>>>of >> >>an >> >>>>L3 >>>> >>>>>>routing table. >>>>>> >>>>>>Policy is an entirely different issue (as is the case in L3)=20 >>>>>>and >> >>it is >> >>>>>>important to separate it out from the routing issue. The draft=20 >>>>>>you >>>> >>>>mention >>>> >>>>>>about pushing policy via DNS is dealing with one out of many >> >>possible >> >>>>>>topologies - namely that of ad hoc federations. There was very >> >>little >> >>>>>>discussion about policy at IETF 65 as the foundations of L5 >> >>routing >> >>>>need >>>> >>>>>>to be cemented before the higher level policy issues can be >> >>addressed. >> >>>>>>Cheers, >>>>>> >>>>>>David >>>>>> >>>>>>-----Original Message----- >>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>>>Sent: =E2 28 =EE=F8=F5 2006 23:34 >>>>>>To: speermint@ietf.org >>>>>>Subject: [Speermint] Comments on reqs-and-terminology-01 and >> >>policy- >> >>>>dds- >>>> >>>>>>00(Peerign concepts and others..) >>>>>> >>>>>>Hello, >>>>>> >>>>>>I've been reading "reqs and terminology" and I would like to=20 >>>>>>step >> >>back >> >>>>>>and ask some questions about some of the definitions. >>>>>> >>>>>> >>>>>>Peering: >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>>>In layer 3 peering two routers exchange their routing tables, >> >>reach a >> >>>>>>steady state, and after that data packets can flow between the=20 >>>>>>two domains. >>>>>> >>>>>>Layer 5 peering means, "interconnection of two service=20 >>>>>>providers >> >>for >> >>>>the >>>> >>>>>>purposes of SIP signaling". >>>>>> >>>>>>Making the inevitable comparison with layer 3 peering, there=20 >>>>>>are >> >>some >> >>>>>>fundamental differences that I'm trying to reconcile. >>>>>> >>>>>>1) In a traditional (a.k.a. layer 3) peering, both routers >> >>exchange >> >>>>all >>>> >>>>>>necessary routing information and enter a steady state. At=20 >>>>>>this >> >>point, >> >>>>>>no other routes are exchanged and routers concentrate on >> >>forwarding >> >>>>>>packets. >>>>>> >>>>>>I know the WG is in the beginning, but it is not clear to me=20 >>>>>>what >>>> >>>>pieces >>>> >>>>>>are needed for an equivalent functionality. For example: >>>>>> >>>>>>1) Are the entities exchanging SIP signaling for the purpose=20 >>>>>>of >>>> >>>>peering >>>> >>>>>>doing so on a _per call_ basis? Is there going to be some >> >>mechanism >> >>>>to >>>> >>>>>>exchange such information in bulk such as in a routing protocol? >> >>Maybe >> >>>>>>based on domain names or something similar? >>>>>> >>>>>>2) The draft states that " A >>>>>> domain's ingress point can be thought of as the location >> >>pointed to >> >>>>>> by the SRV record that resulted from the resolution of the=20 >>>>>>CRD >>>> >>>>(i.e., >>>> >>>>>> a SIP URI)." >>>>>> >>>>>>So, it seems to me that although the "layer 5 peering" is >> >>happening >> >>>>>>between the two entities exchanging SIP signaling, the peering >> >>point >> >>>>>>discovery is a result of a SRV query. But the draft also=20 >>>>>>states >> >>that " >> >>>>>>SPEERMINT Working Group is focused on the use of such CRD." >>>>>> >>>>>>Draft peering-policy states that " This documents proposes the=20 >>>>>>use >> >>of >> >>>>>>DNS entries to publish a SIP proxy's policy for accepting=20 >>>>>>incoming calls" proposes DNS as a way of exchange polices. >>>>>> >>>>>>This begs the question of what are the two "peering" entities >> >>really >> >>>>>>doing besides exchange traditional SIP signaling? It seems the >> >>real >> >>>>>>_information peering_ (for the lack of a better term) is=20 >>>>>>happening between DNS servers. All important information=20 >>>>>>related to >> >>"peering" is >> >>>>>>coming from a DNS server which might as well be on your own=20 >>>>>>domain >> >>(if >> >>>>>>your exchange DNS information). >>>>>> >>>>>>In summary, it seems to me the whole architecture is quite a >> >>departure >> >>>>>>from layer 3 peering where the entities peering are the=20 >>>>>>holders of >> >>the >> >>>>>>necessary information to allow data packets to flow. Here the >> >>entities >> >>>>>>peering publish their peering information to third party=20 >>>>>>server >> >>which >> >>>>>>does the actual "peering" (exchange inter-domain information). >>>>>> >>>>>> >>>>>>Anyway, the idea of the mail is to try to clarify things.=20 >>>>>>There is >>>> >>>>much >>>> >>>>>>emphasis on SIP but it seems DNS plays a more central role. Or >> >>maybe >> >>>>>>some SIP extension will be made to exchange peering policies? >>>>>> >>>>>> >>>>>>Policies and Independence of lower layers: >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>>>It seems sections 5.5 and 5.6 are _somewhat_ conflicting.=20 >>>>>>Today >> >>BGP >> >>>>>>exchange QoS and VPN information, performs discovery, etc.=20 >>>>>>This >>>> >>>>implies >>>> >>>>>>that BGP indirectly (or directly) knows the capabilities of=20 >>>>>>the transport layer (thus the name capability negotiation). >>>>>> >>>>>>So, although the mechanism to exchange the actual policies=20 >>>>>>needs >> >>to be >> >>>>>>independent of the lower layers, there needs to be a way to=20 >>>>>>input >>>> >>>>lower >>>> >>>>>>layer information into the devices exchanging the policies.=20 >>>>>>Just >> >>like >> >>>>>>BGP has filters and priorities based on a myriad of options.=20 >>>>>>So, >> >>maybe >> >>>>>>the wording should change a little. >>>>>> >>>>>>As far as 5.6 goes, it seems to me the policies can be quite >> >>complex. >> >>>>>>The experience of BGP tells us that in the end policies can be >> >>huge. >> >>>>So, >>>> >>>>>>if policies are going to be huge, what draft dds-00 states as=20 >>>>>>a possibility >>>>>> >>>>>>" If the simple boolean logic and the limited space in the DNS >> >>answers >> >>>>>> are insufficient for an application then a type of policy=20 >>>>>>rule >> >>URIs >> >>>>>> can be defined which links to policy statements written in=20 >>>>>>a >> >>fully >> >>>>>> featured policy description language like SAML [14] or=20 >>>>>>XACML >> >>[15]." >> >>>>>>will actually going to be the rule. So, this begs the question=20 >>>>>>of >> >>DNS >> >>>>is >>>> >>>>>>a good choice to publish peering policies. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Reinaldo >>>>>> >>>>>>_______________________________________________ >>>>>>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 >>>>> >>>>>-- >>>>>No virus found in this incoming message. >>>>>Checked by AVG Free Edition. >>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: >> >>3/24/2006 >> >>>-- >>>No virus found in this incoming message. >>>Checked by AVG Free Edition. >>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date:=20 >>>3/24/2006 >>> >> >>_______________________________________________ >>Speermint mailing list >>Speermint@ietf.org >>https://www1.ietf.org/mailman/listinfo/speermint >=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 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 29 11:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdAM-0007KK-LT; Wed, 29 Mar 2006 11:05:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdAL-0007JD-PQ for speermint@ietf.org; Wed, 29 Mar 2006 11:05:01 -0500 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdAL-0003lq-He for speermint@ietf.org; Wed, 29 Mar 2006 11:05:01 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 11:05:01 -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] Billing, Accounting, Tariffing and Charging Date: Wed, 29 Mar 2006 11:05:00 -0500 Message-ID: <8812D8156467224C9E9739E513037EF149D5CE@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging thread-index: AcZTONyKoHtZWqcmQdWrpQqwCPpRSAADak4wAACu6gA= From: "Bob Natale" To: X-OriginalArrivalTime: 29 Mar 2006 16:05:01.0177 (UTC) FILETIME=[88A3F690:01C6534A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: speermint@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 Tim, =20 > I don't think the WG needs to delve deeply into where, when, why or how much operators charge each other. Agreed (enthusiastically :). > But we do need to make some sort of assumption, if for example we're to facilitate their interconnection > through definition of supporting structures (e.g., protocols, MIBs). Agree with your intent, I believe. SPEERMINT is chartered (wrt Requirements at least) to come with a BCP. So we will have to deal with "policies and operations" relating to accounting (and other applicable topics). If by "definition of...e.g., protocols, MIBs" you mean "identification" of them, yes, that's a possibility. > so some form of usage accounting is needed at the points where they interconnect. For sure. Cheers, BobN -----Original Message----- From: Tim Dwight [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, March 29, 2006 10:49 AM To: Bob Natale Cc: speermint@ietf.org Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Bob, Bob Natale wrote: > =20 > Hi Richard, >=20 > 1. Your point about the possible relevance for SPEERMINT's scope of accounting requirements, and not billing requirements, is well-taken and will be reflected clearly in the next rev of the Requirements BCP draft. >=20 > 2. Wrt your comment: "3. So why is it necessary to charge termination fees to the O-user at all for SIGNALLING?": > Might it not be true that some applications of value to the user might > involve signaling only, and not media per se? (I am thinking of=20 > certain presence and notification apps...?) It's not impossible that the signaling channel provide services independent of (or possibly in addition to) establishment of media streams. Anybody remember fast-select in X.25? If signaling were free you can bet people would invent ways to use it. Or, would you rather the network filter the SDP to prevent piggybacking of user data? :-) I don't think the WG needs to delve deeply into where, when, why or how much operators charge each other. But we do need to make some sort of assumption, if for example we're to facilitate their interconnection through definition of supporting structures (e.g., protocols, MIBs). I thought that was Richard's point. Richard Stastny wrote: >=20 > In the PSTN there was originally an accounting regime based on cascading. The O-SP bills the O-user for the call (based on distance), and keeping part of it and paying out part to the next (transit) SP.=20 Maybe somewhere it worked like that. In the US the transit provider (inter-exchange provider) bills the O-user directly. Which makes it necessary to collect usage data on a call by call basis, in the long distance network. =20 The Internet of course adopts a more scalable model in which interconnected ISPs charge each other based on traffic volume (rather than trying to account for individual flows). But the point is they do charge each other, or at least they sometimes do, so some form of usage accounting is needed at the points where they interconnect. Cheers, tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 29 11:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdrr-0001MT-5y; Wed, 29 Mar 2006 11:49:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdrq-0001MF-3H for speermint@ietf.org; Wed, 29 Mar 2006 11:49:58 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOdrm-0005t2-Cn for speermint@ietf.org; Wed, 29 Mar 2006 11:49:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging Date: Wed, 29 Mar 2006 18:53:54 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4940@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009AAAcZysAAQUy8AAAnRr4AAA7MKow== From: "Stastny Richard" To: , "Medhavi Bhatia" , "Reinaldo Penno" , "David Schwartz" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 28adfdfeb3b69a8c1fb469b1c327fd44 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 Hi Tim, >I'll join the confused majority. =20 =20 Welcome ;-) =20 >In my (probably simplistic) view, based on >experience with other technologies, "L5 peering" ought to involve 3 = types of >activities happening over 3 distinct timescales: > >1) some sort of business agreement between entities responsible for a = set of >L5 domains. Historically such agreements have usually been bilateral, >though other models are possible. In general the agreement establishes = the >terms and conditions under which traffic will be exchanged. =20 IMHO you are making an assumption here or drawing a conclusion that "L5 = peering" is fully analogue to L3 peering or interconnection on the PSTN: the hint is in the term "traffic will be exchanged". In both of the = above mentioned cases really "traffic" is exchanged.=20 In our case on L5 only SIP messages are exchanged. If really (media) = traffic is exchanged how much and via which path depends on various other issues such as: do the end users really set up a media session, how are they connected = to the Internet, or are they connected at all. =20 Example: I am in a hotel in New York and register to a provider in = Germany (I have no idea where the servers are located, could be in Poland), I = set up a session to a friend registered to a SP in Australia, = sip:vince@prov.au having his (one of) his servers located in Japan, to find out that my friend is located in the same = hotel in New York, We both pay 10 bucks to the hotel for a day of unlimted Internet access. =20 How his thid "traffic exchanged" and who needs bilateral peering = agreements and who gets paid what? >I struggle to imagine this process happening dynamically, e.g., via = some >sort of automated lookup of and agreement to, another operator's terms = and >conditions.=20 =20 >I do think there is work the WG can do in support of these >agreements, though. For example definition of standard MIBs that can = be >used for accounting purposes. I think as we understand better what >information needs to be exchanged in this "pre-realtime" phase, other >opportunities may emerge. =20 In the above case; who is an operator requiring predefined bilateral peering agreements that I may call my friend in the hotel and get some additional money to the 20 bucks we already paid? Or may I call my friend only if per chance both of us hit the checkpot that our "providers" have a bilateral agreement or are in the same = federation? >2) Step (1), iterated as necessary, establishes a sort of static >interconnect matrix. To make traffic flow across that matrix we may = need >some dynamic exchange of "L5 routing" information. =20 =20 I do not need an dynamic exchange of "L5 routing information" the L5 routing information is given by sip:vince@prov.au there is no matrix, there is only ONE destination provider prov.au, no choice. =20 >As has been previously >noted, this is the role of BGP at L3. BGP is necessarily dynamic = because >the information it communicates (reachability) is constantly in flux. = There >is no analogue to BGP in the PSTN - the criteria governing path = selection at >that level of abstraction (the sequence of networks to be traversed) = are >assumed to be relatively static. [I am omitting discussion of tariff >arbitrage, which is an unfortunate but real result of convoluted = "policy" >that has created a hopefully-shortlived cottage industry] >How will the path to be taken by a given SIP packet, be selected? =20 =20 Are you talking here SIP or RTP packets? =20 A SIP invite is sent from my UA to my proxy, the proxy is looking up prov.au for SRV records, eventually selecting the server in Japan; resolving the IP address and sending the SIP packet there, etc =20 >How decoupled from the path taken by the media stream, can this = practically be? The media stream may not even leave the hotel >For example the signaling might "hop through" some sort of peering = point >that offers no media relay services - that seems reasonable - but to = have >the signaling and media traverse completely disjoint sets of L3 = networks >whilst magically receiving end-to-end QoS treatment, does not. =20 Aha, so to improve QoS within the hotel, we are using managed networks from New York to Poland to Japan, back to New York. this helps? If the LAN is the hotel is congested, you are doomed in either case =20 >What then is >the nature of the association of signaling-path and bearer-path, and = how is >it assured (assuming that the signaling path is determined at L5 and = the >bearer path at L3)? =20 =20 This is rebuilding the PSTN. Is this the scope of speermint? =20 >What if any L5 dynamic information needs to be >exchanged to facilitate this? =20 Please leave this to 3GPP and ETSI TISPAN. Do not spoil their phun and S4 Syndrome >By what means (protocol?) is it exchanged? Again look at TISPAN RACS and NACS >These seem like in-scope questions applicable to the >realtime-but-not-call-by-call timeframe, to me. >3) The last timescale of interest is call-by-call. What (if anything) = needs >to happen in this time scale to facilitate (or as a result of) L5 = peering? QoS can only be done at call time - this is called Trunk Busy by = bell-heads =20 cheers =20 Richard >I *hope* the answer is "nothing", but am willing to be convinced = otherwise. Cheers, Tim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, March 29, 2006 5:08 AM To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; speermint@ietf.org Subject: [Speermint] Billing, Accounting, Tariffing and Charging > > These are not rhetoric questions; I really do not know the answer. Welcome to the club, you are not alone ;-) > > VoIP is exactly the opposite. VoIP (signaling and media) are delay > sensitive, need > > prioritization and will be billed. > > > > Good point. What we need is to separate the problem of peering into at > least two parts: terminating the call and the traffic itself (data = part). > The email model applies only to the termination part. Hmmm, I think it is even more complicated. Terminology: Billing is between end-users and a SP (out of scope in spearmint) = Accounting is between SP (in scope of spearmint?) Tariffing is the calculation of a charge for using a certain resource for a certain amount of time. I consider it also paradox that we are discussing accounting and = charging, particularly termination charges (fees) 1. in a time even in the PSTN = issues are moving to bill-and-keep 2. on an inappropriate layer (L5) A substantial part of the problems with VoIP peering derives not from = trust, QoS, SPIT, etc. problems, but simply how to keep up the existing regime = of termination fees. Especially mobile operators make a living on this. Where is this problem coming from on the PSTN? (Lets for a moment forget problems caused by reverse charging) In the PSTN there was originally an accounting regime based on = cascading. The O-SP bills the O-user for the call (based on distance), and keeping = part of it and paying out part to the next (transit) SP. This goes on until the destination (T-SP) is reached, which also gets a share. The implicit assumptions here are: the originator has the benefit of the call and also call set-up is in one direction and call signalling and = the mediastream is traversing all networks in question. This principle is only broken with call forwarding and also with mobile roaming. In the US also the mobile T-user pays air-time, not so in = Europe, hence the problems with mobile NP Note: in my remark to my previous post on terminating network monopoly (SMP), one may consider the termination fee also as a compensation for = the remedy that a terminating network MUST accept any call. This regime was quite simple, but was more and more complicated over = time by burdening it with additional issues such as subsidies, etc. as it is currently in the US. What does this imply now for VoIP peering or interconnect VoIP; RTC and IP separate signalling (L5) from transport (L3) It also separates the SP from the access Now taking into account some facts: 1. Although SIP signalling (call set-up) is directed from O to T, the mediastream is both ways and symmetric (so much for Whitacre, he may eventually blame Google Video, but not VoIP providers) 2. The cost for the mediastream is moving more and more to the ends (access), even in the PSTN (see the latest OFCOM report on distance gradients), and the access is already paid in some way or the other by = the end-users. 3. So why is it necessary to charge termination fees to the O-user at = all for SIGNALLING? There is one issue where termination fees may apply (although this is = going away also - e.g. Voipbuster): if you connect to the PSTN. But this is out of scope in Speermint and in addition solutions exist = here since years. My recommendation is that as long as speermint is dealing with L5 = peering only, accounting i.e. termination fees should not be dealt with. Cheers Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Wednesday, March 29, 2006 4:28 AM > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Comments on > reqs-and-terminology-01andpolicy-dds- > 00(Peerign concepts and others..) > > Hi Reinaldo, > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, March 28, 2006 8:31 PM > > To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > andpolicy- > dds-00(Peerign > > concepts and others..) > > > > Hello, > > > > I tend to agree that the email model sounds attractive except the > > delay > and business > > requirements of email and VoIP are quire different. > > > > Email is not delay sensitive, does not require any type of > prioritization and is not charged > > (or at least it wasn't). > > > > VoIP is exactly the opposite. VoIP (signaling and media) are delay > sensitive, need > > prioritization and will be billed. > > > > Good point. What we need is to separate the problem of peering into at > least two parts: terminating the call and the traffic itself (data = part). > The email model applies only to the termination part. > > > I believe a call to a public number is (or should) always going to > > be > routable. I guess my > > main question is: is the general belief that VoIP providers will > > just > configure their proxy > > servers to talk to each other in an email type model? No business > agreements similar to > > PSTN/Wireless, no charging, no extra billing for "roaming", etc? > > > > I agree those are issues. It would be good if we can work out > something which is generic (compared to IMS/PSTN specific). Maybe they > are out of scope since we are dealing with protocol and architecture > issues in the WG. The only aspect billing and roaming affect is that > if all technical requirements (e.g the ones this WG specifies) are > satisfied, the peer could still reject traffic (w/o consulting the > destination user, in Richard's terms) if the commercial relationship > does not exist. I think this is what hampers connectivity today. All > these commercial relationships exist because SPs want to be layer 5 > aware (they cannot seem to find a way to evolve their business models > otherwise... :), where only the origination SP (Core-O) and Core-T > need to have a commercial relationship. The roaming aspect again may > be quite artificial and could be questionable going forward... Just = my personal comments. > > -Medhavi. > > > My reply to David's email was more to the idea that you can install > > a > proxy server > > somewhere, point the "MX" to the next upstream "proxy server" and be > done with it? As > > VoIP takes off wouldn't some basic regulatory issues, numbering > > schemes > and others > > prevent such behavior? > > > > These are not rhetoric questions; I really do not know the answer. > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Tuesday, March 28, 2006 5:13 PM > > > To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > andpolicy- > > > dds-00(Peerign concepts and others..) > > > > > > > > > > > It begs the question why the two entities exchanging SIP > > > > signaling > do > > > not exchange policy > > > > information themselves through some SIP extension/new > > > > protocol/ > > name> and the > > > > role played by DNS. I'm not advocating this model but it seems a > > > pertinent question. > > > > > > I think peering in L3 must be basic, given how fundamental L3 is > > > to > the > > > internet. For SIP, TRIP provides functionality similar to BGP > > > (only > for > > > phone numbers though, I think). > > > > > > In my opinion, SIP peering ought to follow the email model. Once > location > > > is done and basic requirements are satisfied at the SIP layer > > > (like identity etc), the call should be routable. As Richard said > > > in the > earlier > > > email, the destination SP may still reject or challenge the call > > > if it lacks either the basic requirements we agree to in the WG or > > > some > extra > > > requirements specific to the termination SP (Core-T in my ID). The > > > challenge is that in some cases there are going to be IXPs > (Interconnects) > > > which sit in the middle due to commercial or regulatory reasons. > > > The location of an IXP, the provisioning of this IXP and the > > > Core-T SP are > the > > > architectural problems which this WG needs to solve as well. > > > > > > -Medhavi. > > > > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > > > > Sent: Tuesday, March 28, 2006 3:18 PM > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > > > > and > > > policy- > > > > > dds-00(Peerign concepts and others..) > > > > > > > > > > Hi Reinaldo > > > > > > > > > > I am not sure the goal of SPEERMINT is to recreate L3 peering > > > > > at > L5. > > > The > > > > > problem being solved is different in that L3 peering is always > with a > > > > > fixed number of neighbors. These are stored as you mention in > static > > > > > routing tables at each node and do not change from call to = call. > In > > > > > contrast, L5 peering is not necessarily static (unless you are > talking > > > > > about a federation model). The destination is chosen only when > > > > > the > > > call is > > > > > made and may be to a peer that a given service provider/domain > > > > > administrator/node has never spoken to before. > > > > > > > > > > Assuming DNS is used to find the peering node, the query is > > > > > made > on a > > > call > > > > > by call basis. Now clearly, this DNS info can be cached at the > > > originating > > > > > node but the cache still has a very different nature than that > > > > > of > an > > > L3 > > > > > routing table. > > > > > > > > > > Policy is an entirely different issue (as is the case in L3) > > > > > and > it is > > > > > important to separate it out from the routing issue. The draft > > > > > you > > > mention > > > > > about pushing policy via DNS is dealing with one out of many > possible > > > > > topologies - namely that of ad hoc federations. There was very > little > > > > > discussion about policy at IETF 65 as the foundations of L5 > routing > > > need > > > > > to be cemented before the higher level policy issues can be > addressed. > > > > > > > > > > Cheers, > > > > > > > > > > David > > > > > > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > Sent: ? 28 ??? 2006 23:34 > > > > > To: speermint@ietf.org > > > > > Subject: [Speermint] Comments on reqs-and-terminology-01 and > policy- > > > dds- > > > > > 00(Peerign concepts and others..) > > > > > > > > > > Hello, > > > > > > > > > > I've been reading "reqs and terminology" and I would like to > > > > > step > back > > > > > and ask some questions about some of the definitions. > > > > > > > > > > > > > > > Peering: > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > In layer 3 peering two routers exchange their routing tables, > reach a > > > > > steady state, and after that data packets can flow between the > > > > > two domains. > > > > > > > > > > Layer 5 peering means, "interconnection of two service > > > > > providers > for > > > the > > > > > purposes of SIP signaling". > > > > > > > > > > Making the inevitable comparison with layer 3 peering, there > > > > > are > some > > > > > fundamental differences that I'm trying to reconcile. > > > > > > > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers > exchange > > > all > > > > > necessary routing information and enter a steady state. At > > > > > this > point, > > > > > no other routes are exchanged and routers concentrate on > forwarding > > > > > packets. > > > > > > > > > > I know the WG is in the beginning, but it is not clear to me > > > > > what > > > pieces > > > > > are needed for an equivalent functionality. For example: > > > > > > > > > > 1) Are the entities exchanging SIP signaling for the purpose > > > > > of > > > peering > > > > > doing so on a _per call_ basis? Is there going to be some > mechanism > > > to > > > > > exchange such information in bulk such as in a routing = protocol? > Maybe > > > > > based on domain names or something similar? > > > > > > > > > > 2) The draft states that " A > > > > > domain's ingress point can be thought of as the location > pointed to > > > > > by the SRV record that resulted from the resolution of the > > > > > CRD > > > (i.e., > > > > > a SIP URI)." > > > > > > > > > > So, it seems to me that although the "layer 5 peering" is > happening > > > > > between the two entities exchanging SIP signaling, the peering > point > > > > > discovery is a result of a SRV query. But the draft also > > > > > states > that " > > > > > SPEERMINT Working Group is focused on the use of such CRD." > > > > > > > > > > Draft peering-policy states that " This documents proposes the > > > > > use > of > > > > > DNS entries to publish a SIP proxy's policy for accepting > > > > > incoming calls" proposes DNS as a way of exchange polices. > > > > > > > > > > This begs the question of what are the two "peering" entities > really > > > > > doing besides exchange traditional SIP signaling? It seems the > real > > > > > _information peering_ (for the lack of a better term) is > > > > > happening between DNS servers. All important information > > > > > related to > "peering" is > > > > > coming from a DNS server which might as well be on your own > > > > > domain > (if > > > > > your exchange DNS information). > > > > > > > > > > In summary, it seems to me the whole architecture is quite a > departure > > > > > from layer 3 peering where the entities peering are the > > > > > holders of > the > > > > > necessary information to allow data packets to flow. Here the > entities > > > > > peering publish their peering information to third party > > > > > server > which > > > > > does the actual "peering" (exchange inter-domain information). > > > > > > > > > > > > > > > Anyway, the idea of the mail is to try to clarify things. > > > > > There is > > > much > > > > > emphasis on SIP but it seems DNS plays a more central role. Or > maybe > > > > > some SIP extension will be made to exchange peering policies? > > > > > > > > > > > > > > > Policies and Independence of lower layers: > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. > > > > > Today > BGP > > > > > exchange QoS and VPN information, performs discovery, etc. > > > > > This > > > implies > > > > > that BGP indirectly (or directly) knows the capabilities of > > > > > the transport layer (thus the name capability negotiation). > > > > > > > > > > So, although the mechanism to exchange the actual policies > > > > > needs > to be > > > > > independent of the lower layers, there needs to be a way to > > > > > input > > > lower > > > > > layer information into the devices exchanging the policies. > > > > > Just > like > > > > > BGP has filters and priorities based on a myriad of options. > > > > > So, > maybe > > > > > the wording should change a little. > > > > > > > > > > As far as 5.6 goes, it seems to me the policies can be quite > complex. > > > > > The experience of BGP tells us that in the end policies can be > huge. > > > So, > > > > > if policies are going to be huge, what draft dds-00 states as > > > > > a possibility > > > > > > > > > > " If the simple boolean logic and the limited space in the DNS > answers > > > > > are insufficient for an application then a type of policy > > > > > rule > URIs > > > > > can be defined which links to policy statements written in > > > > > a > fully > > > > > featured policy description language like SAML [14] or > > > > > XACML > [15]." > > > > > > > > > > will actually going to be the rule. So, this begs the question > > > > > of > DNS > > > is > > > > > a good choice to publish peering policies. > > > > > > > > > > Thanks, > > > > > > > > > > Reinaldo > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > -- > > > > No virus found in this incoming message. > > > > Checked by AVG Free Edition. > > > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > 3/24/2006 > > > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > 3/24/2006 > > > > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 29 11:54:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdw7-0002VH-OI; Wed, 29 Mar 2006 11:54:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdw6-0002UW-M8 for speermint@ietf.org; Wed, 29 Mar 2006 11:54:22 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdw5-00061w-8Q for speermint@ietf.org; Wed, 29 Mar 2006 11:54:22 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 81D291A395; Wed, 29 Mar 2006 18:54:19 +0200 (CEST) Date: Wed, 29 Mar 2006 18:54:19 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..) Message-ID: <20060329165419.GA12968@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <32755D354E6B65498C3BD9FD496C7D462C493E@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C493E@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 valuable discussion. On 2006/03/29 00:03, Stastny Richard wrote: > > Lets reconsider what we are talking about: > > Speermint is primarily about interconnecting sip proxies at L5 > the L5 in SIP is a location service > > two SP have the task to find out for their users (customers) the > IP addresses to allow them to establish a session and finally > exchange IP packets on L3. > > We also could define this in another way: a SP is giving out > to their customers a public user identity, in SIP also called > an Address-of-Record. Note the term PUBLIC. This is a critical element for the Speermint charter. Are we dealing with public user identities in the meaning of "reachable by anybody via the public Internet" or not? > If I get a public user identity from a SP, I assume to be able to give this > to somebody else and he/she is able to reach me via a public > communications network (note that I do not mention here > the Internet, also a walled garden network such as Vonage > is a public communications network)- Ok they are not giving out AoRs What I see right now is that some big service providers * give customers telephone numbers (as their _public_ identity) * use SIP AoRs internally. [The same is true for a lot of corporate PBX systems: Internally they use SIP but all communication with the outside world is done via the PSTN.] The drafts I wrote are targetted at that setting. They assume that we start with zero IP-based interconnection. Calls between different service providers may be possible over the PSTN, but universal connectivity based on SIP AoRs is *not* assumed. I try to offer a path to do better than this 0% IP-based interconnection. Universal reachability on SIP basis may be a goal, but not reaching it isn't failure. *Any* SIP-based interconnection is progress if you start at 0%. On the other hand, if we're assuming that the SIP AoRs are PUBLIC, then I wonder what real world problem Speermint is supposed to solve. Basic interconnection is very well specified by the relevant SIP RFCs. There is hardly any work to do. Maybe some L3 interactions to enhance QoS. Maybe some SIP profiles. Maybe we should ask ourselves who will implement the results of the Speermint WG. Who are our "customers"? What are their assumptions and what issues need to be addressed so that they will agree to use our work? And why aren't the current SIP RFCs enough for them? I'd really appreciate consensus on that question. /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 Wed Mar 29 12:11:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOeCo-0003Do-PI; Wed, 29 Mar 2006 12:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOeCn-0003DQ-GU for speermint@ietf.org; Wed, 29 Mar 2006 12:11:37 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOeCm-0006yE-UX for speermint@ietf.org; Wed, 29 Mar 2006 12:11:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) Date: Wed, 29 Mar 2006 19:15:37 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4941@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) Thread-Index: AcZTUf/9Zpvl8RN8SyiJNNOMF/ZHqQAAM+3G From: "Stastny Richard" To: "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Now are finally at the point =20 I have only one problem here: =20 >The drafts I wrote are targetted at that setting. They assume >that we start with zero IP-based interconnection. Calls between >different service providers may be possible over the PSTN, >but universal connectivity based on SIP AoRs is *not* assumed =20 If you start with zero IP-based Interconnection, how do you get to the DNS to query the policy records in the DNS in the first place? =20 >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, ... =20 BTW, even in 3GPP and TISPAN the AoR are called PUBLIC User Identities, although they also have some problemy to comprehend what this implies. =20 >Are we dealing with public user identities in the meaning >of "reachable by anybody via the public Internet" or not? I thought speermint is an IETF WG =20 >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, >then I wonder what real world problem Speermint is supposed to solve. >Basic interconnection is very well specified by the relevant SIP RFCs. =20 good point ;-) =20 >There is hardly any work to do.=20 =20 As I pointed out earlier BCP setting minimum requiremnets and givin guidance along the sibley draft from the SIPforum could be very useful.=20 I also still see your policy draft useful for additional agreement above basic interconnect Richard ________________________________ Von: Otmar Lendl [mailto:lendl@nic.at] Gesendet: Mi 29.03.2006 18:54 An: speermint@ietf.org Betreff: Re: [Speermint] Comments on reqs-and-terminology-01 = andpolicy-dds-00(Peerign concepts and others..) This is a valuable discussion. On 2006/03/29 00:03, Stastny Richard wrote: >=20 > Lets reconsider what we are talking about: >=20 > Speermint is primarily about interconnecting sip proxies at L5 > the L5 in SIP is a location service >=20 > two SP have the task to find out for their users (customers) the > IP addresses to allow them to establish a session and finally > exchange IP packets on L3. >=20 > We also could define this in another way: a SP is giving out > to their customers a public user identity, in SIP also called > an Address-of-Record. Note the term PUBLIC. This is a critical element for the Speermint charter. Are we dealing with public user identities in the meaning of "reachable by anybody via the public Internet" or not? > If I get a public user identity from a SP, I assume to be able to give = this > to somebody else and he/she is able to reach me via a public > communications network (note that I do not mention here > the Internet, also a walled garden network such as Vonage > is a public communications network)- Ok they are not giving out AoRs What I see right now is that some big service providers * give customers telephone numbers (as their _public_ identity) * use SIP AoRs internally. [The same is true for a lot of corporate PBX systems: Internally they use SIP but all communication with the outside world is done via the = PSTN.] The drafts I wrote are targetted at that setting. They assume that we start with zero IP-based interconnection. Calls between different service providers may be possible over the PSTN, but universal connectivity based on SIP AoRs is *not* assumed. I try to offer a path to do better than this 0% IP-based interconnection. Universal reachability on SIP basis may be a goal, but not reaching it isn't failure. *Any* SIP-based interconnection is progress if you start at 0%. On the other hand, if we're assuming that the SIP AoRs are PUBLIC, then I wonder what real world problem Speermint is supposed to solve. Basic interconnection is very well specified by the relevant SIP RFCs. There is hardly any work to do. Maybe some L3 interactions to enhance QoS. Maybe some SIP profiles. Maybe we should ask ourselves who will implement the results of the Speermint WG. Who are our "customers"? What are their assumptions and what issues need to be addressed so that they will agree to use our work? And why aren't the current SIP RFCs enough for them? I'd really appreciate consensus on that question. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 Wed Mar 29 13:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfPi-0002si-Fh; Wed, 29 Mar 2006 13:29:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfPg-0002sc-QX for speermint@ietf.org; Wed, 29 Mar 2006 13:29:00 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfPe-0002cb-7N for speermint@ietf.org; Wed, 29 Mar 2006 13:29:00 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 29 Mar 2006 10:28:56 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,144,1141632000"; d="scan'208"; a="539692521:sNHT25008352" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Wed, 29 Mar 2006 13:28:55 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE598@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009AAAcZysAAQUy8AAAnRr4AAA7MKowAB2MbwAAHB6bA= From: "Reinaldo Penno" To: , "Stastny Richard" , "Medhavi Bhatia" , "David Schwartz" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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 > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > Sent: Wednesday, March 29, 2006 9:59 AM > To: 'Stastny Richard'; timothy.dwight@verizon.com; 'Medhavi Bhatia'; > Reinaldo Penno; 'David Schwartz'; speermint@ietf.org > Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging >=20 > Richard, >=20 > > >In my (probably simplistic) view, based on experience with other > > >technologies, "L5 peering" ought to involve 3 types of activities > > >happening over 3 distinct timescales: > > > > > >1) some sort of business agreement between entities responsible for a > set > of > > >L5 domains. Historically such agreements have usually been bilateral, > > >though other models are possible. In general the agreement establishes > > >the terms and conditions under which traffic will be exchanged. > > > > IMHO you are making an assumption here or drawing a conclusion that "L5 > peering" > > is fully analogue to L3 peering or interconnection on the PSTN: > > > > the hint is in the term "traffic will be exchanged". In both of the > above > mentioned cases really "traffic" is exchanged. > > > > In our case on L5 only SIP messages are exchanged. >=20 > Understood. [[Reinaldo]]=20 Okay, I understand there is an issue of problem scoping here....but in the real world, is there of _any_ use that your phone ring but you cannot talk or hear anything?=20 I mean, is the WG focused only on "enabling" SIP messages to be exchanged between two domains? Isn't that based on some commercial agreement that as a consequence will enable the two operators to manually configure the necessary devices?=20 Yes, the devices in the network "know" how to send and process DNS queries/replies, but lots of manual configuration will be needed before that. Or is our goal to enable plug-and-play VoIP peering? Because that seems a whole different game. As for media, I'm not saying we should try to solve media path issues, but what is the WG stance on this? "Hey, your phone just rang, be glad for that. That's where our work ends". Aren't there consequences based on the fact that media and signaling take different paths? I guess I'm still struggling with the problem the WG is trying to solve. Thanks, Reinaldo >=20 >=20 > > If really (media) traffic is exchanged how much and via which path > depends > on various other issues such as: > > do the end users really set up a media session, how are they connected > to > the Internet, or are they connected at all. > > > > Example: I am in a hotel in New York and register to a provider in > Germany > (I have no idea where the servers are > > located, could be in Poland), I set up a session to a friend registered > to > a SP in Australia, sip:vince@prov.au > > having his (one of) his servers located in Japan, to find out that my > friend is located in the same hotel in New York, > > We both pay 10 bucks to the hotel for a day of unlimted Internet access. > > > > How his thid "traffic exchanged" and who needs bilateral peering > agreements and who gets paid what? >=20 > It depends. If your providers are nice enough to run open relays then > there > is no need for peering agreements and (probably) no money changes hands > between operators. No doubt this is a viable model. Is it the only model > we intend to support? Doesn't seem very interesting frankly, but maybe > the > interesting work has to happen elsewhere? >=20 >=20 > > >I struggle to imagine this process happening dynamically, e.g., via > > >some sort of automated lookup of and agreement to, another operator's > > >terms and conditions. > > > > >I do think there is work the WG can do in support of these agreements, > > >though. For example definition of standard MIBs that can be used for > > >accounting purposes. I think as we understand better what information > > >needs to be exchanged in this "pre-realtime" phase, other opportunities > > >may emerge. > > > > In the above case; who is an operator requiring predefined bilateral > peering agreements that I may call my friend in the > hotel and get some > additional money to the 20 bucks we already paid? > > > > Or may I call my friend only if per chance both of us hit the checkpot > that our "providers" have a > > bilateral agreement or are in the same federation? >=20 > In the scenario you describe I assume there are no "operators" per se. > Again, that is a valid scenario. If it's the only scenario the WG intends > to consider, fine. Peering if fairly trivial in that context IMHO. >=20 >=20 > > >2) Step (1), iterated as necessary, establishes a sort of static > > >interconnect matrix. To make traffic flow across that matrix we may > > >need some dynamic exchange of "L5 routing" information. > > > > I do not need an dynamic exchange of "L5 routing information" > > the L5 routing information is given by sip:vince@prov.au there is no > matrix, there is only ONE destination provider > > prov.au, no choice. >=20 > The question is, how do you deliver a signaling packet to the operator > authoritative for "prov.au". Maybe that operator runs his SIP proxies as > open relays, in which case you can deliver the packets directly. Your > example assumes that to be the case. I agree it might be the case. I > think > our work would be more valuable if we did not assume it were always the > case. >=20 >=20 > > >As has been previously > > >noted, this is the role of BGP at L3. BGP is necessarily dynamic > > >because the information it communicates (reachability) is constantly in > > >flux. There is no analogue to BGP in the PSTN - the criteria governing > > >path selection at that level of abstraction (the sequence of networks > > >to be traversed) are assumed to be relatively static. [I am omitting > > >discussion of tariff arbitrage, which is an unfortunate but real result > of convoluted "policy" > > >that has created a hopefully-shortlived cottage industry] > > > > >How will the path to be taken by a given SIP packet, be selected? > > > > Are you talking here SIP or RTP packets? >=20 > SIP packet. >=20 >=20 > > A SIP invite is sent from my UA to my proxy, the proxy is looking up > prov.au for SRV records, eventually > > selecting the server in Japan; resolving the IP address and sending the > SIP packet there, etc >=20 > Of course. If every operator accepts signaling packets from every > operator, > things are simple. >=20 >=20 > > > > > >How decoupled from the path taken by the media stream, can this > practically be? >=20 > > The media stream may not even leave the hotel >=20 > Agreed, and in this example that seems like a desirable outcome. There > are > other examples where maybe it wouldn't be so desirable. >=20 >=20 > > >For example the signaling might "hop through" some sort of peering > > >point that offers no media relay services - that seems reasonable - but > > >to have the signaling and media traverse completely disjoint sets of L3 > > >networks whilst magically receiving end-to-end QoS treatment, does not. > > > > Aha, so to improve QoS within the hotel, we are using managed networks > from New York to Poland to Japan, back to > > New York. this helps? >=20 > Probably doesn't help in this case. But again this is only one example. > The interesting question is, can we have it both ways? Can we have the > managed network solution when it adds value, and not when it doesn't? >=20 >=20 > > If the LAN is the hotel is congested, you are doomed in either case >=20 > Of course. >=20 >=20 > > >What then is > > >the nature of the association of signaling-path and bearer-path, and > > >how is it assured (assuming that the signaling path is determined at L5 > > >and the bearer path at L3)? > > > > This is rebuilding the PSTN. Is this the scope of speermint? >=20 > I don't know what the phrase "rebuilding the PSTN" means. >=20 >=20 > Cheers, >=20 > tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 29 14:43:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgZd-0004f3-H6; Wed, 29 Mar 2006 14:43:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgZc-0004es-AH for speermint@ietf.org; Wed, 29 Mar 2006 14:43:20 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOgZb-0005VO-2O for speermint@ietf.org; Wed, 29 Mar 2006 14:43:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging Date: Wed, 29 Mar 2006 21:47:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4942@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009AAAcZysAAQUy8AAAnRr4AAA7MKowAB2MbwAAHB6bAAAr5Kag== From: "Stastny Richard" To: "Reinaldo Penno" , , "Medhavi Bhatia" , "David Schwartz" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec 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 >I guess I'm still struggling with the problem the WG is trying to = solve. I think we all do I have to admit that my example with the New York Hotel was of course provokative and also stating the obvoius, or as Otmar pointed out: it is all there in the RFCs and what speermint may add is some BCPs and minimum reqiurements Why I did this? Because I know about the other extreme model: It is the GSMA model for peering of mobile operators within 3GPP: GSMA is the club of mobile operators They plan that every operator is running SIP in a private=20 10.x.x.x network. A user may either be connected directly to this network or may VPN into it. All mobile operators interconnect to a commonly operated extranet (not (yet) connected to the Internet) which is callex IPX and an evolution of the existing GPX network currently used for GPRS Roaming. The ENUM database and also other DNS domains are provided within the IPX ( basically a managed Internet2). BTW, the DNS root of this network is run by Neustar. This works fine for all operators connected to this network, but the question remains, how does the GSMA operators interwork with say the cable operators or the fixed operators? Two options exist: 1. cable operators and fixed operators create their own clubs, and agree to peer with GSMA via a super IPX 2. All others are joining the GSMA club (GSMA is working on a proposal. Minor problem: the others still do not even have a club to negotiate e.g. TISPAN (the fixed operators) has still no clue which way to go The cable operators are currently doing something in between using private peering fabrics e.g. Xconnect (e.g. in NL) And VoIP providers on the Internet are left behind There is also another problem: an end-device connected such a network (either direct or via VPN) must have two separate IP stacks, if it also still wants to be connected to the Internet. Same is valid for an enterprise connected to a IMS VOIP provider. There is one stack for communications via IMS and another one for communications within the company and to the public Internet. The two may not be connected bcause then the security of the walled garden s compromised. This implies that you may e.g. not lauch a voip call via Outlook from the = corporate exchange server easily, only via complicated indirect portals on the Internet. What I want to state here is: for doing so, they do not need speermint either, they have already defined this and implementing it So one question remains: is there something in between the open Internet model and the closed IPX model? The finaly decision between these models will of course be done by the customer. The customer will have the option on his device which stack to use. This may be some ground for speermint cheers Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Mi 29.03.2006 20:28 An: timothy.dwight@verizon.com; Stastny Richard; Medhavi Bhatia; David = Schwartz; speermint@ietf.org Betreff: RE: [Speermint] Billing, Accounting, Tariffing and Charging > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > Sent: Wednesday, March 29, 2006 9:59 AM > To: 'Stastny Richard'; timothy.dwight@verizon.com; 'Medhavi Bhatia'; > Reinaldo Penno; 'David Schwartz'; speermint@ietf.org > Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging > > Richard, > > > >In my (probably simplistic) view, based on experience with other > > >technologies, "L5 peering" ought to involve 3 types of activities > > >happening over 3 distinct timescales: > > > > > >1) some sort of business agreement between entities responsible for a > set > of > > >L5 domains. Historically such agreements have usually been bilateral, > > >though other models are possible. In general the agreement establishes > > >the terms and conditions under which traffic will be exchanged. > > > > IMHO you are making an assumption here or drawing a conclusion that "L5 > peering" > > is fully analogue to L3 peering or interconnection on the PSTN: > > > > the hint is in the term "traffic will be exchanged". In both of the > above > mentioned cases really "traffic" is exchanged. > > > > In our case on L5 only SIP messages are exchanged. > > Understood. [[Reinaldo]] Okay, I understand there is an issue of problem scoping here....but in the real world, is there of _any_ use that your phone ring but you cannot talk or hear anything? I mean, is the WG focused only on "enabling" SIP messages to be exchanged between two domains? Isn't that based on some commercial agreement that as a consequence will enable the two operators to manually configure the necessary devices? Yes, the devices in the network "know" how to send and process DNS queries/replies, but lots of manual configuration will be needed before that. Or is our goal to enable plug-and-play VoIP peering? Because that seems a whole different game. As for media, I'm not saying we should try to solve media path issues, but what is the WG stance on this? "Hey, your phone just rang, be glad for that. That's where our work ends". Aren't there consequences based on the fact that media and signaling take different paths? I guess I'm still struggling with the problem the WG is trying to solve. Thanks, Reinaldo > > > > If really (media) traffic is exchanged how much and via which path > depends > on various other issues such as: > > do the end users really set up a media session, how are they connected > to > the Internet, or are they connected at all. > > > > Example: I am in a hotel in New York and register to a provider in > Germany > (I have no idea where the servers are > > located, could be in Poland), I set up a session to a friend registered > to > a SP in Australia, sip:vince@prov.au > > having his (one of) his servers located in Japan, to find out that my > friend is located in the same hotel in New York, > > We both pay 10 bucks to the hotel for a day of unlimted Internet access. > > > > How his thid "traffic exchanged" and who needs bilateral peering > agreements and who gets paid what? > > It depends. If your providers are nice enough to run open relays then > there > is no need for peering agreements and (probably) no money changes hands > between operators. No doubt this is a viable model. Is it the only model > we intend to support? Doesn't seem very interesting frankly, but maybe > the > interesting work has to happen elsewhere? > > > > >I struggle to imagine this process happening dynamically, e.g., via > > >some sort of automated lookup of and agreement to, another operator's > > >terms and conditions. > > > > >I do think there is work the WG can do in support of these agreements, > > >though. For example definition of standard MIBs that can be used for > > >accounting purposes. I think as we understand better what information > > >needs to be exchanged in this "pre-realtime" phase, other opportunities > > >may emerge. > > > > In the above case; who is an operator requiring predefined bilateral > peering agreements that I may call my friend in the > hotel and get some > additional money to the 20 bucks we already paid? > > > > Or may I call my friend only if per chance both of us hit the checkpot > that our "providers" have a > > bilateral agreement or are in the same federation? > > In the scenario you describe I assume there are no "operators" per se. > Again, that is a valid scenario. If it's the only scenario the WG intends > to consider, fine. Peering if fairly trivial in that context IMHO. > > > > >2) Step (1), iterated as necessary, establishes a sort of static > > >interconnect matrix. To make traffic flow across that matrix we may > > >need some dynamic exchange of "L5 routing" information. > > > > I do not need an dynamic exchange of "L5 routing information" > > the L5 routing information is given by sip:vince@prov.au there is no > matrix, there is only ONE destination provider > > prov.au, no choice. > > The question is, how do you deliver a signaling packet to the operator > authoritative for "prov.au". Maybe that operator runs his SIP proxies as > open relays, in which case you can deliver the packets directly. Your > example assumes that to be the case. I agree it might be the case. I > think > our work would be more valuable if we did not assume it were always the > case. > > > > >As has been previously > > >noted, this is the role of BGP at L3. BGP is necessarily dynamic > > >because the information it communicates (reachability) is constantly in > > >flux. There is no analogue to BGP in the PSTN - the criteria governing > > >path selection at that level of abstraction (the sequence of networks > > >to be traversed) are assumed to be relatively static. [I am omitting > > >discussion of tariff arbitrage, which is an unfortunate but real result > of convoluted "policy" > > >that has created a hopefully-shortlived cottage industry] > > > > >How will the path to be taken by a given SIP packet, be selected? > > > > Are you talking here SIP or RTP packets? > > SIP packet. > > > > A SIP invite is sent from my UA to my proxy, the proxy is looking up > prov.au for SRV records, eventually > > selecting the server in Japan; resolving the IP address and sending the > SIP packet there, etc > > Of course. If every operator accepts signaling packets from every > operator, > things are simple. > > > > > > > >How decoupled from the path taken by the media stream, can this > practically be? > > > The media stream may not even leave the hotel > > Agreed, and in this example that seems like a desirable outcome. There > are > other examples where maybe it wouldn't be so desirable. > > > > >For example the signaling might "hop through" some sort of peering > > >point that offers no media relay services - that seems reasonable - but > > >to have the signaling and media traverse completely disjoint sets of L3 > > >networks whilst magically receiving end-to-end QoS treatment, does not. > > > > Aha, so to improve QoS within the hotel, we are using managed networks > from New York to Poland to Japan, back to > > New York. this helps? > > Probably doesn't help in this case. But again this is only one example. > The interesting question is, can we have it both ways? Can we have the > managed network solution when it adds value, and not when it doesn't? > > > > If the LAN is the hotel is congested, you are doomed in either case > > Of course. > > > > >What then is > > >the nature of the association of signaling-path and bearer-path, and > > >how is it assured (assuming that the signaling path is determined at L5 > > >and the bearer path at L3)? > > > > This is rebuilding the PSTN. Is this the scope of speermint? > > I don't know what the phrase "rebuilding the PSTN" means. > > > Cheers, > > tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Mar 29 15:14:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOh3t-0002ky-Da; Wed, 29 Mar 2006 15:14:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOh3r-0002kt-Pt for speermint@ietf.org; Wed, 29 Mar 2006 15:14:36 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOh3r-0006n4-Bl for speermint@ietf.org; Wed, 29 Mar 2006 15:14:35 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 3ABCB1A395; Wed, 29 Mar 2006 22:14:34 +0200 (CEST) Date: Wed, 29 Mar 2006 22:14:33 +0200 From: Otmar Lendl To: Stastny Richard Subject: Re: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) Message-ID: <20060329201433.GB28504@nic.at> Mail-Followup-To: Otmar Lendl , Stastny Richard , speermint@ietf.org References: <32755D354E6B65498C3BD9FD496C7D462C4941@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4941@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: speermint@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 2006/03/29 19:03, Stastny Richard wrote: > Now are finally at the point Indeed. > I have only one problem here: > > >The drafts I wrote are targetted at that setting. They assume > >that we start with zero IP-based interconnection. Calls between > >different service providers may be possible over the PSTN, > >but universal connectivity based on SIP AoRs is *not* assumed > > If you start with zero IP-based Interconnection, how > do you get to the DNS to query the policy records in the > DNS in the first place? I probably should have written "IP-based Interconnection for voice calls". The problem isn't that any of those service providers isn't connected to the Internet, the problem is that they refuse to use their Internet connection (or even a private IP link) for VoIP interconnection with other server providers. In the case of Vonage, they do use the public Internet as their access network. So basic IP connectivity isn't the issue. It's getting their SIP border elements to talk to each other. And in that respect I guess it's more a business decision than a technical one. > >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, ... > > BTW, even in 3GPP and TISPAN the AoR are called PUBLIC > User Identities, although they also have some problemy to > comprehend what this implies. > > >Are we dealing with public user identities in the meaning > >of "reachable by anybody via the public Internet" or not? > > I thought speermint is an IETF WG So the IETF protocol police will hunt down those closed network operators and force them to open up their border elements? Or are we going to give those operators tools with which they can selectively open up their networks? IMHO we need to break through this all-or-nothing dilemma. Unless you get regulators to force all VoIP service providers to accept all SIP calls from anybody, none of the big ones will choose to open up their network. > >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, > >then I wonder what real world problem Speermint is supposed to solve. > >Basic interconnection is very well specified by the relevant SIP RFCs. > > good point ;-) > > >There is hardly any work to do. > > As I pointed out earlier BCP setting minimum requiremnets > and givin guidance along the sibley draft from the SIPforum > could be very useful. That SIPforum draft has a very different fundamental assumption: * IP-PBX and SIP service provider enter a contractual relationship. One part of that relationship is an agreement on the technical details of their interconnection (i.e. the sibley document). If things don't work out there are the usual dispute resolution mechanisms (i.e. courts) which can deal with these problems. Contrast that to (using the universal connectivity assumption): * As anybody must be able to place a call over the public Internet, there need not be a contractual relationship between originating and terminating network. The terminating side doesn't even know who the originating side is. We're in e-mail land here. If you want universal SIP connectivity AND contractual relationships between peering/interconnection partners, then you need transit networks. That way lies either PSTN version 2 (The IP version), or you replicate the BGP model at the SIP layer. > I also still see your policy draft useful for additional > agreement above basic interconnect Thanks. /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 Wed Mar 29 15:59:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhlc-0001NB-Nb; Wed, 29 Mar 2006 15:59:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhlb-0001N6-Am for speermint@ietf.org; Wed, 29 Mar 2006 15:59:47 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOhla-0000DY-O2 for speermint@ietf.org; Wed, 29 Mar 2006 15:59:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Mar 2006 23:03:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4943@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Universal Connectivity Assumption Thread-Index: AcZTbfY8HFThHdtQSUyHQ3GY077GDAAA+Vls From: "Stastny Richard" To: "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: speermint@ietf.org Subject: [Speermint] Universal Connectivity Assumption 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 >Contrast that to (using the universal connectivity assumption): > >* As anybody must be able to place a call over the public Internet, > there need not be a contractual relationship between originating > and terminating network. The terminating side doesn't even know > who the originating side is. We're in e-mail land here. >If you want universal SIP connectivity AND contractual relationships >between peering/interconnection partners, then you need transit >networks. That way lies either PSTN version 2 (The IP version), or >you replicate the BGP model at the SIP layer. I see your point =20 but finally there needs to be global connectivity and reachability =20 How can this be achieved? =20 We both agree that bilateral agreements do not scale, and it is also not aceptable by the end-users that reachability is a patchwork =20 the default via the PSTN is also not an option, at least for speermint -it works only with e.164 numbers -it works only for a very limited set of applications (vioce) -it works only as long as the PSTN is there =20 The next step is "transit networks on L5" aka federations This is better then bilateral agreements, but also a patchwork so we need something above the federations to allow them to interwork i.e. eventually even a hierarchy or a circle of trust. This is theoretically possible, but did not work in PKI =20 BTW, what was before the e-mail system (with all its weakness) Compuserve, aol and company mail, I can also dimly remember that there was for a short time e-mail gateways between them =20 And finally your proposal contains also the . policy ;-) =20 cheers =20 Richard ________________________________ Von: Otmar Lendl [mailto:lendl@nic.at] Gesendet: Mi 29.03.2006 22:14 An: Stastny Richard Cc: speermint@ietf.org Betreff: Re: [Speermint] Comments on reqs-and-terminology-01 = andpolicy-dds-00(Peerign concepts and others..) On 2006/03/29 19:03, Stastny Richard wrote: > Now are finally at the point Indeed. > I have only one problem here: >=20 > >The drafts I wrote are targetted at that setting. They assume > >that we start with zero IP-based interconnection. Calls between > >different service providers may be possible over the PSTN, > >but universal connectivity based on SIP AoRs is *not* assumed >=20 > If you start with zero IP-based Interconnection, how > do you get to the DNS to query the policy records in the > DNS in the first place? I probably should have written "IP-based Interconnection for voice = calls". The problem isn't that any of those service providers isn't connected to the Internet, the problem is that they refuse to use their Internet connection (or even a private IP link) for VoIP interconnection with other server providers. In the case of Vonage, they do use the public Internet as their access network. So basic IP connectivity isn't the issue. It's getting their SIP border elements to talk to each other. And in that respect I guess it's more a business decision than a technical one. > >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, = ... >=20 > BTW, even in 3GPP and TISPAN the AoR are called PUBLIC > User Identities, although they also have some problemy to > comprehend what this implies. >=20 > >Are we dealing with public user identities in the meaning > >of "reachable by anybody via the public Internet" or not? > > I thought speermint is an IETF WG So the IETF protocol police will hunt down those closed network operators and force them to open up their border elements? Or are we going to give those operators tools with which they can selectively open up their networks? IMHO we need to break through this all-or-nothing dilemma. Unless you get regulators to force all VoIP service providers to accept all SIP calls from anybody, none of the big ones will choose to open up their network. > >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, > >then I wonder what real world problem Speermint is supposed to solve. > >Basic interconnection is very well specified by the relevant SIP = RFCs. >=20 > good point ;-) >=20 > >There is hardly any work to do. >=20 > As I pointed out earlier BCP setting minimum requiremnets > and givin guidance along the sibley draft from the SIPforum > could be very useful. That SIPforum draft has a very different fundamental assumption: * IP-PBX and SIP service provider enter a contractual relationship. =20 One part of that relationship is an agreement on the technical details of their interconnection (i.e. the sibley document). If things don't work out there are the usual dispute resolution mechanisms (i.e. courts) which can deal with these problems. Contrast that to (using the universal connectivity assumption): * As anybody must be able to place a call over the public Internet, there need not be a contractual relationship between originating and terminating network. The terminating side doesn't even know who the originating side is. We're in e-mail land here. If you want universal SIP connectivity AND contractual relationships between peering/interconnection partners, then you need transit networks. That way lies either PSTN version 2 (The IP version), or you replicate the BGP model at the SIP layer. > I also still see your policy draft useful for additional > agreement above basic interconnect Thanks. /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 Wed Mar 29 21:06:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmYM-0006Z3-H3; Wed, 29 Mar 2006 21:06:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOmYJ-0006Yx-O8 for speermint@ietf.org; Wed, 29 Mar 2006 21:06:23 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOmYH-0007Ey-7G for speermint@ietf.org; Wed, 29 Mar 2006 21:06:23 -0500 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.02) id AD120174; Wed, 29 Mar 2006 21:06:10 -0500 From: "Patrick Melampy" To: "'Stastny Richard'" , "'Otmar Lendl'" Subject: RE: [Speermint] Universal Connectivity Assumption Date: Wed, 29 Mar 2006 21:06:15 -0500 Message-ID: <00d401c6539e$876047d0$6701a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZTbfY8HFThHdtQSUyHQ3GY077GDAAA+VlsAApvPtA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4943@oefeg-s04.oefeg.loc> X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: speermint@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 Even with universal connectivity -- there remains a problem. Are VoIP interconnect reciprocal values congruent with best efforts reciprocal values. Lets look at Layer 3 IP Networks for a quick analogy... With IP networks, network owners can decide how their network will be used by controlling what BGP4 Updates they will send out, and which they will accept. Thus, network owners can control how their network gets used. Last time I checked, IP Network owners do not like to see their network used (even for best efforts) when they don't get reciprocal value. Thus, many network owners manage their bi-lateral peering arrangements to exclude their network being used by accidental 3rd parties. The NAP providers of course are the route of last resort for many network owners when they must send packets to locations where there is no reciprocal exchange. Overlaying a VoIP interconnection based on SIP URI's (resolved using ENUM) will follow these 'default' paths established for best efforts. But this assumes that the value exchanges at the borders for best efforts and VoIP are identical. This is of course not true. IP Interconnects and VoIP interconnects will have dissimilar values for all parties. I think it is quite likely that many best effort relationships between large and small carriers with inadequate reciprocal value for free IP peering, will have very good reciprocal value for VoIP peering. Also consider the case of a strong VoIP carrier wanting to connect for voice with other large VoIP networks, but not really wanting to change or modify the way their best efforts packet agreements that are working today. If these two types of services do not have identical reciprocal values at each border, then it is unlikely that the utilization of 'natural routing' techniques will work. I think the biggest concern is that a VoIP network will get used for best efforts by accident, and that a best efforts IP peering arrangement will get used for VoIP exchanges accidentally. Techniques for filtering or dropping unwanted packets at borders will not work as a technique, because the best efforts services will fail. There exists a "route by service" problem. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, March 29, 2006 4:04 PM To: Otmar Lendl Cc: speermint@ietf.org Subject: [Speermint] Universal Connectivity Assumption >Contrast that to (using the universal connectivity assumption): > >* As anybody must be able to place a call over the public Internet, > there need not be a contractual relationship between originating > and terminating network. The terminating side doesn't even know > who the originating side is. We're in e-mail land here. >If you want universal SIP connectivity AND contractual relationships >between peering/interconnection partners, then you need transit >networks. That way lies either PSTN version 2 (The IP version), or >you replicate the BGP model at the SIP layer. I see your point but finally there needs to be global connectivity and reachability How can this be achieved? We both agree that bilateral agreements do not scale, and it is also not aceptable by the end-users that reachability is a patchwork the default via the PSTN is also not an option, at least for speermint -it works only with e.164 numbers -it works only for a very limited set of applications (vioce) -it works only as long as the PSTN is there The next step is "transit networks on L5" aka federations This is better then bilateral agreements, but also a patchwork so we need something above the federations to allow them to interwork i.e. eventually even a hierarchy or a circle of trust. This is theoretically possible, but did not work in PKI BTW, what was before the e-mail system (with all its weakness) Compuserve, aol and company mail, I can also dimly remember that there was for a short time e-mail gateways between them And finally your proposal contains also the . policy ;-) cheers Richard ________________________________ Von: Otmar Lendl [mailto:lendl@nic.at] Gesendet: Mi 29.03.2006 22:14 An: Stastny Richard Cc: speermint@ietf.org Betreff: Re: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign concepts and others..) On 2006/03/29 19:03, Stastny Richard wrote: > Now are finally at the point Indeed. > I have only one problem here: > > >The drafts I wrote are targetted at that setting. They assume > >that we start with zero IP-based interconnection. Calls between > >different service providers may be possible over the PSTN, > >but universal connectivity based on SIP AoRs is *not* assumed > > If you start with zero IP-based Interconnection, how > do you get to the DNS to query the policy records in the > DNS in the first place? I probably should have written "IP-based Interconnection for voice calls". The problem isn't that any of those service providers isn't connected to the Internet, the problem is that they refuse to use their Internet connection (or even a private IP link) for VoIP interconnection with other server providers. In the case of Vonage, they do use the public Internet as their access network. So basic IP connectivity isn't the issue. It's getting their SIP border elements to talk to each other. And in that respect I guess it's more a business decision than a technical one. > >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, ... > > BTW, even in 3GPP and TISPAN the AoR are called PUBLIC > User Identities, although they also have some problemy to > comprehend what this implies. > > >Are we dealing with public user identities in the meaning > >of "reachable by anybody via the public Internet" or not? > > I thought speermint is an IETF WG So the IETF protocol police will hunt down those closed network operators and force them to open up their border elements? Or are we going to give those operators tools with which they can selectively open up their networks? IMHO we need to break through this all-or-nothing dilemma. Unless you get regulators to force all VoIP service providers to accept all SIP calls from anybody, none of the big ones will choose to open up their network. > >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, > >then I wonder what real world problem Speermint is supposed to solve. > >Basic interconnection is very well specified by the relevant SIP RFCs. > > good point ;-) > > >There is hardly any work to do. > > As I pointed out earlier BCP setting minimum requiremnets > and givin guidance along the sibley draft from the SIPforum > could be very useful. That SIPforum draft has a very different fundamental assumption: * IP-PBX and SIP service provider enter a contractual relationship. One part of that relationship is an agreement on the technical details of their interconnection (i.e. the sibley document). If things don't work out there are the usual dispute resolution mechanisms (i.e. courts) which can deal with these problems. Contrast that to (using the universal connectivity assumption): * As anybody must be able to place a call over the public Internet, there need not be a contractual relationship between originating and terminating network. The terminating side doesn't even know who the originating side is. We're in e-mail land here. If you want universal SIP connectivity AND contractual relationships between peering/interconnection partners, then you need transit networks. That way lies either PSTN version 2 (The IP version), or you replicate the BGP model at the SIP layer. > I also still see your policy draft useful for additional > agreement above basic interconnect Thanks. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 Wed Mar 29 22:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOngC-0000H1-1a; Wed, 29 Mar 2006 22:18:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOngA-0000Gw-9P for speermint@ietf.org; Wed, 29 Mar 2006 22:18:34 -0500 Received: from leka.oceanic.com ([205.172.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOng9-0002bV-PG for speermint@ietf.org; Wed, 29 Mar 2006 22:18:34 -0500 Received: from 1AB764895C324D3 (kihei2 [66.37.169.171]) by leka.oceanic.com (8.13.6/8.13.6) with ESMTP id k2U3IFpa004273; Wed, 29 Mar 2006 17:18:20 -1000 (envelope-from henry@pulver.com) Message-Id: <200603300318.k2U3IFpa004273@leka.oceanic.com> From: "Henry Sinnreich" To: "'Otmar Lendl'" , "'Stastny Richard'" Subject: RE: [Speermint] Comments on reqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..) Date: Wed, 29 Mar 2006 21:18:17 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDg In-Reply-To: <20060329201433.GB28504@nic.at> X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.3.29.185106 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __STOCK_CRUFT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com 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 Otmar, I believe you have nailed it right on target: >The problem isn't that any of those service providers isn't connected to >the Internet, the problem is that they refuse to use their Internet >connection (or even a private IP link) for VoIP interconnection with other >server providers. If this is so, why should the IETF bother with this problem? Thanks, Henry -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Wednesday, March 29, 2006 2:15 PM To: Stastny Richard Cc: speermint@ietf.org Subject: Re: [Speermint] Comments on reqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..) On 2006/03/29 19:03, Stastny Richard wrote: > Now are finally at the point Indeed. > I have only one problem here: > > >The drafts I wrote are targetted at that setting. They assume > >that we start with zero IP-based interconnection. Calls between > >different service providers may be possible over the PSTN, > >but universal connectivity based on SIP AoRs is *not* assumed > > If you start with zero IP-based Interconnection, how > do you get to the DNS to query the policy records in the > DNS in the first place? I probably should have written "IP-based Interconnection for voice calls". The problem isn't that any of those service providers isn't connected to the Internet, the problem is that they refuse to use their Internet connection (or even a private IP link) for VoIP interconnection with other server providers. In the case of Vonage, they do use the public Internet as their access network. So basic IP connectivity isn't the issue. It's getting their SIP border elements to talk to each other. And in that respect I guess it's more a business decision than a technical one. > >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, ... > > BTW, even in 3GPP and TISPAN the AoR are called PUBLIC > User Identities, although they also have some problemy to > comprehend what this implies. > > >Are we dealing with public user identities in the meaning > >of "reachable by anybody via the public Internet" or not? > > I thought speermint is an IETF WG So the IETF protocol police will hunt down those closed network operators and force them to open up their border elements? Or are we going to give those operators tools with which they can selectively open up their networks? IMHO we need to break through this all-or-nothing dilemma. Unless you get regulators to force all VoIP service providers to accept all SIP calls from anybody, none of the big ones will choose to open up their network. > >On the other hand, if we're assuming that the SIP AoRs are PUBLIC, > >then I wonder what real world problem Speermint is supposed to solve. > >Basic interconnection is very well specified by the relevant SIP RFCs. > > good point ;-) > > >There is hardly any work to do. > > As I pointed out earlier BCP setting minimum requiremnets > and givin guidance along the sibley draft from the SIPforum > could be very useful. That SIPforum draft has a very different fundamental assumption: * IP-PBX and SIP service provider enter a contractual relationship. One part of that relationship is an agreement on the technical details of their interconnection (i.e. the sibley document). If things don't work out there are the usual dispute resolution mechanisms (i.e. courts) which can deal with these problems. Contrast that to (using the universal connectivity assumption): * As anybody must be able to place a call over the public Internet, there need not be a contractual relationship between originating and terminating network. The terminating side doesn't even know who the originating side is. We're in e-mail land here. If you want universal SIP connectivity AND contractual relationships between peering/interconnection partners, then you need transit networks. That way lies either PSTN version 2 (The IP version), or you replicate the BGP model at the SIP layer. > I also still see your policy draft useful for additional > agreement above basic interconnect Thanks. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 Thu Mar 30 04:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtCb-0005JA-IW; Thu, 30 Mar 2006 04:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtCa-0005J5-6S for speermint@ietf.org; Thu, 30 Mar 2006 04:12:24 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtCY-00014E-Su for speermint@ietf.org; Thu, 30 Mar 2006 04:12:24 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 956921A3A4; Thu, 30 Mar 2006 11:12:21 +0200 (CEST) Date: Thu, 30 Mar 2006 11:12:21 +0200 From: Otmar Lendl To: Reinaldo Penno Message-ID: <20060330091221.GB12968@nic.at> Mail-Followup-To: Otmar Lendl , Reinaldo Penno , speermint@ietf.org References: <9BD5D7887235424FA97DFC223CAE3C2802DFE58E@proton.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE58E@proton.jnpr.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: speermint@ietf.org Subject: [Speermint] Definition of "Peering" 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 2006/03/28 23:03, Reinaldo Penno wrote: > Hello, > > I've been reading "reqs and terminology" and I would like to step back > and ask some questions about some of the definitions. Good idea. Here is my answer. > Peering: > ======== > > In layer 3 peering two routers exchange their routing tables, reach a > steady state, and after that data packets can flow between the two > domains. I think this definition is too broad: it applies to any BGP connection. A Layer 3 peering is a shortcut connection established to avoid sending the traffic via the default upstream networks. Such a direct connection saves money (upstream is more expensive) and improves the network performance. L3 peering is not about reachability per se. For that, one single interconnect to an upstream networks suffices. I'll use the term "interconnection" below in a very generic sense, and not in the one used in the PSTN world. I'm very much open to alternative wordings. So what about: ----- SIP Peering is the establishement of an alternative communication path between the SIP elements of two entities (service providers, corporations, ...) to improve over the service offered by the default interconnection. The improvements offered by this new path can include (but are not limited to) * better QoS * cost benefits (e.g. if the default path is billed by minute) * additional features (e.g. wideband codecs or IM) * abuse handling. The default interconnection between two parties is out of scope for the Speermint WG. ----- I don't think we should care whether the default interconnection mechanism is SIP according to RFC3261, the PSTN, SIP via a transit network, or simply no default interconnection at all. All we need to focus on here in Speermint is to define a framework which can be used to establish more direct and thus better crosslinks between two SIP service providers. /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 Thu Mar 30 04:33:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtWj-0004Ka-1t; Thu, 30 Mar 2006 04:33:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtWi-0004KA-Bo for speermint@ietf.org; Thu, 30 Mar 2006 04:33:12 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtWh-0001sF-Kb for speermint@ietf.org; Thu, 30 Mar 2006 04:33:12 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2U9X5Ku000765; Thu, 30 Mar 2006 03:33:09 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Mar 2006 10:33:04 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01274969E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Stastny Richard'" , "'Paul Kyzivat'" , "'Bob Natale'" Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Thu, 30 Mar 2006 10:32:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.lucent.com id k2U9X5Ku000765 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d0fbd8998981e4ebcb3d1ed6e80728c Cc: "'speermint@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 I am sure we could get into all sorts of philosophical discussions on thi= s, but let's just postulate one question: How much of the items you spend money on in a year are actually based on = the cost of providing the service, and how much is based on what the mark= et will bear? And I don't see it being any different for most ISPs either. But anyway surely those issues are irrelevant for SPEERMINT. What SPEERMINT needs to deal with is how each operator accounts to anothe= r operator for the traffic that one delivers to the other. In 3GPP that i= s dealt with primarily by the exchange of IOI parameters over SIP. At the= SIP level the account is not exchanged between operators, merely an indi= cator of the operator that the traffic has been passed to. regards Keith > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 29 March 2006 15:05 > To: Paul Kyzivat; Bob Natale > Cc: speermint@ietf.org > Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging >=20 >=20 > Exactly >=20 > Richard >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, March 29, 2006 3:58 PM > > To: Bob Natale > > Cc: Stastny Richard; speermint@ietf.org > > Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging > >=20 > >=20 > >=20 > > Bob Natale wrote: > > > > > > Hi Richard, > > > > > > 1. Your point about the possible relevance for=20 > SPEERMINT's scope of > > accounting requirements, and not billing requirements, is=20 > well-taken and > > will be reflected clearly in the next rev of the=20 > Requirements BCP draft. > > > > > > 2. Wrt your comment: "3. So why is it necessary to=20 > charge termination > > fees to the O-user at all for SIGNALLING?": > > > Might it not be true that some applications of value to=20 > the user might > > involve signaling only, and not media per se? (I am=20 > thinking of certain > > presence and notification apps...?) > >=20 > > What does that change? > >=20 > > IMO it makes sense to charge for services actually=20 > rendered, and not for > > services the SP isn't involved in but wishes they could get=20 > some revenue > > from. > >=20 > > The terminating proxy does render some identifiable=20 > services that could > > potentially be charged for: > > - supplying the AOR > > - processing (routing) requests to the AOR > >=20 > > These are of value precisely because they eliminate the=20 > need for the end > > user to keep a UA online at all times, and because it=20 > permits the end > > user to dynamically associate UAs with the AOR, by providing a > > potentially recognized and trusted domain. > >=20 > > This doesn't seem like stuff that justifies per-use=20 > charging, and the > > amount of charging that can be extracted for these basic services is > > probably limited, but its something. > >=20 > > If an SP wants to charge more, then they will have to provide more > > services - ones that users are interested in paying for. > >=20 > > Paul > >=20 > > > Cheers, > > > BobN > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, March 29, 2006 6:08 AM > > > To: Medhavi Bhatia; Reinaldo Penno; David Schwartz;=20 > speermint@ietf.org > > > Subject: [Speermint] Billing, Accounting, Tariffing and Charging > > > > > > > > >>>These are not rhetoric questions; I really do not know=20 > the answer. > > > > > > > > > Welcome to the club, you are not alone ;-) > > > > > > > > >>>VoIP is exactly the opposite. VoIP (signaling and media)=20 > are delay > > >> > > >>sensitive, need > > >> > > >>>prioritization and will be billed. > > >>> > > >> > > >>Good point. What we need is to separate the problem of=20 > peering into at > > >>least two parts: terminating the call and the traffic itself (data > > part). > > >>The email model applies only to the termination part. > > > > > > > > > Hmmm, I think it is even more complicated. > > > > > > Terminology: > > > > > > Billing is between end-users and a SP (out of scope in spearmint) > > Accounting is between SP (in scope of spearmint?) Tariffing is the > > calculation of a charge for using a certain resource for a=20 > certain amount > > of time. > > > > > > I consider it also paradox that we are discussing accounting and > > charging, particularly termination charges (fees) 1. in a=20 > time even in the > > PSTN issues are moving to bill-and-keep 2. on an=20 > inappropriate layer (L5) > > > > > > A substantial part of the problems with VoIP peering=20 > derives not from > > trust, QoS, SPIT, etc. problems, but simply how to keep up=20 > the existing > > regime of termination fees. > > > > > > Especially mobile operators make a living on this. > > > > > > Where is this problem coming from on the PSTN? > > > (Lets for a moment forget problems caused by reverse > > > charging) > > > > > > In the PSTN there was originally an accounting regime based on > > cascading. The O-SP bills the O-user for the call (based on=20 > distance), and > > keeping part of it and paying out part to the next (transit) SP. > > > This goes on until the destination > > > (T-SP) is reached, which also gets a share. > > > > > > The implicit assumptions here are: the originator has the=20 > benefit of the > > call and also call set-up is in one direction and call=20 > signalling and the > > mediastream is traversing all networks in question. > > > > > > This principle is only broken with call forwarding and=20 > also with mobile > > roaming. In the US also the mobile T-user pays air-time,=20 > not so in Europe, > > hence the problems with mobile NP > > > > > > Note: in my remark to my previous post on terminating=20 > network monopoly > > (SMP), one may consider the termination fee also as a=20 > compensation for the > > remedy that a terminating network MUST accept any call. > > > > > > This regime was quite simple, but was more and more=20 > complicated over > > time by burdening it with additional issues such as=20 > subsidies, etc. as it > > is currently in the US. > > > > > > > > > What does this imply now for VoIP peering or interconnect > > > > > > VoIP; RTC and IP separate signalling (L5) from transport=20 > (L3) It also > > separates the SP from the access Now taking into account some facts: > > > > > > 1. Although SIP signalling (call set-up) is directed from=20 > O to T, the > > mediastream is both ways and symmetric (so much for Whitacre, he may > > eventually blame Google Video, but not VoIP providers) > > > > > > 2. The cost for the mediastream is moving more and more=20 > to the ends > > (access), even in the PSTN (see the latest OFCOM report on distance > > gradients), and the access is already paid in some way or=20 > the other by the > > end-users. > > > > > > 3. So why is it necessary to charge termination fees to=20 > the O-user at > > all for SIGNALLING? > > > > > > There is one issue where termination fees may apply=20 > (although this is > > going away also - e.g. > > > Voipbuster): if you connect to the PSTN. > > > > > > But this is out of scope in Speermint and in addition=20 > solutions exist > > here since years. > > > > > > My recommendation is that as long as speermint is dealing with L5 > > peering only, accounting i.e. termination fees should not=20 > be dealt with. > > > > > > Cheers > > > > > > Richard > > > > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > >>Sent: Wednesday, March 29, 2006 4:28 AM > > >>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > >>Subject: RE: [Speermint] Comments on > > >>reqs-and-terminology-01andpolicy-dds- > > >>00(Peerign concepts and others..) > > >> > > >>Hi Reinaldo, > > >> > > >> > > >>>-----Original Message----- > > >>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > > >>>Sent: Tuesday, March 28, 2006 8:31 PM > > >>>To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > > >>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > >>>andpolicy- > > >> > > >>dds-00(Peerign > > >> > > >>>concepts and others..) > > >>> > > >>>Hello, > > >>> > > >>>I tend to agree that the email model sounds attractive except the > > >>>delay > > >> > > >>and business > > >> > > >>>requirements of email and VoIP are quire different. > > >>> > > >>>Email is not delay sensitive, does not require any type of > > >> > > >>prioritization and is not charged > > >> > > >>>(or at least it wasn't). > > >>> > > >>>VoIP is exactly the opposite. VoIP (signaling and media)=20 > are delay > > >> > > >>sensitive, need > > >> > > >>>prioritization and will be billed. > > >>> > > >> > > >>Good point. What we need is to separate the problem of=20 > peering into at > > >>least two parts: terminating the call and the traffic itself (data > > part). > > >>The email model applies only to the termination part. > > >> > > >> > > >>>I believe a call to a public number is (or should)=20 > always going to > > >>>be > > >> > > >>routable. I guess my > > >> > > >>>main question is: is the general belief that VoIP providers will > > >>>just > > >> > > >>configure their proxy > > >> > > >>>servers to talk to each other in an email type model? No business > > >> > > >>agreements similar to > > >> > > >>>PSTN/Wireless, no charging, no extra billing for "roaming", etc? > > >>> > > >> > > >>I agree those are issues. It would be good if we can work out > > >>something which is generic (compared to IMS/PSTN=20 > specific). Maybe they > > >>are out of scope since we are dealing with protocol and=20 > architecture > > >>issues in the WG. The only aspect billing and roaming=20 > affect is that > > >>if all technical requirements (e.g the ones this WG specifies) are > > >>satisfied, the peer could still reject traffic (w/o consulting the > > >>destination user, in Richard's terms) if the commercial=20 > relationship > > >>does not exist. I think this is what hampers connectivity=20 > today. All > > >>these commercial relationships exist because SPs want to=20 > be layer 5 > > >>aware (they cannot seem to find a way to evolve their=20 > business models > > >>otherwise... :), where only the origination SP (Core-O) and Core-T > > >>need to have a commercial relationship. The roaming=20 > aspect again may > > >>be quite artificial and could be questionable going=20 > forward... Just my > > personal comments. > > >> > > >>-Medhavi. > > >> > > >> > > >>>My reply to David's email was more to the idea that you=20 > can install > > >>>a > > >> > > >>proxy server > > >> > > >>>somewhere, point the "MX" to the next upstream "proxy=20 > server" and be > > >> > > >>done with it? As > > >> > > >>>VoIP takes off wouldn't some basic regulatory issues, numbering > > >>>schemes > > >> > > >>and others > > >> > > >>>prevent such behavior? > > >>> > > >>>These are not rhetoric questions; I really do not know=20 > the answer. > > >>> > > >>>Regards, > > >>> > > >>>Reinaldo > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > >>>>Sent: Tuesday, March 28, 2006 5:13 PM > > >>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > >>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > >> > > >>andpolicy- > > >> > > >>>>dds-00(Peerign concepts and others..) > > >>>> > > >>>> > > >>>>>It begs the question why the two entities exchanging SIP > > >>>>>signaling > > >> > > >>do > > >> > > >>>>not exchange policy > > >>>> > > >>>>>information themselves through some SIP extension/new > > >>>>>protocol/ > >>>> > > >>>>name> and the > > >>>> > > >>>>>role played by DNS. I'm not advocating this model but=20 > it seems a > > >>>> > > >>>>pertinent question. > > >>>> > > >>>>I think peering in L3 must be basic, given how fundamental L3 is > > >>>>to > > >> > > >>the > > >> > > >>>>internet. For SIP, TRIP provides functionality similar to BGP > > >>>>(only > > >> > > >>for > > >> > > >>>>phone numbers though, I think). > > >>>> > > >>>>In my opinion, SIP peering ought to follow the email model. Once > > >> > > >>location > > >> > > >>>>is done and basic requirements are satisfied at the SIP layer > > >>>>(like identity etc), the call should be routable. As=20 > Richard said > > >>>>in the > > >> > > >>earlier > > >> > > >>>>email, the destination SP may still reject or challenge the call > > >>>>if it lacks either the basic requirements we agree to=20 > in the WG or > > >>>>some > > >> > > >>extra > > >> > > >>>>requirements specific to the termination SP (Core-T in=20 > my ID). The > > >>>>challenge is that in some cases there are going to be IXPs > > >> > > >>(Interconnects) > > >> > > >>>>which sit in the middle due to commercial or regulatory reasons. > > >>>>The location of an IXP, the provisioning of this IXP and the > > >>>>Core-T SP are > > >> > > >>the > > >> > > >>>>architectural problems which this WG needs to solve as well. > > >>>> > > >>>>-Medhavi. > > >>>> > > >>>> > > >>>>>Regards, > > >>>>> > > >>>>>Reinaldo > > >>>>> > > >>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > >>>>>>Sent: Tuesday, March 28, 2006 3:18 PM > > >>>>>>To: Reinaldo Penno; speermint@ietf.org > > >>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > >>>>>>and > > >>>> > > >>>>policy- > > >>>> > > >>>>>>dds-00(Peerign concepts and others..) > > >>>>>> > > >>>>>>Hi Reinaldo > > >>>>>> > > >>>>>>I am not sure the goal of SPEERMINT is to recreate L3 peering > > >>>>>>at > > >> > > >>L5. > > >> > > >>>>The > > >>>> > > >>>>>>problem being solved is different in that L3 peering is always > > >> > > >>with a > > >> > > >>>>>>fixed number of neighbors. These are stored as you mention in > > >> > > >>static > > >> > > >>>>>>routing tables at each node and do not change from=20 > call to call. > > >> > > >>In > > >> > > >>>>>>contrast, L5 peering is not necessarily static (unless you are > > >> > > >>talking > > >> > > >>>>>>about a federation model). The destination is chosen only when > > >>>>>>the > > >>>> > > >>>>call is > > >>>> > > >>>>>>made and may be to a peer that a given service provider/domain > > >>>>>>administrator/node has never spoken to before. > > >>>>>> > > >>>>>>Assuming DNS is used to find the peering node, the query is > > >>>>>>made > > >> > > >>on a > > >> > > >>>>call > > >>>> > > >>>>>>by call basis. Now clearly, this DNS info can be cached at the > > >>>> > > >>>>originating > > >>>> > > >>>>>>node but the cache still has a very different nature than that > > >>>>>>of > > >> > > >>an > > >> > > >>>>L3 > > >>>> > > >>>>>>routing table. > > >>>>>> > > >>>>>>Policy is an entirely different issue (as is the case in L3) > > >>>>>>and > > >> > > >>it is > > >> > > >>>>>>important to separate it out from the routing issue. The draft > > >>>>>>you > > >>>> > > >>>>mention > > >>>> > > >>>>>>about pushing policy via DNS is dealing with one out of many > > >> > > >>possible > > >> > > >>>>>>topologies - namely that of ad hoc federations. There was very > > >> > > >>little > > >> > > >>>>>>discussion about policy at IETF 65 as the foundations of L5 > > >> > > >>routing > > >> > > >>>>need > > >>>> > > >>>>>>to be cemented before the higher level policy issues can be > > >> > > >>addressed. > > >> > > >>>>>>Cheers, > > >>>>>> > > >>>>>>David > > >>>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > > >>>>>>Sent: =E2 28 =EE=F8=F5 2006 23:34 > > >>>>>>To: speermint@ietf.org > > >>>>>>Subject: [Speermint] Comments on reqs-and-terminology-01 and > > >> > > >>policy- > > >> > > >>>>dds- > > >>>> > > >>>>>>00(Peerign concepts and others..) > > >>>>>> > > >>>>>>Hello, > > >>>>>> > > >>>>>>I've been reading "reqs and terminology" and I would like to > > >>>>>>step > > >> > > >>back > > >> > > >>>>>>and ask some questions about some of the definitions. > > >>>>>> > > >>>>>> > > >>>>>>Peering: > > >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>> > > >>>>>>In layer 3 peering two routers exchange their routing tables, > > >> > > >>reach a > > >> > > >>>>>>steady state, and after that data packets can flow between the > > >>>>>>two domains. > > >>>>>> > > >>>>>>Layer 5 peering means, "interconnection of two service > > >>>>>>providers > > >> > > >>for > > >> > > >>>>the > > >>>> > > >>>>>>purposes of SIP signaling". > > >>>>>> > > >>>>>>Making the inevitable comparison with layer 3 peering, there > > >>>>>>are > > >> > > >>some > > >> > > >>>>>>fundamental differences that I'm trying to reconcile. > > >>>>>> > > >>>>>>1) In a traditional (a.k.a. layer 3) peering, both routers > > >> > > >>exchange > > >> > > >>>>all > > >>>> > > >>>>>>necessary routing information and enter a steady state. At > > >>>>>>this > > >> > > >>point, > > >> > > >>>>>>no other routes are exchanged and routers concentrate on > > >> > > >>forwarding > > >> > > >>>>>>packets. > > >>>>>> > > >>>>>>I know the WG is in the beginning, but it is not clear to me > > >>>>>>what > > >>>> > > >>>>pieces > > >>>> > > >>>>>>are needed for an equivalent functionality. For example: > > >>>>>> > > >>>>>>1) Are the entities exchanging SIP signaling for the purpose > > >>>>>>of > > >>>> > > >>>>peering > > >>>> > > >>>>>>doing so on a _per call_ basis? Is there going to be some > > >> > > >>mechanism > > >> > > >>>>to > > >>>> > > >>>>>>exchange such information in bulk such as in a=20 > routing protocol? > > >> > > >>Maybe > > >> > > >>>>>>based on domain names or something similar? > > >>>>>> > > >>>>>>2) The draft states that " A > > >>>>>> domain's ingress point can be thought of as the location > > >> > > >>pointed to > > >> > > >>>>>> by the SRV record that resulted from the resolution of the > > >>>>>>CRD > > >>>> > > >>>>(i.e., > > >>>> > > >>>>>> a SIP URI)." > > >>>>>> > > >>>>>>So, it seems to me that although the "layer 5 peering" is > > >> > > >>happening > > >> > > >>>>>>between the two entities exchanging SIP signaling, the peering > > >> > > >>point > > >> > > >>>>>>discovery is a result of a SRV query. But the draft also > > >>>>>>states > > >> > > >>that " > > >> > > >>>>>>SPEERMINT Working Group is focused on the use of such CRD." > > >>>>>> > > >>>>>>Draft peering-policy states that " This documents proposes the > > >>>>>>use > > >> > > >>of > > >> > > >>>>>>DNS entries to publish a SIP proxy's policy for accepting > > >>>>>>incoming calls" proposes DNS as a way of exchange polices. > > >>>>>> > > >>>>>>This begs the question of what are the two "peering" entities > > >> > > >>really > > >> > > >>>>>>doing besides exchange traditional SIP signaling? It seems the > > >> > > >>real > > >> > > >>>>>>_information peering_ (for the lack of a better term) is > > >>>>>>happening between DNS servers. All important information > > >>>>>>related to > > >> > > >>"peering" is > > >> > > >>>>>>coming from a DNS server which might as well be on your own > > >>>>>>domain > > >> > > >>(if > > >> > > >>>>>>your exchange DNS information). > > >>>>>> > > >>>>>>In summary, it seems to me the whole architecture is quite a > > >> > > >>departure > > >> > > >>>>>>from layer 3 peering where the entities peering are the > > >>>>>>holders of > > >> > > >>the > > >> > > >>>>>>necessary information to allow data packets to flow. Here the > > >> > > >>entities > > >> > > >>>>>>peering publish their peering information to third party > > >>>>>>server > > >> > > >>which > > >> > > >>>>>>does the actual "peering" (exchange inter-domain information). > > >>>>>> > > >>>>>> > > >>>>>>Anyway, the idea of the mail is to try to clarify things. > > >>>>>>There is > > >>>> > > >>>>much > > >>>> > > >>>>>>emphasis on SIP but it seems DNS plays a more central role. Or > > >> > > >>maybe > > >> > > >>>>>>some SIP extension will be made to exchange peering policies? > > >>>>>> > > >>>>>> > > >>>>>>Policies and Independence of lower layers: > > >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>> > > >>>>>>It seems sections 5.5 and 5.6 are _somewhat_ conflicting. > > >>>>>>Today > > >> > > >>BGP > > >> > > >>>>>>exchange QoS and VPN information, performs discovery, etc. > > >>>>>>This > > >>>> > > >>>>implies > > >>>> > > >>>>>>that BGP indirectly (or directly) knows the capabilities of > > >>>>>>the transport layer (thus the name capability negotiation). > > >>>>>> > > >>>>>>So, although the mechanism to exchange the actual policies > > >>>>>>needs > > >> > > >>to be > > >> > > >>>>>>independent of the lower layers, there needs to be a way to > > >>>>>>input > > >>>> > > >>>>lower > > >>>> > > >>>>>>layer information into the devices exchanging the policies. > > >>>>>>Just > > >> > > >>like > > >> > > >>>>>>BGP has filters and priorities based on a myriad of options. > > >>>>>>So, > > >> > > >>maybe > > >> > > >>>>>>the wording should change a little. > > >>>>>> > > >>>>>>As far as 5.6 goes, it seems to me the policies can be quite > > >> > > >>complex. > > >> > > >>>>>>The experience of BGP tells us that in the end policies can be > > >> > > >>huge. > > >> > > >>>>So, > > >>>> > > >>>>>>if policies are going to be huge, what draft dds-00 states as > > >>>>>>a possibility > > >>>>>> > > >>>>>>" If the simple boolean logic and the limited space in the DNS > > >> > > >>answers > > >> > > >>>>>> are insufficient for an application then a type of policy > > >>>>>>rule > > >> > > >>URIs > > >> > > >>>>>> can be defined which links to policy statements written in > > >>>>>>a > > >> > > >>fully > > >> > > >>>>>> featured policy description language like SAML [14] or > > >>>>>>XACML > > >> > > >>[15]." > > >> > > >>>>>>will actually going to be the rule. So, this begs the question > > >>>>>>of > > >> > > >>DNS > > >> > > >>>>is > > >>>> > > >>>>>>a good choice to publish peering policies. > > >>>>>> > > >>>>>>Thanks, > > >>>>>> > > >>>>>>Reinaldo > > >>>>>> > > >>>>>>_______________________________________________ > > >>>>>>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 > > >>>>> > > >>>>>-- > > >>>>>No virus found in this incoming message. > > >>>>>Checked by AVG Free Edition. > > >>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > >> > > >>3/24/2006 > > >> > > >>>-- > > >>>No virus found in this incoming message. > > >>>Checked by AVG Free Edition. > > >>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > >>>3/24/2006 > > >>> > > >> > > >>_______________________________________________ > > >>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 > > > > > > _______________________________________________ > > > 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 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 05:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOu22-0007Cm-De; Thu, 30 Mar 2006 05:05:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOu21-0007Ch-4z for speermint@ietf.org; Thu, 30 Mar 2006 05:05:33 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOu1z-0002pa-Fh for speermint@ietf.org; Thu, 30 Mar 2006 05:05:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging Date: Thu, 30 Mar 2006 12:05:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4946@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZT3YiFN4zQv2ikQTCsECCs5y2YDgAA+nLm From: "Stastny Richard" To: "Drage, Keith \(Keith\)" , "Paul Kyzivat" , "Bob Natale" X-Spam-Score: 0.0 (/) X-Scan-Signature: 76319d6f172f4cd0a083860f80065cd1 Cc: speermint@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 Keith, =20 some questions for clarification =20 >What SPEERMINT needs to deal with is how each operator accounts to = another operator for the traffic that one delivers to the >other. In = 3GPP that is dealt with primarily by the exchange of IOI parameters over = SIP. At the SIP level the account is not >exchanged between operators, = merely an indicator of the operator that the traffic has been passed to. 1. So you are proposing SPEERMINT should deal with accounting issues? 2. What kind of traffic? L3 or L5? 3. What if no L3 traffic is deleivered at all? 4.or are you proposing that SPEERMINT is dealing only with networks = behind SBC? 5. IOI? =20 regards Richard ________________________________ Von: Drage, Keith (Keith) [mailto:drage@lucent.com] Gesendet: Do 30.03.2006 11:32 An: Stastny Richard; 'Paul Kyzivat'; 'Bob Natale' Cc: 'speermint@ietf.org' Betreff: RE: [Speermint] Billing, Accounting, Tariffing and Charging I am sure we could get into all sorts of philosophical discussions on = this, but let's just postulate one question: How much of the items you spend money on in a year are actually based on = the cost of providing the service, and how much is based on what the = market will bear? And I don't see it being any different for most ISPs either. But anyway surely those issues are irrelevant for SPEERMINT. What SPEERMINT needs to deal with is how each operator accounts to = another operator for the traffic that one delivers to the other. In 3GPP = that is dealt with primarily by the exchange of IOI parameters over SIP. = At the SIP level the account is not exchanged between operators, merely = an indicator of the operator that the traffic has been passed to. regards Keith > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 29 March 2006 15:05 > To: Paul Kyzivat; Bob Natale > Cc: speermint@ietf.org > Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging > > > Exactly > > Richard > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, March 29, 2006 3:58 PM > > To: Bob Natale > > Cc: Stastny Richard; speermint@ietf.org > > Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging > > > > > > > > Bob Natale wrote: > > > > > > Hi Richard, > > > > > > 1. Your point about the possible relevance for > SPEERMINT's scope of > > accounting requirements, and not billing requirements, is > well-taken and > > will be reflected clearly in the next rev of the > Requirements BCP draft. > > > > > > 2. Wrt your comment: "3. So why is it necessary to > charge termination > > fees to the O-user at all for SIGNALLING?": > > > Might it not be true that some applications of value to > the user might > > involve signaling only, and not media per se? (I am > thinking of certain > > presence and notification apps...?) > > > > What does that change? > > > > IMO it makes sense to charge for services actually > rendered, and not for > > services the SP isn't involved in but wishes they could get > some revenue > > from. > > > > The terminating proxy does render some identifiable > services that could > > potentially be charged for: > > - supplying the AOR > > - processing (routing) requests to the AOR > > > > These are of value precisely because they eliminate the > need for the end > > user to keep a UA online at all times, and because it > permits the end > > user to dynamically associate UAs with the AOR, by providing a > > potentially recognized and trusted domain. > > > > This doesn't seem like stuff that justifies per-use > charging, and the > > amount of charging that can be extracted for these basic services is > > probably limited, but its something. > > > > If an SP wants to charge more, then they will have to provide more > > services - ones that users are interested in paying for. > > > > Paul > > > > > Cheers, > > > BobN > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, March 29, 2006 6:08 AM > > > To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; > speermint@ietf.org > > > Subject: [Speermint] Billing, Accounting, Tariffing and Charging > > > > > > > > >>>These are not rhetoric questions; I really do not know > the answer. > > > > > > > > > Welcome to the club, you are not alone ;-) > > > > > > > > >>>VoIP is exactly the opposite. VoIP (signaling and media) > are delay > > >> > > >>sensitive, need > > >> > > >>>prioritization and will be billed. > > >>> > > >> > > >>Good point. What we need is to separate the problem of > peering into at > > >>least two parts: terminating the call and the traffic itself (data > > part). > > >>The email model applies only to the termination part. > > > > > > > > > Hmmm, I think it is even more complicated. > > > > > > Terminology: > > > > > > Billing is between end-users and a SP (out of scope in spearmint) > > Accounting is between SP (in scope of spearmint?) Tariffing is the > > calculation of a charge for using a certain resource for a > certain amount > > of time. > > > > > > I consider it also paradox that we are discussing accounting and > > charging, particularly termination charges (fees) 1. in a > time even in the > > PSTN issues are moving to bill-and-keep 2. on an > inappropriate layer (L5) > > > > > > A substantial part of the problems with VoIP peering > derives not from > > trust, QoS, SPIT, etc. problems, but simply how to keep up > the existing > > regime of termination fees. > > > > > > Especially mobile operators make a living on this. > > > > > > Where is this problem coming from on the PSTN? > > > (Lets for a moment forget problems caused by reverse > > > charging) > > > > > > In the PSTN there was originally an accounting regime based on > > cascading. The O-SP bills the O-user for the call (based on > distance), and > > keeping part of it and paying out part to the next (transit) SP. > > > This goes on until the destination > > > (T-SP) is reached, which also gets a share. > > > > > > The implicit assumptions here are: the originator has the > benefit of the > > call and also call set-up is in one direction and call > signalling and the > > mediastream is traversing all networks in question. > > > > > > This principle is only broken with call forwarding and > also with mobile > > roaming. In the US also the mobile T-user pays air-time, > not so in Europe, > > hence the problems with mobile NP > > > > > > Note: in my remark to my previous post on terminating > network monopoly > > (SMP), one may consider the termination fee also as a > compensation for the > > remedy that a terminating network MUST accept any call. > > > > > > This regime was quite simple, but was more and more > complicated over > > time by burdening it with additional issues such as > subsidies, etc. as it > > is currently in the US. > > > > > > > > > What does this imply now for VoIP peering or interconnect > > > > > > VoIP; RTC and IP separate signalling (L5) from transport > (L3) It also > > separates the SP from the access Now taking into account some facts: > > > > > > 1. Although SIP signalling (call set-up) is directed from > O to T, the > > mediastream is both ways and symmetric (so much for Whitacre, he may > > eventually blame Google Video, but not VoIP providers) > > > > > > 2. The cost for the mediastream is moving more and more > to the ends > > (access), even in the PSTN (see the latest OFCOM report on distance > > gradients), and the access is already paid in some way or > the other by the > > end-users. > > > > > > 3. So why is it necessary to charge termination fees to > the O-user at > > all for SIGNALLING? > > > > > > There is one issue where termination fees may apply > (although this is > > going away also - e.g. > > > Voipbuster): if you connect to the PSTN. > > > > > > But this is out of scope in Speermint and in addition > solutions exist > > here since years. > > > > > > My recommendation is that as long as speermint is dealing with L5 > > peering only, accounting i.e. termination fees should not > be dealt with. > > > > > > Cheers > > > > > > Richard > > > > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > >>Sent: Wednesday, March 29, 2006 4:28 AM > > >>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > >>Subject: RE: [Speermint] Comments on > > >>reqs-and-terminology-01andpolicy-dds- > > >>00(Peerign concepts and others..) > > >> > > >>Hi Reinaldo, > > >> > > >> > > >>>-----Original Message----- > > >>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > > >>>Sent: Tuesday, March 28, 2006 8:31 PM > > >>>To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > > >>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > >>>andpolicy- > > >> > > >>dds-00(Peerign > > >> > > >>>concepts and others..) > > >>> > > >>>Hello, > > >>> > > >>>I tend to agree that the email model sounds attractive except the > > >>>delay > > >> > > >>and business > > >> > > >>>requirements of email and VoIP are quire different. > > >>> > > >>>Email is not delay sensitive, does not require any type of > > >> > > >>prioritization and is not charged > > >> > > >>>(or at least it wasn't). > > >>> > > >>>VoIP is exactly the opposite. VoIP (signaling and media) > are delay > > >> > > >>sensitive, need > > >> > > >>>prioritization and will be billed. > > >>> > > >> > > >>Good point. What we need is to separate the problem of > peering into at > > >>least two parts: terminating the call and the traffic itself (data > > part). > > >>The email model applies only to the termination part. > > >> > > >> > > >>>I believe a call to a public number is (or should) > always going to > > >>>be > > >> > > >>routable. I guess my > > >> > > >>>main question is: is the general belief that VoIP providers will > > >>>just > > >> > > >>configure their proxy > > >> > > >>>servers to talk to each other in an email type model? No business > > >> > > >>agreements similar to > > >> > > >>>PSTN/Wireless, no charging, no extra billing for "roaming", etc? > > >>> > > >> > > >>I agree those are issues. It would be good if we can work out > > >>something which is generic (compared to IMS/PSTN > specific). Maybe they > > >>are out of scope since we are dealing with protocol and > architecture > > >>issues in the WG. The only aspect billing and roaming > affect is that > > >>if all technical requirements (e.g the ones this WG specifies) are > > >>satisfied, the peer could still reject traffic (w/o consulting the > > >>destination user, in Richard's terms) if the commercial > relationship > > >>does not exist. I think this is what hampers connectivity > today. All > > >>these commercial relationships exist because SPs want to > be layer 5 > > >>aware (they cannot seem to find a way to evolve their > business models > > >>otherwise... :), where only the origination SP (Core-O) and Core-T > > >>need to have a commercial relationship. The roaming > aspect again may > > >>be quite artificial and could be questionable going > forward... Just my > > personal comments. > > >> > > >>-Medhavi. > > >> > > >> > > >>>My reply to David's email was more to the idea that you > can install > > >>>a > > >> > > >>proxy server > > >> > > >>>somewhere, point the "MX" to the next upstream "proxy > server" and be > > >> > > >>done with it? As > > >> > > >>>VoIP takes off wouldn't some basic regulatory issues, numbering > > >>>schemes > > >> > > >>and others > > >> > > >>>prevent such behavior? > > >>> > > >>>These are not rhetoric questions; I really do not know > the answer. > > >>> > > >>>Regards, > > >>> > > >>>Reinaldo > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > >>>>Sent: Tuesday, March 28, 2006 5:13 PM > > >>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > >>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > >> > > >>andpolicy- > > >> > > >>>>dds-00(Peerign concepts and others..) > > >>>> > > >>>> > > >>>>>It begs the question why the two entities exchanging SIP > > >>>>>signaling > > >> > > >>do > > >> > > >>>>not exchange policy > > >>>> > > >>>>>information themselves through some SIP extension/new > > >>>>>protocol/ > >>>> > > >>>>name> and the > > >>>> > > >>>>>role played by DNS. I'm not advocating this model but > it seems a > > >>>> > > >>>>pertinent question. > > >>>> > > >>>>I think peering in L3 must be basic, given how fundamental L3 is > > >>>>to > > >> > > >>the > > >> > > >>>>internet. For SIP, TRIP provides functionality similar to BGP > > >>>>(only > > >> > > >>for > > >> > > >>>>phone numbers though, I think). > > >>>> > > >>>>In my opinion, SIP peering ought to follow the email model. Once > > >> > > >>location > > >> > > >>>>is done and basic requirements are satisfied at the SIP layer > > >>>>(like identity etc), the call should be routable. As > Richard said > > >>>>in the > > >> > > >>earlier > > >> > > >>>>email, the destination SP may still reject or challenge the call > > >>>>if it lacks either the basic requirements we agree to > in the WG or > > >>>>some > > >> > > >>extra > > >> > > >>>>requirements specific to the termination SP (Core-T in > my ID). The > > >>>>challenge is that in some cases there are going to be IXPs > > >> > > >>(Interconnects) > > >> > > >>>>which sit in the middle due to commercial or regulatory reasons. > > >>>>The location of an IXP, the provisioning of this IXP and the > > >>>>Core-T SP are > > >> > > >>the > > >> > > >>>>architectural problems which this WG needs to solve as well. > > >>>> > > >>>>-Medhavi. > > >>>> > > >>>> > > >>>>>Regards, > > >>>>> > > >>>>>Reinaldo > > >>>>> > > >>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > >>>>>>Sent: Tuesday, March 28, 2006 3:18 PM > > >>>>>>To: Reinaldo Penno; speermint@ietf.org > > >>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > >>>>>>and > > >>>> > > >>>>policy- > > >>>> > > >>>>>>dds-00(Peerign concepts and others..) > > >>>>>> > > >>>>>>Hi Reinaldo > > >>>>>> > > >>>>>>I am not sure the goal of SPEERMINT is to recreate L3 peering > > >>>>>>at > > >> > > >>L5. > > >> > > >>>>The > > >>>> > > >>>>>>problem being solved is different in that L3 peering is always > > >> > > >>with a > > >> > > >>>>>>fixed number of neighbors. These are stored as you mention in > > >> > > >>static > > >> > > >>>>>>routing tables at each node and do not change from > call to call. > > >> > > >>In > > >> > > >>>>>>contrast, L5 peering is not necessarily static (unless you are > > >> > > >>talking > > >> > > >>>>>>about a federation model). The destination is chosen only when > > >>>>>>the > > >>>> > > >>>>call is > > >>>> > > >>>>>>made and may be to a peer that a given service provider/domain > > >>>>>>administrator/node has never spoken to before. > > >>>>>> > > >>>>>>Assuming DNS is used to find the peering node, the query is > > >>>>>>made > > >> > > >>on a > > >> > > >>>>call > > >>>> > > >>>>>>by call basis. Now clearly, this DNS info can be cached at the > > >>>> > > >>>>originating > > >>>> > > >>>>>>node but the cache still has a very different nature than that > > >>>>>>of > > >> > > >>an > > >> > > >>>>L3 > > >>>> > > >>>>>>routing table. > > >>>>>> > > >>>>>>Policy is an entirely different issue (as is the case in L3) > > >>>>>>and > > >> > > >>it is > > >> > > >>>>>>important to separate it out from the routing issue. The draft > > >>>>>>you > > >>>> > > >>>>mention > > >>>> > > >>>>>>about pushing policy via DNS is dealing with one out of many > > >> > > >>possible > > >> > > >>>>>>topologies - namely that of ad hoc federations. There was very > > >> > > >>little > > >> > > >>>>>>discussion about policy at IETF 65 as the foundations of L5 > > >> > > >>routing > > >> > > >>>>need > > >>>> > > >>>>>>to be cemented before the higher level policy issues can be > > >> > > >>addressed. > > >> > > >>>>>>Cheers, > > >>>>>> > > >>>>>>David > > >>>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > > >>>>>>Sent: ? 28 ??? 2006 23:34 > > >>>>>>To: speermint@ietf.org > > >>>>>>Subject: [Speermint] Comments on reqs-and-terminology-01 and > > >> > > >>policy- > > >> > > >>>>dds- > > >>>> > > >>>>>>00(Peerign concepts and others..) > > >>>>>> > > >>>>>>Hello, > > >>>>>> > > >>>>>>I've been reading "reqs and terminology" and I would like to > > >>>>>>step > > >> > > >>back > > >> > > >>>>>>and ask some questions about some of the definitions. > > >>>>>> > > >>>>>> > > >>>>>>Peering: > > >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>> > > >>>>>>In layer 3 peering two routers exchange their routing tables, > > >> > > >>reach a > > >> > > >>>>>>steady state, and after that data packets can flow between the > > >>>>>>two domains. > > >>>>>> > > >>>>>>Layer 5 peering means, "interconnection of two service > > >>>>>>providers > > >> > > >>for > > >> > > >>>>the > > >>>> > > >>>>>>purposes of SIP signaling". > > >>>>>> > > >>>>>>Making the inevitable comparison with layer 3 peering, there > > >>>>>>are > > >> > > >>some > > >> > > >>>>>>fundamental differences that I'm trying to reconcile. > > >>>>>> > > >>>>>>1) In a traditional (a.k.a. layer 3) peering, both routers > > >> > > >>exchange > > >> > > >>>>all > > >>>> > > >>>>>>necessary routing information and enter a steady state. At > > >>>>>>this > > >> > > >>point, > > >> > > >>>>>>no other routes are exchanged and routers concentrate on > > >> > > >>forwarding > > >> > > >>>>>>packets. > > >>>>>> > > >>>>>>I know the WG is in the beginning, but it is not clear to me > > >>>>>>what > > >>>> > > >>>>pieces > > >>>> > > >>>>>>are needed for an equivalent functionality. For example: > > >>>>>> > > >>>>>>1) Are the entities exchanging SIP signaling for the purpose > > >>>>>>of > > >>>> > > >>>>peering > > >>>> > > >>>>>>doing so on a _per call_ basis? Is there going to be some > > >> > > >>mechanism > > >> > > >>>>to > > >>>> > > >>>>>>exchange such information in bulk such as in a > routing protocol? > > >> > > >>Maybe > > >> > > >>>>>>based on domain names or something similar? > > >>>>>> > > >>>>>>2) The draft states that " A > > >>>>>> domain's ingress point can be thought of as the location > > >> > > >>pointed to > > >> > > >>>>>> by the SRV record that resulted from the resolution of the > > >>>>>>CRD > > >>>> > > >>>>(i.e., > > >>>> > > >>>>>> a SIP URI)." > > >>>>>> > > >>>>>>So, it seems to me that although the "layer 5 peering" is > > >> > > >>happening > > >> > > >>>>>>between the two entities exchanging SIP signaling, the peering > > >> > > >>point > > >> > > >>>>>>discovery is a result of a SRV query. But the draft also > > >>>>>>states > > >> > > >>that " > > >> > > >>>>>>SPEERMINT Working Group is focused on the use of such CRD." > > >>>>>> > > >>>>>>Draft peering-policy states that " This documents proposes the > > >>>>>>use > > >> > > >>of > > >> > > >>>>>>DNS entries to publish a SIP proxy's policy for accepting > > >>>>>>incoming calls" proposes DNS as a way of exchange polices. > > >>>>>> > > >>>>>>This begs the question of what are the two "peering" entities > > >> > > >>really > > >> > > >>>>>>doing besides exchange traditional SIP signaling? It seems the > > >> > > >>real > > >> > > >>>>>>_information peering_ (for the lack of a better term) is > > >>>>>>happening between DNS servers. All important information > > >>>>>>related to > > >> > > >>"peering" is > > >> > > >>>>>>coming from a DNS server which might as well be on your own > > >>>>>>domain > > >> > > >>(if > > >> > > >>>>>>your exchange DNS information). > > >>>>>> > > >>>>>>In summary, it seems to me the whole architecture is quite a > > >> > > >>departure > > >> > > >>>>>>from layer 3 peering where the entities peering are the > > >>>>>>holders of > > >> > > >>the > > >> > > >>>>>>necessary information to allow data packets to flow. Here the > > >> > > >>entities > > >> > > >>>>>>peering publish their peering information to third party > > >>>>>>server > > >> > > >>which > > >> > > >>>>>>does the actual "peering" (exchange inter-domain information). > > >>>>>> > > >>>>>> > > >>>>>>Anyway, the idea of the mail is to try to clarify things. > > >>>>>>There is > > >>>> > > >>>>much > > >>>> > > >>>>>>emphasis on SIP but it seems DNS plays a more central role. Or > > >> > > >>maybe > > >> > > >>>>>>some SIP extension will be made to exchange peering policies? > > >>>>>> > > >>>>>> > > >>>>>>Policies and Independence of lower layers: > > = >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>> > > >>>>>>It seems sections 5.5 and 5.6 are _somewhat_ conflicting. > > >>>>>>Today > > >> > > >>BGP > > >> > > >>>>>>exchange QoS and VPN information, performs discovery, etc. > > >>>>>>This > > >>>> > > >>>>implies > > >>>> > > >>>>>>that BGP indirectly (or directly) knows the capabilities of > > >>>>>>the transport layer (thus the name capability negotiation). > > >>>>>> > > >>>>>>So, although the mechanism to exchange the actual policies > > >>>>>>needs > > >> > > >>to be > > >> > > >>>>>>independent of the lower layers, there needs to be a way to > > >>>>>>input > > >>>> > > >>>>lower > > >>>> > > >>>>>>layer information into the devices exchanging the policies. > > >>>>>>Just > > >> > > >>like > > >> > > >>>>>>BGP has filters and priorities based on a myriad of options. > > >>>>>>So, > > >> > > >>maybe > > >> > > >>>>>>the wording should change a little. > > >>>>>> > > >>>>>>As far as 5.6 goes, it seems to me the policies can be quite > > >> > > >>complex. > > >> > > >>>>>>The experience of BGP tells us that in the end policies can be > > >> > > >>huge. > > >> > > >>>>So, > > >>>> > > >>>>>>if policies are going to be huge, what draft dds-00 states as > > >>>>>>a possibility > > >>>>>> > > >>>>>>" If the simple boolean logic and the limited space in the DNS > > >> > > >>answers > > >> > > >>>>>> are insufficient for an application then a type of policy > > >>>>>>rule > > >> > > >>URIs > > >> > > >>>>>> can be defined which links to policy statements written in > > >>>>>>a > > >> > > >>fully > > >> > > >>>>>> featured policy description language like SAML [14] or > > >>>>>>XACML > > >> > > >>[15]." > > >> > > >>>>>>will actually going to be the rule. So, this begs the question > > >>>>>>of > > >> > > >>DNS > > >> > > >>>>is > > >>>> > > >>>>>>a good choice to publish peering policies. > > >>>>>> > > >>>>>>Thanks, > > >>>>>> > > >>>>>>Reinaldo > > >>>>>> > > >>>>>>_______________________________________________ > > >>>>>>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 > > >>>>> > > >>>>>-- > > >>>>>No virus found in this incoming message. > > >>>>>Checked by AVG Free Edition. > > >>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > >> > > >>3/24/2006 > > >> > > >>>-- > > >>>No virus found in this incoming message. > > >>>Checked by AVG Free Edition. > > >>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > >>>3/24/2006 > > >>> > > >> > > >>_______________________________________________ > > >>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 > > > > > > _______________________________________________ > > > 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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 05:36:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuVU-0004eJ-Su; Thu, 30 Mar 2006 05:36:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuVT-0004cS-P8 for speermint@ietf.org; Thu, 30 Mar 2006 05:35:59 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOuVT-0004TQ-AG for speermint@ietf.org; Thu, 30 Mar 2006 05:35:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Definition of "Peering" Date: Thu, 30 Mar 2006 12:40:00 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4947@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZT2qM6Y8lESw/uQh+uFvA5M05nOAAB4E1C From: "Stastny Richard" To: "Otmar Lendl" , "Reinaldo Penno" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: speermint@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, =20 your definition of SIP peering (or is it more a definition of the scope of SPEERMINT?) seems to be at least a basis for discussion. =20 But it implies that it is valid only for (or SPEERMINT is=20 dealing only with) additional L3 peerings - this will Keith make happy = ;-) =20 I have only a problem with this: =20 >I don't think we should care whether the default interconnection >mechanism is SIP according to RFC3261, the PSTN, SIP via >a transit network, or simply no default interconnection at all. =20 As you point out in (have I now to say direct) L3 peering, there is always a default connection. =20 In SPEERMINT this could only be RFC3261/3263, and it cannot be the PSTN (Speermint is not dealing with E.164 numbers) =20 And having no default is also not a good idea. =20 Richard ________________________________ Von: Otmar Lendl [mailto:lendl@nic.at] Gesendet: Do 30.03.2006 11:12 An: Reinaldo Penno Cc: speermint@ietf.org Betreff: [Speermint] Definition of "Peering" On 2006/03/28 23:03, Reinaldo Penno wrote: > Hello, > > I've been reading "reqs and terminology" and I would like to step back > and ask some questions about some of the definitions. Good idea. Here is my answer. > Peering: > =3D=3D=3D=3D=3D=3D=3D=3D > > In layer 3 peering two routers exchange their routing tables, reach a > steady state, and after that data packets can flow between the two > domains. I think this definition is too broad: it applies to any BGP connection. A Layer 3 peering is a shortcut connection established to avoid sending the traffic via the default upstream networks. Such a direct connection saves money (upstream is more expensive) and improves the network performance. L3 peering is not about reachability per se. For that, one single interconnect to an upstream networks suffices. I'll use the term "interconnection" below in a very generic sense, and not in the one used in the PSTN world. I'm very much open to alternative wordings. So what about: ----- SIP Peering is the establishement of an alternative communication path between the SIP elements of two entities (service providers, corporations, ...) to improve over the service offered by the default interconnection. The improvements offered by this new path can include (but are not limited to) * better QoS * cost benefits (e.g. if the default path is billed by minute) * additional features (e.g. wideband codecs or IM) * abuse handling. The default interconnection between two parties is out of scope for the Speermint WG. ----- I don't think we should care whether the default interconnection mechanism is SIP according to RFC3261, the PSTN, SIP via a transit network, or simply no default interconnection at all. All we need to focus on here in Speermint is to define a framework which can be used to establish more direct and thus better crosslinks between two SIP service providers. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 Thu Mar 30 08:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOxZ8-0001wW-5t; Thu, 30 Mar 2006 08:51:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOxZ6-0001un-91 for speermint@ietf.org; Thu, 30 Mar 2006 08:51:56 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOxZ3-0004OC-PL for speermint@ietf.org; Thu, 30 Mar 2006 08:51:56 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2006 08:51:54 -0500 X-IronPort-AV: i="4.03,146,1141621200"; d="scan'208"; a="85326843:sNHT32440864" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2UDprWc025414; Thu, 30 Mar 2006 08:51:53 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 08:51:53 -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] Definition of "Peering" Date: Thu, 30 Mar 2006 08:51:52 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30143A7AB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZT2i+n4mwyY1O9TFugY0DJOby/fQAJdLPw From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , "Reinaldo Penno" X-OriginalArrivalTime: 30 Mar 2006 13:51:53.0079 (UTC) FILETIME=[19C6B070:01C65401] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: speermint@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 Otmar, While default paths may be a good idea, that is an implementation detail that should not be the focus of such definitions. SIP Peering is the enablement of direct connection between SIP providers offering essential experience-enhancing services, without the need to resort to transit middlemen providing solely route discovery. Your list of QoS, cost, features, security are examples of useful criteria to identify value-added. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Thursday, March 30, 2006 4:12 AM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: [Speermint] Definition of "Peering" >=20 > On 2006/03/28 23:03, Reinaldo Penno wrote: > > Hello, > >=20 > > I've been reading "reqs and terminology" and I would like=20 > to step back=20 > > and ask some questions about some of the definitions. >=20 > Good idea. Here is my answer. >=20 > > Peering: > > =3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > In layer 3 peering two routers exchange their routing=20 > tables, reach a=20 > > steady state, and after that data packets can flow between the two=20 > > domains. >=20 > I think this definition is too broad: it applies to any BGP=20 > connection. >=20 > A Layer 3 peering is a shortcut connection established to=20 > avoid sending the traffic via the default upstream networks.=20 > Such a direct connection saves money (upstream is more=20 > expensive) and improves the network performance. >=20 > L3 peering is not about reachability per se. For that, one=20 > single interconnect to an upstream networks suffices. >=20 > I'll use the term "interconnection" below in a very generic=20 > sense, and not in the one used in the PSTN world. I'm very=20 > much open to alternative wordings. >=20 > So what about: >=20 > ----- > SIP Peering is the establishement of an alternative=20 > communication path between the SIP elements of two entities=20 > (service providers, corporations, ...) to improve over the=20 > service offered by the default interconnection. The=20 > improvements offered by this new path can include (but are=20 > not limited to) > * better QoS > * cost benefits (e.g. if the default path is billed by minute) > * additional features (e.g. wideband codecs or IM) > * abuse handling. >=20 > The default interconnection between two parties is out of=20 > scope for the Speermint WG.=20 > ----- >=20 > I don't think we should care whether the default=20 > interconnection mechanism is SIP according to RFC3261, the=20 > PSTN, SIP via a transit network, or simply no default=20 > interconnection at all. >=20 > All we need to focus on here in Speermint is to define a=20 > framework which can be used to establish more direct and thus=20 > better crosslinks between two SIP service providers. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=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 Thu Mar 30 09:31:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyB2-0007oA-Bx; Thu, 30 Mar 2006 09:31:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyB0-0007nT-QS for speermint@ietf.org; Thu, 30 Mar 2006 09:31:06 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOy8z-00078k-Jd for speermint@ietf.org; Thu, 30 Mar 2006 09:29:02 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id C92BF1A3A4; Thu, 30 Mar 2006 16:28:59 +0200 (CEST) Date: Thu, 30 Mar 2006 16:28:59 +0200 From: Otmar Lendl To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Definition of "Peering" Message-ID: <20060330142859.GD28504@nic.at> Mail-Followup-To: Otmar Lendl , "Michael Hammer (mhammer)" , Reinaldo Penno , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E30143A7AB@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30143A7AB@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: speermint@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 2006/03/30 15:03, "Michael Hammer (mhammer)" wrote: > > SIP Peering is the enablement of direct connection between SIP providers > offering essential experience-enhancing services, without the need to > resort to transit middlemen providing solely route discovery. Michael, So in the absence of an established SIP Peering: can users of SIP provider A call customers of SIP provider B? If yes, how is that achieved? ----------- I have the feeling that the members of this WG doesn't agree on what the status quo is. No wonder that we have difficulties to agree on what problem Speermint is supposed to solve. /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 Thu Mar 30 10:06:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyjN-0003py-FD; Thu, 30 Mar 2006 10:06:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyjM-0003o9-Dy for speermint@ietf.org; Thu, 30 Mar 2006 10:06:36 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOyjL-0000J2-Kf for speermint@ietf.org; Thu, 30 Mar 2006 10:06:36 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2006 10:06:36 -0500 X-IronPort-AV: i="4.03,147,1141621200"; d="scan'208"; a="85333790:sNHT41977032" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2UF6YWc011090; Thu, 30 Mar 2006 10:06:35 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 10:06:34 -0500 Received: from [161.44.79.176] ([161.44.79.176]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 10:06:34 -0500 Message-ID: <442BF3F9.9090603@cisco.com> Date: Thu, 30 Mar 2006 10:06:33 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging References: <475FF955A05DD411980D00508B6D5FB01274969E@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB01274969E@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Mar 2006 15:06:34.0114 (UTC) FILETIME=[88AE5E20:01C6540B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c48eeb61c971c85fb2ddea78b04c1c76 Cc: 'Stastny Richard' , "'speermint@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 Drage, Keith (Keith) wrote: > I am sure we could get into all sorts of philosophical discussions on this, but let's just postulate one question: > > How much of the items you spend money on in a year are actually based on the cost of providing the service, and how much is based on what the market will bear? > > And I don't see it being any different for most ISPs either. > > But anyway surely those issues are irrelevant for SPEERMINT. Yeah, its probably off topic. > What SPEERMINT needs to deal with is how each operator accounts to another operator for the traffic that one delivers to the other. In 3GPP that is dealt with primarily by the exchange of IOI parameters over SIP. At the SIP level the account is not exchanged between operators, merely an indicator of the operator that the traffic has been passed to. What constitutes the delivery of traffic from one operator to another? Consider Richard's example. (The one where he and his friend are in a hotel in NY.) What traffic is Richard's operator delivering to his friend's operator? Paul > regards > > Keith > > >>-----Original Message----- >>From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>Sent: 29 March 2006 15:05 >>To: Paul Kyzivat; Bob Natale >>Cc: speermint@ietf.org >>Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging >> >> >>Exactly >> >>Richard >> >> >>>-----Original Message----- >>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>Sent: Wednesday, March 29, 2006 3:58 PM >>>To: Bob Natale >>>Cc: Stastny Richard; speermint@ietf.org >>>Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging >>> >>> >>> >>>Bob Natale wrote: >>> >>>>Hi Richard, >>>> >>>>1. Your point about the possible relevance for >> >>SPEERMINT's scope of >> >>>accounting requirements, and not billing requirements, is >> >>well-taken and >> >>>will be reflected clearly in the next rev of the >> >>Requirements BCP draft. >> >>>>2. Wrt your comment: "3. So why is it necessary to >> >>charge termination >> >>>fees to the O-user at all for SIGNALLING?": >>> >>>>Might it not be true that some applications of value to >> >>the user might >> >>>involve signaling only, and not media per se? (I am >> >>thinking of certain >> >>>presence and notification apps...?) >>> >>>What does that change? >>> >>>IMO it makes sense to charge for services actually >> >>rendered, and not for >> >>>services the SP isn't involved in but wishes they could get >> >>some revenue >> >>>from. >>> >>>The terminating proxy does render some identifiable >> >>services that could >> >>>potentially be charged for: >>>- supplying the AOR >>>- processing (routing) requests to the AOR >>> >>>These are of value precisely because they eliminate the >> >>need for the end >> >>>user to keep a UA online at all times, and because it >> >>permits the end >> >>>user to dynamically associate UAs with the AOR, by providing a >>>potentially recognized and trusted domain. >>> >>>This doesn't seem like stuff that justifies per-use >> >>charging, and the >> >>>amount of charging that can be extracted for these basic services is >>>probably limited, but its something. >>> >>>If an SP wants to charge more, then they will have to provide more >>>services - ones that users are interested in paying for. >>> >>> Paul >>> >>> >>>>Cheers, >>>>BobN >>>> >>>>-----Original Message----- >>>>From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>>Sent: Wednesday, March 29, 2006 6:08 AM >>>>To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; >> >>speermint@ietf.org >> >>>>Subject: [Speermint] Billing, Accounting, Tariffing and Charging >>>> >>>> >>>> >>>>>>These are not rhetoric questions; I really do not know >> >>the answer. >> >>>> >>>>Welcome to the club, you are not alone ;-) >>>> >>>> >>>> >>>>>>VoIP is exactly the opposite. VoIP (signaling and media) >> >>are delay >> >>>>>sensitive, need >>>>> >>>>> >>>>>>prioritization and will be billed. >>>>>> >>>>> >>>>>Good point. What we need is to separate the problem of >> >>peering into at >> >>>>>least two parts: terminating the call and the traffic itself (data >>> >>>part). >>> >>>>>The email model applies only to the termination part. >>>> >>>> >>>>Hmmm, I think it is even more complicated. >>>> >>>>Terminology: >>>> >>>>Billing is between end-users and a SP (out of scope in spearmint) >>> >>>Accounting is between SP (in scope of spearmint?) Tariffing is the >>>calculation of a charge for using a certain resource for a >> >>certain amount >> >>>of time. >>> >>>>I consider it also paradox that we are discussing accounting and >>> >>>charging, particularly termination charges (fees) 1. in a >> >>time even in the >> >>>PSTN issues are moving to bill-and-keep 2. on an >> >>inappropriate layer (L5) >> >>>>A substantial part of the problems with VoIP peering >> >>derives not from >> >>>trust, QoS, SPIT, etc. problems, but simply how to keep up >> >>the existing >> >>>regime of termination fees. >>> >>>>Especially mobile operators make a living on this. >>>> >>>>Where is this problem coming from on the PSTN? >>>>(Lets for a moment forget problems caused by reverse >>>>charging) >>>> >>>>In the PSTN there was originally an accounting regime based on >>> >>>cascading. The O-SP bills the O-user for the call (based on >> >>distance), and >> >>>keeping part of it and paying out part to the next (transit) SP. >>> >>>>This goes on until the destination >>>>(T-SP) is reached, which also gets a share. >>>> >>>>The implicit assumptions here are: the originator has the >> >>benefit of the >> >>>call and also call set-up is in one direction and call >> >>signalling and the >> >>>mediastream is traversing all networks in question. >>> >>>>This principle is only broken with call forwarding and >> >>also with mobile >> >>>roaming. In the US also the mobile T-user pays air-time, >> >>not so in Europe, >> >>>hence the problems with mobile NP >>> >>>>Note: in my remark to my previous post on terminating >> >>network monopoly >> >>>(SMP), one may consider the termination fee also as a >> >>compensation for the >> >>>remedy that a terminating network MUST accept any call. >>> >>>>This regime was quite simple, but was more and more >> >>complicated over >> >>>time by burdening it with additional issues such as >> >>subsidies, etc. as it >> >>>is currently in the US. >>> >>>> >>>>What does this imply now for VoIP peering or interconnect >>>> >>>>VoIP; RTC and IP separate signalling (L5) from transport >> >>(L3) It also >> >>>separates the SP from the access Now taking into account some facts: >>> >>>>1. Although SIP signalling (call set-up) is directed from >> >>O to T, the >> >>>mediastream is both ways and symmetric (so much for Whitacre, he may >>>eventually blame Google Video, but not VoIP providers) >>> >>>>2. The cost for the mediastream is moving more and more >> >>to the ends >> >>>(access), even in the PSTN (see the latest OFCOM report on distance >>>gradients), and the access is already paid in some way or >> >>the other by the >> >>>end-users. >>> >>>>3. So why is it necessary to charge termination fees to >> >>the O-user at >> >>>all for SIGNALLING? >>> >>>>There is one issue where termination fees may apply >> >>(although this is >> >>>going away also - e.g. >>> >>>>Voipbuster): if you connect to the PSTN. >>>> >>>>But this is out of scope in Speermint and in addition >> >>solutions exist >> >>>here since years. >>> >>>>My recommendation is that as long as speermint is dealing with L5 >>> >>>peering only, accounting i.e. termination fees should not >> >>be dealt with. >> >>>>Cheers >>>> >>>>Richard >>>> >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] >>>>>Sent: Wednesday, March 29, 2006 4:28 AM >>>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org >>>>>Subject: RE: [Speermint] Comments on >>>>>reqs-and-terminology-01andpolicy-dds- >>>>>00(Peerign concepts and others..) >>>>> >>>>>Hi Reinaldo, >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>>>Sent: Tuesday, March 28, 2006 8:31 PM >>>>>>To: Medhavi Bhatia; David Schwartz; speermint@ietf.org >>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 >>>>>>andpolicy- >>>>> >>>>>dds-00(Peerign >>>>> >>>>> >>>>>>concepts and others..) >>>>>> >>>>>>Hello, >>>>>> >>>>>>I tend to agree that the email model sounds attractive except the >>>>>>delay >>>>> >>>>>and business >>>>> >>>>> >>>>>>requirements of email and VoIP are quire different. >>>>>> >>>>>>Email is not delay sensitive, does not require any type of >>>>> >>>>>prioritization and is not charged >>>>> >>>>> >>>>>>(or at least it wasn't). >>>>>> >>>>>>VoIP is exactly the opposite. VoIP (signaling and media) >> >>are delay >> >>>>>sensitive, need >>>>> >>>>> >>>>>>prioritization and will be billed. >>>>>> >>>>> >>>>>Good point. What we need is to separate the problem of >> >>peering into at >> >>>>>least two parts: terminating the call and the traffic itself (data >>> >>>part). >>> >>>>>The email model applies only to the termination part. >>>>> >>>>> >>>>> >>>>>>I believe a call to a public number is (or should) >> >>always going to >> >>>>>>be >>>>> >>>>>routable. I guess my >>>>> >>>>> >>>>>>main question is: is the general belief that VoIP providers will >>>>>>just >>>>> >>>>>configure their proxy >>>>> >>>>> >>>>>>servers to talk to each other in an email type model? No business >>>>> >>>>>agreements similar to >>>>> >>>>> >>>>>>PSTN/Wireless, no charging, no extra billing for "roaming", etc? >>>>>> >>>>> >>>>>I agree those are issues. It would be good if we can work out >>>>>something which is generic (compared to IMS/PSTN >> >>specific). Maybe they >> >>>>>are out of scope since we are dealing with protocol and >> >>architecture >> >>>>>issues in the WG. The only aspect billing and roaming >> >>affect is that >> >>>>>if all technical requirements (e.g the ones this WG specifies) are >>>>>satisfied, the peer could still reject traffic (w/o consulting the >>>>>destination user, in Richard's terms) if the commercial >> >>relationship >> >>>>>does not exist. I think this is what hampers connectivity >> >>today. All >> >>>>>these commercial relationships exist because SPs want to >> >>be layer 5 >> >>>>>aware (they cannot seem to find a way to evolve their >> >>business models >> >>>>>otherwise... :), where only the origination SP (Core-O) and Core-T >>>>>need to have a commercial relationship. The roaming >> >>aspect again may >> >>>>>be quite artificial and could be questionable going >> >>forward... Just my >> >>>personal comments. >>> >>>>>-Medhavi. >>>>> >>>>> >>>>> >>>>>>My reply to David's email was more to the idea that you >> >>can install >> >>>>>>a >>>>> >>>>>proxy server >>>>> >>>>> >>>>>>somewhere, point the "MX" to the next upstream "proxy >> >>server" and be >> >>>>>done with it? As >>>>> >>>>> >>>>>>VoIP takes off wouldn't some basic regulatory issues, numbering >>>>>>schemes >>>>> >>>>>and others >>>>> >>>>> >>>>>>prevent such behavior? >>>>>> >>>>>>These are not rhetoric questions; I really do not know >> >>the answer. >> >>>>>>Regards, >>>>>> >>>>>>Reinaldo >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] >>>>>>>Sent: Tuesday, March 28, 2006 5:13 PM >>>>>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org >>>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 >>>>> >>>>>andpolicy- >>>>> >>>>> >>>>>>>dds-00(Peerign concepts and others..) >>>>>>> >>>>>>> >>>>>>> >>>>>>>>It begs the question why the two entities exchanging SIP >>>>>>>>signaling >>>>> >>>>>do >>>>> >>>>> >>>>>>>not exchange policy >>>>>>> >>>>>>> >>>>>>>>information themselves through some SIP extension/new >>>>>>>>protocol/>>>>>> >>>>>>>name> and the >>>>>>> >>>>>>> >>>>>>>>role played by DNS. I'm not advocating this model but >> >>it seems a >> >>>>>>>pertinent question. >>>>>>> >>>>>>>I think peering in L3 must be basic, given how fundamental L3 is >>>>>>>to >>>>> >>>>>the >>>>> >>>>> >>>>>>>internet. For SIP, TRIP provides functionality similar to BGP >>>>>>>(only >>>>> >>>>>for >>>>> >>>>> >>>>>>>phone numbers though, I think). >>>>>>> >>>>>>>In my opinion, SIP peering ought to follow the email model. Once >>>>> >>>>>location >>>>> >>>>> >>>>>>>is done and basic requirements are satisfied at the SIP layer >>>>>>>(like identity etc), the call should be routable. As >> >>Richard said >> >>>>>>>in the >>>>> >>>>>earlier >>>>> >>>>> >>>>>>>email, the destination SP may still reject or challenge the call >>>>>>>if it lacks either the basic requirements we agree to >> >>in the WG or >> >>>>>>>some >>>>> >>>>>extra >>>>> >>>>> >>>>>>>requirements specific to the termination SP (Core-T in >> >>my ID). The >> >>>>>>>challenge is that in some cases there are going to be IXPs >>>>> >>>>>(Interconnects) >>>>> >>>>> >>>>>>>which sit in the middle due to commercial or regulatory reasons. >>>>>>>The location of an IXP, the provisioning of this IXP and the >>>>>>>Core-T SP are >>>>> >>>>>the >>>>> >>>>> >>>>>>>architectural problems which this WG needs to solve as well. >>>>>>> >>>>>>>-Medhavi. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Regards, >>>>>>>> >>>>>>>>Reinaldo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: David Schwartz [mailto:David.Schwartz@Kayote.com] >>>>>>>>>Sent: Tuesday, March 28, 2006 3:18 PM >>>>>>>>>To: Reinaldo Penno; speermint@ietf.org >>>>>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 >>>>>>>>>and >>>>>>> >>>>>>>policy- >>>>>>> >>>>>>> >>>>>>>>>dds-00(Peerign concepts and others..) >>>>>>>>> >>>>>>>>>Hi Reinaldo >>>>>>>>> >>>>>>>>>I am not sure the goal of SPEERMINT is to recreate L3 peering >>>>>>>>>at >>>>> >>>>>L5. >>>>> >>>>> >>>>>>>The >>>>>>> >>>>>>> >>>>>>>>>problem being solved is different in that L3 peering is always >>>>> >>>>>with a >>>>> >>>>> >>>>>>>>>fixed number of neighbors. These are stored as you mention in >>>>> >>>>>static >>>>> >>>>> >>>>>>>>>routing tables at each node and do not change from >> >>call to call. >> >>>>>In >>>>> >>>>> >>>>>>>>>contrast, L5 peering is not necessarily static (unless you are >>>>> >>>>>talking >>>>> >>>>> >>>>>>>>>about a federation model). The destination is chosen only when >>>>>>>>>the >>>>>>> >>>>>>>call is >>>>>>> >>>>>>> >>>>>>>>>made and may be to a peer that a given service provider/domain >>>>>>>>>administrator/node has never spoken to before. >>>>>>>>> >>>>>>>>>Assuming DNS is used to find the peering node, the query is >>>>>>>>>made >>>>> >>>>>on a >>>>> >>>>> >>>>>>>call >>>>>>> >>>>>>> >>>>>>>>>by call basis. Now clearly, this DNS info can be cached at the >>>>>>> >>>>>>>originating >>>>>>> >>>>>>> >>>>>>>>>node but the cache still has a very different nature than that >>>>>>>>>of >>>>> >>>>>an >>>>> >>>>> >>>>>>>L3 >>>>>>> >>>>>>> >>>>>>>>>routing table. >>>>>>>>> >>>>>>>>>Policy is an entirely different issue (as is the case in L3) >>>>>>>>>and >>>>> >>>>>it is >>>>> >>>>> >>>>>>>>>important to separate it out from the routing issue. The draft >>>>>>>>>you >>>>>>> >>>>>>>mention >>>>>>> >>>>>>> >>>>>>>>>about pushing policy via DNS is dealing with one out of many >>>>> >>>>>possible >>>>> >>>>> >>>>>>>>>topologies - namely that of ad hoc federations. There was very >>>>> >>>>>little >>>>> >>>>> >>>>>>>>>discussion about policy at IETF 65 as the foundations of L5 >>>>> >>>>>routing >>>>> >>>>> >>>>>>>need >>>>>>> >>>>>>> >>>>>>>>>to be cemented before the higher level policy issues can be >>>>> >>>>>addressed. >>>>> >>>>> >>>>>>>>>Cheers, >>>>>>>>> >>>>>>>>>David >>>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>>>>>>Sent: â 28 îøõ 2006 23:34 >>>>>>>>>To: speermint@ietf.org >>>>>>>>>Subject: [Speermint] Comments on reqs-and-terminology-01 and >>>>> >>>>>policy- >>>>> >>>>> >>>>>>>dds- >>>>>>> >>>>>>> >>>>>>>>>00(Peerign concepts and others..) >>>>>>>>> >>>>>>>>>Hello, >>>>>>>>> >>>>>>>>>I've been reading "reqs and terminology" and I would like to >>>>>>>>>step >>>>> >>>>>back >>>>> >>>>> >>>>>>>>>and ask some questions about some of the definitions. >>>>>>>>> >>>>>>>>> >>>>>>>>>Peering: >>>>>>>>>======== >>>>>>>>> >>>>>>>>>In layer 3 peering two routers exchange their routing tables, >>>>> >>>>>reach a >>>>> >>>>> >>>>>>>>>steady state, and after that data packets can flow between the >>>>>>>>>two domains. >>>>>>>>> >>>>>>>>>Layer 5 peering means, "interconnection of two service >>>>>>>>>providers >>>>> >>>>>for >>>>> >>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>>purposes of SIP signaling". >>>>>>>>> >>>>>>>>>Making the inevitable comparison with layer 3 peering, there >>>>>>>>>are >>>>> >>>>>some >>>>> >>>>> >>>>>>>>>fundamental differences that I'm trying to reconcile. >>>>>>>>> >>>>>>>>>1) In a traditional (a.k.a. layer 3) peering, both routers >>>>> >>>>>exchange >>>>> >>>>> >>>>>>>all >>>>>>> >>>>>>> >>>>>>>>>necessary routing information and enter a steady state. At >>>>>>>>>this >>>>> >>>>>point, >>>>> >>>>> >>>>>>>>>no other routes are exchanged and routers concentrate on >>>>> >>>>>forwarding >>>>> >>>>> >>>>>>>>>packets. >>>>>>>>> >>>>>>>>>I know the WG is in the beginning, but it is not clear to me >>>>>>>>>what >>>>>>> >>>>>>>pieces >>>>>>> >>>>>>> >>>>>>>>>are needed for an equivalent functionality. For example: >>>>>>>>> >>>>>>>>>1) Are the entities exchanging SIP signaling for the purpose >>>>>>>>>of >>>>>>> >>>>>>>peering >>>>>>> >>>>>>> >>>>>>>>>doing so on a _per call_ basis? Is there going to be some >>>>> >>>>>mechanism >>>>> >>>>> >>>>>>>to >>>>>>> >>>>>>> >>>>>>>>>exchange such information in bulk such as in a >> >>routing protocol? >> >>>>>Maybe >>>>> >>>>> >>>>>>>>>based on domain names or something similar? >>>>>>>>> >>>>>>>>>2) The draft states that " A >>>>>>>>> domain's ingress point can be thought of as the location >>>>> >>>>>pointed to >>>>> >>>>> >>>>>>>>> by the SRV record that resulted from the resolution of the >>>>>>>>>CRD >>>>>>> >>>>>>>(i.e., >>>>>>> >>>>>>> >>>>>>>>> a SIP URI)." >>>>>>>>> >>>>>>>>>So, it seems to me that although the "layer 5 peering" is >>>>> >>>>>happening >>>>> >>>>> >>>>>>>>>between the two entities exchanging SIP signaling, the peering >>>>> >>>>>point >>>>> >>>>> >>>>>>>>>discovery is a result of a SRV query. But the draft also >>>>>>>>>states >>>>> >>>>>that " >>>>> >>>>> >>>>>>>>>SPEERMINT Working Group is focused on the use of such CRD." >>>>>>>>> >>>>>>>>>Draft peering-policy states that " This documents proposes the >>>>>>>>>use >>>>> >>>>>of >>>>> >>>>> >>>>>>>>>DNS entries to publish a SIP proxy's policy for accepting >>>>>>>>>incoming calls" proposes DNS as a way of exchange polices. >>>>>>>>> >>>>>>>>>This begs the question of what are the two "peering" entities >>>>> >>>>>really >>>>> >>>>> >>>>>>>>>doing besides exchange traditional SIP signaling? It seems the >>>>> >>>>>real >>>>> >>>>> >>>>>>>>>_information peering_ (for the lack of a better term) is >>>>>>>>>happening between DNS servers. All important information >>>>>>>>>related to >>>>> >>>>>"peering" is >>>>> >>>>> >>>>>>>>>coming from a DNS server which might as well be on your own >>>>>>>>>domain >>>>> >>>>>(if >>>>> >>>>> >>>>>>>>>your exchange DNS information). >>>>>>>>> >>>>>>>>>In summary, it seems to me the whole architecture is quite a >>>>> >>>>>departure >>>>> >>>>> >>>>>>>>>from layer 3 peering where the entities peering are the >>>>>>>> >>>>>>>>>holders of >>>>> >>>>>the >>>>> >>>>> >>>>>>>>>necessary information to allow data packets to flow. Here the >>>>> >>>>>entities >>>>> >>>>> >>>>>>>>>peering publish their peering information to third party >>>>>>>>>server >>>>> >>>>>which >>>>> >>>>> >>>>>>>>>does the actual "peering" (exchange inter-domain information). >>>>>>>>> >>>>>>>>> >>>>>>>>>Anyway, the idea of the mail is to try to clarify things. >>>>>>>>>There is >>>>>>> >>>>>>>much >>>>>>> >>>>>>> >>>>>>>>>emphasis on SIP but it seems DNS plays a more central role. Or >>>>> >>>>>maybe >>>>> >>>>> >>>>>>>>>some SIP extension will be made to exchange peering policies? >>>>>>>>> >>>>>>>>> >>>>>>>>>Policies and Independence of lower layers: >>>>>>>>>========================================== >>>>>>>>> >>>>>>>>>It seems sections 5.5 and 5.6 are _somewhat_ conflicting. >>>>>>>>>Today >>>>> >>>>>BGP >>>>> >>>>> >>>>>>>>>exchange QoS and VPN information, performs discovery, etc. >>>>>>>>>This >>>>>>> >>>>>>>implies >>>>>>> >>>>>>> >>>>>>>>>that BGP indirectly (or directly) knows the capabilities of >>>>>>>>>the transport layer (thus the name capability negotiation). >>>>>>>>> >>>>>>>>>So, although the mechanism to exchange the actual policies >>>>>>>>>needs >>>>> >>>>>to be >>>>> >>>>> >>>>>>>>>independent of the lower layers, there needs to be a way to >>>>>>>>>input >>>>>>> >>>>>>>lower >>>>>>> >>>>>>> >>>>>>>>>layer information into the devices exchanging the policies. >>>>>>>>>Just >>>>> >>>>>like >>>>> >>>>> >>>>>>>>>BGP has filters and priorities based on a myriad of options. >>>>>>>>>So, >>>>> >>>>>maybe >>>>> >>>>> >>>>>>>>>the wording should change a little. >>>>>>>>> >>>>>>>>>As far as 5.6 goes, it seems to me the policies can be quite >>>>> >>>>>complex. >>>>> >>>>> >>>>>>>>>The experience of BGP tells us that in the end policies can be >>>>> >>>>>huge. >>>>> >>>>> >>>>>>>So, >>>>>>> >>>>>>> >>>>>>>>>if policies are going to be huge, what draft dds-00 states as >>>>>>>>>a possibility >>>>>>>>> >>>>>>>>>" If the simple boolean logic and the limited space in the DNS >>>>> >>>>>answers >>>>> >>>>> >>>>>>>>> are insufficient for an application then a type of policy >>>>>>>>>rule >>>>> >>>>>URIs >>>>> >>>>> >>>>>>>>> can be defined which links to policy statements written in >>>>>>>>>a >>>>> >>>>>fully >>>>> >>>>> >>>>>>>>> featured policy description language like SAML [14] or >>>>>>>>>XACML >>>>> >>>>>[15]." >>>>> >>>>> >>>>>>>>>will actually going to be the rule. So, this begs the question >>>>>>>>>of >>>>> >>>>>DNS >>>>> >>>>> >>>>>>>is >>>>>>> >>>>>>> >>>>>>>>>a good choice to publish peering policies. >>>>>>>>> >>>>>>>>>Thanks, >>>>>>>>> >>>>>>>>>Reinaldo >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>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 >>>>>>>> >>>>>>>>-- >>>>>>>>No virus found in this incoming message. >>>>>>>>Checked by AVG Free Edition. >>>>>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: >>>>> >>>>>3/24/2006 >>>>> >>>>> >>>>>>-- >>>>>>No virus found in this incoming message. >>>>>>Checked by AVG Free Edition. >>>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: >>>>>>3/24/2006 >>>>>> >>>>> >>>>>_______________________________________________ >>>>>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 >>>> >>>>_______________________________________________ >>>>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 >> > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 10:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOzOL-0007GS-PO; Thu, 30 Mar 2006 10:48:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOzOK-0007GN-Hg for speermint@ietf.org; Thu, 30 Mar 2006 10:48:56 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOzOI-0002S3-7P for speermint@ietf.org; Thu, 30 Mar 2006 10:48:56 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id ADDC02A8; Thu, 30 Mar 2006 10:48:44 -0500 From: "Hadriel Kaplan" To: , "'Otmar Lendl'" , "'Stastny Richard'" Subject: RE: [Speermint] Comments onreqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..) Date: Thu, 30 Mar 2006 10:48:52 -0500 Message-ID: <037101c65411$71f47060$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1A= In-Reply-To: <200603300318.k2U3IFpa004273@leka.oceanic.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: speermint@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 Henry, Comments inline... > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Wednesday, March 29, 2006 10:18 PM > To: 'Otmar Lendl'; 'Stastny Richard' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Comments onreqs-and-terminology-01andpolicy-dds- > 00(Peerign concepts and others..) > > Otmar, > > I believe you have nailed it right on target: > > >The problem isn't that any of those service providers isn't connected to > >the Internet, the problem is that they refuse to use their Internet > >connection (or even a private IP link) for VoIP interconnection with > other > >server providers. > > If this is so, why should the IETF bother with this problem? Well, for one, because it's not true, as I think you know. VoIP Peering happens all over the place today. Even over the public Internet. But it is an excellent question, and I think we need to determine the answer as soon as possible, to save time and energy if it is not appropriate for the IETF; or to focus on what aspects are appropriate, and do the work. I believe there is no point in working on something if service providers won't use it, or the IESG won't approve it, or other members of the IETF community harass us. ;) But I think we need to at least get terminology done so we can talk the same language, and get some base requirements identified - so we can all figure out the answer to your question. I'm fairly confident we'll end up with something relevant to providers _and_ acceptable to the IETF to specify. Cheers, Hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 11:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP094-0000H4-9J; Thu, 30 Mar 2006 11:37:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP093-0000Gz-Aj for speermint@ietf.org; Thu, 30 Mar 2006 11:37:13 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP092-00050H-3L for speermint@ietf.org; Thu, 30 Mar 2006 11:37:13 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2006 08:37:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,147,1141632000"; d="scan'208"; a="24818887:sNHT23756560" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2UGbBWc001546; Thu, 30 Mar 2006 11:37:11 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 11:37:11 -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] Definition of "Peering" Date: Thu, 30 Mar 2006 11:37:09 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3014A309C@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZUBkyIL2qSQnquTkCZnlZyEPpZxQADVryQ From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" X-OriginalArrivalTime: 30 Mar 2006 16:37:11.0321 (UTC) FILETIME=[31825090:01C65418] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: speermint@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 Otmar, Your question is circular. What you posited earlier was that given indirect option 1, define better direct option 2. While one can learn from experience with option 1, I don't think it is a pre-requisite or dependency for defining option2. Thus, defining where we have been (status quo) is not as important as defining where we want to go. In fact, spending less time looking backwards might help make better progress moving forward. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Thursday, March 30, 2006 9:29 AM > To: Michael Hammer (mhammer) > Cc: Reinaldo Penno; speermint@ietf.org > Subject: Re: [Speermint] Definition of "Peering" >=20 > On 2006/03/30 15:03, "Michael Hammer (mhammer)"=20 > wrote: > >=20 > > SIP Peering is the enablement of direct connection between SIP=20 > > providers offering essential experience-enhancing services, without=20 > > the need to resort to transit middlemen providing solely=20 > route discovery. >=20 > Michael, >=20 > So in the absence of an established SIP Peering: can users of=20 > SIP provider A call customers of SIP provider B? >=20 > If yes, how is that achieved? >=20 > ----------- >=20 > I have the feeling that the members of this WG doesn't agree=20 > on what the status quo is. No wonder that we have=20 > difficulties to agree on what problem Speermint is supposed to solve. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 12:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0y3-00084d-3f; Thu, 30 Mar 2006 12:29:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0y1-00082N-Dw for speermint@ietf.org; Thu, 30 Mar 2006 12:29:53 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP0y1-0007Mi-4Z for speermint@ietf.org; Thu, 30 Mar 2006 12:29:53 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A58B01C8; Thu, 30 Mar 2006 12:29:47 -0500 From: "Hadriel Kaplan" To: Subject: RE: [Speermint] Comments onreqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..) Date: Thu, 30 Mar 2006 12:29:55 -0500 Message-ID: <038401c6541f$8fc72430$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAABrmSw In-Reply-To: <200603301620.k2UGKcwZ019005@leka.oceanic.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: speermint@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 Henry, I am not sure we can come to an agreement on this, but I will try my best because I respect your views and I think there may be confusion simply because we say similar words but don't mean the same things. I believe that is why a terminology document is so critical to starting this process. I was not referring to your email comment when I said "harass". I was unfortunately not at IETF 65, but from what I hear presenters were not given the same level of respect as I have personally seen in previous IETF's for a community approach to a problem. Rather than ignore that, which was my first reaction, I would like to understand and discuss the objections in an open forum. Based on the second-hand description of the arguments raised by attendees at the session, I genuinely believe there is a misunderstanding among the community that a baseline terminology and communication would help clear up. Terms such as "walled-gardens" are used which are ambiguous at best, and misleading at worst. Perhaps that is not the case, and we really have a fundamental difference of opinion. But I would like to find out if that is the case; because I don't think it will be constructive if a majority of the IETF shares the views of the dissenters. There will always be people with differing viewpoints, as there are in every working group and even among working groups. No working group would be able to function if simply the fact of differing viewpoints were to mean work could not progress - so I am not saying we should stop if we simply discover basic human nature exists. BUT, if a significant minority of the IETF shares that then I think it will cause chaos and potentially failure which I would rather avoid at the outset. If you would like, we can discuss them in email exchanges on this list, but I fear the exchange would be long and difficult for people to follow. I would rather get a terminology document done so we can at least start from a documented definition of terms. Regards, Hadriel > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Thursday, March 30, 2006 11:21 AM > To: 'Hadriel Kaplan'; 'Otmar Lendl'; 'Stastny Richard' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Comments onreqs-and-terminology-01andpolicy-dds- > 00(Peerign concepts and others..) > > Hadriel, > > >I believe there is no point in working on something if service providers > >won't use it, or the IESG won't approve it, or other members of the IETF > >community harass us. ;) > > I believe you are right on this item. It appears VoIP peering is just a > business model in conflict with the e2e nature of the Internet. > > Defending e2e against balkanizing business models is not "harassment". > > VoIP businesses are free to take VoIP peering to market, but trying to > legitimize the breakup of e2e in the IETF itself is not OK. > > Thanks, Henry _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 12:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP13R-00047l-Dt; Thu, 30 Mar 2006 12:35:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP13Q-00047g-Ky for speermint@ietf.org; Thu, 30 Mar 2006 12:35:28 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP04H-0004mr-1w for speermint@ietf.org; Thu, 30 Mar 2006 11:32:17 -0500 Received: from leka.oceanic.com ([205.172.16.158]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOztd-00044m-NM for speermint@ietf.org; Thu, 30 Mar 2006 11:21:33 -0500 Received: from 1AB764895C324D3 (kihei2 [66.37.169.171]) by leka.oceanic.com (8.13.6/8.13.6) with ESMTP id k2UGKcwZ019005; Thu, 30 Mar 2006 06:20:41 -1000 (envelope-from henry@pulver.com) Message-Id: <200603301620.k2UGKcwZ019005@leka.oceanic.com> From: "Henry Sinnreich" To: "'Hadriel Kaplan'" , "'Otmar Lendl'" , "'Stastny Richard'" Subject: RE: [Speermint] Comments onreqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..) Date: Thu, 30 Mar 2006 10:20:40 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIA== In-Reply-To: <037101c65411$71f47060$6501a8c0@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.3.30.75107 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0' X-Spam-Score: -1.1 (-) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com 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 Hadriel, >I believe there is no point in working on something if service providers >won't use it, or the IESG won't approve it, or other members of the IETF >community harass us. ;) I believe you are right on this item. It appears VoIP peering is just a business model in conflict with the e2e nature of the Internet. Defending e2e against balkanizing business models is not "harassment". VoIP businesses are free to take VoIP peering to market, but trying to legitimize the breakup of e2e in the IETF itself is not OK. Thanks, Henry -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Thursday, March 30, 2006 9:49 AM To: henry@pulver.com; 'Otmar Lendl'; 'Stastny Richard' Cc: speermint@ietf.org Subject: RE: [Speermint] Comments onreqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..) Hi Henry, Comments inline... > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Wednesday, March 29, 2006 10:18 PM > To: 'Otmar Lendl'; 'Stastny Richard' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Comments onreqs-and-terminology-01andpolicy-dds- > 00(Peerign concepts and others..) > > Otmar, > > I believe you have nailed it right on target: > > >The problem isn't that any of those service providers isn't connected to > >the Internet, the problem is that they refuse to use their Internet > >connection (or even a private IP link) for VoIP interconnection with > other > >server providers. > > If this is so, why should the IETF bother with this problem? Well, for one, because it's not true, as I think you know. VoIP Peering happens all over the place today. Even over the public Internet. But it is an excellent question, and I think we need to determine the answer as soon as possible, to save time and energy if it is not appropriate for the IETF; or to focus on what aspects are appropriate, and do the work. I believe there is no point in working on something if service providers won't use it, or the IESG won't approve it, or other members of the IETF community harass us. ;) But I think we need to at least get terminology done so we can talk the same language, and get some base requirements identified - so we can all figure out the answer to your question. I'm fairly confident we'll end up with something relevant to providers _and_ acceptable to the IETF to specify. Cheers, Hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 13:53:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2Gg-0004re-7m; Thu, 30 Mar 2006 13:53:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2Ge-0004kM-PI for speermint@ietf.org; Thu, 30 Mar 2006 13:53:12 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2Ge-00030P-CK for speermint@ietf.org; Thu, 30 Mar 2006 13:53:12 -0500 Received: from PMelampy [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A91202A0; Thu, 30 Mar 2006 13:53:06 -0500 Message-Id: <200603301353923.SM03164@PMelampy> From: "Patrick Melampy" To: "'Otmar Lendl'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] Definition of "Peering" Date: Thu, 30 Mar 2006 13:53:10 -0500 Message-ID: <015001c6542b$3155c7b0$6701a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQ In-Reply-To: <20060330142859.GD28504@nic.at> X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: speermint@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 There is currently only one type of peering with one set of reciprocal values that IP Network Owners have in the internet today. The real work of this group should be to provide a method to exchange packets where there are different reciprocal values based on a subset of the total packets associated with a service (such as SIP signaled media). This must be done in such a way that no existing services or reciprocal relationships are affected. Additionally, the prevalent protocols used for Layer 3 networking will not be easily extended -- thus the assumption should be made that an architecture that assumes no major changes to BGP4 will be possible. The requirements start at Layer 3 (IP Connectivity, and reachability) and extend to addressing and location of endpoints in adjacent networks and paths to endpoints more than one network hop away. The billing and business models are just the icing on the cake. Even in a world of e2e free internet-hippy style networking, the value of each packet will be different based on the service the packet is part of. This value will be a function of the layer 3 IP-IP interconnection. The IETF's mission is to "make the internet better", and an internet that offers each managed network participant the ability to extract maximum value is a better internet. No solution proposed by anybody will ever remove the best-efforts e2e internet (Your safe Henry). Free services will always be available. The reciprocal value of free services is just that -- exactly equal to the reciprocal value or maximum routing efficiency. Thus the only time the value exchange of peering relations for specific services matches exactly best efforts exchanges is when the service is a zero cost, best efforts service. In these cases, the network owner has no incentive to modify routing of packets. Nor does the service provider have any incentive to deploy any equipment other than the minimum requirements for best efforts. Balkanized? Walled gardens? Net-Neutrality? How about a better, more useful internet that can enable differentiated services -- yet retains the neutrality and openness as core values. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Thursday, March 30, 2006 9:29 AM To: Michael Hammer (mhammer) Cc: speermint@ietf.org Subject: Re: [Speermint] Definition of "Peering" On 2006/03/30 15:03, "Michael Hammer (mhammer)" wrote: > > SIP Peering is the enablement of direct connection between SIP providers > offering essential experience-enhancing services, without the need to > resort to transit middlemen providing solely route discovery. Michael, So in the absence of an established SIP Peering: can users of SIP provider A call customers of SIP provider B? If yes, how is that achieved? ----------- I have the feeling that the members of this WG doesn't agree on what the status quo is. No wonder that we have difficulties to agree on what problem Speermint is supposed to solve. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 Thu Mar 30 15:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3MU-0001ll-HB; Thu, 30 Mar 2006 15:03:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3MT-0001le-4z for speermint@ietf.org; Thu, 30 Mar 2006 15:03:17 -0500 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound2-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP3MR-0005ba-SQ for speermint@ietf.org; Thu, 30 Mar 2006 15:03:17 -0500 Received: from outbound2-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-ash-R.bigfish.com (Postfix) with ESMTP id AB2FC70D20F for ; Thu, 30 Mar 2006 20:03:15 +0000 (UTC) Received: from mail59-ash-R.bigfish.com (unknown [172.18.2.1]) by outbound2-ash.bigfish.com (Postfix) with ESMTP id A9D3B70C130 for ; Thu, 30 Mar 2006 20:03:15 +0000 (UTC) Received: from mail59-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail59-ash-R.bigfish.com (Postfix) with ESMTP id A05D061015D for ; Thu, 30 Mar 2006 20:03:15 +0000 (UTC) X-BigFish: V Received: by mail59-ash (MessageSwitch) id 1143748995539252_18690; Thu, 30 Mar 2006 20:03:15 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail59-ash.bigfish.com (Postfix) with ESMTP id 6F47260FE01 for ; Thu, 30 Mar 2006 20:03:15 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k2UK3E5l004520 for ; Thu, 30 Mar 2006 14:03:14 -0600 (CST) Received: from plswg03a.ad.sprint.com (PLSWG03A.corp.sprint.com [10.214.11.49]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2UK3D013598 for ; Thu, 30 Mar 2006 14:03:13 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg03a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 14:03:00 -0600 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: Thu, 30 Mar 2006 14:03:00 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E0701C9A0@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9A From: "Khan, Sohel Q [CTO]" To: "Khan, Sohel Q [CTO]" X-OriginalArrivalTime: 30 Mar 2006 20:03:00.0966 (UTC) FILETIME=[F2789860:01C65434] X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: speermint@ietf.org Subject: [Speermint] Speermint Charter 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 IMHO, IETF community wants to solve VoIP peering problem in two major ways: e2e/p2p and interprovider/interdomain. I hope that IETF will try to address those separately as follows: P2P SIP BOF/WG: E2E/p2p peering SPEERMINT WG: Interprovider/interdomain peering Thank you. Sohel Khan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 15:20:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3dB-0002JW-3K; Thu, 30 Mar 2006 15:20:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3d9-0002JP-Vl for speermint@ietf.org; Thu, 30 Mar 2006 15:20:31 -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 1FP3d8-0006VD-LM for speermint@ietf.org; Thu, 30 Mar 2006 15:20:31 -0500 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k2UKKRaK020451; Thu, 30 Mar 2006 20:20:27 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id E87B578B4C3; Thu, 30 Mar 2006 20:20:26 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id BCC3978B4BB; Thu, 30 Mar 2006 20:20:26 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 13:20:26 -0700 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] Speermint Charter Date: Thu, 30 Mar 2006 13:20:25 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAADaHlA= From: "Malas, Daryl" To: "Khan, Sohel Q [CTO]" X-OriginalArrivalTime: 30 Mar 2006 20:20:26.0643 (UTC) FILETIME=[61BE3E30:01C65437] X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: speermint@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 Agreed. Thanks... Daryl M. daryl.malas@level3.com -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 Sent: Thursday, March 30, 2006 1:03 PM To: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Subject: [Speermint] Speermint Charter IMHO, IETF community wants to solve VoIP peering problem in two major ways: e2e/p2p and interprovider/interdomain. I hope that IETF will try to address those separately as follows: P2P SIP BOF/WG: E2E/p2p peering SPEERMINT WG: Interprovider/interdomain peering Thank you. Sohel Khan _______________________________________________ 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 Thu Mar 30 15:32:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3pB-0005jN-Mi; Thu, 30 Mar 2006 15:32:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3pA-0005jI-Kz for speermint@ietf.org; Thu, 30 Mar 2006 15:32:56 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FP3p9-0006ud-9h for speermint@ietf.org; Thu, 30 Mar 2006 15:32:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Speermint Charter Date: Thu, 30 Mar 2006 22:34:18 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C494B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhg= From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: speermint@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 Sohel, =20 This is no so simple =20 1. P2P SIP has a complete different charter 2. What if a P2P network is provided by a provider who wants to peer with another provider? =20 Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: Do 30.03.2006 22:03 An: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Betreff: [Speermint] Speermint Charter IMHO, IETF community wants to solve VoIP peering problem in two major ways: e2e/p2p and interprovider/interdomain. I hope that IETF will try to address those separately as follows: P2P SIP BOF/WG: E2E/p2p peering SPEERMINT WG: Interprovider/interdomain peering Thank you. Sohel Khan _______________________________________________ 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 Thu Mar 30 15:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3sl-0007iw-Ho; Thu, 30 Mar 2006 15:36:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3sk-0007ZZ-8a for speermint@ietf.org; Thu, 30 Mar 2006 15:36:38 -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 1FP3sj-0006z8-Sf for speermint@ietf.org; Thu, 30 Mar 2006 15:36:38 -0500 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k2UKaWaK025599; Thu, 30 Mar 2006 20:36:33 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 7D66F12484C; Thu, 30 Mar 2006 20:36:32 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 1B992124829; Thu, 30 Mar 2006 20:36:32 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 13:36:15 -0700 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] Definition of "Peering" Date: Thu, 30 Mar 2006 13:36:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAT0aLA= From: "Malas, Daryl" To: "Patrick Melampy" , "Otmar Lendl" , "Michael Hammer (mhammer)" X-OriginalArrivalTime: 30 Mar 2006 20:36:15.0686 (UTC) FILETIME=[976AB660:01C65439] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: speermint@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 Comments inline...Thanks... -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 Sent: Thursday, March 30, 2006 11:53 AM To: 'Otmar Lendl'; 'Michael Hammer (mhammer)' Cc: speermint@ietf.org Subject: RE: [Speermint] Definition of "Peering" There is currently only one type of peering with one set of reciprocal values that IP Network Owners have in the internet today. The real work of this group should be to provide a method to exchange packets where there are different reciprocal values based on a subset of the total packets associated with a service (such as SIP signaled media). This must be done in such a way that no existing services or reciprocal relationships are affected. Additionally, the prevalent protocols used for Layer 3 networking will not be easily extended -- thus the assumption should be made that an architecture that assumes no major changes to BGP4 will be possible. [Malas, Daryl] Unless I am misunderstanding your thought, I think peering is higher than Layer 3. Layer 3 is simply the transport for SIP (Layer 5) peering. The transport capability can differ greatly from "shared public internet", IPVPN, private line, and many others. This group should focus at Layer 5 as described in the "Requirements and Terminology" draft. Leave transport and the priority/value of packets up to interconnect designs and strategies.-- The requirements start at Layer 3 (IP Connectivity, and reachability) and extend to addressing and location of endpoints in adjacent networks and paths to endpoints more than one network hop away. The billing and business models are just the icing on the cake. [Malas, Daryl] I agree, billing and business models will be a negotiated aspect of peering, and will differ greatly based on pre-arranged peering agreements. Common CDR information relative to SIP signaling will remain consistent in peering for these aspects.-- Even in a world of e2e free internet-hippy style networking, the value of each packet will be different based on the service the packet is part of. This value will be a function of the layer 3 IP-IP interconnection. The IETF's mission is to "make the internet better", and an internet that offers each managed network participant the ability to extract maximum value is a better internet. No solution proposed by anybody will ever remove the best-efforts e2e internet (Your safe Henry). Free services will always be available. The reciprocal value of free services is just that -- exactly equal to the reciprocal value or maximum routing efficiency. Thus the only time the value exchange of peering relations for specific services matches exactly best efforts exchanges is when the service is a zero cost, best efforts service. In these cases, the network owner has no incentive to modify routing of packets. Nor does the service provider have any incentive to deploy any equipment other than the minimum requirements for best efforts. [Malas, Daryl] The internet will remain as a transport mechanism for a low cost peering relationship. The value here is defined easily. Peering can encompass an interconnection with the Internet maintaining both private and public peering capabilities. This reminds me of the 3 different categories of ENUM (Public, Private, and Carrier -- If I remember correctly). I think SPEERMINT should define different categories of peering in a similar manner.-- Balkanized? Walled gardens? Net-Neutrality? How about a better, more useful internet that can enable differentiated services -- yet retains the neutrality and openness as core values.=20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Thursday, March 30, 2006 9:29 AM To: Michael Hammer (mhammer) Cc: speermint@ietf.org Subject: Re: [Speermint] Definition of "Peering" On 2006/03/30 15:03, "Michael Hammer (mhammer)" wrote: >=20 > SIP Peering is the enablement of direct connection between SIP providers > offering essential experience-enhancing services, without the need to > resort to transit middlemen providing solely route discovery. Michael, So in the absence of an established SIP Peering: can users of SIP provider A call customers of SIP provider B? If yes, how is that achieved? ----------- I have the feeling that the members of this WG doesn't agree on=20 what the status quo is. No wonder that we have difficulties to=20 agree on what problem Speermint is supposed to solve. /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 15:46:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP42P-00065e-2B; Thu, 30 Mar 2006 15:46:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP42N-00064A-Qx for speermint@ietf.org; Thu, 30 Mar 2006 15:46:35 -0500 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP42N-0007Ib-Ja for speermint@ietf.org; Thu, 30 Mar 2006 15:46:35 -0500 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k2UKjf6r028158; Thu, 30 Mar 2006 20:45:52 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 402F1124849; Thu, 30 Mar 2006 20:45:26 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id E5800124826; Thu, 30 Mar 2006 20:45:25 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 13:45:23 -0700 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] Speermint Charter Date: Thu, 30 Mar 2006 13:45:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUA== From: "Malas, Daryl" To: "Stastny Richard" , "Khan, Sohel Q [CTO]" X-OriginalArrivalTime: 30 Mar 2006 20:45:23.0312 (UTC) FILETIME=[DDD3CF00:01C6543A] X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: speermint@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 Richard, I responded to soon before. You have a good point. So what you are suggesting is peering can encompass multiple SIP based services (P2P, ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? Thanks... Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, March 30, 2006 1:34 PM To: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Subject: Re: [Speermint] Speermint Charter Hi Sohel, =20 This is no so simple =20 1. P2P SIP has a complete different charter 2. What if a P2P network is provided by a provider who wants to peer with another provider? =20 Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: Do 30.03.2006 22:03 An: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Betreff: [Speermint] Speermint Charter IMHO, IETF community wants to solve VoIP peering problem in two major ways: e2e/p2p and interprovider/interdomain. I hope that IETF will try to address those separately as follows: P2P SIP BOF/WG: E2E/p2p peering SPEERMINT WG: Interprovider/interdomain peering Thank you. Sohel Khan _______________________________________________ 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 15:54:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4AC-0007Ig-NS; Thu, 30 Mar 2006 15:54:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4AB-0007Ib-9L for speermint@ietf.org; Thu, 30 Mar 2006 15:54:39 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4AA-0007Yp-0n for speermint@ietf.org; Thu, 30 Mar 2006 15:54:39 -0500 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 30 Mar 2006 12:54:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,147,1141632000"; d="scan'208"; a="536865162:sNHT32211552" Received: from antibottom.jnpr.net ([172.24.15.28]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 12:54:37 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Speermint Charter Date: Thu, 30 Mar 2006 12:54:25 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAIAK5A= From: "Shai Mohaban" To: "Khan, Sohel Q [CTO]" X-OriginalArrivalTime: 30 Mar 2006 20:54:37.0019 (UTC) FILETIME=[27DCCAB0:01C6543C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: speermint@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 I think p2p SIP has nothing to do with e2e... e2e is a general fundamental principle of the Internet that the IETF is trying to maintain and I don't think Speermint would get a relief on that front... -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 Sent: Thursday, March 30, 2006 12:03 PM To: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Subject: [Speermint] Speermint Charter IMHO, IETF community wants to solve VoIP peering problem in two major ways: e2e/p2p and interprovider/interdomain. I hope that IETF will try to address those separately as follows: P2P SIP BOF/WG: E2E/p2p peering SPEERMINT WG: Interprovider/interdomain peering Thank you. Sohel Khan _______________________________________________ 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 Thu Mar 30 16:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4Pm-00083i-NW; Thu, 30 Mar 2006 16:10:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4Pl-00083T-Sc for speermint@ietf.org; Thu, 30 Mar 2006 16:10:45 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FP4Pl-0008B5-F2 for speermint@ietf.org; Thu, 30 Mar 2006 16:10:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Speermint Charter Date: Thu, 30 Mar 2006 23:14:46 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C494C@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7x From: "Stastny Richard" To: "Malas, Daryl" , "Khan, Sohel Q [CTO]" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: speermint@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 Daryl, >I responded to soon before. You have a good point. So what you are >suggesting is peering can encompass multiple SIP based services (P2P, >ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? > >Thanks... Thank you for bringing this up again and in focus =20 The basic idea of SPEERMINT is to bring an SIP INVITE from Provider (or admin domain) A to B without immediately being rejected. =20 If one follows this discussion, one gets the impression that the = buzzwords immediately are traffic, QoS, managed networks, billing, accounting, = charging,=20 so basically the main task of the SIP INVITE seems to trigger a meter. =20 So most here are immediately putting their Bell-hat on and thinking = voice calls =20 But at that point of time it is not even defined what the purpose of the = session will be =20 Of course we are talking about ALL SIP services. Do I need a guarantied = QoS and managed network for an IM or a filetransfer? =20 Richard >Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, March 30, 2006 1:34 PM To: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Subject: Re: [Speermint] Speermint Charter Hi Sohel, This is no so simple 1. P2P SIP has a complete different charter 2. What if a P2P network is provided by a provider who wants to peer with another provider? Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: Do 30.03.2006 22:03 An: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Betreff: [Speermint] Speermint Charter IMHO, IETF community wants to solve VoIP peering problem in two major ways: e2e/p2p and interprovider/interdomain. I hope that IETF will try to address those separately as follows: P2P SIP BOF/WG: E2E/p2p peering SPEERMINT WG: Interprovider/interdomain peering Thank you. Sohel Khan _______________________________________________ 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 _______________________________________________ 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 Thu Mar 30 16:23:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4c1-0002o1-FV; Thu, 30 Mar 2006 16:23:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4c0-0002nw-69 for speermint@ietf.org; Thu, 30 Mar 2006 16:23:24 -0500 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4by-0000Nz-Sz for speermint@ietf.org; Thu, 30 Mar 2006 16:23:24 -0500 Received: (qmail 24369 invoked by uid 510); 30 Mar 2006 17:05:07 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(66.91.151.100):. Processed in 1.608307 secs); 30 Mar 2006 22:05:07 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(66.91.151.100):. Processed in 1.608307 secs Process 24348) Received: from rrcs-66-91-151-100.west.biz.rr.com (HELO 1AB764895C324D3) (henry@pulver.com@66.91.151.100) by 192.246.69.184 with SMTP; Thu, 30 Mar 2006 22:05:05 +0000 From: "Henry Sinnreich" To: "'Patrick Melampy'" , "'Otmar Lendl'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] Definition of "Peering" Date: Thu, 30 Mar 2006 15:23:22 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAbwYCA= In-Reply-To: <200603301353923.SM03164@PMelampy> X-Antivirus-MYDOMAIN-Message-ID: <114375630683524348@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com 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 Message-Id: Patrick Melampy wites: >Even in a world of e2e free internet-hippy style networking, Where is this world? Users pay for Internet access service, which seems to be a booming business. What does the hippie comment mean on this list? Thanks, Henry -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Thursday, March 30, 2006 12:53 PM To: 'Otmar Lendl'; 'Michael Hammer (mhammer)' Cc: speermint@ietf.org Subject: RE: [Speermint] Definition of "Peering" There is currently only one type of peering with one set of reciprocal values that IP Network Owners have in the internet today. The real work of this group should be to provide a method to exchange packets where there are different reciprocal values based on a subset of the total packets associated with a service (such as SIP signaled media). This must be done in such a way that no existing services or reciprocal relationships are affected. Additionally, the prevalent protocols used for Layer 3 networking will not be easily extended -- thus the assumption should be made that an architecture that assumes no major changes to BGP4 will be possible. The requirements start at Layer 3 (IP Connectivity, and reachability) and extend to addressing and location of endpoints in adjacent networks and paths to endpoints more than one network hop away. The billing and business models are just the icing on the cake. Even in a world of e2e free internet-hippy style networking, the value of each packet will be different based on the service the packet is part of. This value will be a function of the layer 3 IP-IP interconnection. The IETF's mission is to "make the internet better", and an internet that offers each managed network participant the ability to extract maximum value is a better internet. No solution proposed by anybody will ever remove the best-efforts e2e internet (Your safe Henry). Free services will always be available. The reciprocal value of free services is just that -- exactly equal to the reciprocal value or maximum routing efficiency. Thus the only time the value exchange of peering relations for specific services matches exactly best efforts exchanges is when the service is a zero cost, best efforts service. In these cases, the network owner has no incentive to modify routing of packets. Nor does the service provider have any incentive to deploy any equipment other than the minimum requirements for best efforts. Balkanized? Walled gardens? Net-Neutrality? How about a better, more useful internet that can enable differentiated services -- yet retains the neutrality and openness as core values. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Thursday, March 30, 2006 9:29 AM To: Michael Hammer (mhammer) Cc: speermint@ietf.org Subject: Re: [Speermint] Definition of "Peering" On 2006/03/30 15:03, "Michael Hammer (mhammer)" wrote: > > SIP Peering is the enablement of direct connection between SIP providers > offering essential experience-enhancing services, without the need to > resort to transit middlemen providing solely route discovery. Michael, So in the absence of an established SIP Peering: can users of SIP provider A call customers of SIP provider B? If yes, how is that achieved? ----------- I have the feeling that the members of this WG doesn't agree on what the status quo is. No wonder that we have difficulties to agree on what problem Speermint is supposed to solve. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 16:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4fn-000351-0J; Thu, 30 Mar 2006 16:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4fl-00034M-9a for speermint@ietf.org; Thu, 30 Mar 2006 16:27:17 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FP4fk-0000Va-P9 for speermint@ietf.org; Thu, 30 Mar 2006 16:27:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Definition of "Peering" Date: Thu, 30 Mar 2006 23:31:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C494D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAcqVgM= From: "Stastny Richard" To: "Patrick Melampy" , "Otmar Lendl" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: speermint@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 This discussion is getting a bit too philosphical for my simple mind ;-) =20 >Balkanized? Walled gardens? Net-Neutrality?=20 =20 and political I think we should work on improving the charter and the requirements i.e. stick to ou knitting - this is only a little IETF WG ;-) =20 >How about a better, more useful i>nternet that can enable differentiated services -- yet retains the >neutrality and openness as core values. But of course you are basically correct Richard ________________________________ Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] Gesendet: Do 30.03.2006 20:53 An: 'Otmar Lendl'; 'Michael Hammer (mhammer)' Cc: speermint@ietf.org Betreff: RE: [Speermint] Definition of "Peering" There is currently only one type of peering with one set of reciprocal values that IP Network Owners have in the internet today. The real work = of this group should be to provide a method to exchange packets where there = are different reciprocal values based on a subset of the total packets associated with a service (such as SIP signaled media). This must be = done in such a way that no existing services or reciprocal relationships are affected. Additionally, the prevalent protocols used for Layer 3 = networking will not be easily extended -- thus the assumption should be made that = an architecture that assumes no major changes to BGP4 will be possible. The requirements start at Layer 3 (IP Connectivity, and reachability) = and extend to addressing and location of endpoints in adjacent networks and paths to endpoints more than one network hop away. The billing and = business models are just the icing on the cake. Even in a world of e2e free internet-hippy style networking, the value = of each packet will be different based on the service the packet is part = of. This value will be a function of the layer 3 IP-IP interconnection. The IETF's mission is to "make the internet better", and an internet that = offers each managed network participant the ability to extract maximum value is = a better internet. No solution proposed by anybody will ever remove the best-efforts e2e internet (Your safe Henry). Free services will always be available. The reciprocal value of free services is just that -- exactly equal to the reciprocal value or maximum routing efficiency. Thus the only time the = value exchange of peering relations for specific services matches exactly best efforts exchanges is when the service is a zero cost, best efforts = service. In these cases, the network owner has no incentive to modify routing of packets. Nor does the service provider have any incentive to deploy any equipment other than the minimum requirements for best efforts. Balkanized? Walled gardens? Net-Neutrality? How about a better, more = useful internet that can enable differentiated services -- yet retains the neutrality and openness as core values. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Thursday, March 30, 2006 9:29 AM To: Michael Hammer (mhammer) Cc: speermint@ietf.org Subject: Re: [Speermint] Definition of "Peering" On 2006/03/30 15:03, "Michael Hammer (mhammer)" = wrote: > > SIP Peering is the enablement of direct connection between SIP = providers > offering essential experience-enhancing services, without the need to > resort to transit middlemen providing solely route discovery. Michael, So in the absence of an established SIP Peering: can users of SIP = provider A call customers of SIP provider B? If yes, how is that achieved? ----------- I have the feeling that the members of this WG doesn't agree on what the status quo is. No wonder that we have difficulties to agree on what problem Speermint is supposed to solve. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 16:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4jk-0005ll-AG; Thu, 30 Mar 2006 16:31:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4jj-0005jk-Ea for speermint@ietf.org; Thu, 30 Mar 2006 16:31:23 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4jj-0000hJ-43 for speermint@ietf.org; Thu, 30 Mar 2006 16:31:23 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 30 Mar 2006 13:31:22 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,147,1141632000"; d="scan'208"; a="536871399:sNHT26055672" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Speermint Charter Date: Thu, 30 Mar 2006 16:31:21 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5A8@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADA= From: "Reinaldo Penno" To: "Stastny Richard" , "Malas, Daryl" , "Khan, Sohel Q [CTO]" X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: speermint@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 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 30, 2006 1:15 PM > To: Malas, Daryl; Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Speermint Charter >=20 > Daryl, >=20 > >I responded to soon before. You have a good point. So what you are > >suggesting is peering can encompass multiple SIP based services (P2P, > >ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? > > > >Thanks... >=20 > Thank you for bringing this up again and in focus >=20 > The basic idea of SPEERMINT is to bring an SIP INVITE from Provider > (or admin domain) A to B without immediately being rejected. [[Reinaldo]]=20 Hello Richard, If all we need is what you said above, then what we need is already defined in SIP/SIPPING, right? They already standardized procedures for DNS lookup, etc, etc Let me rephrase the question by asking what is missing instead of what is already defined. If we have two SIP domains, with the DNSs properly SIPpenized, where the SIP border proxies are configured to talk to each other, is there anything else needed besides what is in SIP/SIPPING? Is the policy piece the missing link?=20 Sorry, I'm trying to peel another layer to look under "enabling to SIP messages between the two domains", "Layer 5 peering" and other expressions.=20 I'm trying to understand what exactly is missing if all we want is to enable Sip messages from domain A to reach B. Are today VoIP peering points just exchange of media or there is signaling going on as well? I think we should rephrase the charter to be much, much more specific on what our goals are, the drafts we need and milestones. Thanks, Reinaldo >=20 > If one follows this discussion, one gets the impression that the buzzwords > immediately are traffic, QoS, managed networks, billing, accounting, > charging, > so basically the main task of the SIP INVITE seems to trigger a meter. >=20 > So most here are immediately putting their Bell-hat on and thinking voice > calls >=20 > But at that point of time it is not even defined what the purpose of the > session will be >=20 > Of course we are talking about ALL SIP services. Do I need a guarantied > QoS > and managed network for an IM or a filetransfer? >=20 > Richard >=20 > >Daryl M. >=20 >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 30, 2006 1:34 PM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Speermint Charter >=20 > Hi Sohel, >=20 > This is no so simple >=20 > 1. P2P SIP has a complete different charter > 2. What if a P2P network is provided by a provider who wants to peer > with another provider? >=20 > Richard >=20 > ________________________________ >=20 > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Gesendet: Do 30.03.2006 22:03 > An: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Betreff: [Speermint] Speermint Charter >=20 >=20 >=20 > IMHO, IETF community wants to solve VoIP peering problem in two major > ways: e2e/p2p and interprovider/interdomain. >=20 > I hope that IETF will try to address those separately as follows: >=20 > P2P SIP BOF/WG: E2E/p2p peering >=20 > SPEERMINT WG: Interprovider/interdomain peering >=20 >=20 >=20 > Thank you. >=20 > Sohel Khan >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=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 >=20 >=20 > _______________________________________________ > 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 Thu Mar 30 16:56:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP57c-0002rZ-6y; Thu, 30 Mar 2006 16:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP57a-0002r9-Lg for speermint@ietf.org; Thu, 30 Mar 2006 16:56:02 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP57a-0001hq-Bd for speermint@ietf.org; Thu, 30 Mar 2006 16:56:02 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 30 Mar 2006 13:56:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,147,1141632000"; d="scan'208"; a="539985249:sNHT24571376" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Mar 2006 16:56:00 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5A9@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Speermint proposal Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAACJ8vw From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Speermint] Speermint proposal 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 I mentioned in a different message that we should try to rephrase the charter to be more specific/focused. Today the charter states " More specifically, SPEERMINT focuses on real-time session routing architectures and their associated use cases. Deliverables here include the specification of the various types of application flows, such as signaling and media flows, in such networks, and includes both trunking and peer-to-peer flows. In addition, SPEERMINT considers and documents requirements for the feedback of operational conditions (e.g., congestion control) that enables the application of dynamic policy and recognizes that various mechanisms for achieving this should be studied as a potential part of any architecture." This seems quite broad; much more than enabling Sip message from domain A to reach B. Further down it states: " The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." I believe maybe this should be our focus, i.e., "in particular how such calls are routed". We should solidify the terminology draft, which is the starting point and in parallel work on the scenarios on how such calls would be routed. Let's put the "new" requirements aside for the time being. If we identify a missing piece, then we could work it as necessary. On the other hand, it might be that we come up with a routing scenarios/message flows documents and find out that the important pieces are there. This would not be wasted work, I'm sure these would be very important documents. It seems very hard to make progress without some document to base our discussions.=20 My 2 cents, Reinaldo > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Thursday, March 30, 2006 12:45 PM > To: Stastny Richard; Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter >=20 > Richard, >=20 > I responded to soon before. You have a good point. So what you are > suggesting is peering can encompass multiple SIP based services (P2P, > ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? >=20 > Thanks... >=20 > Daryl M. >=20 >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 30, 2006 1:34 PM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Speermint Charter >=20 > Hi Sohel, >=20 > This is no so simple >=20 > 1. P2P SIP has a complete different charter > 2. What if a P2P network is provided by a provider who wants to peer > with another provider? >=20 > Richard >=20 > ________________________________ >=20 > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Gesendet: Do 30.03.2006 22:03 > An: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Betreff: [Speermint] Speermint Charter >=20 >=20 >=20 > IMHO, IETF community wants to solve VoIP peering problem in two major > ways: e2e/p2p and interprovider/interdomain. >=20 > I hope that IETF will try to address those separately as follows: >=20 > P2P SIP BOF/WG: E2E/p2p peering >=20 > SPEERMINT WG: Interprovider/interdomain peering >=20 >=20 >=20 > Thank you. >=20 > Sohel Khan >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 17:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5EL-0007SQ-2n; Thu, 30 Mar 2006 17:03:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5EK-0007SL-8Y for speermint@ietf.org; Thu, 30 Mar 2006 17:03:00 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FP5EJ-00021c-O6 for speermint@ietf.org; Thu, 30 Mar 2006 17:03:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Speermint Charter Date: Fri, 31 Mar 2006 00:07:00 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C494E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAg== From: "Stastny Richard" To: "Reinaldo Penno" , "Malas, Daryl" , "Khan, Sohel Q [CTO]" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: speermint@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 Reinaldo, =20 inline =20 >> >> >I responded to soon before. You have a good point. So what you are >> >suggesting is peering can encompass multiple SIP based services = (P2P, >> >ENUM, SIMPLE, etc.), and should not be limited to basic SIP >telephony? >> > >> >Thanks... >> >> Thank you for bringing this up again and in focus >> >> The basic idea of SPEERMINT is to bring an SIP INVITE from Provider >> (or admin domain) A to B without immediately being rejected. >[[Reinaldo]] > >Hello Richard, > >If all we need is what you said above, then what we need is already >defined in SIP/SIPPING, right? They already standardized procedures for >DNS lookup, etc, etc > >Let me rephrase the question by asking what is missing instead of what >is already defined. If we have two SIP domains, with the DNSs properly >SIPpenized, where the SIP border proxies are configured to talk to each >other, is there anything else needed besides what is in SIP/SIPPING? > >Is the policy piece the missing link? I think so. And eventually a profile and minimum requirements for = interconnect >Sorry, I'm trying to peel another layer to look under "enabling to SIP >messages between the two domains", "Layer 5 peering" and other >expressions. > >I'm trying to understand what exactly is missing if all we want is to >enable Sip messages from domain A to reach B. Are today VoIP peering >points just exchange of media or there is signaling going on as well? Either signaling only or also signaling+media (called SBC) > >I think we should rephrase the charter to be much, much more specific = on >what our goals are, the drafts we need and milestones. Yes, and I think this discussion helped very much to make this clear >Thanks, Thank you Richard Reinaldo > > If one follows this discussion, one gets the impression that the buzzwords > immediately are traffic, QoS, managed networks, billing, accounting, > charging, > so basically the main task of the SIP INVITE seems to trigger a meter. > > So most here are immediately putting their Bell-hat on and thinking voice > calls > > But at that point of time it is not even defined what the purpose of the > session will be > > Of course we are talking about ALL SIP services. Do I need a guarantied > QoS > and managed network for an IM or a filetransfer? > > Richard > > >Daryl M. > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 30, 2006 1:34 PM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Speermint Charter > > Hi Sohel, > > This is no so simple > > 1. P2P SIP has a complete different charter > 2. What if a P2P network is provided by a provider who wants to peer > with another provider? > > Richard > > ________________________________ > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Gesendet: Do 30.03.2006 22:03 > An: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Betreff: [Speermint] Speermint Charter > > > > IMHO, IETF community wants to solve VoIP peering problem in two major > ways: e2e/p2p and interprovider/interdomain. > > I hope that IETF will try to address those separately as follows: > > P2P SIP BOF/WG: E2E/p2p peering > > SPEERMINT WG: Interprovider/interdomain peering > > > > Thank you. > > Sohel Khan > > > > > _______________________________________________ > 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 > > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 17:10:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5LG-0002uC-E2; Thu, 30 Mar 2006 17:10:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5LF-0002sw-WE for speermint@ietf.org; Thu, 30 Mar 2006 17:10:10 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5LE-0002WQ-HT for speermint@ietf.org; Thu, 30 Mar 2006 17:10:09 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 30 Mar 2006 14:10:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,147,1141632000"; d="scan'208"; a="536877189:sNHT24664168" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: More concrete proposals (was RE: [Speermint] Speermint proposal) Date: Thu, 30 Mar 2006 17:10:01 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5AA@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More concrete proposals (was RE: [Speermint] Speermint proposal) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAACJ8vwAADMH2A= From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 More concrete proposals: The "routing architecture" part of draft-bathia and draft-khan could possibly be combined in one draft. This would present an overall of the parts, functions, etc We should then have another draft that details the "message flows and routing" as stated in the charter. For example (this is my quick and dirt version to get something going): alice@ispa.com registers, decides to call bob@ispb.com. alice sends a invite to proxy.ispa.com, which performs a DNS lookup on ispb.com, finds out the ispb.com's proxy is proxy.ispb.com. At this point we have two scenarios: Ispa and ispb have an established commercial agreement and a configuration as a consequence of that (which is out of scope). proxya and proxyb never talked to each other and then will determine if they meet the "minimum requirements" as stated in the charter to talk each other. This could be establishing a TLS connection or whatever. thanks, Reinaldo > -----Original Message----- > From: Reinaldo Penno > Sent: Thursday, March 30, 2006 1:56 PM > To: speermint@ietf.org > Subject: [Speermint] Speermint proposal >=20 > I mentioned in a different message that we should try to rephrase the > charter to be more specific/focused. >=20 > Today the charter states >=20 > " More specifically, SPEERMINT focuses on real-time session > routing architectures and their associated use cases. > Deliverables here include the specification of the various > types of application flows, such as signaling and media flows, in > such networks, and includes both trunking and peer-to-peer > flows. In addition, SPEERMINT considers and documents requirements > for the feedback of operational conditions (e.g., congestion control) > that enables the application of dynamic policy and recognizes > that various mechanisms for achieving this should be studied as > a potential part of any architecture." >=20 > This seems quite broad; much more than enabling Sip message from domain > A to reach B. >=20 > Further down it states: >=20 > " The most focused deliverables of SPEERMINT are best current practices > regarding exchange of real-time sessions among VoIP and other > real-time application service providers and, in particular, how > such calls are routed." >=20 > I believe maybe this should be our focus, i.e., "in particular how such > calls are routed". We should solidify the terminology draft, which is > the starting point and in parallel work on the scenarios on how such > calls would be routed. Let's put the "new" requirements aside for the > time being. If we identify a missing piece, then we could work it as > necessary. >=20 > On the other hand, it might be that we come up with a routing > scenarios/message flows documents and find out that the important pieces > are there. This would not be wasted work, I'm sure these would be very > important documents. >=20 > It seems very hard to make progress without some document to base our > discussions. >=20 > My 2 cents, >=20 > Reinaldo >=20 >=20 > > -----Original Message----- > > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > > Sent: Thursday, March 30, 2006 12:45 PM > > To: Stastny Richard; Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Speermint Charter > > > > Richard, > > > > I responded to soon before. You have a good point. So what you are > > suggesting is peering can encompass multiple SIP based services (P2P, > > ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? > > > > Thanks... > > > > Daryl M. > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, March 30, 2006 1:34 PM > > To: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Speermint Charter > > > > Hi Sohel, > > > > This is no so simple > > > > 1. P2P SIP has a complete different charter > > 2. What if a P2P network is provided by a provider who wants to peer > > with another provider? > > > > Richard > > > > ________________________________ > > > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Gesendet: Do 30.03.2006 22:03 > > An: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Betreff: [Speermint] Speermint Charter > > > > > > > > IMHO, IETF community wants to solve VoIP peering problem in two major > > ways: e2e/p2p and interprovider/interdomain. > > > > I hope that IETF will try to address those separately as follows: > > > > P2P SIP BOF/WG: E2E/p2p peering > > > > SPEERMINT WG: Interprovider/interdomain peering > > > > > > > > Thank you. > > > > Sohel Khan > > > > > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 17:18:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5T6-0003oc-EQ; Thu, 30 Mar 2006 17:18:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5T5-0003oX-5y for speermint@ietf.org; Thu, 30 Mar 2006 17:18:15 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FP5T4-00032J-Li for speermint@ietf.org; Thu, 30 Mar 2006 17:18:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Speermint] Speermint proposal Date: Fri, 31 Mar 2006 00:20:31 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4950@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Speermint proposal Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAACJ8vwAAF4ozI= From: "Stastny Richard" To: "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 Hi Reinaldo,=20 =20 I support your proposal, =20 inline I mentioned in a different message that we should try to rephrase the charter to be more specific/focused. Today the charter states " More specifically, SPEERMINT focuses on real-time session routing architectures and their associated use cases. Deliverables here include the specification of the various types of application flows, such as signaling and media flows, in such networks, and includes both trunking and peer-to-peer flows. In addition, SPEERMINT considers and documents requirements for the feedback of operational conditions (e.g., congestion control) that enables the application of dynamic policy and recognizes that various mechanisms for achieving this should be studied as a potential part of any architecture." This seems quite broad; much more than enabling Sip message from domain A to reach B. [Richard]: Yes, this seemed a good idea, but it is really too broad and=20 Further down it states: " The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." I believe maybe this should be our focus, i.e., "in particular how such calls are routed". We should solidify the terminology draft, which is the starting point and in parallel work on the scenarios on how such calls would be routed. Let's put the "new" requirements aside for the time being. If we identify a missing piece, then we could work it as necessary. On the other hand, it might be that we come up with a routing scenarios/message flows documents and find out that the important pieces are there. This would not be wasted work, I'm sure these would be very important documents. It seems very hard to make progress without some document to base our discussions. My 2 cents, Reinaldo > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Thursday, March 30, 2006 12:45 PM > To: Stastny Richard; Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter > > Richard, > > I responded to soon before. You have a good point. So what you are > suggesting is peering can encompass multiple SIP based services (P2P, > ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? > > Thanks... > > Daryl M. > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 30, 2006 1:34 PM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Speermint Charter > > Hi Sohel, > > This is no so simple > > 1. P2P SIP has a complete different charter > 2. What if a P2P network is provided by a provider who wants to peer > with another provider? > > Richard > > ________________________________ > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Gesendet: Do 30.03.2006 22:03 > An: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Betreff: [Speermint] Speermint Charter > > > > IMHO, IETF community wants to solve VoIP peering problem in two major > ways: e2e/p2p and interprovider/interdomain. > > I hope that IETF will try to address those separately as follows: > > P2P SIP BOF/WG: E2E/p2p peering > > SPEERMINT WG: Interprovider/interdomain peering > > > > Thank you. > > Sohel Khan > > > > > _______________________________________________ > 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 > > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 17:22:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5X0-0006Fo-RR; Thu, 30 Mar 2006 17:22:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5Wz-0006EP-J6 for speermint@ietf.org; Thu, 30 Mar 2006 17:22:17 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FP5Wz-0003E7-26 for speermint@ietf.org; Thu, 30 Mar 2006 17:22:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Speermint proposal Date: Fri, 31 Mar 2006 00:23:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4952@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint proposal Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAACJ8vwAAF4ozIAABvaXA== From: "Stastny Richard" To: "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 Sorry, I het the send by accident =20 Hi Reinaldo,=20 =20 I support your proposal, =20 inline I mentioned in a different message that we should try to rephrase the charter to be more specific/focused. Today the charter states " More specifically, SPEERMINT focuses on real-time session routing architectures and their associated use cases. Deliverables here include the specification of the various types of application flows, such as signaling and media flows, in such networks, and includes both trunking and peer-to-peer flows. In addition, SPEERMINT considers and documents requirements for the feedback of operational conditions (e.g., congestion control) that enables the application of dynamic policy and recognizes that various mechanisms for achieving this should be studied as a potential part of any architecture." This seems quite broad; much more than enabling Sip message from domain A to reach B. [Richard]: Yes, this seemed a good idea, but it is really too broad and = may have caused the confusion we had in the meeting and the discussion Further down it states: " The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." I believe maybe this should be our focus, i.e., "in particular how such calls are routed". We should solidify the terminology draft, which is the starting point and in parallel work on the scenarios on how such calls would be routed. Let's put the "new" requirements aside for the time being. If we identify a missing piece, then we could work it as necessary. [Richard} Correct On the other hand, it might be that we come up with a routing scenarios/message flows documents and find out that the important pieces are there. This would not be wasted work, I'm sure these would be very important documents. [Richard} Agreed regards=20 Richard It seems very hard to make progress without some document to base our discussions. My 2 cents, Reinaldo > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Thursday, March 30, 2006 12:45 PM > To: Stastny Richard; Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter > > Richard, > > I responded to soon before. You have a good point. So what you are > suggesting is peering can encompass multiple SIP based services (P2P, > ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? > > Thanks... > > Daryl M. > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 30, 2006 1:34 PM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Speermint Charter > > Hi Sohel, > > This is no so simple > > 1. P2P SIP has a complete different charter > 2. What if a P2P network is provided by a provider who wants to peer > with another provider? > > Richard > > ________________________________ > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Gesendet: Do 30.03.2006 22:03 > An: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Betreff: [Speermint] Speermint Charter > > > > IMHO, IETF community wants to solve VoIP peering problem in two major > ways: e2e/p2p and interprovider/interdomain. > > I hope that IETF will try to address those separately as follows: > > P2P SIP BOF/WG: E2E/p2p peering > > SPEERMINT WG: Interprovider/interdomain peering > > > > Thank you. > > Sohel Khan > > > > > _______________________________________________ > 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 > > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 17:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5XA-0006zu-2H; Thu, 30 Mar 2006 17:22:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5X8-0006pB-B3 for speermint@ietf.org; Thu, 30 Mar 2006 17:22:26 -0500 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5X7-0003FA-Vd for speermint@ietf.org; Thu, 30 Mar 2006 17:22:26 -0500 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k2UMLv6r003580; Thu, 30 Mar 2006 22:22:08 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 554F012484C; Thu, 30 Mar 2006 22:21:52 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 0DC7E124849; Thu, 30 Mar 2006 22:21:52 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 15:21:51 -0700 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: More concrete proposals (was RE: [Speermint] Speermint proposal) Date: Thu, 30 Mar 2006 15:21:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More concrete proposals (was RE: [Speermint] Speermint proposal) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAACJ8vwAADMH2AAAGU10A== From: "Malas, Daryl" To: "Reinaldo Penno" , X-OriginalArrivalTime: 30 Mar 2006 22:21:51.0807 (UTC) FILETIME=[580A0CF0:01C65448] X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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 Okay, so I have an additional proposal, which I think will be necessary as well: A draft for "peering authentication", with an example continued within your's below... "Ispa and ispb have an established commercial agreement and a configuration as a consequence of that (which is out of scope)." ISPA sends a PROXY REGISTER message to ISPB. ISPB responds with a 401 Unauthorized. ISPA sends a PROXY REGISTER with HTTP/AUTH credentials to ISPB. ISPB responds with 200 OK and "Proxy-auth" key. The auth key is cached by ISPA. "alice@ispa.com registers, decides to call bob@ispb.com." "alice sends a invite to proxy.ispa.com, which performs a DNS lookup on ispb.com, finds out the ispb.com's proxy is proxy.ispb.com." proxy.ispa.com includes "Proxy-auth" key in INVITE from alice as authorization for the peering relationship. ISPB looks for "Proxy-auth" key and allows alice's call to continue to bob. I know this is overly simplistic, but I think this WG must define a mechanism similar to this. This will be critical for securing SIP signaling between peers. Daryl M. daryl.malas@level3.com Ernest Hemingway - "Never mistake motion for action." -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, March 30, 2006 3:10 PM To: speermint@ietf.org Subject: More concrete proposals (was RE: [Speermint] Speermint proposal) More concrete proposals: The "routing architecture" part of draft-bathia and draft-khan could possibly be combined in one draft. This would present an overall of the parts, functions, etc We should then have another draft that details the "message flows and routing" as stated in the charter. For example (this is my quick and dirt version to get something going): alice@ispa.com registers, decides to call bob@ispb.com. alice sends a invite to proxy.ispa.com, which performs a DNS lookup on ispb.com, finds out the ispb.com's proxy is proxy.ispb.com. At this point we have two scenarios: Ispa and ispb have an established commercial agreement and a configuration as a consequence of that (which is out of scope). proxya and proxyb never talked to each other and then will determine if they meet the "minimum requirements" as stated in the charter to talk each other. This could be establishing a TLS connection or whatever. thanks, Reinaldo > -----Original Message----- > From: Reinaldo Penno > Sent: Thursday, March 30, 2006 1:56 PM > To: speermint@ietf.org > Subject: [Speermint] Speermint proposal >=20 > I mentioned in a different message that we should try to rephrase the > charter to be more specific/focused. >=20 > Today the charter states >=20 > " More specifically, SPEERMINT focuses on real-time session > routing architectures and their associated use cases. > Deliverables here include the specification of the various > types of application flows, such as signaling and media flows, in > such networks, and includes both trunking and peer-to-peer > flows. In addition, SPEERMINT considers and documents requirements > for the feedback of operational conditions (e.g., congestion control) > that enables the application of dynamic policy and recognizes > that various mechanisms for achieving this should be studied as > a potential part of any architecture." >=20 > This seems quite broad; much more than enabling Sip message from domain > A to reach B. >=20 > Further down it states: >=20 > " The most focused deliverables of SPEERMINT are best current practices > regarding exchange of real-time sessions among VoIP and other > real-time application service providers and, in particular, how > such calls are routed." >=20 > I believe maybe this should be our focus, i.e., "in particular how such > calls are routed". We should solidify the terminology draft, which is > the starting point and in parallel work on the scenarios on how such > calls would be routed. Let's put the "new" requirements aside for the > time being. If we identify a missing piece, then we could work it as > necessary. >=20 > On the other hand, it might be that we come up with a routing > scenarios/message flows documents and find out that the important pieces > are there. This would not be wasted work, I'm sure these would be very > important documents. >=20 > It seems very hard to make progress without some document to base our > discussions. >=20 > My 2 cents, >=20 > Reinaldo >=20 >=20 > > -----Original Message----- > > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > > Sent: Thursday, March 30, 2006 12:45 PM > > To: Stastny Richard; Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Speermint Charter > > > > Richard, > > > > I responded to soon before. You have a good point. So what you are > > suggesting is peering can encompass multiple SIP based services (P2P, > > ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? > > > > Thanks... > > > > Daryl M. > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, March 30, 2006 1:34 PM > > To: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Speermint Charter > > > > Hi Sohel, > > > > This is no so simple > > > > 1. P2P SIP has a complete different charter > > 2. What if a P2P network is provided by a provider who wants to peer > > with another provider? > > > > Richard > > > > ________________________________ > > > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Gesendet: Do 30.03.2006 22:03 > > An: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Betreff: [Speermint] Speermint Charter > > > > > > > > IMHO, IETF community wants to solve VoIP peering problem in two major > > ways: e2e/p2p and interprovider/interdomain. > > > > I hope that IETF will try to address those separately as follows: > > > > P2P SIP BOF/WG: E2E/p2p peering > > > > SPEERMINT WG: Interprovider/interdomain peering > > > > > > > > Thank you. > > > > Sohel Khan > > > > > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > > 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 _______________________________________________ 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 Thu Mar 30 17:33:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5i1-00073y-G1; Thu, 30 Mar 2006 17:33:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5i0-00073t-9s for speermint@ietf.org; Thu, 30 Mar 2006 17:33:40 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5hz-0003ic-OC for speermint@ietf.org; Thu, 30 Mar 2006 17:33:40 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 30 Mar 2006 14:33:32 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,148,1141632000"; d="scan'208"; a="539992158:sNHT28574076" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: More concrete proposals (was RE: [Speermint] Speermint proposal) Date: Thu, 30 Mar 2006 17:33:20 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5AB@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More concrete proposals (was RE: [Speermint] Speermint proposal) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAACJ8vwAADMH2AAAGU10AAAeKAQ From: "Reinaldo Penno" To: "Malas, Daryl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 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 That's perfectly fine. These were my proposals to get things going so we do not get stuck. The charter states that "Where these domains peer, or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations". Your proposal tackles these. Regards, Reinaldo > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Thursday, March 30, 2006 2:22 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: More concrete proposals (was RE: [Speermint] Speermint > proposal) >=20 > Okay, so I have an additional proposal, which I think will be necessary > as well: >=20 > A draft for "peering authentication", with an example continued within > your's below... >=20 > "Ispa and ispb have an established commercial agreement and a > configuration as a consequence of that (which is out of scope)." >=20 > ISPA sends a PROXY REGISTER message to ISPB. ISPB responds with a 401 > Unauthorized. ISPA sends a PROXY REGISTER with HTTP/AUTH credentials to > ISPB. ISPB responds with 200 OK and "Proxy-auth" key. The auth key is > cached by ISPA. >=20 > "alice@ispa.com registers, decides to call bob@ispb.com." >=20 > "alice sends a invite to proxy.ispa.com, which performs a DNS lookup on > ispb.com, finds out the ispb.com's proxy is proxy.ispb.com." >=20 > proxy.ispa.com includes "Proxy-auth" key in INVITE from alice as > authorization for the peering relationship. ISPB looks for "Proxy-auth" > key and allows alice's call to continue to bob. >=20 > I know this is overly simplistic, but I think this WG must define a > mechanism similar to this. This will be critical for securing SIP > signaling between peers. >=20 > Daryl M. > daryl.malas@level3.com >=20 > Ernest Hemingway - "Never mistake motion for action." >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, March 30, 2006 3:10 PM > To: speermint@ietf.org > Subject: More concrete proposals (was RE: [Speermint] Speermint > proposal) >=20 > More concrete proposals: >=20 > The "routing architecture" part of draft-bathia and draft-khan could > possibly be combined in one draft. >=20 > This would present an overall of the parts, functions, etc >=20 > We should then have another draft that details the "message flows and > routing" as stated in the charter. For example (this is my quick and > dirt version to get something going): >=20 > alice@ispa.com registers, decides to call bob@ispb.com. >=20 > alice sends a invite to proxy.ispa.com, which performs a DNS lookup on > ispb.com, finds out the ispb.com's proxy is proxy.ispb.com. >=20 > At this point we have two scenarios: >=20 > Ispa and ispb have an established commercial agreement and a > configuration as a consequence of that (which is out of scope). >=20 > proxya and proxyb never talked to each other and then will determine if > they meet the "minimum requirements" as stated in the charter to talk > each other. This could be establishing a TLS connection or whatever. >=20 > thanks, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Reinaldo Penno > > Sent: Thursday, March 30, 2006 1:56 PM > > To: speermint@ietf.org > > Subject: [Speermint] Speermint proposal > > > > I mentioned in a different message that we should try to rephrase the > > charter to be more specific/focused. > > > > Today the charter states > > > > " More specifically, SPEERMINT focuses on real-time session > > routing architectures and their associated use cases. > > Deliverables here include the specification of the various > > types of application flows, such as signaling and media flows, in > > such networks, and includes both trunking and peer-to-peer > > flows. In addition, SPEERMINT considers and documents requirements > > for the feedback of operational conditions (e.g., congestion control) > > that enables the application of dynamic policy and recognizes > > that various mechanisms for achieving this should be studied as > > a potential part of any architecture." > > > > This seems quite broad; much more than enabling Sip message from > domain > > A to reach B. > > > > Further down it states: > > > > " The most focused deliverables of SPEERMINT are best current > practices > > regarding exchange of real-time sessions among VoIP and other > > real-time application service providers and, in particular, how > > such calls are routed." > > > > I believe maybe this should be our focus, i.e., "in particular how > such > > calls are routed". We should solidify the terminology draft, which is > > the starting point and in parallel work on the scenarios on how such > > calls would be routed. Let's put the "new" requirements aside for the > > time being. If we identify a missing piece, then we could work it as > > necessary. > > > > On the other hand, it might be that we come up with a routing > > scenarios/message flows documents and find out that the important > pieces > > are there. This would not be wasted work, I'm sure these would be very > > important documents. > > > > It seems very hard to make progress without some document to base our > > discussions. > > > > My 2 cents, > > > > Reinaldo > > > > > > > -----Original Message----- > > > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > > > Sent: Thursday, March 30, 2006 12:45 PM > > > To: Stastny Richard; Khan, Sohel Q [CTO] > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Speermint Charter > > > > > > Richard, > > > > > > I responded to soon before. You have a good point. So what you are > > > suggesting is peering can encompass multiple SIP based services > (P2P, > > > ENUM, SIMPLE, etc.), and should not be limited to basic SIP > telephony? > > > > > > Thanks... > > > > > > Daryl M. > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, March 30, 2006 1:34 PM > > > To: Khan, Sohel Q [CTO] > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Speermint Charter > > > > > > Hi Sohel, > > > > > > This is no so simple > > > > > > 1. P2P SIP has a complete different charter > > > 2. What if a P2P network is provided by a provider who wants to peer > > > with another provider? > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > Gesendet: Do 30.03.2006 22:03 > > > An: Khan, Sohel Q [CTO] > > > Cc: speermint@ietf.org > > > Betreff: [Speermint] Speermint Charter > > > > > > > > > > > > IMHO, IETF community wants to solve VoIP peering problem in two > major > > > ways: e2e/p2p and interprovider/interdomain. > > > > > > I hope that IETF will try to address those separately as follows: > > > > > > P2P SIP BOF/WG: E2E/p2p peering > > > > > > SPEERMINT WG: Interprovider/interdomain peering > > > > > > > > > > > > Thank you. > > > > > > Sohel Khan > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > 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 Thu Mar 30 17:38:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5n7-0000BD-Vi; Thu, 30 Mar 2006 17:38:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5n6-0008Vp-AK for speermint@ietf.org; Thu, 30 Mar 2006 17:38:56 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5n5-0003z9-UR for speermint@ietf.org; Thu, 30 Mar 2006 17:38:56 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FP5mp-00016g-Jx; Thu, 30 Mar 2006 16:38:40 -0600 From: "Brian Rosen" To: "'Stastny Richard'" , "'Reinaldo Penno'" , "'Malas, Daryl'" , "'Khan, Sohel Q [CTO]'" Subject: RE: [Speermint] Speermint Charter Date: Thu, 30 Mar 2006 17:38:41 -0500 Message-ID: <05a701c6544a$b4679c40$b9201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6Hw In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C494E@oefeg-s04.oefeg.loc> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 Wading in the middle: Just for fun, I re-read our charter. I came away saying "that's pretty clear". I now turn to this discussion and say "please re-read the charter". The charter is clear we are talking about all forms of real time communications. The charter doesn't explicitly rule out one way (streaming) but I think we can assume it. So, it's not just voice. The charter is clear we are talking about SIP. We aren't talking about XMPP for example or H.323. The charter does not discuss p2p SIP. I believe that until there is a working group on p2p SIP, and until that group produces some interesting results, it's out of scope for us. We're dealing with proxy to proxy peering. The charter is pretty clear that we are talking about BOTH inter-carrier as well as any inter-domain peering. I suppose it could be clearer about that point. I think inter-enterprise VoIP, to take an example, without benefit of a carrier, is probably in scope. We could, within the group, decide to treat carrier peering and other interdomain peering separately. It's not clear to me that we need to or should, at least at the moment. I don't think anyone can say "we are NOT working on inter-carrier peering". Similarly, I don't believe we are limited to e.164 addresses. I think we include mapping of e.164s to SIP URIs within our documents as one of the things a proxy may do. I think we can also be somewhat cavalier with the differences between public ENUM, infrastructure/carrier ENUM and private ENUM. I don't think we even want to offer guidance on what to do when more than one is available other than observing that such a case will be common. The charter is clear we are talking about BOTH the media and the signaling. If you combine that with "inter-carrier vs inter-domain" then you have BOTH the case of a direct media connection as well as one that goes through (horrors) SBCs, even when two UAs are in the same hotel. Most enterprises seem to like SBCs anyway. Unless someone gives me a really good explanation of why it actually matters if they do run through SBCs with respect to our work, I think we probably can ignore the difference. Finally, in my checkered past, I have had many occasions to observe the difference between a pile of documents that purport to define interoperable implementations, and the reality of actually achieving it. While in general, in the IETF, "profiles" are not a nice word, Best Current Practices are. Our charter is clear we are to develop BCPs. One of the biggest values we can have on peering is to be VERY explicit about what the (SIP) signaling looks like across the peering points. Remember, the wonderful thing about standards is that there are so many to choose from. There is no better example of that than the area in which we find ourselves here, and we CAN do something about making choices. It's all well and good to say "dip ENUM if you have an e.164, use SRV to find the server for the domain of the URI, send an INVITE there", but, in the real world, it's MUCH more complicated then that, and our job is to describe all the dreck that you really have to do. I think our problem is more to define what we do first then what we do. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, March 30, 2006 5:07 PM To: Reinaldo Penno; Malas, Daryl; Khan, Sohel Q [CTO] Cc: speermint@ietf.org Subject: Re: [Speermint] Speermint Charter Hi Reinaldo, inline >> >> >I responded to soon before. You have a good point. So what you are >> >suggesting is peering can encompass multiple SIP based services (P2P, >> >ENUM, SIMPLE, etc.), and should not be limited to basic SIP >telephony? >> > >> >Thanks... >> >> Thank you for bringing this up again and in focus >> >> The basic idea of SPEERMINT is to bring an SIP INVITE from Provider >> (or admin domain) A to B without immediately being rejected. >[[Reinaldo]] > >Hello Richard, > >If all we need is what you said above, then what we need is already >defined in SIP/SIPPING, right? They already standardized procedures for >DNS lookup, etc, etc > >Let me rephrase the question by asking what is missing instead of what >is already defined. If we have two SIP domains, with the DNSs properly >SIPpenized, where the SIP border proxies are configured to talk to each >other, is there anything else needed besides what is in SIP/SIPPING? > >Is the policy piece the missing link? I think so. And eventually a profile and minimum requirements for interconnect >Sorry, I'm trying to peel another layer to look under "enabling to SIP >messages between the two domains", "Layer 5 peering" and other >expressions. > >I'm trying to understand what exactly is missing if all we want is to >enable Sip messages from domain A to reach B. Are today VoIP peering >points just exchange of media or there is signaling going on as well? Either signaling only or also signaling+media (called SBC) > >I think we should rephrase the charter to be much, much more specific on >what our goals are, the drafts we need and milestones. Yes, and I think this discussion helped very much to make this clear >Thanks, Thank you Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 22:26:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPAHe-0005JY-Up; Thu, 30 Mar 2006 22:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPAHc-000590-Si for speermint@ietf.org; Thu, 30 Mar 2006 22:26:44 -0500 Received: from emcsw.com ([69.28.242.167] helo=www.eguy.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPAHb-0000Bt-N0 for speermint@ietf.org; Thu, 30 Mar 2006 22:26:44 -0500 Received: from host-24-149-134-164.patmedia.net ([24.149.134.164]:3327 helo=[192.168.1.4]) by www.eguy.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FPAHj-00031p-Sq for speermint@ietf.org; Thu, 30 Mar 2006 22:26:51 -0500 Message-ID: <442CA14A.80501@eGuy.org> Date: Thu, 30 Mar 2006 22:26:02 -0500 From: Ed Guy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: speermint@ietf.org Subject: Re: [Speermint] Definition of "Peering" References: <32755D354E6B65498C3BD9FD496C7D462C494D@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C494D@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 All, I put up a wiki at http://speermint.ipeerx.com/ It has David's definitions from reqs-and-terminology-01. Feel free to edit away. (however, that doesn't mean the ID editor is under any obligation to use the results.) Cheers Ed Guy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Mar 30 23:10:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPAyG-0008MQ-Fb; Thu, 30 Mar 2006 23:10:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPAyF-0008MD-7z for speermint@ietf.org; Thu, 30 Mar 2006 23:10:47 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPAyD-00025c-V6 for speermint@ietf.org; Thu, 30 Mar 2006 23:10:47 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id ABBB01F8; Thu, 30 Mar 2006 23:10:35 -0500 From: "Hadriel Kaplan" To: , "'Patrick Melampy'" , "'Otmar Lendl'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] Definition of "Peering" Date: Thu, 30 Mar 2006 23:10:42 -0500 Message-ID: <00a601c65479$141a6d10$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAbwYCAADH+b8A== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: speermint@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 Henry, Comments inline... > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Thursday, March 30, 2006 4:23 PM > > Users pay for Internet access service, which seems to be a booming > business. Well I can't speak for it being a booming business or not, but I think what you said is exactly right about Internet access - and shows the confusion caused by us using the same words but possibly meaning different things. It is absolutely true that people pay for "Internet Access", and Internet access is what they should get for that payment. If you want to install a sip phone on your PC and make a point-to-point sip call to your friend - that should be possible. If you want to point your sip phone to the proxy or registrar of your choosing, so long as the owner of the registrar/proxy you choose agrees - then that should be possible. As should best-effort forwarding of any IP packets of any port numbers using any transport layer of your choosing to anywhere routable/reachable in the Internet, so long as the far-end IP-Address destination allows it... you get the idea. The IETF is a completely inappropriate place to discuss NOT allowing that. In my opinion, it MUST be the case that NO output of this WG describes blocking such best-effort "Internet Access" traffic, or blocking the ability to do that with your SIP UA. So when you say "end-to-end" or "e2e" - is that what you mean? Being able to create sip sessions either directly from your PC to your friend's PC? As well as through proxies of your choosing, so long as the proxies you chose allow you to? If so, I think we agree. To some of us, the confusion comes about because the word "access" has a special connotation for voip providers about customers joining and creating sip sessions through a specific collection of sip proxies/registrars. The joining can be explicit through challenged registration means, or implicit through static configuration, or whatever. The confusion is that from the operator's perspective, they should absolutely have the right to only allow specific users to join their collection of sip proxies/registrars/etc. Just like a bank running a web server has the right to only give their paying customers access to their server. The very concepts of SIP/HTTP challenge-response, or mutual-TLS, or any such authentication mechanisms defined by IETF working groups tacitly implies to me that the operator of the proxy/registrar has an IETF-sanctioned right to reject unauthorized users from joining his collection of proxies/registrars. Do we agree on that? -hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 31 04:04:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPFYf-0000St-61; Fri, 31 Mar 2006 04:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPFYe-0000So-Fx for speermint@ietf.org; Fri, 31 Mar 2006 04:04:40 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FPFYa-0006CJ-M7 for speermint@ietf.org; Fri, 31 Mar 2006 04:04:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Definition of "Peering" Date: Fri, 31 Mar 2006 11:08:34 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4E9A@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAbwYCAADH+b8AAKNt7Q From: "Stastny Richard" To: "Hadriel Kaplan" , X-Spam-Score: 0.6 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: speermint@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 > The confusion is that from the operator's perspective, they should > absolutely have the right to only allow specific users to join their > collection of sip proxies/registrars/etc. Just like a bank running a web > server has the right to only give their paying customers access to their > server. >=20 > The very concepts of SIP/HTTP challenge-response, or mutual-TLS, or any > > such > authentication mechanisms defined by IETF working groups tacitly implies > to > me that the operator of the proxy/registrar has an IETF-sanctioned right > to > reject unauthorized users from joining his collection of > proxies/registrars. >=20 > Do we agree on that? It is IMHO not so simple Of course a proxy/registrar/provider may reject unauthorized users i.e. non-subscribers from accessing his collection of proxies. But we are talking in SPEERMINT about the right of rejecting "unauthorized" access BETWEEN providers. There is an old problem of a difference between the Internet and the PSTN lurking here in the background of the discussion:=20 public and private. On the PSTN, or better at the Telephony service as defined in ITU-T E.105, there is a clear distinction between public and private, which is not existing on the Internet. On the PSTN there is the definition of a User-Network-Interface (UNI) and an Network-Network-Interface (NNI). On these interfaces even different protocols are used e.g. SS7/ISUP/R2 etc and ISDN/D-Channel. The information transmitted differs, e.g. regarding=20 Calling Line Identification. The interface between the UA and the proxy may be mapped to a UNI, the interface between providers may be mapped to a NNI. So spearmint seems to deal with NNIs. This seems easy, but the is the problems of enterprises. In the PSTN e.g. an enterprise PBX is ALWAYS connected via an UNI and the appropriate protocol, on the Internet an enterprise may also run a proxy and is within scope of spearmint. There is no distinction here. There is an additional implication with public and private: if you are providing a service for the public or not. And Telephony is a very special public service. In all European Telecommunication Laws there is the definition of a Public Available Telecommunicatios Services (the infamous PATS), which implies some rights and obligations. One of it is the obligation to interconnect (an other obligation is the=20 Provision of emergency services, in some countries with PATS comes the "right" to participate in NP). And here we are with E.164 numbers: the obligation for interconnection is for historical reasons only related to E.164 numbers, not for SIP URIs. Of course private networks on the PSTN are not required to=20 interconnect. This implies that the status quo with all VoIP Providers is the following, even if they provide PATS services: they run their service related to SIP URIs like private networks, because the PATS obligations relate only to E.164 numbers. The obligation to interconnect with E.164 can easily be fulfilled via taking the PSTN as default. If they are clever, they join a private ENUM federation to add in ADDITION a peering with selected partners, but the PSTN is always there as default for all other numbers. This works, but only for E.164 numbers and PSTN-related services (e.g. voice). This causes some problems with spearmint: 1. E.164 numbers are out of scope in spearmint, so is the PSTN 2. Peering/interconnection is done only with SIP URIs (even if these are derived via ENUM from E.164 numbers). 3. All potential SIP services apply, so again the PSTN is no default option. But: there is of course no equivalent to a PATS SIP service, also no distinction between public and private, and also no obligation to interconnect. We should be a bit careful here: Of course we could take it easy and say: who cares about PATS, E.164 numbers and related obligations. On the other hand, the (public) Internet is also, as the name implies, a service for the public. If we ignore these issues, we should consider the implications and eventual outcome: 1. All communications will sooner or later be based on IP technology 2. Laws and their obligations will also be around for some time so if existing PSTN networks migrate to NGN (=3DIP based technology), they will also have to take over some of these obligations. One of these will be the obligation to interconnect via E.164 numbers. Either we deal with these issues also on the public Internet and with our native naming and addressing schemes (SIP URIs) or we force the NGNs even more (they are bound to do this anyway) to build their own "Internet" (e.g. the GSMA IPX) and also to use E.164 numbers forever. This is one reason why I would like to see a default peering in spearmint for SIP URIs The second reason is that we should also consider the customer (end-user) expectations - and this is global reachability with SIP URIs Regards Richard > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, March 31, 2006 6:11 AM > To: henry@pulver.com; 'Patrick Melampy'; 'Otmar Lendl'; 'Michael Hammer > (mhammer)' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Definition of "Peering" >=20 > Hi Henry, > Comments inline... >=20 > > -----Original Message----- > > From: Henry Sinnreich [mailto:henry@pulver.com] > > Sent: Thursday, March 30, 2006 4:23 PM > > > > Users pay for Internet access service, which seems to be a booming > > business. >=20 > Well I can't speak for it being a booming business or not, but I think > what > you said is exactly right about Internet access - and shows the confusion > caused by us using the same words but possibly meaning different things. >=20 > It is absolutely true that people pay for "Internet Access", and Internet > access is what they should get for that payment. If you want to install a > sip phone on your PC and make a point-to-point sip call to your friend - > that should be possible. If you want to point your sip phone to the proxy > or registrar of your choosing, so long as the owner of the registrar/proxy > you choose agrees - then that should be possible. As should best-effort > forwarding of any IP packets of any port numbers using any transport layer > of your choosing to anywhere routable/reachable in the Internet, so long > as > the far-end IP-Address destination allows it... you get the idea. >=20 > The IETF is a completely inappropriate place to discuss NOT allowing that. > In my opinion, it MUST be the case that NO output of this WG describes > blocking such best-effort "Internet Access" traffic, or blocking the > ability > to do that with your SIP UA. >=20 > So when you say "end-to-end" or "e2e" - is that what you mean? Being able > to create sip sessions either directly from your PC to your friend's PC? > As > well as through proxies of your choosing, so long as the proxies you chose > allow you to? If so, I think we agree. >=20 > To some of us, the confusion comes about because the word "access" has a > special connotation for voip providers about customers joining and > creating > sip sessions through a specific collection of sip proxies/registrars. The > joining can be explicit through challenged registration means, or implicit > through static configuration, or whatever. >=20 > The confusion is that from the operator's perspective, they should > absolutely have the right to only allow specific users to join their > collection of sip proxies/registrars/etc. Just like a bank running a web > server has the right to only give their paying customers access to their > server. >=20 > The very concepts of SIP/HTTP challenge-response, or mutual-TLS, or any > such > authentication mechanisms defined by IETF working groups tacitly implies > to > me that the operator of the proxy/registrar has an IETF-sanctioned right > to > reject unauthorized users from joining his collection of > proxies/registrars. >=20 > Do we agree on that? >=20 > -hadriel >=20 >=20 >=20 > _______________________________________________ > 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 Fri Mar 31 09:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPKjD-0008KR-1O; Fri, 31 Mar 2006 09:35:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPKjB-0008KM-T7 for speermint@ietf.org; Fri, 31 Mar 2006 09:35:53 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPKjB-0005SF-Bb for speermint@ietf.org; Fri, 31 Mar 2006 09:35:53 -0500 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AE4301DC; Fri, 31 Mar 2006 09:35:47 -0500 From: "Hadriel Kaplan" To: "'Stastny Richard'" , Subject: RE: [Speermint] Definition of "Peering" Date: Fri, 31 Mar 2006 09:35:55 -0500 Message-ID: <00da01c654d0$6b781380$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAbwYCAADH+b8AAKNt7QAAxmW5A= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4E9A@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: speermint@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 Richard, Of course it isn't so simple, but I'm trying to walk there instead of skipping straight to the meat - because I'm not sure we have a common ground of understanding. I know SPEARMINT is for peering - but without defining peering of what and whom and (most importantly) why, in a way that is acceptable to the IETF, we'll never get anywhere, IMHO. For example, one of the arguments I heard people raised at IETF 65 was "what about this is the Internet? The I in IETF is for Internet, so this group is out of scope." First, it is obviously untrue that the IETF only concerns itself with the ip network transport layer, nor of routing protocols to create an Internet. One need only look at the areas and working groups to see that. It's not only layer 3 protocols being defined. Second, there is one area actually titled "Internet Area", yet even within that area are groups who's entire existence in life is to define VPNs, at layers 2 and 3. How are VPNs the Internet? Extending that idea, there are IETF groups who are (or were last time I was at the IETF) working to define how such VPNs can work between providers, and bridge the VPNs together. For me, if that is acceptable work for the IETF, then there should also be a case for allowing layer-5 VPNs to be bridged together. And that's only if you look at it one way (as L5 VPNs). There are other ways to look at it that I think make it acceptable as well. -hadriel p.s. note these are my views, and may not represent those of my employer whatsoever. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 31, 2006 4:09 AM > To: Hadriel Kaplan; henry@pulver.com > Cc: speermint@ietf.org > Subject: RE: [Speermint] Definition of "Peering" > > > > > The confusion is that from the operator's perspective, they should > > absolutely have the right to only allow specific users to join their > > collection of sip proxies/registrars/etc. Just like a bank running a > web > > server has the right to only give their paying customers access to > their > > server. > > > > The very concepts of SIP/HTTP challenge-response, or mutual-TLS, or > any > > such > > authentication mechanisms defined by IETF working groups tacitly > implies > > to > > me that the operator of the proxy/registrar has an IETF-sanctioned > right > > to > > reject unauthorized users from joining his collection of > > proxies/registrars. > > > > Do we agree on that? > > It is IMHO not so simple > > Of course a proxy/registrar/provider may reject unauthorized users > i.e. non-subscribers from accessing his collection of proxies. > > But we are talking in SPEERMINT about the right of rejecting > "unauthorized" > access BETWEEN providers. > > There is an old problem of a difference between the Internet and > the PSTN lurking here in the background of the discussion: > public and private. > > On the PSTN, or better at the Telephony service as defined in ITU-T > E.105, > there is a clear distinction between public and private, which is > not existing on the Internet. On the PSTN there is the definition of > a User-Network-Interface (UNI) and an Network-Network-Interface (NNI). > On these interfaces even different protocols are used e.g. SS7/ISUP/R2 > etc > and ISDN/D-Channel. The information transmitted differs, e.g. regarding > Calling Line Identification. > > The interface between the UA and the proxy may be mapped to a UNI, the > interface between providers may be mapped to a NNI. So spearmint > seems to deal with NNIs. This seems easy, but the is the problems of > enterprises. In the PSTN e.g. an enterprise PBX is ALWAYS connected via > an UNI and the appropriate protocol, on the Internet an enterprise may > also run a proxy and is within scope of spearmint. There is no > distinction > here. > > There is an additional implication with public and private: if you > are providing a service for the public or not. And Telephony is > a very special public service. In all European Telecommunication > Laws there is the definition of a Public Available Telecommunicatios > Services (the infamous PATS), which implies some rights and obligations. > One of it is the obligation to interconnect (an other obligation is the > Provision of emergency services, in some countries with PATS comes the > "right" to participate in NP). > > And here we are with E.164 numbers: the obligation for interconnection > is for historical reasons only related to E.164 numbers, not for SIP > URIs. Of course private networks on the PSTN are not required to > interconnect. > > This implies that the status quo with all VoIP Providers is the > following, even if they provide PATS services: > they run their service related to SIP URIs like private networks, > because the PATS obligations relate only to E.164 numbers. > > The obligation to interconnect with E.164 can easily be fulfilled > via taking the PSTN as default. If they are clever, they join a > private ENUM federation to add in ADDITION a peering with selected > partners, but the PSTN is always there as default for all other > numbers. This works, but only for E.164 numbers and PSTN-related > services (e.g. voice). > > This causes some problems with spearmint: > > 1. E.164 numbers are out of scope in spearmint, so is the PSTN > 2. Peering/interconnection is done only with SIP URIs (even > if these are derived via ENUM from E.164 numbers). > 3. All potential SIP services apply, so again the PSTN is no > default option. > > But: there is of course no equivalent to a PATS SIP service, > also no distinction between public and private, > and also no obligation to interconnect. > > We should be a bit careful here: > > Of course we could take it easy and say: who cares about PATS, > E.164 numbers and related obligations. > > On the other hand, the (public) Internet is also, as the name > implies, a service for the public. If we ignore these issues, > we should consider the implications and eventual outcome: > > 1. All communications will sooner or later be based on IP technology > 2. Laws and their obligations will also be around for some time > so if existing PSTN networks migrate to NGN (=IP based technology), > they will also have to take over some of these obligations. > > One of these will be the obligation to interconnect via E.164 numbers. > > Either we deal with these issues also on the public Internet > and with our native naming and addressing schemes (SIP URIs) > or we force the NGNs even more (they are bound to do this anyway) > to build their own "Internet" (e.g. the GSMA IPX) and also to use > E.164 numbers forever. > > This is one reason why I would like to see a default peering > in spearmint for SIP URIs > > The second reason is that we should also consider the customer > (end-user) expectations - and this is global reachability > with SIP URIs > > Regards > > Richard > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Friday, March 31, 2006 6:11 AM > > To: henry@pulver.com; 'Patrick Melampy'; 'Otmar Lendl'; 'Michael > Hammer > > (mhammer)' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Definition of "Peering" > > > > Hi Henry, > > Comments inline... > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > Sent: Thursday, March 30, 2006 4:23 PM > > > > > > Users pay for Internet access service, which seems to be a booming > > > business. > > > > Well I can't speak for it being a booming business or not, but I think > > what > > you said is exactly right about Internet access - and shows the > confusion > > caused by us using the same words but possibly meaning different > things. > > > > It is absolutely true that people pay for "Internet Access", and > Internet > > access is what they should get for that payment. If you want to > install a > > sip phone on your PC and make a point-to-point sip call to your friend > - > > that should be possible. If you want to point your sip phone to the > proxy > > or registrar of your choosing, so long as the owner of the > registrar/proxy > > you choose agrees - then that should be possible. As should > best-effort > > forwarding of any IP packets of any port numbers using any transport > layer > > of your choosing to anywhere routable/reachable in the Internet, so > long > > as > > the far-end IP-Address destination allows it... you get the idea. > > > > The IETF is a completely inappropriate place to discuss NOT allowing > that. > > In my opinion, it MUST be the case that NO output of this WG describes > > blocking such best-effort "Internet Access" traffic, or blocking the > > ability > > to do that with your SIP UA. > > > > So when you say "end-to-end" or "e2e" - is that what you mean? Being > able > > to create sip sessions either directly from your PC to your friend's > PC? > > As > > well as through proxies of your choosing, so long as the proxies you > chose > > allow you to? If so, I think we agree. > > > > To some of us, the confusion comes about because the word "access" has > a > > special connotation for voip providers about customers joining and > > creating > > sip sessions through a specific collection of sip proxies/registrars. > The > > joining can be explicit through challenged registration means, or > implicit > > through static configuration, or whatever. > > > > The confusion is that from the operator's perspective, they should > > absolutely have the right to only allow specific users to join their > > collection of sip proxies/registrars/etc. Just like a bank running a > web > > server has the right to only give their paying customers access to > their > > server. > > > > The very concepts of SIP/HTTP challenge-response, or mutual-TLS, or > any > > such > > authentication mechanisms defined by IETF working groups tacitly > implies > > to > > me that the operator of the proxy/registrar has an IETF-sanctioned > right > > to > > reject unauthorized users from joining his collection of > > proxies/registrars. > > > > Do we agree on that? > > > > -hadriel > > > > > > > > _______________________________________________ > > 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 Fri Mar 31 11:54:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPMtH-0007Aj-Ea; Fri, 31 Mar 2006 11:54:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPMtF-0007AW-OZ for speermint@ietf.org; Fri, 31 Mar 2006 11:54:25 -0500 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPMtF-0002zs-Bw for speermint@ietf.org; Fri, 31 Mar 2006 11:54:25 -0500 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id 412359ADB6D; Fri, 31 Mar 2006 16:54:10 +0000 (UTC) Received: from mail59-ash-R.bigfish.com (unknown [172.18.2.1]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id 3F9659ADA52; Fri, 31 Mar 2006 16:54:10 +0000 (UTC) Received: from mail59-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail59-ash-R.bigfish.com (Postfix) with ESMTP id 353DC61163C; Fri, 31 Mar 2006 16:54:10 +0000 (UTC) X-BigFish: V Received: by mail59-ash (MessageSwitch) id 114382405041066_12831; Fri, 31 Mar 2006 16:54:10 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail59-ash.bigfish.com (Postfix) with ESMTP id C57396102E6; Fri, 31 Mar 2006 16:54:09 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k2VGs9Vv004852; Fri, 31 Mar 2006 10:54:09 -0600 (CST) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2VGs9002667; Fri, 31 Mar 2006 10:54:09 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 31 Mar 2006 10:54:09 -0600 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: More concrete proposals (was RE: [Speermint] Speermint proposal) Date: Fri, 31 Mar 2006 10:54:08 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E0701D3EF@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More concrete proposals (was RE: [Speermint] Speermint proposal) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAACJ8vwAADMH2AAAGU10AAnEuxw From: "Khan, Sohel Q [CTO]" To: "Malas, Daryl" , "Reinaldo Penno" , X-OriginalArrivalTime: 31 Mar 2006 16:54:09.0140 (UTC) FILETIME=[BA96EB40:01C654E3] X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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 I think, we need to extend Daryl's proposed draft to a "peering security" draft that addresses all security issues in addition to authentication. =20 -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Thursday, March 30, 2006 4:22 PM To: Reinaldo Penno; speermint@ietf.org Subject: RE: More concrete proposals (was RE: [Speermint] Speermint proposal) Okay, so I have an additional proposal, which I think will be necessary as well: A draft for "peering authentication", with an example continued within your's below... "Ispa and ispb have an established commercial agreement and a configuration as a consequence of that (which is out of scope)." ISPA sends a PROXY REGISTER message to ISPB. ISPB responds with a 401 Unauthorized. ISPA sends a PROXY REGISTER with HTTP/AUTH credentials to ISPB. ISPB responds with 200 OK and "Proxy-auth" key. The auth key is cached by ISPA. "alice@ispa.com registers, decides to call bob@ispb.com." "alice sends a invite to proxy.ispa.com, which performs a DNS lookup on ispb.com, finds out the ispb.com's proxy is proxy.ispb.com." proxy.ispa.com includes "Proxy-auth" key in INVITE from alice as authorization for the peering relationship. ISPB looks for "Proxy-auth" key and allows alice's call to continue to bob. I know this is overly simplistic, but I think this WG must define a mechanism similar to this. This will be critical for securing SIP signaling between peers. Daryl M. daryl.malas@level3.com Ernest Hemingway - "Never mistake motion for action." -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, March 30, 2006 3:10 PM To: speermint@ietf.org Subject: More concrete proposals (was RE: [Speermint] Speermint proposal) More concrete proposals: The "routing architecture" part of draft-bathia and draft-khan could possibly be combined in one draft. This would present an overall of the parts, functions, etc We should then have another draft that details the "message flows and routing" as stated in the charter. For example (this is my quick and dirt version to get something going): alice@ispa.com registers, decides to call bob@ispb.com. alice sends a invite to proxy.ispa.com, which performs a DNS lookup on ispb.com, finds out the ispb.com's proxy is proxy.ispb.com. At this point we have two scenarios: Ispa and ispb have an established commercial agreement and a configuration as a consequence of that (which is out of scope). proxya and proxyb never talked to each other and then will determine if they meet the "minimum requirements" as stated in the charter to talk each other. This could be establishing a TLS connection or whatever. thanks, Reinaldo > -----Original Message----- > From: Reinaldo Penno > Sent: Thursday, March 30, 2006 1:56 PM > To: speermint@ietf.org > Subject: [Speermint] Speermint proposal >=20 > I mentioned in a different message that we should try to rephrase the=20 > charter to be more specific/focused. >=20 > Today the charter states >=20 > " More specifically, SPEERMINT focuses on real-time session routing=20 > architectures and their associated use cases. > Deliverables here include the specification of the various types of=20 > application flows, such as signaling and media flows, in such=20 > networks, and includes both trunking and peer-to-peer flows. In=20 > addition, SPEERMINT considers and documents requirements for the=20 > feedback of operational conditions (e.g., congestion control) that=20 > enables the application of dynamic policy and recognizes that various=20 > mechanisms for achieving this should be studied as a potential part of > any architecture." >=20 > This seems quite broad; much more than enabling Sip message from domain > A to reach B. >=20 > Further down it states: >=20 > " The most focused deliverables of SPEERMINT are best current practices > regarding exchange of real-time sessions among VoIP and other=20 > real-time application service providers and, in particular, how such=20 > calls are routed." >=20 > I believe maybe this should be our focus, i.e., "in particular how such > calls are routed". We should solidify the terminology draft, which is > the starting point and in parallel work on the scenarios on how such=20 > calls would be routed. Let's put the "new" requirements aside for the=20 > time being. If we identify a missing piece, then we could work it as=20 > necessary. >=20 > On the other hand, it might be that we come up with a routing=20 > scenarios/message flows documents and find out that the important pieces > are there. This would not be wasted work, I'm sure these would be very > important documents. >=20 > It seems very hard to make progress without some document to base our=20 > discussions. >=20 > My 2 cents, >=20 > Reinaldo >=20 >=20 > > -----Original Message----- > > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > > Sent: Thursday, March 30, 2006 12:45 PM > > To: Stastny Richard; Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Speermint Charter > > > > Richard, > > > > I responded to soon before. You have a good point. So what you are > > suggesting is peering can encompass multiple SIP based services (P2P, > > ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? > > > > Thanks... > > > > Daryl M. > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, March 30, 2006 1:34 PM > > To: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Speermint Charter > > > > Hi Sohel, > > > > This is no so simple > > > > 1. P2P SIP has a complete different charter 2. What if a P2P network > > is provided by a provider who wants to peer with another provider? > > > > Richard > > > > ________________________________ > > > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Gesendet: Do 30.03.2006 22:03 > > An: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Betreff: [Speermint] Speermint Charter > > > > > > > > IMHO, IETF community wants to solve VoIP peering problem in two major > > ways: e2e/p2p and interprovider/interdomain. > > > > I hope that IETF will try to address those separately as follows: > > > > P2P SIP BOF/WG: E2E/p2p peering > > > > SPEERMINT WG: Interprovider/interdomain peering > > > > > > > > Thank you. > > > > Sohel Khan > > > > > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > > 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 _______________________________________________ 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Mar 31 11:58:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPMxa-00081y-RM; Fri, 31 Mar 2006 11:58:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPMxa-00081t-3K for speermint@ietf.org; Fri, 31 Mar 2006 11:58:54 -0500 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPMxZ-00035a-Nr for speermint@ietf.org; Fri, 31 Mar 2006 11:58:54 -0500 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id 5864F9AD8C5; Fri, 31 Mar 2006 16:58:31 +0000 (UTC) Received: from mail56-ash-R.bigfish.com (unknown [172.18.2.1]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id 3FFC39AD89A; Fri, 31 Mar 2006 16:58:26 +0000 (UTC) Received: from mail56-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail56-ash-R.bigfish.com (Postfix) with ESMTP id 8ABB34AAA1B; Fri, 31 Mar 2006 16:58:22 +0000 (UTC) X-BigFish: V Received: by mail56-ash (MessageSwitch) id 1143824302477651_8211; Fri, 31 Mar 2006 16:58:22 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail56-ash.bigfish.com (Postfix) with ESMTP id 5F38D4AAA06; Fri, 31 Mar 2006 16:58:22 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k2VGwLo0011877; Fri, 31 Mar 2006 10:58:21 -0600 (CST) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2VGwKu15178; Fri, 31 Mar 2006 10:58:21 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 31 Mar 2006 10:58:20 -0600 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: More concrete proposals (was RE: [Speermint] Speermint proposal) Date: Fri, 31 Mar 2006 10:58:19 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E0701D409@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More concrete proposals (was RE: [Speermint] Speermint proposal) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAACJ8vwAADMH2AAJ6lZUA== From: "Khan, Sohel Q [CTO]" To: "Reinaldo Penno" , X-OriginalArrivalTime: 31 Mar 2006 16:58:20.0918 (UTC) FILETIME=[50A93160:01C654E4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 >From my side, you are welcome to be an author to combine these two drafts as you mentioned to create another draft. -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, March 30, 2006 4:10 PM To: speermint@ietf.org Subject: More concrete proposals (was RE: [Speermint] Speermint proposal) More concrete proposals: The "routing architecture" part of draft-bathia and draft-khan could possibly be combined in one draft. This would present an overall of the parts, functions, etc We should then have another draft that details the "message flows and routing" as stated in the charter. For example (this is my quick and dirt version to get something going): alice@ispa.com registers, decides to call bob@ispb.com. alice sends a invite to proxy.ispa.com, which performs a DNS lookup on ispb.com, finds out the ispb.com's proxy is proxy.ispb.com. At this point we have two scenarios: Ispa and ispb have an established commercial agreement and a configuration as a consequence of that (which is out of scope). proxya and proxyb never talked to each other and then will determine if they meet the "minimum requirements" as stated in the charter to talk each other. This could be establishing a TLS connection or whatever. thanks, Reinaldo > -----Original Message----- > From: Reinaldo Penno > Sent: Thursday, March 30, 2006 1:56 PM > To: speermint@ietf.org > Subject: [Speermint] Speermint proposal >=20 > I mentioned in a different message that we should try to rephrase the=20 > charter to be more specific/focused. >=20 > Today the charter states >=20 > " More specifically, SPEERMINT focuses on real-time session routing=20 > architectures and their associated use cases. > Deliverables here include the specification of the various types of=20 > application flows, such as signaling and media flows, in such=20 > networks, and includes both trunking and peer-to-peer flows. In=20 > addition, SPEERMINT considers and documents requirements for the=20 > feedback of operational conditions (e.g., congestion control) that=20 > enables the application of dynamic policy and recognizes that various=20 > mechanisms for achieving this should be studied as a potential part of > any architecture." >=20 > This seems quite broad; much more than enabling Sip message from domain > A to reach B. >=20 > Further down it states: >=20 > " The most focused deliverables of SPEERMINT are best current practices > regarding exchange of real-time sessions among VoIP and other=20 > real-time application service providers and, in particular, how such=20 > calls are routed." >=20 > I believe maybe this should be our focus, i.e., "in particular how such > calls are routed". We should solidify the terminology draft, which is > the starting point and in parallel work on the scenarios on how such=20 > calls would be routed. Let's put the "new" requirements aside for the=20 > time being. If we identify a missing piece, then we could work it as=20 > necessary. >=20 > On the other hand, it might be that we come up with a routing=20 > scenarios/message flows documents and find out that the important pieces > are there. This would not be wasted work, I'm sure these would be very > important documents. >=20 > It seems very hard to make progress without some document to base our=20 > discussions. >=20 > My 2 cents, >=20 > Reinaldo >=20 >=20 > > -----Original Message----- > > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > > Sent: Thursday, March 30, 2006 12:45 PM > > To: Stastny Richard; Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Speermint Charter > > > > Richard, > > > > I responded to soon before. You have a good point. So what you are > > suggesting is peering can encompass multiple SIP based services (P2P, > > ENUM, SIMPLE, etc.), and should not be limited to basic SIP telephony? > > > > Thanks... > > > > Daryl M. > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, March 30, 2006 1:34 PM > > To: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Speermint Charter > > > > Hi Sohel, > > > > This is no so simple > > > > 1. P2P SIP has a complete different charter 2. What if a P2P network > > is provided by a provider who wants to peer with another provider? > > > > Richard > > > > ________________________________ > > > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Gesendet: Do 30.03.2006 22:03 > > An: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Betreff: [Speermint] Speermint Charter > > > > > > > > IMHO, IETF community wants to solve VoIP peering problem in two major > > ways: e2e/p2p and interprovider/interdomain. > > > > I hope that IETF will try to address those separately as follows: > > > > P2P SIP BOF/WG: E2E/p2p peering > > > > SPEERMINT WG: Interprovider/interdomain peering > > > > > > > > Thank you. > > > > Sohel Khan > > > > > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > > 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 _______________________________________________ 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 Fri Mar 31 13:28:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOLo-00081u-V1; Fri, 31 Mar 2006 13:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOLn-00081o-Gt for speermint@ietf.org; Fri, 31 Mar 2006 13:27:59 -0500 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound1-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPOLm-0007q6-OU for speermint@ietf.org; Fri, 31 Mar 2006 13:27:59 -0500 Received: from outbound1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-res-R.bigfish.com (Postfix) with ESMTP id 7AF7E492111; Fri, 31 Mar 2006 18:27:58 +0000 (UTC) Received: from mail1-res-R.bigfish.com (unknown [172.18.16.1]) by outbound1-res.bigfish.com (Postfix) with ESMTP id 78A3F4920C7; Fri, 31 Mar 2006 18:27:58 +0000 (UTC) Received: from mail1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail1-res-R.bigfish.com (Postfix) with ESMTP id 6C64F62086F; Fri, 31 Mar 2006 18:27:58 +0000 (UTC) X-BigFish: V Received: by mail1-res (MessageSwitch) id 1143829678277945_13993; Fri, 31 Mar 2006 18:27:58 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail1-res.bigfish.com (Postfix) with ESMTP id 25DD06207EC; Fri, 31 Mar 2006 18:27:58 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k2VIRhTH019447; Fri, 31 Mar 2006 12:27:43 -0600 (CST) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2VIRf020988; Fri, 31 Mar 2006 12:27:41 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 31 Mar 2006 12:27:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Fri, 31 Mar 2006 12:27:39 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E070EC024@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZT3Qzkm3HikdwGTKiZyiL2GEEdHABE2esA From: "Khan, Sohel Q [CTO]" To: "Drage, Keith \(Keith\)" , "Stastny Richard" , "Paul Kyzivat" , "Bob Natale" X-OriginalArrivalTime: 31 Mar 2006 18:27:41.0230 (UTC) FILETIME=[CBA7E4E0:01C654F0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 86914b0033efd24523ee4a427c36d849 Cc: speermint@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 How the providers should bill each other should be out of scope of = SPEERMINT. However, SPEERMINT needs to define parameters by which account = information may be exchanged between two providers. The accounting information may be packet level or session level or both. =20 -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Thursday, March 30, 2006 3:33 AM To: 'Stastny Richard'; 'Paul Kyzivat'; 'Bob Natale' Cc: 'speermint@ietf.org' Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging I am sure we could get into all sorts of philosophical discussions on = this, but let's just postulate one question: How much of the items you spend money on in a year are actually based on = the cost of providing the service, and how much is based on what the = market will bear? And I don't see it being any different for most ISPs either. But anyway surely those issues are irrelevant for SPEERMINT. What SPEERMINT needs to deal with is how each operator accounts to = another operator for the traffic that one delivers to the other. In 3GPP = that is dealt with primarily by the exchange of IOI parameters over SIP. = At the SIP level the account is not exchanged between operators, merely = an indicator of the operator that the traffic has been passed to. regards Keith > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 29 March 2006 15:05 > To: Paul Kyzivat; Bob Natale > Cc: speermint@ietf.org > Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging >=20 >=20 > Exactly >=20 > Richard >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, March 29, 2006 3:58 PM > > To: Bob Natale > > Cc: Stastny Richard; speermint@ietf.org > > Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging > >=20 > >=20 > >=20 > > Bob Natale wrote: > > > > > > Hi Richard, > > > > > > 1. Your point about the possible relevance for > SPEERMINT's scope of > > accounting requirements, and not billing requirements, is > well-taken and > > will be reflected clearly in the next rev of the > Requirements BCP draft. > > > > > > 2. Wrt your comment: "3. So why is it necessary to > charge termination > > fees to the O-user at all for SIGNALLING?": > > > Might it not be true that some applications of value to > the user might > > involve signaling only, and not media per se? (I am > thinking of certain > > presence and notification apps...?) > >=20 > > What does that change? > >=20 > > IMO it makes sense to charge for services actually > rendered, and not for > > services the SP isn't involved in but wishes they could get > some revenue > > from. > >=20 > > The terminating proxy does render some identifiable > services that could > > potentially be charged for: > > - supplying the AOR > > - processing (routing) requests to the AOR > >=20 > > These are of value precisely because they eliminate the > need for the end > > user to keep a UA online at all times, and because it > permits the end > > user to dynamically associate UAs with the AOR, by providing a=20 > > potentially recognized and trusted domain. > >=20 > > This doesn't seem like stuff that justifies per-use > charging, and the > > amount of charging that can be extracted for these basic services is = > > probably limited, but its something. > >=20 > > If an SP wants to charge more, then they will have to provide more=20 > > services - ones that users are interested in paying for. > >=20 > > Paul > >=20 > > > Cheers, > > > BobN > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, March 29, 2006 6:08 AM > > > To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; > speermint@ietf.org > > > Subject: [Speermint] Billing, Accounting, Tariffing and Charging > > > > > > > > >>>These are not rhetoric questions; I really do not know > the answer. > > > > > > > > > Welcome to the club, you are not alone ;-) > > > > > > > > >>>VoIP is exactly the opposite. VoIP (signaling and media) > are delay > > >> > > >>sensitive, need > > >> > > >>>prioritization and will be billed. > > >>> > > >> > > >>Good point. What we need is to separate the problem of > peering into at > > >>least two parts: terminating the call and the traffic itself (data > > part). > > >>The email model applies only to the termination part. > > > > > > > > > Hmmm, I think it is even more complicated. > > > > > > Terminology: > > > > > > Billing is between end-users and a SP (out of scope in spearmint) > > Accounting is between SP (in scope of spearmint?) Tariffing is the=20 > > calculation of a charge for using a certain resource for a > certain amount > > of time. > > > > > > I consider it also paradox that we are discussing accounting and > > charging, particularly termination charges (fees) 1. in a > time even in the > > PSTN issues are moving to bill-and-keep 2. on an > inappropriate layer (L5) > > > > > > A substantial part of the problems with VoIP peering > derives not from > > trust, QoS, SPIT, etc. problems, but simply how to keep up > the existing > > regime of termination fees. > > > > > > Especially mobile operators make a living on this. > > > > > > Where is this problem coming from on the PSTN? > > > (Lets for a moment forget problems caused by reverse > > > charging) > > > > > > In the PSTN there was originally an accounting regime based on > > cascading. The O-SP bills the O-user for the call (based on > distance), and > > keeping part of it and paying out part to the next (transit) SP. > > > This goes on until the destination > > > (T-SP) is reached, which also gets a share. > > > > > > The implicit assumptions here are: the originator has the > benefit of the > > call and also call set-up is in one direction and call > signalling and the > > mediastream is traversing all networks in question. > > > > > > This principle is only broken with call forwarding and > also with mobile > > roaming. In the US also the mobile T-user pays air-time, > not so in Europe, > > hence the problems with mobile NP > > > > > > Note: in my remark to my previous post on terminating > network monopoly > > (SMP), one may consider the termination fee also as a > compensation for the > > remedy that a terminating network MUST accept any call. > > > > > > This regime was quite simple, but was more and more > complicated over > > time by burdening it with additional issues such as > subsidies, etc. as it > > is currently in the US. > > > > > > > > > What does this imply now for VoIP peering or interconnect > > > > > > VoIP; RTC and IP separate signalling (L5) from transport > (L3) It also > > separates the SP from the access Now taking into account some facts: > > > > > > 1. Although SIP signalling (call set-up) is directed from > O to T, the > > mediastream is both ways and symmetric (so much for Whitacre, he may = > > eventually blame Google Video, but not VoIP providers) > > > > > > 2. The cost for the mediastream is moving more and more > to the ends > > (access), even in the PSTN (see the latest OFCOM report on distance=20 > > gradients), and the access is already paid in some way or > the other by the > > end-users. > > > > > > 3. So why is it necessary to charge termination fees to > the O-user at > > all for SIGNALLING? > > > > > > There is one issue where termination fees may apply > (although this is > > going away also - e.g. > > > Voipbuster): if you connect to the PSTN. > > > > > > But this is out of scope in Speermint and in addition > solutions exist > > here since years. > > > > > > My recommendation is that as long as speermint is dealing with L5 > > peering only, accounting i.e. termination fees should not > be dealt with. > > > > > > Cheers > > > > > > Richard > > > > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > >>Sent: Wednesday, March 29, 2006 4:28 AM > > >>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > >>Subject: RE: [Speermint] Comments on > > >>reqs-and-terminology-01andpolicy-dds- > > >>00(Peerign concepts and others..) > > >> > > >>Hi Reinaldo, > > >> > > >> > > >>>-----Original Message----- > > >>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > > >>>Sent: Tuesday, March 28, 2006 8:31 PM > > >>>To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > > >>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > >>>andpolicy- > > >> > > >>dds-00(Peerign > > >> > > >>>concepts and others..) > > >>> > > >>>Hello, > > >>> > > >>>I tend to agree that the email model sounds attractive except the = > > >>>delay > > >> > > >>and business > > >> > > >>>requirements of email and VoIP are quire different. > > >>> > > >>>Email is not delay sensitive, does not require any type of > > >> > > >>prioritization and is not charged > > >> > > >>>(or at least it wasn't). > > >>> > > >>>VoIP is exactly the opposite. VoIP (signaling and media) > are delay > > >> > > >>sensitive, need > > >> > > >>>prioritization and will be billed. > > >>> > > >> > > >>Good point. What we need is to separate the problem of > peering into at > > >>least two parts: terminating the call and the traffic itself (data > > part). > > >>The email model applies only to the termination part. > > >> > > >> > > >>>I believe a call to a public number is (or should) > always going to > > >>>be > > >> > > >>routable. I guess my > > >> > > >>>main question is: is the general belief that VoIP providers will=20 > > >>>just > > >> > > >>configure their proxy > > >> > > >>>servers to talk to each other in an email type model? No business > > >> > > >>agreements similar to > > >> > > >>>PSTN/Wireless, no charging, no extra billing for "roaming", etc? > > >>> > > >> > > >>I agree those are issues. It would be good if we can work out=20 > > >>something which is generic (compared to IMS/PSTN > specific). Maybe they > > >>are out of scope since we are dealing with protocol and > architecture > > >>issues in the WG. The only aspect billing and roaming > affect is that > > >>if all technical requirements (e.g the ones this WG specifies) are = > > >>satisfied, the peer could still reject traffic (w/o consulting the = > > >>destination user, in Richard's terms) if the commercial > relationship > > >>does not exist. I think this is what hampers connectivity > today. All > > >>these commercial relationships exist because SPs want to > be layer 5 > > >>aware (they cannot seem to find a way to evolve their > business models > > >>otherwise... :), where only the origination SP (Core-O) and Core-T = > > >>need to have a commercial relationship. The roaming > aspect again may > > >>be quite artificial and could be questionable going > forward... Just my > > personal comments. > > >> > > >>-Medhavi. > > >> > > >> > > >>>My reply to David's email was more to the idea that you > can install > > >>>a > > >> > > >>proxy server > > >> > > >>>somewhere, point the "MX" to the next upstream "proxy > server" and be > > >> > > >>done with it? As > > >> > > >>>VoIP takes off wouldn't some basic regulatory issues, numbering=20 > > >>>schemes > > >> > > >>and others > > >> > > >>>prevent such behavior? > > >>> > > >>>These are not rhetoric questions; I really do not know > the answer. > > >>> > > >>>Regards, > > >>> > > >>>Reinaldo > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > >>>>Sent: Tuesday, March 28, 2006 5:13 PM > > >>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > > >>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > > >> > > >>andpolicy- > > >> > > >>>>dds-00(Peerign concepts and others..) > > >>>> > > >>>> > > >>>>>It begs the question why the two entities exchanging SIP=20 > > >>>>>signaling > > >> > > >>do > > >> > > >>>>not exchange policy > > >>>> > > >>>>>information themselves through some SIP extension/new=20 > > >>>>>protocol/ > >>>> > > >>>>name> and the > > >>>> > > >>>>>role played by DNS. I'm not advocating this model but > it seems a > > >>>> > > >>>>pertinent question. > > >>>> > > >>>>I think peering in L3 must be basic, given how fundamental L3 is = > > >>>>to > > >> > > >>the > > >> > > >>>>internet. For SIP, TRIP provides functionality similar to BGP=20 > > >>>>(only > > >> > > >>for > > >> > > >>>>phone numbers though, I think). > > >>>> > > >>>>In my opinion, SIP peering ought to follow the email model. Once > > >> > > >>location > > >> > > >>>>is done and basic requirements are satisfied at the SIP layer=20 > > >>>>(like identity etc), the call should be routable. As > Richard said > > >>>>in the > > >> > > >>earlier > > >> > > >>>>email, the destination SP may still reject or challenge the call = > > >>>>if it lacks either the basic requirements we agree to > in the WG or > > >>>>some > > >> > > >>extra > > >> > > >>>>requirements specific to the termination SP (Core-T in > my ID). The > > >>>>challenge is that in some cases there are going to be IXPs > > >> > > >>(Interconnects) > > >> > > >>>>which sit in the middle due to commercial or regulatory reasons. > > >>>>The location of an IXP, the provisioning of this IXP and the=20 > > >>>>Core-T SP are > > >> > > >>the > > >> > > >>>>architectural problems which this WG needs to solve as well. > > >>>> > > >>>>-Medhavi. > > >>>> > > >>>> > > >>>>>Regards, > > >>>>> > > >>>>>Reinaldo > > >>>>> > > >>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > >>>>>>Sent: Tuesday, March 28, 2006 3:18 PM > > >>>>>>To: Reinaldo Penno; speermint@ietf.org > > >>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01=20 > > >>>>>>and > > >>>> > > >>>>policy- > > >>>> > > >>>>>>dds-00(Peerign concepts and others..) > > >>>>>> > > >>>>>>Hi Reinaldo > > >>>>>> > > >>>>>>I am not sure the goal of SPEERMINT is to recreate L3 peering=20 > > >>>>>>at > > >> > > >>L5. > > >> > > >>>>The > > >>>> > > >>>>>>problem being solved is different in that L3 peering is always > > >> > > >>with a > > >> > > >>>>>>fixed number of neighbors. These are stored as you mention in > > >> > > >>static > > >> > > >>>>>>routing tables at each node and do not change from > call to call. > > >> > > >>In > > >> > > >>>>>>contrast, L5 peering is not necessarily static (unless you are > > >> > > >>talking > > >> > > >>>>>>about a federation model). The destination is chosen only when = > > >>>>>>the > > >>>> > > >>>>call is > > >>>> > > >>>>>>made and may be to a peer that a given service provider/domain = > > >>>>>>administrator/node has never spoken to before. > > >>>>>> > > >>>>>>Assuming DNS is used to find the peering node, the query is=20 > > >>>>>>made > > >> > > >>on a > > >> > > >>>>call > > >>>> > > >>>>>>by call basis. Now clearly, this DNS info can be cached at the > > >>>> > > >>>>originating > > >>>> > > >>>>>>node but the cache still has a very different nature than that = > > >>>>>>of > > >> > > >>an > > >> > > >>>>L3 > > >>>> > > >>>>>>routing table. > > >>>>>> > > >>>>>>Policy is an entirely different issue (as is the case in L3)=20 > > >>>>>>and > > >> > > >>it is > > >> > > >>>>>>important to separate it out from the routing issue. The draft = > > >>>>>>you > > >>>> > > >>>>mention > > >>>> > > >>>>>>about pushing policy via DNS is dealing with one out of many > > >> > > >>possible > > >> > > >>>>>>topologies - namely that of ad hoc federations. There was very > > >> > > >>little > > >> > > >>>>>>discussion about policy at IETF 65 as the foundations of L5 > > >> > > >>routing > > >> > > >>>>need > > >>>> > > >>>>>>to be cemented before the higher level policy issues can be > > >> > > >>addressed. > > >> > > >>>>>>Cheers, > > >>>>>> > > >>>>>>David > > >>>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > > >>>>>>Sent: =E2 28 =EE=F8=F5 2006 23:34 > > >>>>>>To: speermint@ietf.org > > >>>>>>Subject: [Speermint] Comments on reqs-and-terminology-01 and > > >> > > >>policy- > > >> > > >>>>dds- > > >>>> > > >>>>>>00(Peerign concepts and others..) > > >>>>>> > > >>>>>>Hello, > > >>>>>> > > >>>>>>I've been reading "reqs and terminology" and I would like to=20 > > >>>>>>step > > >> > > >>back > > >> > > >>>>>>and ask some questions about some of the definitions. > > >>>>>> > > >>>>>> > > >>>>>>Peering: > > >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>> > > >>>>>>In layer 3 peering two routers exchange their routing tables, > > >> > > >>reach a > > >> > > >>>>>>steady state, and after that data packets can flow between the = > > >>>>>>two domains. > > >>>>>> > > >>>>>>Layer 5 peering means, "interconnection of two service=20 > > >>>>>>providers > > >> > > >>for > > >> > > >>>>the > > >>>> > > >>>>>>purposes of SIP signaling". > > >>>>>> > > >>>>>>Making the inevitable comparison with layer 3 peering, there=20 > > >>>>>>are > > >> > > >>some > > >> > > >>>>>>fundamental differences that I'm trying to reconcile. > > >>>>>> > > >>>>>>1) In a traditional (a.k.a. layer 3) peering, both routers > > >> > > >>exchange > > >> > > >>>>all > > >>>> > > >>>>>>necessary routing information and enter a steady state. At=20 > > >>>>>>this > > >> > > >>point, > > >> > > >>>>>>no other routes are exchanged and routers concentrate on > > >> > > >>forwarding > > >> > > >>>>>>packets. > > >>>>>> > > >>>>>>I know the WG is in the beginning, but it is not clear to me=20 > > >>>>>>what > > >>>> > > >>>>pieces > > >>>> > > >>>>>>are needed for an equivalent functionality. For example: > > >>>>>> > > >>>>>>1) Are the entities exchanging SIP signaling for the purpose=20 > > >>>>>>of > > >>>> > > >>>>peering > > >>>> > > >>>>>>doing so on a _per call_ basis? Is there going to be some > > >> > > >>mechanism > > >> > > >>>>to > > >>>> > > >>>>>>exchange such information in bulk such as in a > routing protocol? > > >> > > >>Maybe > > >> > > >>>>>>based on domain names or something similar? > > >>>>>> > > >>>>>>2) The draft states that " A > > >>>>>> domain's ingress point can be thought of as the location > > >> > > >>pointed to > > >> > > >>>>>> by the SRV record that resulted from the resolution of the=20 > > >>>>>>CRD > > >>>> > > >>>>(i.e., > > >>>> > > >>>>>> a SIP URI)." > > >>>>>> > > >>>>>>So, it seems to me that although the "layer 5 peering" is > > >> > > >>happening > > >> > > >>>>>>between the two entities exchanging SIP signaling, the peering > > >> > > >>point > > >> > > >>>>>>discovery is a result of a SRV query. But the draft also=20 > > >>>>>>states > > >> > > >>that " > > >> > > >>>>>>SPEERMINT Working Group is focused on the use of such CRD." > > >>>>>> > > >>>>>>Draft peering-policy states that " This documents proposes the = > > >>>>>>use > > >> > > >>of > > >> > > >>>>>>DNS entries to publish a SIP proxy's policy for accepting=20 > > >>>>>>incoming calls" proposes DNS as a way of exchange polices. > > >>>>>> > > >>>>>>This begs the question of what are the two "peering" entities > > >> > > >>really > > >> > > >>>>>>doing besides exchange traditional SIP signaling? It seems the > > >> > > >>real > > >> > > >>>>>>_information peering_ (for the lack of a better term) is=20 > > >>>>>>happening between DNS servers. All important information=20 > > >>>>>>related to > > >> > > >>"peering" is > > >> > > >>>>>>coming from a DNS server which might as well be on your own=20 > > >>>>>>domain > > >> > > >>(if > > >> > > >>>>>>your exchange DNS information). > > >>>>>> > > >>>>>>In summary, it seems to me the whole architecture is quite a > > >> > > >>departure > > >> > > >>>>>>from layer 3 peering where the entities peering are the=20 > > >>>>>>holders of > > >> > > >>the > > >> > > >>>>>>necessary information to allow data packets to flow. Here the > > >> > > >>entities > > >> > > >>>>>>peering publish their peering information to third party=20 > > >>>>>>server > > >> > > >>which > > >> > > >>>>>>does the actual "peering" (exchange inter-domain information). > > >>>>>> > > >>>>>> > > >>>>>>Anyway, the idea of the mail is to try to clarify things. > > >>>>>>There is > > >>>> > > >>>>much > > >>>> > > >>>>>>emphasis on SIP but it seems DNS plays a more central role. Or > > >> > > >>maybe > > >> > > >>>>>>some SIP extension will be made to exchange peering policies? > > >>>>>> > > >>>>>> > > >>>>>>Policies and Independence of lower layers: > > = >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>> > > >>>>>>It seems sections 5.5 and 5.6 are _somewhat_ conflicting. > > >>>>>>Today > > >> > > >>BGP > > >> > > >>>>>>exchange QoS and VPN information, performs discovery, etc. > > >>>>>>This > > >>>> > > >>>>implies > > >>>> > > >>>>>>that BGP indirectly (or directly) knows the capabilities of=20 > > >>>>>>the transport layer (thus the name capability negotiation). > > >>>>>> > > >>>>>>So, although the mechanism to exchange the actual policies=20 > > >>>>>>needs > > >> > > >>to be > > >> > > >>>>>>independent of the lower layers, there needs to be a way to=20 > > >>>>>>input > > >>>> > > >>>>lower > > >>>> > > >>>>>>layer information into the devices exchanging the policies. > > >>>>>>Just > > >> > > >>like > > >> > > >>>>>>BGP has filters and priorities based on a myriad of options. > > >>>>>>So, > > >> > > >>maybe > > >> > > >>>>>>the wording should change a little. > > >>>>>> > > >>>>>>As far as 5.6 goes, it seems to me the policies can be quite > > >> > > >>complex. > > >> > > >>>>>>The experience of BGP tells us that in the end policies can be > > >> > > >>huge. > > >> > > >>>>So, > > >>>> > > >>>>>>if policies are going to be huge, what draft dds-00 states as=20 > > >>>>>>a possibility > > >>>>>> > > >>>>>>" If the simple boolean logic and the limited space in the DNS > > >> > > >>answers > > >> > > >>>>>> are insufficient for an application then a type of policy=20 > > >>>>>>rule > > >> > > >>URIs > > >> > > >>>>>> can be defined which links to policy statements written in=20 > > >>>>>>a > > >> > > >>fully > > >> > > >>>>>> featured policy description language like SAML [14] or=20 > > >>>>>>XACML > > >> > > >>[15]." > > >> > > >>>>>>will actually going to be the rule. So, this begs the question = > > >>>>>>of > > >> > > >>DNS > > >> > > >>>>is > > >>>> > > >>>>>>a good choice to publish peering policies. > > >>>>>> > > >>>>>>Thanks, > > >>>>>> > > >>>>>>Reinaldo > > >>>>>> > > >>>>>>_______________________________________________ > > >>>>>>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 > > >>>>> > > >>>>>-- > > >>>>>No virus found in this incoming message. > > >>>>>Checked by AVG Free Edition. > > >>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > >> > > >>3/24/2006 > > >> > > >>>-- > > >>>No virus found in this incoming message. > > >>>Checked by AVG Free Edition. > > >>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > > >>>3/24/2006 > > >>> > > >> > > >>_______________________________________________ > > >>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 > > > > > > _______________________________________________ > > > 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 >=20 _______________________________________________ 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 Fri Mar 31 15:55:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPQe4-0006gE-Hq; Fri, 31 Mar 2006 15:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPQe3-0006g9-2a for speermint@ietf.org; Fri, 31 Mar 2006 15:54:59 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FPQe1-0005fu-7B for speermint@ietf.org; Fri, 31 Mar 2006 15:54:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Mar 2006 22:58:57 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4957@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Background Reading on NGN Interconnect Thread-Index: AcZVBe2ExnqTs7UgTW2kTJiDtOSMxQ== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Subject: [Speermint] Background Reading on NGN Interconnect 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 Folks, =20 Weekend reading =20 Since we obviosly are dealing more with NGN Interconnect in Speermint, I recommend everybody on this this list to read the excellent Background = Paper from Scott Marcus - Interconnection in an IP-based NGN Environment http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1.pd= f =20 to his presentation=20 http://www.itu.int/osg/spu/ngn/documents/presentations/marcus-23-march-20= 06.ppt given at the ITU-T Workshop last week What Rules for Ip-eneabled NGNs? http://www.itu.int/osg/spu/ngn/event-march-2006.phtml =20 The agenda and some other excellent presentations can be downloaded from here: http://www.itu.int/osg/spu/ngn/presentations.html =20 In addition I would also like to point to a CEPT ECC Draft Report on the Future on Numbering, tabled for the next ITU-T SG2 Meeting as TD 198-GEN.=20 https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://www.ero.dk/27132= 22D-C8AF-4407-BE53-131EA2EED278?frames=3Dno%26 The document is in public consultation and not final yet. It contains also some statements regarding termination rates. =20 The paper from Scott is on-topic regarding the current discussion here and dealing with both the European and US situation Scott Marcus is currently living in Europe, but in his former life he was Senior Advisor to the FCC and also CTO for GTE Interworking, so his knowledge is not only theoretical. =20 In the document also contains a definition on peering and transit from = the FCC is given: =20 The two most prevalent forms of Internet interconnection are peering and = transit. For a definition of these=20 terms, we turn to a publication of the Network Reliability and = Interoperability Council (NRIC), an industry=20 advisory panel to the U.S. FCC:=20 =20 Peering is an agreement between ISPs to carry traffic for each other and = for their respective=20 customers. Peering does not include the obligation to carry traffic to = third parties. Peering is usually a=20 bilateral business and technical arrangement, where two providers agree = to accept traffic from one=20 another, and from one another's customers (and thus from their = customers' customers). ...=20 =20 Transit is an agreement where an ISP agrees to carry traffic on behalf = of another ISP or end user. In=20 most cases transit will include an obligation to carry traffic to third = parties. Transit is usually a=20 bilateral business and technical arrangement, where one provider (the = transit provider) agrees to carry=20 traffic to third parties on behalf of another provider or an end user = (the customer). In most cases, the=20 transit provider carries traffic to and from its other customers, and to = and from every destination on=20 the Internet, as part of the transit arrangement. In a transit = agreement, the ISP often also provides=20 ancillary services, such as Service Level Agreements, installation = support, local telecom provisioning,=20 and Network Operations Center (NOC) support.=20 =20 Peering thus offers a provider access only to a single provider's = customers. Transit, by contrast,=20 usually provides access at a predictable price to the entire Internet. = ... Historically, peering has often=20 been done on a bill-and-keep basis, without cash payments. Peering where = there is no explicit=20 exchange of money between parties, and where each party supports part of = the cost of the=20 interconnect, ... is typically used where both parties perceive a = roughly equal exchange of value.=20 Peering therefore is fundamentally a barter relationship =20 Here the Executive Summary of the paper: =20 This report considers the likely evolution of interconnection = arrangements in the context of IP-based Next=20 Generation Networks (NGNs).=20 The NGN represents a synthesis of existing world of the "traditional" = Public Switched Telephone Network=20 (PSTN) with the world of the Internet. The economic and regulatory = arrangements for the two have=20 historically been very different. What should happen when these two = worlds collide?=20 Many of the networks created over the past ten years contain most of the = key elements of an NGN. Most, if=20 not all, of the technology necessary for IP-based NGN interconnection = has been available for five to ten=20 years. Advanced approaches to interconnection have been slow to deploy, = even where the technology has=20 been mature or within hailing distance of maturity.=20 The NGN interconnection problem is best understood, not as a problem of = technology, but rather as a=20 problem in economics. With that in mind, this report seeks to review = what is known about interconnection=20 from an economic perspective, in order to reach conclusions about the = prospects for deployment going=20 forward and the corresponding implications for policymakers.=20 A substantial body of economic theory has been developed over the past = decade as regards interconnection in=20 the traditional PSTN. A smaller body of solid economic research has = emerged in regard to interconnection of=20 IP-based networks. At the level of economic theory, the PSTN and the = Internet are not worlds apart.=20 Economics provides the necessary bridge between the two worlds, = illuminating both the similarities and the=20 differences in these two environments.=20 This report begins by laying out, for the most part at a non-technical = level, the established theory of=20 interconnection, for both the PSTN and the Internet. Wholesale and = retail arrangements are considered=20 separately. Most of the observed behavior of these economic networks can = be explained in terms of a=20 constellation of known economic effects: market power, the termination = monopoly, demand elasticity,=20 network exernalities, transaction costs, service differentiation, price = discrimination, and the Coase theorem=20 (which says that private parties can often negotiate arrangements more = efficiently than government=20 regulators, provided that necessary preconditions have been met).=20 =20 With this theory in hand, the report considers the implications for the = deployment of differentiated Quality of=20 Service, and of universal service. We also consider the implications of = IP-based technology - with the=20 layering, and the changes in industry structure that it implies - = service providers become independent of the=20 network, but neither is well equipped to measure or to charge for the = other's resource consumption.=20 The last section of the report represents a hypothetical scenario, a = "thought experiment", where the historic=20 wired and mobile incumbent of European country upgrades its networks to = an IP-based NGN. We consider=20 the likely results in terms of regulation of the access network, and of = interconnection; likely domestic and=20 international interconnection arrangements; and the implications for = ubiquitous support of QoS. Key findings=20 include:=20 * Provided that markets for Internet transit and for consumer broadband = Internet access are effectively=20 competitive, a "Coasian" interconnection regime is likely to be more = efficient, and more consistent=20 with consumer welfare, than a regulated regime.=20 * Conversely, where these markets are not effectively competitive, = mandates for interconnection at the=20 IP level may prove to be unavoidable, particularly once existing PSTN = interconnection is withdrawn.=20 The migration to NGN potentially creates new sources of market power, at = the same time that it=20 creates new possibilities for competition.=20 * Policymakers might consequently be well advised to focus their = attention first on ensuring=20 competitive markets, and only secondarily on interconnection.=20 Current Calling Party's Network Pays (CPNP) arrangements contain a = number of implicit subsidies. In the=20 world of the NGN, where services providers and networks operators may be = different entities, these=20 subsidies need major re-thinking - call termination payments that were = intended to finance the terminating=20 network would, by default, flow to independent VoIP service provides who = have no network to support. In=20 the absence of termination fees, independent VoIP providers would tend = to compete price levels for=20 telephony service, independent of the network, down to levels not = greatly above cost, which would appear to=20 be a societally desirable outcome. =20 The thought experiment does not flatly preclude the possibility that = governments might somehow erect a=20 new system of subsidies to replace the old, but it suggests that any = subsidy system will be difficult to sustain=20 over time in the face of new forms of competition enabled by the = IP-based NGN - all provided, once again,=20 that underlying markets (especially for wholesale Internet transit and = for retail Internet broadband access)=20 remain effectively competitive. A system of Coasian private = arrangements, in the absence of vertically=20 integrated competitive bottlenecks, seems likely to lead to unsubsidized = arrangements at wholesale and retail=20 price levels not greatly in excess of cost.=20 cheer Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint