From worley@shell01.TheWorld.com Sun Sep 1 19:50:09 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F2D11E82DC for ; Sun, 1 Sep 2013 19:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHdjbLrr2SO5 for ; Sun, 1 Sep 2013 19:50:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id B84A111E82D3 for ; Sun, 1 Sep 2013 19:50:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r822nsEE021418 for ; Sun, 1 Sep 2013 22:49:57 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r822nsWT386471 for ; Sun, 1 Sep 2013 22:49:54 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r822nql0383443; Sun, 1 Sep 2013 22:49:52 -0400 (EDT) Date: Sun, 1 Sep 2013 22:49:52 -0400 (EDT) Message-Id: <201309020249.r822nql0383443@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org Subject: [dispatch] Reason header in 205 responses X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 02:50:09 -0000 draft-kaplan-dispatch-sip-205-response-00 discusses using the Reason header to indicate why the alternative UAS answered the call. E.g., Reason: SIP;cause=483;text="Too Many Hops" Reason: SIP;cause=480;text="Temporarily Unavailable" Reason: SIP;cause=404;text="Not Found" Reason: SIP;cause=486;text="User Busy" However, there's ambiguity when a response contains a reason-value with protocol value "SIP" -- what does it mean, given that the response already has a response code? I suggest that we define a new protocol value for building reason-values that designate why an alternative UAS answered the call. This would relieve all ambiguity of meaning. Most likely the cause values would be defined to be the same as SIP response codes, perhaps with some additional values for special cases. So we could have: Reason: 205cause;cause=483;text="B2bua-Hops exhausted" (this one probably should have a special cause code) Reason: 205cause;cause=480;text="Temporarily Unavailable" Reason: 205cause;cause=404;text="Not Found" Reason: 205cause;cause=486;text="User Busy" Dale From pkyzivat@alum.mit.edu Mon Sep 2 08:02:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2487D21F9F3D for ; Mon, 2 Sep 2013 08:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi1jOsLA-ets for ; Mon, 2 Sep 2013 08:02:37 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 1A54621F9F2B for ; Mon, 2 Sep 2013 08:02:36 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta02.westchester.pa.mail.comcast.net with comcast id LBhb1m0031uE5Es51F2cmx; Mon, 02 Sep 2013 15:02:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id LF2b1m01k3ZTu2S3cF2bEl; Mon, 02 Sep 2013 15:02:36 +0000 Message-ID: <5224A88B.3020205@alum.mit.edu> Date: Mon, 02 Sep 2013 11:02:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dispatch@ietf.org References: <201309020249.r822nql0383443@shell01.TheWorld.com> In-Reply-To: <201309020249.r822nql0383443@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378134156; bh=uICs9g69SghFHWmQebMpb1L73zdifUhrycDVjUzpw7Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g+85O3XheZo8MYhZqHYtP8GsDlzGbJGysoueCEfhkSZoP8QRlFNj1aAJf0oQCRvAE dQfwneyR536/34LDj5B56e1N7h8znUHuq7DElwDNlEPBtL7AeJVdRbZtBpNwr5nJUn i1oEGait5nLPkpnBRlLWYmLPGD36xRXxPqGUJ8fOZTTOiVBlpLPVGcDzdGBUI2Tt0e jOb7QMUepEweDsGeSaMWMVuPPGTz33UmGae0eo2XSB4kA1FJGGE5y1Ca1up8lGByht zWMxY5v/Mjtewq3eNKR9PckdDeVeZ+8NxG5h7aiqyTpZnNvJ0nTGvVoc6/IXw9aeKG GxtxREpxWistA== Subject: Re: [dispatch] Reason header in 205 responses X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 15:02:42 -0000 IMO this is overkill. I don't see the problem with using sip reason codes with 205. The description of the 205 response can say something about how to interpret these. Thanks, Paul On 9/1/13 10:49 PM, Dale R. Worley wrote: > draft-kaplan-dispatch-sip-205-response-00 discusses using the Reason > header to indicate why the alternative UAS answered the call. E.g., > > Reason: SIP;cause=483;text="Too Many Hops" > Reason: SIP;cause=480;text="Temporarily Unavailable" > Reason: SIP;cause=404;text="Not Found" > Reason: SIP;cause=486;text="User Busy" > > However, there's ambiguity when a response contains a reason-value > with protocol value "SIP" -- what does it mean, given that the > response already has a response code? > > I suggest that we define a new protocol value for building > reason-values that designate why an alternative UAS answered the call. > This would relieve all ambiguity of meaning. Most likely the cause > values would be defined to be the same as SIP response codes, perhaps > with some additional values for special cases. So we could have: > > Reason: 205cause;cause=483;text="B2bua-Hops exhausted" > (this one probably should have a special cause code) > Reason: 205cause;cause=480;text="Temporarily Unavailable" > Reason: 205cause;cause=404;text="Not Found" > Reason: 205cause;cause=486;text="User Busy" > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From fas_vm@surguttel.ru Mon Sep 2 11:00:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30FC21E8084 for ; Mon, 2 Sep 2013 11:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.727 X-Spam-Level: ** X-Spam-Status: No, score=2.727 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_50=0.001, FAKE_REPLY_C=2.012, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpHMfQ3Ev-nH for ; Mon, 2 Sep 2013 11:00:10 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id DA2B321E8083 for ; Mon, 2 Sep 2013 11:00:09 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id DAB97514D5E; Tue, 3 Sep 2013 00:00:05 +0600 (YEKT) Received: from Gateway (unknown [151.252.73.108]) by mail.s86.ru (Postfix) with ESMTPA id A1F33514C30 for ; Tue, 3 Sep 2013 00:00:02 +0600 (YEKT) Message-ID: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> From: "Anton Tveretin" To: Date: Mon, 2 Sep 2013 23:59:59 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130902-0, 02.09.2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 18:00:15 -0000 Hello All, Thanks to everybody who answered. Let me go into details. I define "telephony" as real-time inter-personal communication. By SIP, I mean a protocol family, not the protocol. >[MB] There have been proposals for call park and call pickup. You can see here why the work was not progressed: http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html As I understand that message, authors of some I-D withdrew their proposal. The same for another I-D. I don't think that binds me. "No one implements" does not sound as a reasonable argument for me. I cannot use it because no one implements, no one implements because no one uses. For conferences, SIP requires conference URI. For that, there must be routing function recognizing them and routing requests to appropriate focus, focus service itself, conference factory that allocates and assigns conference URIs, at least. In P2P scenarios, nothing of this would be available. Suppose someone (Alice?) starts a conference. Anyone wishing to join knows only Alice's address. Currently, in H.323, this is sufficient, but not in SIP, as there is no way to indicate "join". More to come... Sincerely yours, Anton. From hadriel.kaplan@oracle.com Mon Sep 2 16:47:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822B221F9193 for ; Mon, 2 Sep 2013 16:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sREWUZuFQ1HT for ; Mon, 2 Sep 2013 16:47:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C12F721F90A7 for ; Mon, 2 Sep 2013 16:47:27 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r82NlP7T006179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Sep 2013 23:47:25 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r82NlNFG029157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Sep 2013 23:47:24 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r82NlN1u018651; Mon, 2 Sep 2013 23:47:23 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Sep 2013 16:47:23 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Hadriel Kaplan X-Priority: 3 In-Reply-To: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> Date: Mon, 2 Sep 2013 19:47:22 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> To: Anton Tveretin X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 23:47:35 -0000 On Sep 2, 2013, at 1:59 PM, Anton Tveretin wrote: > Suppose someone (Alice?) starts a conference. Anyone wishing to join knows > only Alice's address. Currently, in H.323, this is sufficient, but not in > SIP, as there is no way to indicate "join". Ummm... RFC 3911? http://tools.ietf.org/html/rfc3911 -hadriel From worley@shell01.TheWorld.com Mon Sep 2 18:23:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE0021F9E7E for ; Mon, 2 Sep 2013 18:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgFR0xpp7YeB for ; Mon, 2 Sep 2013 18:23:24 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B035721F9E77 for ; Mon, 2 Sep 2013 18:23:24 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r831MRka027411; Mon, 2 Sep 2013 21:22:29 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r831MM63439946; Mon, 2 Sep 2013 21:22:27 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r831MFk7440076; Mon, 2 Sep 2013 21:22:15 -0400 (EDT) Date: Mon, 2 Sep 2013 21:22:15 -0400 (EDT) Message-Id: <201309030122.r831MFk7440076@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: John-Luc Bakker In-reply-to: <155970D1DA8E174F9E46039E10E2AA35E7339B@XMB103ADS.rim.net> (jbakker@blackberry.com) References: <155970D1DA8E174F9E46039E10E2AA35E7339B@XMB103ADS.rim.net> Cc: dispatch@ietf.org Subject: Re: [dispatch] purpose RE: draft-avasarala-dispatch-comm-div-notification X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 01:23:30 -0000 > From: John-Luc Bakker > The initial motivation for CDIVN is "debugging" or analyses of > communication diversion rules (see "introduction" in the > draft). Some state is needed in the network enabling this analyses. > The proposed state is a ternary value and can take the following > values IDLE, DIVERSION_NOTIFIED, DIVERSION_NOT_NOTIFIED: > > > The subscriber could receive, as part of the notification > information, the state the FSM was in prior to detecting the > diversion. > > o [IDLE]: meaning that no diversions have occurred since setting the > present "filter". > > o [DIVERSION_NOTIFIED]: meaning that since receiving the last NOTIFY > request for this event package, no additional diversions have > occurred. > > o [DIVERSION_NOT_NOTIFIED]: meaning that one or more diversions have > occurred since setting the present "filter" or since receiving the > last NOTIFY request for this event package. > > > The state has limited use to a user trying to understand > communication diversion rules. If a user receives an indication that > diversions have happened for which it did not receive a notification > and the user had not expected these diversions to happen, then the > user can further "debug" the diversion and notification filtering > rules. The primary advantage of this rather limited information is > that the amount of state stored for a user subscribed to > "communication diversion" is limited, yet still enables "analyses". > > There is no 3GPP requirement to receive notification from all > diversions that have happened in the past. That is, if a diversion > wasn't notified due to failing to meet conditions expressed in the > notification filter, then there is no requirement to be able to > notify that diversion at a later stage. > > Is the ternary value maintained at the NOTIFIER per CDIVN subscriber > compliant with the SIP event model? Yes, you can make a "ternary value maintained at the NOTIFIER per CDIVN *subscription*" compliant, though it takes some extra verbiage to get the definition right. But I believe that it doesn't give you the effect you want. For example, assuming that the previous state is DIVERSION_NOTIFIED, if a diversion happens that is not selected by the filter, then the state changes to DIVERSION_NOT_NOTIFIED. But since previous-cdivn-state *is part of the state*, the notifier has to tell the subscriber that it has just changed, resulting in a NOTIFY that tells the subscriber that an event just happened that the subscriber wasn't notified of. I believe what you actually want to tell the subscriber is, connected with each diversion notification that is sent, whether there were un-notified diversions between that diversion and the previous {diversion that was notified}. Hmmmm... This entire discussion is unsatisfying, and the problem seems to revolve around getting "filtering" to deliver the information we want to each subscriber. Interestingly, I just discovered RFC 4660 "Functional Description of Event Notification Filtering", which I was not aware of. I think I will read it before commenting further on this subject... OK, I've looked over 4660 and 4661. From a theoretical point of view, they introduce "trigger" filtering, the ability to specify which state changes are to be notified to the subscriber. This extends the RFC 3265/6665 model, within which the subscriber cannot prevent notification of state changes which are visible to the subscriber. If we admit the possibility of trigger filtering, then we can solve most of the comm-div problem by defining the state to be the comm-div-ntfy-info element describing the *latest* diversion. Whenever a new divershion happens, that state changes and could trigger a notification. (However there still is the problem if there are two identical diversions within the same second; in that case, the state does not change. You really need to add a unique identifier element to comm-div-ntfy-info to cover that.) Assuming that the event notification framework has been enlarged to admit trigger filtering, comm-div-ntfy-trigger-criteria is just another way to specify triggering. Getting back to CDIVN, that's harder to fit within the SIP event model. You could make it work something like is done with call-completion, that part of the state is the CDIVN status of all the subscriptions, but each subscription is only allowed to see its own CDIVN status. The underlying problem is that it's a bad idea in general to have state specifically associated with *subscriptions*. In this case, I don't see much value in the ternary value. All it can tell the receiver is that, since the previous notification, there was a diversion but the subscriber wasn't notified about it. It seems to me that there two possible use cases: 1) The subscriber expects that all diversions will match its filters. In this case, the subscriber would not need to provide any filters (since that would just add processing overhead). And if there were diversions for reasons that were unexpected by the subscriber, it could discover that itself, by examining the diversion notifications. 2) The subscriber expects that there are diversions that it will match the filters it provies. In this case, the ternary value would simply tell the subscriber what it expects, that there have been diversions that it has not been notified of. The only use case where the ternary value would be helpful is if there was a desire to know *that* diversions had happened, but that prompt notification was not needed, and the details of the diversion were not needed. Dale From pkyzivat@alum.mit.edu Tue Sep 3 09:08:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4694C21E817C for ; Tue, 3 Sep 2013 09:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qMYH3xFStI5 for ; Tue, 3 Sep 2013 09:08:11 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 1730A21E814E for ; Tue, 3 Sep 2013 09:08:07 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta12.westchester.pa.mail.comcast.net with comcast id LbLW1m0010xGWP85Cg82D0; Tue, 03 Sep 2013 16:08:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id Lg821m0023ZTu2S3Yg82zv; Tue, 03 Sep 2013 16:08:02 +0000 Message-ID: <52260961.2090202@alum.mit.edu> Date: Tue, 03 Sep 2013 12:08:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dispatch@ietf.org References: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378224482; bh=HAafAb4HpiVn63G4y2lqyG3SMN23wWbStXgwyC0l0/g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=L5xNZ1YYmwluQFjQ6xPNHc2BgY7ARvPqygUI1B2l1QBodIZeLaGGVTnDHFwtDUmc5 a2w8u0ImFbO2xRxrP3dYg+6KmH8W1XDyrhD631IAAVc4p/KOWOXILKdNchJaovTPHV 3g/yGuZFqMWdaWW3/zk2dfLFdiFm74k/rZNO+RgULXY1PQMbC2ZpmcEQ8C5w7mOOOa 01jvwLUN8apiQ9eXHzOZa5+NRu/Ze2wTvULCmW/cw/tWBDP6vW0I5ATyGCqmXYQDZx I546Rrte8PcXev2FlycR7GD5TQbgYW12zTxXyUH6gMvqeVvfsVKO6lKaXjiaZIWCXy 1gKQW6T57PoMA== Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 16:08:16 -0000 On 9/2/13 7:47 PM, Hadriel Kaplan wrote: > > On Sep 2, 2013, at 1:59 PM, Anton Tveretin wrote: > >> Suppose someone (Alice?) starts a conference. Anyone wishing to join knows >> only Alice's address. Currently, in H.323, this is sufficient, but not in >> SIP, as there is no way to indicate "join". > > Ummm... RFC 3911? > http://tools.ietf.org/html/rfc3911 Join does require the joiner to know the dialog id of the dialog it wishes to join, in addition to the URL. But that is a fundamental problem if you want to join a conference, unless you assume the UA you are calling can only be in one call at a time. And its more complex if there are multiple UAs at the same AOR. If somehow you are in the situation where you know somebody you want to call is already in a call that you want to join, but you don't know the dialog id, then you can subscribe to the dialog event package of your callee, look at the existing dialogs, and choose one to join. Of course this isn't something that you would want to allow everyone to do. Hadriel can comment on the difficulty of using dialog ids when there are B2BUAs in use. If you want to address a real problem, that may be the one. SIP was designed to work in a different environment than it is currently deployed. Thanks, Paul From hadriel.kaplan@oracle.com Tue Sep 3 11:45:59 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3903511E81E3 for ; Tue, 3 Sep 2013 11:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wC20A13MsEa for ; Tue, 3 Sep 2013 11:45:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id ABE5B21E8093 for ; Tue, 3 Sep 2013 11:45:53 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r83IjpRK005736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Sep 2013 18:45:52 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r83IjoXY000320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Sep 2013 18:45:51 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r83Ijo4M008718; Tue, 3 Sep 2013 18:45:50 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Sep 2013 11:45:50 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <52260961.2090202@alum.mit.edu> Date: Tue, 3 Sep 2013 14:45:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1EFEBA74-03C2-4FB3-A5C6-925FEB048E7F@oracle.com> References: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> <52260961.2090202@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 18:45:59 -0000 Hey I didn't say it was ever used or usable - just that SIP has such a = concept. :) In practice it's unnecessary. Alice is in a SIP call with Bob; Carol = calls Alice to join that Alice-Bob call using a normal SIP call; Alice = sees Carol's incoming call; Alice puts Bob on hold and answers Carol, = who says "can I join?"; Alice then can decide to join Carol to the = Alice-Bob call by pressing a UI button for that purpose on her phone; = the phone keeps them as distinct SIP dialogs, but bridges the media. In other words, one doesn't actually need the SIP protocol level to = indicate this joining, since the higher-layer application can do it by = itself (with Alice's knowledge/input). That model works for any call = scenario, including one where Carol is actually in the PSTN and called = Alice through a gateway, for example. Arguably that's also why conference-server scenarios are frequently = implemented without the special SIP-layer RFC 4579 stuff. -hadriel On Sep 3, 2013, at 12:08 PM, Paul Kyzivat wrote: > On 9/2/13 7:47 PM, Hadriel Kaplan wrote: >>=20 >> On Sep 2, 2013, at 1:59 PM, Anton Tveretin = wrote: >>=20 >>> Suppose someone (Alice?) starts a conference. Anyone wishing to = join knows >>> only Alice's address. Currently, in H.323, this is sufficient, but = not in >>> SIP, as there is no way to indicate "join". >>=20 >> Ummm... RFC 3911? >> http://tools.ietf.org/html/rfc3911 >=20 > Join does require the joiner to know the dialog id of the dialog it = wishes to join, in addition to the URL. >=20 > But that is a fundamental problem if you want to join a conference, = unless you assume the UA you are calling can only be in one call at a = time. And its more complex if there are multiple UAs at the same AOR. >=20 > If somehow you are in the situation where you know somebody you want = to call is already in a call that you want to join, but you don't know = the dialog id, then you can subscribe to the dialog event package of = your callee, look at the existing dialogs, and choose one to join. Of = course this isn't something that you would want to allow everyone to do. >=20 > Hadriel can comment on the difficulty of using dialog ids when there = are B2BUAs in use. >=20 > If you want to address a real problem, that may be the one. SIP was = designed to work in a different environment than it is currently = deployed. >=20 > Thanks, > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From timothy.dwight@verizon.com Tue Sep 3 11:52:25 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECD621E804E for ; Tue, 3 Sep 2013 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf7-+I6dQL14 for ; Tue, 3 Sep 2013 11:52:11 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id ACA2011E81E9 for ; Tue, 3 Sep 2013 11:51:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 03 Sep 2013 18:51:55 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.89,1015,1367971200"; d="scan'208";a="539718025" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 03 Sep 2013 18:51:54 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Tue, 3 Sep 2013 14:51:54 -0400 To: Hadriel Kaplan , Paul Kyzivat Date: Tue, 3 Sep 2013 14:51:53 -0400 Thread-Topic: [dispatch] SIP Problem Statement Thread-Index: Ac6o1dmpGVCWDSMwQiSSb11mibyYRQAAEnoQ Message-ID: <2B0F677F0B95454297753F58D4A07FA3012B152FC8@FHDP1LUMXC7V31.us.one.verizon.com> References: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> <52260961.2090202@alum.mit.edu> <1EFEBA74-03C2-4FB3-A5C6-925FEB048E7F@oracle.com> In-Reply-To: <1EFEBA74-03C2-4FB3-A5C6-925FEB048E7F@oracle.com> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 18:52:26 -0000 Hadriel, I agree that what you describe is commonly implemented for fixed line devic= es. For mobiles it's another story. The mobile operator typically doesn't= want the device to perform this bridging function, because it wastes spect= rum. tim -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Hadriel Kaplan Sent: Tuesday, September 03, 2013 1:46 PM To: Paul Kyzivat Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP Problem Statement Hey I didn't say it was ever used or usable - just that SIP has such a conc= ept. :) In practice it's unnecessary. Alice is in a SIP call with Bob; Carol calls= Alice to join that Alice-Bob call using a normal SIP call; Alice sees Caro= l's incoming call; Alice puts Bob on hold and answers Carol, who says "can = I join?"; Alice then can decide to join Carol to the Alice-Bob call by pres= sing a UI button for that purpose on her phone; the phone keeps them as dis= tinct SIP dialogs, but bridges the media. In other words, one doesn't actually need the SIP protocol level to indicat= e this joining, since the higher-layer application can do it by itself (wit= h Alice's knowledge/input). That model works for any call scenario, includ= ing one where Carol is actually in the PSTN and called Alice through a gate= way, for example. Arguably that's also why conference-server scenarios are frequently impleme= nted without the special SIP-layer RFC 4579 stuff. -hadriel On Sep 3, 2013, at 12:08 PM, Paul Kyzivat wrote: > On 9/2/13 7:47 PM, Hadriel Kaplan wrote: >>=20 >> On Sep 2, 2013, at 1:59 PM, Anton Tveretin wrote: >>=20 >>> Suppose someone (Alice?) starts a conference. Anyone wishing to=20 >>> join knows only Alice's address. Currently, in H.323, this is=20 >>> sufficient, but not in SIP, as there is no way to indicate "join". >>=20 >> Ummm... RFC 3911? >> http://tools.ietf.org/html/rfc3911 >=20 > Join does require the joiner to know the dialog id of the dialog it wishe= s to join, in addition to the URL. >=20 > But that is a fundamental problem if you want to join a conference, unles= s you assume the UA you are calling can only be in one call at a time. And = its more complex if there are multiple UAs at the same AOR. >=20 > If somehow you are in the situation where you know somebody you want to c= all is already in a call that you want to join, but you don't know the dial= og id, then you can subscribe to the dialog event package of your callee, l= ook at the existing dialogs, and choose one to join. Of course this isn't s= omething that you would want to allow everyone to do. >=20 > Hadriel can comment on the difficulty of using dialog ids when there are = B2BUAs in use. >=20 > If you want to address a real problem, that may be the one. SIP was desig= ned to work in a different environment than it is currently deployed. >=20 > Thanks, > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Sep 3 12:39:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D0311E8135 for ; Tue, 3 Sep 2013 12:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWVqOYjpJBKf for ; Tue, 3 Sep 2013 12:39:07 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id B01F921E808C for ; Tue, 3 Sep 2013 12:39:07 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id LbTY1m0011ei1Bg54jf7lM; Tue, 03 Sep 2013 19:39:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id Ljf61m01X3ZTu2S3kjf7fo; Tue, 03 Sep 2013 19:39:07 +0000 Message-ID: <52263AD9.2080906@alum.mit.edu> Date: Tue, 03 Sep 2013 15:39:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Dwight, Timothy M (Tim)" References: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> <52260961.2090202@alum.mit.edu> <1EFEBA74-03C2-4FB3-A5C6-925FEB048E7F@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012B152FC8@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012B152FC8@FHDP1LUMXC7V31.us.one.verizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378237147; bh=x0sLRuXHRDGNuwLfAq09+xt4hyg65g+DQ00Wi/sHJlQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UAKDtRR2Upwa7nFrCBy9KF8RkbjGWIJM7OcTexptvRvqLEOEudn5oqxRgAma6BalJ aIwhrbok1YMj5NB1BP52EqGPJ2cFwZHFwPhXCrwmfrxTxvVDYl8icxAqjFV+frEPGL tWqS4UaY+PX86e+v7GqzZxems1tnsnRO84uk2jV/zhz95KFfTASPDEYGJD9ikKgTwp 6fQ/NAyc/suHuBuQnikVjVWB1ZocnR2jZyi/kdCAppNtwIb5QzChDCZW+PiP0tWq8s 79vKBX6lonyvEYAY+eOHomJHrEuTUcPtmOFaSuDZiiVtQAZWky82C4lmzHrfCWvXog pHiWQIlQfM0cA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 19:39:16 -0000 On 9/3/13 2:51 PM, Dwight, Timothy M (Tim) wrote: > Hadriel, > > I agree that what you describe is commonly implemented for fixed line devices. For mobiles it's another story. The mobile operator typically doesn't want the device to perform this bridging function, because it wastes spectrum. The device doesn't need to actually do the bridging. But it can orchestrate - decide to form the conference, and recruit a server to do the media processing. Thanks, Paul > tim > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Tuesday, September 03, 2013 1:46 PM > To: Paul Kyzivat > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SIP Problem Statement > > > Hey I didn't say it was ever used or usable - just that SIP has such a concept. :) > > In practice it's unnecessary. Alice is in a SIP call with Bob; Carol calls Alice to join that Alice-Bob call using a normal SIP call; Alice sees Carol's incoming call; Alice puts Bob on hold and answers Carol, who says "can I join?"; Alice then can decide to join Carol to the Alice-Bob call by pressing a UI button for that purpose on her phone; the phone keeps them as distinct SIP dialogs, but bridges the media. > > In other words, one doesn't actually need the SIP protocol level to indicate this joining, since the higher-layer application can do it by itself (with Alice's knowledge/input). That model works for any call scenario, including one where Carol is actually in the PSTN and called Alice through a gateway, for example. > > Arguably that's also why conference-server scenarios are frequently implemented without the special SIP-layer RFC 4579 stuff. > > -hadriel > > > On Sep 3, 2013, at 12:08 PM, Paul Kyzivat wrote: > >> On 9/2/13 7:47 PM, Hadriel Kaplan wrote: >>> >>> On Sep 2, 2013, at 1:59 PM, Anton Tveretin wrote: >>> >>>> Suppose someone (Alice?) starts a conference. Anyone wishing to >>>> join knows only Alice's address. Currently, in H.323, this is >>>> sufficient, but not in SIP, as there is no way to indicate "join". >>> >>> Ummm... RFC 3911? >>> http://tools.ietf.org/html/rfc3911 >> >> Join does require the joiner to know the dialog id of the dialog it wishes to join, in addition to the URL. >> >> But that is a fundamental problem if you want to join a conference, unless you assume the UA you are calling can only be in one call at a time. And its more complex if there are multiple UAs at the same AOR. >> >> If somehow you are in the situation where you know somebody you want to call is already in a call that you want to join, but you don't know the dialog id, then you can subscribe to the dialog event package of your callee, look at the existing dialogs, and choose one to join. Of course this isn't something that you would want to allow everyone to do. >> >> Hadriel can comment on the difficulty of using dialog ids when there are B2BUAs in use. >> >> If you want to address a real problem, that may be the one. SIP was designed to work in a different environment than it is currently deployed. >> >> Thanks, >> Paul >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From worley@shell01.TheWorld.com Tue Sep 3 18:22:12 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B84421F9928 for ; Tue, 3 Sep 2013 18:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O92nRD9-+z9H for ; Tue, 3 Sep 2013 18:22:06 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B57EC21F9675 for ; Tue, 3 Sep 2013 18:22:03 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r841LdUZ000540; Tue, 3 Sep 2013 21:21:41 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r841LcOI492735; Tue, 3 Sep 2013 21:21:38 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r841LX6e492030; Tue, 3 Sep 2013 21:21:33 -0400 (EDT) Date: Tue, 3 Sep 2013 21:21:33 -0400 (EDT) Message-Id: <201309040121.r841LX6e492030@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <52263AD9.2080906@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> <52260961.2090202@alum.mit.edu> <1EFEBA74-03C2-4FB3-A5C6-925FEB048E7F@oracle.com> <2B0F677F0B95454297753F58D4A07FA3012B152FC8@FHDP1LUMXC7V31.us.one.verizon.com> <52263AD9.2080906@alum.mit.edu> Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 01:22:12 -0000 > From: Paul Kyzivat > > The device doesn't need to actually do the bridging. > But it can orchestrate - decide to form the conference, and recruit a > server to do the media processing. Even with ordinary SIP, it can use REFERs and 302 responses to INVITEs to route all the call legs to a conference it has set up elsewhere. Dale From fas_vm@surguttel.ru Wed Sep 4 08:49:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E3B11E80DE for ; Wed, 4 Sep 2013 08:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.317 X-Spam-Level: * X-Spam-Status: No, score=1.317 tagged_above=-999 required=5 tests=[AWL=0.956, BAYES_05=-1.11, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP4o5xHrKxaa for ; Wed, 4 Sep 2013 08:49:38 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5211C21F99B7 for ; Wed, 4 Sep 2013 08:49:38 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 075F15164FB; Wed, 4 Sep 2013 21:49:33 +0600 (YEKT) Received: from Gateway (unknown [151.252.75.80]) by mail.s86.ru (Postfix) with ESMTPA id CB825514A51; Wed, 4 Sep 2013 21:49:29 +0600 (YEKT) Message-ID: <535A4CD1A13F486F8783EF2A7AC30D1F@Gateway> From: "Anton Tveretin" To: "Hadriel Kaplan" References: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> Date: Wed, 4 Sep 2013 21:42:30 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130904-0, 04.09.2013), Outbound message X-Antivirus-Status: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:49:43 -0000 RFC 3911 requires a conference URI. This implies that 1) there is one; 2) this URI is known to the caller beforehand. My original idea was to send Join: without URI (and normatively update RFC 3911 for that). Anyway, IMO some (syntax level) indication needed to indicate that an INVITE is a request to join rather than just a call. Even though such an INVITE contains no session description. Actually, this might mean 3pcc. ----- Original Message ----- From: "Hadriel Kaplan" To: "Anton Tveretin" Cc: Sent: Tuesday, September 03, 2013 5:47 AM Subject: Re: [dispatch] SIP Problem Statement > > On Sep 2, 2013, at 1:59 PM, Anton Tveretin wrote: > >> Suppose someone (Alice?) starts a conference. Anyone wishing to join >> knows >> only Alice's address. Currently, in H.323, this is sufficient, but not in >> SIP, as there is no way to indicate "join". > > Ummm... RFC 3911? > http://tools.ietf.org/html/rfc3911 > > -hadriel > > > From rjsparks@nostrum.com Wed Sep 4 11:36:17 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D309611E8103 for ; Wed, 4 Sep 2013 11:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHhSVyZQqM6J for ; Wed, 4 Sep 2013 11:36:17 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D587711E80E7 for ; Wed, 4 Sep 2013 11:36:16 -0700 (PDT) Received: from unnumerable.local (mobile-166-147-071-020.mycingular.net [166.147.71.20]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r84IaFKS049026 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Wed, 4 Sep 2013 13:36:16 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <52277D9A.9030704@nostrum.com> Date: Wed, 04 Sep 2013 13:36:10 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dispatch@ietf.org References: <9E9087E68DE74D5CA0A7660E3CC2E662@Gateway> <535A4CD1A13F486F8783EF2A7AC30D1F@Gateway> In-Reply-To: <535A4CD1A13F486F8783EF2A7AC30D1F@Gateway> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 166.147.71.20 is authenticated by a trusted mechanism) Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 18:36:18 -0000 On 9/4/13 10:42 AM, Anton Tveretin wrote: > RFC 3911 requires a conference URI. No, it doesn't really. I can see how you draw that from the text, but if you look at the mechanics, there is nothing in it that makes the URI itself special. It was always the intent to allow ad-hoc conferences/mixing at the UA using this mechanism, and I've seen it implemented. RjS > This implies that > 1) there is one; > 2) this URI is known to the caller beforehand. > > My original idea was to send Join: without URI (and normatively update > RFC 3911 for that). > Anyway, IMO some (syntax level) indication needed to indicate that an > INVITE is a request to join rather than just a call. Even though such > an INVITE contains no session description. Actually, this might mean > 3pcc. > > ----- Original Message ----- From: "Hadriel Kaplan" > > To: "Anton Tveretin" > Cc: > Sent: Tuesday, September 03, 2013 5:47 AM > Subject: Re: [dispatch] SIP Problem Statement > > >> >> On Sep 2, 2013, at 1:59 PM, Anton Tveretin wrote: >> >>> Suppose someone (Alice?) starts a conference. Anyone wishing to >>> join knows >>> only Alice's address. Currently, in H.323, this is sufficient, but >>> not in >>> SIP, as there is no way to indicate "join". >> >> Ummm... RFC 3911? >> http://tools.ietf.org/html/rfc3911 >> >> -hadriel >> >> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mayumi.ohsugi@ntt-at.co.jp Sun Sep 8 23:31:44 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A826F21E80D3 for ; Sun, 8 Sep 2013 23:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.509 X-Spam-Level: ** X-Spam-Status: No, score=2.509 tagged_above=-999 required=5 tests=[HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTYZRIKTcU2O for ; Sun, 8 Sep 2013 23:31:33 -0700 (PDT) Received: from mgw2.ntt-at.co.jp (mgw2.ntt-at.co.jp [202.253.162.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8411221E80A6 for ; Sun, 8 Sep 2013 23:31:30 -0700 (PDT) Received: from gwall1.bb.ntt-at.co.jp ([192.168.225.241]) by mgw2i.dc.ntt-at.co.jp with ESMTP; 09 Sep 2013 15:31:29 +0900 Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id r896VTNP009223; Mon, 9 Sep 2013 15:31:29 +0900 Received: from vcsrv1d.dc.ntt-at.co.jp [192.168.225.46] by gwall1.bb.ntt-at.co.jp with ESMTP id RAA09221; Mon, 9 Sep 2013 15:31:29 +0900 Received: from vcsrv1d.dc.ntt-at.co.jp (vcsrv1d.dc.ntt-at.co.jp [127.0.0.1]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r896VTi8015801; Mon, 9 Sep 2013 15:31:29 +0900 Received: from atmail27.am.ntt-at.co.jp (atmail27.am.ntt-at.co.jp [192.168.225.147]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r896VTAo015798; Mon, 9 Sep 2013 15:31:29 +0900 Received: from [IPv6:::1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by atmail27.am.ntt-at.co.jp (Postfix) with ESMTP id 05237ED005E; Mon, 9 Sep 2013 15:31:29 +0900 (JST) Message-ID: <522D6B23.5080901@ntt-at.co.jp> Date: Mon, 09 Sep 2013 15:30:59 +0900 From: Mayumi Ohsugi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dispatch@ietf.org References: <201308291521.r7TFLUHc193847@shell01.TheWorld.com> <949EF20990823C4C85C18D59AA11AD8B08B1FC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201308301426.r7UEQg8q247642@shell01.TheWorld.com> In-Reply-To: <201308301426.r7UEQg8q247642@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: No Subject: Re: [dispatch] Comments on draft-vanelburg-dispatch-private-network-ind-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 06:31:44 -0000 Hi Dale, Thank you for the review and comments on draft-vanelburg-dispatch-private-network-ind-02. I agree that the abstract needs a statement telling what the header means. I will correct the abstract as you proposed. Thanks, Mayumi (2013/08/30 23:26), Dale R. Worley wrote: >> From: "DRAGE, Keith (Keith)" >> >> I also think the abstract is long enough as it is and your proposed >> sentence can be inferred from the text, sufficiently for >> bibliographies and so on to identify what the document is about. To >> include what you want, what would you delete? > > I'd say that everything in the abstract can be inferred from the text, > but the point of an abstract is that you should be able to read it > without reading the text and yet know what the text is about. I think > you've been thinking about PPNI long enough that you don't notice that > its purpose isn't obvious to the naive reader. > > In regard to the size of the abstract, certainly you could omit > sentence 4, "The indication also distinguishes traffic from one > private network from another private network." as that would be > redundant after adding my proposed sentence between sentences 1 and 2. > If that isn't sufficient, I would propose removing sentence 2, "The > use of ...", as that is pretty much common to all P- headers (and is > stated in detail in section 1.2), and isn't as important as describing > what the header is *for*. > > So I propose this as an improved abstract: > > This document specifies the SIP P-Private-Network-Indication > P-header used by the 3rd-Generation Partnership Project (3GPP). > The P-Private-Network-Indication indicates that the message is > part of the message traffic of a private network, and identifies > that private network. A private network indication allows nodes > to treat private network traffic according to a different set of > rules than the set applicable to public network traffic. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From keith.drage@alcatel-lucent.com Mon Sep 9 09:18:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A29C21F9AF8 for ; Mon, 9 Sep 2013 09:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GPMF1sFDYeR for ; Mon, 9 Sep 2013 09:18:15 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B81C311E8116 for ; Mon, 9 Sep 2013 09:00:18 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r89G0FfL005743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Sep 2013 11:00:17 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r89G0E3M019174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 18:00:15 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 9 Sep 2013 18:00:14 +0200 From: "DRAGE, Keith (Keith)" To: Mayumi Ohsugi , "dispatch@ietf.org" Thread-Topic: [dispatch] Comments on draft-vanelburg-dispatch-private-network-ind-02 Thread-Index: AQHOpYzy3ziQCFWyLUaMNLfibjb2jpm836qAgAC+T8A= Date: Mon, 9 Sep 2013 16:00:14 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B09FABF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <201308291521.r7TFLUHc193847@shell01.TheWorld.com> <949EF20990823C4C85C18D59AA11AD8B08B1FC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201308301426.r7UEQg8q247642@shell01.TheWorld.com> <522D6B23.5080901@ntt-at.co.jp> In-Reply-To: <522D6B23.5080901@ntt-at.co.jp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [dispatch] Comments on draft-vanelburg-dispatch-private-network-ind-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:18:21 -0000 The proposed abstract is fine with me. My main concern was not to make it longer and the proposal meets that conce= rn. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mayumi Ohsugi > Sent: 09 September 2013 07:31 > To: dispatch@ietf.org > Subject: Re: [dispatch] Comments on draft-vanelburg-dispatch-private- > network-ind-02 >=20 > Hi Dale, >=20 > Thank you for the review and comments on > draft-vanelburg-dispatch-private-network-ind-02. >=20 > I agree that the abstract needs a statement > telling what the header means. >=20 > I will correct the abstract as you proposed. >=20 > Thanks, > Mayumi >=20 >=20 > (2013/08/30 23:26), Dale R. Worley wrote: > >> From: "DRAGE, Keith (Keith)" > >> > >> I also think the abstract is long enough as it is and your proposed > >> sentence can be inferred from the text, sufficiently for > >> bibliographies and so on to identify what the document is about. To > >> include what you want, what would you delete? > > > > I'd say that everything in the abstract can be inferred from the text, > > but the point of an abstract is that you should be able to read it > > without reading the text and yet know what the text is about. I think > > you've been thinking about PPNI long enough that you don't notice that > > its purpose isn't obvious to the naive reader. > > > > In regard to the size of the abstract, certainly you could omit > > sentence 4, "The indication also distinguishes traffic from one > > private network from another private network." as that would be > > redundant after adding my proposed sentence between sentences 1 and 2. > > If that isn't sufficient, I would propose removing sentence 2, "The > > use of ...", as that is pretty much common to all P- headers (and is > > stated in detail in section 1.2), and isn't as important as describing > > what the header is *for*. > > > > So I propose this as an improved abstract: > > > > This document specifies the SIP P-Private-Network-Indication > > P-header used by the 3rd-Generation Partnership Project (3GPP). > > The P-Private-Network-Indication indicates that the message is > > part of the message traffic of a private network, and identifies > > that private network. A private network indication allows nodes > > to treat private network traffic according to a different set of > > rules than the set applicable to public network traffic. > > > > Dale > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mayumi.ohsugi@ntt-at.co.jp Tue Sep 10 18:34:41 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CADF11E8189 for ; Tue, 10 Sep 2013 18:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.439 X-Spam-Level: ** X-Spam-Status: No, score=2.439 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qPFJskvGvTO for ; Tue, 10 Sep 2013 18:34:37 -0700 (PDT) Received: from mgw2.ntt-at.co.jp (mgw2.ntt-at.co.jp [202.253.162.42]) by ietfa.amsl.com (Postfix) with ESMTP id E568211E80F3 for ; Tue, 10 Sep 2013 18:34:36 -0700 (PDT) Received: from gwall2.bb.ntt-at.co.jp ([192.168.225.242]) by mgw2i.dc.ntt-at.co.jp with ESMTP; 11 Sep 2013 10:34:35 +0900 Received: (from root@localhost) by gwall2.bb.ntt-at.co.jp (8.13.1/8.13.1) id r8B1YZim025268; Wed, 11 Sep 2013 10:34:35 +0900 Received: from vcsrv1d.dc.ntt-at.co.jp [192.168.225.46] by gwall2.bb.ntt-at.co.jp with ESMTP id LAA25267; Wed, 11 Sep 2013 10:34:34 +0900 Received: from vcsrv1d.dc.ntt-at.co.jp (vcsrv1d.dc.ntt-at.co.jp [127.0.0.1]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r8B1YZ6J016967; Wed, 11 Sep 2013 10:34:35 +0900 Received: from atmail17.am.ntt-at.co.jp (atmail17.am.ntt-at.co.jp [192.168.225.144]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r8B1YZfk016964; Wed, 11 Sep 2013 10:34:35 +0900 Received: from [IPv6:::1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by atmail17.am.ntt-at.co.jp (Postfix) with ESMTP id DF333940056; Wed, 11 Sep 2013 10:34:34 +0900 (JST) Message-ID: <522FC89C.6020507@ntt-at.co.jp> Date: Wed, 11 Sep 2013 10:34:20 +0900 From: Mayumi Ohsugi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <51E4B4ED.4060305@ntt-at.co.jp> <7D2F7D7ADBA812449F25F4A69922881C14AA59@ESESSMB203.ericsson.se> <7D2F7D7ADBA812449F25F4A69922881C16E34A@ESESSMB203.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080C73A3@STNTEXMB10.cis.neustar.com> <521F07CB.4040305@ntt-at.co.jp> <949EF20990823C4C85C18D59AA11AD8B08B1F8@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B08B1F8@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: No Cc: "dispatch@ietf.org" , "Yu, James" , Cullen Jennings Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 01:34:41 -0000 Keith, Thank you for the comments. Sorry for the late reply. #9 OK, I will keep the sentence regarding subdomains as it is. 7.1.1 I will correct "breaking" to "break-in". I believe that all the comments have been solved so I will submit the revised draft soon. Thanks, Mayumi (2013/08/30 3:44), DRAGE, Keith (Keith) wrote: > The proposed changes are OK except: > > #9: I would prefer we mentioned multiple domain names and subdomains, rather than deleting subdomains. > > #10: I agree we should not specify this. Break-in in 3GPP would be an application server type function, and it is up to the enterprise how it wants to instruct the public network to handle such break-in. It could be a single default value. It could be based on the Request-URI in the request. It could be based on all sorts of things. > > Additionally in reviewing this I spotted in subclause 7.1.1 a "breaking" that should be "break-in". > > Regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mayumi Ohsugi >> Sent: 29 August 2013 09:35 >> To: Yu, James >> Cc: dispatch@ietf.org; Cullen Jennings >> Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private- >> network-ind >> >> Hi James, >> >> Thank you for the comments to the P-Private-Network-Indication draft. >> See inline. >> >> (2013/08/29 6:59), Yu, James wrote: >>> Mayumi, >>> >>> I have a few comments below. >>> >>> Best Regards, >>> >>> James >>> >>> ------------------- >>> >>> #1. Page 4, Section 1.1, 2nd sentence: Remove the parentheses >>> and either leave the sentence at the same place or move it to a footnote. >> >> [MO] I will remove the parentheses. >> >>> >>> #2. Page 5, Section 1.5, 1st paragraph: Change the sentence >>> containing "network element (supporting this specification) >>> traversed" to "A private network indication as proposed by >>> this document that is received in an incoming request indicates >>> to the receiving network element (supporting this specification) >>> that this request is related to a private network traffic as >>> opposed to a public network traffic.". >> >> [MO] I prefer a little shorter sentence. I will correct it to >> "A private network indication as proposed by this document >> indicates to the receiving network element (supporting this >> specification) that this request is related to a private >> network traffic as opposed to a public network traffic." >> >> >>> Change "on behalf to" to"on behalf of" in the 2nd to the last line. >> >> [MO] Yes, I will. >> >>> >>> #3. Page 6, Section 1.5, the last set of items 1 and 2: >>> Change "As caller" to "Caller" in item 1. >>> Change "network" to "networks" in the 1st line and "is" to "are" >>> in the 3rd line of item 2. >> >> [MO] I will make these editorial corrections. >> >>> >>> #4. Page 8, 1st paragraph and Figure 1 (and other places?): >>> It may be better to use "pre-arranged domain name" instead of >>> "common domain". Suggest to change the 1st paragraph to >>> "There may be circumstances where traffic between two different >>> enterprises are tagged as private network traffic using a >>> pre-arranged domain name agreed by the two involved enterprises." >> >> [MO] I agree your suggestion is much better. >> I will change the sentence as you proposed. >> >>> >>> #5. Page 8, last paragraph, 6th line: Change "break out" to "break-out". >> >> [MO] I will correct it. >> >>> >>> #6. Page 10, Figure 3: Between the enterprise phone and the >>> hosted enterprise service for enterprise 1, should it be >>> "public network traffic" because there is no need to include >>> the P-Private-Network-Indication header field in the request >>> in either direction. >> >> [MO] The traffic can be either public or private. >> This figure shows the example where the traffic is tagged as private. >> I will correct the explanation of Figure 3 as follows; >> "Traffic from the enterprise phones would not normally be >> tagged, but it can be tagged as private network traffic." >> >>> >>> #7. Page 10, Section 5, R1: Change "that indicates" to "to indicate". >> >> [MO] I will. >> >>> >>> #8. Page 11, last paragraph: Insert "a" before "globally" in the 2nd >> line. >>> Also the 2nd line says "associated with the originating enterprise". >>> For a common domain, the PNI would be associated with both the >>> originating and terminating enterprises. >> >> [MO] I will insert "a" before "globally" and >> correct "associated with the originating enterprise" to >> "associated with the originating and/or terminating enterprise(s)". >> >>> >>> #9. Page 12, 1st paragraph: "subdomains" is mentioned when anenterprise >>> needs more than one identifier. But the I-D should notrule out that >>> an enterprise can use multiple domain names so long as it owns them. >> >> [MO] I will delete the sentence regarding subdomain >> in order not to mention about subdomain in this draft. >> >>> >>> #10. Page 12, Section 7.1.1: If a common domain name is used, >>> the PNI would correspond to two enterprises in the last sentence. >>> In case an enterprise has more than one identifiers, the proxy would >>> need to know which identifier is to be used when it needs to convert >>> public network traffic to private network . I don't know if the proxy >>> has the knowledge to know the appropriate identifier to use based on >>> the incoming request. If not, there should be a default identifier >>> and the procedure needs to be discussed. >> >> [MO] I will correct "enterprise" to "enterprise(s)". >> Regarding the multiple identifiers, which identity should be used will be >> implementation matter, so I would like to avoid mention it in this draft. >> >>> >>> #11. Page 12, Section 7.1.2: Change "on" to "in" in the 4th line >>> and insert "a" before "case" in the 2nd to the last line. >>> The 1st server in the public telecom network that receives the >>> P-Private-Network-Indication header field in an incoming request >>> should check if the originating enterprise can include the >>> indicateddomain name in the header field (also see comment #15 >> >> [MO] I will make these editorial corrections. >> >>> >>> #12. Page 12, Section 7.1.3: Change "breakout" to "break-out" >>> in the 2nd line to be consistent. Is there a need to include >>> "with a value" in the last line? The text would imply that this >>> header field is not removed if it does not contain a value. >>> This header field should always be removed. >> >> [MO] I will correct "breakout" to "break-out". >> I agree and will delete "with a value". >> >>> >>> #13. Page 13, 1st paragraph, last sentence: "for a specific enterprise" >>> probably does not apply to the case with a common domain name used by >>> two enterprises. >> >> [MO] I will correct "for a specific enterprise" to >> "for a specific enterprise(s)". >> >>> >>> #14. Page 13, 2nd paragraph, 2nd line: Change "the following" to >> "described below". >> >> [MO] I will correct it as you proposed. >> >>> >>> #15. Page 13, Section 9: Change "physically" to "physical" in the 5th >> line. >>> When an enterprise includes the P-Private-Network-Indication header >> field >>> in a request, should the public telecom network check if the originating >>> enterprise can use that domain name? If an enterprise wrongly uses >> another >>> enterprise's domain name without any verification, the only impact is >> that >>> rules for another enterprise is applied to the traffic related to this >> request. >>> But for the purpose of security, the public telecom network would be >>> provisioned with the domain names that can be used in the this header >> field >>> for each served enterprise. >> >> [MO] I will correct "physically" to "physical". >> Regarding the verification of domain name by the public telecom network, >> I will put a new subsection as follows; >> >> 7.1.4. P-Private-Network-Indication verification >> When proxies supporting this specification receive a P-Private-Network- >> Indication >> header field in a SIP request from a trusted node, proxies MUST check >> whether >> the received domain name in the request is the same as the domain name >> associated >> with the provisioned domain name. If the received domain name does not >> match, >> proxies MUST remove the P-Private-Network-Indication header field. >> >>> >>> #16. Page 14, 1st paragraph: Not clear about "the own proxy" in the 2nd >> line. >>> Change "understand the" to "understand this". >> >> [MO] I will delete "such as the own proxy" and >> correct "understands the" to "understands this". >> >> Many Thanks, >> Mayumi >> >> >>> >>> >>> -----Original Message----- >>> From: Atle Monrad [mailto:atle.monrad@ERICSSON.COM] >>> Sent: Thursday, August 15, 2013 5:35 AM >>> To: 3GPP_TSG_CT_IETF-COORD@LIST.ETSI.ORG >>> Subject: FW: [dispatch] New version of draft-vanelburg-dispatch-private- >> network-ind >>> >>> Again >>> >>> Kindly review and/or advocate support for this draft on the dispatch- >> list. >>> >>> It seems to be close to completion!! >>> >>> thanks >>> /a >>> ________________________________ >>> >>> >>> Atle Monrad >>> 3GPP CT Chairman >>> >>> Group Function Technology - Standardization and Technical Regulation >> Ericsson >>> >>> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Atle Monrad >>> Sent: 29. juli 2013 10:40 >>> To: Mayumi Ohsugi; dispatch@ietf.org >>> Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private- >> network-ind >>> >>> All >>> >>> Thanks to Mayumi to pick up the remaining topics on this draft. >>> >>> I have reviewed the new version. >>> >>> I have no comments and can confirm that 3GPP would like to get the draft >> completed to finish one of our long time outstanding dependencies. >>> >>> cheers >>> /atle >>> ________________________________ >>> >>> >>> Atle Monrad >>> 3GPP CT Chairman >>> >>> Group Function Technology - Standardization and Technical Regulation >> Ericsson >>> >>> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mayumi Ohsugi >>> Sent: 16. juli 2013 04:50 >>> To: dispatch@ietf.org >>> Subject: [dispatch] New version of draft-vanelburg-dispatch-private- >> network-ind >>> >>> Hi, >>> >>> I have submitted the following draft: >>> >>> http://www.ietf.org/id/draft-vanelburg-dispatch-private-network-ind- >> 02.txt >>> >>> The draft was discussed in DISPATCH list three years ago. >>> While it has been expired for more than two years, the draft has been >> referred in 3GPP IMS specifications and the P-Private-Network-Indication >> header field is now implemented by some vendors for enterprise customers. >>> >>> We have updated the draft to solve the remaining issues from Expert >> Review (by John Elwell) of three years ago. >>> >>> Any comments are welcome. >>> >>> Thanks, >>> Mayumi >>> >>> ----- >>> Mayumi Ohsugi, NTT >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2013.0.2904 / Virus Database: 3211/6577 - Release Date: >> 08/14/13 >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From mary.ietf.barnes@gmail.com Wed Sep 11 13:12:59 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8C21E808D for ; Wed, 11 Sep 2013 13:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojMY367vIrw6 for ; Wed, 11 Sep 2013 13:12:58 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0E14421E8054 for ; Wed, 11 Sep 2013 13:12:57 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id x7so5955370qeu.33 for ; Wed, 11 Sep 2013 13:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a8EAFz9K2lN5oF01pCSl2LRgqJiXDUt6+tl6TcbeJJk=; b=qkWHKEbIGhRCPP0vpECVxAm9Rl9F9DJDNVo+Oq9StfQB/4ARFG6aL1YcJEX7bih25K kLDQolP8arLJjPrvlrnXPnuTMWW9lt1FsoK9Cb1YYngd0mxgAp2AXilS6zWm+GNIwvC1 Gy8XrN5M4taOcjf8HPJaNOlh0sv92Rs+elu/WwsMLYk/THcmw7yRb2IKvyMUPBvWvphq L6ktxWZb9JEVtu73IIzeEpyGHJAQoE/GF7c8tW734iuNgK4VZ4G/BvKw4OzMW/bT6823 9xlTM1dGNMOkKZacN/eUoSHJpRSRRKrkuekuCBOWSMZo99T1ajff70yfeiOqXvP1zx6s MAaw== MIME-Version: 1.0 X-Received: by 10.229.127.74 with SMTP id f10mr6662953qcs.16.1378930377435; Wed, 11 Sep 2013 13:12:57 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 11 Sep 2013 13:12:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Sep 2013 15:12:57 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a1133dd4c514d9704e6213f8e Subject: [dispatch] Fwd: Review of draft-drage-sipping-rfc3455bis-08 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 20:12:59 -0000 --001a1133dd4c514d9704e6213f8e Content-Type: text/plain; charset=ISO-8859-1 Hi all, The authors of draft-drage-sipping-rfc3455bis-08 have requested the ADs to sponsor this document. It is a 3GPP dependency and is an update of RFC 3455. In order to progress the document, the ADs asked for an expert review. Dean Willis performed the review detailed below. The authors will need to update the document to address the changes. In addition, we need to ensure that no one in the DISPATCH WG has concerns with regards to progressing this document as AD sponsored. If you do have concerns, please raise them no later than Wednesday, Oct. 2nd, 2013 5pm Pacific. Regards, Mary DISPATCH WG co-chair ---------- Forwarded message ---------- From: Dean Willis Date: Wed, Sep 11, 2013 at 2:38 PM Subject: Fwd: Review of draft-drage-sipping-rfc3455bis-08 To: Mary Barnes I've completed a cursory review of draft-drage-sipping-rfc3455bis-08. I have not validated the ABNF; such validation is needed before submission to the RFC Editor. General: This draft is a revision to an existing limited-scope RFC. The revisions are not controversial, but are primarily small clarifications. I found nothing major to complain about, but noticed a few nits that can be readily addressed. In last sentence of 4.2: A SIP proxy MUST NOT insert a P-Called-Party-ID header field in the REGISTER requests. Please remove the "the" before "REGISTER". Explain the MUST. What happens if they do? Will the registrar reject the request? Guidance in 4.3.2.1 on SHOULD is lacking. Why? When would this SHOULD reasonably be violated? In 4.3.2.3. Examples of Usage Finally, in flow F3, proxy P2 decides to insert his own identifier, derived from its own domain name to the P-Visited-Network-ID header field. Note the "his own identifier". How did we determine the masculinity of the proxy? 4.4.2.2 Proxy behavior An outbound proxy MUST remove any P-Access-Network-Info header field containing a "network-provided" value. How does a proxy know it's an outbound proxy? Draft-ietf-sip-outbound? I think perhaps a clarifying sentence that refers to the edge of the protection zone referenced in 4.4.1 would help. Alternatively, a proxy-requires is needed. Note that the whole 4th paragraph here is a bit fudgy, and doesn't really address the "outbound" question. Sentence: "A proxy that provides services to the user, is typically located in the home network, and therefore trusted." This has an extra comma in it after "user". referenced in 4.4.1 would help. Alternatively, a proxy-requires is needed. Note that the whole 4th paragraph here is a bit fudgy, and doesn't reall yaddress the "outbound" question. Sentence: "A proxy that provides services to the user, is typically located in the home network, and therefore trusted." This has an extra comma in it after "user". 4.5 The P-Charging Function-Addresses header field The third paragraph "We define ..." is a bit complex and probably not consistent in header and header field uses. Of course, this is a global problem in SIP literature, but is it a header or a header field? --001a1133dd4c514d9704e6213f8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

