From nobody Sun Mar 2 10:38:22 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9401A09CB for ; Sun, 2 Mar 2014 10:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLxB2nl-m9Wu for ; Sun, 2 Mar 2014 10:38:18 -0800 (PST) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id DDAFC1A09BC for ; Sun, 2 Mar 2014 10:38:17 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id j17so1609911oag.28 for ; Sun, 02 Mar 2014 10:38:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=RVIw6AWIffW2dDOdAZWgfbZsXHlqrC6wX8vP4uNQeaE=; b=iA4vnTCH5/Uvj2ZyNcI/6omWLC8a5nD1BwfwCWIOmW9zj0K/R3lxGOWnWI042BmD69 QZ1xxlDeJjnTHGVHxFAl808RfzXJCdjohtdYJBwKTGfPuFz3NTpi+JpaZDVxRhouUwfw 8G8IDUHkaFFY3SoUg/UYqYcRLPH2LY3Q/n40HUnhUJTJU6AH1qSFu8YaTt10jAjIbCXO KiGwQD+DV8VGsEYSDi1GL2/JDOvr1L9+h+GvZyrKoVgzC4IIoqdn860qNXYvEWixU7f1 9H082vjeCIoCfcxoExvpgo1x42Lpb4PMtcNU3lr0C4a4YOZ7CE2TY7U5FkA1HMBHn5ix rvrA== X-Gm-Message-State: ALoCoQkstVekR8A2vQ3ZlY6atPB0sj5FTChhwOtMWAobEwHiIyCwe5fBQn+/MWoQIHi6Y0LASZAb MIME-Version: 1.0 X-Received: by 10.182.230.135 with SMTP id sy7mr23994254obc.24.1393785495161; Sun, 02 Mar 2014 10:38:15 -0800 (PST) Received: by 10.60.69.102 with HTTP; Sun, 2 Mar 2014 10:38:15 -0800 (PST) Date: Sun, 2 Mar 2014 18:38:15 +0000 Message-ID: From: Richard Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a11c3367655216104f3a3f954 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/1_LhljVnWqlFrYGcnqEzMmsSjuU Subject: [dispatch] Proposed mini-WG: DiffServ considerations for real-time communications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 18:38:19 -0000 --001a11c3367655216104f3a3f954 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear DISPATCH, The RAI and TSV ADs and several WG chairs have been discussing how to address several transport concerns arising from draft-ietf-rtcweb-transport and draft-dhesikan-tsvwg-rtcweb-qos (n=E9e draft-ietf-rtcweb-qos). One thi= ng that emerged from that discussion is the need for a document to describe certain realities regarding DiffServ and (possibly) multiplexed flows. Unforunately, such a document does not fall within the charters of current RAI WGs, since it it is relevant to many WGs. So we would like to propose the formation of a mini-WG in the RAI area to develop this document. A charter is below; I will ask the DISPATCH chairs to call for consensus at the meeting tomorrow. Thanks, --Richard ----- BEGIN Charter ----- DART - DSCP Applied to RTP Transports DIffServ code points (DSCP) can be used in some situations to provide quality of service (QoS). Packets with different marketings can be reordered, which can cause poor interaction with a transport that is responsive to reordering. When RTP streams or other real-time media (sub-)flows are used with different DSCP values with the same transport 5-tuple, there are interactions with the transports. There are also environments where the DSCP markings are removed or remarked. This WG will write a document that explains the limitations that exist with DSCP when used with RTP in general as well in the specific RTCWeb cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCORE, MMUSIC, CLUE, and RTCWEB. Aug 2014 - Send Information draft to IESG on DSCP usage consideration ----- END Charter ----- --001a11c3367655216104f3a3f954 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear DISPATCH,

The RAI and TSV ADs and = several WG chairs have been discussing how to address several transport con= cerns arising from draft-ietf-rtcweb-transport and=A0draft-dhesikan-tsvwg-r= tcweb-qos (n=E9e draft-ietf-rtcweb-qos). =A0One thing that emerged from tha= t discussion is the need for a document to describe certain realities regar= ding DiffServ and (possibly) multiplexed flows. =A0Unforunately, such a doc= ument does not fall within the charters of current RAI WGs, since it it is = relevant to many WGs.

So we would like to propose the formation of a mini-WG = in the RAI area to develop this document. =A0A charter is below; I will ask= the DISPATCH chairs to call for consensus at the meeting tomorrow. =A0

Thanks,
--Richard

----- BEGIN Charter -----
DART - DSCP Applied to RTP Transports

D= IffServ code points (DSCP) can be used in some situations to provide qualit= y of service (QoS). Packets with different marketings can be reordered, whi= ch can cause poor interaction with a transport that is responsive to reorde= ring. When RTP streams or other real-time media =A0(sub-)flows are used wit= h different DSCP values with the same transport 5-tuple, there are interact= ions with the transports. There are also environments where the DSCP markin= gs are removed or remarked.

T= his WG will write a document that explains the limitations that exist with = DSCP when used with RTP in general as well in the specific RTCWeb cases. Th= e WG will coordinate with relevant WGs, including TSVWG, AVTCORE, MMUSIC, C= LUE, and RTCWEB.

A= ug 2014 - Send Information draft to IESG on DSCP usage consideration=
----- END Charter -----
--001a11c3367655216104f3a3f954-- From nobody Sun Mar 2 19:10:59 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90CC1A0C40 for ; Sun, 2 Mar 2014 19:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHLibuqixuc0 for ; Sun, 2 Mar 2014 19:10:55 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id EAED61A0C1E for ; Sun, 2 Mar 2014 19:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4779; q=dns/txt; s=iport; t=1393816252; x=1395025852; h=message-id:date:to:from:subject:in-reply-to:references: mime-version:content-transfer-encoding; bh=EoQ4gbNs7ZtCcd8UfnDjdBDSem6SJgTCJDjyNY5Cpvc=; b=G0FidybN/DnSHdKG1eG1CIGk+bNFG3IoCKQxPvLAjB1TZrSVi9rFtneB JOFFAshyRjIlAOeKUHP1ybmBOjzjbylh7/bnJyXdd9PRVItq+QarXgppG NQnwkuh91JzfR/ukawTO39v9GLRYS9FhrEGO4+BD2wzXUs94uqiixThiz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAEnyE1OtJXHB/2dsb2JhbABZgwY7wFVPgRsWdIIlAQEBBAEBARobNhsHBA4KCSUPCg4wBgESh3kNzAMTBI5ghDgEiRM4iwaWFoFvgV0d X-IronPort-AV: E=Sophos;i="4.97,575,1389744000"; d="scan'208";a="24394195" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 03 Mar 2014 03:10:51 +0000 Received: from jmpolk-WS.cisco.com (rcdn-vpn-client-10-89-3-223.cisco.com [10.89.3.223]) (authenticated bits=0) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s233An4J031157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2014 03:10:50 GMT Message-Id: <201403030310.s233An4J031157@rcdn-core2-6.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Mar 2014 21:10:47 -0600 To: Richard Barnes , DISPATCH From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-User: jmpolk Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/WBL22fw6Cg0PwMyiB9IN7pTLZZU Subject: Re: [dispatch] Proposed mini-WG: DiffServ considerations for real-time communications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 03:10:58 -0000 At 12:38 PM 3/2/2014, Richard Barnes wrote: >Dear DISPATCH, > >The RAI and TSV ADs and several WG chairs have=20 >been discussing how to address several transport=20 >concerns arising from=20 >draft-ietf-rtcweb-transport and=20 >draft-dhesikan-tsvwg-rtcweb-qos (n=E9e=20 >draft-ietf-rtcweb-qos). One thing that emerged=20 >from that discussion is the need for a document=20 >to describe certain realities regarding DiffServ=20 >and (possibly) multiplexed flows. Unforunately,=20 >such a document does not fall within the=20 >charters of current RAI WGs, since it it is relevant to many WGs. > >So we would like to propose the formation of a=20 >mini-WG in the RAI area to develop this=20 >document. A charter is below; I will ask the=20 >DISPATCH chairs to call for consensus at the meeting tomorrow. > >Thanks, >--Richard > I couldn't help myself (I know how much you love=20 it when I do that), but there are too many=20 inaccuracies in the short (draft) charter below. I offer (boldly, because you didn't ask for it)=20 what I think is a better version of a draft,=20 incorporating your text and ideas. I realize its=20 length is nearly half the size of the ID this WG produces. ;-) ----- BEGIN Charter ----- DART - DSCP Applied to RTP Transports Various transport protocols exist today for=20 various reasons; mostly because there was a need=20 for a behavior that the IP layer just could not=20 provide, or a behavior that another transport=20 protocol didn't have (at the time, in some=20 cases). For example, both a type of congestion=20 control and an ability to reorder at the receiver=20 out of order packets necessitated the need for=20 the development of a transport layer to handle=20 both capabilities better. The result was TCP.=20 There are now multiple transport protocols (i.e.,=20 TCP, UDP, SCTP, etc.) that have various=20 behaviors. These behaviors are not the same=20 depending on the network circumstance a/each=20 packet finds itself in as it traverses through the network. With the IP layer, and not part of the 5-tuple=20 identifier, DiffServ code points (DSCP) can be=20 used in situations to provide quality of service=20 (QoS), but in fact it is a class of service (COS)=20 differentiation they provide. These 64 different=20 values are found within the old TOS byte. There=20 is nothing in the DSCP field but zeros most of=20 the time (i.e., Best Effort). As specified within=20 RFC 2474 and 2475 is called a per hop behavior=20 (PHB). Hence most packets receive a best effort=20 PHB. An important aspect of a PHB is that it is=20 just that, and a packet, and indirectly its user,=20 needs to be prepared to have its DSCP remarked to=20 another value one or more times, or any time it traverses a layer node. With the desire to now explore other than best=20 effort DSCP markings of RTP streams or other=20 real-time media (sub-)flows, certain realities,=20 say for example reordering of packets within a=20 stream or flow, not all transport protocols=20 behave the same. Some will have their DSCP of a=20 non-zero value set to zero by some router before=20 the destination, or another non-zero value that=20 is different from the packet that it was originally set to. This WG will write a document that explains the=20 limitations that exist with DSCP when used with=20 RTP in general as well in the specific RTCWeb=20 cases. The WG will coordinate with relevant WGs,=20 including TSVWG (Diffserv's home WG), AVTCORE, MMUSIC, CLUE, and RTCWEB. Aug 2014 - Send Information draft to IESG on DSCP usage consideration ----- END Charter ----- >----- BEGIN Charter ----- >DART - DSCP Applied to RTP Transports > >DIffServ code points (DSCP) can be used in some=20 >situations to provide quality of service (QoS).=20 >Packets with different marketings can be=20 >reordered, which can cause poor interaction with=20 >a transport that is responsive to reordering.=20 >When RTP streams or other real-time=20 >media (sub-)flows are used with different DSCP=20 >values with the same transport 5-tuple, there=20 >are interactions with the transports. There are=20 >also environments where the DSCP markings are removed or remarked. > >This WG will write a document that explains the=20 >limitations that exist with DSCP when used with=20 >RTP in general as well in the specific RTCWeb=20 >cases. The WG will coordinate with relevant WGs,=20 >including TSVWG, AVTCORE, MMUSIC, CLUE, and RTCWEB. > >Aug 2014 - Send Information draft to IESG on DSCP usage consideration >----- END Charter ----- >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Mar 2 22:20:23 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8C1A0C06 for ; Sun, 2 Mar 2014 22:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.345 X-Spam-Level: X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOKdeteVqZke for ; Sun, 2 Mar 2014 22:20:15 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 699E41A0B97 for ; Sun, 2 Mar 2014 22:20:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 08F3A7C4F3A for ; Mon, 3 Mar 2014 07:20:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEk3MoUpfFx0 for ; Mon, 3 Mar 2014 07:20:09 +0100 (CET) Received: from [192.168.43.73] (host-95-195-148-135.mobileonline.telia.com [95.195.148.135]) by mork.alvestrand.no (Postfix) with ESMTPSA id 784647C4F16 for ; Mon, 3 Mar 2014 07:20:09 +0100 (CET) Message-ID: <53141F18.9000703@alvestrand.no> Date: Mon, 03 Mar 2014 07:20:08 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------000009050803050908050300" Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/_Sci0HI8yEKtfczkQagLGkHmNuE Subject: Re: [dispatch] Proposed mini-WG: DiffServ considerations for real-time communications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 06:20:19 -0000 This is a multi-part message in MIME format. --------------000009050803050908050300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 03/02/2014 07:38 PM, Richard Barnes wrote: > Dear DISPATCH, > > The RAI and TSV ADs and several WG chairs have been discussing how to > address several transport concerns arising from > draft-ietf-rtcweb-transport and draft-dhesikan-tsvwg-rtcweb-qos (née > draft-ietf-rtcweb-qos). One thing that emerged from that discussion > is the need for a document to describe certain realities regarding > DiffServ and (possibly) multiplexed flows. Unforunately, such a > document does not fall within the charters of current RAI WGs, since > it it is relevant to many WGs. > > So we would like to propose the formation of a mini-WG in the RAI area > to develop this document. A charter is below; I will ask the DISPATCH > chairs to call for consensus at the meeting tomorrow. 1) Will the agenda be updated? 2) Obviously 24 hours from proposal to call for consensus is a bit short; what's the proposed timeframe for the consensus call on the list? 3) Do we need a WG here, or a mailing list + an individual submission? > > Thanks, > --Richard > > > ----- BEGIN Charter ----- > DART - DSCP Applied to RTP Transports > > DIffServ code points (DSCP) can be used in some situations to provide > quality of service (QoS). Packets with different marketings can be > reordered, which can cause poor interaction with a transport that is > responsive to reordering. When RTP streams or other real-time media > (sub-)flows are used with different DSCP values with the same > transport 5-tuple, there are interactions with the transports. There > are also environments where the DSCP markings are removed or remarked. > > This WG will write a document that explains the limitations that exist > with DSCP when used with RTP in general as well in the specific RTCWeb > cases. The WG will coordinate with relevant WGs, including TSVWG, > AVTCORE, MMUSIC, CLUE, and RTCWEB. > > Aug 2014 - Send Information draft to IESG on DSCP usage consideration > ----- END Charter ----- > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Surveillance is pervasive. Go Dark. --------------000009050803050908050300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/02/2014 07:38 PM, Richard Barnes wrote:
Dear DISPATCH,

The RAI and TSV ADs and several WG chairs have been discussing how to address several transport concerns arising from draft-ietf-rtcweb-transport and draft-dhesikan-tsvwg-rtcweb-qos (née draft-ietf-rtcweb-qos).  One thing that emerged from that discussion is the need for a document to describe certain realities regarding DiffServ and (possibly) multiplexed flows.  Unforunately, such a document does not fall within the charters of current RAI WGs, since it it is relevant to many WGs.

So we would like to propose the formation of a mini-WG in the RAI area to develop this document.  A charter is below; I will ask the DISPATCH chairs to call for consensus at the meeting tomorrow. 

1) Will the agenda be updated?

2) Obviously 24 hours from proposal to call for consensus is a bit short; what's the proposed timeframe for the consensus call on the list?

3) Do we need a WG here, or a mailing list + an individual submission?


Thanks,
--Richard


----- BEGIN Charter -----
DART - DSCP Applied to RTP Transports

DIffServ code points (DSCP) can be used in some situations to provide quality of service (QoS). Packets with different marketings can be reordered, which can cause poor interaction with a transport that is responsive to reordering. When RTP streams or other real-time media  (sub-)flows are used with different DSCP values with the same transport 5-tuple, there are interactions with the transports. There are also environments where the DSCP markings are removed or remarked.

This WG will write a document that explains the limitations that exist with DSCP when used with RTP in general as well in the specific RTCWeb cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCORE, MMUSIC, CLUE, and RTCWEB.

Aug 2014 - Send Information draft to IESG on DSCP usage consideration
----- END Charter -----


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



-- 
Surveillance is pervasive. Go Dark.
--------------000009050803050908050300-- From nobody Mon Mar 3 00:12:16 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972C61A0AFC for ; Mon, 3 Mar 2014 00:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR9XVPtUTgiy for ; Mon, 3 Mar 2014 00:12:08 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 193A51A0AC8 for ; Mon, 3 Mar 2014 00:12:06 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id t60so2688819wes.5 for ; Mon, 03 Mar 2014 00:12:03 -0800 (PST) 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=51BYlZgzhN/Rq8fOe3Cdo8LmhhA+vGDKzehtXJ1gsAc=; b=bzR7bN5CT5ekQUHUqJrCqVpWHjXc1PCNkc48X/l6FhYwdCYusvl1XEIgzL/IelRvbp GWbUJR60CVky8oyCmTELl5lcZ4/UFrZa5JNBDAyEFl55cl9lHdzQk3fS3k7tfe9CKdW+ 5L8VHvOcjQVhOswgQG7tqMHClRaGrEmkGPhWNlEQgezTonPQcqd033YQ+O7S0Zm+au69 AxfvO64E3aa2/zMMG6ejWtVTXJ6Q0ks595PYRug4PIUfB8Qk1ltWpMPh72uoiHNlhmud utrDf+2Th72T7X+n4MOlSpQU6X7K2xq9v+2uJydyvRtQAMXRl8HEo2G8Wim3jFdRLVk0 HTvQ== MIME-Version: 1.0 X-Received: by 10.194.192.233 with SMTP id hj9mr3358536wjc.78.1393834323870; Mon, 03 Mar 2014 00:12:03 -0800 (PST) Received: by 10.217.96.195 with HTTP; Mon, 3 Mar 2014 00:12:03 -0800 (PST) In-Reply-To: <53141F18.9000703@alvestrand.no> References: <53141F18.9000703@alvestrand.no> Date: Mon, 3 Mar 2014 02:12:03 -0600 Message-ID: From: Mary Barnes To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7bb70b2ec00ac004f3af576d Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/V1dSFZ3Hqbh6ET9Mr94BDIeqaI4 Cc: DISPATCH Subject: Re: [dispatch] Proposed mini-WG: DiffServ considerations for real-time communications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 08:12:12 -0000 --047d7bb70b2ec00ac004f3af576d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Responses below [MB]. On Mon, Mar 3, 2014 at 12:20 AM, Harald Alvestrand wr= ote: > On 03/02/2014 07:38 PM, Richard Barnes wrote: > > Dear DISPATCH, > > The RAI and TSV ADs and several WG chairs have been discussing how to > address several transport concerns arising from draft-ietf-rtcweb-transpo= rt > and draft-dhesikan-tsvwg-rtcweb-qos (n=E9e draft-ietf-rtcweb-qos). One t= hing > that emerged from that discussion is the need for a document to describe > certain realities regarding DiffServ and (possibly) multiplexed flows. > Unforunately, such a document does not fall within the charters of curre= nt > RAI WGs, since it it is relevant to many WGs. > > So we would like to propose the formation of a mini-WG in the RAI area > to develop this document. A charter is below; I will ask the DISPATCH > chairs to call for consensus at the meeting tomorrow. > > > 1) Will the agenda be updated? > [MB] The plan was to include a slide on this in the charts presented by the chairs which will be uploaded shortly[/MB] > > 2) Obviously 24 hours from proposal to call for consensus is a bit short; > what's the proposed timeframe for the consensus call on the list? > [MB] I agree. I think it's quite reasonable to highlight this in the DISPATCH meeting, but I think that a 2 week call for consensus (and consideration of feedback such as that from James Polk) is reasonable. [/MB] > > 3) Do we need a WG here, or a mailing list + an individual submission? > [MB] The current proposal is a "mini WG" with a narrow scope and shorter, more agrressive timeline than a typical WG. My understanding is that the work was deemed to be of more interest than work items that typically result in an AD sponsored document. [/MB] > > > Thanks, > --Richard > > > ----- BEGIN Charter ----- > DART - DSCP Applied to RTP Transports > > DIffServ code points (DSCP) can be used in some situations to provide > quality of service (QoS). Packets with different marketings can be > reordered, which can cause poor interaction with a transport that is > responsive to reordering. When RTP streams or other real-time media > (sub-)flows are used with different DSCP values with the same transport > 5-tuple, there are interactions with the transports. There are also > environments where the DSCP markings are removed or remarked. > > This WG will write a document that explains the limitations that exist > with DSCP when used with RTP in general as well in the specific RTCWeb > cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCORE= , > MMUSIC, CLUE, and RTCWEB. > > Aug 2014 - Send Information draft to IESG on DSCP usage consideration > ----- END Charter ----- > > > _______________________________________________ > dispatch mailing listdispatch@ietf.orghttps://www.ietf.org/mailman/listin= fo/dispatch > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --047d7bb70b2ec00ac004f3af576d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Responses below [MB].

On Mon, Mar 3, 2014 at 12:20 AM, Harald Alvest= rand <harald@alvestrand.no> wrote:
=20 =20 =20
On 03/02/2014 07:38 PM, Richard Barnes wrote:
Dear DISPATCH,

The RAI and TSV ADs and several WG chairs have been discussing how to address several transport concerns arising from draft-ietf-rtcweb-transport and=A0draft-dhesikan-tsvwg-rtcweb-qos (n=E9e draft-ietf-rtcweb-qos). =A0One thing that emerged from that discussion is the need for a document to describe certain realities regarding DiffServ and (possibly) multiplexed flows. =A0Unforunately, such a document does not fall within the charters of current RAI WGs, since it it is relevant to many WGs.

So we would like to propose the formation of a mini-WG in the RAI area to develop this document. =A0A charter is below; I will ask the DISPATCH chairs to call for consensus at the meeting tomorrow.=A0

1) Will the agenda be updated?
[MB] The plan= was to include a slide on this in the charts presented by the chairs which= will be uploaded shortly[/MB]

2) Obviously 24 hours from proposal to call for consensus is a bit short; what's the proposed timeframe for the consensus call on the list?
[MB] =A0I agree. I think it's quit= e reasonable to highlight this in the DISPATCH meeting, but I think that a = 2 week call for consensus (and consideration of feedback such as that from = James Polk) is reasonable. [/MB]=A0

3) Do we need a WG here, or a mailing list + an individual submission?
[MB] The current proposal is a &= quot;mini WG" with a narrow scope and shorter, more agrressive timelin= e than a typical WG. =A0 My understanding is that the work was deemed to be= of more interest than work items that typically result in an AD sponsored = document. [/MB]


Thanks,
--Richard


----- BEGIN Charter -----
DART - DSCP Applied to RTP Transports

DIffServ code points (DSCP) can be used in some situations to provide quality of service (QoS). Packets with different marketings can be reordered, which can cause poor interaction with a transport that is responsive to reordering. When RTP streams or other real-time media =A0(sub-)flows are used with different DSCP values with the same transport 5-tuple, there are interactions with the transports. There are also environments where the DSCP markings are removed or remarked.

This WG will write a document that explains the limitations that exist with DSCP when used with RTP in general as well in the specific RTCWeb cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCORE, MMUSIC, CLUE, and RTCWEB.

