From Peter.Dawes@vodafone.com Wed Dec 5 06:30:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73D921F8C9C for ; Wed, 5 Dec 2012 06:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.883 X-Spam-Level: X-Spam-Status: No, score=-4.883 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utb42KBr-kkl for ; Wed, 5 Dec 2012 06:30:04 -0800 (PST) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3C34421F8BF7 for ; Wed, 5 Dec 2012 06:30:04 -0800 (PST) Received: from mailint02 (localhost [127.0.0.1]) by mailout02 (Postfix) with ESMTP id C3DE8381D2D for ; Wed, 5 Dec 2012 15:30:02 +0100 (CET) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) by mailint02 (Postfix) with ESMTP id B6D65381D18 for ; Wed, 5 Dec 2012 15:30:02 +0100 (CET) Received: from VOEXM31W.internal.vodafone.com ([169.254.7.8]) by VOEXC05W.internal.vodafone.com ([145.230.101.25]) with mapi id 14.02.0318.004; Wed, 5 Dec 2012 15:30:02 +0100 From: "Dawes, Peter, Vodafone Group" To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt Thread-Index: Ac3S9PAlalti9DbhSdSeWbKKk4gapQ== Date: Wed, 5 Dec 2012 14:30:02 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CCB6@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 14:30:04 -0000 Hello All, I submitted a slide presentation IETF #83 http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-00.txt From Peter.Dawes@vodafone.com Wed Dec 5 06:45:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE41D21F8CC1 for ; Wed, 5 Dec 2012 06:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-1.256, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CY2sDK3Cbp3 for ; Wed, 5 Dec 2012 06:45:28 -0800 (PST) Received: from mailout11.vodafone.com (mailout11.vodafone.com [195.232.224.80]) by ietfa.amsl.com (Postfix) with ESMTP id B951B21F8CAB for ; Wed, 5 Dec 2012 06:45:25 -0800 (PST) Received: from mailint11 (localhost [127.0.0.1]) by mailout11 (Postfix) with ESMTP id 4DBC42A23E1 for ; Wed, 5 Dec 2012 15:45:24 +0100 (CET) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint11 (Postfix) with ESMTPS id 4090E2A2372; Wed, 5 Dec 2012 15:45:24 +0100 (CET) Received: from AVOEXH04W.internal.vodafone.com (145.230.15.136) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 5 Dec 2012 15:45:23 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.8]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.02.0318.004; Wed, 5 Dec 2012 15:45:23 +0100 From: "Dawes, Peter, Vodafone Group" To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt Thread-Index: Ac3S9PAlalti9DbhSdSeWbKKk4gapQAACfvQ Date: Wed, 5 Dec 2012 14:45:22 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fluffy@iii.ca" Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 14:45:28 -0000 Hello All, I submitted a slide presentation IETF #83 Paris on the topic of marking SIP= signalling to make it practical to troubleshoot sessions that cross multip= le networks (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.= pdf). I proposed to add this function to the session-id work being done by = insipid but the feedback was that dispatch should consider the proposal. I = have therefore written a requirements draft http://www.ietf.org/internet-dr= afts/draft-dawes-dispatch-logme-reqs-00.txt as a starting point for discuss= ion which I hope will lead to further work on draft http://tools.ietf.org/i= d/draft-kaithal-dispatch-sip-log-information-00.txt, which describes someth= ing quite similar to the slides I submitted to the Paris meeting. Regards, Peter From fluffy@cisco.com Wed Dec 5 08:53:23 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8878D21F8CF0 for ; Wed, 5 Dec 2012 08:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqBYCujSxQpk for ; Wed, 5 Dec 2012 08:53:22 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A89D721F87FF for ; Wed, 5 Dec 2012 08:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4926; q=dns/txt; s=iport; t=1354726402; x=1355936002; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SMi5p2NfBZnMz/VTQA2C2MgmyPEiMuiOtENhDq7w+xo=; b=NbjCDmk1bI7PDJ8Z6aP5FuwIjH7gv6yLGq/2w0Lbl0WMM/3xDd+wFjFS BLsheb+qFw1vt2lSk1K242INGn/Z1OGtpLzArO16+yS5g3kJkJyVYQ+R8 KSWBkBjZH61qbRlORFvBUztzUhe0fky79yzN64wdkBxNpn0mvG5HYrHem Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFJ6v1CtJV2Y/2dsb2JhbABEvisWc4IeAQEBAwEBAQE3NAkCBQcEAgEIEQQBAQEKCwkFBAcnCxQJCAIEDgUIAYgBBgzCO4w3FXmCUmEDlx+PK4JygWM+ X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="149697623" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 05 Dec 2012 16:53:22 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB5GrMb0020074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 16:53:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 10:53:21 -0600 From: "Cullen Jennings (fluffy)" To: Atle Monrad Thread-Topic: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt Thread-Index: AQHN0wkIIwhXqUUFQUakphb9ygW8/A== Date: Wed, 5 Dec 2012 16:53:20 +0000 Message-ID: References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> <5046385A.4080803@alum.mit.edu> <7A051DFAA46D0246A82293C7CEF621E90709FCB203@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E90709FCB203@ESESSCMS0352.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <8BADED6D9702CC439870B3CD9B48A88E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Dec 2012 09:37:53 -0800 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:53:23 -0000 So this is draft that would be used be emergency calling on 3G mobile phone= s and folks are proposing it would be experimental. Care provide the justif= ication for that? On Sep 17, 2012, at 5:56 AM, Atle Monrad wrote: > All >=20 > 3GPP has been waiting for long time on completion of this draft. I hope t= hat the new version provided by John-Luc is acceptable and can be progresse= d. >=20 > As the new version has limited changes compated to the previous version, = I hope that this draft does not need too long time for considerations befor= e it can be progressed & completed. >=20 > From 3GPP, this draft is supported. >=20 > /atle >=20 > ________________________________=20 >=20 >=20 > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management=20 > Ericsson >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Paul Kyzivat > Sent: 4. september 2012 19:20 > To: dispatch@ietf.org > Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatc= h-3gpp-ims-xml-body-handling-00.txt >=20 > To make it easier for other readers, here is a link that does the diff of= this version to the prior one: >=20 > http://tools.ietf.org/rfcdiff?url1=3Ddraft-bakker-sipping-3gpp-ims-xml-bo= dy-handling-08.txt;url2=3Ddraft-bakker-dispatch-3gpp-ims-xml-body-handling-= 00.txt >=20 > Regards, > Paul >=20 > On 9/4/12 11:30 AM, John-Luc Bakker wrote: >> Dear all, >>=20 >> I have submitted a new version of the previous "draft-bakker-sipping-3gp= p-ims-xml-body-handling", taking into account the various comments received= . The most notable change is to submit the draft to DISPATCH (instead of SI= PPING) and to submit the draft for standards track consideration. >>=20 >> I welcome your comments. >>=20 >> Kind regards, >>=20 >> John-Luc >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, September 04, 2012 10:26 AM >> To: John-Luc Bakker >> Subject: New Version Notification for=20 >> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >>=20 >>=20 >> A new version of I-D,=20 >> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >> has been successfully submitted by John-Luc Bakker and posted to the IET= F repository. >>=20 >> Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling >> Revision: 00 >> Title: Specification of 3GPP IM CN Subsystem XML body handling >> Creation date: 2012-09-04 >> WG ID: Individual Submission >> Number of pages: 8 >> URL: http://www.ietf.org/internet-drafts/draft-bakker-dispat= ch-3gpp-ims-xml-body-handling-00.txt >> Status: http://datatracker.ietf.org/doc/draft-bakker-dispatch-3= gpp-ims-xml-body-handling >> Htmlized: http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-i= ms-xml-body-handling-00 >>=20 >>=20 >> Abstract: >> This document registers new disposition-types for the Content- >> Disposition header field that apply to the application/3gpp-ims+xml >> body (part) used by 3GPP [5]. The applicability of these content- >> disposition values are limited to 3GPP IMS [5]. The application/ >> 3gpp-ims+xml body (part) has the following three distinct uses: (1) >> for redirecting the emergency session to use a different domain (e.g. >> using a Circuit Switched call), (2) for delivering user profile >> specific information from the SIP registrar to an Application Server, >> and (3) for causing a UAC to attempt to re-register with the IMS. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Wed Dec 5 10:41:50 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC121F8464 for ; Wed, 5 Dec 2012 10:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5pKcvHFp+gr for ; Wed, 5 Dec 2012 10:41:50 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4E08321F8436 for ; Wed, 5 Dec 2012 10:41:50 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id Xrqh1k0021uE5Es53uhoSC; Wed, 05 Dec 2012 18:41:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id Xuho1k00J3ZTu2S3cuhouP; Wed, 05 Dec 2012 18:41:48 +0000 Message-ID: <50BF956B.3050308@alum.mit.edu> Date: Wed, 05 Dec 2012 13:41:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.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=1354732908; bh=KMyxcJ3L9+AmHoOW7oFU5lUnpT0bzO9RpsSkR6NbPoI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jA2Nh1TRaECypQ8HHnB2oTl98VOrQbHCkuFxrr3cMvsBah8KKlGs6wg7ARCm2B1V3 tnqbOKGDeitWg8evzqHYPDDk4vEtEkoGXkvVYdAKsVk2lXpAPc3WdIJBpGMCBL/ZoU XYnl4AqXT0Hdlf+bXE0+EJ5g0TxsRyj7kQmZ0bx3B0W95kCW7uXFFVtbV8pCNu37+O ZlQvIXLl21zfoeokKcLfNTA+z2K/ItEtM5CPqBFXRmHPd/JMg02thLfvMteZmO3Tdk +zc7v7sPfgqgm1xFgRTcaULNqh9IA/1JK6jI1UEjtYK5NtYtiBTqVdyptqlrXBcUGQ 0SEN6rXEtBTOQ== Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:41:51 -0000 On 12/5/12 9:45 AM, Dawes, Peter, Vodafone Group wrote: > Hello All, > I submitted a slide presentation IETF #83 Paris on the topic of marking SIP signalling to make it practical to troubleshoot sessions that cross multiple networks (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf). I proposed to add this function to the session-id work being done by insipid but the feedback was that dispatch should consider the proposal. I have therefore written a requirements draft http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-00.txt as a starting point for discussion which I hope will lead to further work on draft http://tools.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt, which describes something quite similar to the slides I submitted to the Paris meeting. You've done the right first step by publishing this and commenting on it here. The next thing is to see how much interest there is in it. I have a couple of comments: - You have two REQ2s. - I think you should explain more about REQ3. On one hand, there are cases when you might want/need for this to survive trust boundaries. OTOH the administrators of the domains might not want to allow this. Its not clear to me that you can mandate much here. - are REQ5 and REQ6 talking about the same identifier, or different identifiers? - there is potential overlap between this and Session-ID. Would like to see you discuss whether Session-ID satisfies your identifier needs. Thanks, Paul From worley@shell01.TheWorld.com Wed Dec 5 11:26:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A931221F8965 for ; Wed, 5 Dec 2012 11:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5G9x00F77zm for ; Wed, 5 Dec 2012 11:26:02 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B0E1321F892A for ; Wed, 5 Dec 2012 11:26:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qB5JP9Qk030082 for ; Wed, 5 Dec 2012 14:25:12 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qB5JP99v2442267 for ; Wed, 5 Dec 2012 14:25:09 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qB5JP9iK2381562; Wed, 5 Dec 2012 14:25:09 -0500 (EST) Date: Wed, 5 Dec 2012 14:25:09 -0500 (EST) Message-Id: <201212051925.qB5JP9iK2381562@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.com> (Peter.Dawes@vodafone.com) References: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.com> Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:26:03 -0000 I recall during discussion of a similar topic that people from carriers said that carriers do not diagnose networks by tracing the signaling of single calls, but rather monitor the usage statistics of various facilities for anomalies. I see that the author of this draft is from Vodafone, which is a carrier, and the mechanism proposed in the draft is to trace the signaling of single calls. Is it correct for me to infer that there are occasions where carriers trace single calls for diagnostic purposes? Dale From fluffy@cisco.com Wed Dec 5 14:49:29 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9C21F8C3E for ; Wed, 5 Dec 2012 14:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMTsWrx9Ko1J for ; Wed, 5 Dec 2012 14:49:29 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0913221F8C23 for ; Wed, 5 Dec 2012 14:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5470; q=dns/txt; s=iport; t=1354747769; x=1355957369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TqyaD2LNmCQ2TgxqdVaAtZJa32+5yluoMiMnrcU/raM=; b=UW+6Unqoohz2RrjeVL1LDcRW1+rx5iT04uh39hAdxtoZ9SwlwRVN0TtI ed8ZZDeGJgjQWFQSEPqdJL57uka+aTz91CQj6uOrwcucZAYTre0vC5Jcp QeAElc+8AtvSDTIZrPfJhCcnxnhTV2U8ag1dcku+BzkAR0RPP/tyhoAsw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAInOv1CtJXG+/2dsb2JhbABEviQWc4IeAQEBAwEBAQE3NAkCDAQCAQgRBAEBAQoLCQUEBycLFAkIAgQOBQgBiAEGDMJijDcVeYJSYQOXH48rgnKBYz4 X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149634279" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 05 Dec 2012 22:49:28 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB5MnSXQ019316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 22:49:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 16:49:27 -0600 From: "Cullen Jennings (fluffy)" To: Atle Monrad Thread-Topic: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt Thread-Index: AQHN0zrG3z+YFfyfr0uC4P7yjG1lGA== Date: Wed, 5 Dec 2012 22:49:26 +0000 Message-ID: References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> <5046385A.4080803@alum.mit.edu> <7A051DFAA46D0246A82293C7CEF621E90709FCB203@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 22:49:30 -0000 My apologies, I see it is standards track. I had looked at the sipping vers= ion not the dispatch version. Thanks to James for pointing out I had looked= at the sipping version. On Dec 5, 2012, at 9:53 AM, "Cullen Jennings (fluffy)" w= rote: >=20 > So this is draft that would be used be emergency calling on 3G mobile pho= nes and folks are proposing it would be experimental. Care provide the just= ification for that? >=20 >=20 >=20 > On Sep 17, 2012, at 5:56 AM, Atle Monrad wrote= : >=20 >> All >>=20 >> 3GPP has been waiting for long time on completion of this draft. I hope = that the new version provided by John-Luc is acceptable and can be progress= ed. >>=20 >> As the new version has limited changes compated to the previous version,= I hope that this draft does not need too long time for considerations befo= re it can be progressed & completed. >>=20 >> From 3GPP, this draft is supported. >>=20 >> /atle >>=20 >> ________________________________=20 >>=20 >>=20 >> Atle Monrad >> 3GPP CT Chairman >> Standardization and Regulation, >> Group Function Technology and Portfolio Management=20 >> Ericsson >>=20 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Be= half Of Paul Kyzivat >> Sent: 4. september 2012 19:20 >> To: dispatch@ietf.org >> Subject: Re: [dispatch] New Version Notification for draft-bakker-dispat= ch-3gpp-ims-xml-body-handling-00.txt >>=20 >> To make it easier for other readers, here is a link that does the diff o= f this version to the prior one: >>=20 >> http://tools.ietf.org/rfcdiff?url1=3Ddraft-bakker-sipping-3gpp-ims-xml-b= ody-handling-08.txt;url2=3Ddraft-bakker-dispatch-3gpp-ims-xml-body-handling= -00.txt >>=20 >> Regards, >> Paul >>=20 >> On 9/4/12 11:30 AM, John-Luc Bakker wrote: >>> Dear all, >>>=20 >>> I have submitted a new version of the previous "draft-bakker-sipping-3g= pp-ims-xml-body-handling", taking into account the various comments receive= d. The most notable change is to submit the draft to DISPATCH (instead of S= IPPING) and to submit the draft for standards track consideration. >>>=20 >>> I welcome your comments. >>>=20 >>> Kind regards, >>>=20 >>> John-Luc >>>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Tuesday, September 04, 2012 10:26 AM >>> To: John-Luc Bakker >>> Subject: New Version Notification for=20 >>> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >>>=20 >>>=20 >>> A new version of I-D,=20 >>> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >>> has been successfully submitted by John-Luc Bakker and posted to the IE= TF repository. >>>=20 >>> Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling >>> Revision: 00 >>> Title: Specification of 3GPP IM CN Subsystem XML body handling >>> Creation date: 2012-09-04 >>> WG ID: Individual Submission >>> Number of pages: 8 >>> URL: http://www.ietf.org/internet-drafts/draft-bakker-dispa= tch-3gpp-ims-xml-body-handling-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-bakker-dispatch-= 3gpp-ims-xml-body-handling >>> Htmlized: http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-= ims-xml-body-handling-00 >>>=20 >>>=20 >>> Abstract: >>> This document registers new disposition-types for the Content- >>> Disposition header field that apply to the application/3gpp-ims+xml >>> body (part) used by 3GPP [5]. The applicability of these content- >>> disposition values are limited to 3GPP IMS [5]. The application/ >>> 3gpp-ims+xml body (part) has the following three distinct uses: (1) >>> for redirecting the emergency session to use a different domain (e.g. >>> using a Circuit Switched call), (2) for delivering user profile >>> specific information from the SIP registrar to an Application Server, >>> and (3) for causing a UAC to attempt to re-register with the IMS. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful. >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Peter.Dawes@vodafone.com Thu Dec 6 01:00:16 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6395221F8613 for ; Thu, 6 Dec 2012 01:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac8gixOxxglw for ; Thu, 6 Dec 2012 01:00:15 -0800 (PST) Received: from mailout09.vodafone.com (mailout09.vodafone.com [195.232.224.78]) by ietfa.amsl.com (Postfix) with ESMTP id BE81E21F860D for ; Thu, 6 Dec 2012 01:00:10 -0800 (PST) Received: from mailint09 (localhost [127.0.0.1]) by mailout09 (Postfix) with ESMTP id 84381E1517 for ; Thu, 6 Dec 2012 10:00:08 +0100 (CET) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint09 (Postfix) with ESMTPS id 7574FE1500; Thu, 6 Dec 2012 10:00:08 +0100 (CET) Received: from VOEXM31W.internal.vodafone.com ([169.254.7.8]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.02.0318.004; Thu, 6 Dec 2012 10:00:06 +0100 From: "Dawes, Peter, Vodafone Group" To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt Thread-Index: Ac3S9PAlalti9DbhSdSeWbKKk4gapQAACfvQAApSE60AG/I3cA== Date: Thu, 6 Dec 2012 09:00:05 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5D3A8@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.com> <201212051925.qB5JP9iK2381562@shell01.TheWorld.com> In-Reply-To: <201212051925.qB5JP9iK2381562@shell01.TheWorld.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 09:00:16 -0000 Hello Dale, This carrier has SIP-based networks in more than one country, but in the ne= twork I am familiar with we have tools that can check for correct operation= down to a single-call level. Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dale R. Worley Sent: 05 December 2012 19:25 To: dispatch@ietf.org Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt I recall during discussion of a similar topic that people from carriers sai= d that carriers do not diagnose networks by tracing the signaling of single= calls, but rather monitor the usage statistics of various facilities for a= nomalies. I see that the author of this draft is from Vodafone, which is a carrier, a= nd the mechanism proposed in the draft is to trace the signaling of single = calls. Is it correct for me to infer that there are occasions where carriers trace= single calls for diagnostic purposes? Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Peter.Dawes@vodafone.com Thu Dec 6 01:50:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF4821F8669 for ; Thu, 6 Dec 2012 01:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcq7sBuVAlLR for ; Thu, 6 Dec 2012 01:50:04 -0800 (PST) Received: from mailout07.vodafone.com (mailout07.vodafone.com [195.232.224.76]) by ietfa.amsl.com (Postfix) with ESMTP id BC58921F860F for ; Thu, 6 Dec 2012 01:50:03 -0800 (PST) Received: from mailint07 (localhost [127.0.0.1]) by mailout07 (Postfix) with ESMTP id 047FD222B41 for ; Thu, 6 Dec 2012 10:50:01 +0100 (CET) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint07 (Postfix) with ESMTPS id ED7F9222A1C; Thu, 6 Dec 2012 10:50:00 +0100 (CET) Received: from AVOEXH04W.internal.vodafone.com (145.230.15.136) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 6 Dec 2012 10:50:00 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.8]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.02.0318.004; Thu, 6 Dec 2012 10:50:00 +0100 From: "Dawes, Peter, Vodafone Group" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt Thread-Index: Ac3S9PAlalti9DbhSdSeWbKKk4gapQAACfvQAAatEoAAIJl/gA== Date: Thu, 6 Dec 2012 09:49:59 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5D434@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.com> <50BF956B.3050308@alum.mit.edu> In-Reply-To: <50BF956B.3050308@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 09:50:04 -0000 Hello Paul, Thanks for your comments.=20 Regarding REQ3 "Log-me marking shall be removed at trust domain boundaries"= , to expand a little on your comment I imagine that a network would remove = any inbound 'log me' marker unless it has an agreement with the source netw= ork not to do so. However, the 'log me' marker is most effective if it pass= es end-to-end. REQ3 asks source networks to behave responsibly and not leav= e it to the downstream networks to detect and remove a marker that they don= 't want. I will reword it to try to include these points. REQ 5 " Log-me marking may include an identifier that indicates the test ca= se that caused it to be inserted, known as a test case identifier" and REQ = 6 "Log-me marking may include an identifier of the server that collects log= s, known as the diagnostic server identifier." are for different identifier= s. The 'test case identifier' in REQ 5 is the name of one test in a set of = regression tests, which could be something like 'test 01' or 'paging mode m= essaging' or 'e3f634'. The 'server identifier' in REQ 6 is the address of a= network monitoring server.=20 Session-ID provides an end-to-end identifier which is very useful informati= on when checking for correct session setup. However, Session-ID cannot indi= cate that a particular session is for testing purposes and therefore needs = to be logged. If you have to test a particular session and you have Session= -ID only (i.e. no log-me marker), the only way to follow signalling end-to-= end is to log all signalling in all entities that might be on the path and = then search these logs later for the relevant session ID.=20 Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Paul Kyzivat Sent: 05 December 2012 18:42 To: dispatch@ietf.org Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt On 12/5/12 9:45 AM, Dawes, Peter, Vodafone Group wrote: > Hello All, > I submitted a slide presentation IETF #83 Paris on the topic of marking S= IP signalling to make it practical to troubleshoot sessions that cross mult= iple networks (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-= 1.pdf). I proposed to add this function to the session-id work being done b= y insipid but the feedback was that dispatch should consider the proposal. = I have therefore written a requirements draft http://www.ietf.org/internet-= drafts/draft-dawes-dispatch-logme-reqs-00.txt as a starting point for discu= ssion which I hope will lead to further work on draft http://tools.ietf.org= /id/draft-kaithal-dispatch-sip-log-information-00.txt, which describes some= thing quite similar to the slides I submitted to the Paris meeting. You've done the right first step by publishing this and commenting on it he= re. The next thing is to see how much interest there is in it. I have a couple of comments: - You have two REQ2s. - I think you should explain more about REQ3. On one hand, there are cases when you might want/need for this to survive trust boundaries. OTOH the administrators of the domains might not want to allow this. Its not clear to me that you can mandate much here. - are REQ5 and REQ6 talking about the same identifier, or different identifiers? - there is potential overlap between this and Session-ID. Would like to see you discuss whether Session-ID satisfies your identifier needs. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Thu Dec 6 08:47:32 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5150B21F875D for ; Thu, 6 Dec 2012 08:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AoEzDFCqpo5 for ; Thu, 6 Dec 2012 08:47:31 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA0521F85DD for ; Thu, 6 Dec 2012 08:47:29 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta02.westchester.pa.mail.comcast.net with comcast id YCSw1k0071HzFnQ51GnVUL; Thu, 06 Dec 2012 16:47:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id YGnU1k00n3ZTu2S3aGnUVn; Thu, 06 Dec 2012 16:47:29 +0000 Message-ID: <50C0CC20.5050105@alum.mit.edu> Date: Thu, 06 Dec 2012 11:47:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Dawes, Peter, Vodafone Group" References: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.com> <50BF956B.3050308@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5D434@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5D434@VOEXM31W.internal.vodafone.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=1354812449; bh=9EzrYgQrq6stxQNiMd/+ku92gWCyLdurovj/ZdoPQyw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=idMfiNqIzXNv74F0pT1RlusqovDDtojYGqgW9IbgOiJfehtf8/uRcCLDAZsDSZrbW kJdVBMmBLIX/cMmNhdwjMbVHfW51AZtXD/uXWCYuJHT9vZUBipbm6s9CKvrBXsBNpC /O1EqO+3+/of+iX4iJj52qYi945/yYN96Eg+XsfUcu7GZq8cFn8i6wKZmLdPrUkHvk 97FxHJeNgpPgDlQTcQMIli4OVt5zpO6o1T0jOybAf29hVkfwXZaQJM8cwmndXr31WA A92AskfUOrDGJQL1GEzk2TFacaNHos2jbisrYvgE63s46L6PsdPUV8VU994KsD7Ayp TqP7h+Ips8F1g== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 16:47:32 -0000 On 12/6/12 4:49 AM, Dawes, Peter, Vodafone Group wrote: > Hello Paul, > Thanks for your comments. > > Regarding REQ3 "Log-me marking shall be removed at trust domain boundaries", to expand a little on your comment I imagine that a network would remove any inbound 'log me' marker unless it has an agreement with the source network not to do so. However, the 'log me' marker is most effective if it passes end-to-end. REQ3 asks source networks to behave responsibly and not leave it to the downstream networks to detect and remove a marker that they don't want. I will reword it to try to include these points. > > REQ 5 " Log-me marking may include an identifier that indicates the test case that caused it to be inserted, known as a test case identifier" and REQ 6 "Log-me marking may include an identifier of the server that collects logs, known as the diagnostic server identifier." are for different identifiers. The 'test case identifier' in REQ 5 is the name of one test in a set of regression tests, which could be something like 'test 01' or 'paging mode messaging' or 'e3f634'. The 'server identifier' in REQ 6 is the address of a network monitoring server. > > Session-ID provides an end-to-end identifier which is very useful information when checking for correct session setup. However, Session-ID cannot indicate that a particular session is for testing purposes and therefore needs to be logged. If you have to test a particular session and you have Session-ID only (i.e. no log-me marker), the only way to follow signalling end-to-end is to log all signalling in all entities that might be on the path and then search these logs later for the relevant session ID. I realize that Session-ID would not serve as a request for logging. But perhaps it would serve as an alternative to the "test case identifier". I suggest that you think about that. Otherwise, you are introducing another identifier that you will have to fight to get people to support. The server-identifier seems to be a entirely different and a bigger deal. It seems to suggest that you want all servers on the path to log remotely using consistent tools to a common server. I expect you to have a huge battle to get anybody to agree to that. I'm thinking your log request needs some sort of new indicator, and then the (so far hypothetical) session-id would serve as the test id to coordinate the logs from all the systems. It would then still take some sleuthing to find the systems on the path that have logged something, but you can query using the session-id. Perhaps the new indicator requesting logging could be a new "purpose" value for Call-Info. If so, you could even use the corresponding URI to point to a logging server. (But still don't count on everything using it.) Thanks, Paul > Regards, > Peter > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 05 December 2012 18:42 > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt > > On 12/5/12 9:45 AM, Dawes, Peter, Vodafone Group wrote: >> Hello All, >> I submitted a slide presentation IETF #83 Paris on the topic of marking SIP signalling to make it practical to troubleshoot sessions that cross multiple networks (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf). I proposed to add this function to the session-id work being done by insipid but the feedback was that dispatch should consider the proposal. I have therefore written a requirements draft http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-00.txt as a starting point for discussion which I hope will lead to further work on draft http://tools.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt, which describes something quite similar to the slides I submitted to the Paris meeting. > > You've done the right first step by publishing this and commenting on it here. The next thing is to see how much interest there is in it. > > I have a couple of comments: > > - You have two REQ2s. > > - I think you should explain more about REQ3. > On one hand, there are cases when you might > want/need for this to survive trust boundaries. > OTOH the administrators of the domains might > not want to allow this. Its not clear to me > that you can mandate much here. > > - are REQ5 and REQ6 talking about the same > identifier, or different identifiers? > > - there is potential overlap between this and > Session-ID. Would like to see you discuss > whether Session-ID satisfies your identifier > needs. > > Thanks, > Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From partha@parthasarathi.co.in Thu Dec 6 09:25:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7ED21F87E1 for ; Thu, 6 Dec 2012 09:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psb9RAHvF1tC for ; Thu, 6 Dec 2012 09:25:53 -0800 (PST) Received: from outbound-us3.mailhostbox.com (unknown [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id BFE6221F8742 for ; Thu, 6 Dec 2012 09:25:53 -0800 (PST) Received: from userPC (unknown [122.179.88.144]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 152F686850C; Thu, 6 Dec 2012 17:25:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1354814752; bh=Bvj0J8lpk4pQP6rh3AVdwHij2Qvo+IjNP6f23c5auAc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=izfIYo0Ie1H9dES3EGXxQY0CI9B4ypSlB9/DO6h0XuIGsD95SoX5HCLQKpXbuiaCx ExYN/nOP5fPp8GcYXG9luL/5+LwNjNsygJD/FcNlxR86FUyqVZSU09B6gk5T+F87tJ t2+29pu9rkDEJ2l1F/7W1rLX6K/zuNb4JWI4MwK4= From: "Parthasarathi R" To: "'Paul Kyzivat'" , "'Dawes, Peter, Vodafone Group'" References: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5CD1A@VOEXM31W.internal.vodafone.com> <50BF956B.3050308@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5D434@VOEXM31W.internal.vodafone.com> <50C0CC20.5050105@alum.mit.edu> In-Reply-To: <50C0CC20.5050105@alum.mit.edu> Date: Thu, 6 Dec 2012 22:55:42 +0530 Message-ID: <002b01cdd3d6$bb1a7db0$314f7910$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3T0WUE12AZ2+f6S6ykuWNukS6qgwABEzxA Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0203.50C0D520.0129, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:25:54 -0000 Paul, Sec 3.5 of draft-ietf-insipid-session-id-reqts-03 describes "logme" usecase for session id. The text is added after discussing about "logme" usecase in INSIPID WG. Thanks Partha Note: 3.5. Session Signal Logging An after the fact search of SIP messages to determine which were part of the same transaction or call is difficult when B2BUAs and SBCs are involved in the signaling between UAs. Mapping more than one Call-ID together can be challenging because all of the values in SIP headers on one side of the B2BUA or SBC will likely be different than those on the other side. If multiple B2BUAs and/or SBCs are in the signaling path, more than two sets of header values will exist, creating more of a challenge. Creating a common header value through all SIP entities will greatly reduce any challenge for the purposes of debugging, communication tracking (such as for security purposes in case of theft of service), etc. Derived Requirements: REQ1, REQ3, REQ5, REQ6 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, December 06, 2012 10:17 PM To: Dawes, Peter, Vodafone Group Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt On 12/6/12 4:49 AM, Dawes, Peter, Vodafone Group wrote: > Hello Paul, > Thanks for your comments. > > Regarding REQ3 "Log-me marking shall be removed at trust domain boundaries", to expand a little on your comment I imagine that a network would remove any inbound 'log me' marker unless it has an agreement with the source network not to do so. However, the 'log me' marker is most effective if it passes end-to-end. REQ3 asks source networks to behave responsibly and not leave it to the downstream networks to detect and remove a marker that they don't want. I will reword it to try to include these points. > > REQ 5 " Log-me marking may include an identifier that indicates the test case that caused it to be inserted, known as a test case identifier" and REQ 6 "Log-me marking may include an identifier of the server that collects logs, known as the diagnostic server identifier." are for different identifiers. The 'test case identifier' in REQ 5 is the name of one test in a set of regression tests, which could be something like 'test 01' or 'paging mode messaging' or 'e3f634'. The 'server identifier' in REQ 6 is the address of a network monitoring server. > > Session-ID provides an end-to-end identifier which is very useful information when checking for correct session setup. However, Session-ID cannot indicate that a particular session is for testing purposes and therefore needs to be logged. If you have to test a particular session and you have Session-ID only (i.e. no log-me marker), the only way to follow signalling end-to-end is to log all signalling in all entities that might be on the path and then search these logs later for the relevant session ID. I realize that Session-ID would not serve as a request for logging. But perhaps it would serve as an alternative to the "test case identifier". I suggest that you think about that. Otherwise, you are introducing another identifier that you will have to fight to get people to support. The server-identifier seems to be a entirely different and a bigger deal. It seems to suggest that you want all servers on the path to log remotely using consistent tools to a common server. I expect you to have a huge battle to get anybody to agree to that. I'm thinking your log request needs some sort of new indicator, and then the (so far hypothetical) session-id would serve as the test id to coordinate the logs from all the systems. It would then still take some sleuthing to find the systems on the path that have logged something, but you can query using the session-id. Perhaps the new indicator requesting logging could be a new "purpose" value for Call-Info. If so, you could even use the corresponding URI to point to a logging server. (But still don't count on everything using it.) Thanks, Paul > Regards, > Peter > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 05 December 2012 18:42 > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt > > On 12/5/12 9:45 AM, Dawes, Peter, Vodafone Group wrote: >> Hello All, >> I submitted a slide presentation IETF #83 Paris on the topic of marking SIP signalling to make it practical to troubleshoot sessions that cross multiple networks (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf). I proposed to add this function to the session-id work being done by insipid but the feedback was that dispatch should consider the proposal. I have therefore written a requirements draft http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-00.txt as a starting point for discussion which I hope will lead to further work on draft http://tools.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt, which describes something quite similar to the slides I submitted to the Paris meeting. > > You've done the right first step by publishing this and commenting on it here. The next thing is to see how much interest there is in it. > > I have a couple of comments: > > - You have two REQ2s. > > - I think you should explain more about REQ3. > On one hand, there are cases when you might > want/need for this to survive trust boundaries. > OTOH the administrators of the domains might > not want to allow this. Its not clear to me > that you can mandate much here. > > - are REQ5 and REQ6 talking about the same > identifier, or different identifiers? > > - there is potential overlap between this and > Session-ID. Would like to see you discuss > whether Session-ID satisfies your identifier > needs. > > Thanks, > Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From R.Jesske@telekom.de Fri Dec 7 00:48:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C379321F87D1 for ; Fri, 7 Dec 2012 00:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI0rMoh8J6ct for ; Fri, 7 Dec 2012 00:48:53 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1838421F87CE for ; Fri, 7 Dec 2012 00:48:52 -0800 (PST) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 07 Dec 2012 09:48:45 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 7 Dec 2012 09:48:45 +0100 From: To: Date: Fri, 7 Dec 2012 09:48:44 +0100 Thread-Topic: draft-drage-sipping-rfc3455bis-06 Thread-Index: Ac3UV6pLS2NjhFI1Q3GBqN5AU1ijNA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D15C2188307@HE111648.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D15C2188307HE111648emea1_" MIME-Version: 1.0 Subject: [dispatch] draft-drage-sipping-rfc3455bis-06 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 08:48:54 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D15C2188307HE111648emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, please find attached a link to an updated RFC3455 which is a private draft = for 3GPP extensions used only within the 3GPP IMS. The draft can be found u= nder: http://tools.ietf.org/id/draft-drage-sipping-rfc3455bis-06.txt Now we would like to proceed the draft towards publication as a private RFC= . Within Section 10 it is described what changes where done compared to the a= lready published RFC3455. Advised by Gonzalo I'm now asking here on the list for comments and advice = if this is the correct group to look on these extensions. Comments are welcome. Thank you and Best Regards Roland Jesske Deutsche Telekom Technik GmbH Fixed Mobile Engineering Deutschland Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 6151 58-13395 (Fax) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. Deutsche Telekom Technik GmbH Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D15C2188307HE111648emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,
please fi= nd attached=20 a link to an updated RFC3455 which is a private draft for 3GPP extensions u= sed=20 only within the 3GPP IMS. The draft can be found under:
 
