From D.Malas@cablelabs.com Fri Apr 1 01:32:15 2011 Return-Path: X-Original-To: vipr@core3.amsl.com Delivered-To: vipr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCA63A63C9 for ; Fri, 1 Apr 2011 01:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZkFmbKTBkbu for ; Fri, 1 Apr 2011 01:32:14 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 94E293A635F for ; Fri, 1 Apr 2011 01:32:14 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p318Xpef029493; Fri, 1 Apr 2011 02:33:52 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 1 Apr 2011 02:33:51 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 1 Apr 2011 02:33:51 -0600 From: Daryl Malas To: Hadriel Kaplan , "vipr@ietf.org" Date: Fri, 1 Apr 2011 02:33:49 -0600 Thread-Topic: [VIPR] Creating an alt-root for E.164 Thread-Index: AcvwR4dmeZ3bTU7GR7mWAq7Vu3jc8A== Message-ID: In-Reply-To: <24AD6F1F-1511-4DFF-AE67-EACC8DF36969@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [VIPR] Creating an alt-root for E.164 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:32:15 -0000 Hadriel, Using your analogy, is there any reason why the IP/PBX could not perform VIPR on behalf of it's registered UAs? So, regardless of who the TN is ultimately assigned to, the IP/PBX ultimately is the associated UA for the VIPR exchanges and IP/Internet path? The draft refers to SIP endpoints, and in the real world an IP/PBX (B2BUA) is a SIP endpoint -- whether we like it or not. Regards, Daryl=20 On 3/31/11 4:36 PM, "Hadriel Kaplan" wrote: >Howdy, >I apologize if this has been hashed out already - if so please tell me to >RTFM and I'll try and find the thread. (I did google already without luck) > >I have a question about why we're ok with creating an alt-root for ITU's >ownership of E.164 in an IETF protocol. By that I mean that for however >long the vipr client is willing to believe the vipr-resolved URI >represents the E.164, it is not querying the authoritative database (ie, >the PSTN). The truth of the matter is your phone does not own and is not >authoritative for the E.164 phone number - afaik only the ITU is truly >authoritative for it (but yes assigns them out downhill). > >So for example, right now if you dial the E.164 +1-781-328-4428, it >resolves to my desk phone (well, actually to voicemail since I never >answer my desk phone). Let's pretend my desk phone did vipr. If I get >fired or quit tomorrow, my employer would re-allocate my number >immediately - most likely to a receptionist for some period of time, and >ultimately to a new employee. From my employer's perspective, they "own" >+1-781-328-4428, and should have the right/power to reallocate it at >their leisure/whim. Yet VIPR moves the ownership time decision to the >caller, for whatever duration time it wants to use. > >In the IETF we have a long-standing concern with creating an alt-root for >DNS. So to put this in terms people here may grok, imagine if we have >vipr resolve email addresses instead of E.164 numbers. I send an email >through my email server to "fluffy@cisco.com". My email server >subsequently uses a vipr model to learn a "direct" URI of >"mail:c.jennings@ieee.org" or even "mail:root@10.1.2.3", and sends all my >subsequent emails for "mail:fluffy@cisco.com" to the "direct" one. Would >that be ok? Would it be ok to use vipr to resolve-cache from >"mail:chair@iab.org" to "mail:olaf@ripe.net" for the next 6 months? > >-hadriel > >_______________________________________________ >VIPR mailing list >VIPR@ietf.org >https://www.ietf.org/mailman/listinfo/vipr From HKaplan@acmepacket.com Fri Apr 1 02:29:14 2011 Return-Path: X-Original-To: vipr@core3.amsl.com Delivered-To: vipr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08C83A67B6 for ; Fri, 1 Apr 2011 02:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrFOLxNw3bok for ; Fri, 1 Apr 2011 02:29:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3BD763A67AD for ; Fri, 1 Apr 2011 02:29:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 1 Apr 2011 05:30:50 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 1 Apr 2011 05:30:50 -0400 From: Hadriel Kaplan To: Daryl Malas Date: Fri, 1 Apr 2011 05:30:48 -0400 Thread-Topic: [VIPR] Creating an alt-root for E.164 Thread-Index: AcvwT30bdL4J9HuTQhCrkmQvXLNgsQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFU Cc: "vipr@ietf.org" Subject: Re: [VIPR] Creating an alt-root for E.164 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:29:14 -0000 Yeah I should have been clearer - while there's no debate the IP-PBX could = be the VIPR agent on both caller and called sides, and indeed that's how I = think most people think of it, it should also be clear that any UA could be= the VIPR agent - and there is no way to prevent it. For example if you us= e a PC-softclient or mobile app, it could reasonably expect to be able to d= o VIPR (if this thing becomes popular of course). And if both are running = it as the server side there's a 50/50 chance you'd get the UA. -hadriel On Apr 1, 2011, at 4:33 AM, Daryl Malas wrote: > Hadriel, >=20 > Using your analogy, is there any reason why the IP/PBX could not perform > VIPR on behalf of it's registered UAs? So, regardless of who the TN is > ultimately assigned to, the IP/PBX ultimately is the associated UA for th= e > VIPR exchanges and IP/Internet path? The draft refers to SIP endpoints, > and in the real world an IP/PBX (B2BUA) is a SIP endpoint -- whether we > like it or not. >=20 > Regards, >=20 > Daryl=20 >=20 > On 3/31/11 4:36 PM, "Hadriel Kaplan" wrote: >=20 >> Howdy, >> I apologize if this has been hashed out already - if so please tell me t= o >> RTFM and I'll try and find the thread. (I did google already without luc= k) >>=20 >> I have a question about why we're ok with creating an alt-root for ITU's >> ownership of E.164 in an IETF protocol. By that I mean that for however >> long the vipr client is willing to believe the vipr-resolved URI >> represents the E.164, it is not querying the authoritative database (ie, >> the PSTN). The truth of the matter is your phone does not own and is no= t >> authoritative for the E.164 phone number - afaik only the ITU is truly >> authoritative for it (but yes assigns them out downhill). >>=20 >> So for example, right now if you dial the E.164 +1-781-328-4428, it >> resolves to my desk phone (well, actually to voicemail since I never >> answer my desk phone). Let's pretend my desk phone did vipr. If I get >> fired or quit tomorrow, my employer would re-allocate my number >> immediately - most likely to a receptionist for some period of time, and >> ultimately to a new employee. From my employer's perspective, they "own= " >> +1-781-328-4428, and should have the right/power to reallocate it at >> their leisure/whim. Yet VIPR moves the ownership time decision to the >> caller, for whatever duration time it wants to use. >>=20 >> In the IETF we have a long-standing concern with creating an alt-root fo= r >> DNS. So to put this in terms people here may grok, imagine if we have >> vipr resolve email addresses instead of E.164 numbers. I send an email >> through my email server to "fluffy@cisco.com". My email server >> subsequently uses a vipr model to learn a "direct" URI of >> "mail:c.jennings@ieee.org" or even "mail:root@10.1.2.3", and sends all m= y >> subsequent emails for "mail:fluffy@cisco.com" to the "direct" one. Woul= d >> that be ok? Would it be ok to use vipr to resolve-cache from >> "mail:chair@iab.org" to "mail:olaf@ripe.net" for the next 6 months? >>=20 >> -hadriel >>=20 >> _______________________________________________ >> VIPR mailing list >> VIPR@ietf.org >> https://www.ietf.org/mailman/listinfo/vipr >=20 From dworley@avaya.com Sun Apr 17 15:23:40 2011 Return-Path: X-Original-To: vipr@ietfc.amsl.com Delivered-To: vipr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2EE00E0687 for ; Sun, 17 Apr 2011 15:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scipILTvC3Hv for ; Sun, 17 Apr 2011 15:23:39 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfc.amsl.com (Postfix) with ESMTP id 3DD00E0750 for ; Sun, 17 Apr 2011 15:23:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU3GmAcF/2dsb2JhbACmZXSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.64,229,1301889600"; d="scan'208";a="275249805" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Apr 2011 18:23:35 -0400 X-IronPort-AV: E=Sophos;i="4.64,229,1301889600"; d="scan'208";a="609807017" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Apr 2011 18:23:35 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Sun, 17 Apr 2011 18:23:35 -0400 From: "Worley, Dale R (Dale)" To: "vipr@ietf.org" Date: Sun, 17 Apr 2011 18:23:34 -0400 Thread-Topic: [VIPR] Creating an alt-root for E.164 Thread-Index: AQHL78ahRdU18HRtz0CzyEMiBcz8RQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ironport-av: E=Sophos;i="4.63,276,1299474000"; d="scan'208";a="603704077" x-ironport-anti-spam-result: AvsEAJgtcU3GmAcF/2dsb2JhbACmZHSkegKZF4VhBJAM x-ironport-anti-spam-filtered: true Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [VIPR] Creating an alt-root for E.164 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 22:23:40 -0000 Trying to send this again: ____________________________________________ From: Hadriel Kaplan I have a question about why we're ok with creating an alt-root for ITU's ow= nership of E.164 in an IETF protocol. By that I mean that for however long= the vipr client is willing to believe the vipr-resolved URI represents the= E.164, it is not querying the authoritative database (ie, the PSTN). The = truth of the matter is your phone does not own and is not authoritative for= the E.164 phone number - afaik only the ITU is truly authoritative for it = (but yes assigns them out downhill). ____________________________________________ There are actually two different issues here. One is that the ViPR client = (caller) caches the ViPR resolutions. That is purely for practical purpose= s, although of course, it raises the error rate. In practice, we assume th= at the error rate will be small, and that people ultimately authenticate a = phone call by the sound of the voice of the person they contact. The other issue is that we really are "creating an alternative root for E.1= 64". We do this because the creation of the "primary" E.164 database is no= t progressing well, and we expect the carriers (who are the first- or secon= d-level delegates of the ITU) to obstruct the creation of the database. So= we are reduced to creating an alternative database. Dale From dworley@avaya.com Mon Apr 18 12:38:00 2011 Return-Path: X-Original-To: vipr@ietfc.amsl.com Delivered-To: vipr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 96CCFE0723 for ; Mon, 18 Apr 2011 12:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMADVd2M7U+v for ; Mon, 18 Apr 2011 12:37:59 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfc.amsl.com (Postfix) with ESMTP id A1746E070C for ; Mon, 18 Apr 2011 12:37:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.64,234,1301889600"; d="scan'208";a="242315793" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Apr 2011 15:37:57 -0400 X-IronPort-AV: E=Sophos;i="4.64,234,1301889600"; d="scan'208";a="640367508" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Apr 2011 15:37:56 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 18 Apr 2011 15:37:56 -0400 From: "Worley, Dale R (Dale)" To: "vipr@ietf.org" Date: Mon, 18 Apr 2011 15:37:55 -0400 Thread-Topic: The ViPR database Thread-Index: AQHL/gAdPrNnuNdu2U+/oq5RJyaIsw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [VIPR] The ViPR database X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:38:00 -0000 These are my suggestions for the abstract data structure of the ViPR databa= se entries. They contain a bunch of suggestions to maximize extensibility,= etc. An entry is the database is a mapping: * from a URI (In the initial case, the "from" URI will be a "tel" URI, but allowing gene= ral URIs allows expanding the source address set in the future. Although i= n the near future we will probably need to define an extension to specify p= refix groups of E.164 numbers. URIs are composed only of characters in the= ASCII set, so there are no encoding issues.) * to a URI (In the initial case, the "to" URI will be a "sip" or "sips" URI.) * with additional information giving the specifications for verification, w= hich are a set of zero or more: (A set of zero verification methods may be needed to effectively retract a = previously published mapping.) ** structures,=20 *** the first element being a one-octet number specifying a verification sc= heme that is supported by the mapping: **** numbers 0 and 255 are reserved for all time **** numbers 245 through 254 are reserved for private/experimental usage **** standardized methods are numbered from 1 upward *** the second element is auxiliary data for the verification scheme, which= is a sequence of zero or more octets. Dale From petithug@acm.org Fri Apr 22 07:42:05 2011 Return-Path: X-Original-To: vipr@ietfc.amsl.com Delivered-To: vipr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C784AE0775 for ; Fri, 22 Apr 2011 07:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.545 X-Spam-Level: X-Spam-Status: No, score=-101.545 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMvuCu2QOqjT for ; Fri, 22 Apr 2011 07:42:05 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfc.amsl.com (Postfix) with ESMTP id 0F638E0745 for ; Fri, 22 Apr 2011 07:42:02 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 15E77DBCC046; Fri, 22 Apr 2011 14:42:01 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 51F30DBCC044; Fri, 22 Apr 2011 14:42:00 +0000 (UTC) Message-ID: <4DB193B7.5010607@acm.org> Date: Fri, 22 Apr 2011 07:41:59 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: "Khan, Sohel" References: <837E772D16C77141BFA5FEC3F30487FF30C1C767@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF30C1C767@PACDCEXMB02.cable.comcast.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] Draft: SIP Extensions for Blocking VoIP Spam X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:42:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/2011 07:22 AM, Khan, Sohel wrote: > I have many questions on this draft. > > > > First, in section 3.0 second paragraph: > > “…This INVITE will contain a ticket in the X-Cisco-ViPR-Ticket header field value.” > > > > Should a proprietary header such as “X-Cisco-ViPR-Ticket” be used? > You are right, a new SIP header should be registered. I searched if there was not an existing header with similar semantics that could be reused, but I could not find one (but as I did not follow SIP for the last few years, I could have missed it). Because this header and its semantic could be reused by other distribution mechanisms than VIPR, I propose to rename the SIP header as "Ticket". I am also thinking that a Require option tag should also be defined so a SIP INVITE with a Ticket header is not processed if the UAS does not understand the Ticket header (in case the SIP request is misrouted). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2xk7UACgkQ9RoMZyVa61eNsgCfSrdM/ywMYhRCbaFs5iCIpa3+ vNIAoIHForDYdbMaWDyz1+GMa16zDfV4 =sU1O -----END PGP SIGNATURE----- From fluffy@cisco.com Mon Apr 25 21:06:02 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DA0E06CA for ; Mon, 25 Apr 2011 21:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLZwO1sXfmGC for ; Mon, 25 Apr 2011 21:06:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 08A90E06B7 for ; Mon, 25 Apr 2011 21:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3180; q=dns/txt; s=iport; t=1303790761; x=1305000361; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nXIa1emrayp+KeSSgwTDr4qWJKIGHYi9WVMZktAQB64=; b=Vq6j8EJ4tvCT0JUJVQq5l31RLpMqRM4nXUKf9NB2Peo8TPeUq3S63gc6 ZIiL6e4udL8+PQyemyzmyTUSF6+mKmjJiYOp5jNFqLvzC4+ylnj3jzE/E X4zqxofs3v7rsFNdIZ7JCe+jIoxMwau7ERC0O7fl5aq7eMkkSQEowXOrV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAINEtk2rRDoG/2dsb2JhbAClPHeIcJ9enRCDGYJdBIV3iEKECw X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208";a="686956974" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2011 04:06:01 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q460l2015273; Tue, 26 Apr 2011 04:06:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <24AD6F1F-1511-4DFF-AE67-EACC8DF36969@acmepacket.com> Date: Mon, 25 Apr 2011 22:06:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24AD6F1F-1511-4DFF-AE67-EACC8DF36969@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] Creating an alt-root for E.164 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:06:02 -0000 Normally I try not to feed trolls but just because you and I have = already had this discussion many times ... When you send email to fluffy@please-shoot-me-now.org, that resolves to = an IP that via DNS. That result is cached in many places and future = emails can recuse that. Of course the TTL of the cached data is = important to proper function. The TTL of DNS addresses is typically = lower than the TTL of E.164 but the TTL is still just as important.=20 On Mar 31, 2011, at 8:36 AM, Hadriel Kaplan wrote: > Howdy, > I apologize if this has been hashed out already - if so please tell me = to RTFM and I'll try and find the thread. (I did google already without = luck) >=20 > I have a question about why we're ok with creating an alt-root for = ITU's ownership of E.164 in an IETF protocol. By that I mean that for = however long the vipr client is willing to believe the vipr-resolved URI = represents the E.164, it is not querying the authoritative database (ie, = the PSTN). The truth of the matter is your phone does not own and is = not authoritative for the E.164 phone number - afaik only the ITU is = truly authoritative for it (but yes assigns them out downhill). Yah, sure and this work does not change that. If the the E.164 number = get's assigned to someone by the ITU-T, this tracks that. We all agree = there needs to be a TTL.=20 >=20 > So for example, right now if you dial the E.164 +1-781-328-4428, it = resolves to my desk phone (well, actually to voicemail since I never = answer my desk phone). Let's pretend my desk phone did vipr. If I get = fired or quit tomorrow, my employer would re-allocate my number = immediately - most likely to a receptionist for some period of time, and = ultimately to a new employee. =46rom my employer's perspective, they = "own" +1-781-328-4428, and should have the right/power to reallocate it = at their leisure/whim. Yet VIPR moves the ownership time decision to = the caller, for whatever duration time it wants to use. ' uh and a SIP call would still go to your enterprises PBX and get routed = to the receptionist. I don't see the problem.=20 >=20 > In the IETF we have a long-standing concern with creating an alt-root = for DNS. So to put this in terms people here may grok, imagine if we = have vipr resolve email addresses instead of E.164 numbers. I send an = email through my email server to "fluffy@cisco.com". My email server = subsequently uses a vipr model to learn a "direct" URI of = "mail:c.jennings@ieee.org" or even "mail:root@10.1.2.3", and sends all = my subsequent emails for "mail:fluffy@cisco.com" to the "direct" one. = Would that be ok? Would it be ok to use vipr to resolve-cache from = "mail:chair@iab.org" to "mail:olaf@ripe.net" for the next 6 months? The alt-root problem has to do with creating to different authorities = for a single namespace. That's not what is happening here. ITU-T and it = delegates remain the authority for namespace. >=20 > -hadriel >=20 > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From fluffy@cisco.com Mon Apr 25 21:10:35 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53164E06CA for ; Mon, 25 Apr 2011 21:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhCVyCRm2dNG for ; Mon, 25 Apr 2011 21:10:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 834DDE067C for ; Mon, 25 Apr 2011 21:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1957; q=dns/txt; s=iport; t=1303791034; x=1305000634; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ieAzajfRB/ZVu0w57LCrdHBEgE7kAKUmCTiTCHWqYBY=; b=lXSCtQu62zKgeZgzkqXM+MddX9iIrim/lbAFqfMjeqeTkFKOOMqsXbPX VniQLK8PrycXpNz6efLQDzXlx3eLM0GLauJP2ojRDjJRrUNN4yOBkm6bt 4QJ9G3JKADCO8TyWg0z8P6QGDpt9c7xOjQu0wFger7+PbbVSFePwHinTr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAINEtk2rRDoI/2dsb2JhbAClPHeoTp0QhXYEhXeIQoQL X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208";a="686957916" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2011 04:10:34 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q4AXNw021565; Tue, 26 Apr 2011 04:10:33 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <4DB193B7.5010607@acm.org> Date: Mon, 25 Apr 2011 22:10:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <837E772D16C77141BFA5FEC3F30487FF30C1C767@PACDCEXMB02.cable.comcast.com> <4DB193B7.5010607@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "Khan, Sohel" , "vipr@ietf.org" Subject: Re: [VIPR] Draft: SIP Extensions for Blocking VoIP Spam X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:10:35 -0000 I don't see why a require header would be needed. A UA that does not = understand an unknown header will just ignore it. Seems like that would = be fine.=20 (oh, and agree with you and Sohel that the existing name needs to = change. Insert rant about P- headers here. ). On Apr 22, 2011, at 8:41 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 03/31/2011 07:22 AM, Khan, Sohel wrote: >> I have many questions on this draft. >>=20 >>=20 >>=20 >> First, in section 3.0 second paragraph: >>=20 >> =93=85This INVITE will contain a ticket in the X-Cisco-ViPR-Ticket = header field value.=94 >>=20 >>=20 >>=20 >> Should a proprietary header such as =93X-Cisco-ViPR-Ticket=94 be = used? >>=20 >=20 > You are right, a new SIP header should be registered. >=20 > I searched if there was not an existing header with similar semantics = that could > be reused, but I could not find one (but as I did not follow SIP for > the last few years, I could have missed it). >=20 > Because this header and its semantic could be reused by other = distribution > mechanisms than VIPR, I propose to rename the SIP header as "Ticket". >=20 > I am also thinking that a Require option tag should also be defined so = a SIP > INVITE with a Ticket header is not processed if the UAS does not = understand the > Ticket header (in case the SIP request is misrouted). >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk2xk7UACgkQ9RoMZyVa61eNsgCfSrdM/ywMYhRCbaFs5iCIpa3+ > vNIAoIHForDYdbMaWDyz1+GMa16zDfV4 > =3DsU1O > -----END PGP SIGNATURE----- > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From petithug@acm.org Mon Apr 25 22:30:39 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48010E06CD for ; Mon, 25 Apr 2011 22:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.465 X-Spam-Level: X-Spam-Status: No, score=-100.465 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZBvcWt4XuoX for ; Mon, 25 Apr 2011 22:30:38 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9C710E067C for ; Mon, 25 Apr 2011 22:30:35 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id CDABBDBCC046; Tue, 26 Apr 2011 05:30:34 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 417B6DBCC044; Tue, 26 Apr 2011 05:30:34 +0000 (UTC) Message-ID: <4DB65879.8030801@acm.org> Date: Mon, 25 Apr 2011 22:30:33 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: Cullen Jennings References: <837E772D16C77141BFA5FEC3F30487FF30C1C767@PACDCEXMB02.cable.comcast.com> <4DB193B7.5010607@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Khan, Sohel" , "vipr@ietf.org" Subject: Re: [VIPR] Draft: SIP Extensions for Blocking VoIP Spam X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:30:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/25/2011 09:10 PM, Cullen Jennings wrote: > > I don't see why a require header would be needed. A UA that does not understand an unknown header will just ignore it. Seems like that would be fine. Well, it won't work anyway as a Require cannot be removed by a proxy. > > (oh, and agree with you and Sohel that the existing name needs to change. Insert rant about P- headers here. ). > > On Apr 22, 2011, at 8:41 AM, Marc Petit-Huguenin wrote: > > On 03/31/2011 07:22 AM, Khan, Sohel wrote: >>>> I have many questions on this draft. >>>> >>>> >>>> >>>> First, in section 3.0 second paragraph: >>>> >>>> &This INVITE will contain a ticket in the X-Cisco-ViPR-Ticket header field value. >>>> >>>> >>>> >>>> Should a proprietary header such as X-Cisco-ViPR-Ticket be used? >>>> > > You are right, a new SIP header should be registered. > > I searched if there was not an existing header with similar semantics that could > be reused, but I could not find one (but as I did not follow SIP for > the last few years, I could have missed it). > > Because this header and its semantic could be reused by other distribution > mechanisms than VIPR, I propose to rename the SIP header as "Ticket". > > I am also thinking that a Require option tag should also be defined so a SIP > INVITE with a Ticket header is not processed if the UAS does not understand the > Ticket header (in case the SIP request is misrouted). > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk22WHQACgkQ9RoMZyVa61fAQwCggEOP8Q4L0JhrWBaGvK+z9fBY E5gAn1vzFPWGL1faBw5pwcMDQAXLJWEj =of1n -----END PGP SIGNATURE----- From ietf@kenfischer.net Tue Apr 26 06:45:24 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA14CE0738 for ; Tue, 26 Apr 2011 06:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phPELV6oJGla for ; Tue, 26 Apr 2011 06:45:23 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C170AE07AD for ; Tue, 26 Apr 2011 06:45:23 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 82453584065 for ; Tue, 26 Apr 2011 06:45:23 -0700 (PDT) Received: from [192.168.123.108] (c-24-9-47-190.hsd1.co.comcast.net [24.9.47.190]) (Authenticated sender: ietf@kenfischer.net) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 53C5B584059 for ; Tue, 26 Apr 2011 06:45:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 26 Apr 2011 07:45:16 -0600 From: Ken Fischer Sender: Ken Fischer To: "vipr@ietf.org" Message-ID: Thread-Topic: [VIPR] Creating an alt-root for E.164 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [VIPR] Creating an alt-root for E.164 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:45:24 -0000 I will toss my 2 cents in below. On 4/25/11 10:06 PM, "Cullen Jennings" wrote: > >Normally I try not to feed trolls but just because you and I have already >had this discussion many times ... > >When you send email to fluffy@please-shoot-me-now.org, that resolves to >an IP that via DNS. That result is cached in many places and future >emails can recuse that. Of course the TTL of the cached data is important >to proper function. The TTL of DNS addresses is typically lower than the >TTL of E.164 but the TTL is still just as important. > > >On Mar 31, 2011, at 8:36 AM, Hadriel Kaplan wrote: > >> Howdy, >> I apologize if this has been hashed out already - if so please tell me >>to RTFM and I'll try and find the thread. (I did google already without >>luck) >>=20 >> I have a question about why we're ok with creating an alt-root for >>ITU's ownership of E.164 in an IETF protocol. By that I mean that for >>however long the vipr client is willing to believe the vipr-resolved URI >>represents the E.164, it is not querying the authoritative database (ie, >>the PSTN). The truth of the matter is your phone does not own and is >>not authoritative for the E.164 phone number - afaik only the ITU is >>truly authoritative for it (but yes assigns them out downhill). > >Yah, sure and this work does not change that. If the the E.164 number >get's assigned to someone by the ITU-T, this tracks that. We all agree >there needs to be a TTL. The ITU is authoritative about which licensed carriers are assigned which numbers. They are not authoritative about which enterprise (your company) or which user (you) is currently assigned a number. I think the discussion has been clear that that ViPR is not about building an alternate PSTN, and as such, it leaves the ITU and the carrier matters to the side. > >>=20 >> So for example, right now if you dial the E.164 +1-781-328-4428, it >>resolves to my desk phone (well, actually to voicemail since I never >>answer my desk phone). Let's pretend my desk phone did vipr. If I get >>fired or quit tomorrow, my employer would re-allocate my number >>immediately - most likely to a receptionist for some period of time, and >>ultimately to a new employee. From my employer's perspective, they >>"own" +1-781-328-4428, and should have the right/power to reallocate it >>at their leisure/whim. Yet VIPR moves the ownership time decision to >>the caller, for whatever duration time it wants to use. ' > >uh and a SIP call would still go to your enterprises PBX and get routed >to the receptionist. I don't see the problem. As far as the PTSN (and ViPR) are concerned, the E.164 number does not really resolve to your desk phone. It resolves to your company's PBX which is what the draft refers to as the Call Agent. What ever your PBX administrator decided to do with your number would have the same effect whether the call arrives via the PSTN, or via the SIP URI. Also, most enterprises actually have a decay policy that mimics carriers, putting numbers into the bottom of the pool to be re-used last. I left my last company in October of 2007. Until December of 2010, you could still hear the voice mail I left stating that I had left the company when you dialed my old number. If you call today, Frank answers it. If someone in the callers domain had continued to call my number at least once every time period (say 30 days), then eventually ViPR would send you to Frank instead of my voice mail, but that is exactly the same experience you would get with that behavior if you used the PSTN. Also, don=B9t forget that the "Called" enterprise can choose not to participate in ViPR. If I were the administrator of the phone system at your company, and we were so tight on numbers that we gave them away days after an employee was fired or quit, I would not enable ViPR on my IP_PBX because I would anticipate the problem you describe. By not enabling it, your number would never validate, and as such the callers Call Agent would not have a ViPR route for your phone number. A more simple way might be to simply refuse to accept calls on the SIP URI, forcing the calling CA to chose its 2nd option (the PSTN), which still gets the call to the same CA that ViPR would have >=20 > >>=20 >> In the IETF we have a long-standing concern with creating an alt-root >>for DNS. So to put this in terms people here may grok, imagine if we >>have vipr resolve email addresses instead of E.164 numbers. I send an >>email through my email server to "fluffy@cisco.com". My email server >>subsequently uses a vipr model to learn a "direct" URI of >>"mail:c.jennings@ieee.org" or even "mail:root@10.1.2.3", and sends all >>my subsequent emails for "mail:fluffy@cisco.com" to the "direct" one. >>Would that be ok? Would it be ok to use vipr to resolve-cache from >>"mail:chair@iab.org" to "mail:olaf@ripe.net" for the next 6 months? > >The alt-root problem has to do with creating to different authorities for >a single namespace. That's not what is happening here. ITU-T and it >delegates remain the authority for namespace. > >>=20 >> -hadriel >>=20 >> _______________________________________________ >> VIPR mailing list >> VIPR@ietf.org >> https://www.ietf.org/mailman/listinfo/vipr > >_______________________________________________ >VIPR mailing list >VIPR@ietf.org >https://www.ietf.org/mailman/listinfo/vipr From D.Malas@cablelabs.com Wed Apr 27 14:56:38 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C83E080E for ; Wed, 27 Apr 2011 14:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogxCEBlUrs2w for ; Wed, 27 Apr 2011 14:56:38 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id C72BBE0829 for ; Wed, 27 Apr 2011 14:56:37 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p3RLuZOu017168 for ; Wed, 27 Apr 2011 15:56:35 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 27 Apr 2011 15:56:36 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 27 Apr 2011 15:56:36 -0600 From: Daryl Malas To: "vipr@ietf.org" Date: Wed, 27 Apr 2011 15:56:33 -0600 Thread-Topic: [VIPR] 80th IETF ViPR Meeting Notes Posted Thread-Index: AcwFJfpWzMXhGBceRoq65IkWoy3ZmQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9DDED311563Cdmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [VIPR] 80th IETF ViPR Meeting Notes Posted X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:56:38 -0000 --_000_C9DDED311563Cdmalascablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The meeting notes for the ViPR meeting at the 80th IETF meetings in Prague = have been posted. http://www.ietf.org/proceedings/80/minutes/vipr.txt Here are the primary action items captured from the meeting: The following people agreed to review draft-jennings-vipr-overview-00 (http://tools.ietf.org/html/draft-jennings-vipr-overview-00): - Mary Barnes - Ken Fischer - Marc Petit-Huguenin - Richard Barnes - Michael Procter Please review and post comments to the mailing list as soon as possible to = allow time for discussion prior to the next IETF meeting. If you plan to r= eview in the next month or two, please send Jon and I a note indicating whe= n you plan to have your review completed. Thanks, Daryl --_000_C9DDED311563Cdmalascablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