Aug 2014 - Send Information draft to IESG on DSCP usage consideration
----- END Charter -----


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--=20
Surveillance is pervasive. Go Dark.

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--047d7bb70b2ec00ac004f3af576d-- From nobody Mon Mar 3 02:37:57 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EE01A0E91 for ; Mon, 3 Mar 2014 02:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzL267eLCYiW for ; Mon, 3 Mar 2014 02:37:53 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id A2D581A0E7C for ; Mon, 3 Mar 2014 02:37:53 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id uz6so6689008obc.27 for ; Mon, 03 Mar 2014 02:37:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wEyJ4Vi8F3meN+9kAgiVq88xSHwt1rCsHjnMoBimLSA=; b=Gam0B6pJmbnW2h+aAY03gmnwwGhz/XHaIB2LUubV0eYlg9aVm7UhrVUlWJvJkOfo54 7k/tJnj/i7qabwrnqNyL6Dxyv+QofFSzJN23f+tWKDJrZvYPCnkfgmskJOnxgeKsKkZt p38eL9+Db7DZldoU9yPeNDW4mdI0vONVe4/tvYgn8mY71noRnlp+0yc7SpxNAWoBOk4h CJs6/jBnEj/qiUr7nfCtNMQ2hwz9HGQZJHLvzUHyePf/km2TlAaSGPXKEcrk7P4QAuuV aCy7yQt/Uj79sPakUg8X24hrPGdt/i0Xt/k+hBT/pSa5ugWChHvzz0/8RcmW0n0tvUQL 6Cqg== X-Gm-Message-State: ALoCoQlWFzkspnsdoKCjqW8l74iR2TDaNt6yRMNqrlcTIUJEDcEVZTnUm2seW2cMK60h5ES/3Ewm MIME-Version: 1.0 X-Received: by 10.60.51.6 with SMTP id g6mr15715047oeo.5.1393843070805; Mon, 03 Mar 2014 02:37:50 -0800 (PST) Received: by 10.60.69.102 with HTTP; Mon, 3 Mar 2014 02:37:50 -0800 (PST) In-Reply-To: References: <53141F18.9000703@alvestrand.no> Date: Mon, 3 Mar 2014 10:37:50 +0000 Message-ID: From: Richard Barnes To: Mary Barnes Content-Type: multipart/alternative; boundary=001a11c306f01bc1b704f3b16174 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/E78baE1oc9CmgqQ3OTZowNWmcW0 Cc: Harald Alvestrand , DISPATCH Subject: Re: [dispatch] Proposed mini-WG: DiffServ considerations for real-time communications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:37:56 -0000 --001a11c306f01bc1b704f3b16174 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 3, 2014 at 8:12 AM, Mary Barnes wro= te: > Responses below [MB]. > > > On Mon, Mar 3, 2014 at 12:20 AM, Harald Alvestrand = wrote: > >> On 03/02/2014 07:38 PM, Richard Barnes wrote: >> >> Dear DISPATCH, >> >> The RAI and TSV ADs and several WG chairs have been discussing how to >> address several transport concerns arising from draft-ietf-rtcweb-transp= ort >> and draft-dhesikan-tsvwg-rtcweb-qos (n=E9e draft-ietf-rtcweb-qos). One = thing >> that emerged from that discussion is the need for a document to describe >> certain realities regarding DiffServ and (possibly) multiplexed flows. >> Unforunately, such a document does not fall within the charters of curr= ent >> RAI WGs, since it it is relevant to many WGs. >> >> So we would like to propose the formation of a mini-WG in the RAI area >> to develop this document. A charter is below; I will ask the DISPATCH >> chairs to call for consensus at the meeting tomorrow. >> >> >> 1) Will the agenda be updated? >> > [MB] The plan was to include a slide on this in the charts presented by > the chairs which will be uploaded shortly[/MB] > >> >> 2) Obviously 24 hours from proposal to call for consensus is a bit short= ; >> what's the proposed timeframe for the consensus call on the list? >> > [MB] I agree. I think it's quite reasonable to highlight this in the > DISPATCH meeting, but I think that a 2 week call for consensus (and > consideration of feedback such as that from James Polk) is reasonable. > [/MB] > >> >> 3) Do we need a WG here, or a mailing list + an individual submission? >> > [MB] The current proposal is a "mini WG" with a narrow scope and shorter, > more agrressive timeline than a typical WG. My understanding is that th= e > work was deemed to be of more interest than work items that typically > result in an AD sponsored document. [/MB] > Some of the ADs involved in the discussion felt it was important to have a WG as a focus for discussion on this draft, since it does have impacts on several WGs in at least two areas. However, as Mary notes, the hope here is to have the timeline be not much longer than an AD-sponsored draft would= . --Richard > >> >> Thanks, >> --Richard >> >> >> ----- BEGIN Charter ----- >> DART - DSCP Applied to RTP Transports >> >> DIffServ code points (DSCP) can be used in some situations to provide >> quality of service (QoS). Packets with different marketings can be >> reordered, which can cause poor interaction with a transport that is >> responsive to reordering. When RTP streams or other real-time media >> (sub-)flows are used with different DSCP values with the same transport >> 5-tuple, there are interactions with the transports. There are also >> environments where the DSCP markings are removed or remarked. >> >> This WG will write a document that explains the limitations that exist >> with DSCP when used with RTP in general as well in the specific RTCWeb >> cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCOR= E, >> MMUSIC, CLUE, and RTCWEB. >> >> Aug 2014 - Send Information draft to IESG on DSCP usage consideration >> ----- END Charter ----- >> >> >> _______________________________________________ >> dispatch mailing listdispatch@ietf.orghttps://www.ietf.org/mailman/listi= nfo/dispatch >> >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> 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 > > --001a11c306f01bc1b704f3b16174 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 3, 2014 at 8:12 AM, Mary Barnes <<= a href=3D"mailto:mary.ietf.barnes@gmail.com" target=3D"_blank">mary.ietf.ba= rnes@gmail.com> wrote:
Responses below [MB].


On Mon, Mar 3, 2014 at 12:20 AM, Harald Alvestrand <<= a href=3D"mailto:harald@alvestrand.no" target=3D"_blank">harald@alvestrand.= no> wrote:
=20 =20 =20
On 03/02/2014 07:38 PM, Richard Barnes wrote:
Dear DISPATCH,

The RAI and TSV ADs and several WG chairs have been discussing how to address several transport concerns arising from draft-ietf-rtcweb-transport and=A0draft-dhesikan-tsvwg-rtcweb-qos (n=E9e draft-ietf-rtcweb-qos). =A0One thing that emerged from that discussion is the need for a document to describe certain realities regarding DiffServ and (possibly) multiplexed flows. =A0Unforunately, such a document does not fall within the charters of current RAI WGs, since it it is relevant to many WGs.

So we would like to propose the formation of a mini-WG in the RAI area to develop this document. =A0A charter is below; I will ask the DISPATCH chairs to call for consensus at the meeting tomorrow.=A0

1) Will the agenda be updated?
[MB] Th= e plan was to include a slide on this in the charts presented by the chairs= which will be uploaded shortly[/MB]

2) Obviously 24 hours from proposal to call for consensus is a bit short; what's the proposed timeframe for the consensus call on the list?
[MB] =A0I agree. I think it'= s quite reasonable to highlight this in the DISPATCH meeting, but I think t= hat a 2 week call for consensus (and consideration of feedback such as that= from James Polk) is reasonable. [/MB]=A0

3) Do we need a WG here, or a mailing list + an individual submission?
[MB] The current proposal = is a "mini WG" with a narrow scope and shorter, more agrressive t= imeline than a typical WG. =A0 My understanding is that the work was deemed= to be of more interest than work items that typically result in an AD spon= sored document. [/MB]

Some of the ADs involved= in the discussion felt it was important to have a WG as a focus for discus= sion on this draft, since it does have impacts on several WGs in at least t= wo areas. =A0However, as Mary notes, the hope here is to have the timeline = be not much longer than an AD-sponsored draft would.

--Richard


=A0


Thanks,
--Richard


----- BEGIN Charter -----
DART - DSCP Applied to RTP Transports

DIffServ code points (DSCP) can be used in some situations to provide quality of service (QoS). Packets with different marketings can be reordered, which can cause poor interaction with a transport that is responsive to reordering. When RTP streams or other real-time media =A0(sub-)flows are used with different DSCP values with the same transport 5-tuple, there are interactions with the transports. There are also environments where the DSCP markings are removed or remarked.

This WG will write a document that explains the limitations that exist with DSCP when used with RTP in general as well in the specific RTCWeb cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCORE, MMUSIC, CLUE, and RTCWEB.

Aug 2014 - Send Information draft to IESG on DSCP usage consideration
----- END Charter -----


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--=20
Surveillance is pervasive. Go Dark.

_______________________________________________
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


--001a11c306f01bc1b704f3b16174-- From nobody Tue Mar 4 01:23:12 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2384E1A044C for ; Tue, 4 Mar 2014 01:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcPGqYF-02tH for ; Tue, 4 Mar 2014 01:23:08 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 49A661A0431 for ; Tue, 4 Mar 2014 01:23:08 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id p61so3374209wes.25 for ; Tue, 04 Mar 2014 01:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wxKtwXJdcjwr5zYL3smOl//KvcJ9vN0R09bFT21qOPU=; b=GrQmd9+lEjoCGMheUfIv8J6rcV/arEHiEqJgP/OJ6cmNRSqOgR9nHTfLBPDjfE3bw/ 7GPge74YWo1wV7I7JGGLFlIiwPB+wmbfkGdCQX1OSJQtVQS2ODCkIk5MNaYFFw+ar/3T /WchXG+90IJotv6WqW/mmeW8NYI+yrwMdOLK0K2xsoIJpswu7le46OWX1rFVH1Mj+GkP QTwWwWi8MSZxrNnZ84R4s7CVoWa9VTsvcz+2VN82pS1DvD2q/xD4dwlntHxokOxRI9JE 2hVPohqeLBRKid6xq/N9xg4VutJnT9310I4G8yeYXzWSC9D5pVH+xLMAMTpBo1KjnNYD YvWA== MIME-Version: 1.0 X-Received: by 10.194.134.132 with SMTP id pk4mr13424002wjb.82.1393924984733; Tue, 04 Mar 2014 01:23:04 -0800 (PST) Received: by 10.217.96.195 with HTTP; Tue, 4 Mar 2014 01:23:04 -0800 (PST) Date: Tue, 4 Mar 2014 03:23:04 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=089e01227f448f063304f3c473ed Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/aqxabxXGpMk3vpvpIxBNYo_PmAw Subject: [dispatch] Updated DART charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:23:10 -0000 --089e01227f448f063304f3c473ed Content-Type: text/plain; charset=ISO-8859-1 Note, the DART charter has been updated in the datatracker: https://datatracker.ietf.org/doc/charter-ietf-dart/ Any final concerns or suggestions should be raised now. Mary. DISPATCH WG co-chair --089e01227f448f063304f3c473ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Note, the DART charter has been updated in the datatracker= :

=
Any final concerns or suggestions should be raised now.

Mary.=A0
DISPATCH WG co-chair
--089e01227f448f063304f3c473ed-- From nobody Tue Mar 4 03:11:17 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DF41A02F9 for ; Tue, 4 Mar 2014 03:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEElMZ1P6ttZ for ; Tue, 4 Mar 2014 03:11:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 467351A029F for ; Tue, 4 Mar 2014 03:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=959; q=dns/txt; s=iport; t=1393931470; x=1395141070; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=V2uCusIqynHzF1V015GfCMK3VCb9y8wHYe2+95uyiuE=; b=i2USNZZ18TERO7y+RjcuZLJRA1o+HtZEpek5YFf0aOd0Ptc5lIInPJm1 CHvxXHpCMKsDT+PHWuxsYIuPlTOdF8jEGYQmYnwteLlHCq1q/9X7iumD9 azKvzyRbH+be4iroOqX4CPEtPx14HSab+uLBGT6kVp0Qw4t1c8yGsAwlB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAI20FVOtJV2a/2dsb2JhbABagwY7wHVPgSAWdIIlAQEBBAEBATUCNAsQBwQYCRUQDwoOMAYTh3kNzDETBI5RB4Q4BIlLoRyDTB0 X-IronPort-AV: E=Sophos;i="4.97,584,1389744000"; d="scan'208";a="307869456" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 04 Mar 2014 11:11:10 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn4-1852.cisco.com [10.82.215.60]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s24BB7hj017295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2014 11:11:08 GMT Message-Id: <201403041111.s24BB7hj017295@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Mar 2014 05:11:06 -0600 To: DISPATCH From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/wZ8T7L7lThA1fANZKA6W1zphyK0 Subject: Re: [dispatch] Updated DART charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:11:15 -0000 What I wrote yesterday (with my version of an alternate charter text for DART) clearly was for a different audience, and I apologize for that. That said, as a TSVWG chair (where Diffserv lives and is extended), I still have heartburn with the first sentence describing Diffserv as anything other than providing a classifier of traffic (CoS), and not performing any form of quality of service (QoS) (cuz it doesn't do that, and that might be one of a few points of DART's deliverable). James At 03:23 AM 3/4/2014, Mary Barnes wrote: >Note, the DART charter has been updated in the datatracker: >https://datatracker.ietf.org/doc/charter-ietf-dart/ > >Any final concerns or suggestions should be raised now. > >Mary. >DISPATCH WG co-chair >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Mar 4 07:23:02 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176B01A014D for ; Tue, 4 Mar 2014 07:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1Gwl_kdPoPw for ; Tue, 4 Mar 2014 07:22:53 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 306CB1A005E for ; Tue, 4 Mar 2014 07:22:52 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s24FMlRA004803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2014 10:22:48 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s24FMlRA004803 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1393946568; bh=nWkTZ68y2I8QW6gabhAf8pAD7RM=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rPbSSAw5M9og6gboM6ByQzWNT89hW4DURT1rK56q7j6eEQ4cGAIW9Z5yeDpU2sR5G 1xvWzSgQZYQrnBEl3HmFTb8V30qeaGTwQp1MUkWAusu38btGy0+vfCRNM/pmAm+HQb sS5D3jY4p1zHgEUZyi57oxbJ0LQW+2If06hBI+1M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s24FMlRA004803 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd53.lss.emc.com (RSA Interceptor); Tue, 4 Mar 2014 10:22:34 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s24FMXmb028323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 10:22:34 -0500 Received: from mx15a.corp.emc.com ([169.254.1.223]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Tue, 4 Mar 2014 10:22:33 -0500 From: "Black, David" To: James Polk , DISPATCH Date: Tue, 4 Mar 2014 10:22:32 -0500 Thread-Topic: [dispatch] Updated DART charter Thread-Index: Ac83mnc2kUXmznONQgCJoz5e0XJvlwAIowEQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71206CF438C54@MX15A.corp.emc.com> References: <201403041111.s24BB7hj017295@rcdn-core-3.cisco.com> In-Reply-To: <201403041111.s24BB7hj017295@rcdn-core-3.cisco.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 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/WTbeImpj25BUrT3tKDAbVoalGks Subject: Re: [dispatch] Updated DART charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:22:57 -0000 > That said, as a TSVWG chair (where Diffserv lives and is extended), I > still have heartburn with the first sentence describing Diffserv as > anything other than providing a classifier of traffic (CoS), and not > performing any form of quality of service (QoS) (cuz it doesn't do > that, and that might be one of a few points of DART's deliverable). Well, that's one of the reasons why I wanted both "DiffServ" and "DSCP" used in the charter: - The DSCPs are used for traffic classification. - DiffServ is broader, and does provide QoS in a full implementation, see RFC 2475, starting with Section 2.3. Thanks, --David > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of James Polk > Sent: Tuesday, March 04, 2014 6:11 AM > To: DISPATCH > Subject: Re: [dispatch] Updated DART charter >=20 > What I wrote yesterday (with my version of an alternate charter text > for DART) clearly was for a different audience, and I apologize for that. >=20 > That said, as a TSVWG chair (where Diffserv lives and is extended), I > still have hearturn with the first sentence describing Diffserv as > anything other than providing a classifier of traffic (CoS), and not > performing any form of quality of service (QoS) (cuz it doesn't do > that, and that might be one of a few points of DART's deliverable). >=20 > James >=20 > At 03:23 AM 3/4/2014, Mary Barnes wrote: > >Note, the DART charter has been updated in the datatracker: > > dart/>https://datatracker.ietf.org/doc/charter-ietf-dart/ > > > >Any final concerns or suggestions should be raised now. > > > >Mary. > >DISPATCH WG co-chair > >_______________________________________________ > >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 nobody Wed Mar 5 07:23:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F171A06FC for ; Wed, 5 Mar 2014 07:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNQWJPfeEBzH for ; Wed, 5 Mar 2014 07:23:43 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 686411A06F2 for ; Wed, 5 Mar 2014 07:23:43 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so1167502iec.37 for ; Wed, 05 Mar 2014 07:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uCSaa7oyZ85dGwpKInVdS4vvAF7+cW6YacPVifzmVOE=; b=TCcAO7sMSmy5F9GqxjzuEwnSX4X16Hmps4IQrBOslAPr/EzbWnyMpL6oef5zPmW3y1 F8SRpsud87GJh02TP5K/YNlPCIfE6heHVuenZDimFhTJuyccHd7Y2jcgUo5Ha1n50aVM SRmocsK/Jk+TNhjzWVT3HEuDq1AbABXc+gDKLGOwXKbJz5JMezVTK1snsezQJbr6fHOl UAgXuRwIn8WLJkJ7yotuOzg7AHJYjJL5Ge4m5bNTVOUfjQ08WeCRwC8SuMIkcMYR0Fq3 io67Xn3jozOcuaC+8nstsmwhmlowxEOqFUdiH/yZ7bXqe1HjYdGIjLVbeYjRBXpPBWwe ycHQ== X-Received: by 10.50.40.37 with SMTP id u5mr9674928igk.30.1394033019274; Wed, 05 Mar 2014 07:23:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.225.98 with HTTP; Wed, 5 Mar 2014 07:23:19 -0800 (PST) In-Reply-To: References: From: Varun Singh Date: Wed, 5 Mar 2014 15:23:19 +0000 Message-ID: To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/DQ2B0OrW2ThMGxVWthM5RCofSzo Cc: DISPATCH Subject: Re: [dispatch] Updated DART charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:23:45 -0000 On Tue, Mar 4, 2014 at 9:23 AM, Mary Barnes wrote: > Note, the DART charter has been updated in the datatracker: > https://datatracker.ietf.org/doc/charter-ietf-dart/ > > Any final concerns or suggestions should be raised now. > I'd like to suggest a minor comment, the charter should include co-ordination with RMCAT as well. > Mary. > DISPATCH WG co-chair > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- http://www.netlab.tkk.fi/~varun/ From nobody Thu Mar 6 01:35:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22671A01C6 for ; Thu, 6 Mar 2014 01:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8Ihk1m8sdwE for ; Thu, 6 Mar 2014 01:35:43 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D921A01C4 for ; Thu, 6 Mar 2014 01:35:42 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s269ZR49073186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Mar 2014 03:35:29 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: Date: Thu, 6 Mar 2014 09:35:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <253BD242-4A69-455B-8B2C-D4CD3D64B163@nostrum.com> References: To: Mary Barnes X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/U7KPrPXIUaFuy4un1Mw9p68r5S4 Cc: DISPATCH Subject: Re: [dispatch] Updated DART charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:35:45 -0000 Minor nit suggestion: Change "responsive to reordering" to "sensitive to reordering". = "Responsive" sounds too much like a good thing. Old:=20 Packets with different markings can be reordered, which can cause poor = interaction with a transport protocol that is responsive to reordering. New: Packets with different markings can be reordered, which can cause poor = interaction with a transport protocol that is _sensitive_ to reordering. On Mar 4, 2014, at 9:23 AM, Mary Barnes = wrote: > Note, the DART charter has been updated in the datatracker: > https://datatracker.ietf.org/doc/charter-ietf-dart/ >=20 > Any final concerns or suggestions should be raised now. >=20 > Mary.=20 > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 6 01:54:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ECF1A019A for ; Thu, 6 Mar 2014 01:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE_gKnkJ4qL0 for ; Thu, 6 Mar 2014 01:54:28 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id A69B91A01B7 for ; Thu, 6 Mar 2014 01:54:27 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s269sKfD000616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2014 04:54:21 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s269sKfD000616 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394099661; bh=2s0Xz+rYneNoI1P0vDNvYs6/wGU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=HGoJjKk2N4SwXI0YIZ2BdFQ49EIjUP/v+JZOF3HE5FyaPLhCnQl/R9j+fAwze3n35 o3Mgl5y/xGaPP5YigBSV5ohO7OBGME2HX/w2CLs8IrBsowW+0CJB7z8IofajL7w5T6 A36R57qhDMIZmpfDPzFw9GuLve8jGdNhiYPry9bc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s269sKfD000616 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 6 Mar 2014 01:54:07 -0800 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s269s6wT023052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 04:54:07 -0500 Received: from mx15a.corp.emc.com ([169.254.1.223]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Thu, 6 Mar 2014 04:54:06 -0500 From: "Black, David" To: Ben Campbell , Mary Barnes Date: Thu, 6 Mar 2014 04:54:05 -0500 Thread-Topic: [dispatch] Updated DART charter Thread-Index: Ac85H4jputZxIGQpSqq6IDSpWoXvTwAAnUww Message-ID: <8D3D17ACE214DC429325B2B98F3AE71206CF43900E@MX15A.corp.emc.com> References: <253BD242-4A69-455B-8B2C-D4CD3D64B163@nostrum.com> In-Reply-To: <253BD242-4A69-455B-8B2C-D4CD3D64B163@nostrum.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 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Y1NFpGd_4qfPaeOCkkjsSoot-HE Cc: DISPATCH Subject: Re: [dispatch] Updated DART charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:54:31 -0000 +1, --David > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbe= ll > Sent: Thursday, March 06, 2014 4:35 AM > To: Mary Barnes > Cc: DISPATCH > Subject: Re: [dispatch] Updated DART charter >=20 > Minor nit suggestion: >=20 > Change "responsive to reordering" to "sensitive to reordering". "Responsi= ve" > sounds too much like a good thing. >=20 > Old: >=20 > Packets with different markings can be reordered, which can cause poor > interaction with a transport protocol that is responsive to reordering. >=20 > New: >=20 > Packets with different markings can be reordered, which can cause poor > interaction with a transport protocol that is _sensitive_ to reordering. >=20 >=20 > On Mar 4, 2014, at 9:23 AM, Mary Barnes wrot= e: >=20 > > Note, the DART charter has been updated in the datatracker: > > https://datatracker.ietf.org/doc/charter-ietf-dart/ > > > > Any final concerns or suggestions should be raised now. > > > > Mary. > > DISPATCH WG co-chair > > _______________________________________________ > > 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 nobody Wed Mar 12 11:20:49 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F931A0736; Wed, 12 Mar 2014 11:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrIoZy7Trrbz; Wed, 12 Mar 2014 11:20:41 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id D73631A058E; Wed, 12 Mar 2014 11:20:40 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Mar 2014 14:20:19 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 14:20:18 -0400 From: Andrew Allen To: "dispatch@ietf.org" , "straw@ietf.org" , "SIPCORE (sipcore@ietf.org)" Thread-Topic: draft-allen-dispatch-routing-out-of-dialog-request-00 posted Thread-Index: Ac89dJaprbnFDofWSDGBbfkVqnqeng== Date: Wed, 12 Mar 2014 18:20:18 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23398A1743XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/rzvafrSVxB8PEGRRbx-tvwNG2bg Subject: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-00 posted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:20:43 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD23398A1743XMB122CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted a draft that discusses the problem posed by B2BUA intermed= iaries for out of dialog requests that are related to another dialog and id= entifies some possible solutions. It can be found at: http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-request-0= 0.txt I would like to receive comments on this and a view as to where such work s= hould be dispatched to. Andrew --_000_BBF5DDFE515C3946BC18D733B20DAD23398A1743XMB122CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have submitted a draft that discusses the problem = posed by B2BUA intermediaries for out of dialog requests that are related t= o another dialog and identifies some possible solutions.

 

It can be found at:

 

http://www.ietf.org/id/draft-allen= -dispatch-routing-out-of-dialog-request-00.txt

 

 

I would like to receive comments on this and a view = as to where such work should be dispatched to.

 

Andrew