htt= p://tools.ietf.org/id/draft-drage-sipping-rfc3455bis-06.txt
 
Now we wo= uld like to=20 proceed the draft towards publication as a private RFC.<= /DIV>
Within Se= ction 10 it=20 is described what changes where done compared to the already published= =20 RFC3455. 
Advised b= y=20 Gonzalo I'm now asking here on the list for comments and advice i= f=20 this is the correct group to look on these extensions.
 
Comments = are=20 welcome.
 

Thank you and Best=20 Regards

Roland=20 Jesske

Deu= tsche=20 Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland= =20 Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151=20 58-12766 (Tel.)
+49 6151 58-13395=20 (Fax)
+49 171 = 8618-445=20 (Mobil)
http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas= Knoll=20 (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzen= der),=20 Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB=20 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262=20

Gro=DFe=20 Ver=E4nderungen fangen klein an =96=20 Ressourcen schonen und nicht jede E-Mail drucken.=20

 
--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D15C2188307HE111648emea1_-- From lishitao@huawei.com Fri Dec 7 00:51:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9EB21F84C2 for ; Fri, 7 Dec 2012 00:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riJV7BaYBkCx for ; Fri, 7 Dec 2012 00:51:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2154921F84C0 for ; Fri, 7 Dec 2012 00:51:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMG47457; Fri, 07 Dec 2012 08:51:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 08:51:06 +0000 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 08:51:38 +0000 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.230]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.003; Fri, 7 Dec 2012 16:51:34 +0800 From: Lishitao To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-li-dispatch-ice-trickling-signalling-00.txt Thread-Index: AQHN1CxUE0j1ts5UBkm9GrnDqdZPgZgNBKBA Date: Fri, 7 Dec 2012 08:51:33 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [dispatch] FW: New Version Notification for draft-li-dispatch-ice-trickling-signalling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 08:51:54 -0000 SGkgDQoNCkkgc3VibWl0dGVkIGEgZHJhZnQgdGhhdCBkaXNjdXNzZWQgc2V2ZXJhbCBwb3RlbnRp YWwgcHJvcG9zYWxzIHRoYXQgY2FuIGJlIHVzZWQgdG8gY2FycnkgYWRkaXRpb25hbCBjYW5kaWRh dGVzIGluZm9ybWF0aW9uIGluIFNJUCBwcm90b2NvbCB0aGF0IHVzaW5nIElDRSB0cmlja2xlIG1l Y2hhbmlzbS4NCg0KVGhlcmUgbWlnaHQgYmUgb3RoZXIgc29sdXRpb25zIHRoYXQgY2FuIGJlIHVz ZWQgYnV0IG5vdCBpbiB0aGlzIGRyYWZ0LCBnbGFkIHRvIGRpc2N1c3MuDQoNClJlZ2FyZHMNClNo aXRhbw0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlk YXksIERlY2VtYmVyIDA3LCAyMDEyIDExOjM4IEFNDQpUbzogTGlzaGl0YW8NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktZGlzcGF0Y2gtaWNlLXRyaWNrbGlu Zy1zaWduYWxsaW5nLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saS1k aXNwYXRjaC1pY2UtdHJpY2tsaW5nLXNpZ25hbGxpbmctMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IFNoaXRhbyBMaSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBv c2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWxpLWRpc3BhdGNoLWljZS10cmlja2xpbmctc2ln bmFsbGluZw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgU0lQIHNpZ25hbGxpbmcgZm9yIElDRSB0 cmlja2xpbmcNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTEyLTA3DQpXRyBJRDoJCSBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTMNClVSTDogICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktZGlzcGF0Y2gtaWNlLXRyaWNr bGluZy1zaWduYWxsaW5nLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWRpc3BhdGNoLWljZS10cmlja2xpbmctc2lnbmFsbGlu Zw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1k aXNwYXRjaC1pY2UtdHJpY2tsaW5nLXNpZ25hbGxpbmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRy aWNrbGUgSUNFIGlzIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIElDRSBhZ2VudHMgdG8gc2VuZCBh bmQgcmVjZWl2ZQ0KICAgY2FuZGlkYXRlcyBpbmNyZW1lbnRhbGx5IHJhdGhlciB0aGFuIGV4Y2hh bmdpbmcgY29tcGxldGUgbGlzdHMuICBUaGlzDQogICBkb2N1bWVudCBnaXZlcyBzZXZlcmFsIHNv bHV0aW9ucyBmb3IgdHJpY2tsZSBJQ0Ugd2l0aCBTSVAgcHJvdG9jb2wuDQoNCk5vdGUNCg0KICAg RGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMgZm9yIGltcHJvdmVtZW50IGFyZSByZXF1ZXN0ZWQs IGFuZCBzaG91bGQNCiAgIGJlIHNlbnQgdG8gZGlzcGF0Y2hAaWV0Zi5vcmcuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From worley@shell01.TheWorld.com Fri Dec 7 08:25:08 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311BE21F86AF for ; Fri, 7 Dec 2012 08:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2NmvahCoDok for ; Fri, 7 Dec 2012 08:25:07 -0800 (PST) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9426521F8635 for ; Fri, 7 Dec 2012 08:25:07 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qB7GOWeY011321 for ; Fri, 7 Dec 2012 11:24:34 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qB7GOTdr2565221 for ; Fri, 7 Dec 2012 11:24:31 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qB7GOTE02577681; Fri, 7 Dec 2012 11:24:29 -0500 (EST) Date: Fri, 7 Dec 2012 11:24:29 -0500 (EST) Message-Id: <201212071624.qB7GOTE02577681@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 16:25:08 -0000 The situation regarding statelessness seems to me to be unclear. Marking could be entirely stateless (at least for proxies) if each request and response to be logged was marked. But to make that work, we require that the UAS (or some entity near it) echoes the mark from requests to responses. Either we need to codify the mark-echoing, or we need to require proxies be transaction-stateful, in regard to remembering the mark on requests requires logging responses. At the dialog level, the "Skeleton Diagnostic Procedure" says: o Subsequent responses and requests in the same dialog are logged. This requires dialog-state in the UAs and intermediate entities, in order to remember to log subsequent requests and responses. We could avoid requiring the intermediate entities to have dialog-state if we require the UAs to remember that log-me is in effect for the dialog and apply it to all subsequent requests. Given that log-me marking is removed from requests when they cross trust boundaries, how does a network apply the log-me marking to the corresponding responses when they arrive across the trust boundary? That can't depend on any marking on the response as supplied by the non-trusting network. In regard to the test case identifier and the diagnostic server identifier, are these intended to be opaque strings, or what? If the test case identifier is just to identify the test, its role could be taken by Session-ID. If it is required that the test equipment can specify the test case identifier, we need a further data item. In regard to the diagnostic server identifier, is it an opaque string to be interpreted according to an unspecified policy, or is it a locator for a server that is accumulating the logging information? If the latter, we presumably intend to standardize the manner in which logging information is transmitted to the specified server. In practice, it would seem to me that operators will often have the log-me market inserted not by the customer's UA but by a proxy that handles the UAs requests. I don't see that this would cause problems for the design, but it's a use case to keep in mind. Dale From Peter.Dawes@vodafone.com Mon Dec 10 10:08:15 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EFB21F8545 for ; Mon, 10 Dec 2012 10:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSI4wbofmXGm for ; Mon, 10 Dec 2012 10:08:15 -0800 (PST) Received: from mailout07.vodafone.com (mailout07.vodafone.com [195.232.224.76]) by ietfa.amsl.com (Postfix) with ESMTP id DBAB121F853B for ; Mon, 10 Dec 2012 10:08:14 -0800 (PST) Received: from mailint07 (localhost [127.0.0.1]) by mailout07 (Postfix) with ESMTP id C5F4F223373 for ; Mon, 10 Dec 2012 19:08:12 +0100 (CET) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint07 (Postfix) with ESMTPS id B7BCB2246C1; Mon, 10 Dec 2012 19:08:12 +0100 (CET) Received: from VOEXM31W.internal.vodafone.com ([169.254.7.8]) by VOEXC04W.internal.vodafone.com ([145.230.101.24]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 19:08:12 +0100 From: "Dawes, Peter, Vodafone Group" To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt Thread-Index: AQHN1JdUalti9DbhSdSeWbKKk4gapZgSFaJQ Date: Mon, 10 Dec 2012 18:08:11 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5E001@VOEXM31W.internal.vodafone.com> References: <201212071624.qB7GOTE02577681@shell01.TheWorld.com> In-Reply-To: <201212071624.qB7GOTE02577681@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "akaithal@cisco.com" Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:08:16 -0000 Hello Dale, I think you are right that the UAS (or some entity near it) would have to e= cho the mark from requests to responses, alternatively at least one entity = will have to be stateful and mark requests and responses so I will need to = modify REQ4 on that point. Similarly, for requests that have crossed the tr= ust domain boundary and had the log-me marking removed, a SIP entity at the= network edge receiving a response would have to be stateful and re-insert = the log-me marking.=20 Probably the test case identifier could be Session-ID, although it would be= convenient for the test equipment to be able to insert its own identifier.= I did not expect this test case identifier to have any function in the SIP= protocol, its purpose is to help the diagnostic server aggregate logging d= ata.=20 The diagnostic server identifier is a locator for a server that is accumula= ting the logging information and, as you suggest, it would be useful to sta= ndardize the manner in which logging information is transmitted to the spec= ified server. I think that draft http://tools.ietf.org/id/draft-kaithal-dis= patch-sip-log-information-00.txt suggests something in clause 5 with=20 log-type =3D "mailto" / "http"/ "syslog" / "tftp" /"ftp" /"sftp" / "local"= / other-type I think you are right that log-me marking will in some cases be inserted by= a proxy that handles a UA's requests rather than by the UA itself, so I wi= ll make sure that is clear in the requirements. Thanks for all of the useful pointers. Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dale R. Worley Sent: 07 December 2012 16:24 To: dispatch@ietf.org Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt The situation regarding statelessness seems to me to be unclear. Marking could be entirely stateless (at least for proxies) if each request = and response to be logged was marked. But to make that work, we require th= at the UAS (or some entity near it) echoes the mark from requests to respon= ses. Either we need to codify the mark-echoing, or we need to require prox= ies be transaction-stateful, in regard to remembering the mark on requests = requires logging responses. At the dialog level, the "Skeleton Diagnostic Procedure" says: o Subsequent responses and requests in the same dialog are logged. This requires dialog-state in the UAs and intermediate entities, in order t= o remember to log subsequent requests and responses. We could avoid requir= ing the intermediate entities to have dialog-state if we require the UAs to= remember that log-me is in effect for the dialog and apply it to all subse= quent requests. Given that log-me marking is removed from requests when they cross trust bo= undaries, how does a network apply the log-me marking to the corresponding = responses when they arrive across the trust boundary? That can't depend on any marking on the response as supplied by the non-tru= sting network. In regard to the test case identifier and the diagnostic server identifier,= are these intended to be opaque strings, or what? If the test case identifier is just to identify the test, its role could be= taken by Session-ID. If it is required that the test equipment can specif= y the test case identifier, we need a further data item. In regard to the diagnostic server identifier, is it an opaque string to be= interpreted according to an unspecified policy, or is it a locator for a s= erver that is accumulating the logging information? If the latter, we pres= umably intend to standardize the manner in which logging information is tra= nsmitted to the specified server. In practice, it would seem to me that operators will often have the log-me = market inserted not by the customer's UA but by a proxy that handles the UA= s requests. I don't see that this would cause problems for the design, but= it's a use case to keep in mind. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From akaithal@cisco.com Mon Dec 10 21:03:40 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D01021F86A2 for ; Mon, 10 Dec 2012 21:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dboH+dOwTEao for ; Mon, 10 Dec 2012 21:03:39 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5C42F21F8647 for ; Mon, 10 Dec 2012 21:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4926; q=dns/txt; s=iport; t=1355202219; x=1356411819; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C2UYawPTh2lgjbyxyav483gklD6ZHPCQWffNwSTnpf8=; b=F4ABOScCUesuUFhLiN7l0X7/05knd0/n8tePiGKGL/fbXW3OE7xxTgPP ASHTi/HHnMvK5JFw1DEUvQkM4TqkAkFDhsA3esR4qz0cFtNNftGLw2Dvn fx4itRDkYpJYpH65A65+eZfOnntboOw+yUy3sROaCPKfMxMHSLSNE1biQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIm9xlCtJV2b/2dsb2JhbAA7Cr5vFnOCHgEBAQMBAQEBNzQLBQcEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCIgDBgyoRpAwjD8Rg1FhA4tQhwOET4U+iW6Cc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="148518553" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 11 Dec 2012 05:03:38 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBB53cNj029903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 05:03:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.177]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 23:03:38 -0600 From: "Adarsh Kaithal (akaithal)" To: "Dawes, Peter, Vodafone Group" , "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt Thread-Index: AQHN1JdUalti9DbhSdSeWbKKk4gapZgSFaJQgAD58mA= Date: Tue, 11 Dec 2012 05:03:37 +0000 Message-ID: <91B51885BB796947A427A8CD3D8479B129E75DFE@xmb-rcd-x01.cisco.com> References: <201212071624.qB7GOTE02577681@shell01.TheWorld.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5E001@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB5E001@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.82.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 05:03:40 -0000 Hi Peter, It will be very important in the cases when intermediated entity (proxy or = B2BUA) also try to debug and collect the data for debugging without UA inte= rvention. Best Regards, Adarsh > -----Original Message----- > From: Dawes, Peter, Vodafone Group [mailto:Peter.Dawes@vodafone.com] > Sent: Monday, December 10, 2012 11:38 PM > To: Dale R. Worley; dispatch@ietf.org > Cc: Adarsh Kaithal (akaithal); Sandeep K.S (sandks) > Subject: RE: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt >=20 > Hello Dale, > I think you are right that the UAS (or some entity near it) would have to= echo > the mark from requests to responses, alternatively at least one entity wi= ll > have to be stateful and mark requests and responses so I will need to mod= ify > REQ4 on that point. Similarly, for requests that have crossed the trust > domain boundary and had the log-me marking removed, a SIP entity at the > network edge receiving a response would have to be stateful and re-insert > the log-me marking. >=20 > Probably the test case identifier could be Session-ID, although it would = be > convenient for the test equipment to be able to insert its own identifier= . I did > not expect this test case identifier to have any function in the SIP prot= ocol, > its purpose is to help the diagnostic server aggregate logging data. >=20 > The diagnostic server identifier is a locator for a server that is accumu= lating > the logging information and, as you suggest, it would be useful to > standardize the manner in which logging information is transmitted to the > specified server. I think that draft http://tools.ietf.org/id/draft-kaith= al- > dispatch-sip-log-information-00.txt suggests something in clause 5 with >=20 > log-type =3D "mailto" / "http"/ "syslog" / "tftp" /"ftp" /"sftp" / "loca= l" / other- > type >=20 > I think you are right that log-me marking will in some cases be inserted = by a > proxy that handles a UA's requests rather than by the UA itself, so I wil= l > make sure that is clear in the requirements. >=20 > Thanks for all of the useful pointers. >=20 > Regards, > Peter >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dale R. Worley > Sent: 07 December 2012 16:24 > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt >=20 > The situation regarding statelessness seems to me to be unclear. >=20 > Marking could be entirely stateless (at least for proxies) if each reques= t and > response to be logged was marked. But to make that work, we require that > the UAS (or some entity near it) echoes the mark from requests to respons= es. > Either we need to codify the mark-echoing, or we need to require proxies = be > transaction-stateful, in regard to remembering the mark on requests > requires logging responses. >=20 > At the dialog level, the "Skeleton Diagnostic Procedure" says: >=20 > o Subsequent responses and requests in the same dialog are logged. >=20 > This requires dialog-state in the UAs and intermediate entities, in order= to > remember to log subsequent requests and responses. We could avoid > requiring the intermediate entities to have dialog-state if we require th= e UAs > to remember that log-me is in effect for the dialog and apply it to all > subsequent requests. >=20 > Given that log-me marking is removed from requests when they cross trust > boundaries, how does a network apply the log-me marking to the > corresponding responses when they arrive across the trust boundary? > That can't depend on any marking on the response as supplied by the non- > trusting network. >=20 > In regard to the test case identifier and the diagnostic server identifie= r, are > these intended to be opaque strings, or what? >=20 > If the test case identifier is just to identify the test, its role could = be taken by > Session-ID. If it is required that the test equipment can specify the te= st case > identifier, we need a further data item. >=20 > In regard to the diagnostic server identifier, is it an opaque string to = be > interpreted according to an unspecified policy, or is it a locator for a = server > that is accumulating the logging information? If the latter, we presumab= ly > intend to standardize the manner in which logging information is > transmitted to the specified server. >=20 > In practice, it would seem to me that operators will often have the log-m= e > market inserted not by the customer's UA but by a proxy that handles the = UAs > requests. I don't see that this would cause problems for the design, but= it's a > use case to keep in mind. >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From victor.pascual.avila@gmail.com Mon Dec 17 14:29:25 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A46321F8880 for ; Mon, 17 Dec 2012 14:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPdqQ0IflIGi for ; Mon, 17 Dec 2012 14:29:24 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE2B21F8850 for ; Mon, 17 Dec 2012 14:29:23 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id r15so5175758lag.36 for ; Mon, 17 Dec 2012 14:29:22 -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 :content-type; bh=OvYkTQOrnzW4uCSydCZOJmUJ+OzvueJ6JOJHgIdmkJ8=; b=qUvhOzib5NA3u/dB0ooDUuAqQodXXfHfVrQGJJEodRXiEOvKI8krDbgKrWzOrO7+oZ ZLgXFlF378rdcCc4zlx1iYnx4qgSQsNd37dt8NapFpdl+6jhUPqHJHrqzWXMbrxQTtkT vFybIkLKX9JllIxJVIISBwWiuDX3NmvyYPPTDrj/qdH5M5817nxb9nCEiE0XA0zuhZfv M9d66lTMCEL08pk1/RQV3/rob0JHfajVj0tI2rtMmKmPsCQhIPy1JfLUp5KmkItnU53a PkDr/UWiaz562QI1n1lMlquxNJNneCVxd9cjZ5vqXCQL0P2DcPICEdekiQARWa7shrpo qQtw== MIME-Version: 1.0 Received: by 10.112.29.10 with SMTP id f10mr57525lbh.4.1355783362708; Mon, 17 Dec 2012 14:29:22 -0800 (PST) Received: by 10.114.76.203 with HTTP; Mon, 17 Dec 2012 14:29:22 -0800 (PST) In-Reply-To: References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 23:29:22 +0100 Message-ID: From: Victor Pascual Avila To: DISPATCH Content-Type: multipart/alternative; boundary=bcaec5555654ba069004d113e908 Subject: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:29:25 -0000 --bcaec5555654ba069004d113e908 Content-Type: text/plain; charset=UTF-8 Dear DISPATCH, comments on the draft below[1] would be appreciated. The proposed mechanism has been implemented and there's open-source code available for both client[2] and server[3] side implementations. [1] http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00 [2] http://code.google.com/p/crocodile-msrp/wiki/Overview [3] http://www.kamailio.org/wiki/features/new-in-devel#websocket Thanks, Peter, Gavin and Victor On 12/17/12 5:15 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-pd-dispatch-msrp-websocket-00.txt >has been successfully submitted by Peter Dunkley and posted to the >IETF repository. > >Filename: draft-pd-dispatch-msrp-websocket >Revision: 00 >Title: The WebSocket Protocol as a Transport for the Message Session >Relay Protocol (MSRP) >Creation date: 2012-12-17 >WG ID: Individual Submission >Number of pages: 19 >URL: >http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-00.tx >t >Status: >http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket >Htmlized: >http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00 > > >Abstract: > The WebSocket protocol enables two-way real-time communication > between clients and servers. This document specifies a new WebSocket > sub-protocol as a reliable transport mechanism between MSRP (Message > Session Relay Protocol) clients and relays to enable usage of MSRP in > new scenarios. This document normatively updates RFC 4975 and RFC > 4976. > > > > > >The IETF Secretariat > --bcaec5555654ba069004d113e908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear DISPATCH,

comments on the draft below[1] would be a= ppreciated. The proposed mechanism has been implemented and there's ope= n-source code available for both client[2] and server[3] side implementatio= ns.


Peter, Gavin and Victor<= /div>

On 12/17/12 5:15 PM, "inte= rnet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A new version of I-D, draft-pd-dispatch-msrp-websocket-00.txt
>has been successfully submitted by Peter Dunkley and posted to the
>IETF repository.
>
>Filename: =C2=A0 =C2=A0 =C2=A0 draft-pd-dispatch-msrp-websocket
>Revision: =C2=A0 =C2=A0 =C2=A0 00
>Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The WebSocket Protocol as a Tr= ansport for the Message Session
>Relay Protocol (MSRP)
>Creation date: =C2=A02012-12-17
>WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>Number of pages: 19
>URL:
>http://www.ietf.org/internet-drafts/draft= -pd-dispatch-msrp-websocket-00.tx
>t
>Status:
>http://datatracker.ietf.org/doc/draft-pd-dispatch-m= srp-websocket
>Htmlized:
>http://tools.ietf.org/html/draft-pd-dispatch-msrp-web= socket-00
>
>
>Abstract:
> =C2=A0 The WebSocket protocol enables two-way real-time communication<= br> > =C2=A0 between clients and servers. =C2=A0This document specifies a ne= w WebSocket
> =C2=A0 sub-protocol as a reliable transport mechanism between MSRP (Me= ssage
> =C2=A0 Session Relay Protocol) clients and relays to enable usage of M= SRP in
> =C2=A0 new scenarios. =C2=A0This document normatively updates RFC 4975= and RFC
> =C2=A0 4976.
>
>
>
>
>
>The IETF Secretariat
>
--bcaec5555654ba069004d113e908--