The meeting notes for the ViPR meeting at the 80th IETF meetings in P= rague have been posted.


Here are the primary action ite= ms captured from the meeting:

The following p= eople agreed to review draft-jennings-vipr-overview-00
(http://to= ols.ietf.org/html/draft-jennings-vipr-overview-00):
- Mary Barnes=
- Ken Fischer
- Marc Petit-Huguenin
- Richar= d Barnes
- Michael Procter

Please review= and post comments to the mailing list as soon as possible to allow time fo= r discussion prior to the next IETF meeting.  If you plan to revi= ew in the next month or two, please send Jon and I a note indicating when y= ou plan to have your review completed.

Thanks,

Daryl
--_000_C9DDED311563Cdmalascablelabscom_-- From ietf@kenfischer.net Thu Apr 28 08:55:59 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D19E06F0 for ; Thu, 28 Apr 2011 08:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbbiUrzVOev7 for ; Thu, 28 Apr 2011 08:55:56 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 34B64E0685 for ; Thu, 28 Apr 2011 08:55:56 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 034B754077 for ; Thu, 28 Apr 2011 08:55:56 -0700 (PDT) Received: from [192.168.123.108] (c-24-9-47-190.hsd1.co.comcast.net [24.9.47.190]) (Authenticated sender: ietf@kenfischer.net) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id 88E965406F for ; Thu, 28 Apr 2011 08:55:55 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 28 Apr 2011 09:55:52 -0600 From: Ken Fischer Sender: Ken Fischer To: "vipr@ietf.org" Message-ID: Thread-Topic: draft-jennings-vipr-overview-00, Clarification Suggestion for Introduction In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386829355_55804617" Subject: Re: [VIPR] draft-jennings-vipr-overview-00, Clarification Suggestion for Introduction X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:55:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3386829355_55804617 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit In Prague I agreed to review the overview draft, and provide comments/changes. Based on some of the discussions at the meeting, I think we should add something to Page 5, paragraph 3. The private federations are good, but limit innovation. I think the private federation sentence should be re-written to something like: Though SIP is used between domains, it is typically through private federation agreements. While such agreements are positive, they cause a "least common denominator" problem, which has limited the growth of advanced SIP features, and prevented the innovation that we expected SIP to drive. Maybe this belongs some other place in the introduction, but I think this is about more than just any-to-any for the sake of any-to-any. Its about the feature improvement that can flourish when non-supportive intermediaries are removed from the path. Ken --B_3386829355_55804617 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable


In Prague I agreed to review the overview draft, and provide comments/chan= ges.  Based on some of the discussions at the meeting, I think we = should add something to Page 5, paragraph 3.  The private federations a= re good, but limit innovation.  I think the private federation sen= tence should be re-written to something like:

Though SIP is used between = domains, it is typically through private federation agreements.  While= such agreements are positive, they cause a "least common denominator"&= nbsp;problem, which has limited the growth of advanced SIP features, 
        and prevented the innovation = that we expected SIP to drive.


Maybe= this belongs some other place in the introduction, but I think this is abou= t more than just any-to-any for the sake of any-to-any.  Its about the = feature improvement that can flourish when non-supportive intermediaries are= removed from the path.


Ken

--B_3386829355_55804617-- From rob.maidhof@comcast.net Thu Apr 28 09:46:00 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0DCE06AF for ; Thu, 28 Apr 2011 09:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPOHJQNwcrso for ; Thu, 28 Apr 2011 09:45:59 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id D5957E0669 for ; Thu, 28 Apr 2011 09:45:59 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta14.emeryville.ca.mail.comcast.net with comcast id d4ie1g0011GXsucAE4lzSw; Thu, 28 Apr 2011 16:45:59 +0000 Received: from sz0129.ev.mail.comcast.net ([76.96.26.193]) by omta07.emeryville.ca.mail.comcast.net with comcast id d4ly1g00F49ylMG8U4lyNh; Thu, 28 Apr 2011 16:45:59 +0000 Date: Thu, 28 Apr 2011 16:45:58 +0000 (UTC) From: rob.maidhof@comcast.net To: vipr@ietf.org Message-ID: <1892288606.4720447.1304009158854.JavaMail.root@sz0129a.emeryville.ca.mail.comcast.net> In-Reply-To: <992624525.4719175.1304008066174.JavaMail.root@sz0129a.emeryville.ca.mail.comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4720446_21834028.1304009158852" X-Originating-IP: [71.229.140.2] X-Mailer: Zimbra 6.0.5_GA_2431.RHEL5_64 (ZimbraWebClient - FF3.0 (Mac)/6.0.5_GA_2427.RHEL4) Subject: [VIPR] [ViPR] draft-jennings-vipr-overview-00, Clarification on Ticket verification X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 16:46:00 -0000 ------=_Part_4720446_21834028.1304009158852 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I was looking for some clarification on whether the intent is for the Border Element or Call Agent on the terminating side of the call to verify the ticket? For example, the last paragraph of section 8.4 page36, states that the terminating call agent verifies the ticket, then at the end of the paragraph it states that the call is then forwarded to the terminating call agent. Was the intent to say the BE verifies and then forwards to the CA? In relation to this, section 6.3 page 27 states that a responsibility of the BE is to perform ticket verification, while the call agent section 6.2 does not list this as a responsibility. Page 22 states that the CA performs ticket verification. I understand an individual network element could perform both CA and BE functions, if it is simply a terminology issue, perhaps we could structure the text to insure consistency. Rob ------=_Part_4720446_21834028.1304009158852 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Arial; font-size: 12pt; color: #000000'>I was loo= king for some clarification on whether the intent is for the Border Element= or Call Agent on the terminating side of the call to verify the ticket?
For example, the last paragraph of section 8.4 page36, states that th= e terminating call agent verifies the ticket, then at the end of the paragr= aph it states that the call is then forwarded to the terminating call agent= . Was the intent to say the BE verifies and then forwards to the CA?
In = relation to this, section 6.3 page 27 states that a responsibility of the B= E is to perform ticket verification, while the call agent section 6.2 does = not list this as a responsibility. Page 22 states that the CA performs tick= et verification. 
I understand an individual network element could= perform both CA and BE functions, if it is simply a terminology issue, per= haps we could structure the text to insure consistency.


Rob
<= /div> ------=_Part_4720446_21834028.1304009158852--