--_000_BBF5DDFE515C3946BC18D733B20DAD23398A1743XMB122CNCrimnet_-- From nobody Wed Mar 12 11:38:23 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9521A0778; Wed, 12 Mar 2014 11:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyXOy5omoYE3; Wed, 12 Mar 2014 11:38:16 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB331A0755; Wed, 12 Mar 2014 11:38:15 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so5558916wgh.17 for ; Wed, 12 Mar 2014 11:38:09 -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=E02OeViH9tIzJP2EswZ8QbzRiMRCnc+X90sBcBUu6V0=; b=o2eESwK0cMo+WI8Bv01YuQ7qtKQWU8ArvLT3kKgZba/flSddvwIUtnV0MkQ25kCMLi UDBCcpgxZ5ireH1k/WR92My22ttTkvPeBVxTjEc7T+9Hx1iAqYmtqQiLhwIEIDM06/ba zcL/+0jf3od9yS6Ap1tA36oPgGOJC//Cb/2G8YQCtOovyXaJDZUQztJvskzZl8EogVdc W9Zyjg6f2TI9Cx+1lkRor8DoNi/5LFLRDMZkGDvpcbGx+vsHnshwXFFrK5GgrLUMbTJT q8BY1gfOeWvesQ+M3bgVZHsbhC8iMF3ACdkqxF1Srx60Qt1t0NaeNYraB7eggonnZpDF QELQ== MIME-Version: 1.0 X-Received: by 10.194.21.193 with SMTP id x1mr42129046wje.33.1394649489363; Wed, 12 Mar 2014 11:38:09 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Wed, 12 Mar 2014 11:38:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 13:38:09 -0500 Message-ID: From: Mary Barnes To: Andrew Allen Content-Type: multipart/alternative; boundary=047d7b5d561066586f04f46d23eb Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/hedxq4DNku3XvKWmfv2M67-Dbjk Cc: "dispatch@ietf.org" , "SIPCORE \(sipcore@ietf.org\)" , "straw@ietf.org" Subject: Re: [dispatch] [sipcore] draft-allen-dispatch-routing-out-of-dialog-request-00 posted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:38:19 -0000 --047d7b5d561066586f04f46d23eb Content-Type: text/plain; charset=ISO-8859-1 Please do NOT crosspost. If you want this document to be considered by the DISPATCH WG process, then please keep the discussion there. Right now, this email is cached with my SIPCORE WG emails since the IETF mailing lists do NOT send duplicate messages. So it's very likely that I will miss any discussion that might be relevant to making a decision in the DISPATCH WG. The right thing to do is to have the discussion on the DISPATCH WG mailing list and send a note to any related WGs that the discussion is underway on the DISPATCH WG mailing list. Thanks, Mary. On Wed, Mar 12, 2014 at 1:20 PM, Andrew Allen wrote: > > > I have submitted a draft that discusses the problem posed by B2BUA > intermediaries for out of dialog requests that are related to another > dialog and identifies some possible solutions. > > > > It can be found at: > > > > > http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-request-00.txt > > > > > > I would like to receive comments on this and a view as to where such work > should be dispatched to. > > > > Andrew > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --047d7b5d561066586f04f46d23eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please do NOT crosspost. =A0If you want this document to b= e considered by the DISPATCH WG process, then please keep the discussion th= ere. =A0Right now, this email is cached with my SIPCORE WG emails since the= IETF mailing lists do NOT send duplicate messages. =A0So it's very lik= ely that I will miss any discussion that might be relevant to making a deci= sion in the DISPATCH WG. =A0The right thing to do is to have the discussion= on the DISPATCH WG mailing list and send a note to any related WGs that th= e discussion is underway on the DISPATCH WG mailing list.

Thanks,
Mary.=A0


On Wed, Mar 12, 2014 at 1:20 PM, An= drew Allen <aallen@blackberry.com> wrote:

=A0

I have submitted a draft that discusses the problem = posed by B2BUA intermediaries for out of dialog requests that are related t= o another dialog and identifies some possible solutions.

=A0

It can be found at:

=A0

http://www.ietf.= org/id/draft-allen-dispatch-routing-out-of-dialog-request-00.txt=

=A0

=A0

I would like to receive comments on this and a view = as to where such work should be dispatched to.

=A0