The authors of=A0draft-drage-si= pping-rfc3455bis-08 have requested the ADs to sponsor this document. It is = a 3GPP dependency and is an update of RFC 3455. =A0In order to progress the= document, the ADs asked for an expert review. =A0Dean Willis performed the= review detailed below. =A0The authors will need to update the document to = address the changes. =A0In addition, we need to ensure that no one in the D= ISPATCH WG has concerns with regards to progressing this document as AD spo= nsored. =A0If you do have concerns, please raise them no later than Wednesd= ay, Oct. 2nd, 2013 5pm Pacific. =A0

Regards,
Mary=A0
DISPATCH WG co-cha= ir



---------- Forwarded message ----------
From: Dean Willis <dean.willis@softarmor.com>
Date: Wed, Sep 11, 2013 at 2:38 PM
Subject: Fwd: Review of draft-drage-s= ipping-rfc3455bis-08
To: Mary Barnes <mary.ietf.barnes@gmail.com>


I've completed a cursory review of draft-drage-sipping-rfc3455bis-08. I= have not validated the ABNF; such validation is needed before submission t= o the RFC Editor.=A0

General: This draft is a revision to an existing limited-scope RFC. Th= e revisions are not controversial, but are primarily small clarifications. = I found nothing major to complain about, but noticed a few nits that can be= readily addressed.



In last sentence of 4.2: =

=A0 =A0 =A0A SIP proxy MUST NOT insert a P-Called-Party-ID header= =A0
=A0 =A0 =A0field in the REGISTER requests.

Please remove the "the" before "REGISTER". Expla= in the MUST. What happens if they do? Will the registrar reject the request= ?

Guidance in 4.3.2.1 on SHOULD is lacking. Why? When wou= ld this SHOULD reasonably be violated?

In 4.3.2.3.= =A0Examples of Usage

=A0 =A0Finally, in flow F3, = proxy P2 decides to insert his own identifier,
=A0 =A0derived from its own domain name to the P-Visited-Network-ID he= ader
=A0 =A0field.
=A0 =A0
Note the "his= own identifier". How did we determine the masculinity of the proxy?

4.4.2.2 Proxy behavior
=A0
=A0 =A0An out= bound proxy MUST remove any P-Access-Network-Info
=A0 =A0header f= ield containing a "network-provided" value.

<= div>
How does a proxy know it's an outbound proxy? Draft-ietf-sip= -outbound? I think perhaps a clarifying sentence that refers to the edge of= the protection zone referenced in 4.4.1 would help. Alternatively, a proxy= -requires is needed. Note that the whole 4th paragraph here is a bit fudgy,= and doesn't really address the "outbound" question.