Andrew


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--047d7b5d561066586f04f46d23eb-- From nobody Wed Mar 12 13:38:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D32A1A0644 for ; Wed, 12 Mar 2014 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mroxiEU5Ojkc for ; Wed, 12 Mar 2014 13:38:43 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 493661A0496 for ; Wed, 12 Mar 2014 13:38:43 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id cjrr1n0030ldTLk55kedn6; Wed, 12 Mar 2014 20:38:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id ckec1n00T3ZTu2S01kecZC; Wed, 12 Mar 2014 20:38:36 +0000 Message-ID: <5320C5CC.7040806@alum.mit.edu> Date: Wed, 12 Mar 2014 16:38:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "dispatch@ietf.org" 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=1394656717; bh=r9Y9eE1lP07elAaRpo8aZaL54Eu+xZwxvq/PwSsvCvg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hFKOunkcv6wMa184CFlmSzv/hHvEVncPFkHvCaUXxS2k1VdX5hDtsLr/rchNKtf+X LKZ7ZOVooTAd30PzdtgKooQeaeSjaCG8rd7/n6Ky/TmpZivmP/DE0fvdsim3VwJGAb uVAXrpLpOZ6tdUwKhVlyozlvXaR01eNPWRBcLaDRqiwGh2Rto1+QwqpfewDBJ8ArCJ WqUE08+mxHDYOEoY6wNhA8A5LnCD3QQPjn1B+RVfQui9FPytfR7DfsC6FgoVdB1jmQ yiTsJSGHUel4jjP9BBp1iH2J/ns9pisMDED5ncueNc1iUmBVQ4yprHFKNnz9Y9snFK esQp0+l/n3log== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/P563vWZqj-CSNmdyjjEV3xdRWWw Subject: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:38:44 -0000 I read this draft as well as the referenced draft draft-kaplan-dispatch-gruu-problematic-00 (which somehow slipped by without my noticing.) I am not very sympathetic. This seems to be a problem that SBC products have made, and it ought to be one that they fix. AFAIK SBC vendors have typically advertised that they "fix" problems in integrating different sip implementations. This is not new. IMS has had B2BUAs and access proxies for a long time. And at one point procedures were included for how they should handle gruus. And in cases where user endpoints are specialized for non-standard environments it is also possible for those endpoints to obtain gruus in some non-standard way, rather than using standard registrar-provided gruus. I'll also note that 3261 *required* that *all* contact addresses be globally routable, and GRUUs were introduced in the first place because that had been widely violated. I don't recall any alternatives to GRUU being proposed at the time. I want to hear a very careful explanation of how attempts have been made to get gruus to work, and how it is impossible to do so. And I want to see a specific, workable, and deployable proposal for an alternative. (And it needs to deal with the issues around dialog sharing.) Thanks, Paul From nobody Wed Mar 12 15:27:27 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3B01A0799 for ; Wed, 12 Mar 2014 15:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY-C-c7sOESB for ; Wed, 12 Mar 2014 15:27:24 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4E51A0796 for ; Wed, 12 Mar 2014 15:27:24 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2CMRGJQ012100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Mar 2014 22:27:17 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2CMRFQQ029783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2014 22:27:16 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2CMRFja029775; Wed, 12 Mar 2014 22:27:15 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Mar 2014 15:27:15 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <5320C5CC.7040806@alum.mit.edu> Date: Wed, 12 Mar 2014 18:27:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5320C5CC.7040806@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/obt9A5oTnc6kQx9qfoQWPsComPQ Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 22:27:26 -0000 On Mar 12, 2014, at 4:38 PM, Paul Kyzivat wrote: > I read this draft as well as the referenced draft = draft-kaplan-dispatch-gruu-problematic-00 (which somehow slipped by = without my noticing.) >=20 > I am not very sympathetic. >=20 > This seems to be a problem that SBC products have made, and it ought = to be one that they fix. AFAIK SBC vendors have typically advertised = that they "fix" problems in integrating different sip implementations. Hmmm... I could be tacky and put this URL here: http://i.imgur.com/nZutGqn.jpg ...but I'll try to be good. Instead I'll just point out that most of = draft-kaplan-dispatch-gruu-problematic-00 is not due to problems caused = by SBCs, or at least not *only* SBCs. (I haven't read Andrew's draft yet though) -hadriel From nobody Wed Mar 12 15:44:10 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFD61A0796 for ; Wed, 12 Mar 2014 15:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3NsDIcnb9gu for ; Wed, 12 Mar 2014 15:44:00 -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 D75D51A0781 for ; Wed, 12 Mar 2014 15:43:59 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta04.westchester.pa.mail.comcast.net with comcast id cmJR1n00427AodY54mjtnS; Wed, 12 Mar 2014 22:43:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id cmjt1n00B3ZTu2S3fmjt0Y; Wed, 12 Mar 2014 22:43:53 +0000 Message-ID: <5320E329.5000209@alum.mit.edu> Date: Wed, 12 Mar 2014 18:43:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <5320C5CC.7040806@alum.mit.edu> 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=1394664233; bh=M8AoR8qc2764v+qRbycGi9YlcsMGcdYMGQeTYKJsO9g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DR4VB9s6nfBEmunum6xyuuqd3fUP8CTH1g/K9oEEU2r8XpKrtP5L7yhWT4d5hQeHZ lOBU83pLcbHSBIK1364kgzfEnbIZVCVDSCSKrR0WWNFA3HWrFZLRHxk21IdmVygfsm PSfZ2dfhhDXYT4cY/LkRZfRpQ0YPhynKRuy1Cn2wcr3zyvdiO0F1ElXo3tctu/J1/y YmIsbj4DBcPGJ5LICWzZNcKioQD9kAhfrdMn65DVRNvKZK+2eW7zas1zEIWunBPG85 EbljqB8UwREY2Z99Pk40eLyQfDOn/I6N88Tu6ZcwK+oixmi2P/E2DW8yT5DVkBkxsj vcrU0tLbPNuMg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/S5QD_IfF30QgOaQuGjkFGJm5XHo Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 22:44:01 -0000 On 3/12/14 6:27 PM, Hadriel Kaplan wrote: > > On Mar 12, 2014, at 4:38 PM, Paul Kyzivat wrote: > >> I read this draft as well as the referenced draft draft-kaplan-dispatch-gruu-problematic-00 (which somehow slipped by without my noticing.) >> >> I am not very sympathetic. >> >> This seems to be a problem that SBC products have made, and it ought to be one that they fix. AFAIK SBC vendors have typically advertised that they "fix" problems in integrating different sip implementations. > > Hmmm... I could be tacky and put this URL here: > > http://i.imgur.com/nZutGqn.jpg > > ...but I'll try to be good. Thanks for being good! > Instead I'll just point out that most of draft-kaplan-dispatch-gruu-problematic-00 is not due to problems caused by SBCs, or at least not *only* SBCs. Then maybe you can resume the role of good guys who fix other people's problems. :-) > (I haven't read Andrew's draft yet though) Go for it. Its short. Here is my problem: SIP was specified on the assumption of global routability of contacts. GRUUs were introduced to give UAs a alternative if they had no other way to get a globally routable contact. We don't have another general alternative. Requiring that UAs assume that magic middle boxes are always deployed that can figure out how to fix everyting doesn't seem a good answer, since we have no definition of such boxes and no way to ensure they are present. IMO it is the responsibility of middle boxes to ensure they don't break things. (Yes, I know that can be hard, since the full set of things they shouldn't break is undefined. But that is what you bite off when you deploy one.) Thanks, Paul From nobody Wed Mar 12 16:38:09 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13971A07B7 for ; Wed, 12 Mar 2014 16:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob2Eh1_RvlMA for ; Wed, 12 Mar 2014 16:38:01 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 806F31A07BC for ; Wed, 12 Mar 2014 16:38:01 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2CNbrDD008400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Mar 2014 23:37:54 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2CNbqWu013353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2014 23:37:53 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2CNbq8h019563; Wed, 12 Mar 2014 23:37:52 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Mar 2014 16:37:52 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <5320E329.5000209@alum.mit.edu> Date: Wed, 12 Mar 2014 19:37:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/6_SfoLAI4pZuwB6OUVxt2REmC9U Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 23:38:07 -0000 On Mar 12, 2014, at 6:43 PM, Paul Kyzivat wrote: >> Instead I'll just point out that most of = draft-kaplan-dispatch-gruu-problematic-00 is not due to problems caused = by SBCs, or at least not *only* SBCs. >=20 > Then maybe you can resume the role of good guys who fix other people's = problems. :-) There is no problem I know of, so long as you do NOT use GRUUs, or = ignore the 'gr' param and just behave like they're normal contact URIs. "Fixing" GRUU isn't really possible - at least not in the sense of (1) = being a GRUU and thus *globally routable*, and also of being able to = give a received GRUU to someone else and have them be able to use it, = anytime, anyplace. It's not solvable because the problem is there is no URI you can create = that is *truly* globally routable, in practice, in most networks. The = reasons why are documented in draft-kaplan-dispatch-gruu-problematic-00. = Many of those reasons ultimately mean there can be no such thing as a = globally-routable/de-referencable URI, for many domains. >> (I haven't read Andrew's draft yet though) >=20 > Go for it. Its short. Done. Yup, short. :) It would be simpler to just use a Contact param that meant "use the = received Record-Route list in this dialog to generate a Route set for a = new out-of-dialog REFER, if you send such a REFER". Or something like = that. Years back we toy'ed with the idea of embedding the Record-Route = headers into the "gruu" contact, to try to make GRUU work, but it grows = way too big. > Here is my problem: SIP was specified on the assumption of global = routability of contacts. GRUUs were introduced to give UAs a alternative = if they had no other way to get a globally routable contact. Why do they need one? What's "broken" that has to be fixed? The only problem I know of is that RFC 6665 demands GRUUs, and IMS has = decided they need 6665 for some reason. There's nothing wrong with 6665 - it just can't be used by many SIP = domains, including IMS ones. It's like writing an RFC and saying "to = implement this RFC you MUST use IPV6". That's cool and all... good luck = with that. > We don't have another general alternative. Requiring that UAs assume = that magic middle boxes are always deployed that can figure out how to = fix everyting doesn't seem a good answer, since we have no definition of = such boxes and no way to ensure they are present. > IMO it is the responsibility of middle boxes to ensure they don't = break things. (Yes, I know that can be hard, since the full set of = things they shouldn't break is undefined. But that is what you bite off = when you deploy one.) It's not only the middleboxes that break it. If you deploy a SIP domain = and don't accept SIP requests from any device anywhere on the Internet = (for both IPv4 and IPv6), then you can't use GRUUs. If you deploy a SIP = domain and won't allow all your proxies or UAs to directly send SIP = requests to any device anywhere on the Internet, then you can't accept = GRUUs. In practice, very few SIP domains accept SIP requests from any random = device on the Internet, or allow all their proxies/UAs to send SIP = requests directly to any random device on the Internet. IMS domains = don't. Most Enterprise domains don't. They're all incompatible with = GRUUs. They just don't realize it. -hadriel From nobody Thu Mar 13 08:01:19 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153901A09FA for ; Thu, 13 Mar 2014 08:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV2TPJzArYhF for ; Thu, 13 Mar 2014 08:01:16 -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 C1AF21A09DC for ; Thu, 13 Mar 2014 08:01:15 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta12.westchester.pa.mail.comcast.net with comcast id d0Bq1n0060mv7h05C319X4; Thu, 13 Mar 2014 15:01:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id d3181n00i3ZTu2S3X318Rl; Thu, 13 Mar 2014 15:01:09 +0000 Message-ID: <5321C834.9000309@alum.mit.edu> Date: Thu, 13 Mar 2014 11:01:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> In-Reply-To: <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.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=1394722869; bh=oAf+IQwCTlb6n9GfLxMxvUta7beEZEOf9oNtVHfAnyc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MMiNEG6f5NqYHiJQCO9NSy6/0WwlCPOgx2y+akYWPpc1IvnitA0PrKrpzMG6zfNLR k6vGC2xIl4726aTURWuQSDGj3mnOA/MiFr+FPTUqtYT6jwjalztiV4aRptLMNlToeH Oam3jGkzOAz+aKTcB0OkBJB5KKZZ7OZxF9E6yYPSTi1rNChRGBJAyEar5LSHy6tMS+ FeAMoe2mt431TyEMyZYQyONOTLC/YRLRuTjj+dePv2wFNMKUotM/qRefIUVocsyGL3 LceV4uU4T6Swu+Qu+x6sgvvKP0D97610TRp16sah59zGDM1PyXF0BZdmJcKCHdkAN0 +L1xLcZipp8ww== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/AguR9bKZDi0RXPPRWjc0nqJpY80 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:01:17 -0000 On 3/12/14 7:37 PM, Hadriel Kaplan wrote: > > On Mar 12, 2014, at 6:43 PM, Paul Kyzivat wrote: > >>> Instead I'll just point out that most of draft-kaplan-dispatch-gruu-problematic-00 is not due to problems caused by SBCs, or at least not *only* SBCs. >> >> Then maybe you can resume the role of good guys who fix other people's problems. :-) > > There is no problem I know of, so long as you do NOT use GRUUs, or ignore the 'gr' param and just behave like they're normal contact URIs. So you are saying that take any old contact from an existing dialog, and use it as the Refer-To URI in an out of dialog request to anybody, and it will work fine? > "Fixing" GRUU isn't really possible - at least not in the sense of (1) being a GRUU and thus *globally routable*, and also of being able to give a received GRUU to someone else and have them be able to use it, anytime, anyplace. > > It's not solvable because the problem is there is no URI you can create that is *truly* globally routable, in practice, in most networks. The reasons why are documented in draft-kaplan-dispatch-gruu-problematic-00. Many of those reasons ultimately mean there can be no such thing as a globally-routable/de-referencable URI, for many domains. In practice it is only important to be routable from places you want to be reached from. If other calls fail, and that is what you wanted to happen, then fine. The problem is when call flows break even when all the participants are legitimate - when the providers are creating a walled garden that only works for the specific call flows they have anticipated and made specific provision for. That breaks innovation, and drives things like webrtc. >>> (I haven't read Andrew's draft yet though) >> >> Go for it. Its short. > > Done. Yup, short. :) > It would be simpler to just use a Contact param that meant "use the received Record-Route list in this dialog to generate a Route set for a new out-of-dialog REFER, if you send such a REFER". Or something like that. Years back we toy'ed with the idea of embedding the Record-Route headers into the "gruu" contact, to try to make GRUU work, but it grows way too big. It sounds like you want to be involved in the update to 3515! >> Here is my problem: SIP was specified on the assumption of global routability of contacts. GRUUs were introduced to give UAs a alternative if they had no other way to get a globally routable contact. > > Why do they need one? What's "broken" that has to be fixed? > > The only problem I know of is that RFC 6665 demands GRUUs, and IMS has decided they need 6665 for some reason. You know the reason. First, it was updating 3265 to eliminate multiple dialog usages, as specified in rfc 5057. Do you have some other way to achieve that? > There's nothing wrong with 6665 - it just can't be used by many SIP domains, including IMS ones. It's like writing an RFC and saying "to implement this RFC you MUST use IPV6". That's cool and all... good luck with that. Did you object to 6665 when it was being reviewed? >> We don't have another general alternative. Requiring that UAs assume that magic middle boxes are always deployed that can figure out how to fix everyting doesn't seem a good answer, since we have no definition of such boxes and no way to ensure they are present. >> IMO it is the responsibility of middle boxes to ensure they don't break things. (Yes, I know that can be hard, since the full set of things they shouldn't break is undefined. But that is what you bite off when you deploy one.) > > It's not only the middleboxes that break it. If you deploy a SIP domain and don't accept SIP requests from any device anywhere on the Internet (for both IPv4 and IPv6), then you can't use GRUUs. If you deploy a SIP domain and won't allow all your proxies or UAs to directly send SIP requests to any device anywhere on the Internet, then you can't accept GRUUs. > > In practice, very few SIP domains accept SIP requests from any random device on the Internet, or allow all their proxies/UAs to send SIP requests directly to any random device on the Internet. IMS domains don't. Most Enterprise domains don't. They're all incompatible with GRUUs. They just don't realize it. That is unfortunate, and is indeed a problem. SIP was designed on the email model. But "market forces" don't like that model. But as I said above, I don't think it is *the* problem in this case. I realize there is *a* problem. Andrew's draft and yours about gruu indicate pain. I think it is reasonable to investigate that further. But it will take some work to tease out exactly what is causing the problem, and what makes sense as a solution. (Versus what implementers just don't want to do.) It seems to require formalizing behavior that is common in the field that is not written down in a way that allows it to be considered in our specifications. Thanks, Paul From nobody Thu Mar 13 10:44:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463BD1A0492 for ; Thu, 13 Mar 2014 10:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9m8NxwqRGum for ; Thu, 13 Mar 2014 10:44:27 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id F1D861A09FC for ; Thu, 13 Mar 2014 10:44:26 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-70-5321ee73749c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 23.90.04249.37EE1235; Thu, 13 Mar 2014 18:44:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 18:44:12 +0100 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkI9QG2qJsn0h02GuGTGefBK+5rd+86AgAAPFICAAQH2AIAAPIpf Date: Thu, 13 Mar 2014 17:44:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2132DD@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com>, <5321C834.9000309@alum.mit.edu> In-Reply-To: <5321C834.9000309@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW7xO8Vgg5lP9CyWTlrAavFp0ydm ixUbDrA6MHv8ff+ByWPJkp9MHh+f3mIJYI7isklJzcksSy3St0vgyvi4dRdLwSqOivOTnzM2 MJ5g62Lk5JAQMJE4unsdI4QtJnHh3nqgOBeHkMARRol9h+YyQThLGCXWrf3M3MXIwcEmYCHR /U8bpEFEIExix8qLrCA2s4C2xP/rEIOEBaIlupdNZIaoiZF4v7iREcJ2k/j3cyFYnEVAVaJ5 9RlGkJG8Ar4Si0+ZQ6y6yihx6+0tsHpOAR2JXxcawQ5lBDru+6k1TBC7xCVuPZnPBHG0gMSS PeeZIWxRiZeP/7FC2IoSV6cvh6rXkViw+xMbzJ3LFr4Gq+cVEJQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMXIUpxYn5aYbGWxiBEbOwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MNzYI6+isCshnzHxR0x43K7hWOjJ4mqu9T521WYPtxmrbMx6y B6eJP/35ehtfsct13klvd2fYSX5tmsfDfXHuscMf3q2LvxE39/Fsc/UQnlsvr3wNPlkc/Ojt /AyFJQmJHs8vHugRu/OJOWzaqVULzCt5Xx12PS9wxdWC5YfhoY92DVN1PKS0lFiKMxINtZiL ihMB+DpX2GoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/G7uVt3LBa1CzIxhLgH4ENP2Jsh8 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:44:29 -0000 Hi, >> In practice, very few SIP domains accept SIP requests from any random de= vice on the Internet, or allow all their proxies/UAs to send SIP requests=20 >> directly to any random device on the Internet. IMS domains don't. Most= Enterprise domains don't. They're all incompatible with GRUUs. They just= don't realize it. > > That is unfortunate, and is indeed a problem. SIP was designed on the > email model. But "market forces" don't like that model. E-mails aren't sent to a user device. They are sent to the receiver's mail = server, from where the user device(s) fetch them (push or pull). Also, one of the justifications for GRUU was to not only reach a specific u= ser - but a specific user DEVICE (needed for call transfer). E-mails don't = need to reach a specific user device - they can be "forked" to every user d= evice running a mail program connected to the mail server. I know this is not really related to the topic of this thread, but I don't = think we should compare SIP with e-mail :) Regards, Christer From nobody Thu Mar 13 10:53:03 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6967D1A0A36 for ; Thu, 13 Mar 2014 10:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrPJwRNi52DP for ; Thu, 13 Mar 2014 10:53:00 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 445F81A0A23 for ; Thu, 13 Mar 2014 10:53:00 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id d0wL1n0040SCNGk5A5st8E; Thu, 13 Mar 2014 17:52:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id d5st1n00B3ZTu2S3V5stWz; Thu, 13 Mar 2014 17:52:53 +0000 Message-ID: <5321F075.2020001@alum.mit.edu> Date: Thu, 13 Mar 2014 13:52:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , Hadriel Kaplan References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com>, <5321C834.9000309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2132DD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2132DD@ESESSMB209.ericsson.se> 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=1394733173; bh=2qyV+a7k7a18ls8EIAjM/d/4+S11rEOYpmx4HF4sSek=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DDsL7zFT/RZl91qbwOafr59l3Vp4dfNSZv1FhVnDjiUxCVWdFhGW1AGlvjHpsyzyg iw2zuMMSfF/SVWuy01UqoT3yOyosHUOS/vRmt2ddKaRwAoPs92CnWuX7bb5ABbT9Pz oH12kZLudDggIWGOtVzcvW1iZ7no+/xNtA0l9yUHJeJRTrdW5PkSP6QPmQMyMAPGwv wf/uHLSx05IbM/vdxJWDzlXYRsB6iRI2qburgVOLbGVF8vfzn2+Fx0dxdUoN+HUDEJ Uq1uBwA5rr9m3EIu7XkWTHOvhGhp7sxmIhq/0f3lhQwIdt+znjNUAvvTf86ohWmkT0 IbGjYLE6MwnXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/FpUftCKeAlGH4decg63EC4XjtxI Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:53:01 -0000 On 3/13/14 1:44 PM, Christer Holmberg wrote: > > Hi, > >>> In practice, very few SIP domains accept SIP requests from any random device on the Internet, or allow all their proxies/UAs to send SIP requests >>> directly to any random device on the Internet. IMS domains don't. Most Enterprise domains don't. They're all incompatible with GRUUs. They just don't realize it. >> >> That is unfortunate, and is indeed a problem. SIP was designed on the >> email model. But "market forces" don't like that model. > > E-mails aren't sent to a user device. They are sent to the receiver's mail server, from where the user device(s) fetch them (push or pull). > > Also, one of the justifications for GRUU was to not only reach a specific user - but a specific user DEVICE (needed for call transfer). E-mails don't need to reach a specific user device - they can be "forked" to every user device running a mail program connected to the mail server. > > I know this is not really related to the topic of this thread, but I don't think we should compare SIP with e-mail :) I meant it was like email in the sense that anyone can send to anyone. There aren't "peering relationships" that enforce an oligopoly. Thanks, Paul From nobody Thu Mar 13 11:10:58 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180A61A0A42 for ; Thu, 13 Mar 2014 11:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzLe2vzI0nZt for ; Thu, 13 Mar 2014 11:10:43 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC8C1A0A0F for ; Thu, 13 Mar 2014 11:10:43 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2DIAZZC007923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 18:10:35 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2DIAYBm025751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Mar 2014 18:10:34 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2DIAXlP029418; Thu, 13 Mar 2014 18:10:33 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Mar 2014 11:10:33 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <5321C834.9000309@alum.mit.edu> Date: Thu, 13 Mar 2014 14:10:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48BAD8BC-14D6-4338-A3CF-FEF74370C4B9@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/NgQuEftkVoPnU2Qcl-sUBZTYg-s Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 18:10:49 -0000 [splitting the email up because it's getting long...] On Mar 13, 2014, at 11:01 AM, Paul Kyzivat = wrote: > On 3/12/14 7:37 PM, Hadriel Kaplan wrote: >> There is no problem I know of, so long as you do NOT use GRUUs, or = ignore the 'gr' param and just behave like they're normal contact URIs. >=20 > So you are saying that take any old contact from an existing dialog, = and use it as the Refer-To URI in an out of dialog request to anybody, = and it will work fine? No of course not - I didn't mean you couldn't manufacture a problematic = scenario - I meant as far as I know, people aren't hitting this = "problem" in practice, in the field. We had some problems along these = lines years ago, but we fixed it by using "global contacts" as indicated = in my draft. I haven't heard of any problems since then. (which isn't = to say there aren't such problems - perhaps a LOT of people are having = such problems - I just haven't heard of it personally) >> "Fixing" GRUU isn't really possible - at least not in the sense of = (1) being a GRUU and thus *globally routable*, and also of being able to = give a received GRUU to someone else and have them be able to use it, = anytime, anyplace. >>=20 >> It's not solvable because the problem is there is no URI you can = create that is *truly* globally routable, in practice, in most networks. = The reasons why are documented in = draft-kaplan-dispatch-gruu-problematic-00. Many of those reasons = ultimately mean there can be no such thing as a = globally-routable/de-referencable URI, for many domains. >=20 > In practice it is only important to be routable from places you want = to be reached from. If other calls fail, and that is what you wanted to = happen, then fine. Right, so that's the "problem" I'm saying I don't see happening. Call = transfers aren't failing due to legacy SIP contact usage, afaict. It used to, but I haven't heard of problems since global contacts = started getting used. (but again, that's just my experience and I could = be way wrong on that) > The problem is when call flows break even when all the participants = are legitimate - when the providers are creating a walled garden that = only works for the specific call flows they have anticipated and made = specific provision for. That breaks innovation, and drives things like = webrtc. You realize the irony in that last statement right? Webrtc is = by-definition a walled-garden. :) -hadriel From nobody Thu Mar 13 11:50:00 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467FE1A0492 for ; Thu, 13 Mar 2014 11:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTKLXBIWTVyL for ; Thu, 13 Mar 2014 11:49:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id E05B31A07F5 for ; Thu, 13 Mar 2014 11:49:50 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2DInff3023381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 18:49:42 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2DIneON005826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Mar 2014 18:49:41 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2DIneGK008818; Thu, 13 Mar 2014 18:49:40 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Mar 2014 11:49:40 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <5321C834.9000309@alum.mit.edu> Date: Thu, 13 Mar 2014 14:49:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/VmaWU1p_s4Wp1vFdbJNSSSABsSo Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 18:49:53 -0000 [part 2...] On Mar 13, 2014, at 11:01 AM, Paul Kyzivat = wrote: >>>> (I haven't read Andrew's draft yet though) >>>=20 >>> Go for it. Its short. >>=20 >> Done. Yup, short. :) >> It would be simpler to just use a Contact param that meant "use the = received Record-Route list in this dialog to generate a Route set for a = new out-of-dialog REFER, if you send such a REFER". Or something like = that. Years back we toy'ed with the idea of embedding the Record-Route = headers into the "gruu" contact, to try to make GRUU work, but it grows = way too big. >=20 > It sounds like you want to be involved in the update to 3515! Only if it contains: "...and here's how to send in-dialog REFER = requests..." ;) On a more serious note, it needs to not demand GRUUs be used. >>> Here is my problem: SIP was specified on the assumption of global = routability of contacts. GRUUs were introduced to give UAs a alternative = if they had no other way to get a globally routable contact. >>=20 >> Why do they need one? What's "broken" that has to be fixed? >>=20 >> The only problem I know of is that RFC 6665 demands GRUUs, and IMS = has decided they need 6665 for some reason. >=20 > You know the reason. First, it was updating 3265 to eliminate multiple = dialog usages, as specified in rfc 5057. Do you have some other way to = achieve that? Afaik, the only "problem" with multiple dialog usages is implementors = get confused by it, or don't know about it to begin with. (and don't get = me wrong - it *is* very confusing) IMS has no substantive reason for eliminating them that I know of, nor = to go to 6665... other than the RFC number for 6665 is higher than 3265. Afaict, IMS networks can't truly use GRUUs safely, for most intents and = purposes. >> There's nothing wrong with 6665 - it just can't be used by many SIP = domains, including IMS ones. It's like writing an RFC and saying "to = implement this RFC you MUST use IPV6". That's cool and all... good luck = with that. >=20 > Did you object to 6665 when it was being reviewed? Nope. I don't even remember it much. I guess I wasn't paying much = attention to it - I thought it was just cleaning up stuff, not = fundamentally changing things. (my fault) >> It's not only the middleboxes that break it. If you deploy a SIP = domain and don't accept SIP requests from any device anywhere on the = Internet (for both IPv4 and IPv6), then you can't use GRUUs. If you = deploy a SIP domain and won't allow all your proxies or UAs to directly = send SIP requests to any device anywhere on the Internet, then you can't = accept GRUUs. >>=20 >> In practice, very few SIP domains accept SIP requests from any random = device on the Internet, or allow all their proxies/UAs to send SIP = requests directly to any random device on the Internet. IMS domains = don't. Most Enterprise domains don't. They're all incompatible with = GRUUs. They just don't realize it. >=20 > That is unfortunate, and is indeed a problem. SIP was designed on the = email model. But "market forces" don't like that model. Yup. We've been struggling with that in these WGs for over a decade. > But as I said above, I don't think it is *the* problem in this case. > I realize there is *a* problem. Andrew's draft and yours about gruu = indicate pain. I think it is reasonable to investigate that further. But = it will take some work to tease out exactly what is causing the problem, = and what makes sense as a solution. (Versus what implementers just don't = want to do.) It seems to require formalizing behavior that is common in = the field that is not written down in a way that allows it to be = considered in our specifications. It's a complicated issue. IMS in particular makes it even more = complicated, because as specified in the IMS docs the P-CSCF isn't truly = a B2BUA in the way an SBC is, yet the access-controls and message = routing rules/model are similar to SBCs. So they're trying to have = their cake and eat it too. Regardless, no matter it being true "IMS" as specified, or a normal = Service-provider network, or a access-controlled Enterprise, or = whatever... I think the basic problem is all messages related to a = dialog have to flow through specific hops; the same ones used for the = dialog. -hadriel From nobody Thu Mar 13 12:32:51 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4321A03E2 for ; Thu, 13 Mar 2014 12:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bexVu9SZN1rB for ; Thu, 13 Mar 2014 12:32:48 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 635551A078B for ; Thu, 13 Mar 2014 12:32:48 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-a9-532207d91aa3 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2C.1B.23809.9D702235; Thu, 13 Mar 2014 20:32:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 20:32:40 +0100 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkI9QG2qJsn0h02GuGTGefBK+5rd+86AgAAPFICAAV1y3w== Date: Thu, 13 Mar 2014 19:32:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2134F8@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu>, <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> In-Reply-To: <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje5NdqVgg4MzRCyWTlrAavFp0ydm ixUbDrA6MHv8ff+ByWPJkp9MHh+f3mIJYI7isklJzcksSy3St0vgyvg8ewlrQT9rxdE/nSwN jC0sXYycHBICJhLbX+9khbDFJC7cW8/WxcjFISRwiFFi+aIp7BDOEkaJu/+fMXcxcnCwCVhI dP/TBmkQEQiT+DdpGVgzs4C2xP/r6xhBbGGBaInuZROZIWpiJN4vbmSEsJ0kFt77CRZnEVCV ePhmDlgvr4CvxOzX/5khdm1mlNi5+zAbSIJTwE5i6fu77CA2I9B130+tYYJYJi5x68l8Joir BSSW7DnPDGGLSrx8/A/qG0WJq9OXQ9XrSCzY/YkN5tBlC18zQywWlDg58wnLBEaxWUjGzkLS MgtJyywkLQsYWVYxsucmZuaklxttYgRGzsEtv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjFJy2jeNOj78/CEXICjxTaGT/xX35fmT8rYc3Pv3wWVG5aA7 6+cannWwXR8Qm/Nbb0+ruQ3TrKlrrPMXXWv2NXqV2b+zTo6/JNDiaarv5IdaTccqxEvCKuvU P26ztcvmuLF9W/LsQ1XzF6/mWf10fqPeWn1Jbm2lVuFtM0SUZx63N0mTXf4/R4mlOCPRUIu5 qDgRAMH3qLtqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/UqGHKKoddshAD8dnkR0wUITQAA4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 19:32:50 -0000 Hi, > It would be simpler to just use a Contact param that meant "use the recei= ved Record-Route list in this dialog to generate a Route set for a new=20 > out-of-dialog REFER, if you send such a REFER". Or something like that. = Years back we toy'ed with the idea of embedding the Record-Route=20 > headers into the "gruu" contact, to try to make GRUU work, but it grows w= ay too big. Yes - we need to keep SIP messages short ;) Anyway, 3261 already supports adding embedded headers to the contact. Wheth= er entities would actually use them, especially for out-of-dialog requests,= is another question... Regards, Christer From nobody Thu Mar 13 12:42:01 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33391A09BD for ; Thu, 13 Mar 2014 12:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8Ap9HcXa6Wc for ; Thu, 13 Mar 2014 12:41:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C3CE11A094F for ; Thu, 13 Mar 2014 12:41:56 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-3d-532209fd0e46 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FF.AB.23809.DF902235; Thu, 13 Mar 2014 20:41:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 20:41:49 +0100 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkI9QG2qJsn0h02GuGTGefBK+5rd+86AgAAPFICAAQH2AIAAP9oAgAAdXH8= Date: Thu, 13 Mar 2014 19:41:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D213534@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje5fTqVgg08rDSyWTlrAavFp0ydm ixUbDrA6MHv8ff+ByWPJkp9MHh+f3mIJYI7isklJzcksSy3St0vgyvg57QxTQS97xdqNp5ga GI+zdjFyckgImEg8nbSYDcIWk7hwbz2YLSRwiFHi9T3lLkYuIHsJo0TLvLNADRwcbAIWEt3/ tEFqRATCJP5NWgY2h1lAW+L/9XWMILawQLRE97KJzBA1MRLvFzcyQth+EnObnoDZLAKqEjuf bwOr4RXwlXg1B+QGkF2dTBJnb1xiAUlwCthJPNs4H+wgRqDjvp9awwSxTFzi1pP5TBBHC0gs 2XOeGcIWlXj5+B/UY4oSV6cvh6rXkViw+xMbzKHLFr6GWiwocXLmE5YJjGKzkIydhaRlFpKW WUhaFjCyrGJkz03MzEkvN9rECIybg1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYN72O+CYoGdb49Ar7Qev6LS8N591ftOdx2yXxSWmH9v5uD+HMuOg5 McrzjnYN/ylBy1M1ZlN4zs6bo9q9ns1cOTVpyuorU+57/PhSvUpclSPs3pw9646U1C/j0+ap nSpjKn8m2N6YQenvXoO1n/7uUPPZ/Hv5qyMLRAq29GS2LNZZbs26fOnSVCWW4oxEQy3mouJE AIUXaIVpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/_g68eGNH3ojWyzywmT_fYaLVZgA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 19:41:59 -0000 Hi, >>>>> (I haven't read Andrew's draft yet though) >>>> >>>> Go for it. Its short. >>> >>> Done. Yup, short. :) >>> It would be simpler to just use a Contact param that meant "use the rec= eived Record-Route list in this dialog to generate a Route set for a new ou= t-of-dialog=20 >>> REFER, if you send such a REFER". Or something like that. Years back = we toy'ed with the idea of embedding the Record-Route headers into the "gru= u" contact, to try to make GRUU work, but it grows way too big. >> >> It sounds like you want to be involved in the update to 3515! > > Only if it contains: "...and here's how to send in-dialog REFER requests.= .." > ;) ...which, as we discuused in London, means that the text needs to continue = with "...by making sure no ref-subscription (well, at least not a ref-subsc= ription within the same dialog) is created..." Regards, Christer From nobody Thu Mar 13 13:59:29 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443BB1A0A39 for ; Thu, 13 Mar 2014 13:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YUVdanblGzH for ; Thu, 13 Mar 2014 13:59:25 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0171D1A0A28 for ; Thu, 13 Mar 2014 13:59:24 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2DKxDDd012446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 20:59:14 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2DKxDIx020284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 20:59:13 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2DKxD8j007410; Thu, 13 Mar 2014 20:59:13 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Mar 2014 13:59:12 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2134F8@ESESSMB209.ericsson.se> Date: Thu, 13 Mar 2014 16:59:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2B16BC52-DB8E-4DDC-8DA6-CC328F31E183@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu>, <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D2134F8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ajU6iOuib1DzYdsTzzRHDfkR4L8 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 20:59:27 -0000 On Mar 13, 2014, at 3:32 PM, Christer Holmberg = wrote: >> It would be simpler to just use a Contact param that meant "use the = received Record-Route list in this dialog to generate a Route set for a = new=20 >> out-of-dialog REFER, if you send such a REFER". Or something like = that. Years back we toy'ed with the idea of embedding the Record-Route=20= >> headers into the "gruu" contact, to try to make GRUU work, but it = grows way too big. >=20 > Yes - we need to keep SIP messages short ;) Actually, we do need to. Not in specs of course, but in deployment. :) > Anyway, 3261 already supports adding embedded headers to the contact. Of course - that's why we were considering using it. > Whether entities would actually use them, especially for out-of-dialog = requests, is another question... Yeah the odds aren't great. -hadriel From nobody Fri Mar 14 11:36:45 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819F1A01B6 for ; Fri, 14 Mar 2014 11:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz1DfHyL7YLU for ; Fri, 14 Mar 2014 11:36:24 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id A24321A01BF for ; Fri, 14 Mar 2014 11:36:18 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta14.westchester.pa.mail.comcast.net with comcast id dSTq1n0031swQuc5EWcBc5; Fri, 14 Mar 2014 18:36:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id dWcB1n00A3ZTu2S3bWcBp0; Fri, 14 Mar 2014 18:36:11 +0000 Message-ID: <53234C1B.3020308@alum.mit.edu> Date: Fri, 14 Mar 2014 14:36:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> 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=1394822171; bh=AZ6MmNGFO6CrPDdB0m6OdkLcc3pjclGBVZYU45x+dWQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YMcPX8H4hFYZWnJngigjHOHzU5VWsAwnxYVY2YNc20zHCNRuWabRc5u6Z0FDKTpU0 B+Z3lUSfVHsOrjfkwKoveNpomdREnYrbLJoKGKr1P8snubcl1jlLm1zp5+m8+ksfWL Ikhu7aw0oLa9YkqYa1UFPXt5wTkg9S+B1PCJthlzmf7zIJlXZybFaQzoqvDBVOuJhK tRtQwFTBHq4cMyB1XldFbXcmcA+/F7xFpHDPraSVJyzZ832W0K7v/lJ9pbRbszw9/e WjuEvrjbezdIuwjxM1MQtecZw0OuaPo0o2GH9yCxzUAz9GzOm11vjw22NrsAcLd8Tw TcsLQokI5CzSA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/KnwUaCzP-ydTvIARSczuw_WtDX0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:36:32 -0000 On 3/13/14 2:49 PM, Hadriel Kaplan wrote: > > [part 2...] > > On Mar 13, 2014, at 11:01 AM, Paul Kyzivat wrote: > >>>>> (I haven't read Andrew's draft yet though) >>>> >>>> Go for it. Its short. >>> >>> Done. Yup, short. :) >>> It would be simpler to just use a Contact param that meant "use the received Record-Route list in this dialog to generate a Route set for a new out-of-dialog REFER, if you send such a REFER". Or something like that. Years back we toy'ed with the idea of embedding the Record-Route headers into the "gruu" contact, to try to make GRUU work, but it grows way too big. >> >> It sounds like you want to be involved in the update to 3515! > > Only if it contains: "...and here's how to send in-dialog REFER requests..." > ;) > > On a more serious note, it needs to not demand GRUUs be used. Of the work currently contemplated, that is your leverage point to sell your position. >>>> Here is my problem: SIP was specified on the assumption of global routability of contacts. GRUUs were introduced to give UAs a alternative if they had no other way to get a globally routable contact. >>> >>> Why do they need one? What's "broken" that has to be fixed? >>> >>> The only problem I know of is that RFC 6665 demands GRUUs, and IMS has decided they need 6665 for some reason. >> >> You know the reason. First, it was updating 3265 to eliminate multiple dialog usages, as specified in rfc 5057. Do you have some other way to achieve that? > > Afaik, the only "problem" with multiple dialog usages is implementors get confused by it, or don't know about it to begin with. (and don't get me wrong - it *is* very confusing) So where were you when RFC5057 was being discussed. *I* was in favor of retaining multiple dialog usages, but AFAIK I was the *only* person who was. So I was overridden. > IMS has no substantive reason for eliminating them that I know of, nor to go to 6665... other than the RFC number for 6665 is higher than 3265. You heard Christer. They have a policy of updating to the latest updates to the drafts they reference. Also, they need the new H-I, and it references 6665. > Afaict, IMS networks can't truly use GRUUs safely, for most intents and purposes. As I said elsewhere, a number of years ago I worked on IMS revisions for GRUU. (Done for Cable Labs.) But I wasn't involved long enough to know if they were ever adopted. Were they? Or not? >>> There's nothing wrong with 6665 - it just can't be used by many SIP domains, including IMS ones. It's like writing an RFC and saying "to implement this RFC you MUST use IPV6". That's cool and all... good luck with that. >> >> Did you object to 6665 when it was being reviewed? > > Nope. I don't even remember it much. I guess I wasn't paying much attention to it - I thought it was just cleaning up stuff, not fundamentally changing things. (my fault) Then this is now sour grapes. >>> It's not only the middleboxes that break it. If you deploy a SIP domain and don't accept SIP requests from any device anywhere on the Internet (for both IPv4 and IPv6), then you can't use GRUUs. If you deploy a SIP domain and won't allow all your proxies or UAs to directly send SIP requests to any device anywhere on the Internet, then you can't accept GRUUs. >>> >>> In practice, very few SIP domains accept SIP requests from any random device on the Internet, or allow all their proxies/UAs to send SIP requests directly to any random device on the Internet. IMS domains don't. Most Enterprise domains don't. They're all incompatible with GRUUs. They just don't realize it. >> >> That is unfortunate, and is indeed a problem. SIP was designed on the email model. But "market forces" don't like that model. > > Yup. We've been struggling with that in these WGs for over a decade. > > >> But as I said above, I don't think it is *the* problem in this case. >> I realize there is *a* problem. Andrew's draft and yours about gruu indicate pain. I think it is reasonable to investigate that further. But it will take some work to tease out exactly what is causing the problem, and what makes sense as a solution. (Versus what implementers just don't want to do.) It seems to require formalizing behavior that is common in the field that is not written down in a way that allows it to be considered in our specifications. > > It's a complicated issue. IMS in particular makes it even more complicated, because as specified in the IMS docs the P-CSCF isn't truly a B2BUA in the way an SBC is, yet the access-controls and message routing rules/model are similar to SBCs. So they're trying to have their cake and eat it too. > > Regardless, no matter it being true "IMS" as specified, or a normal Service-provider network, or a access-controlled Enterprise, or whatever... I think the basic problem is all messages related to a dialog have to flow through specific hops; the same ones used for the dialog. They have to deal with the details. AFAIK you don't speak for them. I look to people like Christer, Andrew, and Gonzalo to bring up issues like this. And now is kind of late. Thanks, Paul From nobody Fri Mar 14 11:39:11 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29DE1A0185 for ; Fri, 14 Mar 2014 11:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4n6tm-XyVjD for ; Fri, 14 Mar 2014 11:39:09 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD451A019E for ; Fri, 14 Mar 2014 11:39:09 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id dPCD1n0050xGWP855Wf2PD; Fri, 14 Mar 2014 18:39:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id dWf21n00W3ZTu2S3YWf20y; Fri, 14 Mar 2014 18:39:02 +0000 Message-ID: <53234CC6.1090905@alum.mit.edu> Date: Fri, 14 Mar 2014 14:39:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , Hadriel Kaplan References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1D213534@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D213534@ESESSMB209.ericsson.se> 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=1394822342; bh=4NQIUiI3GCQ85FhtZqIckN7goY5WrpqNzjhaiL4isx8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XGB9iSXhmHPOzMFyyoGRGui5Cw85Jrpn+orvhSxbFoRdbK03/yLLJotMkKvA6qcdn IOA1WzR1eueNJpaC/4thhgb9ZVxMxQhbsxSsmGbdNy8Z5o9ap8vI5fy+aoyTAIfqqU N0bawLzC2MmbCWkCgy97CyuOpssNXlVDxaowIC/B+lVxBS/LcHCVmWaAOB+eIzndZN CaevJ3JQ7OSRLVED9wnCEvdlw8omCh4k/s6FoUVN2O69fGsIpEMDHL4u7DQx/bJsZJ Z/WHud9vzrWUBETB9bQSj/XfA08spBEgo8SiUrdg5YjzBK4qjp15RoCl/rZBFgjVu0 owB1HYvOUEHOw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/niZuHk3h2XOMJq6L4-gF35NELkE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:39:11 -0000 On 3/13/14 3:41 PM, Christer Holmberg wrote: > > Hi, > >>>>>> (I haven't read Andrew's draft yet though) >>>>> >>>>> Go for it. Its short. >>>> >>>> Done. Yup, short. :) >>>> It would be simpler to just use a Contact param that meant "use the received Record-Route list in this dialog to generate a Route set for a new out-of-dialog >>>> REFER, if you send such a REFER". Or something like that. Years back we toy'ed with the idea of embedding the Record-Route headers into the "gruu" contact, to try to make GRUU work, but it grows way too big. >>> >>> It sounds like you want to be involved in the update to 3515! >> >> Only if it contains: "...and here's how to send in-dialog REFER requests..." >> ;) > > ...which, as we discuused in London, means that the text needs to continue with "...by making sure no ref-subscription (well, at least not a ref-subscription within the same dialog) is created..." One of the possibilities mentioned (though not too seriously) was to revise 3515 to totally eliminate the implicit subscription to the refer event package - forcing it to be done explicitly if desired. I can think of lots of reasons why that would be a bad idea. But there may be other possibilities. ISTM that the way norefersub was defined was less than successful. Thanks, Paul From nobody Fri Mar 14 11:43:08 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8FF1A01A9 for ; Fri, 14 Mar 2014 11:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fZE9o_Jw9oW for ; Fri, 14 Mar 2014 11:43:05 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id F29151A01A0 for ; Fri, 14 Mar 2014 11:43:04 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta10.westchester.pa.mail.comcast.net with comcast id dWdg1n0051uE5Es5AWiypQ; Fri, 14 Mar 2014 18:42:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id dWix1n00f3ZTu2S3cWixR9; Fri, 14 Mar 2014 18:42:58 +0000 Message-ID: <53234DB1.702@alum.mit.edu> Date: Fri, 14 Mar 2014 14:42:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hadriel Kaplan , Christer Holmberg References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu>, <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D2134F8@ESESSMB209.ericsson.se> <2B16BC52-DB8E-4DDC-8DA6-CC328F31E183@oracle.com> In-Reply-To: <2B16BC52-DB8E-4DDC-8DA6-CC328F31E183@oracle.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=1394822578; bh=YEvql9NDJxm7bzUfjnYFzwogcx3UWTWWj5Hg4Y4eVQA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MhKnG8ov54dcYuxG01Pad+DDCLjYKozzGz12HPMixUmmqQzaes/i5zsqEWlYuVzT1 oareNDN/HLCy7WgyZQFx5wUENmbm62NLEq0uIpx7vpd8sBu7czUafebIXBO7dn2alF M31HaSN9kBfjxaj2hk9i20PiuCpBGDzeBwdx0MFppE7+PfytP5GF34w8aFLaBdlP/N D5+vEo7vb0ELMiO0nul+a9WUxDWTx0hgrFLEsISAGT2cVVkZpWQDPxIGzoJcI7Ktkq q0VdPKnX7machPY+Ls4UWJHCMx05+QkVj1b40hJNVMWWwzdRZzHTDwDtO9DvggRhX9 HkasdU9t1TejQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/R7BDXWbjGsnABWVCRWJngn47aQQ Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:43:06 -0000 On 3/13/14 4:59 PM, Hadriel Kaplan wrote: > > On Mar 13, 2014, at 3:32 PM, Christer Holmberg wrote: > >>> It would be simpler to just use a Contact param that meant "use the received Record-Route list in this dialog to generate a Route set for a new >>> out-of-dialog REFER, if you send such a REFER". Or something like that. Years back we toy'ed with the idea of embedding the Record-Route >>> headers into the "gruu" contact, to try to make GRUU work, but it grows way too big. >> >> Yes - we need to keep SIP messages short ;) > > Actually, we do need to. Not in specs of course, but in deployment. :) We haven't solved this with TCP. But maybe we are approaching a time when we have strong arguments for why people need to use TLS on all hops (without SIPS) to provide privacy, and then get large message support as a bonus. Thanks, Paul >> Anyway, 3261 already supports adding embedded headers to the contact. > > Of course - that's why we were considering using it. > > >> Whether entities would actually use them, especially for out-of-dialog requests, is another question... > > Yeah the odds aren't great. > > -hadriel > > > From nobody Fri Mar 14 12:00:37 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7011A01C6 for ; Fri, 14 Mar 2014 12:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWQu6IcRRgqB for ; Fri, 14 Mar 2014 12:00:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EFFC41A019F for ; Fri, 14 Mar 2014 12:00:30 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-f5-532351c76f98 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.8C.23809.7C153235; Fri, 14 Mar 2014 20:00:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 20:00:22 +0100 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkI9QG2qJsn0h02GuGTGefBK+5rd+86AgAAPFICAAQH2AIAAP9oAgAAdXH+AAXIAAIAAFYLT Date: Fri, 14 Mar 2014 19:00:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D215C22@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1D213534@ESESSMB209.ericsson.se>, <53234CC6.1090905@alum.mit.edu> In-Reply-To: <53234CC6.1090905@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje7xQOVgg2nbJS2WTlrAavFp0ydm ixUbDrA6MHv8ff+ByWPJkp9MHh+f3mIJYI7isklJzcksSy3St0vgyug8fZ+x4BN3Re/WdUwN jBs5uxg5OSQETCQeHl7GCGGLSVy4t56ti5GLQ0jgEKPEsY/7GSGcJYwS/b9vMnUxcnCwCVhI dP/TBmkQEQiT2LHyIiuIzSygLfH/+jqwQcIC0RLdyyYyQ9TESLxf3MgIYUdJ7Lg5lxVkDIuA qsTF5WogYV4BX4ldE7exQKx6yyQxZ3kvG0iCU0BH4u20s0wgNiPQcd9PrWGC2CUucevJfCaI owUkluw5zwxhi0q8fPyPFcJWkvix4RILRL2OxILdn9hg7ly28DUzxGJBiZMzn7BMYBSbhWTs LCQts5C0zELSsoCRZRUje25iZk56udEmRmDcHNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXAqKp5d8v9Iy3KCTXPrqv9q9W41dpSX+lz+J/d/Zaqwrq0 gtAr9+csMdlSNf0855G3FhEHa77M+y+2gvfxvwT/OSuzu3dOPxg664B1u/1jl1Xde59+N1j0 Q+3csfk/GU+8P3b6SPd2BVONqBLX2TFnApS0rl9huLOy8MhGnVyXCWtSTA6p3dNOuqLEUpyR aKjFXFScCACQMqKcaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/hp961V8CXHMuxRr8AnS0y-u1bns Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:00:35 -0000 Hi, >>>>>>> (I haven't read Andrew's draft yet though) >>>>>> >>>>>> Go for it. Its short. >>>>> >>>>> Done. Yup, short. :) >>>>> It would be simpler to just use a Contact param that meant "use the r= eceived Record-Route list in this dialog to generate a Route set for a new = out-of-dialog >>>>> REFER, if you send such a REFER". Or something like that. Years bac= k we toy'ed with the idea of embedding the Record-Route headers into the "g= ruu" contact, to try to make GRUU work, but it grows way too big. >>>> >>>> It sounds like you want to be involved in the update to 3515! >>> >>> Only if it contains: "...and here's how to send in-dialog REFER request= s..." >>> ;) >> >> ...which, as we discuused in London, means that the text needs to contin= ue with "...by making sure no ref-subscription (well, at least not a ref-su= bscription within the same dialog) is created..." > > One of the possibilities mentioned (though not too seriously) was to > revise 3515 to totally eliminate the implicit subscription to the refer > event package - forcing it to be done explicitly if desired. I took it possibility seriously :) > I can think of lots of reasons why that would be a bad idea. But there > may be other possibilities. ISTM that the way norefersub was defined was > less than successful. One suggestion (by myself) was to define a new option-tag, which in a Requi= re header field would mean "must support AND must use", similar to 100rel. Regards, Christer From nobody Fri Mar 14 12:12:25 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2734A1A01B4 for ; Fri, 14 Mar 2014 12:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_47=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtAshuSqECFA for ; Fri, 14 Mar 2014 12:12:20 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA61A018B for ; Fri, 14 Mar 2014 12:12:20 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id dUe31n0020bG4ec58XCDd4; Fri, 14 Mar 2014 19:12:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id dXCD1n0083ZTu2S3PXCDjV; Fri, 14 Mar 2014 19:12:13 +0000 Message-ID: <5323548D.3060407@alum.mit.edu> Date: Fri, 14 Mar 2014 15:12:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <48BAD8BC-14D6-4338-A3CF-FEF74370C4B9@oracle.com> In-Reply-To: <48BAD8BC-14D6-4338-A3CF-FEF74370C4B9@oracle.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=1394824333; bh=fQtMCKbHoYYpujp7t8APKKIbyem8NqWz/o6rbImaus8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pYP4q9eOiL+ev1ILPotLdop09Nuho+bvqycm7whlUOTpavaUalQjgmQrW1MOWanSI G9gBquh5Hu4f1RytAmA0RqsaVCB9HUiQvs4BtXmThjkDPBbRC3TGMR+VqsAGHs65Vf cIm/NXyJjj186tCuhUQxGC26rHgmBG9DkoCKvwLjDy9FUl5/Pn1l5oo6thxaF3NeME fWuyjQ9fM0xcuLXJXxCFTMWjU01TtFyclWrlKSsnraRW/JpOx2rlCKxBwS1HOpBO/G nKyLyqGnMi2SCtWGRL4F9QFPyJ1+2GmyMLefYY43woXjqEC5776ksA1SOO80IMFfE8 x03ikfiyKKYAQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/IrbFKLg_mHkeVDfQzuy0dNivj1c Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:12:22 -0000 On 3/13/14 2:10 PM, Hadriel Kaplan wrote: > > [splitting the email up because it's getting long...] > > On Mar 13, 2014, at 11:01 AM, Paul Kyzivat wrote: > >> On 3/12/14 7:37 PM, Hadriel Kaplan wrote: >>> There is no problem I know of, so long as you do NOT use GRUUs, or ignore the 'gr' param and just behave like they're normal contact URIs. >> >> So you are saying that take any old contact from an existing dialog, and use it as the Refer-To URI in an out of dialog request to anybody, and it will work fine? > > No of course not - I didn't mean you couldn't manufacture a problematic scenario - I meant as far as I know, people aren't hitting this "problem" in practice, in the field. We had some problems along these lines years ago, but we fixed it by using "global contacts" as indicated in my draft. I haven't heard of any problems since then. (which isn't to say there aren't such problems - perhaps a LOT of people are having such problems - I just haven't heard of it personally) > > >>> "Fixing" GRUU isn't really possible - at least not in the sense of (1) being a GRUU and thus *globally routable*, and also of being able to give a received GRUU to someone else and have them be able to use it, anytime, anyplace. >>> >>> It's not solvable because the problem is there is no URI you can create that is *truly* globally routable, in practice, in most networks. The reasons why are documented in draft-kaplan-dispatch-gruu-problematic-00. Many of those reasons ultimately mean there can be no such thing as a globally-routable/de-referencable URI, for many domains. >> >> In practice it is only important to be routable from places you want to be reached from. If other calls fail, and that is what you wanted to happen, then fine. > > Right, so that's the "problem" I'm saying I don't see happening. Call transfers aren't failing due to legacy SIP contact usage, afaict. > It used to, but I haven't heard of problems since global contacts started getting used. (but again, that's just my experience and I could be way wrong on that) So you say you haven't had a problem since you introduced a proprietary solution. And that was documented in an individual draft that expired years ago. (The draft was published on Oct 18, 2010, and afaict was discussed on the mailing list for two days and then never again until now.) From what I can see, the complete definition of "Global Contacts" is: "which are Contact URIs having the properties of a GRUU, but not being a GRUU in syntax (i.e., without a 'gr' param, and not indicating an AoR)." Note that the UA aren't required to use GRUUs constructed according to rfc5627. They can use anything with the required properties. The purpose of the "gr" parameter is to hint others that the uri has the gruu property, so they can avoid work-arounds such as sending requests in-dialog. I guess you wanted to preserve the work=arounds. >> The problem is when call flows break even when all the participants are legitimate - when the providers are creating a walled garden that only works for the specific call flows they have anticipated and made specific provision for. That breaks innovation, and drives things like webrtc. > > You realize the irony in that last statement right? Webrtc is by-definition a walled-garden. :) It depends on your point of view. Certainly each web server that puts usages of webrtc into its web pages is a sort of walled garden. And that can indeed be a problem if I want to talk to a Facebook user, since I don't have a Facebook account. OTOH, it is open in the sense that any browser can work with any of those web servers. It is a radically different model, so hard to compare. Thanks, Paul From nobody Fri Mar 14 13:34:38 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6111A01CA for ; Fri, 14 Mar 2014 13:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNV_AU2GUvC5 for ; Fri, 14 Mar 2014 13:34:35 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 677891A01C8 for ; Fri, 14 Mar 2014 13:34:35 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2EKYQgF003981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Mar 2014 20:34:27 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2EKYQmY029973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Mar 2014 20:34:26 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2EKYPMo020876; Fri, 14 Mar 2014 20:34:26 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Mar 2014 13:34:25 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <53234C1B.3020308@alum.mit.edu> Date: Fri, 14 Mar 2014 16:34:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/hW8zDVy2LNAKxHOz03qMlTXBahQ Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 20:34:37 -0000 On Mar 14, 2014, at 2:36 PM, Paul Kyzivat wrote: >> Afaik, the only "problem" with multiple dialog usages is implementors = get confused by it, or don't know about it to begin with. (and don't get = me wrong - it *is* very confusing) >=20 > So where were you when RFC5057 was being discussed. I don't know - probably doing my day job instead of IETF stuff. :) >> IMS has no substantive reason for eliminating them that I know of, = nor to go to 6665... other than the RFC number for 6665 is higher than = 3265. >=20 > You heard Christer. They have a policy of updating to the latest = updates to the drafts they reference. Also, they need the new H-I, and = it references 6665. Uhhh, not that I see it doesn't. Why would it? >> Afaict, IMS networks can't truly use GRUUs safely, for most intents = and purposes. >=20 > As I said elsewhere, a number of years ago I worked on IMS revisions = for GRUU. (Done for Cable Labs.) But I wasn't involved long enough to = know if they were ever adopted. Were they? Or not? Using GRUUs is in their specs. Whether it gets used in practice is a = different question, with probably a mixed answer. (there's a lot in IMS = specs that rarely sees deployment, or takes a veeery long time to, = afaict) >>>> There's nothing wrong with 6665 - it just can't be used by many SIP = domains, including IMS ones. It's like writing an RFC and saying "to = implement this RFC you MUST use IPV6". That's cool and all... good luck = with that. >>>=20 >>> Did you object to 6665 when it was being reviewed? >>=20 >> Nope. I don't even remember it much. I guess I wasn't paying much = attention to it - I thought it was just cleaning up stuff, not = fundamentally changing things. (my fault) >=20 > Then this is now sour grapes. Oh no, not at all - RFFC 6665 is only a "Proposed Standard" after all, = not an actual Internet Standard. ;) >> It's a complicated issue. IMS in particular makes it even more = complicated, because as specified in the IMS docs the P-CSCF isn't truly = a B2BUA in the way an SBC is, yet the access-controls and message = routing rules/model are similar to SBCs. So they're trying to have = their cake and eat it too. >>=20 >> Regardless, no matter it being true "IMS" as specified, or a normal = Service-provider network, or a access-controlled Enterprise, or = whatever... I think the basic problem is all messages related to a = dialog have to flow through specific hops; the same ones used for the = dialog. >=20 > They have to deal with the details. AFAIK you don't speak for them. I = look to people like Christer, Andrew, and Gonzalo to bring up issues = like this. And now is kind of late. I don't speak for anyone but myself in IETF mailing lists. Not for 3GPP, = nor my employer. I didn't start this thread - you guys did. So I'm just = giving my input, and it's not just about IMS networks. If you don't want = public input, I don't think this mailing list is the right one for this = thread. (or else I misunderstand the nature of IETF WG mailing lists) -hadriel From nobody Fri Mar 14 13:38:17 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F071A01D7 for ; Fri, 14 Mar 2014 13:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTah-G4H1yXW for ; Fri, 14 Mar 2014 13:38:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 70F651A01D6 for ; Fri, 14 Mar 2014 13:38:13 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2EKc2CD007691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Mar 2014 20:38:03 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2EKc1dt006064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2014 20:38:02 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2EKc1GP005745; Fri, 14 Mar 2014 20:38:01 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Mar 2014 13:38:01 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <53234CC6.1090905@alum.mit.edu> Date: Fri, 14 Mar 2014 16:37:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4351258D-F92D-44BF-9C8C-FE3227BE841A@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1D213534@ESESSMB209.ericsson.se> <53234CC6.1090905@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/MDnkdA-8o0kK2g_McugYJXurztw Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 20:38:15 -0000 On Mar 14, 2014, at 2:39 PM, Paul Kyzivat wrote: > On 3/13/14 3:41 PM, Christer Holmberg wrote: >>=20 >> ...which, as we discuused in London, means that the text needs to = continue with "...by making sure no ref-subscription (well, at least not = a ref-subscription within the same dialog) is created..." >=20 > One of the possibilities mentioned (though not too seriously) was to = revise 3515 to totally eliminate the implicit subscription to the refer = event package - forcing it to be done explicitly if desired. I don't think that will help - because if the UA desires to do it = explicitly, the SUBSCRIBE has to go to the same place/path the = INVITE/REFER did too. -hadriel From nobody Fri Mar 14 13:57:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C181A01D1 for ; Fri, 14 Mar 2014 13:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOKVU86BfMfX for ; Fri, 14 Mar 2014 13:57:46 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0181A01CC for ; Fri, 14 Mar 2014 13:57:46 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-81-53236d42d6c0 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id D8.0F.04853.24D63235; Fri, 14 Mar 2014 21:57:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 21:57:38 +0100 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkI9QG2qJsn0h02GuGTGefBK+5rd+86AgAAPFICAAQH2AIAAP9oAgAAdXH+AAXIAAIAAITyAgAAVrz4= Date: Fri, 14 Mar 2014 20:57:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D215D17@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1D213534@ESESSMB209.ericsson.se> <53234CC6.1090905@alum.mit.edu>, <4351258D-F92D-44BF-9C8C-FE3227BE841A@oracle.com> In-Reply-To: <4351258D-F92D-44BF-9C8C-FE3227BE841A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvja5TrnKwwYutChZLJy1gtfi06ROz xYoNB1gdmD3+vv/A5LFkyU8mj49Pb7EEMEdx2aSk5mSWpRbp2yVwZewDqi+YylbR2O/TwPiO pYuRk0NCwETi+Ye1rBC2mMSFe+vZuhi5OIQETjBKTF10ghXCWcIo8fDFfuYuRg4ONgELie5/ 2iANIgJhEv8mLQNrZhbQlvh/fR0jiC0sEC3RvWwiM0RNjMT7xY2MEHaSxOc1X8HiLAKqErcn bGYEGckr4CvxZbE4xKqFzBIbJq0Dm8kpYCfx5uAjsEMZgY77fmoNE8QucYlbT+YzQRwtILFk z3lmCFtU4uXjf1DPKEp8fLWPEaJeR2LB7k9sMHcuW/garJ5XQFDi5MwnLBMYxWYhGTsLScss JC2zkLQsYGRZxShZnFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGFkHt/w22sF4co/9IUZp DhYlcd7rrDVBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhibVLxiTuc7vp75Rz0vTE+v68qU bhONS1PtEmYu09R6bWrixTzfPcb8GPeFUzmmVxK/nXZPsO38+pfXpXxhcUkMo8r6uycE9Lv7 58/Ifrzxv6DzIQve7K8nH/K83O99c/mGxJf3w45byKca/dWdGF1dXbairEl8g3dL6OuVHMHW z5+Y25mGGCqxFGckGmoxFxUnAgBK9tJhegIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/EigzcHbxgPThzcDQNFr46VkQftc Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 20:57:47 -0000 Hi, >>> ...which, as we discuused in London, means that the text needs to conti= nue with "...by making sure no ref-subscription (well, at least not a ref->= >>subscription within the same dialog) is created..." >> >> One of the possibilities mentioned (though not too seriously) was to rev= ise 3515 to totally eliminate the implicit subscription to the refer event = package - >> forcing it to be done explicitly if desired. > > I don't think that will help - because if the UA desires to do it explici= tly, the SUBSCRIBE has to go to the same place/path the INVITE/REFER did to= o. True. But, it would solve the case where the UA does NOT want a subscriptio= n, which I belive is the use-case that triggered the discussion in London := ) Regards, Christer From nobody Fri Mar 14 14:03:45 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB961A01D1 for ; Fri, 14 Mar 2014 14:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LaNUjupYx63 for ; Fri, 14 Mar 2014 14:03:40 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1820E1A01CB for ; Fri, 14 Mar 2014 14:03:40 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 14:00:45 -0700 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "hadriel.kaplan@oracle.com" Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkJAwL91KWETy0uWxRW9R8gOD5regeqAgAAPFICAAQH2AIAANO4AgAGjjoD//6hx0A== Date: Fri, 14 Mar 2014 21:03:38 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF41FC5@sc9-ex2k10mb1.corp.yaanatech.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <48BAD8BC-14D6-4338-A3CF-FEF74370C4B9@oracle.com> <5323548D.3060407@alum.mit.edu> In-Reply-To: <5323548D.3060407@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.121] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04C5_01CF3FA6.EF53EED0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/zrNQ62SSJNM5NNA2w9mNRqA6_fk Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 21:03:43 -0000 ------=_NextPart_000_04C5_01CF3FA6.EF53EED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The real irony would be if the WebRTC servers interconnected to each other using a widely-available IMS and thereby become more open. One walled-garden turning the other walled-garden inside out. :) ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, March 14, 2014 3:12 PM To: Hadriel Kaplan Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 On 3/13/14 2:10 PM, Hadriel Kaplan wrote: > > [splitting the email up because it's getting long...] > > On Mar 13, 2014, at 11:01 AM, Paul Kyzivat wrote: > >> On 3/12/14 7:37 PM, Hadriel Kaplan wrote: >>> There is no problem I know of, so long as you do NOT use GRUUs, or ignore the 'gr' param and just behave like they're normal contact URIs. >> >> So you are saying that take any old contact from an existing dialog, and use it as the Refer-To URI in an out of dialog request to anybody, and it will work fine? > > No of course not - I didn't mean you couldn't manufacture a > problematic scenario - I meant as far as I know, people aren't hitting > this "problem" in practice, in the field. We had some problems along > these lines years ago, but we fixed it by using "global contacts" as > indicated in my draft. I haven't heard of any problems since then. > (which isn't to say there aren't such problems - perhaps a LOT of > people are having such problems - I just haven't heard of it > personally) > > >>> "Fixing" GRUU isn't really possible - at least not in the sense of (1) being a GRUU and thus *globally routable*, and also of being able to give a received GRUU to someone else and have them be able to use it, anytime, anyplace. >>> >>> It's not solvable because the problem is there is no URI you can create that is *truly* globally routable, in practice, in most networks. The reasons why are documented in draft-kaplan-dispatch-gruu-problematic-00. Many of those reasons ultimately mean there can be no such thing as a globally-routable/de-referencable URI, for many domains. >> >> In practice it is only important to be routable from places you want to be reached from. If other calls fail, and that is what you wanted to happen, then fine. > > Right, so that's the "problem" I'm saying I don't see happening. Call transfers aren't failing due to legacy SIP contact usage, afaict. > It used to, but I haven't heard of problems since global contacts > started getting used. (but again, that's just my experience and I > could be way wrong on that) So you say you haven't had a problem since you introduced a proprietary solution. And that was documented in an individual draft that expired years ago. (The draft was published on Oct 18, 2010, and afaict was discussed on the mailing list for two days and then never again until now.) From what I can see, the complete definition of "Global Contacts" is: "which are Contact URIs having the properties of a GRUU, but not being a GRUU in syntax (i.e., without a 'gr' param, and not indicating an AoR)." Note that the UA aren't required to use GRUUs constructed according to rfc5627. They can use anything with the required properties. The purpose of the "gr" parameter is to hint others that the uri has the gruu property, so they can avoid work-arounds such as sending requests in-dialog. I guess you wanted to preserve the work=arounds. >> The problem is when call flows break even when all the participants are legitimate - when the providers are creating a walled garden that only works for the specific call flows they have anticipated and made specific provision for. That breaks innovation, and drives things like webrtc. > > You realize the irony in that last statement right? Webrtc is > by-definition a walled-garden. :) It depends on your point of view. Certainly each web server that puts usages of webrtc into its web pages is a sort of walled garden. And that can indeed be a problem if I want to talk to a Facebook user, since I don't have a Facebook account. OTOH, it is open in the sense that any browser can work with any of those web servers. It is a radically different model, so hard to compare. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_04C5_01CF3FA6.EF53EED0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDMx NDIxMDA0MlowIwYJKoZIhvcNAQkEMRYEFCDtDNwM9G9WidRD7sEBa410M6qxMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAM6zEv8EgcKw2UCzPemeD5MlmwmytYGtyxY+7WzBK 3AI9xjf07flSQWCU1agJJgoWP683m5fMKpb82jjkRJ54aRLiJcdKGjsMqfMO008/KXfPmunZVKt8 pvUzN38QKS781DixvAIenm2tbL4ZKkA6oaSQcZq1CXfM/Sr8lPcOZO55phsIPzn3yysi7IkZ7cCr 6OXY6ttxyAFcSpcQdvJP49MUrxmlTW2G9vZ7dYxJO+uGh6Fp/vT07nH3l/cF0KdjLzbH1BTUHhEQ ls0Rbmlr7XoY8AdGPQO2G4b+SofxL+zkENsz2Ei9UYM/JXjIZKxB1bZaGv3Ggexe5F+UqHFP2gAA AAAAAA== ------=_NextPart_000_04C5_01CF3FA6.EF53EED0-- From nobody Fri Mar 14 14:11:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F871A01CF for ; Fri, 14 Mar 2014 14:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBLaXdSdFMuJ for ; Fri, 14 Mar 2014 14:11:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4075A1A01CB for ; Fri, 14 Mar 2014 14:11:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-71-5323705cd3b2 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C7.24.23809.C5073235; Fri, 14 Mar 2014 22:10:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 22:10:52 +0100 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkI9QG2qJsn0h02GuGTGefBK+5rd+86AgAAPFICAAQH2AIAAP9oAgAGOkYCAACEGgIAAF95e Date: Fri, 14 Mar 2014 21:10:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu>, <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> In-Reply-To: <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW5MgXKwwfMzKhZLJy1gtfi06ROz xYoNB1gdmD3+vv/A5LFkyU8mj49Pb7EEMEdx2aSk5mSWpRbp2yVwZfT+aGEp2CVfsX7uJeYG xi7JLkZODgkBE4nHO56yQ9hiEhfurWfrYuTiEBI4xChx4n8XI4SzhFFi2cSvQBkODjYBC4nu f9ogDSICYRL/Ji1jBbGZBbQl/l9fxwhiCwtES3Qvm8gMURMj8X5xIyOEHSXxaEsXWJxFQFXi 8OW/YHFeAV+Je59+QS2+zyTR8PofG0iCU8BO4v+WxWALGIGu+35qDRPEMnGJW0/mM0FcLSCx ZM95ZghbVOLl43+sELaixMdX+xgh6nUkFuz+xAZz6LKFr5khFgtKnJz5hGUCo9gsJGNnIWmZ haRlFpKWBYwsqxjZcxMzc9LLjTYxAiPn4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQbGpVGB9RfmFz2MNM8I8SqqZBReL5Giz3kqeEv1x3spC6e2cx4X Ur54OOL8AUG128tLg/dpzrz5N6/YJHKjVcivw9UZ581dJW0Mjkt9zBb42LHhQpHsu+XeeVsz F77QfnZJ6zuz+qKHdtMZz61gjAyZFOohPz/J4/A2xQTf+0naArp3nNPd45SVWIozEg21mIuK EwHI94aZagIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/kyJZRS2krT5CPpBpSKv8wvIy5e8 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 21:11:04 -0000 Hi, What started this whole discussion was the submission of Andrew's draft, wh= ich is not about GRUUs as such, eventhough the draft does mention GRUUs get= ting overwritten.=20 The main issue raised in the draft is SBCs re-writing the contact, but not = other parameters (e.g Target-Dialog, Replaces, Refer-To URI, etc), and that= out-of-dialog requested addressed using those other parameters won't reach= the UA. Regards, Christer ________________________________________ From: dispatch [dispatch-bounces@ietf.org] on behalf of Hadriel Kaplan [had= riel.kaplan@oracle.com] Sent: Friday, 14 March 2014 10:34 PM To: Paul Kyzivat Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dia= log-request-00 On Mar 14, 2014, at 2:36 PM, Paul Kyzivat wrote: >> Afaik, the only "problem" with multiple dialog usages is implementors ge= t confused by it, or don't know about it to begin with. (and don't get me w= rong - it *is* very confusing) > > So where were you when RFC5057 was being discussed. I don't know - probably doing my day job instead of IETF stuff. :) >> IMS has no substantive reason for eliminating them that I know of, nor t= o go to 6665... other than the RFC number for 6665 is higher than 3265. > > You heard Christer. They have a policy of updating to the latest updates = to the drafts they reference. Also, they need the new H-I, and it reference= s 6665. Uhhh, not that I see it doesn't. Why would it? >> Afaict, IMS networks can't truly use GRUUs safely, for most intents and = purposes. > > As I said elsewhere, a number of years ago I worked on IMS revisions for = GRUU. (Done for Cable Labs.) But I wasn't involved long enough to know if t= hey were ever adopted. Were they? Or not? Using GRUUs is in their specs. Whether it gets used in practice is a differ= ent question, with probably a mixed answer. (there's a lot in IMS specs tha= t rarely sees deployment, or takes a veeery long time to, afaict) >>>> There's nothing wrong with 6665 - it just can't be used by many SIP do= mains, including IMS ones. It's like writing an RFC and saying "to impleme= nt this RFC you MUST use IPV6". That's cool and all... good luck with that= . >>> >>> Did you object to 6665 when it was being reviewed? >> >> Nope. I don't even remember it much. I guess I wasn't paying much attent= ion to it - I thought it was just cleaning up stuff, not fundamentally chan= ging things. (my fault) > > Then this is now sour grapes. Oh no, not at all - RFFC 6665 is only a "Proposed Standard" after all, not = an actual Internet Standard. ;) >> It's a complicated issue. IMS in particular makes it even more complica= ted, because as specified in the IMS docs the P-CSCF isn't truly a B2BUA in= the way an SBC is, yet the access-controls and message routing rules/model= are similar to SBCs. So they're trying to have their cake and eat it too. >> >> Regardless, no matter it being true "IMS" as specified, or a normal Serv= ice-provider network, or a access-controlled Enterprise, or whatever... I t= hink the basic problem is all messages related to a dialog have to flow thr= ough specific hops; the same ones used for the dialog. > > They have to deal with the details. AFAIK you don't speak for them. I loo= k to people like Christer, Andrew, and Gonzalo to bring up issues like this= . And now is kind of late. I don't speak for anyone but myself in IETF mailing lists. Not for 3GPP, no= r my employer. I didn't start this thread - you guys did. So I'm just givin= g my input, and it's not just about IMS networks. If you don't want public = input, I don't think this mailing list is the right one for this thread. (o= r else I misunderstand the nature of IETF WG mailing lists) -hadriel _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Mar 14 14:12:18 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3C01A01F0 for ; Fri, 14 Mar 2014 14:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rogZQD-jotGz for ; Fri, 14 Mar 2014 14:12:15 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E370D1A01CF for ; Fri, 14 Mar 2014 14:12:14 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-34-532370a7142a Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E8.DF.04853.7A073235; Fri, 14 Mar 2014 22:12:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 22:12:07 +0100 From: Christer Holmberg To: Michael Hammer , "pkyzivat@alum.mit.edu" , "hadriel.kaplan@oracle.com" Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkI9QG2qJsn0h02GuGTGefBK+5rd+86AgAAPFICAAQH2AIAANO0AgAGjj4CAAB8hAIAAEuy6 Date: Fri, 14 Mar 2014 21:12:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D215FD7@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <48BAD8BC-14D6-4338-A3CF-FEF74370C4B9@oracle.com> <5323548D.3060407@alum.mit.edu>, <00C069FD01E0324C9FFCADF539701DB3BBF41FC5@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF41FC5@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvje7yAuVggyP3ZS2WTlrAavFp0ydm i3Urv7FYrNhwgNWBxePv+w9MHkuW/GTy+Pj0FovH9YM9jAEsUVw2Kak5mWWpRfp2CVwZRy8+ Yy7YqVrx68UMlgbGNrkuRk4OCQETibdHl7JD2GISF+6tZ+ti5OIQEjjBKHH36DMWCGcJo0TP 1OPMXYwcHGwCFhLd/7RBGkQE5jNKbLoXCWIzC2hL/L++jhHEFhaIluheNpEZoiZG4v3iRkYI O0riy/f5LCA2i4CqxPrGc2wgNq+Ar8TmxW/A6oUEfjJJ3PyQCWJzCkRIvJkxDayGEei476fW MEHsEpe49WQ+E8TRAhJL9pxnhrBFJV4+/scKYStKfHy1jxGiXkdiwe5PbDB3Llv4mhlir6DE yZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyilGyOLW4ODfdyEAvNz23RC+1KDO5uDg/T684dRMj MN4ObvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTB2/Try 60D8Q80KNZsC73PvGH/JJJ94tOtXywephiNTveP8Sr4fUk1r9vDVvbL18y/+A2syH3K+vdnk OjU3bvHC6rAtLH++7TmWGWV+K26bxN44vpwNJ3etcrZQaMjaxfNrwX71P/4rcg6oOlY0r9B+ 1CzUY2TfF+LOPSd77WJbMYUlfpOK8xKVWIozEg21mIuKEwGHF0VDhQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/AY4miclvmEqg5FAcSVdlw9Ujs5k Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 21:12:17 -0000 >The real irony would be if the WebRTC servers interconnected to each other >using a widely-available IMS and thereby become more open. > >One walled-garden turning the other walled-garden inside out. :) Well, your dream is about to become true, as 3GPP is currently defining Web= RTC access to IMS :) Regards, Christer ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, March 14, 2014 3:12 PM To: Hadriel Kaplan Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 On 3/13/14 2:10 PM, Hadriel Kaplan wrote: > > [splitting the email up because it's getting long...] > > On Mar 13, 2014, at 11:01 AM, Paul Kyzivat wrote: > >> On 3/12/14 7:37 PM, Hadriel Kaplan wrote: >>> There is no problem I know of, so long as you do NOT use GRUUs, or ignore the 'gr' param and just behave like they're normal contact URIs. >> >> So you are saying that take any old contact from an existing dialog, and use it as the Refer-To URI in an out of dialog request to anybody, and it will work fine? > > No of course not - I didn't mean you couldn't manufacture a > problematic scenario - I meant as far as I know, people aren't hitting > this "problem" in practice, in the field. We had some problems along > these lines years ago, but we fixed it by using "global contacts" as > indicated in my draft. I haven't heard of any problems since then. > (which isn't to say there aren't such problems - perhaps a LOT of > people are having such problems - I just haven't heard of it > personally) > > >>> "Fixing" GRUU isn't really possible - at least not in the sense of (1) being a GRUU and thus *globally routable*, and also of being able to give a received GRUU to someone else and have them be able to use it, anytime, anyplace. >>> >>> It's not solvable because the problem is there is no URI you can create that is *truly* globally routable, in practice, in most networks. The reasons why are documented in draft-kaplan-dispatch-gruu-problematic-00. Many of those reasons ultimately mean there can be no such thing as a globally-routable/de-referencable URI, for many domains. >> >> In practice it is only important to be routable from places you want to be reached from. If other calls fail, and that is what you wanted to happen= , then fine. > > Right, so that's the "problem" I'm saying I don't see happening. Call transfers aren't failing due to legacy SIP contact usage, afaict. > It used to, but I haven't heard of problems since global contacts > started getting used. (but again, that's just my experience and I > could be way wrong on that) So you say you haven't had a problem since you introduced a proprietary solution. And that was documented in an individual draft that expired years ago. (The draft was published on Oct 18, 2010, and afaict was discussed on the mailing list for two days and then never again until now.) From what I can see, the complete definition of "Global Contacts" is: "which are Contact URIs having the properties of a GRUU, but not being a GRUU in syntax (i.e., without a 'gr' param, and not indicating an AoR)." Note that the UA aren't required to use GRUUs constructed according to rfc5627. They can use anything with the required properties. The purpose of the "gr" parameter is to hint others that the uri has the gruu property, so they can avoid work-arounds such as sending requests in-dialog. I guess you wanted to preserve the work=3Darounds. >> The problem is when call flows break even when all the participants are legitimate - when the providers are creating a walled garden that only work= s for the specific call flows they have anticipated and made specific provision for. That breaks innovation, and drives things like webrtc. > > You realize the irony in that last statement right? Webrtc is > by-definition a walled-garden. :) It depends on your point of view. Certainly each web server that puts usage= s of webrtc into its web pages is a sort of walled garden. And that can indee= d be a problem if I want to talk to a Facebook user, since I don't have a Facebook account. OTOH, it is open in the sense that any browser can work with any of those web servers. It is a radically different model, so hard to compare. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Mar 14 14:33:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AC61A01E2 for ; Fri, 14 Mar 2014 14:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsYLcxXwVSLv for ; Fri, 14 Mar 2014 14:33:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 16E301A01D1 for ; Fri, 14 Mar 2014 14:33:03 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2ELWs9B029457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Mar 2014 21:32:55 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2ELWrux019298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2014 21:32:54 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2ELWrIp029828; Fri, 14 Mar 2014 21:32:53 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Mar 2014 14:32:53 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <5323548D.3060407@alum.mit.edu> Date: Fri, 14 Mar 2014 17:32:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99CF4DA4-40BC-4DA2-A7CF-D1B48FC136BB@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <48BAD8BC-14D6-4338-A3CF-FEF74370C4B9@oracle.com> <5323548D.3060407@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/rhhHSTgbTy7qjA58XS0qrH3N5qs Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 21:33:04 -0000 On Mar 14, 2014, at 3:12 PM, Paul Kyzivat wrote: > On 3/13/14 2:10 PM, Hadriel Kaplan wrote: >> Right, so that's the "problem" I'm saying I don't see happening. = Call transfers aren't failing due to legacy SIP contact usage, afaict. >> It used to, but I haven't heard of problems since global contacts = started getting used. (but again, that's just my experience and I could = be way wrong on that) >=20 > So you say you haven't had a problem since you introduced a = proprietary solution. And that was documented in an individual draft = that expired years ago. (The draft was published on Oct 18, 2010, and = afaict was discussed on the mailing list for two days and then never = again until now.) I think you're venting at the wrong target. I didn't raise this = topic/thread, nor was I the one to start referencing my gruu-problematic = draft. I'm not the one bringing this issue up in the first place. Regarding the gruu-problematic draft, I didn't refresh it since 2010 = because there didn't seem much interest - in fact, there was general = anger vented against it if I recall right. I get enough of that from my = other drafts, I didn't need another. :) > Note that the UA aren't required to use GRUUs constructed according to = rfc5627. They can use anything with the required properties. The purpose = of the "gr" parameter is to hint others that the uri has the gruu = property, so they can avoid work-arounds such as sending requests = in-dialog. I guess you wanted to preserve the work=3Darounds. No, we wanted to keep calls working. We would have far preferred to = have to do nothing new instead, and let things just work as advertised. -hadriel From nobody Fri Mar 14 17:50:49 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBB41A021F for ; Fri, 14 Mar 2014 17:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKdTzJh1fcwj for ; Fri, 14 Mar 2014 17:50:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 656321A0240 for ; Fri, 14 Mar 2014 17:50:05 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2F0nsBd027747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Mar 2014 00:49:54 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 s2F0nrwD003532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2014 00:49:53 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s2F0nrXs005920; Sat, 15 Mar 2014 00:49:53 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Mar 2014 17:49:52 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se> Date: Fri, 14 Mar 2014 20:49:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0956401D-93D6-4253-B05E-8898A36112C5@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu>, <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/y5QP78_FWqMh3pidRLPpo8gtReE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:50:45 -0000 On Mar 14, 2014, at 5:10 PM, Christer Holmberg = wrote: > What started this whole discussion was the submission of Andrew's = draft, which is not about GRUUs as such, eventhough the draft does = mention GRUUs getting overwritten.=20 >=20 > The main issue raised in the draft is SBCs re-writing the contact, but = not other parameters (e.g Target-Dialog, Replaces, Refer-To URI, etc), = and that out-of-dialog requested addressed using those other parameters = won't reach the UA. >=20 You make it sound like replacing the Contact is a bug or bad idea - it = isn't, it's what an SBC *should* do. It's what P-CSCF's should have done = from the beginning too, for that matter. It's what makes things actually = *work*. If an SBC doesn't also replace the other headers, that's a = bug/bad-idea. But that wasn't what Andrew's draft said... or at least that's not how I = read it. His gripe with a B2BUA replacing the Contact is you lose what the = far-end UAC's capabilities were. But again, that too is not a bug/bad-idea, it's what a B2BUA *should* = do. Having a B2BUA blindly pass-along UAC capabilities without knowing = if the B2BUA itself supports them is just asking for things to break = badly. The downside is it means you have to either upgrade B2BUAs to = support new features, or configure them to pass the feature caps that = you know will work through them. That's the price you pay for using = B2BUAs instead of real Proxies. (and let's not pretend a P-CSCF is a = real Proxy) It's a price many are willing to pay, to make phone calls actually work. = And arguably it's what they should want to happen, because most = operators of SIP domains want to test new features first, before it's = used by endpoints, to make sure it will work between everyone and they = don't get inundated with support calls for things not working. They = don't want a change in UA behavior until they're sure they can handle = it. -hadriel From nobody Sat Mar 15 02:11:41 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCC21A00A6 for ; Sat, 15 Mar 2014 02:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W9gnklIfpXg for ; Sat, 15 Mar 2014 02:11:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5139E1A00B4 for ; Sat, 15 Mar 2014 02:11:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-30-5324193bf837 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0D.DA.10875.B3914235; Sat, 15 Mar 2014 10:11:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Sat, 15 Mar 2014 10:11:22 +0100 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkI9QG2qJsn0h02GuGTGefBK+5rd+86AgAAPFICAAQH2AIAAP9oAgAGOkYCAACEGgIAAF95egAAvgoCAAJsn8g== Date: Sat, 15 Mar 2014 09:11:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D229C3C@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu>, <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se>, <0956401D-93D6-4253-B05E-8898A36112C5@oracle.com> In-Reply-To: <0956401D-93D6-4253-B05E-8898A36112C5@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja61pEqwwdOdYhZLJy1gtfi06ROz xYoNB1gdmD3+vv/A5LFkyU8mj49Pb7EEMEdx2aSk5mSWpRbp2yVwZcyewV2wm6ti/fYWpgbG WRxdjBwcEgImEr23lboYOYFMMYkL99azdTFycQgJHGKUeNX3iwXCWcIo8eN6GztIA5uAhUT3 P20QU0RAT+LoPU6QXmaBYIkNZ6awgtjCAtES3csmMoPYIgIxEu8XNzJC2FkSD94cYwKxWQRU JdZ8nQIW5xXwleievZQZYtVVZolzS/6xgMznFLCTmL2/EKSGEei276fWMEHsEpe49WQ+E8TN AhJL9pxnhrBFJV4+/scKYStKfHy1jxGiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPYLCRj ZyFpmYWkZRaSlgWMLKsY2XMTM3PSyw03MQIj5uCW37o7GE+dEznEKM3BoiTO++Gtc5CQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGRuvcppbF2mzV4kfk19/mYppdt2P7C3axK0Efr8x8l6BW fTH8wyTZLRUH076+y92u2en+I1IlSnnSv3cxPCwXd6+7rSR1cK6I4Z7En78+zligtrpkz0EP kwexxz/O6l0SxZ8wvSVUa96R6tpH368pam79sOlzbsT8uTxm/gyTmpznHlgTyM58YbUSS3FG oqEWc1FxIgCJXwxDZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/GkaIF9n_TVWRGGNPK1RGClXoBZs Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 09:11:38 -0000 Hi, >> What started this whole discussion was the submission of Andrew's draft,= which is not about GRUUs as such, eventhough the draft does mention GRUUs = getting overwritten. >> >> The main issue raised in the draft is SBCs re-writing the contact, but n= ot other parameters (e.g Target-Dialog, Replaces, Refer-To URI, etc), and t= hat out-of-dialog requested addressed using those other parameters won't re= ach the UA. >> > > > > You make it sound like replacing the Contact is a bug or bad idea=20 Not me - the draft. I probably agree with most things you say :) I simply clarified what the draft talks about. > - it isn't, it's what an SBC *should* do. It's what P-CSCF's should have = done from the beginning too, for that matter. It's what makes things actual= ly *work*. If an SBC doesn't also replace the other headers, that's a bug/b= ad-idea. Exactly. > But that wasn't what Andrew's draft said... or at least that's not how I = read it. > > His gripe with a B2BUA replacing the Contact is you lose what the far-end= UAC's capabilities were. That is another issue in the draft, yes. The draft claims that it is problematic if the capabilities point to the UA= , but the contact to the SBC, but the draft doesn't say why that is problem= atic. Regards, Christer From nobody Sun Mar 16 14:44:26 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03201A0320 for ; Sun, 16 Mar 2014 14:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfqnMG6mo-Ps for ; Sun, 16 Mar 2014 14:44:21 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by ietfa.amsl.com (Postfix) with ESMTP id EC60C1A0139 for ; Sun, 16 Mar 2014 14:44:20 -0700 (PDT) Received: from [50.184.77.69] (port=56325 helo=[192.168.1.24]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WPIqn-0004iJ-N5; Sun, 16 Mar 2014 16:44:09 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Shida Schubert In-Reply-To: <53234C1B.3020308@alum.mit.edu> Date: Sun, 16 Mar 2014 14:44:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.184.77.69 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.24]) [50.184.77.69]:56325 X-Source-Auth: shida+agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/NHIqzZ7W9K-mu9vUNKWE3PCWeJo Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:44:25 -0000 All; Let me clarify one point as a co-author of H-Ibis.=20 >=20 > You heard Christer. They have a policy of updating to the latest = updates to the drafts they reference. Also, they need the new H-I, and = it references 6665. >=20 H-I doesn't require RFC6665, it's the RFC6910 (BLISS-Call-Completion) = that references=20 RFC6665. At the point of publication it used to reference RFC3265 but as = new shiny=20 car replaced the old one, it was requested to reference the new guy. = Thus an issue=20 is arising at 3gpp.=20 Shida= From nobody Sun Mar 16 15:15:26 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAC31A0323 for ; Sun, 16 Mar 2014 15:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb7RP4RPd96y for ; Sun, 16 Mar 2014 15:15:22 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 683501A0324 for ; Sun, 16 Mar 2014 15:15:22 -0700 (PDT) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Mar 2014 18:15:13 -0400 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sun, 16 Mar 2014 18:15:12 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Sun, 16 Mar 2014 18:15:12 -0400 From: Andrew Allen To: "shida@ntt-at.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkJEgyWy7xDnZUSqdAQ6CrWBQ5reT5+AgAAPFICAAQH3AIAAP9oAgAGOkICAA1koAP//xaSm Date: Sun, 16 Mar 2014 22:15:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/eQZ-_nqhXmEQDM8c9EZHZ0mrDmU Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 22:15:24 -0000 I agree with Shida. I mispoke at the microphone at IETF#89 mixing up one 3G= PP IETF dependency with another. Apologies for that. But the fact remains 3GPP is in reality forced to upgrade to the latest ver= sions ultimately as other RFC dependencies will suck in the latest versions= of updated documents. Also 3GPP has a basic principle in the current release under development t= o incorporate the bug fixes found in earlier releases. In my view RFC 6665 = is a collection of fixes from RFC 3265.=20 What we need is to ensure that RFC 6665 mechanisms stiill work even when SB= Cs are in the way. Andrew ----- Original Message ----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Sunday, March 16, 2014 05:44 PM Eastern Standard Time=0A= To: Paul Kyzivat Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dia= log-request-00 All; Let me clarify one point as a co-author of H-Ibis.=20 >=20 > You heard Christer. They have a policy of updating to the latest updates = to the drafts they reference. Also, they need the new H-I, and it reference= s 6665. >=20 H-I doesn't require RFC6665, it's the RFC6910 (BLISS-Call-Completion) that= references=20 RFC6665. At the point of publication it used to reference RFC3265 but as ne= w shiny=20 car replaced the old one, it was requested to reference the new guy. Thus a= n issue=20 is arising at 3gpp.=20 Shida _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Mar 16 15:48:04 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B301A01E8 for ; Sun, 16 Mar 2014 15:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O9GQPJN9mv2 for ; Sun, 16 Mar 2014 15:48:01 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 70A561A0321 for ; Sun, 16 Mar 2014 15:48:01 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2GMlWRb021413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Mar 2014 22:47:33 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2GMlUxc028425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 16 Mar 2014 22:47:31 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2GMlU30028420; Sun, 16 Mar 2014 22:47:30 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Mar 2014 15:47:30 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: Date: Sun, 16 Mar 2014 18:47:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BC10C88-4550-4742-8801-E096D2D5F46B@oracle.com> References: To: Andrew Allen X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/oO2bPZINFtvCkwP__gg1piQ9Wyo Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 22:48:03 -0000 On Mar 16, 2014, at 6:15 PM, Andrew Allen wrote: > What we need is to ensure that RFC 6665 mechanisms stiill work even = when SBCs are in the way. I think you mean B2BUAs in general. But anyway it will work, afaict - the B2BUA will use its own Contact, = which if not a GRUU would force the UA to assume it's talking to a = pre-6665 device and revert to normal behavior. -hadriel From nobody Sun Mar 16 17:55:17 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70511A0339 for ; Sun, 16 Mar 2014 17:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GSgSTX4cMz4 for ; Sun, 16 Mar 2014 17:55:10 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9F71A032B for ; Sun, 16 Mar 2014 17:55:09 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Mar 2014 20:54:34 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0174.001; Sun, 16 Mar 2014 20:54:33 -0400 From: Andrew Allen To: "hadriel.kaplan@oracle.com" Thread-Topic: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPPkJEgyWy7xDnZUSqdAQ6CrWBQ5reT5+AgAAPFICAAQH3AIAAP9oAgAGOkICAA1koAP//xaSmgABMEwD//+Bz8g== Date: Mon, 17 Mar 2014 00:54:33 +0000 Message-ID: In-Reply-To: <0BC10C88-4550-4742-8801-E096D2D5F46B@oracle.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/3EtKf7SlWq33kwOWUjMlG2oKPpw Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 00:55:14 -0000 Which totally defeats the main reason for RFC 6665! In addition as I state in my draft modifying the Contact header field means= either the media feature tags of the remote UA are lost or the B2BUA is sa= ying if you send a request to this address (including potentially after thi= s session has ended) you can expect that this feature is supported. Having B2BUAs only include feature tags they understand to my view means no= innovation and no new services. B2BUAs have then become the switches of ol= d needing all to be updated or reconfigured to support any new services. Andrew=20 ----- Original Message ----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Sunday, March 16, 2014 06:47 PM Eastern Standard Time=0A= To: Andrew Allen Cc: shida@ntt-at.com ; pkyzivat@alum.mit.edu ; dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dia= log-request-00 On Mar 16, 2014, at 6:15 PM, Andrew Allen wrote: > What we need is to ensure that RFC 6665 mechanisms stiill work even when = SBCs are in the way. I think you mean B2BUAs in general. But anyway it will work, afaict - the B2BUA will use its own Contact, which= if not a GRUU would force the UA to assume it's talking to a pre-6665 devi= ce and revert to normal behavior. -hadriel From nobody Mon Mar 17 00:18:31 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265101A0124 for ; Mon, 17 Mar 2014 00:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAjMNICCeAnX for ; Mon, 17 Mar 2014 00:18:27 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id AF8DA1A006E for ; Mon, 17 Mar 2014 00:18:26 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 1F9ED93C2A2; Mon, 17 Mar 2014 07:18:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 17 Mar 2014 08:18:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <11DC8AC3-8F97-464A-8A2D-3916FA7EC428@edvina.net> References: To: Andrew Allen X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/M58s00m3CSg1iPOso__9Rx9Az1c Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 07:18:30 -0000 On 17 Mar 2014, at 01:54, Andrew Allen wrote: >=20 > Which totally defeats the main reason for RFC 6665! >=20 > In addition as I state in my draft modifying the Contact header field = means either the media feature tags of the remote UA are lost or the = B2BUA is saying if you send a request to this address (including = potentially after this session has ended) you can expect that this = feature is supported. >=20 > Having B2BUAs only include feature tags they understand to my view = means no innovation and no new services. B2BUAs have then become the = switches of old needing all to be updated or reconfigured to support any = new services. Yes, that's Asterisk in a nutshell.=20 /O >=20 > Andrew=20 >=20 > ----- Original Message ----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Sunday, March 16, 2014 06:47 PM Eastern Standard Time > To: Andrew Allen > Cc: shida@ntt-at.com ; pkyzivat@alum.mit.edu = ; dispatch@ietf.org > Subject: Re: [dispatch] Comments on = draft-allen-dispatch-routing-out-of-dialog-request-00 >=20 >=20 > On Mar 16, 2014, at 6:15 PM, Andrew Allen = wrote: >=20 >> What we need is to ensure that RFC 6665 mechanisms stiill work even = when SBCs are in the way. >=20 > I think you mean B2BUAs in general. >=20 > But anyway it will work, afaict - the B2BUA will use its own Contact, = which if not a GRUU would force the UA to assume it's talking to a = pre-6665 device and revert to normal behavior. >=20 > -hadriel >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Mar 17 07:16:26 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1701A017E for ; Mon, 17 Mar 2014 07:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO3mrlN-j-Xt for ; Mon, 17 Mar 2014 07:16:24 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1009E1A036E for ; Mon, 17 Mar 2014 07:16:24 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2HEGCsG000597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Mar 2014 14:16:13 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2HEGBEE024450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2014 14:16:12 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2HEGBUL012147; Mon, 17 Mar 2014 14:16:11 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Mar 2014 07:16:11 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 17 Mar 2014 10:16:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F8BCA35-A22D-4911-8C2A-0433727E14FE@oracle.com> References: To: Andrew Allen X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Tov3p_EP7v3sITtLDlsoMh5XmhE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:16:25 -0000 On Mar 16, 2014, at 8:54 PM, Andrew Allen wrote: > Which totally defeats the main reason for RFC 6665! Which would be...? What great feature does IMS get from it, exactly? > In addition as I state in my draft modifying the Contact header field = means either the media feature tags of the remote UA are lost or the = B2BUA is saying if you send a request to this address (including = potentially after this session has ended) you can expect that this = feature is supported. > Having B2BUAs only include feature tags they understand to my view = means no innovation and no new services. B2BUAs have then become the = switches of old needing all to be updated or reconfigured to support any = new services. Yup, and that's exactly the right thing to happen. It's what most IMS = operators actually should *want* to happen as well. See here: http://www.ietf.org/mail-archive/web/dispatch/current/msg05432.html It's really not a bad thing to want service stability. -hadriel From nobody Mon Mar 17 07:22:01 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C361A0409 for ; Mon, 17 Mar 2014 07:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sz_03LuwY0D for ; Mon, 17 Mar 2014 07:21:58 -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 7F6AB1A03F5 for ; Mon, 17 Mar 2014 07:21:58 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id eckP1n0011HzFnQ54eMqqM; Mon, 17 Mar 2014 14:21:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id eeMp1n0183ZTu2S3aeMqCA; Mon, 17 Mar 2014 14:21:50 +0000 Message-ID: <532704FD.1030603@alum.mit.edu> Date: Mon, 17 Mar 2014 10:21:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Hadriel Kaplan , Christer Holmberg References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu>, <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se> <0956401D-93D6-4253-B05E-8898A36112C5@oracle.com> In-Reply-To: <0956401D-93D6-4253-B05E-8898A36112C5@oracle.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=q20140121; t=1395066110; bh=X/0wuE6NkCQqyOqEKFTv6QL7TK4kWfWfdBL2iqT5YSM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dHM88y53nG/hLThq+19kf7LyTgeA+/6RMaH/kHwkjfZpJxZjwtw1uDUnF+Mdv7NYc 8en7JGgc5WhJChcxRXH7Qog0x3+YcFkNRZ5WJvYwXRZhXYdl20Zsom22JhZSE9CNnq iDuZUe2DYl7DVoOV/3UFKfwxWS0Sqcu7xMDUO7ugJKUKUBYIpqmtFc9A81whxgXgXR yWaph+vdEye1syrBjblpuTMX+IcInL2evwnfmAPXyFZEsPbWWeEc7GPHbE0/r7inws IiG/4uJHhvdwbKeTIU1e4tXuffOIg5yFCIpHQsidTuTttC7pRx4gYI1UqqlTVKUbKS fPovnNovelFFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/pzhkSkiDQzJYUVaGjdWBZLG-Mmc Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:22:00 -0000 I actually agree with much of what you say!!! On 3/14/14 8:49 PM, Hadriel Kaplan wrote: > > On Mar 14, 2014, at 5:10 PM, Christer Holmberg wrote: > >> What started this whole discussion was the submission of Andrew's draft, which is not about GRUUs as such, eventhough the draft does mention GRUUs getting overwritten. >> >> The main issue raised in the draft is SBCs re-writing the contact, but not other parameters (e.g Target-Dialog, Replaces, Refer-To URI, etc), and that out-of-dialog requested addressed using those other parameters won't reach the UA. >> > > > > You make it sound like replacing the Contact is a bug or bad idea - it isn't, it's what an SBC *should* do. It's what P-CSCF's should have done from the beginning too, for that matter. It's what makes things actually *work*. If an SBC doesn't also replace the other headers, that's a bug/bad-idea. I agree. If it doesn't include its own contact, then as I understand things it shouldn't be considered a UA/B2BUA. Rather it is just a misbehaving proxy. > But that wasn't what Andrew's draft said... or at least that's not how I read it. > > His gripe with a B2BUA replacing the Contact is you lose what the far-end UAC's capabilities were. > > But again, that too is not a bug/bad-idea, it's what a B2BUA *should* do. Having a B2BUA blindly pass-along UAC capabilities without knowing if the B2BUA itself supports them is just asking for things to break badly. I agree here too. > The downside is it means you have to either upgrade B2BUAs to support new features, or configure them to pass the feature caps that you know will work through them. That's the price you pay for using B2BUAs instead of real Proxies. (and let's not pretend a P-CSCF is a real Proxy) > It's a price many are willing to pay, to make phone calls actually work. And arguably it's what they should want to happen, because most operators of SIP domains want to test new features first, before it's used by endpoints, to make sure it will work between everyone and they don't get inundated with support calls for things not working. They don't want a change in UA behavior until they're sure they can handle it. This is the motivation for the e2e principle, and one of the key things that made the Internet a success compared to many other networking approaches. SIP *could* have been made to work without this. We could argue about why it didn't shake out that way. (But there really isn't any point in doing so.) We see the pain that results from abandoning the e2e principle. Still, it would be ok if there was a commitment to updating all those B2BUAs when they are found to break things, to eliminate the breakage. That means properly replicating all the features, such as making GRUUs and out of dialog requests work. ISTM the problem is that such updating isn't happening. Instead, those deploying such intermediaries seem to expect the endpoints to work around their foibles. Thanks, Paul > > > -hadriel > > From nobody Mon Mar 17 08:56:36 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E8B1A01BE; Mon, 17 Mar 2014 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIBWuykT44X1; Mon, 17 Mar 2014 08:56:31 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 71BCB1A0427; Mon, 17 Mar 2014 08:56:30 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so4825975wgh.35 for ; Mon, 17 Mar 2014 08:56:22 -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=dxDhWX+nTHBcx3viYU82BVQdga0GnekkY3jtjVcx6ws=; b=mRd1X8sv9X0TTMaa0kn+OAt1ghCpr0G5e8DsLptzaHlcdKUDC7clCvOuJg/GyaNllL Be0ENST/3glckVTXFSAsT2aqrDW0T1PeeXW6xyi493XxNx7TCKNnbpTwoRPoPRC/p9TR YHrNLVX2KfTS9/fbaLpBFKUmEWbxNU9tlTQ/SW4I9jNFClzswoQ+KR/P/leO1TPqO1Ea i8b1X1uiF3O7/17Ogc6CiW1hzUrynoSWUy1GPzf3HGGAr3MLB99SBxmYZNsLl0olC2xQ ROC4I741THMVBhc65lvc/dLuybL6ZzvANJCChAxqZ4OZvRwfPkFryLmhOcnGhZMLbVo3 RsQw== MIME-Version: 1.0 X-Received: by 10.180.20.176 with SMTP id o16mr10244450wie.7.1395071782079; Mon, 17 Mar 2014 08:56:22 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Mon, 17 Mar 2014 08:56:22 -0700 (PDT) Date: Mon, 17 Mar 2014 10:56:22 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53f35f501d2c604f4cf76ff Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/cbVUl_PQZBCubYgz_tPkYpNCQw4 Cc: DISPATCH , SIPCORE Subject: [dispatch] Passing of Francois Audet X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:56:33 -0000 --bcaec53f35f501d2c604f4cf76ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A number of you all will remember Francois Audet, who was a colleague of mine at Nortel and a regular IETF attendee (until he went to Skype ;) He was a co-author on the recently published 4244bis drafts. He unfortunately lost his battle with cancer on Friday. I have received the following information from a family friend via Facebook: Thanks for all your support messages, both on & offline. I've talked to Genevi=E8ve over the week-end, and she reminded me that ther= e is just no real treatment of Brain Tumors, and that form of cancer is growing at some alarming rate. She agreed that the best support message would be to sponsor the research, for which donations can be made as a memorial gift for Francois Audet. I've selected a few organizations: - Stanford Brain Tumor Center (http://medicalgiving.stanford.edu/, this is where Fran=E7ois was treated. Make sure to indicate the Brain Tumor Center = as the recipient). - UCSF Brain Tumor Center ( https://makeagift.ucsf.edu/site/SPageServer?pagename=3DA1_API_GordonMurrayG= ivingForm&ACode=3DB2934 ) - National Brain Tumor Society (http://www.braintumor.org/) Note that he also left behind a son, Olivier. That's all the information I have at this point. Regards, Mary. --bcaec53f35f501d2c604f4cf76ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A number of you all will remember Francois Audet, who was = a colleague of mine at Nortel and a regular IETF attendee (until he went to= Skype ;) =A0He was a co-author on the recently published 4244bis drafts. = =A0He unfortunately lost his battle with cancer on Friday. =A0I have receiv= ed the following information from a family friend via Facebook:

Thanks for all your support messages, both on & off= line.
I've talked to Genevi=E8ve over the week-end, and she r= eminded me that there is just no real treatment of Brain Tumors, and that f= orm of cancer is growing at some alarming rate.
She agreed that the best support message would be to sponsor the resea= rch, for which donations can be made as a memorial gift for Francois Audet.=
I've selected a few organizations:
- Stanford Brai= n Tumor Center (http://medic= algiving.stanford.edu/, this is where Fran=E7ois was treated. Make sure= to indicate the Brain Tumor Center as the recipient).
- National Brain Tumor Society (http://www.braintumor.org/)

Note that h= e also left behind a son, Olivier.=A0

That's a= ll the information I have at this point.=A0

Regards,
Mary.
--bcaec53f35f501d2c604f4cf76ff-- From nobody Mon Mar 17 11:01:10 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7181A045B; Mon, 17 Mar 2014 10:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3APE5dMeHQPU; Mon, 17 Mar 2014 10:40:08 -0700 (PDT) Received: from ukel19pa21.eemsg.mail.mil (ukel19pa21.eemsg.mail.mil [214.24.22.89]) by ietfa.amsl.com (Postfix) with ESMTP id 44B2D1A044C; Mon, 17 Mar 2014 10:40:07 -0700 (PDT) X-EEMSG-Attachment-filename: smime.p7s Received: from edge-cols.mail.mil ([131.64.100.13]) by ukel19pa21.eemsg.mail.mil with ESMTP; 17 Mar 2014 17:39:58 +0000 Received: from UCOLHP3M.easf.csd.disa.mil (131.64.100.152) by edge-cols.mail.mil (131.64.100.13) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 17 Mar 2014 17:39:58 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.200]) by UCOLHP3M.easf.csd.disa.mil ([131.64.100.152]) with mapi id 14.03.0174.001; Mon, 17 Mar 2014 17:39:57 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Mary Barnes , "rai@ietf.org" Thread-Topic: [sipcore] Passing of Francois Audet (UNCLASSIFIED) Thread-Index: AQHPQfl9rgjNnFJblkm0fVDvrCcaUJrlia6g Date: Mon, 17 Mar 2014 17:39:57 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF55B35D3B@ucolhp9b.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.201.79] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001D_01CF41E6.5F9B98F0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/eDB5GtcXSSkfaZ_0w_ZRTwhS4eU X-Mailman-Approved-At: Mon, 17 Mar 2014 11:01:08 -0700 Cc: DISPATCH , SIPCORE Subject: Re: [dispatch] [sipcore] Passing of Francois Audet (UNCLASSIFIED) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:40:11 -0000 ------=_NextPart_000_001D_01CF41E6.5F9B98F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED Caveats: NONE Hi, Marry and all: My heartfelt prayer to God for resting his soul in Heaven! My heartfelt sympathy to his son Oliver and family as we all is a part of this = eternal cycle! I would know him since the mid-1990s while he used to participate in ATM Forum and a liaison to the ITU-T H.323 WG. His crystal clear voice and technical explanations has kept amazing me and all others since his last breath! Best regards, Radhika -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Monday, March 17, 2014 11:56 AM To: rai@ietf.org Cc: DISPATCH; SIPCORE Subject: [sipcore] Passing of Francois Audet A number of you all will remember Francois Audet, who was a colleague of mine at Nortel and a regular IETF attendee (until he went to Skype ;) = He was a co-author on the recently published 4244bis drafts. He = unfortunately lost his battle with cancer on Friday. I have received the following information from a family friend via Facebook: Thanks for all your support messages, both on & offline. I've talked to Genevi=E8ve over the week-end, and she reminded me that = there is just no real treatment of Brain Tumors, and that form of cancer is growing at some alarming rate. She agreed that the best support message would be to sponsor the = research, for which donations can be made as a memorial gift for Francois Audet. I've selected a few organizations: - Stanford Brain Tumor Center (http://medicalgiving.stanford.edu/, this = is where Fran=E7ois was treated. Make sure to indicate the Brain Tumor = Center as the recipient). - UCSF Brain Tumor Center (https://makeagift.ucsf.edu/site/SPageServer?pagename=3DA1_API_GordonMurr= ayGiv ingForm&ACode=3DB2934) - National Brain Tumor Society (http://www.braintumor.org/) Note that he also left behind a son, Olivier.=20 That's all the information I have at this point.=20 Regards, Mary. Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_001D_01CF41E6.5F9B98F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDAzMTcxNzM5NTFaMCMGCSqGSIb3DQEJBDEWBBTFVTtEfzO2kl2UKeJWiZ3l KbjICjBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBABHDtBxVZFPC375ZKXUYAX3d4ipdlPqouA7qyjLVxSUFEbo+pE4+F+Olq3z0f/q74Xbd +QjBrqm7S3AZXUmXLaMOfMMi0D57yZqp5S8GTckANbyrjVbMJstBR5w+zh5vP7OeYrXHm1+dBoFR 4yyUdJFKlHDhBCO4KfY/sQ4cxJqAp/TqvOUi73VThLAQ3lXWVdkejmJzL0QDMjxNYkhY9DxK1IjL KnQpRNue5vPhclH+MJ4PRzZTZb2F7/Rr/cJSleXX2AguQFlLtigacLSAAZVyH2NY2pd/lsPua7s+ ChSs5/y883O+MRyhX+QbvCuFKuNkfjkYYexqFB3aWGgPw8wAAAAAAAA= ------=_NextPart_000_001D_01CF41E6.5F9B98F0-- From nobody Tue Mar 18 11:55:25 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F3E1A0455; Tue, 18 Mar 2014 11:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq0pHSNiTaiU; Tue, 18 Mar 2014 11:55:20 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EF75F1A040E; Tue, 18 Mar 2014 11:55:19 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so7754508iec.29 for ; Tue, 18 Mar 2014 11:55:11 -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=Vsh4R66xnTXYwiaxXjlQCYDFYbJycZQ8BDJobYZAQxU=; b=s04BGDzN6dqE9osQNyf+fWwSrWlGehVI3XttoMTNRST9vHMCsEzwf3A9wJPscMkowc u/iPt/tTGM3zXY75EcuemR1T2tZ/9yD6kDJae6DKt+nhl+j1YgsOKLGbfdWl3ZEtZGaH b9LHx7sRXpAdaA9gWosdRxpqt7PaL8/00o92gAXEO/vlkTsyEu3vp2iawa6nybQKrQkO l2hxEMvyG5HhGyzcF2J3Vv6X3HVmvY0dfxzSLg9sXml6cic7Y/g9M+sK3uF1mKDKtOIV RoiOB2GWC7vXDhh2kipObNPTL+jVY8QUpq3lT1Cfgjyg5m4IqDLbHovikwNqy0tyDKTS 3ulw== X-Received: by 10.42.61.4 with SMTP id s4mr3201464ich.58.1395168911013; Tue, 18 Mar 2014 11:55:11 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-145-184.tor.primus.ca. [173.206.145.184]) by mx.google.com with ESMTPSA id an1sm28567628igc.0.2014.03.18.11.54.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 11:54:54 -0700 (PDT) Message-ID: <5328967B.9020104@gmail.com> Date: Tue, 18 Mar 2014 14:54:51 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rai@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/QgZLXLIuM_MV-KCP7H-M3kB55G0 Cc: DISPATCH , SIPCORE Subject: Re: [dispatch] Passing of Francois Audet X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 18:55:21 -0000 I'm really sorry to hear this. I worked with Francois on H.323 in particular, he representing the enterprise side and I the carrier side of the business. I was aware of his previous work with the ATM Forum, and of course, we both turned to SIP eventually. Beyond being a pleasure to work with, Francois was probably one of the most competent standards representatives I've ever known. I'm sure he brought the same competence and focus to his PLM job at Skype, however long that lasted given his illness. My condolences to his present friends and family. Tom Taylor On 17/03/2014 11:56 AM, Mary Barnes wrote: > A number of you all will remember Francois Audet, who was a colleague of > mine at Nortel and a regular IETF attendee (until he went to Skype ;) He > was a co-author on the recently published 4244bis drafts. He unfortunately > lost his battle with cancer on Friday. I have received the following > information from a family friend via Facebook: ... From nobody Wed Mar 19 14:43:21 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844C61A078A for ; Wed, 19 Mar 2014 14:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNCQ2U5FdaIw for ; Wed, 19 Mar 2014 14:43:17 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id B43651A0724 for ; Wed, 19 Mar 2014 14:43:16 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id fWGL1n0060EZKEL59Zj7Tk; Wed, 19 Mar 2014 21:43:07 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta01.westchester.pa.mail.comcast.net with comcast id fZj71n00R1KKtkw3MZj78J; Wed, 19 Mar 2014 21:43:07 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2JLh72L012886 for ; Wed, 19 Mar 2014 17:43:07 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2JLh6FF012885; Wed, 19 Mar 2014 17:43:06 -0400 Date: Wed, 19 Mar 2014 17:43:06 -0400 Message-Id: <201403192143.s2JLh6FF012885@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <532704FD.1030603@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu>, <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se> <0956401D-93D6-4253-B05E-8898A36112C5@oracle.com> <532704FD.1030603@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395265387; bh=vxjY/hcaetYcPyt5hk1oSd5rUn+3B/kF5X2fFlsXZAw=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=lQ0VFXx7uR3/z3QkNbVyuwWkCXaf1H48XfjRynfUpZI1WyNUngZRH7UQ0kFIhHNxu CDjxrTDnND6+53LNO6TfpQ163/AgZRfQw+osbfqFFLmpyMjg2nhUT+Qo0s9jXrPT45 E4YpuDX43ot7VODLigIycBdwWKHI9+cF/7f+jSVkMLH4YgZYzLEi6CKsXRjJhmDk7z eNUVrAvf+1/cU/i0ZMev6cIHljzt4cEkbWOTAIzqw2n6voZSnugOiidgIalLDEq5VP IgldFZmhTKRLqVhiWc26SnuYXz9cuHeOanLIuzpxRGcGkFlXp9t6zTY1dFboFPo2Su 3aZ7GQLUL+2WA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ZPKgxTPjvxISvl1u0ZCHOPqLWZg Subject: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 21:43:18 -0000 I move that we move the consideration of draft-allen-dispatch-routing-out-of-dialog-request-00 (and draft-kaplan-dispatch-gruu-problematic-00 as well) to the Sipcore working group. This will allow us to move the surrounding discussion to the Sipcore mailing list, which is the technically correct place to have it (since this is all about *getting your request to where it is going*). We need to properly consider these drafts in relationship to the practical problems that have been described. It is clear that there is not yet a consensus on solutions, or the essential nature of the observed problems. And at least in my mind, we haven't even clearly identified the crucial specifics of typical failure cases -- the discussion has been carried out at a level of generality that (IMHO) may mask diversity in the nature of the failure cases. "Pure SIP" usages as envisioned by the early RFCs differ significantly from a large part of deployed usage. A good solution to these problems needs to be aware of this, and will accommodate both correctly, as well as *ensuring that the two interoperate correctly*. The proper nature of the outcome can only be determined by further discussion. The existing drafts may be turned into RFCs describing new mechanisms. Alternatively, they may be revised into some sort of Best Current Practices, or Poor Practices to be Avoided. Perhaps it will be determined that present practices are sufficient. All in favor? Dale From nobody Thu Mar 20 09:25:12 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5241A08E6 for ; Thu, 20 Mar 2014 09:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV46MZ0gHFTB for ; Thu, 20 Mar 2014 09:25:10 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id A50411A08D0 for ; Thu, 20 Mar 2014 09:25:02 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta06.westchester.pa.mail.comcast.net with comcast id fp4U1n0041ei1Bg56sQtPa; Thu, 20 Mar 2014 16:24:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id fsQt1n00U3ZTu2S3ksQtqs; Thu, 20 Mar 2014 16:24:53 +0000 Message-ID: <532B1655.2050002@alum.mit.edu> Date: Thu, 20 Mar 2014 12:24:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu>, <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se> <0956401D-93D6-4253-B05E-8898A36112C5@oracle.com> <532704FD.1030603@alum.mit.edu> <201403192143.s2JLh6FF012885@hobgoblin.ariadne.com> In-Reply-To: <201403192143.s2JLh6FF012885@hobgoblin.ariadne.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=q20140121; t=1395332693; bh=i594PFtWBtRmQkuBcYJkRIrNEKlZTyNxYWg/lIpshNY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=v5NDO+vtMq/hvnPDQgqIeLZDHKKtjpbJrPrESxJ18DM6OhqO9KN7d9DFKfiepJ4nB l05LcSjtzJTmlabkab8iX2/OcoLcKONHTL0ANmHP3A6zXsYcWx5RC92CRbstp72ZPn i4O07Wyi0jyKPmjnT+ZwpTR1gocU8t4b9EpDZxgX0a3nyXJpjxDExMjB0j77MznSG6 ruZI7QMy2DG6imtw7JFYC2zdMAfqFFRFseoltl7SsZHXYVT9q2rtm5hngxNUeHryvk ktPRbApAVjwjyAkUhTNN91ygTHmNqxtfXzDflJ+YoeYcZWTjy528bb/BNQrPnHBjH+ 5PzFphpgkCpyQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/eDlfOUJDmtCVlqqRrAO6ncc-I5s Subject: Re: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 16:25:11 -0000 Speaking as sipcore co-chair: I agree that the sipcore mailing list is the appropriate place to have this discussion. (The issue is clearly a fundamental issue with SIP.) At this point it is indeed just *discussion*. There has been no decision that there is need to define a deliverable regarding this. Discussion might lead to such a decision. In all likelihood, if we were to decide to do that it would fall within the scope of sipcore. But we can defer that decision, and if there is question we can then defer to dispatch. Thanks, Paul On 3/19/14 5:43 PM, Dale R. Worley wrote: > I move that we move the consideration of > draft-allen-dispatch-routing-out-of-dialog-request-00 (and > draft-kaplan-dispatch-gruu-problematic-00 as well) to the Sipcore > working group. This will allow us to move the surrounding discussion > to the Sipcore mailing list, which is the technically correct place to > have it (since this is all about *getting your request to where it is > going*). > > We need to properly consider these drafts in relationship to the > practical problems that have been described. It is clear that there > is not yet a consensus on solutions, or the essential nature of the > observed problems. And at least in my mind, we haven't even clearly > identified the crucial specifics of typical failure cases -- the > discussion has been carried out at a level of generality that (IMHO) > may mask diversity in the nature of the failure cases. > > "Pure SIP" usages as envisioned by the early RFCs differ significantly > from a large part of deployed usage. A good solution to these > problems needs to be aware of this, and will accommodate both > correctly, as well as *ensuring that the two interoperate correctly*. > > The proper nature of the outcome can only be determined by further > discussion. The existing drafts may be turned into RFCs describing > new mechanisms. Alternatively, they may be revised into some sort of > Best Current Practices, or Poor Practices to be Avoided. Perhaps it > will be determined that present practices are sufficient. > > All in favor? > > Dale > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Mar 20 10:48:39 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046681A0700; Thu, 20 Mar 2014 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYuqohEwKX9p; Thu, 20 Mar 2014 10:48:30 -0700 (PDT) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5A52A1A0790; Thu, 20 Mar 2014 10:48:30 -0700 (PDT) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2KHl5Di080514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 20 Mar 2014 12:47:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88] claimed to be unnumerable.local Message-ID: <532B299C.3070909@nostrum.com> Date: Thu, 20 Mar 2014 12:47:08 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org, mmusic@ietf.org, rtcweb@ietf.org, avt@ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/a8VCc-tLhU4KV0i5mEFJ6ua7jPY Subject: [dispatch] Registration for SIPit 31 is open X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rai@ietf.org List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:48:32 -0000 (Please forgive the crosspost, and reply only to the rai list): Please see From nobody Thu Mar 20 12:04:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763771A042C for ; Thu, 20 Mar 2014 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5kSGG4E9WaU for ; Thu, 20 Mar 2014 12:04:28 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFD91A0410 for ; Thu, 20 Mar 2014 12:04:28 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-ed-532b3bb29f7a Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.EB.04249.2BB3B235; Thu, 20 Mar 2014 20:04:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Thu, 20 Mar 2014 20:04:17 +0100 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-00 Thread-Index: AQHPQ7w7p3/NmkI/rEa3PKXegoNC/ZrqGZyAgAA9DJo= Date: Thu, 20 Mar 2014 19:04:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D25660B@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu>, <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se> <0956401D-93D6-4253-B05E-8898A36112C5@oracle.com> <532704FD.1030603@alum.mit.edu> <201403192143.s2JLh6FF012885@hobgoblin.ariadne.com>, <532B1655.2050002@alum.mit.edu> In-Reply-To: <532B1655.2050002@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje4ma+1ggx+NuhZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx+9cS9oID4hU/Lk5ma2DsEu5i5OSQEDCR +PH1PyOELSZx4d56ti5GLg4hgSOMEusONTBBOEsYJW4s/sXcxcjBwSZgIdH9TxukQUQgWOLg 4Z0sILawgK/E1K4j7BDxAIm9J+8xQdhWEqvufQRbwCKgKjHn/UmwGl6g+gc9m5kh5l9ikVix 8DvYfE4BHYm9//VBahiBDvp+ag3YHGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQtqLEzrPt zBD1OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXIUZxanJSb bmSwiREYDQe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MHpNem+34dPnZu+7z3o/rTsX7ne6qvWlvsv2zE+Hu5ZK9ldaVVfy5oqek4r68+aTtsWhVXkX 12yWfBH132Tr8k73gsfzMsK8r6qdTAtPX9X42uib+D5XmSJG4x63LxIhW84yc79csia6N4K5 ZNmzIuZGqfaCNVK2fAxsC+9LH2b8mX+i0bhxpxJLcUaioRZzUXEiAGJVReNUAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/zE_KEVaPfaEfGUO-QJL7fndee48 Subject: Re: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 19:04:31 -0000 Hi, If the delivery would be an SBC BCP document, I guess it could also be done= in STRAW. But, for now I agree that the discussion should be taken to SIPCORE, and th= en we'll figure out what (if anything) needs to be done. Regards, Christer ________________________________________ From: dispatch [dispatch-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzi= vat@alum.mit.edu] Sent: Thursday, 20 March 2014 6:24 PM To: dispatch@ietf.org Subject: Re: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-= 00 Speaking as sipcore co-chair: I agree that the sipcore mailing list is the appropriate place to have this discussion. (The issue is clearly a fundamental issue with SIP.) At this point it is indeed just *discussion*. There has been no decision that there is need to define a deliverable regarding this. Discussion might lead to such a decision. In all likelihood, if we were to decide to do that it would fall within the scope of sipcore. But we can defer that decision, and if there is question we can then defer to dispatch. Thanks, Paul On 3/19/14 5:43 PM, Dale R. Worley wrote: > I move that we move the consideration of > draft-allen-dispatch-routing-out-of-dialog-request-00 (and > draft-kaplan-dispatch-gruu-problematic-00 as well) to the Sipcore > working group. This will allow us to move the surrounding discussion > to the Sipcore mailing list, which is the technically correct place to > have it (since this is all about *getting your request to where it is > going*). > > We need to properly consider these drafts in relationship to the > practical problems that have been described. It is clear that there > is not yet a consensus on solutions, or the essential nature of the > observed problems. And at least in my mind, we haven't even clearly > identified the crucial specifics of typical failure cases -- the > discussion has been carried out at a level of generality that (IMHO) > may mask diversity in the nature of the failure cases. > > "Pure SIP" usages as envisioned by the early RFCs differ significantly > from a large part of deployed usage. A good solution to these > problems needs to be aware of this, and will accommodate both > correctly, as well as *ensuring that the two interoperate correctly*. > > The proper nature of the outcome can only be determined by further > discussion. The existing drafts may be turned into RFCs describing > new mechanisms. Alternatively, they may be revised into some sort of > Best Current Practices, or Poor Practices to be Avoided. Perhaps it > will be determined that present practices are sufficient. > > All in favor? > > Dale > > _______________________________________________ > 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 nobody Tue Mar 25 08:41:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D051A01B1; Tue, 25 Mar 2014 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHDaj3ze_6mF; Tue, 25 Mar 2014 08:41:27 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 017D81A019F; Tue, 25 Mar 2014 08:41:26 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so3556487wib.3 for ; Tue, 25 Mar 2014 08:41:25 -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=//M9RLOYx/v1jPDy/ssGXtOZTUi1Ni/eAedx14SBSaw=; b=wvFXhLPCoB7rq3LwadmBTw042n0u8/qsR4vRhNXoxBM214CD10hshzO2TULe3FzAck /16kQ0plNyDEKW/5grtgV6ZlAKnjyIZLPekcLVhERVSTIPdduc798aMni0mVe4qeHE4u r73KKdkE4fUXqJnCFoAe2XnPkKPn4XYI/G6aGgquwMDXhQzm6/eJvjUi6x8nvBSYp/lk QdV0tcl7vGHke+ofPU3s5npmObpWh+3pnV2ATXiHM6sX9colrY9yw2pUQBwqpYcKFnvT KXDjp//Ghk0wlaFeNr25vcExbgIO5lALDTXrFaFCGVnVL3WPFjnrDgdHSoI6ZSFa+5zA jAWQ== MIME-Version: 1.0 X-Received: by 10.180.20.176 with SMTP id o16mr24063111wie.7.1395762085382; Tue, 25 Mar 2014 08:41:25 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Tue, 25 Mar 2014 08:41:25 -0700 (PDT) Date: Tue, 25 Mar 2014 10:41:25 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53f35f54a501b04f5702fe4 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/XaUpTyDbbP6T5y0p-B-Bf4TqzME Cc: DISPATCH , SIPCORE Subject: [dispatch] Passing of Francois Audet - Additional information X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:41:31 -0000 --bcaec53f35f54a501b04f5702fe4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I have some additional information to share that I thought would be of interest to a number of people. 1) There have been some queries as to specifically how one can help the family directly. A Special Needs Trust has been established for Francois' son, Olivier. This fund will be used to offset the costs of Olivier's treatments that aren't covered by medical insurance or other funding. If you are interested in making a donation to this fund, please contact me directly for further details. 2) The funeral is scheduled as follows: Saturday, April 5 at 14:00 hours, at the funeral Cooperative in the Outaouais, 95 boulevard Cit=E9-des-Jeunes, Gatineau (QC) J8Y 6 X 3 3) If you have any photos of Francois from meetings, etc, can you please forward those to me? I am putting together a scrapbook for Olivier. Also, if you want to include a personal note, please send that. Thanks for all your support, Mary. On Mon, Mar 17, 2014 at 10:56 AM, Mary Barnes w= rote: > A number of you all will remember Francois Audet, who was a colleague of > mine at Nortel and a regular IETF attendee (until he went to Skype ;) He > was a co-author on the recently published 4244bis drafts. He unfortunate= ly > lost his battle with cancer on Friday. I have received the following > information from a family friend via Facebook: > > Thanks for all your support messages, both on & offline. > I've talked to Genevi=E8ve over the week-end, and she reminded me that th= ere > is just no real treatment of Brain Tumors, and that form of cancer is > growing at some alarming rate. > She agreed that the best support message would be to sponsor the research= , > for which donations can be made as a memorial gift for Francois Audet. > I've selected a few organizations: > - Stanford Brain Tumor Center (http://medicalgiving.stanford.edu/, this > is where Fran=E7ois was treated. Make sure to indicate the Brain Tumor Ce= nter > as the recipient). > - UCSF Brain Tumor Center ( > https://makeagift.ucsf.edu/site/SPageServer?pagename=3DA1_API_GordonMurra= yGivingForm&ACode=3DB2934 > ) > - National Brain Tumor Society (http://www.braintumor.org/) > > Note that he also left behind a son, Olivier. > > That's all the information I have at this point. > > Regards, > Mary. > --bcaec53f35f54a501b04f5702fe4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I have some additional informat= ion to share that I thought would be of interest to a number of people.

1) There have been some queries as to specifically ho= w one can help the family directly. =A0A Special Needs Trust has been estab= lished for Francois' son, Olivier. This fund will be used to offset the= costs of Olivier's treatments that aren't covered by medical insur= ance or other funding. =A0If you are interested in making a donation to thi= s fund, please contact me directly for further details.

2) The funeral is scheduled as follows:
Saturd= ay, April 5 at 14:00 hours, at the funeral Cooperative in the Outaouais, 95= boulevard Cit=E9-des-Jeunes, Gatineau (QC) J8Y 6 X 3

3) If you have any photos of Francois from meetin= gs, etc, can you please forward those to me? =A0I am putting together a scr= apbook for Olivier. Also, if you want to include a personal note, please se= nd that. =A0

Thanks for all your support,
Mary.=A0
=A0=A0


= On Mon, Mar 17, 2014 at 10:56 AM, Mary Barnes <mary.ietf.barnes@g= mail.com> wrote:
A number of you all will remember Francois Audet, who was a colleague of mi= ne at Nortel and a regular IETF attendee (until he went to Skype ;) =A0He w= as a co-author on the recently published 4244bis drafts. =A0He unfortunatel= y lost his battle with cancer on Friday. =A0I have received the following i= nformation from a family friend via Facebook:

Thanks for all your support messages, both on & off= line.
I've talked to Genevi=E8ve over the week-end, and she r= eminded me that there is just no real treatment of Brain Tumors, and that f= orm of cancer is growing at some alarming rate.
She agreed that the best support message would be to sponsor the resea= rch, for which donations can be made as a memorial gift for Francois Audet.=
I've selected a few organizations:
- Stanford Brai= n Tumor Center (http://medicalgiving.stanford.edu/, this is where Fran=E7ois was = treated. Make sure to indicate the Brain Tumor Center as the recipient).
- National Brain Tumor Society (http://www.braintumor.org/)

Note that he also left behind a son, Olivier.=A0

That's all the information I have at this point.=A0

Regards,
Mary.

--bcaec53f35f54a501b04f5702fe4-- From nobody Thu Mar 27 09:40:05 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6531A06C3; Thu, 27 Mar 2014 09:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j0lAGL5fKUb; Thu, 27 Mar 2014 09:39:58 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3700F1A0332; Thu, 27 Mar 2014 09:39:58 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so1926035wes.38 for ; Thu, 27 Mar 2014 09:39:55 -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 :content-type; bh=jlD4MlHfIkmEs5De+vypvdkY0WPg+pBwIjj6AMDh6ew=; b=GQhfJzpiBwE7gFslfoE2ydxHVo6qtYptiRGUbR1KTk0Mva/K1/sKzj3Fb1MGkCmnqC Hzw4jhT3b+SMNZWfOZDgUiDB9WDWJf6TvAWa/MZvyoV7ntmffeL/1Nm80yN3ERzE4Oz5 yvIJ9IzuweHWY5mW4wXvcGZxq98OgkPRzZVkunbVzK6n9YAbkRqw9iOaGAGfT+tz5DDX BkkyMmWp4HKlb5x1kEowiflRgsXfOHDGgu79ciGKpYpCMi/HB8QxBJzdDZiHE9D7F0te 93O/9+zNbcGrkWH2tcf6sNVuL0bxYggQi7aCNQpPUUFm4oKmDlcSTUTjyfbQqcRkxmPE 0jnQ== MIME-Version: 1.0 X-Received: by 10.180.20.176 with SMTP id o16mr40623910wie.7.1395938395440; Thu, 27 Mar 2014 09:39:55 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Thu, 27 Mar 2014 09:39:55 -0700 (PDT) In-Reply-To: <532B2896.6090502@nostrum.com> References: <532B2896.6090502@nostrum.com> Date: Thu, 27 Mar 2014 11:39:55 -0500 Message-ID: From: Mary Barnes To: SIPCORE , DISPATCH Content-Type: multipart/alternative; boundary=bcaec53f35f5304c7904f5993cb7 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/k56XunQYyzG8eqph9Ay7N3Th3mU Subject: [dispatch] Fwd: [RAI] SIPit 31 registration is open X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:40:01 -0000 --bcaec53f35f5304c7904f5993cb7 Content-Type: text/plain; charset=ISO-8859-1 I didn't see this hit either SIPCORE or DISPATCH WG mailing lists and I know that the RAI mailing list has far fewer subscribers than these other two lists. Obviously, don't reply to this message on these other lists. ---------- Forwarded message ---------- From: Robert Sparks Date: Thu, Mar 20, 2014 at 12:42 PM Subject: [RAI] SIPit 31 registration is open To: rai@ietf.org SIPit 31 will be held in Nice, France Sep 28 - Oct 3, 2014. The event will be hosted by ETSI. More information, and the registration page, is available at Please take advantage of the opportunity to register early. In addition to the normal team-to-team testing at the event, we will be concentrating on several specific interoperability areas: * Nat and Firewall Traversal using Outbound, TURN, and STUN * RTCWeb * Advanced Video scenarios * Use of TLS and DTLS If you're planning to attend and have other areas you would like have a multi-team focus session around, please let me know. RjS _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai --bcaec53f35f5304c7904f5993cb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I didn't see this hit either SIPCORE or DISPATCH WG ma= iling lists and I know that the RAI mailing list has far fewer subscribers = than these other two lists.

Obviously, don't reply t= o this message on these other lists.=A0

---------- Forwarded message ----------
F= rom: Robert Sparks <= rjsparks@nostrum.com>=
Date: Thu, Mar 20, 2014 at 12:42 PM
Subject: [RAI] SIPit 31 registration= is open
To: rai@ietf.org

SIPit 31 will be held in Nice, France Sep 28 - Oct 3, 2014.
The event will be hosted by ETSI.

More information, and the registration page, =A0is available at
<http://www.etsi.org/news-events/events/750-sipit-31&= gt;
Please take advantage of the opportunity to register early.

In addition to the normal team-to-team testing at the event,
we will be concentrating on several specific interoperability areas:
* Nat and Firewall Traversal using Outbound, TURN, and STUN
* RTCWeb
* Advanced Video scenarios
* Use of TLS and DTLS

If you're planning to attend and have other areas you would like
have a multi-team focus session around, please let me know.

RjS

_______________________________________________
RAI mailing list
RAI@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/rai

--bcaec53f35f5304c7904f5993cb7--