Sentence: "A proxy that provides services to the u= ser, is typically located in the home network, and therefore trusted."= This has an extra comma in it after "user".

referenced in 4.4.1 would help. Alternatively, a proxy-requires i= s needed. Note that the whole 4th paragraph here is a bit fudgy, and doesn&= #39;t reall yaddress the "outbound" question.

Sentence: "A proxy that provides services to the user, is typical= ly located in the home network, and therefore trusted." This has an ex= tra comma in it after "user".

4.5 The P-= Charging Function-Addresses header field

The third paragraph "We define ..." is a bit = complex and probably not consistent in header and header field uses. Of cou= rse, this is a global problem in SIP literature, but is it a header or a he= ader field?


--001a1133dd4c514d9704e6213f8e-- From mayumi.ohsugi@ntt-at.co.jp Wed Sep 11 19:19:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CDD1F0D13 for ; Wed, 11 Sep 2013 19:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.175 X-Spam-Level: * X-Spam-Status: No, score=1.175 tagged_above=-999 required=5 tests=[AWL=1.264, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXENtXXCVtVd for ; Wed, 11 Sep 2013 19:19:38 -0700 (PDT) Received: from mgw2.ntt-at.co.jp (mgw2.ntt-at.co.jp [202.253.162.42]) by ietfa.amsl.com (Postfix) with ESMTP id 55D1711E80ED for ; Wed, 11 Sep 2013 19:19:38 -0700 (PDT) Received: from gwall1.bb.ntt-at.co.jp ([192.168.225.241]) by mgw2i.dc.ntt-at.co.jp with ESMTP; 12 Sep 2013 11:19:37 +0900 Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id r8C2Jatg002702; Thu, 12 Sep 2013 11:19:36 +0900 Received: from vcsrv1d.dc.ntt-at.co.jp [192.168.225.46] by gwall1.bb.ntt-at.co.jp with ESMTP id MAA02700; Thu, 12 Sep 2013 11:19:36 +0900 Received: from vcsrv1d.dc.ntt-at.co.jp (vcsrv1d.dc.ntt-at.co.jp [127.0.0.1]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r8C2JapB019649; Thu, 12 Sep 2013 11:19:36 +0900 Received: from atmail26.am.ntt-at.co.jp (atmail26.am.ntt-at.co.jp [192.168.225.146]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r8C2JaQp019645; Thu, 12 Sep 2013 11:19:36 +0900 Received: from [IPv6:::1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by atmail26.am.ntt-at.co.jp (Postfix) with ESMTP id 46C84C50062; Thu, 12 Sep 2013 11:19:35 +0900 (JST) Message-ID: <523124B0.2000305@ntt-at.co.jp> Date: Thu, 12 Sep 2013 11:19:28 +0900 From: Mayumi Ohsugi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> In-Reply-To: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: No Subject: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 02:19:42 -0000 Hi, I have submitted the following draft: http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-network-ind-03.txt The draft reflects all the comments discussed in DISPATCH list. The major changes are as follows: - corrected the abstract - corrected the term "common domain" to "pre-arranged domain" - added 7.1.4 "P-Private-Network-Indication verification" - editorial changes Regards, Mayumi From mary.ietf.barnes@gmail.com Thu Sep 12 14:19:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEF121E80BB for ; Thu, 12 Sep 2013 14:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.662 X-Spam-Level: X-Spam-Status: No, score=-101.662 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSrFD6Mg2he2 for ; Thu, 12 Sep 2013 14:19:31 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC621E80B9 for ; Thu, 12 Sep 2013 14:19:31 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id jy17so316766qeb.40 for ; Thu, 12 Sep 2013 14:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SD4G30ss0n4OtB5/GM2P+1ypBWkQgYnK3qxZ147/YNc=; b=rKqJKQdzGQamHo+WecB1tuw0GaJsy1d2/Iq/kn0nkeab4xXGMqQU+qQ3ytOJVZaJnp uYksXCDdLBvsAC9fJHjsGWuEPV7KKamGOAtMKo8Wqi0YQaZZ2Xpwt4Hebb/xRHg4ntBf WVOQ5ydGpxoskJ8qWEAVpMFWtoz+b0gSLJ9KZJBK80bn/N1BaBhbIEEtksW8FKMY8PaR 0NhCvkawXZXzt3M876oA6G0QC6dX+iVBx5ELykWlxww8W5ryS9f0gwLXxKHVeiNgbCNp dutOgrgMX4q2/pYxgaOHHZZsvhqEwuHs0VQCqxEOopATWssed7GPcQvDSfl+mo5BcLol L+cw== MIME-Version: 1.0 X-Received: by 10.49.15.97 with SMTP id w1mr17279602qec.13.1379020770748; Thu, 12 Sep 2013 14:19:30 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Thu, 12 Sep 2013 14:19:30 -0700 (PDT) In-Reply-To: <523124B0.2000305@ntt-at.co.jp> References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> Date: Thu, 12 Sep 2013 16:19:30 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=047d7bb042e22dcbc504e6364b5f Cc: draft-vanelburg-dispatch-private-network-ind@tools.ietf.org Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 21:19:32 -0000 --047d7bb042e22dcbc504e6364b5f Content-Type: text/plain; charset=ISO-8859-1 Hi all, The authors of this document have requested the ADs to sponsor the publication of this document. Before we do that, we need to ensure that no one in the DISPATCH WG has concerns with regards to progressing this document as AD sponsored. If you do have concerns, please raise them no later than Wednesday, Oct. 3rd, 2013 5pm Pacific. Regards, Mary DISPATCH WG co-chair On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi wrote: > Hi, > > I have submitted the following draft: > > http://www.ietf.org/internet-**drafts/draft-vanelburg-** > dispatch-private-network-ind-**03.txt > > The draft reflects all the comments discussed in DISPATCH list. > > The major changes are as follows: > > - corrected the abstract > - corrected the term "common domain" to "pre-arranged domain" > - added 7.1.4 "P-Private-Network-Indication verification" > - editorial changes > > Regards, > Mayumi > ______________________________**_________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/**listinfo/dispatch > --047d7bb042e22dcbc504e6364b5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

The author= s of this document=A0have requested the ADs to sponsor the publication of t= his document. Before we do that, we need to ensure that no one in the DISPA= TCH WG has concerns with regards to progressing this document as AD sponsor= ed. =A0If you do have concerns, please raise them no later than Wednesday, = Oct. 3rd, 2013 5pm Pacific. =A0

Regards,
Mary=A0
DISPATCH WG co-cha= ir


On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <mayumi.ohsugi@n= tt-at.co.jp> wrote:
Hi,

I have submitted the following draft:

http://www.ietf.org/internet-= drafts/draft-vanelburg-dispatch-private-network-ind-03.tx= t

The draft reflects all the comments discussed in DISPATCH list.

The major changes are as follows:

- corrected the abstract
- corrected the term "common domain" to "pre-arranged domain= "
- added 7.1.4 "P-Private-Network-Indication verification"
- editorial changes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Regards,
Mayumi
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--047d7bb042e22dcbc504e6364b5f-- From R.Jesske@telekom.de Fri Sep 13 01:25:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B9B11E81D0 for ; Fri, 13 Sep 2013 01:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VID1P+SP3+av for ; Fri, 13 Sep 2013 01:25:20 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9084511E81DD for ; Fri, 13 Sep 2013 01:25:17 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 13 Sep 2013 10:25:13 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 13 Sep 2013 10:25:11 +0200 From: To: , Date: Fri, 13 Sep 2013 10:25:10 +0200 Thread-Topic: Review of draft-drage-sipping-rfc3455bis-08 Thread-Index: Ac6vK1qY77NngvgwSMKBTRWURPNvvwAapeLA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60BEC@HE113667.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60BECHE113667eme_" MIME-Version: 1.0 Subject: Re: [dispatch] Review of draft-drage-sipping-rfc3455bis-08 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 08:25:26 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60BECHE113667eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, now I have updated the draft with regard to the comments from Dean. More de= tail please see below. When I get positive feedback on my proposed changes I will upload the new v= ersion on Monday. I went through a further time and made an additional editorial wrap-up. There was also identified that the ABNF for the time-zone was not correct. = (Correction of ABNF change UE-time-zone to local-time-zone) Best Regards Roland Here are the comments: In last sentence of 4.2: A SIP proxy MUST NOT insert a P-Called-Party-ID header field in the REGISTER requests. Please remove the "the" before "REGISTER". Explain the MUST. What happens i= f they do? Will the registrar reject the request? [RJ] OK Guidance in 4.3.2.1 on SHOULD is lacking. Why? When would this SHOULD reaso= nably be violated? [RJ] Comment on 4.3.2.1: A normal User Equipment has no knowledge of the P= -Visited-Network-ID when sending the REGISTER. This is the task of the fi= rst proxy within the visited network. I do not know why Should not instead = of must not was taken. In 4.3.2.3. Examples of Usage Finally, in flow F3, proxy P2 decides to insert his own identifier, derived from its own domain name to the P-Visited-Network-ID header field. Note the "his own identifier". How did we determine the masculinity of the = proxy? [RJ] OK replaced it by its 4.4.2.2 Proxy behavior An outbound proxy MUST remove any P-Access-Network-Info header field containing a "network-provided" value. [RJ] changed to: An proxy sending towards an untrusted entity MUST remove = any P-Access-Network-Info header field containing a "network-provide= d" value. --> I hope that is OK for all. How does a proxy know it's an outbound proxy? Draft-ietf-sip-outbound? I th= ink perhaps a clarifying sentence that refers to the edge of the protection= zone referenced in 4.4.1 would help. Alternatively, a proxy-requires is ne= eded. Note that the whole 4th paragraph here is a bit fudgy, and doesn't re= ally address the "outbound" question. [RJ] I hope that this is solved with the proposal above. Sentence: "A proxy that provides services to the user, is typically located= in the home network, and therefore trusted." This has an extra comma in it= after "user". [RJ] OK done 4.5 The P-Charging Function-Addresses header field The third paragraph "We define ..." is a bit complex and probably not consi= stent in header and header field uses. Of course, this is a global problem = in SIP literature, but is it a header or a header field? [RJ] OK fixed. header --> header field --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60BECHE113667eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mary,

no= w I have updated the draft with regard to the comments from Dean. More deta= il please see below.

When I get positive feedback on my proposed changes I will upload= the new version on Monday.

I went through a further time and made an additional editori= al wrap-up.

= There was also identified that the ABNF for the time-zone was not correct.<= /span> (Correction of ABNF change UE-time-zone to local-time-zone= )

 

 

Best Regards

 

=

Roland

<= div>

 

 

Here are the comments:<= o:p>

 

In last sentence of 4.2:

     A SIP proxy MUST NOT = insert a P-Called-Party-ID header 

     field in the REGIS= TER requests.

 

Please remove the "the" before "REGISTER"= ;. Explain the MUST. What happens if they do? Will the registrar reject the= request?

[RJ= ] OK

 

Guidance in 4.3.2.1 on SHOULD is lacking. Why? When would this SHOULD= reasonably be violated?

 

<= p class=3DMsoListParagraph>[RJ] Comment on 4.3.2.1: A= =A0 normal User Equipment has no knowledge of the P-Visited-Network-ID when= sending the REGISTER.=A0=A0 This is the task of the first proxy within the= visited network. I do not know why Should not instead of must not was take= n.

 = ;

 

In 4.3.2.3. =  Examples of Usage

 

   Finally, in flow F3, proxy P2 decides= to insert his own identifier,

   derived from its own domain name t= o the P-Visited-Network-ID header

   field.

   

Note the "= his own identifier". How did we determine the masculinity of the proxy= ?

[RJ] OK rep= laced it by its

 

 

 

4.4.2.2 Proxy behavior

 

   An outbound proxy MUST remove any= P-Access-Network-Info

   header field containing a "network-pr= ovided" value.<= /p>

 

[RJ] changed to:=A0 An proxy sending towards an= untrusted entity MUST remove any

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 P-Access= -Network-Info header field containing a "network-provided"

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 val= ue. =E0 I hope that is OK for all.

 

How does a proxy know it's an outbound proxy? Draft-ie= tf-sip-outbound? I think perhaps a clarifying sentence that refers to the e= dge of the protection zone referenced in 4.4.1 would help. Alternatively, a= proxy-requires is needed. Note that the whole 4th paragraph here is a bit = fudgy, and doesn't really address the "outbound" question.

 

[RJ] I hope that this is so= lved with the proposal above.

 

Sentence: "A proxy that provides servi= ces to the user, is typically located in the home network, and therefore tr= usted." This has an extra comma in it after "user".

 

[RJ] OK done

 

 = ;

4.5 Th= e P-Charging Function-Addresses header field

 

The third paragraph "We = define ..." is a bit complex and probably not consistent in header and= header field uses. Of course, this is a global problem in SIP literature, = but is it a header or a header field?

 

[RJ] OK fixed. header = =E0 header field

= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60BECHE113667eme_-- From dean.willis@softarmor.com Fri Sep 13 09:07:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4624011E819D for ; Fri, 13 Sep 2013 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.027 X-Spam-Level: X-Spam-Status: No, score=-102.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt3nGGsqkB18 for ; Fri, 13 Sep 2013 09:07:21 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 12DEA11E8167 for ; Fri, 13 Sep 2013 09:07:20 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so1318863oag.40 for ; Fri, 13 Sep 2013 09:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1OMH21sFcdtn5OHdGrVAHn4bngK6kuDpGho3RN4zPlc=; b=LWP5KFaqmu59i3LTqrzAlR5Uful0UkbojewTFdMRHdBgyxDPRLEu2ykXWsnVnle53k 23/Go56AYgtnOztLryY4OiTjdCo5Hm3gDshONCUT+Xl6ZzEhOrK8+NqCX3YfO0MnuMb9 wBvHZYWRMMK4y940Q/OhuTvd4RwhyPKtSk2g0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1OMH21sFcdtn5OHdGrVAHn4bngK6kuDpGho3RN4zPlc=; b=ll7gTMLyQPtcv0IIiZT0Vsn9YpvjB3n2EAFfrjRoKZRTGUK5hif8HbJur9YgK1S4Mm SAvJNWXXWY7cmeYRkp2AFYrWV9ldHocZgqyjCmVowdbaVBkn/qM+v7JllKGEdpeMOSfd kyN7B0/j1Q2U82Q+V4Oy/opIeLWhazXS6xwIV8CMQ3YQU2aywv4eK1JGn6PhDyalDOdj 5bMAfdmnLJNFdSXxIkeuQ/tyKtOdZs5pTEvtKyNUZwWJJIMH+ynwVjUkN7TSbBHax7dm bo6UtgunOvtXqDyxvXvwFFoYGPVxT9/Wjl84fyd7pOLdzKeR8ojAV+AvwyIi8Zty2Z1O 8txA== X-Gm-Message-State: ALoCoQkaRb5zL9hFc4TWOIBK8p4NSRMUjanNVeWvRnW5Nb2EM6mxmAVWDnPAdju/Wu8/ljCf9rCb X-Received: by 10.182.73.169 with SMTP id m9mr1103678obv.91.1379088436664; Fri, 13 Sep 2013 09:07:16 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id r6sm14937600obi.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 09:07:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3DAEEC19-CE61-437D-9FBC-71071CCDAF3B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: Date: Fri, 13 Sep 2013 11:07:14 -0500 Message-Id: <292C5059-C27E-4453-9455-0F9B6031D2BF@softarmor.com> References: To: Mary Barnes X-Mailer: Apple Mail (2.1508) Cc: DISPATCH Subject: Re: [dispatch] Review of draft-drage-sipping-rfc3455bis-08 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:07:23 -0000 --Apple-Mail=_3DAEEC19-CE61-437D-9FBC-71071CCDAF3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 11, 2013, at 3:12 PM, Mary Barnes = wrote: > Hi all, >=20 > The authors of draft-drage-sipping-rfc3455bis-08 have requested the = ADs to sponsor this document. It is a 3GPP dependency and is an update = of RFC 3455. In order to progress the document, the ADs asked for an = expert review. Dean Willis performed the review detailed below. The = authors will need to update the document to address the changes. In = addition, we need to ensure that no one in the DISPATCH WG has concerns = with regards to progressing this document as AD sponsored. If you do = have concerns, please raise them no later than Wednesday, Oct. 2nd, 2013 = 5pm Pacific. =20 I'm terribly sorry, but seem to have had a major cut-and-paste error in = the text I sent Mary (actually, I've apparently found a new bug in = Chrome OS text editor, which is a new "desktop app"). The full text of my review, with less gibberish, is hopefully here: Review: draft-drage-sipping-rfc3455bis-08 in last sentence of 4.2 A SIP proxy MUST NOT insert a P-Called-Party-ID header field in the REGISTER requests. elimnate "the" before "REGISTER". Explain the MUST. What happens if they = do? WIll the registrar reject the request? 4.3 Question: What is threat model on spoofing P-Visited-Network-ID? Guidance in 4.3.2.1 on SHOULD is lacking. Why? When would this SHOULD = reasonably be violated? IN 4.3.2.3. Examples of Usage Finally, in flow F3, proxy P2 decides to insert his own identifier, derived from its own domain name to the P-Visited-Network-ID header field. =20 Note the "his own identifier". How did we determine the masculinity of = the proxy? 4.4.2.2 Proxy behavior An outbound proxy MUST remove any P-Access-Network-Info header field containing a "network-provided" value. How does a proxy know it's an outbound proxy? Draft-ietf-sip-outbound? I = think perhaps a clarifying sentence that refers to the edge of the = protection zone referenced in 4.4.1 would help. Alternatively, a = proxy-requires is needed. Note that the whole 4th paragraph here is a = bit fudgy, and doesn't reall yaddress the "outbound" question. Sentence: "A proxy that provides services to the user, is typically = located in the home network, and therefore trusted." This has an extra = comma in it after "user". 4.5 The P-ChargingFunction-Addresses header field The third paragraph "We define ..." is a bit complex and probably not = consistent in header and header field uses. Of course, this is a global = problem in SIP literatue, but ... 4.6 The P-Charging-Vector header In the 9th parapgraph: "When presen only one instance of the header MUST = be present in a particular request or response." Probably missing a "t" = on "presen".=20 --Apple-Mail=_3DAEEC19-CE61-437D-9FBC-71071CCDAF3B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSMzgyAAoJENG95ttGtcqroSoQAIBGlkA3NTmiktjel94BsLlj QL8GUr6w6sDekwRKvxjUTgn/+u15d45uasLSMkhGuyKGnWAWmUYech6WrMzJT7cC iAGM0cli0b0Ppt3Vl64Xl1iPcyN7RXJ6gWdeuk6R6ot+0L4R/GtNsxQB0F80J9Dp bghxxbuk2T8uuaW8QPcr3AjjaYYmdmKY0jC36alPsqgyduJnrTwsmkvTH540wboY NWKVE5wZ7/Yn/XwEbUOuJrw/32XuHaOdmtPeu9lxON7ig39EX4uWf2kIBuNRgscY Fal6BEKensk6ycxQOF+8qfKkw9cdTrAs8XMWA2lenSb1QMELBivenmObkyc/Vn2E W9bfpa6ygn/57/YmHLNiIUa08LPyP9KJz9q1/zKCNjNhgjDM77mgq4lZ4oegiJHo vJPnuuEnTmVM/tGcKy715BWv02cYtGahGtQ6ZJ2losdEaSWAsy/u5G5AmWCxUCc3 VHqpQ3Y049aqR+9Y4a5XoeTI3wJ0YPGNsscqqPdq1DMc4bgbrcXqDVpfXluLN8z3 u38LUqaW4vwp6yJbMfnttZKF49qV14Nt+sQV5VbiR9Sytg7QROqs5dYaqUGt2lCk UJ0odGoHKgvdwNQA67PTbobkhqBAnwv3Xfjl2lYQ5WQrRpspjk2IVK7scNYuZjGE 6Zz1KLsnWPKMWW2lzVBx =Wj8H -----END PGP SIGNATURE----- --Apple-Mail=_3DAEEC19-CE61-437D-9FBC-71071CCDAF3B-- From dean.willis@softarmor.com Fri Sep 13 09:16:48 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4F011E812F for ; Fri, 13 Sep 2013 09:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5waPXoECwd3m for ; Fri, 13 Sep 2013 09:16:47 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 860DA11E8167 for ; Fri, 13 Sep 2013 09:16:46 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j10so1376091oah.27 for ; Fri, 13 Sep 2013 09:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VBIhiid9/3W68RmEEEIy0RFNEREEsi237CwlBc8uhkU=; b=MvxW5sBJq8pX2t8EF+dhETu/0bko0+pf0PowmF3vGmWm1U8RRXPy1wror/VG4Cn//z DU0xeaMcEfmmn7ZmzPNQY1LDLlF4s6FMTSgqwxQJQwqCYKq2Aal0NxyTC2tAUN8Eea/q h8vkl50xtIx5tPc0At0Cdqtp8dAuaS9pj9baE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=VBIhiid9/3W68RmEEEIy0RFNEREEsi237CwlBc8uhkU=; b=MCDYZSOe2kPfzLq3kM8TJBnAh/j5Sy3AuCvFYg/WrONX38A8UZTwAcwf+qlrhL+4rZ TRQ4wSuqqut0W5J7vUr6b5E0G5+qGhJrxrs++ecSGaMi7zSxBRDyMdyArOM5lO5RGLnI FvesTVAVf6eh8jMzdSfNSWtDToj4Ll4dYOqtAp+ccMgzqfJS040dc6ocfmu0MtfRRC9D m8InMJwKBuaPv2YN4wya6wiEpT3MPG5yijf2iZuc+4nhbPVB+M8VYxNj6fSklBQH9BEg +OOqRiFBMzH5+JFZO6h9Rbez4KD/MeQ9fj0dJUE11ZupASouoJo/kX7OfPDXasWZbQgb z+7A== X-Gm-Message-State: ALoCoQkQ5svljAF0NOcWe/Znl8+RxUg4bXdCnojFZB+OvaeS95TtZjCPQfOCr4pDFvVeFHB1wFn0 X-Received: by 10.60.96.131 with SMTP id ds3mr12933881oeb.50.1379089005896; Fri, 13 Sep 2013 09:16:45 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id b5sm14914458obj.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 09:16:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CFC5B64B-F3F4-443D-9BF4-3DDD161657FA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60BEC@HE113667.emea1.cds.t-internal.com> Date: Fri, 13 Sep 2013 11:16:44 -0500 Message-Id: References: <058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60BEC@HE113667.emea1.cds.t-internal.com> To: R.Jesske@telekom.de X-Mailer: Apple Mail (2.1508) Cc: dispatch@ietf.org Subject: Re: [dispatch] Review of draft-drage-sipping-rfc3455bis-08 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:16:48 -0000 --Apple-Mail=_CFC5B64B-F3F4-443D-9BF4-3DDD161657FA Content-Type: multipart/alternative; boundary="Apple-Mail=_697B6773-40DE-43E4-B644-42800EF11644" --Apple-Mail=_697B6773-40DE-43E4-B644-42800EF11644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 13, 2013, at 3:25 AM, R.Jesske@telekom.de wrote: > Hi Mary, > now I have updated the draft with regard to the comments from Dean. = More detail please see below. > When I get positive feedback on my proposed changes I will upload the = new version on Monday. > I went through a further time and made an additional editorial = wrap-up. > There was also identified that the ABNF for the time-zone was not = correct. (Correction of ABNF change UE-time-zone to local-time-zone) > =20 > =20 > Best Regards > =20 > Roland > =20 > =20 > Here are the comments: > =20 > In last sentence of 4.2:=20 >=20 > A SIP proxy MUST NOT insert a P-Called-Party-ID header=20 > field in the REGISTER requests. > =20 > Please remove the "the" before "REGISTER". Explain the MUST. What = happens if they do? Will the registrar reject the request? > [RJ] OK > =20 > Guidance in 4.3.2.1 on SHOULD is lacking. Why? When would this SHOULD = reasonably be violated? > =20 > [RJ] Comment on 4.3.2.1: A normal User Equipment has no knowledge of = the P-Visited-Network-ID when sending the REGISTER. This is the task = of the first proxy within the visited network. I do not know why Should = not instead of must not was taken. [DW] This is what happens when we try to use requirements language to = explain "how things work", instead of using them to describe the = LIMITATIONS on how things can be used. RFC 2119 is no substitute for = descriptive prose. I suggest inserting your above explanation, or some close variant = thereof, instead of the SHOULD in question. > =20 > =20 > In 4.3.2.3. Examples of Usage > =20 > Finally, in flow F3, proxy P2 decides to insert his own identifier, > derived from its own domain name to the P-Visited-Network-ID header > field. > =20 > Note the "his own identifier". How did we determine the masculinity of = the proxy? > [RJ] OK replaced it by its >=20 [DW] That was mostly a tongue-in-cheek comment. I'm struggling to learn = Spanish, which has apparently arcane logic for determining the gender of = inanimate objects. Proxies might well be masculine in some languages. So = I'm actually curious about whether there was a real reason to use "his" = here. > =20 > 4.4.2.2 Proxy behavior > =20 > An outbound proxy MUST remove any P-Access-Network-Info > header field containing a "network-provided" value. > =20 > [RJ] changed to: An proxy sending towards an untrusted entity MUST = remove any > P-Access-Network-Info header field containing a = "network-provided" > value. =E0 I hope that is OK for all. > =20 > How does a proxy know it's an outbound proxy? Draft-ietf-sip-outbound? = I think perhaps a clarifying sentence that refers to the edge of the = protection zone referenced in 4.4.1 would help. Alternatively, a = proxy-requires is needed. Note that the whole 4th paragraph here is a = bit fudgy, and doesn't really address the "outbound" question. > =20 > [RJ] I hope that this is solved with the proposal above. [DW] I think this is supported by the discussion of the sensitivity of = network-provided values, so that's probably adequate. > =20 > Sentence: "A proxy that provides services to the user, is typically = located in the home network, and therefore trusted." This has an extra = comma in it after "user". > =20 > [RJ] OK done > =20 > =20 > 4.5 The P-Charging Function-Addresses header field > =20 > The third paragraph "We define ..." is a bit complex and probably not = consistent in header and header field uses. Of course, this is a global = problem in SIP literature, but is it a header or a header field? > =20 > [RJ] OK fixed. header =E0 header field [DW] I believe my cut-and-paste error dropped off a small comment on 4.6=20= 4.6 The P-Charging-Vector header In the 9th parapgraph: "When presen only one instance of the header MUST = be present in a particular request or response." Probably missing a "t" = on the first "presen". --Apple-Mail=_697B6773-40DE-43E4-B644-42800EF11644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Sep 13, 2013, = at 3:25 AM, R.Jesske@telekom.de= wrote:

Hi = Mary,
now I have updated the draft with = regard to the comments from Dean. More detail please see = below.
When I get positive feedback on = my proposed changes I will upload the new version on = Monday.
I went through a further time and = made an additional editorial wrap-up.
There was = also identified that the ABNF for the time-zone was not = correct. (Correction of ABNF = change UE-time-zone to local-time-zone) 
Best Regards
Roland
 
 
Here are the = comments:
 
In last sentence of 4.2: 

    =  A SIP proxy MUST NOT insert a P-Called-Party-ID = header 
     field in the REGISTER = requests.
 
Please remove the "the" before "REGISTER". = Explain the MUST. What happens if they do? Will the registrar reject the = request?
[RJ] = OK
 
Guidance in 4.3.2.1 on SHOULD is lacking. = Why? When would this SHOULD reasonably be = violated?
[RJ] Comment on 4.3.2.1: A  = normal User Equipment has no knowledge of the P-Visited-Network-ID when = sending the REGISTER.   This is the task of the first proxy = within the visited network. I do not know why Should not instead of must = not was = taken.
=

[DW] This is what happens when we try to use = requirements language to explain "how things work", instead of using = them to describe the LIMITATIONS on how things can be used. RFC 2119 is = no substitute for descriptive prose.

I suggest = inserting your above explanation, or some close variant thereof, instead = of the SHOULD in question.

 
In 4.3.2.3.  Examples of = Usage
 
   Finally, in flow F3, proxy P2 = decides to insert his own = identifier,
   derived from its own domain name to = the P-Visited-Network-ID header
  =  field.
  =  
Note the "his own identifier". How did we = determine the masculinity of the proxy?
[RJ] OK = replaced it by its


 
4.4.2.2 Proxy = behavior
 
   An outbound proxy = MUST remove any = P-Access-Network-Info
   header field = containing a "network-provided" value.
 
[RJ] changed to:  An proxy sending towards an untrusted entity MUST remove = any
           = P-Access-Network-Info header field containing a = "network-provided"
=E0 I hope that = is OK for all.
 
How does a proxy know it's an outbound = proxy? Draft-ietf-sip-outbound? I think perhaps a clarifying sentence = that refers to the edge of the protection zone referenced in 4.4.1 would = help. Alternatively, a proxy-requires is needed. Note that the whole 4th = paragraph here is a bit fudgy, and doesn't really address the "outbound" = question.
 
[RJ] I hope that this is solved with the proposal = above.
=

[DW] I think this is supported by the = discussion of the sensitivity of network-provided values, so that's = probably adequate.

 
Sentence: "A proxy that = provides services to the user, is typically located in the home network, = and therefore trusted." This has an extra comma in it after = "user".
 
[RJ] OK = done
 
 
4.5 The P-Charging Function-Addresses header = field
 
The third paragraph "We define ..." is a = bit complex and probably not consistent in header and header field uses. = Of course, this is a global problem in SIP literature, but is it a = header or a header field?
 
[RJ] OK fixed. header =E0 header = field

[DW] I believe my cut-and-paste error dropped off a small comment = on 4.6 


4.6 The P-Charging-Vector header

In = the 9th parapgraph: "When presen only one instance of the header MUST be = present in a particular request or response." Probably missing a "t" on = the first "presen".
= --Apple-Mail=_697B6773-40DE-43E4-B644-42800EF11644-- --Apple-Mail=_CFC5B64B-F3F4-443D-9BF4-3DDD161657FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSMzpsAAoJENG95ttGtcqrzx4P/iz5RYRw1o7d15OUG2O2dRNl vbwRUj3oNTesqcY6NqW7tWjVQAyBNf2ZQRLY2oEDI776kU2kxxmm06CUFBqAS3hQ xRf6h65cSr3TvVIm1bzUT9/i+vxtmPMohKOr5JOMb57IE9Q7qzSXFiPoLRVhfL+m xYDiNpJSNlsTAmtbB6NyLdNBdN2aMpcBylcCNwAr+WkeAcxLPmyFfVMKBojUxjnp 56Hfb3zC0BBC9qUFprRBOmO6R6f/TBizaz8EPrI44i5uMEd553flIz8+bJPE40N1 DSBawB9Jye7pDppDT/7O5rBMzKbqafg0BiG1djfWdDjyUo1IYisK0JwLwsINfE95 hPm0d4s01EArAikZ2+CWIs8/NUkPOQIDfGvykIMG0QbaVd3zQ9Zc86WLnkD88m+7 JCYbS8E6DFQUXQ+PGjuY0TEnqqdX8k5mlxxhQwUMgwivcytqT3sHjvWKRAh646jk BmefbC/wQx3PTKAlwd3YCbJB8mtEcBPjxILt9158Uk8tBCnHXfBOWqyWTJNeWl/h hPKehq6KYAX/46ruhdzGIug5h8Ij2uUuiDWz9JKkEDK1h/LQ5GMejw6wy8jOSm+6 t+c59oXEa8coUb/s/21CT3FDbdjHf4dbrSC8CUD4wq5wn8Ju8YvJiBvM3SmXMGHz f8x6i4q2juQ6PtZJ2Dm3 =5E/B -----END PGP SIGNATURE----- --Apple-Mail=_CFC5B64B-F3F4-443D-9BF4-3DDD161657FA-- From mary.ietf.barnes@gmail.com Mon Sep 16 14:34:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C0811E815B for ; Mon, 16 Sep 2013 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP2I5w82f8nU for ; Mon, 16 Sep 2013 14:34:42 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBE511E8112 for ; Mon, 16 Sep 2013 14:34:42 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id hu16so1460389qab.14 for ; Mon, 16 Sep 2013 14:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Fhjrdw1Y6LlGHWCeykfzcjHZo5ppues1EPKBNZFegNQ=; b=Cue694ytXAx9FCS32DRt+LTSmxX8d+zDjKxNi+SjMF+1bW2NWiQ+G8gIrWaknaSwsj iZh9innK0lhAv5Wp8GXhmFlcvuz188Dw3D1v2IKQ5Syzy2ytss+CZdC5+6AIQ1CnQqJw VsXqegPCWIuLzU+2MK1pzowDpJkNDUlRiIn/APRPHC+7aXweXm0XKtGq2mCGjsKxtHWe aEYtERr2LFxoDOTyHfzDPtJYsrZ2Q1+lRRGatI1VL4FAz1Fa7uzV5ke8g1mU7zal01YO oEmwvloFcilf4X50KCRfZQzPbtHEdoc90bVyDn39UhlpJMZ5umhAuKqPLGukljmY3oOi YpxQ== MIME-Version: 1.0 X-Received: by 10.229.228.195 with SMTP id jf3mr49018381qcb.0.1379367281924; Mon, 16 Sep 2013 14:34:41 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Mon, 16 Sep 2013 14:34:41 -0700 (PDT) Date: Mon, 16 Sep 2013 16:34:41 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a11343d60daa0c804e686f82c Cc: Cullen Jennings Subject: [dispatch] Reminder: IETF-88 deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:34:43 -0000 --001a11343d60daa0c804e686f82c Content-Type: text/plain; charset=ISO-8859-1 As a reminder, the DISPATCH deadlines for IETF-88 per the wiki are as follows: http://trac.tools.ietf.org/wg/dispatch/trac/wiki - Oct 1, 2013. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. - Oct 7, 2013. Cutoff for charter proposals for topics. - Oct 21, 2013. Draft deadline. We do not assume that just because you've submitted a draft that you might want agenda time. We need explicit emails - you can send those directly to the chairs. Including "IETF-88 Agenda request" or "IETF-88 Topic Proposal" in the subject line will ensure we don't miss your request. As a reminder, we don't need solutions at this stage in DISPATCH - we need problem statements, objectives, milestones, etc. We need to understand why you want to do the work and exactly what work you believe needs to be done. You should be starting threads of discussion on the mailing list and include a link to any relevant drafts. We generally do not allocate agenda time or dispatch topics unless there is mailing list discussion. Regards, Mary DISPATCH WG co-chair --001a11343d60daa0c804e686f82c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a reminder, the DISPATCH deadlines for IETF-88 per the = wiki are as follows: =A0http://tr= ac.tools.ietf.org/wg/dispatch/trac/wiki
  • Oct 1, 2013. Cutof= f date to notify the chairs/DISPATCH WG of plans to submit a proposal.
    • =
  • Oct 7, 2013. Cutoff for charter proposals for topics.
  • Oct 21, 2013. Draft deadline.
We do not assume that just because you've s= ubmitted a draft that you might want agenda time. =A0We need explicit email= s - you can send those directly to the chairs. =A0Including "IETF-88 A= genda request" or "IETF-88 Topic Proposal" in the subject li= ne will ensure we don't miss your request. =A0

As a reminder= , we don't need solutions at this stage in DISPATCH - we need problem s= tatements, objectives, milestones, etc. =A0We need to understand why you wa= nt to do the work and exactly what work you believe needs to be done. =A0Yo= u should be starting threads of discussion on the mailing list and include = a link to any relevant drafts. We generally do not allocate agenda time or = dispatch topics unless there is mailing list discussion.

Regards,
Mary=A0=
DISPATCH WG co-= chair
--001a11343d60daa0c804e686f82c-- From R.Jesske@telekom.de Tue Sep 17 23:22:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C417211E8125 for ; Tue, 17 Sep 2013 23:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqF8m680wwS9 for ; Tue, 17 Sep 2013 23:22:27 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id E041311E8129 for ; Tue, 17 Sep 2013 23:22:25 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 18 Sep 2013 08:22:23 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 18 Sep 2013 08:22:23 +0200 From: To: Date: Wed, 18 Sep 2013 08:22:21 +0200 Thread-Topic: [dispatch] Review of draft-drage-sipping-rfc3455bis-08 Thread-Index: Ac6wnLPhLPAUTGgQQpy8OXkelMIKSQDmc+zA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DD50BB7049@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60BEC@HE113667.emea1.cds.t-internal.com> <29420723.6391.1379089029262.JavaMail.trustmail@he111469> In-Reply-To: <29420723.6391.1379089029262.JavaMail.trustmail@he111469> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01DD50BB7049HE113667eme_" MIME-Version: 1.0 Cc: dispatch@ietf.org Subject: Re: [dispatch] Review of draft-drage-sipping-rfc3455bis-08 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 06:22:33 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DD50BB7049HE113667eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dean, Thank you for your comments. I have incorporated everything. The text in 4.3.2.1 is now. A normal User Equipment has normally no knowledge of the P-Visited-Network-= ID when sending the REGISTER. Therefore user agent clients do not insert a = P-Visited-Network-ID header field in any SIP message. I hope everybody is now happy. When I receive the last comments I will update the draft and upload it. Best regards Roland Guidance in 4.3.2.1 on SHOULD is lacking. Why? When would this SHOULD reaso= nably be violated? [RJ] Comment on 4.3.2.1: A normal User Equipment has no knowledge of the P= -Visited-Network-ID when sending the REGISTER. This is the task of the fi= rst proxy within the visited network. I do not know why Should not instead = of must not was taken. [DW] This is what happens when we try to use requirements language to expla= in "how things work", instead of using them to describe the LIMITATIONS on = how things can be used. RFC 2119 is no substitute for descriptive prose. I suggest inserting your above explanation, or some close variant thereof, = instead of the SHOULD in question. --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DD50BB7049HE113667eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dean,

Thank you for your comments.

I have incorporated everyth= ing.

The text in 4.3.2.1 is now.

A normal User Equipment has normally no knowledge of the P-Vis= ited-Network-ID when sending the REGISTER. Therefore user agent clients do = not insert a P-Visited-Network-ID header field in any SIP message.

 

I hope eve= rybody is now happy.

When I receive the last comments I will up= date the draft and upload it.

 

Best regards<= /o:p>

 

Roland

 

 

Guidance in 4.3.2.1 on SHOUL= D is lacking. Why? When would this SHOULD reasonably be violated?

 

[RJ] Comment on 4.3.2.1: A  normal User Equipment has no kno= wledge of the P-Visited-Network-ID when sending the REGISTER.   T= his is the task of the first proxy within the visited network. I do not kno= w why Should not instead of must not was taken.

=

 

[DW] This is what happens when we t= ry to use requirements language to explain "how things work", ins= tead of using them to describe the LIMITATIONS on how things can be used. R= FC 2119 is no substitute for descriptive prose.

 

I s= uggest inserting your above explanation, or some close variant thereof, ins= tead of the SHOULD in question.


= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DD50BB7049HE113667eme_-- From fas_vm@surguttel.ru Wed Sep 18 12:40:19 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B3311E8140 for ; Wed, 18 Sep 2013 12:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.432 X-Spam-Level: *** X-Spam-Status: No, score=3.432 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_BL_SPAMCOP_NET=1.96, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8+umf4ezAGg for ; Wed, 18 Sep 2013 12:40:13 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id DF45111E8291 for ; Wed, 18 Sep 2013 12:39:55 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 978A2515274; Thu, 19 Sep 2013 01:38:19 +0600 (YEKT) Received: from Gateway (unknown [151.252.75.113]) by mail.s86.ru (Postfix) with ESMTPA id 6D38F514B91 for ; Thu, 19 Sep 2013 01:38:16 +0600 (YEKT) Message-ID: From: "Anton Tveretin" To: Date: Thu, 19 Sep 2013 01:35:10 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130918-4, 18.09.2013), Outbound message X-Antivirus-Status: Clean Subject: [dispatch] Call management and USSD X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 19:40:19 -0000 Dear All, The term USSD is used to the 2 different things. The first one is formally called "Man-Machine interface", 3GPP 22.030. Informally, they use "USSD codes". Examples... Of course, some codes to not need any network traffic, and others are implemented with USSD (see below). The second one is 3GPP 24.008, and associated functions of MAP (29.002). It is called "Unstructured supplementary services data" (USSD) and actualy defines a bearer, similar to D-channel bearer of ISDN. The are examples of its usage as of bearer (WAP), unassociated from MMI. Since early versions of H.323, HTTP is suggested for network-level supplementary service handling. However, ISTM that there are no standard URLs, and user has to navigate through pages. Common way to manage calls (activate or deactivate call forwarding, for instance) allows to use alternative approaches (e.g. menu) that is device-specific and not provider-specific. I suggest making a list of services not mentioned in 22.030 (I would add CUG management, AOC activation and "probing" i.e. checking cost of call without actually making it, and billing-related). Later, I think there should be either standard URLs, or SIP dialogs used (again, with standard URLs). Sincerely yours, Anton. From GOPALAKR@infosys.com Wed Sep 18 21:31:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F3211E80F9 for ; Wed, 18 Sep 2013 21:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH2k5XBRvpYX for ; Wed, 18 Sep 2013 21:31:46 -0700 (PDT) Received: from KECGATE03.infosys.com (kecgate03.infosys.com [122.98.10.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2A711E80D1 for ; Wed, 18 Sep 2013 21:31:44 -0700 (PDT) X-TM-IMSS-Message-ID: <616f5c6d000e06e9@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id 616f5c6d000e06e9 ; Thu, 19 Sep 2013 09:57:51 +0530 Received: from BLRKECHUB06.ad.infosys.com (10.66.236.116) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 Sep 2013 10:01:05 +0530 Received: from BLRKECMBX22.ad.infosys.com ([fe80::f035:6246:a69c:67fc]) by BLRKECHUB06.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 10:01:05 +0530 From: GOPALAKR To: "dispatch@ietf.org" Thread-Topic: [dispatch] Dispatch request: draft-ilan-dispatch-subscription-diff-list-00.txt Thread-Index: Ac608Q0rVtonNn4VSK6155iP6y+yhA== Date: Thu, 19 Sep 2013 04:31:04 +0000 Message-ID: Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.236.167] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: ilankumaran Subject: [dispatch] Dispatch request: draft-ilan-dispatch-subscription-diff-list-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 04:31:50 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBT ZXB0ZW1iZXIgMTYsIDIwMTMgMTA6MjcgUE0NClRvOiBHT1BBTEFLUjsgaWxhbmt1bWFyYW47IEdP UEFMQUtSDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlsYW4t ZGlzcGF0Y2gtc3Vic2NyaXB0aW9uLWRpZmYtbGlzdC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtaWxhbi1kaXNwYXRjaC1zdWJzY3JpcHRpb24tZGlmZi1saXN0LTAwLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOIElsYW5rdW1hcmFuIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1pbGFuLWRp c3BhdGNoLXN1YnNjcmlwdGlvbi1kaWZmLWxpc3QNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFN1 YnNjcmlwdGlvbiB0byBEaWZmZXJudGlhbCBSZXNvdXJjZSBsaXN0cyBpbiBTSVAgUHJlc2VuY2Ug RXZlbnQgTm90aWZpY2F0aW9uIG1vZGVsDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wOS0xNg0KR3Jv dXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEyDQpVUkw6ICAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlsYW4t ZGlzcGF0Y2gtc3Vic2NyaXB0aW9uLWRpZmYtbGlzdC0wMC50eHQNClN0YXR1czogICAgICAgICAg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pbGFuLWRpc3BhdGNoLXN1YnNj cmlwdGlvbi1kaWZmLWxpc3QNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWxhbi1kaXNwYXRjaC1zdWJzY3JpcHRpb24tZGlmZi1saXN0LTAwDQoNCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGFuIGV4dGVuc2lvbiB0byBjcmVh dGUgYSBkaWZmZXJlbnRpYWwgcmVzb3VyY2UNCiAgIGxpc3QgY29udGFpbmVkIGluIHRoZSBzdWJz Y3JpcHRpb24gcmVxdWVzdHMgZm9yIFNJUCBwcmVzZW5jZS4gVGhlDQogICBtb2RlbCBkZWZpbmVk IGluIHRoaXMgZG9jdW1lbnQgZXhwYW5kcyBvbiBbUkZDIDUzNjddLCB0byBzcGVjaWZ5DQogICBz ZW1hbnRpY3MgZm9yIHRoZSBkaWZmZXJlbnRpYWwgcmVzb3VyY2UgbGlzdCBjYXJyaWVkIGluIFNV QlNDUklCRQ0KICAgcmVxdWVzdHMgZm9yIHN1YnNjcmlwdGlvbiByZWZyZXNoZXMuIFRoaXMgZW5h YmxlcyBmdXRoZXIgb3B0aW1pemF0aW9uDQogICBvZiBiYWNrLWVuZCBzdWJzY3JpcHRpb25zIGJl dHdlZW4gUkxTIGFuZCBpbnRlci1kb21haW4gUFMsIGFuZCB0aGUNCiAgIHJlc3VsdGFudCBub3Rp ZmljYXRpb25zIG9wdGltaXplZCBmb3IgZHluYW1pY2FsbHkgdXBkYXRlZCByZXNvdXJjZQ0KICAg bGlzdHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KKioqKioqKioqKioq KioqKiBDQVVUSU9OIC0gRGlzY2xhaW1lciAqKioqKioqKioqKioqKioqKg0KVGhpcyBlLW1haWwg Y29udGFpbnMgUFJJVklMRUdFRCBBTkQgQ09ORklERU5USUFMIElORk9STUFUSU9OIGludGVuZGVk IHNvbGVseSANCmZvciB0aGUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSANCm5vdGlmeSB0aGUgc2VuZGVyIGJ5IGUt bWFpbCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlLiBGdXJ0aGVyLCB5b3UgYXJlIG5v dCANCnRvIGNvcHksIGRpc2Nsb3NlLCBvciBkaXN0cmlidXRlIHRoaXMgZS1tYWlsIG9yIGl0cyBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uIGFuZCANCmFueSBzdWNoIGFjdGlvbnMgYXJlIHVu bGF3ZnVsLiBUaGlzIGUtbWFpbCBtYXkgY29udGFpbiB2aXJ1c2VzLiBJbmZvc3lzIGhhcyB0YWtl biANCmV2ZXJ5IHJlYXNvbmFibGUgcHJlY2F1dGlvbiB0byBtaW5pbWl6ZSB0aGlzIHJpc2ssIGJ1 dCBpcyBub3QgbGlhYmxlIGZvciBhbnkgZGFtYWdlIA0KeW91IG1heSBzdXN0YWluIGFzIGEgcmVz dWx0IG9mIGFueSB2aXJ1cyBpbiB0aGlzIGUtbWFpbC4gWW91IHNob3VsZCBjYXJyeSBvdXQgeW91 ciANCm93biB2aXJ1cyBjaGVja3MgYmVmb3JlIG9wZW5pbmcgdGhlIGUtbWFpbCBvciBhdHRhY2ht ZW50LiBJbmZvc3lzIHJlc2VydmVzIHRoZSANCnJpZ2h0IHRvIG1vbml0b3IgYW5kIHJldmlldyB0 aGUgY29udGVudCBvZiBhbGwgbWVzc2FnZXMgc2VudCB0byBvciBmcm9tIHRoaXMgZS1tYWlsIA0K YWRkcmVzcy4gTWVzc2FnZXMgc2VudCB0byBvciBmcm9tIHRoaXMgZS1tYWlsIGFkZHJlc3MgbWF5 IGJlIHN0b3JlZCBvbiB0aGUgDQpJbmZvc3lzIGUtbWFpbCBzeXN0ZW0uDQoqKipJTkZPU1lTKioq KioqKiogRW5kIG9mIERpc2NsYWltZXIgKioqKioqKipJTkZPU1lTKioq From fas_vm@surguttel.ru Thu Sep 19 09:25:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF421F935A for ; Thu, 19 Sep 2013 09:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.438 X-Spam-Level: **** X-Spam-Status: No, score=4.438 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_50=0.001, FAKE_REPLY_C=2.012, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_BL_SPAMCOP_NET=1.96, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxfE67rI4DN7 for ; Thu, 19 Sep 2013 09:25:04 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5D42221F958A for ; Thu, 19 Sep 2013 09:25:01 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id ECCF7516C1F; Thu, 19 Sep 2013 22:24:56 +0600 (YEKT) Received: from Gateway (unknown [151.252.74.229]) by mail.s86.ru (Postfix) with ESMTPA id 973FF5168EE; Thu, 19 Sep 2013 22:24:53 +0600 (YEKT) Message-ID: From: "Anton Tveretin" To: Date: Thu, 19 Sep 2013 22:24:12 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130919-1, 19.09.2013), Outbound message X-Antivirus-Status: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP Problem Statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:25:10 -0000 Still, I think there should be a BCP or information-level RFC. How to discriminate conference ad hoc URIs from other conference URIs and other URIs? Should there be one more invalid URI as a placeholder for unknown conference URI? Wed, 04 Sep 2013 13:36:10 -0500 Robert Sparks: No, it doesn't really. I can see how you draw that from the text, but if you look at the mechanics, there is nothing in it that makes the URI itself special. It was always the intent to allow ad-hoc conferences/mixing at the UA using this mechanism, and I've seen it implemented. RjS From keith.drage@alcatel-lucent.com Thu Sep 19 09:36:08 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C152221F97C7 for ; Thu, 19 Sep 2013 09:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx0k6+FC1fxj for ; Thu, 19 Sep 2013 09:36:03 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B5F0C21F96ED for ; Thu, 19 Sep 2013 09:36:03 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r8JGZwVw014252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Sep 2013 11:36:00 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r8JGZv8L016520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 18:35:58 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 19 Sep 2013 18:35:57 +0200 From: "DRAGE, Keith (Keith)" To: Anton Tveretin , "dispatch@ietf.org" Thread-Topic: [dispatch] Call management and USSD Thread-Index: AQHOtKbyOuEQ6X5v7kOP9n7f7QyrQ5nNQkQw Date: Thu, 19 Sep 2013 16:35:57 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0A71B5@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [dispatch] Call management and USSD X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:36:08 -0000 For USSD see: ftp://ftp.3gpp.org/Specs/html-info/24390.htm=20 As far as I am aware USSD is used only by mobile operators, which presumabl= y have no H.323 deployment. In regard to supplementary service management, see: ftp://ftp.3gpp.org/Specs/html-info/24623.htm=20 There is also=20 ftp://ftp.3gpp.org/Specs/html-info/24238.htm=20 which uses dialstrings, but does not specify them. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Anton Tveretin > Sent: 18 September 2013 20:35 > To: dispatch@ietf.org > Subject: [dispatch] Call management and USSD >=20 > Dear All, > The term USSD is used to the 2 different things. > The first one is formally called "Man-Machine interface", 3GPP 22.030. > Informally, they use "USSD codes". Examples... Of course, some codes to > not > need any network traffic, and others are implemented with USSD (see below= ). > The second one is 3GPP 24.008, and associated functions of MAP (29.002). > It > is called "Unstructured supplementary services data" (USSD) and actualy > defines a bearer, similar to D-channel bearer of ISDN. The are examples o= f > its usage as of bearer (WAP), unassociated from MMI. > Since early versions of H.323, HTTP is suggested for network-level > supplementary service handling. However, ISTM that there are no standard > URLs, and user has to navigate through pages. > Common way to manage calls (activate or deactivate call forwarding, for > instance) allows to use alternative approaches (e.g. menu) that is > device-specific and not provider-specific. > I suggest making a list of services not mentioned in 22.030 (I would add > CUG > management, AOC activation and "probing" i.e. checking cost of call > without > actually making it, and billing-related). > Later, I think there should be either standard URLs, or SIP dialogs used > (again, with standard URLs). > Sincerely yours, Anton. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From worley@shell01.TheWorld.com Fri Sep 20 13:01:29 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B97221F9E40 for ; Fri, 20 Sep 2013 13:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2W1PhEhOpDb for ; Fri, 20 Sep 2013 13:01:23 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id E881F21F9CAF for ; Fri, 20 Sep 2013 13:01:20 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r8KK0wXU000384; Fri, 20 Sep 2013 16:01:00 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r8KK0wq81469142; Fri, 20 Sep 2013 16:00:58 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r8KK0vQG1472249; Fri, 20 Sep 2013 16:00:57 -0400 (EDT) Date: Fri, 20 Sep 2013 16:00:57 -0400 (EDT) Message-Id: <201309202000.r8KK0vQG1472249@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: GOPALAKR In-reply-to: (GOPALAKR@infosys.com) References: Cc: ilankumaran@infosys.com, dispatch@ietf.org Subject: [dispatch] Comments on the abstract of draft-ilan-dispatch-subscription-diff-list-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 20:01:29 -0000 > Filename: draft-ilan-dispatch-subscription-diff-list > Revision: 00 > Title: Subscription to Differntial Resource lists in SIP Presence Event Notification model > Abstract: > This document presents an extension to create a differential resource > list contained in the subscription requests for SIP presence. The > model defined in this document expands on [RFC 5367], to specify > semantics for the differential resource list carried in SUBSCRIBE > requests for subscription refreshes. This enables futher optimization > of back-end subscriptions between RLS and inter-domain PS, and the > resultant notifications optimized for dynamically updated resource > lists. Since the abstract is supposed to be understandable without reading the body of the RFC, it would be helpful to provide an explanation of what a "differentisl resource list" is. Also, the acronyms "RLS" and "PS" are not explained. Dale From GOPALAKR@infosys.com Mon Sep 23 04:59:54 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D7A21F94FA for ; Mon, 23 Sep 2013 04:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak3n5vdCKht3 for ; Mon, 23 Sep 2013 04:59:48 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) by ietfa.amsl.com (Postfix) with ESMTP id 237C621F9343 for ; Mon, 23 Sep 2013 04:59:45 -0700 (PDT) X-TM-IMSS-Message-ID: <01187bd500006a63@infosys.com> Received: from BLRKECHUB05.ad.infosys.com ([10.66.236.45]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 01187bd500006a63 ; Mon, 23 Sep 2013 17:29:44 +0530 Received: from BLRKECHUB10.ad.infosys.com (10.66.236.120) by BLRKECHUB05.ad.infosys.com (10.66.236.45) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 23 Sep 2013 17:28:47 +0530 Received: from BLRKECMBX22.ad.infosys.com ([fe80::f035:6246:a69c:67fc]) by blrkechub10.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 17:28:47 +0530 From: GOPALAKR To: "Dale R. Worley" Thread-Topic: Comments on the abstract of draft-ilan-dispatch-subscription-diff-list-00.txt Thread-Index: Ac64SYoAI403FBcGSGWWlIKXptXkuA== Date: Mon, 23 Sep 2013 11:58:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.236.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ilankumaran , "dispatch@ietf.org" Subject: Re: [dispatch] Comments on the abstract of draft-ilan-dispatch-subscription-diff-list-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:59:58 -0000 Hi Dale, These acronyms were based on the SIP SIMPLE work group definitions. (and = I had assumed these are for liberal usage in individual drafts) I understand I need to submit individual drafts to "DISPATCH" work group= , prior to consideration by chairs. I have modified abstract as per your comments. (new version draft-ilan-di= spatch-subscription-diff-lists-01.txt) Thanks Gopal -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com] Sent: Saturday, September 21, 2013 1:31 AM To: GOPALAKR Cc: dispatch@ietf.org; ilankumaran Subject: Comments on the abstract of draft-ilan-dispatch-subscription-dif= f-list-00.txt > Filename:=09 draft-ilan-dispatch-subscription-diff-list > Revision:=09 00 > Title:=09 Subscription to Differntial Resource lists in SIP Presence Ev= ent Notification model > Abstract: > This document presents an extension to create a differential resourc= e > list contained in the subscription requests for SIP presence. The > model defined in this document expands on [RFC 5367], to specify > semantics for the differential resource list carried in SUBSCRIBE > requests for subscription refreshes. This enables futher optimizatio= n > of back-end subscriptions between RLS and inter-domain PS, and the > resultant notifications optimized for dynamically updated resource > lists. Since the abstract is supposed to be understandable without reading the b= ody of the RFC, it would be helpful to provide an explanation of what a "= differentisl resource list" is. Also, the acronyms "RLS" and "PS" are no= t explained. Dale **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From tom.taylor.stds@gmail.com Mon Sep 23 05:38:44 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3164221F9E1D for ; Mon, 23 Sep 2013 05:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nsfzhd+UqO9 for ; Mon, 23 Sep 2013 05:38:35 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id BEE9421F9E76 for ; Mon, 23 Sep 2013 05:38:31 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id aq17so6416639iec.13 for ; Mon, 23 Sep 2013 05:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tED/gFX7ei2nzM+ypiPhcYcBSY2CI+N00Y73qf7YKbk=; b=04Jy0M4AwpQPyrXoN2H1ZajQpAxNFBATmhuJJzqcedmR9d5Df9eZht/pNorbm0meia fvgBssrLDEBbgAj4wZR5IA8//epsH43FEYCjGows06RkWzw7qMbwsf3iN3NRR7X7GvNP dpLFM4fYfzkFtzokrQilA3dyFaVvpNqSEBkILhpBbKkD9PZReqns+HIj+Qyp/mmAR0Gz jzUms7qWLMLdMHn8t/nmG3klTNQn4kYyjztqb+fiVQ8GqA0p61Pt9lmz0wYw3mrjD2q+ 2z+mnGnPiot+5RlmwRvv3mKH8GJwTvLnuJ/UPOV8CYPABBf8wsl7ooF0qZAi2JCYeWAw Jh8w== X-Received: by 10.43.132.138 with SMTP id hu10mr116274icc.72.1379939909003; Mon, 23 Sep 2013 05:38:29 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id t7sm18532093igd.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 05:38:28 -0700 (PDT) Message-ID: <52403643.1000104@gmail.com> Date: Mon, 23 Sep 2013 08:38:27 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: GOPALAKR References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , ilankumaran Subject: Re: [dispatch] Comments on the abstract of draft-ilan-dispatch-subscription-diff-list-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 12:38:44 -0000 The well-known acronyms are the starred items in the RFC Editor's list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt. All others must be spelled out on first use. On 23/09/2013 7:58 AM, GOPALAKR wrote: > Hi Dale, > These acronyms were based on the SIP SIMPLE work group definitions. (and I had assumed these are for liberal usage in individual drafts) > I understand I need to submit individual drafts to "DISPATCH" work group, prior to consideration by chairs. > > I have modified abstract as per your comments. (new version draft-ilan-dispatch-subscription-diff-lists-01.txt) > > Thanks > Gopal > > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Saturday, September 21, 2013 1:31 AM > To: GOPALAKR > Cc: dispatch@ietf.org; ilankumaran > Subject: Comments on the abstract of draft-ilan-dispatch-subscription-diff-list-00.txt > >> Filename: draft-ilan-dispatch-subscription-diff-list >> Revision: 00 >> Title: Subscription to Differntial Resource lists in SIP Presence Event Notification model > >> Abstract: >> This document presents an extension to create a differential resource >> list contained in the subscription requests for SIP presence. The >> model defined in this document expands on [RFC 5367], to specify >> semantics for the differential resource list carried in SUBSCRIBE >> requests for subscription refreshes. This enables futher optimization >> of back-end subscriptions between RLS and inter-domain PS, and the >> resultant notifications optimized for dynamically updated resource >> lists. > > Since the abstract is supposed to be understandable without reading the body of the RFC, it would be helpful to provide an explanation of what a "differentisl resource list" is. Also, the acronyms "RLS" and "PS" are not explained. > > Dale > ... From fas_vm@surguttel.ru Mon Sep 23 10:21:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2787A21F9F74 for ; Mon, 23 Sep 2013 10:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.935 X-Spam-Level: *** X-Spam-Status: No, score=3.935 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_BL_SPAMCOP_NET=1.96, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7M0nfPWgzi4 for ; Mon, 23 Sep 2013 10:21:45 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5909821F9F4F for ; Mon, 23 Sep 2013 10:21:45 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 58) id 5FF24514711; Mon, 23 Sep 2013 23:21:38 +0600 (YEKT) Received: from Gateway (unknown [151.252.73.249]) by mail.s86.ru (Postfix) with ESMTPA id 8F25C514411; Mon, 23 Sep 2013 23:21:33 +0600 (YEKT) Message-ID: <43319E51A4E74EC7BE189E6D00DE47A6@Gateway> From: "Anton Tveretin" To: "DRAGE, Keith \(Keith\)" References: <949EF20990823C4C85C18D59AA11AD8B0A71B5@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 23 Sep 2013 22:56:48 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130923-0, 23.09.2013), Outbound message X-Antivirus-Status: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Call management and USSD X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 17:21:50 -0000 That's what I want to change. :) "As far as I am aware USSD is used only by mobile operators, which presumably have no H.323 deployment." Also, I think there should be a code for 3pcc. Namely, to trust third party to initiate calls, and to get list of trustees or trustors. This also covers "doctor" scenario discussed in STIR. I noticed that many phones (incl. softphones) still use numeric keyboard, so it is a good idea to use numeric codes. As an example implementation: 1. REGISTER response contains an URL (http(s):, wap:, sip(s):, etc). 2. When user inputs an MMI code, dispatch it as text/plain body to that URL, or alternatively transform that URL (for further study). 3. Process response. This may start a SIP dialog or cookie-based HTTP session, or complete in a single transaction. 4. Further exchange messages. 5. Terminate the dialog on user action. ----- Original Message ----- From: "DRAGE, Keith (Keith)" To: "Anton Tveretin" ; Sent: Thursday, September 19, 2013 10:35 PM Subject: RE: [dispatch] Call management and USSD For USSD see: ftp://ftp.3gpp.org/Specs/html-info/24390.htm In regard to supplementary service management, see: ftp://ftp.3gpp.org/Specs/html-info/24623.htm There is also ftp://ftp.3gpp.org/Specs/html-info/24238.htm which uses dialstrings, but does not specify them. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Anton Tveretin > Sent: 18 September 2013 20:35 > To: dispatch@ietf.org > Subject: [dispatch] Call management and USSD > > Dear All, > The term USSD is used to the 2 different things. > The first one is formally called "Man-Machine interface", 3GPP 22.030. > Informally, they use "USSD codes". Examples... Of course, some codes to > not > need any network traffic, and others are implemented with USSD (see > below). > The second one is 3GPP 24.008, and associated functions of MAP (29.002). > It > is called "Unstructured supplementary services data" (USSD) and actualy > defines a bearer, similar to D-channel bearer of ISDN. The are examples of > its usage as of bearer (WAP), unassociated from MMI. > Since early versions of H.323, HTTP is suggested for network-level > supplementary service handling. However, ISTM that there are no standard > URLs, and user has to navigate through pages. > Common way to manage calls (activate or deactivate call forwarding, for > instance) allows to use alternative approaches (e.g. menu) that is > device-specific and not provider-specific. > I suggest making a list of services not mentioned in 22.030 (I would add > CUG > management, AOC activation and "probing" i.e. checking cost of call > without > actually making it, and billing-related). > Later, I think there should be either standard URLs, or SIP dialogs used > (again, with standard URLs). > Sincerely yours, Anton. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch