From gsalguei@cisco.com Mon Jul 1 12:04:46 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8921F9951 for ; Mon, 1 Jul 2013 12:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP95M6BXVmkL for ; Mon, 1 Jul 2013 12:04:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id D516811E819C for ; Mon, 1 Jul 2013 12:04:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r61J4UHt023906 for ; Mon, 1 Jul 2013 15:04:30 -0400 (EDT) Received: from rtp-vpn2-1558.cisco.com (rtp-vpn2-1558.cisco.com [10.82.246.24]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r61J4T3o009181 for ; Mon, 1 Jul 2013 15:04:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <080f01ce67b9$3f22d0a0$bd6871e0$@packetizer.com> Date: Mon, 1 Jul 2013 15:04:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B6BDDD0-D939-4619-A16C-F1A9B781E1D8@cisco.com> References: <080f01ce67b9$3f22d0a0$bd6871e0$@packetizer.com> To: "insipid@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:04:46 -0000 The chairs would like to kindly request that folks please take some time = to review this latest version and provide any feedback. This document = had only a few pending issues preventing us from moving forward with = WGLC. The authors believe those have been addressed.=20 To ensure discussion at the meeting is as productive as possible, timely = feedback is greatly appreciated in the event a new version is required = prior to the cutoff. Gonzalo & Keith On Jun 12, 2013, at 6:07 PM, Paul E. Jones = wrote: > Folks, > =20 > Taking input from various folks, I posted a revision to the = requirements document. Please have a look and provide comments. > =20 > Paul > =20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Mon Jul 1 13:33:28 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2DE11E826E for ; Mon, 1 Jul 2013 13:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-xmTQ+l28UT for ; Mon, 1 Jul 2013 13:33:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 96A3D11E8254 for ; Mon, 1 Jul 2013 13:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1188; q=dns/txt; s=iport; t=1372710803; x=1373920403; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=xQVaRW57zokEVthKQLSBgtZCEDIsG/y8OJYk6L6R3WA=; b=cddeH/v05wtRbn0FcjeafVzKmMd+H09z7d+6XUYjoaMAvzOz4odUVsSw uyOI9JiCdKupfBmaB8fqHUdybWrcaFc2BD6g+fHI7Fj84m+HlKtOlEIiF Yy8A1tmKsx8TRA3vjJ+CqLX/8Mttji2sF4GoVtPsb0yavCIgvYY1bnCHb g=; X-IronPort-AV: E=Sophos;i="4.87,975,1363132800"; d="scan'208";a="229621225" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 01 Jul 2013 20:33:23 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r61KXMfW003090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 20:33:23 GMT Message-Id: <201307012033.r61KXMfW003090@rcdn-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Jul 2013 15:33:22 -0500 To: Gonzalo Salgueiro , "insipid@ietf.org" From: James Polk In-Reply-To: <4B6BDDD0-D939-4619-A16C-F1A9B781E1D8@cisco.com> References: <080f01ce67b9$3f22d0a0$bd6871e0$@packetizer.com> <4B6BDDD0-D939-4619-A16C-F1A9B781E1D8@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 20:33:28 -0000 this is a brilliant piece of technical writing! I endorse all that this version has in it as is. -j At 02:04 PM 7/1/2013, Gonzalo Salgueiro wrote: >The chairs would like to kindly request that folks please take some >time to review this latest version and provide any feedback. This >document had only a few pending issues preventing us from moving >forward with WGLC. The authors believe those have been addressed. > >To ensure discussion at the meeting is as productive as possible, >timely feedback is greatly appreciated in the event a new version is >required prior to the cutoff. > >Gonzalo & Keith > > > > >On Jun 12, 2013, at 6:07 PM, Paul E. Jones wrote: > > > Folks, > > > > Taking input from various folks, I posted a revision to the > requirements document. Please have a look and provide comments. > > > > Paul > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From eckelcu@cisco.com Tue Jul 2 08:12:11 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED6521F9E16 for ; Tue, 2 Jul 2013 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0UtF-r2S9xc for ; Tue, 2 Jul 2013 08:12:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1B34621F9DB6 for ; Tue, 2 Jul 2013 08:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1580; q=dns/txt; s=iport; t=1372777924; x=1373987524; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MQg1eOEVwgO0vQgwZQKzFILs7Ze9/gbbeywLrG+hAVM=; b=c3nvYm5OhJL+xtxuyWBB7R/JNW76AeDQOav8p32WisxeNVOAeQ/b1Qy3 zKHibznUPMzQX62Y3NMBtc4qT8XJlDnTlycezT/FeXhI0ywatUNLwVG7E FBrspcCTOD1S7aJfBOwG7lTXWG5FW6DvkW6BTfRwQACWUYNOOQso3tdfg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAJfr0lGtJV2Z/2dsb2JhbABagwkySb9OgQEWdIIjAQEBBAEBATc0FwQCAQgRBAEBAQoUCQcnCxQJCAEBBAESCIgHDLwWBI8pOAaCfmcDqQ6DEYIo X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229975581" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 02 Jul 2013 15:12:03 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r62FC3SQ016206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Jul 2013 15:12:03 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.187]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 10:12:03 -0500 From: "Charles Eckel (eckelcu)" To: "Gonzalo Salgueiro (gsalguei)" , "insipid@ietf.org" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-reqts-07 Thread-Index: Ac5nuSZ2l6Zo+81TSHWtsMCcwYT1lgO/pI6AAB+GWvA= Date: Tue, 2 Jul 2013 15:12:02 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828048AA192@xmb-aln-x08.cisco.com> References: <080f01ce67b9$3f22d0a0$bd6871e0$@packetizer.com> <4B6BDDD0-D939-4619-A16C-F1A9B781E1D8@cisco.com> In-Reply-To: <4B6BDDD0-D939-4619-A16C-F1A9B781E1D8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.80.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:12:11 -0000 The changes look good to me. They remove any duplicate or conflicting defin= itions. The draft reads better now. Thanks to the authors for their persist= ence in getting the draft to this state. Cheers, Charles =20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Gonzalo Salgueiro (gsalguei) > Sent: Monday, July 01, 2013 12:04 PM > To: insipid@ietf.org > Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-07 >=20 > The chairs would like to kindly request that folks please take some time = to > review this latest version and provide any feedback. This document had o= nly a > few pending issues preventing us from moving forward with WGLC. The > authors believe those have been addressed. >=20 > To ensure discussion at the meeting is as productive as possible, timely > feedback is greatly appreciated in the event a new version is required pr= ior to > the cutoff. >=20 > Gonzalo & Keith >=20 >=20 >=20 >=20 > On Jun 12, 2013, at 6:07 PM, Paul E. Jones wrote: >=20 > > Folks, > > > > Taking input from various folks, I posted a revision to the requirement= s > document. Please have a look and provide comments. > > > > Paul > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Wed Jul 3 17:02:31 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56411E8108 for ; Wed, 3 Jul 2013 17:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hce9SX5LbrRi for ; Wed, 3 Jul 2013 17:02:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE2E611E8104 for ; Wed, 3 Jul 2013 17:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5142; q=dns/txt; s=iport; t=1372896147; x=1374105747; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=Xut28qeW79x2UlkpClCs+774qCSiuioYm7haKcpLRMY=; b=Sv254PkhmVUcjLOWHcGoMf83gZTr+UfNJJux/rkKnVl42JwqWXL6FNeh 5c80pqbz8Ia3stiBT5CoX8NjaNBF2Sc/Jk+8MtaaeuGODTjaZTBb6qgU9 zy5ZNuYt19Lz48W4lFjJcnl8zacLqeDhD/biaKF0UPovWu9rVfxuxi3ZA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACW71FGtJV2a/2dsb2JhbABagwkywQWBCRZ0giMBAQEEAQEBJBECNAsQBwQOCgkVEA8KDjAGCgmIDwy6IwSPaweDbQOJI4pUlReDLx6BLAQB X-IronPort-AV: E=Sophos;i="4.87,991,1363132800"; d="scan'208";a="227790106" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 04 Jul 2013 00:02:26 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6402PjJ029041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2013 00:02:26 GMT Message-Id: <201307040002.r6402PjJ029041@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Jul 2013 19:02:25 -0500 To: Robert Sparks From: James Polk In-Reply-To: <51657669.2090701@nostrum.com> References: <515C9D18.706@nostrum.com> <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> <5164ABE5.9010602@nostrum.com> <0be001ce35b6$c026eea0$4074cbe0$@packetizer.com> <51657669.2090701@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "Paul E. Jones" , insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 00:02:31 -0000 Robert Can you pick out a call flow from an existing RFC or ID that you would like for me to add in a Session-ID to for each of the following messages: - 100 Trying - CANCEL and - whatever other messages you would like to see in s9 Just give me the doc name and which figure in said doc you want me to include a Session-ID in that call flow, and I'll do it. Thanks James At 09:25 AM 4/10/2013, Robert Sparks wrote: >Thanks Paul - > >Trimming heavily to just a couple of things. > >On 4/10/13 1:43 AM, Paul E. Jones wrote: >> >> >>PEJ: I got the point. What you said is correct, which is why I >>used the language "sender of the message". If that's not clear, >>how can we make it clear? >Add a sentence that says something like this: > >"Note that unlike To and From tags which remain in the same order in >the request and all responses to the request, the components of the >Session-ID in each response will in the reversed order from the request". > >I'm sure that needs wordsmithing though. > >Now, for the martian value conversation, using this figure again, >but still trimming heavily: >> >>(Again, view in a fixed-width font) >>Alice Intermediary >> | S:{A} | >> |-------->| >> | S:{B,A} | >> |<--------| >> | | (the service interactions section 6 paragraph 3 mentions >> | S:{B,M} | happen somewhere over here) >> |<--------| >(leaving this bit for context) >>You are saying that the next message alice sends in that session >>should contain S:{A,B}, and would never contain an M. >>The document does not yet say that. >> >>PEJ: The text says Alice would never change her UUID for the >>duration of the session. She would always send {A, >received in the most recent message>}. If that's not clear, it >>should be simple to clarify it. I'll admit I might be conveying >>something that's not written clearly, since I know what I >>expect. But, I'm missing why it's not clear. In the above flow, >>Alice received a message from B to her (A). >Here's what I want to talk about. >>Then she received a message from B to her, but this time >>mislabeled. I don't see how that can happen. >I think we're identifying then that the document needs to be clearer >when you move paragraph 3 of section 6. >Right now, the document explicitly _says_ that figure can happen. >Look at the figure and this text. If the text is >meant to say something that prevents (or at least does not imply) >that picture, call it out. > > It should be noted that messages received by a UA might contain a > "remote" parameter that does match the UAs UUID. This might happen > as a result of service interactions by intermediaries and MUST NOT be > regarded as an error. > >>Now, had B been transferred to C (using some non-standard >>signaling), C might send a message to A that was {C,M}. Alice >>should accept that (as per Section 6). But, I would not expect the above flow. >So more explanation in the document about what could lead to the >condition is in order (providing an full example of the service >interaction involved), and I think we need to dive a level of detail lower. > >Are you saying that inside a given SIP dialog, you know of no way >that Alice would receive a message with a Session-ID containing a >remote-uuid did not match what Alice had provided in an earlier uuid? > >If so, then the only time this could occur is in an out of dialog >message (like an initial INVITE). Are you sure that whatever >circumstances that led to there being a remote-uuid in that message >wouldn't also have lead to there being a non-empty to-tag? If it >did, Alice would reject the message with a 481. If you _can_ think >of a circumstance where Alice would get an initial message with a >populated remote-uuid that she didn't provide that was otherwise >admissible SIP, could you put a description of it in the document? > >Either way, in the text you are working on re: not using the >remote-uuid, please explicitly call out the case of one showing >up in an out-of-dialog message. >> >> >>I would not expect there to be a Session-ID header in a 100 Trying since >> >>it's not generated by an endpoint. Since 9.2 is a little busy, would you >> >>rather see this in 9.1? >>_REALLY_? >>I don't expect the working group to agree with you, but let's ask. >>Those folks wanting to be able to grab messages to do diagnostics >>are going to be _seriously_ interested in those hop-by-hop cancels, >>100s, 200 OKs, and ACKs. >> >>PEJ: I didn't speak of CANCEL or 200, just 100 Trying. What would >>make sense in a 100? >Whatever appeared in the INVITE the 100 is squelching the retransmissions of >(with local and remote reversed). >That squelching of retransmissions is why the people that are >looking at using this for diagnostic >purposes are going to really want to be able to find those 100s. > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From gsalguei@cisco.com Fri Jul 5 13:05:15 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892E621F9F50 for ; Fri, 5 Jul 2013 13:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geFSZKzzaJ58 for ; Fri, 5 Jul 2013 13:05:11 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD221F9F48 for ; Fri, 5 Jul 2013 13:05:11 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r65K59UI011139 for ; Fri, 5 Jul 2013 16:05:09 -0400 (EDT) Received: from rtp-vpn2-1558.cisco.com (rtp-vpn2-1558.cisco.com [10.82.246.24]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r65K55CH014223; Fri, 5 Jul 2013 16:05:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: Date: Fri, 5 Jul 2013 16:05:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "insipid@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: insipid-chairs@tools.ietf.org Subject: Re: [Insipid] INSIPID Session has been scheduled for IETF 87 (Berlin) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 20:05:15 -0000 INSIPID had some conflicts and needed to be re-scheduled. We got a = slightly shorter timeslot (1.5 hours) and it moved from Monday afternoon = to Thursday afternoon. =20 The new scheduling info for INSIPID is now: --------------------------------------------------------- insipid Session 1 (1:30:00) Thursday, Afternoon Session II 1520-1650 Room Name: Charlottenburg 1 Length of Session(s): 2 Hours Number of Attendees: 40 --------------------------------------------------------- This should be pretty much set in stone at this point. Please let the = chairs know (if you haven't already) if you have any topics you feel = should be covered and/or would like a speaking slot. Cheers, Gonzalo & Keith On Jun 28, 2013, at 2:28 AM, Gonzalo Salgueiro = wrote: > The INSIPID session has been scheduled for IETF87 in Berlin: =20 >=20 > --------------------------------------------- > insipid Session 1 (2:00:00) > Monday, Afternoon Session I 1300-1500 > Room Name: Charlottenburg 1 > Length of Session(s): 2 Hours > Number of Attendees: 40 > --------------------------------------------- >=20 > Note that this is still subject to change, as swaps are going on to = resolve conflicts. RAI area tends to be fairly stable, but changes can = always occur. >=20 > Additionally, while I think the chairs have a reasonably good idea of = what we think should be on the agenda, if you have specific requests, = now would be the time to send them to the chairs. >=20 > Regards >=20 > Gonzalo & Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From internet-drafts@ietf.org Mon Jul 8 15:47:49 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAE611E80AE; Mon, 8 Jul 2013 15:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N48FP6pDuUyG; Mon, 8 Jul 2013 15:47:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2074321F9E80; Mon, 8 Jul 2013 15:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708224749.1155.90049.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 15:47:49 -0700 Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-01.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 22:47:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the INtermediary-safe SIP session ID Working = Group of the IETF. Title : End-to-End Session Identification in IP-Based Multimedia= Communication Networks Author(s) : Paul E. Jones Chris Pearce James Polk Gonzalo Salgueiro Filename : draft-ietf-insipid-session-id-01.txt Pages : 20 Date : 2013-07-08 Abstract: This document describes an end-to-end Session Identifier for use in IP-based Multimedia Communication systems that enables endpoints, intermediate devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-insipid-session-id-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-insipid-session-id-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Mon Jul 8 16:17:19 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303FD21F9546 for ; Mon, 8 Jul 2013 16:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEZCz+JKUe95 for ; Mon, 8 Jul 2013 16:17:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDEB21F9AD1 for ; Mon, 8 Jul 2013 16:17:13 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r68NHBqh029778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 8 Jul 2013 19:17:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1373325432; bh=ckcvSED3lLOJykvuC6h9uSS4Kj9VcaazHMOvHA+XUPo=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=GFju/TovV1uXcsbBSfnv1oB834+Gzww0aDARrbhD54j1BHNRs2GDAABLO6fAi8of/ fyzzcb5W1/YzuNJajHlmrmYD+AFLLJ8oyrVr9GZBQHjKPLD3e6UCHx8UJGiC+QbjQ6 3K0QzRgZB2r5fjuTNd1m85pqnWcSwJDAT2ocrIA8= From: "Paul E. Jones" To: Date: Mon, 8 Jul 2013 19:17:15 -0400 Message-ID: <032c01ce7c31$48ea00e0$dabe02a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac58MC0dGJ9B9+pdQO+VryJ4gzrSmQ== Subject: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 23:17:19 -0000 Folks, I posted a new version of draft-ietf-insipid-session-id for your consideration. One significant addition is one to address a comment Laura had about ensuring that intermediary devices can consistently re-create a UUID and remain stateless. New text is introduced in Section 4.1 that describes how such entities can construct the UUIDs. Section 6 was also revised with text to explain that the UUID order relates to who sends the message. It also discusses the longevity of the UUID, logging, and changes to the "remote" UUID. Previously, requests were made for additional call flows. Those were not added to the document, but the requests are listed as TODO items in section(s) under section 9. There is also a TODO for section 9 related to requested changes to section 9 to make it cleared the text is just examples. Paul From keith.drage@alcatel-lucent.com Mon Jul 8 17:09:59 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBDD11E80E3 for ; Mon, 8 Jul 2013 17:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faIoZTWp35ac for ; Mon, 8 Jul 2013 17:09:52 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C329221F9829 for ; Mon, 8 Jul 2013 17:09:52 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6909l7A009044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jul 2013 19:09:49 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6909l7f025050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Jul 2013 02:09:47 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 9 Jul 2013 02:09:47 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: WGLC for draft-ietf-insipid-session-id-reqts-07 Thread-Index: Ac58OGhKYBWRLys3QOmOsXUVqzCOig== Date: Tue, 9 Jul 2013 00:09:46 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 00:09:59 -0000 (As WG co chair) This document has been around for 3 or 4 weeks now and has attracted no com= ments to update it. The chairs would therefore like to make a further one week WGLC to check th= at the document has been finished and ready to do a publication request. So if you have any comments before we request IESG to approve this as an in= formational document, then please make them by close of business on 16th Ju= ly. Regards Keith Title : Requirements for an End-to-End Session Identification in= IP-Based Multimedia Communication Networks Author(s) : Paul E. Jones Gonzalo Salgueiro James Polk Laura Liess Hadriel Kaplan Filename : draft-ietf-insipid-session-id-reqts-07.txt Pages : 11 Date : 2013-06-12 Abstract: This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. From keith.drage@alcatel-lucent.com Mon Jul 8 17:41:25 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F95611E80F2 for ; Mon, 8 Jul 2013 17:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j4xl-WpRwdO for ; Mon, 8 Jul 2013 17:41:20 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAEF11E80EF for ; Mon, 8 Jul 2013 17:41:19 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r690fGad010818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Jul 2013 19:41:18 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r690fCMA015588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Jul 2013 02:41:16 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 9 Jul 2013 02:41:12 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-01 Thread-Index: Ac58MC0dGJ9B9+pdQO+VryJ4gzrSmQADIbnA Date: Tue, 9 Jul 2013 00:41:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B066DAF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <032c01ce7c31$48ea00e0$dabe02a0$@packetizer.com> In-Reply-To: <032c01ce7c31$48ea00e0$dabe02a0$@packetizer.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 00:41:25 -0000 (As WG cochair) As well as reviewing the document generally, it would be useful if the WG m= embership could indicate any issues they think need face to face discussion= time in Berlin. Or is everything going perfectly? Apart from what is listed below, is anything else missing from the document= ? Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Paul E. Jones > Sent: 09 July 2013 00:17 > To: insipid@ietf.org > Subject: [Insipid] draft-ietf-insipid-session-id-01 >=20 > Folks, >=20 > I posted a new version of draft-ietf-insipid-session-id for your > consideration. >=20 > One significant addition is one to address a comment Laura had about > ensuring that intermediary devices can consistently re-create a UUID and > remain stateless. New text is introduced in Section 4.1 that describes > how > such entities can construct the UUIDs. >=20 > Section 6 was also revised with text to explain that the UUID order > relates > to who sends the message. It also discusses the longevity of the UUID, > logging, and changes to the "remote" UUID. >=20 > Previously, requests were made for additional call flows. Those were not > added to the document, but the requests are listed as TODO items in > section(s) under section 9. There is also a TODO for section 9 related t= o > requested changes to section 9 to make it cleared the text is just > examples. >=20 > Paul >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Tue Jul 9 05:42:34 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FBC21F9FE4 for ; Tue, 9 Jul 2013 05:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy78HwszmlwS for ; Tue, 9 Jul 2013 05:42:26 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7353021F9FF4 for ; Tue, 9 Jul 2013 05:42:26 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r69CgNjt012979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 9 Jul 2013 07:42:24 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r69CgMN4030194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Jul 2013 14:42:23 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 9 Jul 2013 14:42:23 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: WGLC for draft-ietf-insipid-session-id-reqts-07 Thread-Index: Ac58OGhKYBWRLys3QOmOsXUVqzCOigAaK6tw Date: Tue, 9 Jul 2013 12:42:22 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 12:42:34 -0000 (As WG cochair) I've just been double checking, and having thought that we had already had = a WGLC on it, I find that formally, this is the first. I will therefore ext= end this WGLC until 23rd July 2013 to give it the full 2 weeks. I'd also remind you that there are a number of IPR declarations against thi= s document https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_docume= nt_tag=3Ddraft-ietf-insipid-session-id-reqts=20 I believe we have briefly discussed these in the past, but please raise any= concerns you have with proceeding with the draft in the presence of these = declarations. Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: 09 July 2013 01:10 > To: insipid@ietf.org > Subject: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 >=20 > (As WG co chair) >=20 > This document has been around for 3 or 4 weeks now and has attracted no > comments to update it. >=20 > The chairs would therefore like to make a further one week WGLC to check > that the document has been finished and ready to do a publication request= . >=20 > So if you have any comments before we request IESG to approve this as an > informational document, then please make them by close of business on 16t= h > July. >=20 > Regards >=20 > Keith >=20 >=20 > Title : Requirements for an End-to-End Session > Identification in IP-Based Multimedia Communication Networks > Author(s) : Paul E. Jones > Gonzalo Salgueiro > James Polk > Laura Liess > Hadriel Kaplan > Filename : draft-ietf-insipid-session-id-reqts-07.txt > Pages : 11 > Date : 2013-06-12 >=20 > Abstract: > This document specifies the requirements for an end-to-end session > identifier in IP-based multimedia communication networks. This > identifier would enable endpoints, intermediate devices, and > management and monitoring systems to identify a session end-to-end > across multiple SIP devices, hops, and administrative domains. > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From rjsparks@nostrum.com Tue Jul 9 15:10:34 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C626321F8447 for ; Tue, 9 Jul 2013 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLdDp2NPYf8a for ; Tue, 9 Jul 2013 15:10:34 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 363D821F8FF8 for ; Tue, 9 Jul 2013 15:10:13 -0700 (PDT) Received: from unnumerable.local (mobile-166-147-068-200.mycingular.net [166.147.68.200]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r69MAA29065510 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 9 Jul 2013 17:10:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51DC8A3D.5050308@nostrum.com> Date: Tue, 09 Jul 2013 17:10:05 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: James Polk References: <515C9D18.706@nostrum.com> <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> <5164ABE5.9010602@nostrum.com> <0be001ce35b6$c026eea0$4074cbe0$@packetizer.com> <51657669.2090701@nostrum.com> <201307040002.r6402PjJ029041@rcdn-core-3.cisco.com> In-Reply-To: <201307040002.r6402PjJ029041@rcdn-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 166.147.68.200 is authenticated by a trusted mechanism) Cc: "Paul E. Jones" , insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 22:10:34 -0000 On 7/3/13 7:02 PM, James Polk wrote: > Robert > > Can you pick out a call flow from an existing RFC or ID that you would > like for me to add in a Session-ID to for each of the following messages: > > - 100 Trying > - CANCEL and I went looking for a minimal call flow that showed 100 Trying with forking. I was really surprised to not find a good one in the RFC series already (unless I've just missed it). You can get started with https://datatracker.ietf.org/doc/rfc3665 section 3.8, but it will miss the important differences you will get into when you have more than one branch in a fork (particularly if each leg has established early media) that I think you should consider. I'll ask on sipcore if anybody else can find an already published example that I've missed. If not, I'll make one for you. > - whatever other messages you would like to see in s9 You asked separately about OOD refer - you might look at 5589 section 6.1 for that one. RjS > > Just give me the doc name and which figure in said doc you want me to > include a Session-ID in that call flow, and I'll do it. > > Thanks > > James > > At 09:25 AM 4/10/2013, Robert Sparks wrote: >> Thanks Paul - >> >> Trimming heavily to just a couple of things. >> >> On 4/10/13 1:43 AM, Paul E. Jones wrote: >>> >>> >>> PEJ: I got the point. What you said is correct, which is why I used >>> the language "sender of the message". If that's not clear, how can >>> we make it clear? >> Add a sentence that says something like this: >> >> "Note that unlike To and From tags which remain in the same order in >> the request and all responses to the request, the components of the >> Session-ID in each response will in the reversed order from the >> request". >> >> I'm sure that needs wordsmithing though. >> >> Now, for the martian value conversation, using this figure again, but >> still trimming heavily: >>> >>> (Again, view in a fixed-width font) >>> Alice Intermediary >>> | S:{A} | >>> |-------->| >>> | S:{B,A} | >>> |<--------| >>> | | (the service interactions section 6 paragraph 3 mentions >>> | S:{B,M} | happen somewhere over here) >>> |<--------| >> (leaving this bit for context) >>> You are saying that the next message alice sends in that session >>> should contain S:{A,B}, and would never contain an M. >>> The document does not yet say that. >>> >>> PEJ: The text says Alice would never change her UUID for the >>> duration of the session. She would always send {A, >> received in the most recent message>}. If that's not clear, it >>> should be simple to clarify it. I'll admit I might be conveying >>> something that's not written clearly, since I know what I expect. >>> But, I'm missing why it's not clear. In the above flow, Alice >>> received a message from B to her (A). >> Here's what I want to talk about. >>> Then she received a message from B to her, but this time >>> mislabeled. I don't see how that can happen. >> I think we're identifying then that the document needs to be clearer >> when you move paragraph 3 of section 6. >> Right now, the document explicitly _says_ that figure can happen. >> Look at the figure and this text. If the text is >> meant to say something that prevents (or at least does not imply) >> that picture, call it out. >> >> It should be noted that messages received by a UA might contain a >> "remote" parameter that does match the UAs UUID. This might happen >> as a result of service interactions by intermediaries and MUST NOT be >> regarded as an error. >> >>> Now, had B been transferred to C (using some non-standard >>> signaling), C might send a message to A that was {C,M}. Alice >>> should accept that (as per Section 6). But, I would not expect the >>> above flow. >> So more explanation in the document about what could lead to the >> condition is in order (providing an full example of the service >> interaction involved), and I think we need to dive a level of detail >> lower. >> >> Are you saying that inside a given SIP dialog, you know of no way >> that Alice would receive a message with a Session-ID containing a >> remote-uuid did not match what Alice had provided in an earlier uuid? >> >> If so, then the only time this could occur is in an out of dialog >> message (like an initial INVITE). Are you sure that whatever >> circumstances that led to there being a remote-uuid in that message >> wouldn't also have lead to there being a non-empty to-tag? If it did, >> Alice would reject the message with a 481. If you _can_ think of a >> circumstance where Alice would get an initial message with a >> populated remote-uuid that she didn't provide that was otherwise >> admissible SIP, could you put a description of it in the document? >> >> Either way, in the text you are working on re: not using the >> remote-uuid, please explicitly call out the case of one showing >> up in an out-of-dialog message. >>> >>> >>> I would not expect there to be a Session-ID header in a 100 Trying >>> since >>> >>> it's not generated by an endpoint. Since 9.2 is a little busy, >>> would you >>> >>> rather see this in 9.1? >>> _REALLY_? >>> I don't expect the working group to agree with you, but let's ask. >>> Those folks wanting to be able to grab messages to do diagnostics >>> are going to be _seriously_ interested in those hop-by-hop cancels, >>> 100s, 200 OKs, and ACKs. >>> >>> PEJ: I didn't speak of CANCEL or 200, just 100 Trying. What would >>> make sense in a 100? >> Whatever appeared in the INVITE the 100 is squelching the >> retransmissions of >> (with local and remote reversed). >> That squelching of retransmissions is why the people that are looking >> at using this for diagnostic >> purposes are going to really want to be able to find those 100s. >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > From rjsparks@nostrum.com Wed Jul 10 13:43:38 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC23821F9DBC for ; Wed, 10 Jul 2013 13:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfgEbw9MYcRk for ; Wed, 10 Jul 2013 13:43:38 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D329A21F8956 for ; Wed, 10 Jul 2013 13:43:37 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6AKhavZ021676 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Wed, 10 Jul 2013 15:43:37 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51DDC778.2070609@nostrum.com> Date: Wed, 10 Jul 2013 15:43:36 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: insipid@ietf.org References: <515C9D18.706@nostrum.com> <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> <5164ABE5.9010602@nostrum.com> <0be001ce35b6$c026eea0$4074cbe0$@packetizer.com> <51657669.2090701@nostrum.com> <201307040002.r6402PjJ029041@rcdn-core-3.cisco.com> <51DC8A3D.5050308@nostrum.com> In-Reply-To: <51DC8A3D.5050308@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:43:38 -0000 Dale suggests: rfc 5359 section 2.9 That's a good starting point - it has 180s from two legs. I think it would help illuminate things to add 100s before those 180s, and replace the 180s with 183s (with answers). The forking shown there is serial, but it should still help make sure we're thinking about what the right values are - please think through what would be different, if anything, if the forking were parallel (both legs active at the same time). Thanks again Dale! RjS On 7/9/13 5:10 PM, Robert Sparks wrote: > On 7/3/13 7:02 PM, James Polk wrote: >> Robert >> >> Can you pick out a call flow from an existing RFC or ID that you >> would like for me to add in a Session-ID to for each of the following >> messages: >> >> - 100 Trying >> - CANCEL and > I went looking for a minimal call flow that showed 100 Trying with > forking. > I was really surprised to not find a good one in the RFC series > already (unless I've just missed it). > > You can get started with https://datatracker.ietf.org/doc/rfc3665 > section 3.8, but it will miss > the important differences you will get into when you have more than > one branch in a fork (particularly > if each leg has established early media) that I think you should > consider. > > I'll ask on sipcore if anybody else can find an already published > example that I've missed. If not, I'll make > one for you. >> - whatever other messages you would like to see in s9 > You asked separately about OOD refer - you might look at 5589 section > 6.1 for that one. > > RjS >> >> Just give me the doc name and which figure in said doc you want me to >> include a Session-ID in that call flow, and I'll do it. >> >> Thanks >> >> James >> >> At 09:25 AM 4/10/2013, Robert Sparks wrote: >>> Thanks Paul - >>> >>> Trimming heavily to just a couple of things. >>> >>> On 4/10/13 1:43 AM, Paul E. Jones wrote: >>>> >>>> >>>> PEJ: I got the point. What you said is correct, which is why I >>>> used the language "sender of the message". If that's not clear, >>>> how can we make it clear? >>> Add a sentence that says something like this: >>> >>> "Note that unlike To and From tags which remain in the same order in >>> the request and all responses to the request, the components of the >>> Session-ID in each response will in the reversed order from the >>> request". >>> >>> I'm sure that needs wordsmithing though. >>> >>> Now, for the martian value conversation, using this figure again, >>> but still trimming heavily: >>>> >>>> (Again, view in a fixed-width font) >>>> Alice Intermediary >>>> | S:{A} | >>>> |-------->| >>>> | S:{B,A} | >>>> |<--------| >>>> | | (the service interactions section 6 paragraph 3 mentions >>>> | S:{B,M} | happen somewhere over here) >>>> |<--------| >>> (leaving this bit for context) >>>> You are saying that the next message alice sends in that session >>>> should contain S:{A,B}, and would never contain an M. >>>> The document does not yet say that. >>>> >>>> PEJ: The text says Alice would never change her UUID for the >>>> duration of the session. She would always send {A, >>> received in the most recent message>}. If that's not clear, it >>>> should be simple to clarify it. I'll admit I might be conveying >>>> something that's not written clearly, since I know what I expect. >>>> But, I'm missing why it's not clear. In the above flow, Alice >>>> received a message from B to her (A). >>> Here's what I want to talk about. >>>> Then she received a message from B to her, but this time >>>> mislabeled. I don't see how that can happen. >>> I think we're identifying then that the document needs to be clearer >>> when you move paragraph 3 of section 6. >>> Right now, the document explicitly _says_ that figure can happen. >>> Look at the figure and this text. If the text is >>> meant to say something that prevents (or at least does not imply) >>> that picture, call it out. >>> >>> It should be noted that messages received by a UA might contain a >>> "remote" parameter that does match the UAs UUID. This might happen >>> as a result of service interactions by intermediaries and MUST >>> NOT be >>> regarded as an error. >>> >>>> Now, had B been transferred to C (using some non-standard >>>> signaling), C might send a message to A that was {C,M}. Alice >>>> should accept that (as per Section 6). But, I would not expect the >>>> above flow. >>> So more explanation in the document about what could lead to the >>> condition is in order (providing an full example of the service >>> interaction involved), and I think we need to dive a level of detail >>> lower. >>> >>> Are you saying that inside a given SIP dialog, you know of no way >>> that Alice would receive a message with a Session-ID containing a >>> remote-uuid did not match what Alice had provided in an earlier uuid? >>> >>> If so, then the only time this could occur is in an out of dialog >>> message (like an initial INVITE). Are you sure that whatever >>> circumstances that led to there being a remote-uuid in that message >>> wouldn't also have lead to there being a non-empty to-tag? If it >>> did, Alice would reject the message with a 481. If you _can_ think >>> of a circumstance where Alice would get an initial message with a >>> populated remote-uuid that she didn't provide that was otherwise >>> admissible SIP, could you put a description of it in the document? >>> >>> Either way, in the text you are working on re: not using the >>> remote-uuid, please explicitly call out the case of one showing >>> up in an out-of-dialog message. >>>> >>>> >>>> I would not expect there to be a Session-ID header in a 100 Trying >>>> since >>>> >>>> it's not generated by an endpoint. Since 9.2 is a little busy, >>>> would you >>>> >>>> rather see this in 9.1? >>>> _REALLY_? >>>> I don't expect the working group to agree with you, but let's ask. >>>> Those folks wanting to be able to grab messages to do diagnostics >>>> are going to be _seriously_ interested in those hop-by-hop cancels, >>>> 100s, 200 OKs, and ACKs. >>>> >>>> PEJ: I didn't speak of CANCEL or 200, just 100 Trying. What would >>>> make sense in a 100? >>> Whatever appeared in the INVITE the 100 is squelching the >>> retransmissions of >>> (with local and remote reversed). >>> That squelching of retransmissions is why the people that are >>> looking at using this for diagnostic >>> purposes are going to really want to be able to find those 100s. >>> >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From internet-drafts@ietf.org Mon Jul 15 12:16:36 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF8711E81B4; Mon, 15 Jul 2013 12:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1ADB1xhvlGv; Mon, 15 Jul 2013 12:16:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 851EC11E81D1; Mon, 15 Jul 2013 12:16:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:16:35 -0700 Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:16:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the INtermediary-safe SIP session ID Working = Group of the IETF. Title : End-to-End Session Identification in IP-Based Multimedia= Communication Networks Author(s) : Paul E. Jones Chris Pearce James Polk Gonzalo Salgueiro Filename : draft-ietf-insipid-session-id-02.txt Pages : 25 Date : 2013-07-15 Abstract: This document describes an end-to-end Session Identifier for use in IP-based Multimedia Communication systems that enables endpoints, intermediate devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-insipid-session-id-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-insipid-session-id-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Mon Jul 15 14:01:14 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2321E8098 for ; Mon, 15 Jul 2013 14:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3oMJsibFtrm for ; Mon, 15 Jul 2013 14:01:10 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4A21E8186 for ; Mon, 15 Jul 2013 14:01:07 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id 0d7D1m0081vXlb851l166s; Mon, 15 Jul 2013 21:01:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 0l161m00j3ZTu2S3dl16bf; Mon, 15 Jul 2013 21:01:06 +0000 Message-ID: <51E46311.8070902@alum.mit.edu> Date: Mon, 15 Jul 2013 17:01:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: insipid@ietf.org References: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> In-Reply-To: <20130715191635.11306.95537.idtracker@ietfa.amsl.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=1373922066; bh=Dm2nz843tbYWiZvmYQUQkSiDfNmAi/EjqbAZiNlPXhc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b8MXY+5DUGGUjjz7NxiRuM7yekScI3zzeO2WaOqBo+i//VAWjK5lVKtUA4JMsqd7d 4/K9+MnKr5wDuONCwlUwCeYlcn0pM9WyhI8KpkKkj/grF7Y2sJycLG5n23Llr6Ag3l fOzMCFUO5afb8Te4jcYY1g/gHqZ+Yvm7ofmr6y+TuHlpuiwCoeFtXGVF4JQcpmvL82 FTnwTcPu3NAtlyJgdfU2pZpO9NcSTEqqIfKHz8sFMnk0BJVmxoNohVVaBwVSfIKS80 LPecMQ7sucLPNCbiEElxe6yUUAnT94FOu7NrX5hRIbf072swEWTCHYVZBmaF0j3DWq TnN+DohTjqNag== Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:01:14 -0000 This is getting better. I have a few things: Section 6: The exception to including the UUID of the transmitting entity mentioned above is in the case of provisional responses that occur before the destination UA has generated its UUID. The 100 (Trying) response and the 181 (Call Forwarding) response are examples of such provisional responses. In these cases, the sending intermediary places the one known UUID in the remote-uuid field, and leaves the "local-uuid" blank. This placement is always where a UA expects to receive its UUID value in SIP responses. The syntax doesn't currently permit the local-uuid to be "blank". Then Section 7 talks about the same thing and says to use a null uuid, which is really one with all zeros. I guess you intend to use "null" everywhere, but haven't got the language fixed everywhere. Frankly, I would like it better if you changed the syntax for Session-ID to make the local-uuid optional: session-id = "Session-ID" HCOLON [local-uuid] *(SEMI sess-id-param) Section 9.6: I don't think figures 6 & 7 are consistent with the words in this section. It says: o The MCU that is contacted, i.e., the UAS MCU, does not populate or complete the Session-ID header value. The UAS MCU transmits a 200 OK response acknowledging it is to respond with this M' UUID to all requests for the designated conference. yet figure 6 shows {J,M'} and figure 7 shows {J,M'}, {K,M'}, {L,M'}. AFAICT, J/K/L could only be known if sent from the UAS MCU. Also, the *point* of this is that participants in the conference will always get M', regardless of which MCU they contact. I think this should be shown by expanding the flows to include the connecting of a UA to one of the subordinate MCUs. Section 9.9: Figure 10 annotates the REFER with "(Target-Dialog:Carol)". If you look at the original in 5589, the Target-Dialog has the dialog id of the dialog between Bob and Alice - it has nothing to do with Carol. (There is as yet no dialog with Carol.) But you say this is about an out-of-dialog REFER. So why do you put {X} in it? It makes more sense to me that you would still use {B}, since this is intended to replace the {B,A} dialog. Either way, when Alice gets this she sees the Target-Dialog and knows this is to replace the {B,A} dialog. That is what causes her to use {A} in the the resulting INVITE. Thanks, Paul On 7/15/13 3:16 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the INtermediary-safe SIP session ID Working Group of the IETF. > > Title : End-to-End Session Identification in IP-Based Multimedia Communication Networks > Author(s) : Paul E. Jones > Chris Pearce > James Polk > Gonzalo Salgueiro > Filename : draft-ietf-insipid-session-id-02.txt > Pages : 25 > Date : 2013-07-15 > > Abstract: > This document describes an end-to-end Session Identifier for use in > IP-based Multimedia Communication systems that enables endpoints, > intermediate devices, and management systems to identify a session > end-to-end, associate multiple endpoints with a given multipoint > conference, track communication sessions when they are redirected, > and associate one or more media flows with a given communication > session. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-insipid-session-id-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-session-id-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From jmpolk@cisco.com Mon Jul 15 15:24:03 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB1721F9EEB for ; Mon, 15 Jul 2013 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB6kY9mOzwyw for ; Mon, 15 Jul 2013 15:23:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 52CDD21E818F for ; Mon, 15 Jul 2013 15:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5301; q=dns/txt; s=iport; t=1373927025; x=1375136625; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=5r7JTyuG63Ak0sCg1ulIyDDxEQO/eXotV68s0P933yo=; b=SqOy4OnS5jy9VApLvLu7rsi/PedKz4fIRegARYk1J5XAphy4Cd7hHmfK Hw4EXGwOe5W2gLObQZg95UoOa9KQVpvanw2RDrzcwgvl/Grx91zh2Rnpv lXTwd/qybn/tWTSKB1L0K6RHkt3Vc1R2uGoOvbJYi9h7/mHqG3ZgObJQt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAGB15FGtJV2Z/2dsb2JhbABQCgENgng0ScFigQ4WdIIjAQEBBAEBATUCLgYbBwQOCgkVEA8KDjAGARIJiAcHBbY0jiiBQ4N4A4knj16QJIJUXB4 X-IronPort-AV: E=Sophos;i="4.89,671,1367971200"; d="scan'208";a="235185257" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2013 22:23:44 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6FMNiff010966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 22:23:44 GMT Message-Id: <201307152223.r6FMNiff010966@rcdn-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Jul 2013 17:23:43 -0500 To: Paul Kyzivat , From: James Polk In-Reply-To: <51E46311.8070902@alum.mit.edu> References: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> <51E46311.8070902@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:24:03 -0000 At 04:01 PM 7/15/2013, Paul Kyzivat wrote: >This is getting better. I have a few things: > >Section 6: > > The exception to including the UUID of the transmitting entity > mentioned above is in the case of provisional responses that occur > before the destination UA has generated its UUID. The 100 (Trying) > response and the 181 (Call Forwarding) response are examples of such > provisional responses. In these cases, the sending intermediary > places the one known UUID in the remote-uuid field, and leaves the > "local-uuid" blank. This placement is always where a UA expects to > receive its UUID value in SIP responses. > >The syntax doesn't currently permit the local-uuid to be "blank". You're right, we got ahead of ourselves in that we didn't touch the ABNF, but should have *with* making these changes to other sections. A thousand apologies... >Then Section 7 talks about the same thing and says to use a null >uuid, which is really one with all zeros. > >I guess you intend to use "null" everywhere, but haven't got the >language fixed everywhere. Frankly, I would like it better if you >changed the syntax for Session-ID to make the local-uuid optional: > > session-id = "Session-ID" HCOLON [local-uuid] > *(SEMI sess-id-param) That's certainly worth considering (instead of the null value we allude to in this new versions). >Section 9.6: > >I don't think figures 6 & 7 are consistent with the words in this >section. It says: > > o The MCU that is contacted, i.e., the UAS MCU, does not populate > or complete the Session-ID header value. The UAS MCU transmits a > 200 OK response acknowledging it is to respond with this M' UUID > to all requests for the designated conference. > >yet figure 6 shows {J,M'} and figure 7 shows {J,M'}, {K,M'}, {L,M'}. >AFAICT, J/K/L could only be known if sent from the UAS MCU. > >Also, the *point* of this is that participants in the conference >will always get M', regardless of which MCU they contact. But we have to have a means of distributing M' to all the MCUs, and that's what we're after. Obviously we missed some text to bring the draft all to the point of consistency. >I think this should be shown by expanding the flows to include the >connecting of a UA to one of the subordinate MCUs. ok, that sounds reasonable to me. >Section 9.9: > >Figure 10 annotates the REFER with "(Target-Dialog:Carol)". If you >look at the original in 5589, the Target-Dialog has the dialog id of >the dialog between Bob and Alice - it has nothing to do with Carol. >(There is as yet no dialog with Carol.) > >But you say this is about an out-of-dialog REFER. So why do you put >{X} in it? It makes more sense to me that you would still use {B}, >since this is intended to replace the {B,A} dialog. In 5589, the figure we took from that RFC shows the REFER as a separate dialog than the Alice-to-Bob dialog. How is the Session-ID not going to change with the dialog change? Thanks for the quick review JAmes >Either way, when Alice gets this she sees the Target-Dialog and >knows this is to replace the {B,A} dialog. That is what causes her >to use {A} in the the resulting INVITE. > > Thanks, > Paul > >On 7/15/13 3:16 PM, internet-drafts@ietf.org wrote: >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the INtermediary-safe SIP session >> ID Working Group of the IETF. >> >> Title : End-to-End Session Identification in >> IP-Based Multimedia Communication Networks >> Author(s) : Paul E. Jones >> Chris Pearce >> James Polk >> Gonzalo Salgueiro >> Filename : draft-ietf-insipid-session-id-02.txt >> Pages : 25 >> Date : 2013-07-15 >> >>Abstract: >> This document describes an end-to-end Session Identifier for use in >> IP-based Multimedia Communication systems that enables endpoints, >> intermediate devices, and management systems to identify a session >> end-to-end, associate multiple endpoints with a given multipoint >> conference, track communication sessions when they are redirected, >> and associate one or more media flows with a given communication >> session. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-insipid-session-id-02 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-session-id-02 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>insipid mailing list >>insipid@ietf.org >>https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Mon Jul 15 15:24:36 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C378521F9FC7 for ; Mon, 15 Jul 2013 15:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbHyAegDWygs for ; Mon, 15 Jul 2013 15:24:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 29ACE21F9EB8 for ; Mon, 15 Jul 2013 15:24:30 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r6FMOSw6016406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Jul 2013 18:24:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1373927069; bh=CHW/WrrIaNVBDCjDJGYIo0whirAi6zrDBptgPVtj3W8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=uY8eawaEu1x+yqTFBs4nSovh+oczJOC5HxmAsbj82PaxmaBMrS05fkI7k7OpNLpAY mgtUpFYoG3Ibe20J17yVPcLWZhBmG5gDeFVbn5CjdMjrtwx7aKBLHZraqqLTwewJBe zT0fov/sw6Z5gpDKNALZAxcEuqU4xre4u5J4LEL0= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> <51E46311.8070902@alum.mit.edu> In-Reply-To: <51E46311.8070902@alum.mit.edu> Date: Mon, 15 Jul 2013 18:24:37 -0400 Message-ID: <02b701ce81aa$17447970$45cd6c50$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCh4N2jFhoBtIm+B6xE/0sC7VLOgQHim7dtm7Bt4DA= Content-Language: en-us Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:24:37 -0000 Paul, You're quick... you commented before I had a chance to summarize the changes. I'll do that separately, but to reply to your comments: > Section 6: > > The exception to including the UUID of the transmitting entity > mentioned above is in the case of provisional responses that occur > before the destination UA has generated its UUID. The 100 (Trying) > response and the 181 (Call Forwarding) response are examples of such > provisional responses. In these cases, the sending intermediary > places the one known UUID in the remote-uuid field, and leaves the > "local-uuid" blank. This placement is always where a UA expects to > receive its UUID value in SIP responses. > > The syntax doesn't currently permit the local-uuid to be "blank". Indeed, that's a leftover from where we initially tried to address Robert's 100 Trying call flow example. The offending sentence should have been: In these cases, the sending intermediary places the one known UUID in the "remote-uuid" field, and sets the "local-uuid" field to the "null" UUID value. > Then Section 7 talks about the same thing and says to use a null uuid, > which is really one with all zeros. Correct. That's intended. > I guess you intend to use "null" everywhere, but haven't got the > language fixed everywhere. Frankly, I would like it better if you > changed the syntax for Session-ID to make the local-uuid optional: > > session-id = "Session-ID" HCOLON [local-uuid] > *(SEMI sess-id-param) This is certainly open for discussion, as we just inserted this to address those new call flows. If folks prefer to allow a Session-ID header of the form: Session-ID: ; remote=6e7d43af3ea14ec6a43d39171ff17b09 > Section 9.6: > > I don't think figures 6 & 7 are consistent with the words in this > section. It says: > > o The MCU that is contacted, i.e., the UAS MCU, does not populate > or complete the Session-ID header value. The UAS MCU transmits a > 200 OK response acknowledging it is to respond with this M' UUID > to all requests for the designated conference. > > yet figure 6 shows {J,M'} and figure 7 shows {J,M'}, {K,M'}, {L,M'}. > AFAICT, J/K/L could only be known if sent from the UAS MCU. Right. That paragraph should be deleted. We had it this was in the last draft, but I felt it was inconsistent with all other call flows. We neglected to remove that paragraph. > Also, the *point* of this is that participants in the conference will > always get M', regardless of which MCU they contact. I think this should > be shown by expanding the flows to include the connecting of a UA to one > of the subordinate MCUs. That's correct and I agree. I don't want to rush those changes out the door, but I'll take note that we should show a UA calling into MCU 3 or 4, for example. > Section 9.9: > > Figure 10 annotates the REFER with "(Target-Dialog:Carol)". If you look > at the original in 5589, the Target-Dialog has the dialog id of the > dialog between Bob and Alice - it has nothing to do with Carol. (There > is as yet no dialog with Carol.) You're correct. James and I will need to revise this. Not sure why it reads like this. > But you say this is about an out-of-dialog REFER. So why do you put {X} > in it? It makes more sense to me that you would still use {B}, since > this is intended to replace the {B,A} dialog. Not sure about this one. REFER here uses a whole new Call-ID, which is the reason why the Session-ID is different. It's not related to the current Session and, therefore, should not utilize the same UUID value. > Either way, when Alice gets this she sees the Target-Dialog and knows > this is to replace the {B,A} dialog. That is what causes her to use {A} > in the the resulting INVITE. Right. Regardless of what prompts the call transfer, Alice should re-use her UUID since the call is transferred. Paul From paulej@packetizer.com Mon Jul 15 15:40:51 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF3111E8219 for ; Mon, 15 Jul 2013 15:40:51 -0700 (PDT) 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=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R+5hHM+1f8t for ; Mon, 15 Jul 2013 15:40:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 17E6511E823D for ; Mon, 15 Jul 2013 15:40:44 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r6FMehs0017348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 15 Jul 2013 18:40:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1373928043; bh=S6FcbHXrF4VrY8VCGRoxDaLl/mUGiDrnufZasKvSA0Q=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YDf6Slg+/nKpXGrOMsZvk15jkcr6W+gA5PwbEOyJ9XAbbLnOk88x3tyjCBJyAX+PD f8OTr+bnpmJr0RnWJ2hoRVrDalCZM3/sDTBzFXbFu4tV3GFNXzf1b2tlNRx9o1K8Sv 3nzDePiuqffIux6vZ3MkI5ujxF7UaOIKUbuLgZY8= From: "Paul E. Jones" To: References: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> In-Reply-To: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 18:40:51 -0400 Message-ID: <02b901ce81ac$5c0bac70$14230550$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCh4N2jFhoBtIm+B6xE/0sC7VLOgZu/lRZg Content-Language: en-us Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:40:51 -0000 Folks, In this draft, the following changes were made: * Revised the example UUID values to use "version 4" (random) UUIDs to be consistent with the requirements spec * Introduced the "null" UUID value (numerically zero) to support some message exchanges like sending a 100 Trying from an intermediary * Clarified that the "sender" of a message is the "transmitter" of a message (terminology change) * Introduce language related to 100 Trying and CANCEL in Sections 5 and 6 * Modified the language of the example to make it clearer those are non-normative examples * Made minor changes to most examples to make them clearer * Introduced new examples for 100 Trying, Cancel, and OOD REFER Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Monday, July 15, 2013 3:17 PM > To: i-d-announce@ietf.org > Cc: insipid@ietf.org > Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the INtermediary-safe SIP session ID Working > Group of the IETF. > > Title : End-to-End Session Identification in IP-Based > Multimedia Communication Networks > Author(s) : Paul E. Jones > Chris Pearce > James Polk > Gonzalo Salgueiro > Filename : draft-ietf-insipid-session-id-02.txt > Pages : 25 > Date : 2013-07-15 > > Abstract: > This document describes an end-to-end Session Identifier for use in > IP-based Multimedia Communication systems that enables endpoints, > intermediate devices, and management systems to identify a session > end-to-end, associate multiple endpoints with a given multipoint > conference, track communication sessions when they are redirected, > and associate one or more media flows with a given communication > session. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-insipid-session-id-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-session-id-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Mon Jul 15 18:17:11 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD7521E80CB for ; Mon, 15 Jul 2013 18:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJNAQIkSkhuS for ; Mon, 15 Jul 2013 18:17:05 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4B421E8055 for ; Mon, 15 Jul 2013 18:17:04 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id 0o5e1m0010EZKEL51pH3WF; Tue, 16 Jul 2013 01:17:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id 0pH31m00k3ZTu2S3MpH3bE; Tue, 16 Jul 2013 01:17:03 +0000 Message-ID: <51E49F0F.90903@alum.mit.edu> Date: Mon, 15 Jul 2013 21:17:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: James Polk References: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> <51E46311.8070902@alum.mit.edu> <201307152223.r6FMNiff010966@rcdn-core-2.cisco.com> In-Reply-To: <201307152223.r6FMNiff010966@rcdn-core-2.cisco.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=1373937423; bh=mCdBHJZWxlD214IHMKjEYLPwBRY+0auiR9TCEyfup9A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OCsMoIIWnZAfyR5YsvQsZRp/F8dCI/OEa3KbpcdnSzXMd7raFLGTl/PUCwmEj1vhk entGLp2YE0K2L3SKXnO1MbWsJO702wbDG4YBFDUybZDFefVme3L0gRYTtLdDpuq508 /n6O4YWIMT7Y1yKChOCKFztQ0xLrIFgOiwFv1botvlRWjBTvXcOw6JiAg56tlnxfWK sMZtyoMF1yglIoRhSV1gVSojRHNcbq+M7i02r7Olcaup+zkY/P4OjWHHUxM13v2ndh HrEoULbXKvof15ZGMbVnFIs8/wOrIAQ4KfdZO3ahu0UvS86twcE1N8JZZ8xyA1Nx0e xrj4LR6b2bT3Q== Cc: insipid@ietf.org Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 01:17:11 -0000 On 7/15/13 6:23 PM, James Polk wrote: >> Section 9.9: >> >> Figure 10 annotates the REFER with "(Target-Dialog:Carol)". If you >> look at the original in 5589, the Target-Dialog has the dialog id of >> the dialog between Bob and Alice - it has nothing to do with Carol. >> (There is as yet no dialog with Carol.) >> >> But you say this is about an out-of-dialog REFER. So why do you put >> {X} in it? It makes more sense to me that you would still use {B}, >> since this is intended to replace the {B,A} dialog. > > In 5589, the figure we took from that RFC shows the REFER as a separate > dialog than the Alice-to-Bob dialog. How is the Session-ID not going to > change with the dialog change? Its up to you to make the rules. A focus uses the same uuid for all the dialogs in the conference. So why shouldn't the transferor use the same uuid for the before/after dialogs? Ultimately it doesn't make much difference, because the transferor isn't part of the new (referred) invite dialog. But at least there would be some commonality via the session id of the refer. Thanks, Paul From jmpolk@cisco.com Mon Jul 15 18:38:58 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6C11E8121 for ; Mon, 15 Jul 2013 18:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaDsEa1BWJXq for ; Mon, 15 Jul 2013 18:38:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A943211E818E for ; Mon, 15 Jul 2013 18:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1668; q=dns/txt; s=iport; t=1373938735; x=1375148335; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=PlY0FvYyQlhAJaDInrNarp/6URxpy7K2zurC93BwEo4=; b=BzwrV3GVsAFWjq8WRHIQiyxTcQ0ElK3MFdzZWAkSrIibSOv1BW2/L2aw JEGm4JnDrcfAiNmcXwI8RDAtU7PMQaJscunsqCPsOYVheSQASCzYDY+Yu VZnUoG3WdnxlkuG/VyjIbRhsH3Oiqn1s5e2Cn7Fz/Ht9zy/LMyZYgYUoF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAFKj5FGtJXG+/2dsb2JhbABaDoJ4NMIqgRMWdIIjAQEBAwEBAQE1Ai4GCwULBwQOCgkVEA8KDjAGCgmICgYMtkgEj2QHg3gDiSegAoJUXB4 X-IronPort-AV: E=Sophos;i="4.89,673,1367971200"; d="scan'208";a="232215332" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2013 01:38:53 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6G1cplK021766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 01:38:52 GMT Message-Id: <201307160138.r6G1cplK021766@rcdn-core2-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Jul 2013 20:38:51 -0500 To: Paul Kyzivat From: James Polk In-Reply-To: <51E49F0F.90903@alum.mit.edu> References: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> <51E46311.8070902@alum.mit.edu> <201307152223.r6FMNiff010966@rcdn-core-2.cisco.com> <51E49F0F.90903@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: insipid@ietf.org Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 01:38:58 -0000 At 08:17 PM 7/15/2013, Paul Kyzivat wrote: >On 7/15/13 6:23 PM, James Polk wrote: > >>>Section 9.9: >>> >>>Figure 10 annotates the REFER with "(Target-Dialog:Carol)". If you >>>look at the original in 5589, the Target-Dialog has the dialog id of >>>the dialog between Bob and Alice - it has nothing to do with Carol. >>>(There is as yet no dialog with Carol.) >>> >>>But you say this is about an out-of-dialog REFER. So why do you put >>>{X} in it? It makes more sense to me that you would still use {B}, >>>since this is intended to replace the {B,A} dialog. >> >>In 5589, the figure we took from that RFC shows the REFER as a separate >>dialog than the Alice-to-Bob dialog. How is the Session-ID not going to >>change with the dialog change? > >Its up to you to make the rules. A focus uses the same uuid for all >the dialogs in the conference. So why shouldn't the transferor use >the same uuid for the before/after dialogs? > >Ultimately it doesn't make much difference, because the transferor >isn't part of the new (referred) invite dialog. But at least there >would be some commonality via the session id of the refer. I agree with commonality as a goal. However, in this case, Robert specifically wanted an "out-of-dialog REFER", and he hand picked the figure out of RFC 5589 for us to use - one that didn't have a dialog-ID in common with the Alice-to-Bob dialog. I believe that's what we showed. I could be wrong though... James > Thanks, > Paul > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Mon Jul 15 19:07:19 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D2521F9B40 for ; Mon, 15 Jul 2013 19:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3RwNCbUrpds for ; Mon, 15 Jul 2013 19:07:13 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 82B2111E817B for ; Mon, 15 Jul 2013 19:07:13 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id 0pfM1m0041swQuc5Fq7Cki; Tue, 16 Jul 2013 02:07:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 0q7C1m01Q3ZTu2S3bq7CKi; Tue, 16 Jul 2013 02:07:12 +0000 Message-ID: <51E4AACF.7040407@alum.mit.edu> Date: Mon, 15 Jul 2013 22:07:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: James Polk References: <20130715191635.11306.95537.idtracker@ietfa.amsl.com> <51E46311.8070902@alum.mit.edu> <201307152223.r6FMNiff010966@rcdn-core-2.cisco.com> <51E49F0F.90903@alum.mit.edu> <201307160138.r6G1cplK021766@rcdn-core2-3.cisco.com> In-Reply-To: <201307160138.r6G1cplK021766@rcdn-core2-3.cisco.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=1373940432; bh=Hq8t2uYPUclvZ1e3ciZy1lxpgVeuyg2pV5MxraCwrVE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nhCfKgO8bNegloTSm18ebF5Lop4pjo1J922OklbPnv87l2rnbRnu/r5CIW8xxZjkx /V30Bv5i8nVWOefu3UPXAkmcgrTQ0HZ5XWLjnqAmItvbqu8eImW1PfkSPQHsocfjEX /ZcL6pOINgebpIVJIMZWvGEk4rejtMWSi2GzszAEaBZIwPz10dQSYGahzFzeYl91V7 Kb8tC/YXKv2N9jEWqN1VQUhevCv668uKWWxLZBkof0ag/RnMJk1/A1jaJ6Lvww0Ikd eCW97qA0XHgUBMmbSFZ4xmeXQyrnjzfTMMQrg7EQPol+71pc4EMLIuamFWc9TENUUZ PEfzS3nDuWclQ== Cc: insipid@ietf.org Subject: Re: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 02:07:19 -0000 On 7/15/13 9:38 PM, James Polk wrote: > At 08:17 PM 7/15/2013, Paul Kyzivat wrote: >> On 7/15/13 6:23 PM, James Polk wrote: >> >>>> Section 9.9: >>>> >>>> Figure 10 annotates the REFER with "(Target-Dialog:Carol)". If you >>>> look at the original in 5589, the Target-Dialog has the dialog id of >>>> the dialog between Bob and Alice - it has nothing to do with Carol. >>>> (There is as yet no dialog with Carol.) >>>> >>>> But you say this is about an out-of-dialog REFER. So why do you put >>>> {X} in it? It makes more sense to me that you would still use {B}, >>>> since this is intended to replace the {B,A} dialog. >>> >>> In 5589, the figure we took from that RFC shows the REFER as a separate >>> dialog than the Alice-to-Bob dialog. How is the Session-ID not going to >>> change with the dialog change? >> >> Its up to you to make the rules. A focus uses the same uuid for all >> the dialogs in the conference. So why shouldn't the transferor use the >> same uuid for the before/after dialogs? >> >> Ultimately it doesn't make much difference, because the transferor >> isn't part of the new (referred) invite dialog. But at least there >> would be some commonality via the session id of the refer. > > I agree with commonality as a goal. However, in this case, Robert > specifically wanted an "out-of-dialog REFER", and he hand picked the > figure out of RFC 5589 for us to use - one that didn't have a dialog-ID > in common with the Alice-to-Bob dialog. > > I believe that's what we showed. > > I could be wrong though... Well, without showing the sip messages it is not possible to tell if you are doing out of dialog REFER or not. If it were in-dialog, then I guess the session id would be {B,A}. If its out of dialog, then it could still be {B}. And then Alice, seeing that the target-dialog is {A,B}, might choose to respond to the REFER with {A,B} even though it is a different dialog, or {Y,B} because it is a different dialog. (That seems a little fuzzy.) Thanks, Paul From keith.drage@alcatel-lucent.com Tue Jul 16 08:32:45 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F4D21F9AFD for ; Tue, 16 Jul 2013 08:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fECPVO2wgwnG for ; Tue, 16 Jul 2013 08:32:35 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB8E21F9AEB for ; Tue, 16 Jul 2013 08:32:26 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6GFWKRj010015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jul 2013 10:32:23 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GFWKQ4007702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jul 2013 17:32:20 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 17:32:20 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: WGLC for draft-ietf-insipid-session-id-reqts-07 Thread-Index: Ac58OGhKYBWRLys3QOmOsXUVqzCOigAaK6twAWYUl8A= Date: Tue, 16 Jul 2013 15:32:19 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:32:46 -0000 (As WG cochair) A reminder of this working group last call, now you all have plenty of time= following the draft deadline. If you have read it and have no comments, then do send the chairs a short m= ail saying that. Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: 09 July 2013 13:42 > To: insipid@ietf.org > Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 >=20 > (As WG cochair) >=20 > I've just been double checking, and having thought that we had already ha= d > a WGLC on it, I find that formally, this is the first. I will therefore > extend this WGLC until 23rd July 2013 to give it the full 2 weeks. >=20 > I'd also remind you that there are a number of IPR declarations against > this document >=20 > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_docu= men > t_tag=3Ddraft-ietf-insipid-session-id-reqts >=20 > I believe we have briefly discussed these in the past, but please raise > any concerns you have with proceeding with the draft in the presence of > these declarations. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf > > Of DRAGE, Keith (Keith) > > Sent: 09 July 2013 01:10 > > To: insipid@ietf.org > > Subject: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 > > > > (As WG co chair) > > > > This document has been around for 3 or 4 weeks now and has attracted no > > comments to update it. > > > > The chairs would therefore like to make a further one week WGLC to chec= k > > that the document has been finished and ready to do a publication > request. > > > > So if you have any comments before we request IESG to approve this as a= n > > informational document, then please make them by close of business on > 16th > > July. > > > > Regards > > > > Keith > > > > > > Title : Requirements for an End-to-End Session > > Identification in IP-Based Multimedia Communication Networks > > Author(s) : Paul E. Jones > > Gonzalo Salgueiro > > James Polk > > Laura Liess > > Hadriel Kaplan > > Filename : draft-ietf-insipid-session-id-reqts-07.txt > > Pages : 11 > > Date : 2013-06-12 > > > > Abstract: > > This document specifies the requirements for an end-to-end session > > identifier in IP-based multimedia communication networks. This > > identifier would enable endpoints, intermediate devices, and > > management and monitoring systems to identify a session end-to-end > > across multiple SIP devices, hops, and administrative domains. > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Tue Jul 16 09:00:36 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AF521F9B07 for ; Tue, 16 Jul 2013 09:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39pigQWEkFuP for ; Tue, 16 Jul 2013 09:00:26 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id D315A21F9C7B for ; Tue, 16 Jul 2013 09:00:17 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id 13Ez1m0070xGWP85140HqT; Tue, 16 Jul 2013 16:00:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 140H1m00P3ZTu2S3Y40Hy2; Tue, 16 Jul 2013 16:00:17 +0000 Message-ID: <51E56E10.3010807@alum.mit.edu> Date: Tue, 16 Jul 2013 12:00:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: insipid@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.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=1373990417; bh=oYO2roWA4NlgpoNSG2+STJ4i2EIBL4drWklKmhx5Mbs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mdWXrJprBmjDIbBZVEggSICKZWxd2QoDrzIjH7YdlBa7zSnBIvqg7l/dE2w2mboVo aXyfDCoUEk8hgMORwWE11YRs3ccMl5ZlBRb/FB68rYWDgjoYxVonqrhcWkJbgxmWRp vVbMYRRo6cjwIxIruyil90bgER0DprRZS36mr+TYbXd1m7JwAQ9D3+XYybLJCI8X9N RAxMil/feeuEr5TfYSU4uzMlpIk+PSgSqsqLXlVZL6z+jtLyXnYz/w8ijkzyvyeL72 tQqKdu2TqtbllR47Xm8m2qiXpYepSNLPT1C09h1+999cQ0FD/F4AbdnRvoZ9iZxd1f Tz2+xOKYB+U+w== Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:00:36 -0000 I've read it. I'm done nit picking it. Thanks, Paul On 7/16/13 11:32 AM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > A reminder of this working group last call, now you all have plenty of time following the draft deadline. > > If you have read it and have no comments, then do send the chairs a short mail saying that. > > Keith > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of DRAGE, Keith (Keith) >> Sent: 09 July 2013 13:42 >> To: insipid@ietf.org >> Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 >> >> (As WG cochair) >> >> I've just been double checking, and having thought that we had already had >> a WGLC on it, I find that formally, this is the first. I will therefore >> extend this WGLC until 23rd July 2013 to give it the full 2 weeks. >> >> I'd also remind you that there are a number of IPR declarations against >> this document >> >> https://datatracker.ietf.org/ipr/search/?option=document_search&id_documen >> t_tag=draft-ietf-insipid-session-id-reqts >> >> I believe we have briefly discussed these in the past, but please raise >> any concerns you have with proceeding with the draft in the presence of >> these declarations. >> >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf >>> Of DRAGE, Keith (Keith) >>> Sent: 09 July 2013 01:10 >>> To: insipid@ietf.org >>> Subject: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 >>> >>> (As WG co chair) >>> >>> This document has been around for 3 or 4 weeks now and has attracted no >>> comments to update it. >>> >>> The chairs would therefore like to make a further one week WGLC to check >>> that the document has been finished and ready to do a publication >> request. >>> >>> So if you have any comments before we request IESG to approve this as an >>> informational document, then please make them by close of business on >> 16th >>> July. >>> >>> Regards >>> >>> Keith >>> >>> >>> Title : Requirements for an End-to-End Session >>> Identification in IP-Based Multimedia Communication Networks >>> Author(s) : Paul E. Jones >>> Gonzalo Salgueiro >>> James Polk >>> Laura Liess >>> Hadriel Kaplan >>> Filename : draft-ietf-insipid-session-id-reqts-07.txt >>> Pages : 11 >>> Date : 2013-06-12 >>> >>> Abstract: >>> This document specifies the requirements for an end-to-end session >>> identifier in IP-based multimedia communication networks. This >>> identifier would enable endpoints, intermediate devices, and >>> management and monitoring systems to identify a session end-to-end >>> across multiple SIP devices, hops, and administrative domains. >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From gsalguei@cisco.com Tue Jul 16 22:26:11 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB91521F99AC for ; Tue, 16 Jul 2013 22:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2+-gpPbQHAA for ; Tue, 16 Jul 2013 22:26:07 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id B1CB221F9AE6 for ; Tue, 16 Jul 2013 22:26:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6H5Q6dV025408; Wed, 17 Jul 2013 01:26:06 -0400 (EDT) Received: from rtp-gsalguei-8914.cisco.com (rtp-gsalguei-8914.cisco.com [10.116.132.53]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6H5Q1N1020147; Wed, 17 Jul 2013 01:26:01 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jul 2013 01:26:01 -0400 Message-Id: <2ACD2296-FEB7-4395-A713-CD984B565584@cisco.com> To: "insipid@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "" Subject: [Insipid] Preliminary Agenda for IETF 87 INSIPID Meeting X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 05:26:12 -0000 Hello Everyone, A draft agenda for the INSIPID WG meeting in Berlin is now available: http://www.ietf.org/proceedings/87/agenda/agenda-87-insipid If you have any suggestions and/or comments please let the chairs know = (insipid-chairs@ietf.org). Gonzalo & Keith (as co-chairs)= From brett@broadsoft.com Fri Jul 19 09:44:31 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C612611E8156 for ; Fri, 19 Jul 2013 09:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sHBi1Rvmuo3 for ; Fri, 19 Jul 2013 09:44:27 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id AEE4F11E80E1 for ; Fri, 19 Jul 2013 09:44:27 -0700 (PDT) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 19 Jul 2013 09:44:17 -0700 Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 19 Jul 2013 09:44:17 -0700 From: Brett Tate To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: WGLC for draft-ietf-insipid-session-id-reqts-07 Thread-Index: Ac58OGhKYBWRLys3QOmOsXUVqzCOigAaK6twAWYUl8AAl/tHkA== Date: Fri, 19 Jul 2013 16:44:16 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196BD09B@MBX07.citservers.local> References: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:44:31 -0000 > If you have read it and have no comments, then do=20 > send the chairs a short mail saying that. I have read the draft and have no comments. As discussed within the following thread, it sounds like requirement 3 will= not be fully met. However, there likely isn't much reason to list the var= ious exceptions or loosen the "must require". http://www.ietf.org/mail-archive/web/insipid/current/msg00529.html Thanks, Brett From paulej@packetizer.com Fri Jul 19 12:05:52 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAE411E819B for ; Fri, 19 Jul 2013 12:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1R8oH3CsE6C for ; Fri, 19 Jul 2013 12:05:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D3ED311E8193 for ; Fri, 19 Jul 2013 12:05:47 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r6JJ5fC4022413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jul 2013 15:05:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1374260742; bh=nJzSY+Aq7G2y8m5bnWYO+7pVO2WXurZHX11a749i8Ww=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ElEsMrBfi1gmwTf2G46N+c7ejBccVGN+y4/Vk+ynxVypSFVXXb7tE09MyWeuvfLTk B36FN9W/6AYeBCtpC4li0naWm7TO8oeHdkFeGnC4LGbi5wjboI70BS6q5OUVdWkbXN rCpnaTTzVUtfyIlHpgxe3hgH7v+pM4uvB1of9Srs= From: "Paul E. Jones" To: "'Brett Tate'" , "'DRAGE, Keith \(Keith\)'" , References: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <576A8B541C219D4E9CEB1DF8C19C7B88196BD09B@MBX07.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196BD09B@MBX07.citservers.local> Date: Fri, 19 Jul 2013 15:05:57 -0400 Message-ID: <0ca101ce84b3$009043b0$01b0cb10$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQOTq0tO3bIeaP7z4n13DCHxfCFa4gE4sWlQAjG/qxgA3/qubpW/tZKQ Content-Language: en-us Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:05:52 -0000 Brett, What you introduced in that flow has multiple ends. Bp and Bc are two different endpoints and the signaling is merged at the B2BUA. Basically, the B2BUA is acting like an MCU, but one that never gets involved in media transcoding or mixing. So from Alice to the B2BUA (MCU), there is one session ID. From the B2BUA to Bp and Bc, there are different session IDs, but we re-use the B2BUA's UUID "M" since that's the procedures specified for MCU behavior. The net result is three session IDs that are related: {A,M} {M,Bp} {M,Bc} That's exactly what we would have had three users called into an MCU. The common value here is "M". So, one could argue that REQ3 is not met, but another way to look at it is that the "end" is the B2BUA. Arranging the signaling as you have it in that flow is about like using MGCP or H.248 to control the video or audio device associated with the B2BUA. In any case, we cannot use a single identifier to identify a call from the point of origin to the point of termination if there are actually multiple simultaneous termination points. The best we can do is associate them as we do for an MCU. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Brett Tate > Sent: Friday, July 19, 2013 12:44 PM > To: DRAGE, Keith (Keith); insipid@ietf.org > Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 > > > If you have read it and have no comments, then do > > send the chairs a short mail saying that. > > I have read the draft and have no comments. > > As discussed within the following thread, it sounds like requirement 3 > will not be fully met. However, there likely isn't much reason to list > the various exceptions or loosen the "must require". > > http://www.ietf.org/mail-archive/web/insipid/current/msg00529.html > > Thanks, > Brett > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From christer.holmberg@ericsson.com Sat Jul 20 07:08:34 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A784D11E810E for ; Sat, 20 Jul 2013 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.583 X-Spam-Level: X-Spam-Status: No, score=-5.583 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBizpodSboZw for ; Sat, 20 Jul 2013 07:08:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CFE3D11E8103 for ; Sat, 20 Jul 2013 07:08:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-7d-51ea99d0bd88 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 55.1F.06741.0D99AE15; Sat, 20 Jul 2013 16:08:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Sat, 20 Jul 2013 16:08:16 +0200 From: Christer Holmberg To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 Thread-Index: Ac58OGhKYBWRLys3QOmOsXUVqzCOigAaK6twAWYUl8D//+bGAP/5tIsw Date: Sat, 20 Jul 2013 14:08:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3DD3C0@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <51E56E10.3010807@alum.mit.edu> In-Reply-To: <51E56E10.3010807@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre6Fma8CDRa8UrOYf/8Zk8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6Mvg/T2Qu65CtmvhBtYLwq0cXIySEhYCLx +vNKJghbTOLCvfVsILaQwGFGiYtNNV2MXED2YkaJ77t+ABVxcLAJWEh0/9MGqRERCJS4fHQB WL2wgJvEx+3z2UBKRATcJfbtS4YocZPYOOE9C4jNIqAq8bfxH5jNK+Ar8Xz5LTaI8fOYJH58 +QN2A6eAjsTqjysZQWxGoHu+n1oDFmcWEJf4cPA6M8SdAhJL9pyHskUlXj7+xwphK0k0LnnC ClGvJ3Fj6hQ2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl hpsYgXFwcMtv3R2Mp86JHGKU5mBREufdpHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj YWXfqXv3Mp2n3f6x7v9Vye18tzMKp2T3L9iv8JJ3T9zWtsM6UZG6DW+Pq713iOrWP5lvJdPW 9WHdy9+p3kFO/2QTg2/ss7+647lU+eKwd/PuuKsaPXTUKauR7tZX9zzo49Z9ICv8qOnH1Ztn 8e+6En5t2+Syu5sWOIpf+LI91eT1443/76ZcVWIpzkg01GIuKk4EAJEk9ehRAgAA Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 14:08:34 -0000 Hi, I'm ok with the reqs document. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org]= Puolesta Paul Kyzivat L=E4hetetty: 16. hein=E4kuuta 2013 19:00 Vastaanottaja: insipid@ietf.org Aihe: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 I've read it. I'm done nit picking it. Thanks, Paul On 7/16/13 11:32 AM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > A reminder of this working group last call, now you all have plenty of ti= me following the draft deadline. > > If you have read it and have no comments, then do send the chairs a short= mail saying that. > > Keith > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On=20 >> Behalf Of DRAGE, Keith (Keith) >> Sent: 09 July 2013 13:42 >> To: insipid@ietf.org >> Subject: Re: [Insipid] WGLC for=20 >> draft-ietf-insipid-session-id-reqts-07 >> >> (As WG cochair) >> >> I've just been double checking, and having thought that we had=20 >> already had a WGLC on it, I find that formally, this is the first. I=20 >> will therefore extend this WGLC until 23rd July 2013 to give it the full= 2 weeks. >> >> I'd also remind you that there are a number of IPR declarations=20 >> against this document >> >> https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_do >> cumen t_tag=3Ddraft-ietf-insipid-session-id-reqts >> >> I believe we have briefly discussed these in the past, but please=20 >> raise any concerns you have with proceeding with the draft in the=20 >> presence of these declarations. >> >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf >>> Of DRAGE, Keith (Keith) >>> Sent: 09 July 2013 01:10 >>> To: insipid@ietf.org >>> Subject: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 >>> >>> (As WG co chair) >>> >>> This document has been around for 3 or 4 weeks now and has attracted=20 >>> no comments to update it. >>> >>> The chairs would therefore like to make a further one week WGLC to=20 >>> check that the document has been finished and ready to do a=20 >>> publication >> request. >>> >>> So if you have any comments before we request IESG to approve this=20 >>> as an informational document, then please make them by close of=20 >>> business on >> 16th >>> July. >>> >>> Regards >>> >>> Keith >>> >>> >>> Title : Requirements for an End-to-End Session >>> Identification in IP-Based Multimedia Communication Networks >>> Author(s) : Paul E. Jones >>> Gonzalo Salgueiro >>> James Polk >>> Laura Liess >>> Hadriel Kaplan >>> Filename : draft-ietf-insipid-session-id-reqts-07.txt >>> Pages : 11 >>> Date : 2013-06-12 >>> >>> Abstract: >>> This document specifies the requirements for an end-to-end session >>> identifier in IP-based multimedia communication networks. This >>> identifier would enable endpoints, intermediate devices, and >>> management and monitoring systems to identify a session end-to-end >>> across multiple SIP devices, hops, and administrative domains. >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From eckelcu@cisco.com Mon Jul 22 13:24:58 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6658F21F8424 for ; Mon, 22 Jul 2013 13:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHXnhpQwzFYP for ; Mon, 22 Jul 2013 13:24:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7896A21F8447 for ; Mon, 22 Jul 2013 13:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3839; q=dns/txt; s=iport; t=1374524692; x=1375734292; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2B+r8+prDYB8peGW2Mc4MvxCTexnyObvGKulFMtPFBo=; b=bOHdHPbhPpUxv0ZdUj2SGUAqZV5o504xkzmnb09nrpL6v1X1uvUGBena 7dQqTk/iTY9hpkzGCyG6GU3fmlyvN0ARB5+D173SVpIdJo5xslM7YCMT4 ZAocW09waAGymfLrz9zK+3rMtha6E/QU0EwOnTX64cIpKdYOhgApWudJt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAK+U7VGtJXG//2dsb2JhbABRCoMDNVDAMoEWFnSCJAEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCIgHAQy4HQSOWgqBATgGgwpuA6kqgxKBaAcCFyI X-IronPort-AV: E=Sophos;i="4.89,721,1367971200"; d="scan'208";a="237965048" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jul 2013 20:24:48 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6MKOm1L027689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 20:24:48 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 15:24:48 -0500 From: "Charles Eckel (eckelcu)" To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: WGLC for draft-ietf-insipid-session-id-reqts-07 Thread-Index: Ac58OGhKYBWRLys3QOmOsXUVqzCOigAaK6twAWYUl8ABN/viMA== Date: Mon, 22 Jul 2013 20:24:38 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828048D5C03@xmb-aln-x08.cisco.com> References: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:24:58 -0000 I have read it and think it is ready to move forward. Cheers, Charles > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: Tuesday, July 16, 2013 8:32 AM > To: insipid@ietf.org > Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 >=20 > (As WG cochair) >=20 > A reminder of this working group last call, now you all have plenty of ti= me > following the draft deadline. >=20 > If you have read it and have no comments, then do send the chairs a short= mail > saying that. >=20 > Keith >=20 > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Beh= alf > > Of DRAGE, Keith (Keith) > > Sent: 09 July 2013 13:42 > > To: insipid@ietf.org > > Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 > > > > (As WG cochair) > > > > I've just been double checking, and having thought that we had already = had > > a WGLC on it, I find that formally, this is the first. I will therefore > > extend this WGLC until 23rd July 2013 to give it the full 2 weeks. > > > > I'd also remind you that there are a number of IPR declarations against > > this document > > > > > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_docu= men > > t_tag=3Ddraft-ietf-insipid-session-id-reqts > > > > I believe we have briefly discussed these in the past, but please raise > > any concerns you have with proceeding with the draft in the presence of > > these declarations. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf > > > Of DRAGE, Keith (Keith) > > > Sent: 09 July 2013 01:10 > > > To: insipid@ietf.org > > > Subject: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 > > > > > > (As WG co chair) > > > > > > This document has been around for 3 or 4 weeks now and has attracted = no > > > comments to update it. > > > > > > The chairs would therefore like to make a further one week WGLC to ch= eck > > > that the document has been finished and ready to do a publication > > request. > > > > > > So if you have any comments before we request IESG to approve this as= an > > > informational document, then please make them by close of business on > > 16th > > > July. > > > > > > Regards > > > > > > Keith > > > > > > > > > Title : Requirements for an End-to-End Session > > > Identification in IP-Based Multimedia Communication Networks > > > Author(s) : Paul E. Jones > > > Gonzalo Salgueiro > > > James Polk > > > Laura Liess > > > Hadriel Kaplan > > > Filename : draft-ietf-insipid-session-id-reqts-07.txt > > > Pages : 11 > > > Date : 2013-06-12 > > > > > > Abstract: > > > This document specifies the requirements for an end-to-end session > > > identifier in IP-based multimedia communication networks. This > > > identifier would enable endpoints, intermediate devices, and > > > management and monitoring systems to identify a session end-to-end > > > across multiple SIP devices, hops, and administrative domains. > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Mon Jul 22 19:50:52 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6918711E8183 for ; Mon, 22 Jul 2013 19:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=0.192, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ugbtigYgifB for ; Mon, 22 Jul 2013 19:50:46 -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 702AF21F894E for ; Mon, 22 Jul 2013 19:50:43 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta14.westchester.pa.mail.comcast.net with comcast id 3ef81m0051vXlb85EeqiP7; Tue, 23 Jul 2013 02:50:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 3eqi1m00e3ZTu2S3deqig3; Tue, 23 Jul 2013 02:50:42 +0000 Message-ID: <51EDEF82.3060908@alum.mit.edu> Date: Mon, 22 Jul 2013 22:50:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "insipid@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=1374547842; bh=T+yOUG97OBXeXElL3lc+JWQQr5cc0Ot7IOq/nK9KNmQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DgUJBboTeQmFli19Bx8Rn9NkhjTlg+nUZLwQ+Ladv5zUirWS44gIbKfFHvOcIVsFH oKhoQelN99saAap6UP7lsnjVOYCINKkqmuMJLJa41inW5QGY4F7yt9y0cEJwOQC3yH S9TTq5u62CK7sacoK1IKVZwaSx8ryTP+nO3rSayY3D5F62CnmId1tzyF5sE3bMyZ2V deiUiUXX0/A71V+XBStLSkkOZc4vzbWCv1RUYdT7y+85H1jtMoEHolX6ytkupsZT7e nowSGGeOkOESbuuHnemhllgcSMgmtvw6ZQG8peMV5lSZdQ3pbS6u5pAq24F/IUpYMz lCUoGWF/ybIUg== Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 02:50:52 -0000 Some questions about this draft: The requirements and other discussion imply certain behavior by servers that support this. I'd like to hear more explicit discussion of what that expected behavior is, within the potential solutions. E.g., when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time. Section 7.1: This says the header is first inserted by the UAC. There might be reason to have it inserted by the UAS in some cases, or even a proxy or B2BUA based on policy for debugging a UA that can't be controlled. Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers. I want to hear more about sending the address of the server collecting logs. For this to be useful there must be an explicit or implicit protocol used to transmit the logs. Is there one such protocol or many? If many, how do you know which will be supported? What about trust by the server doing the logging of the log server, and authorization by the log server of those sending logs? Will all servers doing logging want to use a server chosen by the one inserting the logme request? Section 7.2: Where does the test case id go with this solution? In Figure 3 the call-info in the figure is syntactically incorrect. The parameter is a domain name, but it is required to be a URL. Thanks, Paul From keith.drage@alcatel-lucent.com Wed Jul 24 05:35:29 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D6111E8215 for ; Wed, 24 Jul 2013 05:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BgZ6Sal8hMT for ; Wed, 24 Jul 2013 05:35:24 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E878A11E821A for ; Wed, 24 Jul 2013 05:35:15 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6OCZD8u001820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Jul 2013 07:35:14 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6OCZCUU010298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jul 2013 14:35:13 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 24 Jul 2013 14:35:13 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: IPR declarations on draft-ietf-insipid-session-id Thread-Index: Ac6IajxkQe1y1DL1TCalKGBRmuNy0A== Date: Wed, 24 Jul 2013 12:35:12 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B071AB0@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [Insipid] IPR declarations on draft-ietf-insipid-session-id X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 12:35:29 -0000 (As WG cochair) There were a number of IPR declarations against the requirements document, = and two IPR declarations against the author draft that eventually became th= e solutions document. Currently no IPR declarations have been made directly against draft-ietf-in= sipid-session-id. https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-insipid-session-id=20 I would ask those organizations / individuals that made IPR declarations ab= ove against earlier documents to review and submit if appropriate their pot= ential declarations against draft-ietf-insipid-session-id. And of course if anyone else out there thinks they have IPR on the solution= , then please do declare it. Regards Keith From keith.drage@alcatel-lucent.com Wed Jul 24 09:50:25 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0822A11E8115 for ; Wed, 24 Jul 2013 09:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlC4kT-OE4gg for ; Wed, 24 Jul 2013 09:50:19 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D093A11E8111 for ; Wed, 24 Jul 2013 09:50:18 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6OGoFmY010493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Jul 2013 11:50:17 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6OGoFe8014221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jul 2013 18:50:15 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 24 Jul 2013 18:50:15 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: WGLC for draft-ietf-insipid-session-id-reqts-07 Thread-Index: Ac58OGhKYBWRLys3QOmOsXUVqzCOigAaK6twAWYUl8ABlQrdMA== Date: Wed, 24 Jul 2013 16:50:14 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B071EDA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B066D52@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B067448@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06AE2F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:50:25 -0000 [As WGLC cochair] The WGLC has completed. No comments have been submitted and a number of mai= ls have been received from people indicating that they have read the docume= nt and are happy with it. The next step is to submit the draft to the IESG, and that is currently in = progress. I have identified a number of editorials for correction, and this= will occur when the new version has been issued. Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: 16 July 2013 16:32 > To: insipid@ietf.org > Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 >=20 > (As WG cochair) >=20 > A reminder of this working group last call, now you all have plenty of > time following the draft deadline. >=20 > If you have read it and have no comments, then do send the chairs a short > mail saying that. >=20 > Keith >=20 > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf > > Of DRAGE, Keith (Keith) > > Sent: 09 July 2013 13:42 > > To: insipid@ietf.org > > Subject: Re: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 > > > > (As WG cochair) > > > > I've just been double checking, and having thought that we had already > had > > a WGLC on it, I find that formally, this is the first. I will therefore > > extend this WGLC until 23rd July 2013 to give it the full 2 weeks. > > > > I'd also remind you that there are a number of IPR declarations against > > this document > > > > > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_docu= men > > t_tag=3Ddraft-ietf-insipid-session-id-reqts > > > > I believe we have briefly discussed these in the past, but please raise > > any concerns you have with proceeding with the draft in the presence of > > these declarations. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf > > > Of DRAGE, Keith (Keith) > > > Sent: 09 July 2013 01:10 > > > To: insipid@ietf.org > > > Subject: [Insipid] WGLC for draft-ietf-insipid-session-id-reqts-07 > > > > > > (As WG co chair) > > > > > > This document has been around for 3 or 4 weeks now and has attracted > no > > > comments to update it. > > > > > > The chairs would therefore like to make a further one week WGLC to > check > > > that the document has been finished and ready to do a publication > > request. > > > > > > So if you have any comments before we request IESG to approve this as > an > > > informational document, then please make them by close of business on > > 16th > > > July. > > > > > > Regards > > > > > > Keith > > > > > > > > > Title : Requirements for an End-to-End Session > > > Identification in IP-Based Multimedia Communication Networks > > > Author(s) : Paul E. Jones > > > Gonzalo Salgueiro > > > James Polk > > > Laura Liess > > > Hadriel Kaplan > > > Filename : draft-ietf-insipid-session-id-reqts-07.txt > > > Pages : 11 > > > Date : 2013-06-12 > > > > > > Abstract: > > > This document specifies the requirements for an end-to-end session > > > identifier in IP-based multimedia communication networks. This > > > identifier would enable endpoints, intermediate devices, and > > > management and monitoring systems to identify a session end-to-end > > > across multiple SIP devices, hops, and administrative domains. > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Thu Jul 25 12:53:49 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062FF21F8B04 for ; Thu, 25 Jul 2013 12:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSui0xOSaTXw for ; Thu, 25 Jul 2013 12:53:43 -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 6AF3121F8C9D for ; Thu, 25 Jul 2013 12:53:35 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta14.westchester.pa.mail.comcast.net with comcast id 4gpC1m0020EZKEL5Ejta0n; Thu, 25 Jul 2013 19:53:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id 4jta1m0103ZTu2S3MjtaeD; Thu, 25 Jul 2013 19:53:34 +0000 Message-ID: <51F1823E.5040200@alum.mit.edu> Date: Thu, 25 Jul 2013 15:53:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "insipid@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=1374782014; bh=74MVfh3UOgcjfzju11DXco9x5tfZ/UmKCL/1ibgZbzU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Vqm3sDZ/z5s79i5tY6bptz6z6UU0rqTljqXYzc2bbGJAHNjZfULMwMcXBN1H0vGZK u2JVk+rWaD8JfJpG2M5MBkxrA85R5PSXN6QJHTHCn8F2WUI1ZRX/KwcAwySGhyY9rI 996z1sCaZSlR86sN48RdobNPaRhG3vgpDiPyDwA9LNBdyupxdT/KOcwQsrtn07udR9 Cb0vI0PxJB6g5ZKmmhLgxOjhcezbRnzui+csRbaAiV/BveSV9L/Pj/RKI403abh1b5 kqPx8yszSDLpehkvI0i+9+36h+CuR/EXVFaEm2nDz1F/9rMImVb+RhShk4WXWjh4kN KmHvltquxAxVg== Subject: [Insipid] draft-ietf-insipid-session-id-02 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 19:53:49 -0000 I made earlier comments on this version that still apply. The following is (I think) new to this version, though I have raised similar comment against earlier versions: Section 9.3: It says: "Bob sends a reINVITE to Alice...informing her to transfer her existing call to Carol." As described this makes no sense. There is nothing about a reinvite that informs the recipient to transfer the call. So this example needs to be changed somehow. Either the flow should change, or else at least the text needs to be expanded to explain how it is that the B2BUA (not Bob) decides to transfer the call, and why Bob sent an reinvite to accomplish this. Thanks, Paul From hadriel.kaplan@oracle.com Mon Jul 29 01:06:39 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902F421F9C55 for ; Mon, 29 Jul 2013 01:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4try5eACt2F for ; Mon, 29 Jul 2013 01:06:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 047E821F9E12 for ; Mon, 29 Jul 2013 01:06:28 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6T86MaB002577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Jul 2013 08:06:23 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 r6T86La0007122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 08:06:22 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6T86L3R012651; Mon, 29 Jul 2013 08:06:21 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jul 2013 01:06:21 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B066DAF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 29 Jul 2013 04:06:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032c01ce7c31$48ea00e0$dabe02a0$@packetizer.com> <949EF20990823C4C85C18D59AA11AD8B066DAF@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:06:39 -0000 I think there needs some discussion and justification for why the = sess-id value order/placement is swapped in SIP responses and upstream = requests, instead of being kept the same order throughout. This = order-changing breaks backward compatibility with the older Session-ID = individual draft, and is arguably harder to use/find in logs and = wireshark for troubleshooting purposes. I think someone mentioned some = reason this re-ordering was necessary, but I can't recall what it is and = I don't see it explained in the draft. -hadriel On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" = wrote: > (As WG cochair) >=20 > As well as reviewing the document generally, it would be useful if the = WG membership could indicate any issues they think need face to face = discussion time in Berlin. >=20 > Or is everything going perfectly? >=20 > Apart from what is listed below, is anything else missing from the = document? >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf >> Of Paul E. Jones >> Sent: 09 July 2013 00:17 >> To: insipid@ietf.org >> Subject: [Insipid] draft-ietf-insipid-session-id-01 >>=20 >> Folks, >>=20 >> I posted a new version of draft-ietf-insipid-session-id for your >> consideration. >>=20 >> One significant addition is one to address a comment Laura had about >> ensuring that intermediary devices can consistently re-create a UUID = and >> remain stateless. New text is introduced in Section 4.1 that = describes >> how >> such entities can construct the UUIDs. >>=20 >> Section 6 was also revised with text to explain that the UUID order >> relates >> to who sends the message. It also discusses the longevity of the = UUID, >> logging, and changes to the "remote" UUID. >>=20 >> Previously, requests were made for additional call flows. Those were = not >> added to the document, but the requests are listed as TODO items in >> section(s) under section 9. There is also a TODO for section 9 = related to >> requested changes to section 9 to make it cleared the text is just >> examples. >>=20 >> Paul >>=20 >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From internet-drafts@ietf.org Mon Jul 29 17:09:54 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6C511E80E0; Mon, 29 Jul 2013 17:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZXXDh+TIokl; Mon, 29 Jul 2013 17:09:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CC121F8EFE; Mon, 29 Jul 2013 17:09:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730000953.29250.25138.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 17:09:53 -0700 Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-reqts-08.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 00:09:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the INtermediary-safe SIP session ID Working = Group of the IETF. Title : Requirements for an End-to-End Session Identification in= IP-Based Multimedia Communication Networks Author(s) : Paul E. Jones Gonzalo Salgueiro James Polk Laura Liess Hadriel Kaplan Filename : draft-ietf-insipid-session-id-reqts-08.txt Pages : 11 Date : 2013-07-29 Abstract: This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-insipid-session-id-reqts-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From atle.monrad@ericsson.com Tue Jul 30 02:24:52 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2648111E8144 for ; Tue, 30 Jul 2013 02:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=2.825, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCbV6aghgmkn for ; Tue, 30 Jul 2013 02:24:37 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 817F311E81CB for ; Tue, 30 Jul 2013 02:22:30 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-b9-51f785cdc764 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EC.F6.19388.DC587F15; Tue, 30 Jul 2013 11:22:22 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.48]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Tue, 30 Jul 2013 11:22:21 +0200 From: Atle Monrad To: Hadriel Kaplan , Robert Sparks Thread-Topic: [Insipid] publishing draft-kaplan session-id as historic Thread-Index: AQHOIDw3D/Lw37+nlUOfmGw4zhPOkpl9yxNw Date: Tue, 30 Jul 2013 09:22:20 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C14E94C@ESESSMB203.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <5140E9ED.5060206@nostrum.com> <919553E8-D8AB-4B56-A68D-1AF46A5B72C3@acmepacket.com> In-Reply-To: <919553E8-D8AB-4B56-A68D-1AF46A5B72C3@acmepacket.com> Accept-Language: nb-NO, 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+Jvre651u+BBut+clrMvfyc3WL+/WdM FtfmNLI5MHtsmryZzWPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgyrjefpi54JhNRcvSuAbG RsMuRk4OCQETiVctDUwQtpjEhXvr2boYuTiEBA4zSpy+85QRwlnMKDHp3Eo2kCo2AR2Jcz/v sILYIgLBEn+ed7CA2MwC2hJ3z70Bs4UFXCXW3N/DDlHjJvH9xQc2CNtI4uWSP8wgNouAqkTb 97Ngc3gFvCVuf5vDDLFsAZPEyebnYCdxCjhJfG7tAmrm4GAUkJWY28QLsUtc4taT+VBXC0gs 2XOeGcIWlXj5+B8rhK0k8WPDJajbdCQW7P7EBnPnsoWvmSH2CkqcnPmEZQKj2CwkY2chaZmF pGUWkpYFjCyrGNlzEzNz0svNNzEC4+bglt8GOxg33Rc7xCjNwaIkzrtZ70ygkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBkbTwsZzSw8eWPlFafvE3tTzx9pE1HsSxPtOd5ZtK5lhXPT5sWc6 /yaTPd6ct6Y+0hLqlrEW/FfIa+a+btcdJZ/pl6Vn72ucxckQt2DZVr3F77waZvTUSlVE5x5+ dGdjeOhafa74Ty6/lIxnKhcYvzj1wKiq10BVeJFvPLP9JKbv3hP01oieYVdiKc5INNRiLipO BADv3njjaQIAAA== Cc: "" Subject: Re: [Insipid] publishing draft-kaplan session-id as historic X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:24:53 -0000 Hadriel Will you at some point in the not too far future kindly do the necessary ed= its to gracefully park this draft in the archives as an RFC ?? Cheers /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Hadriel Kaplan Sent: 13. mars 2013 23:44 To: Robert Sparks Cc: Subject: Re: [Insipid] publishing draft-kaplan session-id as historic Yes sorry I should have been clearer - I realize I'll have to edit the doc = to actually submit, I just meant using 03 as the version vs. 02 or 01 or wh= atever. -hadriel On Mar 13, 2013, at 5:04 PM, Robert Sparks wrote: > On 3/13/13 4:36 PM, Hadriel Kaplan wrote: >> From today's meeting action I took... below was the email. >> The difference between draft-kaplan-dispatch-session-id-03 and 02 can be= seen here: >>=20 >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-kaplan-dispatch-session-id-03= .txt >>=20 >> It did not change the ABNF nor protocol rules. Therefore I propose to s= ubmit 03 as independent submission to the RFC Editor, for 'Historic' status= . Or 'Epic' status if they have that. :) > It wouldn't be -03 as is - there needs to be an editing pass explaining t= his document's this is a proprietary something that may be in the wild. The= text should be touched to make it an exposition (This is what you would ha= ve seen) vs a specification (this is what you should do). >=20 > RjS >=20 >>=20 >> -hadriel >>=20 >>=20 >> On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan wro= te: >>=20 >>> When we talked about this in Vancouver I was thinking there wouldn't be= any problem going to/from UUID syntax, because going to/from UUIDs in H.32= 3 was talked about a long, long time ago for session-id. But I forgot abou= t the bug in the draft-kaplan ABNF... >>>=20 >>> Since version 01 of draft-kaplan-sip-session-id in 2008, which later be= came draft-kaplan-dispatch-session-id, the rules for generating the session= -id always made it lower-case *hex* characters. I.e., the g-z range wasn't= actually possible. The ABNF for it didn't get fixed until draft-kaplan-di= spatch-session-id-01 in April 2010, but that also dropped it to 16 characte= rs of hex because the algorithm changed, and then 3 months later reverted b= ack to 32 characters and the correct ABNF. >>>=20 >>> So that begs the question of *which* version of draft-kaplan we want to= be backwards compatible with. Since draft-kaplan-dispatch-session-id-01 o= nly existed for 3 months, I think we can ignore that one. And since everyt= hing else only used hex characters, except the initial 00-draft which itsel= f only existed for 4 months, I think we can ignore that one too. >>>=20 >>> Therefore, as far as I can tell we shouldn't have a problem converting = draft-kaplan session-ids to/from UUIDs for H.323/whatever. >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote: >>>=20 >>>> Hi, >>>>=20 >>>> In Vancouver, I expressed a wish to make the INSIPID mechanism backwar= d compatible with the draft-kaplan-session-id one, the reason being that it= has been around for a relatively long time, and has been implemented and d= eployed. >>>>=20 >>>> I compared the suggested draft-jones solution with the draft-kaplan so= lution, and I think there are ways to achieve backward compability. >>>>=20 >>>>=20 >>>> -------------- >>>>=20 >>>>=20 >>>> FIRST, looking purely at the ABNF syntax: >>>>=20 >>>> The jones ABNF is: >>>>=20 >>>>=20 >>>> Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID >>>>=20 >>>>=20 >>>>=20 >>>> The kaplan ABNF is: >>>>=20 >>>>=20 >>>>=20 >>>> Session-ID =3D "Session-ID" HCOLON sess-id >>>>=20 >>>> *( SEMI generic-param ) >>>>=20 >>>> sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Now, assuming 32 chars is enough to carry ONE UUID, jones applications= could put the SECOND UUID in a header field parameter (generic-param), rat= her than combining it with the received UUID. >>>>=20 >>>>=20 >>>>=20 >>>> Of course, the first UUDI (carried in sess-id) can only contains chara= cters 0-9 and a-z. >>>>=20 >>>>=20 >>>>=20 >>>> A UUID can contain characters 0-9 and a-f and A-F. >>>>=20 >>>>=20 >>>>=20 >>>> So, a jones entity would have to be prepared to receive g-z. >>>>=20 >>>>=20 >>>>=20 >>>> And, as kaplan entity is not prepared to receive capital A-F, a jones = entity would have to only use small letters. But, that should not be a prob= lem, afaik, as they have the same meaning as far as UUID is concerned. >>>>=20 >>>>=20 >>>>=20 >>>> -------------- >>>>=20 >>>>=20 >>>>=20 >>>> SECOND, looking at it would work functionwise: >>>>=20 >>>>=20 >>>>=20 >>>> There are two main alternatives: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> 1. Second UUID is added even when one entity is kaplan compliant >>>>=20 >>>> 2. Second UUID is not added when one entity is kaplan compliant >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Alternative 1: >>>>=20 >>>>=20 >>>>=20 >>>> When a kaplan entity inserts the first UUID (I use that as a general t= erm, eventhough a kaplan entity does not use UUIDs), one must assume that i= t is prepared to receive a response from a jones entity which has added the= second UUID into the header field parameter. >>>>=20 >>>>=20 >>>>=20 >>>> When a jones entity inserts the first UUID, one must assume that it is= prepared to receive a response from a kaplan entity where the second UUID = has *not* been added. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Alternative 2: >>>>=20 >>>>=20 >>>>=20 >>>> When a kaplan entity inserts the first UUID, the jones entity detects = (using some identify-a-kaplan-entity mechanism) that it comes from a kaplan= entity, so it does not insert a seoncd UUID in the first place. >>>>=20 >>>>=20 >>>>=20 >>>> As in alternative 1, when a jones entity inserts the first UUID, it ha= s to be prepared to receive a response where the second UUID has not been a= dded (the identify-a-kaplan-entity mechanism might also inform the jones en= tity that the response comes from a kaplan entity. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -------------- >>>>=20 >>>>=20 >>>>=20 >>>> Now, there will of course be cases, where two UUIDs are required, that= won't work. But, kaplan entities would be able to use the session-id for w= hatever they've used it so far. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>>=20 >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Tue Jul 30 02:35:22 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D7A11E8137 for ; Tue, 30 Jul 2013 02:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.591 X-Spam-Level: X-Spam-Status: No, score=-110.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evC0jE7CdkGK for ; Tue, 30 Jul 2013 02:35:16 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 788EC11E80C5 for ; Tue, 30 Jul 2013 02:35:05 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6U9YkG0025887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 30 Jul 2013 04:34:48 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6U9YcR2014322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jul 2013 11:34:46 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 30 Jul 2013 11:34:33 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: Publication request for draft-ietf-insipid-session-id-reqts-08 Thread-Index: Ac6NBpgBWX7x9hAiQ9i6j0IHFHr3wg== Date: Tue, 30 Jul 2013 09:34:33 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B077956@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <809149FEF0AE86419D42BA6D077275C1@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [Insipid] Publication request for draft-ietf-insipid-session-id-reqts-08 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:35:22 -0000 I have just requested publication (i.e. sent to the IESG) of the INSIPID re= quirements document. draft-ietf-insipid-session-id-reqts-08 The writeup is as follows. Regards Keith -------------------------- Document writeup for "Requirements for an End-to-End Session Identification= in IP-Based Multimedia Communication Networks" draft-ietf-insipid-session-= id-reqts-08 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? It is intended that the document be published as informational. It is not i= ntended that this document should be applicable directly to an implementati= on, but rather identifies a set of requirements on which a future IETF solu= tion will be built; the latter document will be standards track. In the cas= es where these requirements are a standalone document, they have traditiona= lly been published as an informational RFC. The document status is indicated in the document title page. (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introductio= n of the document. If not, this may be an indication that there are deficie= ncies in the abstract or introduction. This document specifies the requirements for an end-to-end session identifi= er in IP-based multimedia communication networks. This identifier would en= able endpoints, intermediate devices, and management and monitoring systems= to identify a session end-to-end across multiple SIP devices, hops, and ad= ministrative domains. Working Group Summary: Was there anything in WG process that is worth noting? For example, was the= re controversy about particular points or were there decisions where the co= nsensus was particularly rough? The document has achieved working group consensus. One particular issue was on how much terminology to define in this document= , and section 3 has been substantially worked upon within the working group= . There also has been significant discussion on the scoping of the work, and = its applicability to more complex scenarios. In accordance with the charter= , the work has been kept to the simpler scenarios, and the applicability to= the more complex scenarios will be limited to whatever works as a result. Document Quality: Are there existing implementations of the protocol? Have a significant numb= er of vendors indicated their plan to implement the specification? Are ther= e any reviewers that merit special mention as having done a thorough review= , e.g., one that resulted in important changes or a conclusion that the doc= ument had no substantive issues? If there was a MIB Doctor, Media Type or o= ther expert review, what was its course (briefly)? In the case of a Media T= ype review, on what date was the request posted? There are no implementations as this is a requirements document. The workin= g group is currently working on a solutions document in draft-ietf-insipid-= session-id. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Keith Drage is the document shepherd. Gonzalo Camarillo is the responsible = area director. (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. Primarily a read through to ensure all the text is consistent with the rema= inder of the document, along with a check for editorial and idnit issues. T= he working group has gone several times through each requirement in the req= uirements clause in open discussion. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? The document shepherd has no concerns about the depth or breadth of the rev= iews that have been performed. (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. This document does not need reviews from a particular or a from a broader p= erspective. The solution document might need such wider reviews, but this i= s not appropriate for a requirements document. (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. The document shepherd has no concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why? Each author has confirmed that all appropriate IPR disclosures have been ma= de. Note that some authors have declared IPR on the related solutions document,= but do not consider such a declaration impacts the requirements document. (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. IPR disclosures have been filed on this document. These have been identifie= d in working group discussions, and further brought to the working group's = attention during the working group last call. No concerns have been raised = within the working group. (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? The contents of this document have been extensively discussed amongst many = individuals in this working group. A significant number of individuals have indicated they had read the docume= nt during working group last call and had no further comments. (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No such view has been expressed. (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. No idnits have been found and the document passes the boilerplate checks. (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. The document contains no material of a formal nature requiring such review. (13) Have all references within this document been identified as either nor= mative or informative? Yes. (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure. There are no downward references. (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. This document is not of such a nature to change any other RFC. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). The document has no IANA considerations, as it makes no changes to any IANA= registry. (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. The document has no IANA considerations, as it makes no changes to any IANA= registry. (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. The document contains no material of a formal nature requiring such review. From keith.drage@alcatel-lucent.com Tue Jul 30 03:41:24 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB22121F9EED for ; Tue, 30 Jul 2013 03:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.592 X-Spam-Level: X-Spam-Status: No, score=-111.592 tagged_above=-999 required=5 tests=[AWL=1.007, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r20AN9gwg-97 for ; Tue, 30 Jul 2013 03:41:18 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 28FBF21F9EC2 for ; Tue, 30 Jul 2013 03:41:18 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6UAfBid024847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2013 05:41:12 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6UAf6VR032109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 12:41:06 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 30 Jul 2013 12:41:06 +0200 From: "DRAGE, Keith (Keith)" To: Atle Monrad , Hadriel Kaplan , Robert Sparks Thread-Topic: [Insipid] publishing draft-kaplan session-id as historic Thread-Index: AQHOIDw3D/Lw37+nlUOfmGw4zhPOkpl9yxNwgAAVkBA= Date: Tue, 30 Jul 2013 10:41:05 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B077ADF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <5140E9ED.5060206@nostrum.com> <919553E8-D8AB-4B56-A68D-1AF46A5B72C3@acmepacket.com> <7D2F7D7ADBA812449F25F4A69922881C14E94C@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C14E94C@ESESSMB203.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "" Subject: Re: [Insipid] publishing draft-kaplan session-id as historic X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:41:24 -0000 The following document has been around since 14th July https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/=20 Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Atle Monrad > Sent: 30 July 2013 10:22 > To: Hadriel Kaplan; Robert Sparks > Cc: > Subject: Re: [Insipid] publishing draft-kaplan session-id as historic >=20 > Hadriel >=20 > Will you at some point in the not too far future kindly do the necessary > edits to gracefully park this draft in the archives as an RFC ?? >=20 > Cheers >=20 > /atle >=20 > ________________________________ >=20 >=20 > Atle Monrad > 3GPP CT Chairman >=20 > Group Function Technology - Standardization and Technical Regulation > Ericsson >=20 >=20 >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Hadriel Kaplan > Sent: 13. mars 2013 23:44 > To: Robert Sparks > Cc: > Subject: Re: [Insipid] publishing draft-kaplan session-id as historic >=20 >=20 > Yes sorry I should have been clearer - I realize I'll have to edit the do= c > to actually submit, I just meant using 03 as the version vs. 02 or 01 or > whatever. >=20 > -hadriel >=20 >=20 > On Mar 13, 2013, at 5:04 PM, Robert Sparks wrote: >=20 > > On 3/13/13 4:36 PM, Hadriel Kaplan wrote: > >> From today's meeting action I took... below was the email. > >> The difference between draft-kaplan-dispatch-session-id-03 and 02 can > be seen here: > >> > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-kaplan-dispatch-session-id- > 03.txt > >> > >> It did not change the ABNF nor protocol rules. Therefore I propose to > submit 03 as independent submission to the RFC Editor, for 'Historic' > status. Or 'Epic' status if they have that. :) > > It wouldn't be -03 as is - there needs to be an editing pass explaining > this document's this is a proprietary something that may be in the wild. > The text should be touched to make it an exposition (This is what you > would have seen) vs a specification (this is what you should do). > > > > RjS > > > >> > >> -hadriel > >> > >> > >> On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan > wrote: > >> > >>> When we talked about this in Vancouver I was thinking there wouldn't > be any problem going to/from UUID syntax, because going to/from UUIDs in > H.323 was talked about a long, long time ago for session-id. But I forgo= t > about the bug in the draft-kaplan ABNF... > >>> > >>> Since version 01 of draft-kaplan-sip-session-id in 2008, which later > became draft-kaplan-dispatch-session-id, the rules for generating the > session-id always made it lower-case *hex* characters. I.e., the g-z > range wasn't actually possible. The ABNF for it didn't get fixed until > draft-kaplan-dispatch-session-id-01 in April 2010, but that also dropped > it to 16 characters of hex because the algorithm changed, and then 3 > months later reverted back to 32 characters and the correct ABNF. > >>> > >>> So that begs the question of *which* version of draft-kaplan we want > to be backwards compatible with. Since draft-kaplan-dispatch-session-id- > 01 only existed for 3 months, I think we can ignore that one. And since > everything else only used hex characters, except the initial 00-draft > which itself only existed for 4 months, I think we can ignore that one to= o. > >>> > >>> Therefore, as far as I can tell we shouldn't have a problem convertin= g > draft-kaplan session-ids to/from UUIDs for H.323/whatever. > >>> > >>> -hadriel > >>> > >>> > >>> On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote: > >>> > >>>> Hi, > >>>> > >>>> In Vancouver, I expressed a wish to make the INSIPID mechanism > backward compatible with the draft-kaplan-session-id one, the reason bein= g > that it has been around for a relatively long time, and has been > implemented and deployed. > >>>> > >>>> I compared the suggested draft-jones solution with the draft-kaplan > solution, and I think there are ways to achieve backward compability. > >>>> > >>>> > >>>> -------------- > >>>> > >>>> > >>>> FIRST, looking purely at the ABNF syntax: > >>>> > >>>> The jones ABNF is: > >>>> > >>>> > >>>> Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID > >>>> > >>>> > >>>> > >>>> The kaplan ABNF is: > >>>> > >>>> > >>>> > >>>> Session-ID =3D "Session-ID" HCOLON sess-id > >>>> > >>>> *( SEMI generic-param ) > >>>> > >>>> sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z= ] > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Now, assuming 32 chars is enough to carry ONE UUID, jones > applications could put the SECOND UUID in a header field parameter > (generic-param), rather than combining it with the received UUID. > >>>> > >>>> > >>>> > >>>> Of course, the first UUDI (carried in sess-id) can only contains > characters 0-9 and a-z. > >>>> > >>>> > >>>> > >>>> A UUID can contain characters 0-9 and a-f and A-F. > >>>> > >>>> > >>>> > >>>> So, a jones entity would have to be prepared to receive g-z. > >>>> > >>>> > >>>> > >>>> And, as kaplan entity is not prepared to receive capital A-F, a jone= s > entity would have to only use small letters. But, that should not be a > problem, afaik, as they have the same meaning as far as UUID is concerned= . > >>>> > >>>> > >>>> > >>>> -------------- > >>>> > >>>> > >>>> > >>>> SECOND, looking at it would work functionwise: > >>>> > >>>> > >>>> > >>>> There are two main alternatives: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 1. Second UUID is added even when one entity is kaplan compliant > >>>> > >>>> 2. Second UUID is not added when one entity is kaplan compliant > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Alternative 1: > >>>> > >>>> > >>>> > >>>> When a kaplan entity inserts the first UUID (I use that as a general > term, eventhough a kaplan entity does not use UUIDs), one must assume tha= t > it is prepared to receive a response from a jones entity which has added > the second UUID into the header field parameter. > >>>> > >>>> > >>>> > >>>> When a jones entity inserts the first UUID, one must assume that it > is prepared to receive a response from a kaplan entity where the second > UUID has *not* been added. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Alternative 2: > >>>> > >>>> > >>>> > >>>> When a kaplan entity inserts the first UUID, the jones entity detect= s > (using some identify-a-kaplan-entity mechanism) that it comes from a > kaplan entity, so it does not insert a seoncd UUID in the first place. > >>>> > >>>> > >>>> > >>>> As in alternative 1, when a jones entity inserts the first UUID, it > has to be prepared to receive a response where the second UUID has not > been added (the identify-a-kaplan-entity mechanism might also inform the > jones entity that the response comes from a kaplan entity. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -------------- > >>>> > >>>> > >>>> > >>>> Now, there will of course be cases, where two UUIDs are required, > that won't work. But, kaplan entities would be able to use the session-id > for whatever they've used it so far. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Regards, > >>>> > >>>> > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> insipid mailing list > >>>> insipid@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/insipid > >>> _______________________________________________ > >>> insipid mailing list > >>> insipid@ietf.org > >>> https://www.ietf.org/mailman/listinfo/insipid > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From laura.liess.dt@googlemail.com Tue Jul 30 04:18:58 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3211E81D4 for ; Tue, 30 Jul 2013 04:18:58 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4IjMEuMDkfp for ; Tue, 30 Jul 2013 04:18:57 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4311E814F for ; Tue, 30 Jul 2013 04:18:56 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id v20so4571941lbc.27 for ; Tue, 30 Jul 2013 04:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HtuCGq59/01pcqwweFyTkWULgDcpmToiFm3TramuBKo=; b=H6LstqqVoWe8v/dDVAUKJMglyTVftOsbuiql4Gq5vQajm6Mc/FWzP/kEI36tAZhMAw GPbNOun8j6s6VFZ8mpke/cQ14Ky4Iz1wI1iW57ogfGSdkkMODBzIaBpUeidpe1XogWdU wXDp+gATRlMOPDUzfjzmK7i+N/dTSiELtFoiE5mMV+XUUAXJHUcLvCYSOYHZfPBUwv4i PZqy5sZ0BEo23hgKk4HKud00uulAA8hAGs/aCMqX1Fu7e4FXnR1v5XE5oNbOTo7+mLeQ B5RwPBeQ4xnJfakoiFzfNmEZyOVmF89rc/IGwzq2AQXS2+vUnvzKpBwi8wy4SM+UXLXM WBAQ== MIME-Version: 1.0 X-Received: by 10.152.170.162 with SMTP id an2mr28720360lac.3.1375183134038; Tue, 30 Jul 2013 04:18:54 -0700 (PDT) Received: by 10.114.75.144 with HTTP; Tue, 30 Jul 2013 04:18:53 -0700 (PDT) In-Reply-To: References: <032c01ce7c31$48ea00e0$dabe02a0$@packetizer.com> <949EF20990823C4C85C18D59AA11AD8B066DAF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 30 Jul 2013 13:18:53 +0200 Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=089e011615e434a0cc04e2b8c6b5 Cc: "DRAGE, Keith \(Keith\)" , "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:18:58 -0000 --089e011615e434a0cc04e2b8c6b5 Content-Type: text/plain; charset=ISO-8859-1 I agree with Hadriel. If I remember correctly, we had an agreement in the WG that the identifier defined here has to be backward compatible with the session-id identifier defined in Hadriel's draft and that a reference to this draft has to be added. Backward incompatibility with Hadriel's session-id would be a big drawback for the implementation of the new identifier within carrier networks. Carriers as my employer, where Hadriel's session-id is already implemented, will never switch to the new identifier. They will require the old identifier for any new systems they buy, including conferencing systems. Because Hadriel's session-id is used in the 3GPP IMS specificatios, I assume that the situation is the same for other carriers using IMS. Thank you Laura 2013/7/29 Hadriel Kaplan > > I think there needs some discussion and justification for why the sess-id > value order/placement is swapped in SIP responses and upstream requests, > instead of being kept the same order throughout. This order-changing > breaks backward compatibility with the older Session-ID individual draft, > and is arguably harder to use/find in logs and wireshark for > troubleshooting purposes. I think someone mentioned some reason this > re-ordering was necessary, but I can't recall what it is and I don't see it > explained in the draft. > > -hadriel > > > On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" < > keith.drage@alcatel-lucent.com> wrote: > > > (As WG cochair) > > > > As well as reviewing the document generally, it would be useful if the > WG membership could indicate any issues they think need face to face > discussion time in Berlin. > > > > Or is everything going perfectly? > > > > Apart from what is listed below, is anything else missing from the > document? > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf > >> Of Paul E. Jones > >> Sent: 09 July 2013 00:17 > >> To: insipid@ietf.org > >> Subject: [Insipid] draft-ietf-insipid-session-id-01 > >> > >> Folks, > >> > >> I posted a new version of draft-ietf-insipid-session-id for your > >> consideration. > >> > >> One significant addition is one to address a comment Laura had about > >> ensuring that intermediary devices can consistently re-create a UUID and > >> remain stateless. New text is introduced in Section 4.1 that describes > >> how > >> such entities can construct the UUIDs. > >> > >> Section 6 was also revised with text to explain that the UUID order > >> relates > >> to who sends the message. It also discusses the longevity of the UUID, > >> logging, and changes to the "remote" UUID. > >> > >> Previously, requests were made for additional call flows. Those were > not > >> added to the document, but the requests are listed as TODO items in > >> section(s) under section 9. There is also a TODO for section 9 related > to > >> requested changes to section 9 to make it cleared the text is just > >> examples. > >> > >> Paul > >> > >> > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > --089e011615e434a0cc04e2b8c6b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Hadriel.=A0 If I remember correctly, we had an agreement in th= e WG that the identifier defined here has to be backward compatible with th= e session-id identifier defined in Hadriel's draft and that a reference= to this draft has to be added.

Backward incompatibility with Hadriel's session-id would be a big d= rawback for the implementation of the new identifier within carrier network= s. Carriers as my employer, where Hadriel's session-id is already imple= mented, will never switch to the new identifier. They will require the old = identifier for any new systems they buy, including conferencing systems.
Because Hadriel's session-id is used in the 3GPP IMS specificatios,= I assume that the situation is the same for other carriers using IMS.
=
Thank you
Laura =A0 =A0



2= 013/7/29 Hadriel Kaplan <hadriel.kaplan@oracle.com><= br>

I think there needs some discussion and justification for why the sess-id v= alue order/placement is swapped in SIP responses and upstream requests, ins= tead of being kept the same order throughout. =A0This order-changing breaks= backward compatibility with the older Session-ID individual draft, and is = arguably harder to use/find in logs and wireshark for troubleshooting purpo= ses. =A0I think someone mentioned some reason this re-ordering was necessar= y, but I can't recall what it is and I don't see it explained in th= e draft.

-hadriel


On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com&= gt; wrote:

> (As WG cochair)
>
> As well as reviewing the document generally, it would be useful if the= WG membership could indicate any issues they think need face to face discu= ssion time in Berlin.
>
> Or is everything going perfectly?
>
> Apart from what is listed below, is anything else missing from the doc= ument?
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: insipid-bounces@= ietf.org [mailto:insipid-bo= unces@ietf.org] On Behalf
>> Of Paul E. Jones
>> Sent: 09 July 2013 00:17
>> To: insipid@ietf.org
>> Subject: [Insipid] draft-ietf-insipid-session-id-01
>>
>> Folks,
>>
>> I posted a new version of draft-ietf-insipid-session-id for your >> consideration.
>>
>> One significant addition is one to address a comment Laura had abo= ut
>> ensuring that intermediary devices can consistently re-create a UU= ID and
>> remain stateless. =A0New text is introduced in Section 4.1 that de= scribes
>> how
>> such entities can construct the UUIDs.
>>
>> Section 6 was also revised with text to explain that the UUID orde= r
>> relates
>> to who sends the message. =A0It also discusses the longevity of th= e UUID,
>> logging, and changes to the "remote" UUID.
>>
>> Previously, requests were made for additional call flows. =A0Those= were not
>> added to the document, =A0but the requests are listed as TODO item= s in
>> section(s) under section 9. =A0There is also a TODO for section 9 = related to
>> requested changes to section 9 to make it cleared the text is just=
>> examples.
>>
>> Paul
>>
>>
>> _______________________________________________
>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid

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

--089e011615e434a0cc04e2b8c6b5-- From gonzalo.camarillo@ericsson.com Tue Jul 30 04:25:04 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD05D21F9048 for ; Tue, 30 Jul 2013 04:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.356 X-Spam-Level: X-Spam-Status: No, score=-103.356 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVBEFX-a0AxT for ; Tue, 30 Jul 2013 04:24:58 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 18A5321F8FCE for ; Tue, 30 Jul 2013 04:24:28 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-c6-51f7a26b1260 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 34.7E.11907.B62A7F15; Tue, 30 Jul 2013 13:24:28 +0200 (CEST) Received: from [131.160.126.17] (153.88.183.16) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Tue, 30 Jul 2013 13:24:27 +0200 Message-ID: <51F7A26B.1000704@ericsson.com> Date: Tue, 30 Jul 2013 13:24:27 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+JvrW7Oou+BBt/OcVvMv/+MyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGX0v/7AWPBGt2HJzPXsD4xnBLkYODgkBE4klv7S6GDmBTDGJ C/fWs3UxcnEICRxllHjcvhrKWc0osf/LclaQKl4BbYmNV/eD2SwCqhI3VhxmArHZBCwktty6 zwJiiwpESbT2TmWGqBeUODnzCVhcBGjD4+2TWEEWCwtYS2zaqQuxWFJiy4t2dhCbWUBPYsrV FkYIW15i+9s5YGOEgNYuf9bCMoGRfxaSqbOQtMxC0rKAkXkVI0dxanFSbrqRwSZGYDgd3PLb Ygfj5b82hxilOViUxHm36J0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBYY8KgLW+ce51B /lpcVCvfw6SC9l43P0NF15ur10mU7WaO2Bu8MDTWaOVcrY+q++NlSxILK7puzfqzrSbuZtXN j7VP5jt2nbVQ3f+3VO14NrPCFtvoOcKhUyTYl13jrnBNOLx29tufqhfz2QsOnzk+y2Tq/Myz /5aHnp/y41ttsHPUdqNFbf+VWIozEg21mIuKEwE3/2no9QEAAA== Subject: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:25:05 -0000 Hi, I just got a publication request for the requirements document: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 The following is one of the requirements in the draft, which was one of the main reasons for creating this WG: > REQ3: The solution must require that the identifier, if present, pass > unchanged through SIP B2BUAs or other intermediaries. Hadriel, who works for an important SBC vendor and is one of the authors of the requirements document, sent the comments below to the STIR list a couple of weeks ago (see email below). How should I interpret those comments in the context of my AD review of this document and, even more importantly, as the responsible AD for this WG (as you know, we have had many scope-related discussions in the past)? Thanks, Gonzalo -------- Original Message -------- Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) Date: Tue, 16 Jul 2013 10:21:13 -0400 From: Hadriel Kaplan To: Richard Shockey CC: IETF STIR Mail List On Jul 16, 2013, at 9:35 AM, "Richard Shockey" wrote: > I actually believe INSIPID is equally important to the overall task since it > is the track and trace elements of this that can ultimately enable some > enforcement. I wish there was some more discussion on how the mechanisms > would work at the edge SIP/SS7 network gateways since that clearly has been > the center of most of the reported problems. I still think something needs > to be done to police that traffic but that is still ultimately a regulatory > effort. I agree we need a tracking/tracing mechanism, but in my opinion we cannot and should not rely on INSIPID Session-ID at all for that. They have gone beyond benign troubleshooting-type purposes now, which means there is absolutely no guarantee the Session-ID will make it intact across service providers in all cases. In fact, my hunch is it won't. Regardless, the Session-ID isn't what we really need for tracing a bad caller-id call. Even without Session-ID, the service provider's CDRs or logs can be used to trace it back to the peering connection and peer upstream provider the call came in from. What we also need is a list of SPIDs the call request has crossed through, so we can trace it back further upstream. Kinda like a Via header, but with very different properties and purpose. We've talked about doing that before, back when there was talk about creating a registry of SPIDs. What ever happened to having a registry of SPIDs? -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From R.Jesske@telekom.de Tue Jul 30 04:38:27 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7BD11E81D4 for ; Tue, 30 Jul 2013 04:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luUKM8BhivGy for ; Tue, 30 Jul 2013 04:38:23 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34D11E81D7 for ; Tue, 30 Jul 2013 04:38:21 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 30 Jul 2013 13:38:19 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 30 Jul 2013 13:38:19 +0200 From: To: , Date: Tue, 30 Jul 2013 13:38:17 +0200 Thread-Topic: [Insipid] draft-ietf-insipid-session-id-01 Thread-Index: Ac6NFqJOtsnEUGkSQKmFGE24Es3XeAAApiYg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D183BA5F5CA@HE111648.emea1.cds.t-internal.com> References: <032c01ce7c31$48ea00e0$dabe02a0$@packetizer.com> <949EF20990823C4C85C18D59AA11AD8B066DAF@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: 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_580BEA5E3B99744AB1F5BFF5E9A3C67D183BA5F5CAHE111648emea1_" MIME-Version: 1.0 Cc: keith.drage@alcatel-lucent.com, insipid@ietf.org Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:38:27 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D183BA5F5CAHE111648emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Full support of Laura's statement. BR Roland Von: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] Im Auftrag = von Laura Liess Gesendet: Dienstag, 30. Juli 2013 13:19 An: Hadriel Kaplan Cc: DRAGE, Keith (Keith); insipid@ietf.org Betreff: Re: [Insipid] draft-ietf-insipid-session-id-01 I agree with Hadriel. If I remember correctly, we had an agreement in the = WG that the identifier defined here has to be backward compatible with the = session-id identifier defined in Hadriel's draft and that a reference to th= is draft has to be added. Backward incompatibility with Hadriel's session-id would be a big drawback = for the implementation of the new identifier within carrier networks. Carri= ers as my employer, where Hadriel's session-id is already implemented, will= never switch to the new identifier. They will require the old identifier f= or any new systems they buy, including conferencing systems. Because Hadriel's session-id is used in the 3GPP IMS specificatios, I assum= e that the situation is the same for other carriers using IMS. Thank you Laura 2013/7/29 Hadriel Kaplan > I think there needs some discussion and justification for why the sess-id v= alue order/placement is swapped in SIP responses and upstream requests, ins= tead of being kept the same order throughout. This order-changing breaks b= ackward compatibility with the older Session-ID individual draft, and is ar= guably harder to use/find in logs and wireshark for troubleshooting purpose= s. I think someone mentioned some reason this re-ordering was necessary, b= ut I can't recall what it is and I don't see it explained in the draft. -hadriel On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" > wrote: > (As WG cochair) > > As well as reviewing the document generally, it would be useful if the WG= membership could indicate any issues they think need face to face discussi= on time in Berlin. > > Or is everything going perfectly? > > Apart from what is listed below, is anything else missing from the docume= nt? > > Regards > > Keith > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:= insipid-bounces@ietf.org] On Behalf >> Of Paul E. Jones >> Sent: 09 July 2013 00:17 >> To: insipid@ietf.org >> Subject: [Insipid] draft-ietf-insipid-session-id-01 >> >> Folks, >> >> I posted a new version of draft-ietf-insipid-session-id for your >> consideration. >> >> One significant addition is one to address a comment Laura had about >> ensuring that intermediary devices can consistently re-create a UUID and >> remain stateless. New text is introduced in Section 4.1 that describes >> how >> such entities can construct the UUIDs. >> >> Section 6 was also revised with text to explain that the UUID order >> relates >> to who sends the message. It also discusses the longevity of the UUID, >> logging, and changes to the "remote" UUID. >> >> Previously, requests were made for additional call flows. Those were no= t >> added to the document, but the requests are listed as TODO items in >> section(s) under section 9. There is also a TODO for section 9 related = to >> requested changes to section 9 to make it cleared the text is just >> examples. >> >> Paul >> >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D183BA5F5CAHE111648emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Full support of Laura’s statement.

 

BR

 

Roland

 

Von: insipid-bo= unces@ietf.org [mailto:insipid-bounces@ietf.org] Im Auftrag von Laur= a Liess
Gesendet: Dienstag, 30. Juli 2013 13:19
An: Had= riel Kaplan
Cc: DRAGE, Keith (Keith); insipid@ietf.org
Betr= eff: Re: [Insipid] draft-ietf-insipid-session-id-01

 

I agree with Hadriel.  If I remember correc= tly, we had an agreement in the WG that the identifier defined here has to = be backward compatible with the session-id identifier defined in Hadriel's = draft and that a reference to this draft has to be added.

Backward = incompatibility with Hadriel's session-id would be a big drawback for the i= mplementation of the new identifier within carrier networks. Carriers as my= employer, where Hadriel's session-id is already implemented, will never sw= itch to the new identifier. They will require the old identifier for any ne= w systems they buy, including conferencing systems.

Because Hadriel= 's session-id is used in the 3GPP IMS specificatios, I assume that the situ= ation is the same for other carriers using IMS.

Thank you
Laura =    


2013/7/2= 9 Hadriel Kaplan <hadriel.kaplan@oracle.com>


I think there needs some discussion and justification for why the se= ss-id value order/placement is swapped in SIP responses and upstream reques= ts, instead of being kept the same order throughout.  This order-chang= ing breaks backward compatibility with the older Session-ID individual draf= t, and is arguably harder to use/find in logs and wireshark for troubleshoo= ting purposes.  I think someone mentioned some reason this re-ordering= was necessary, but I can't recall what it is and I don't see it explained = in the draft.

-ha= driel



On= Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>= ; wrote:

> (As WG cochair)
>
> As well as reviewing t= he document generally, it would be useful if the WG membership could indica= te any issues they think need face to face discussion time in Berlin.
&g= t;
> Or is everything going perfectly?
>
> Apart from wha= t is listed below, is anything else missing from the document?
>
&= gt; Regards
>
> Keith
>
>> -----Original Message= -----
>> From: insipid= -bounces@ietf.org [mailto:i= nsipid-bounces@ietf.org] On Behalf
>> Of Paul E. Jones
>= > Sent: 09 July 2013 00:17
>> To: insipid@ietf.org
>> Subject: [Insipid] draft-ietf-insip= id-session-id-01
>>
>> Folks,
>>
>> I p= osted a new version of draft-ietf-insipid-session-id for your
>> c= onsideration.
>>
>> One significant addition is one to ad= dress a comment Laura had about
>> ensuring that intermediary devi= ces can consistently re-create a UUID and
>> remain stateless. &nb= sp;New text is introduced in Section 4.1 that describes
>> how
= >> such entities can construct the UUIDs.
>>
>> Sec= tion 6 was also revised with text to explain that the UUID order
>>= ; relates
>> to who sends the message.  It also discusses the= longevity of the UUID,
>> logging, and changes to the "remot= e" UUID.
>>
>> Previously, requests were made for ad= ditional call flows.  Those were not
>> added to the document= ,  but the requests are listed as TODO items in
>> section(s)= under section 9.  There is also a TODO for section 9 related to
&g= t;> requested changes to section 9 to make it cleared the text is just>> examples.
>>
>> Paul
>>
>>>> _______________________________________________
>> insi= pid mailing list
>> insipid@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/insipid> _______________________________________________
> insipid mail= ing list
> insipid@ietf.org> https://www.ietf.org/mailman/listinfo/insipid

__________= _____________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mai= lman/listinfo/insipid

 

= --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D183BA5F5CAHE111648emea1_-- From prvs=89238312aa=aallen@blackberry.com Tue Jul 30 07:29:01 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FE421E8118 for ; Tue, 30 Jul 2013 07:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO12QS-QYJ0A for ; Tue, 30 Jul 2013 07:28:56 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 366ED21E8103 for ; Tue, 30 Jul 2013 07:28:17 -0700 (PDT) X-AuditID: 0a412830-b7fa06d000003f99-b6-51f7cd74e287 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 16.75.16281.47DC7F15; Tue, 30 Jul 2013 09:28:04 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 09:28:03 -0500 From: Andrew Allen To: "laura.liess.dt@googlemail.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-01 Thread-Index: AQHOjTD/qDE6qvPOB0SmbQD1X8AOIg== Date: Tue, 30 Jul 2013 14:28:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338DED5BDXMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDKsWRmVeSWpSXmKPExsXC5Zyvq1ty9nugwazD8hafNn1itph//xmT xdPGs4wWc64YOrB4tD7by+rxdMJkdo8lS34yeXx8eoslgCWqgdEmKbGkLDgzPU/fziYxLy+/ JLEkVSEltTjZVsknNT0xRyGgKLMsMblSwSWzODknMTM3tUhJITPFVslESaEgJzE5NTc1r8RW KbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2ekmdPJk3P6zl7HgTl5F U8ta5gbGO9ldjJwcEgImEnsvfGWFsMUkLtxbz9bFyMUhJNDGJHF84z8oZzOjRN//g2BVbAJa EvsPT2cCsUUE6iR+nFgLFmcWyJNYu/IBmC0sYC6x798zNogaC4nVdz8xdzFyANl6Ep/vGYGE WQRUJR4eWARWzivgITFz63YWEJtTIFDiasdVsPGMQAd9P7WGCWK8uMStJ/OZIA4VkFiy5zwz hC0q8fLxP6gHFCVm7JkPdU6+xN0Fl9kh5gtKnJz5hGUCo8gsJKNmISmbhaRsFtClzAKaEut3 6UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2BuRrGBmWFyXrJeUWauXl5qySZGUIpx1DDYwfj+ vcUhRgEORiUe3m27vwcKsSaWFVfmHmKU4GBWEuE9PxEoxJuSWFmVWpQfX1Sak1p8iDEIGEAT maW4k/OB6S+vJN7YwIBIjpI4r6vKh0AhgXRgEstOTS1ILYIZysTBCbKUS0qkGJiKUosSS0sy 4kEJM74YmDKlGhitvIJfrXDv6nWV3VYd6+Od+Lp7v5dVTZSCy7l/7dcvcwtJX7s0p7qfW8Bp Lc8c+Rklz46ndB72XcNqHtNdEu/a2dBqx+302FxCw0B3U57x0md7My1SQjxmn/9e1Bb09Z1e qbVa7vm9zNEnORf6LrKMbjzPfWH6n59W5lb84vfnT6m50j9xlxJLcUaioRZzUXEiAN4Tf3B/ AwAA Cc: "keith.drage@alcatel-lucent.com" , "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:29:01 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338DED5BDXMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 DQpJIGFsc28gY29uY3VyIHdpdGggTGF1cmEncyByZWNvbGxlY3Rpb24uIFRoYXQgYWdyZWVt ZW50IHdhcyB0aGUgYmFzaXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlIEpvbmVzIGRyYWZ0 IGFzIHRoZSBXRyBkcmFmdC4NCg0KQW5kcmV3DQoNCkZyb206IExhdXJhIExpZXNzIFttYWls dG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDMwLCAyMDEzIDA2OjE4IEFNIENlbnRyYWwgU3RhbmRhcmQgVGltZQ0KVG86IEhhZHJpZWwg S2FwbGFuIDxoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPg0KQ2M6IERSQUdFLCBLZWl0aCAo S2VpdGgpIDxrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+OyBpbnNpcGlkQGlldGYu b3JnIDxpbnNpcGlkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJbnNpcGlkXSBkcmFmdC1p ZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC0wMQ0KDQpJIGFncmVlIHdpdGggSGFkcmllbC4gIElm IEkgcmVtZW1iZXIgY29ycmVjdGx5LCB3ZSBoYWQgYW4gYWdyZWVtZW50IGluIHRoZSBXRyB0 aGF0IHRoZSBpZGVudGlmaWVyIGRlZmluZWQgaGVyZSBoYXMgdG8gYmUgYmFja3dhcmQgY29t cGF0aWJsZSB3aXRoIHRoZSBzZXNzaW9uLWlkIGlkZW50aWZpZXIgZGVmaW5lZCBpbiBIYWRy aWVsJ3MgZHJhZnQgYW5kIHRoYXQgYSByZWZlcmVuY2UgdG8gdGhpcyBkcmFmdCBoYXMgdG8g YmUgYWRkZWQuDQoNCkJhY2t3YXJkIGluY29tcGF0aWJpbGl0eSB3aXRoIEhhZHJpZWwncyBz ZXNzaW9uLWlkIHdvdWxkIGJlIGEgYmlnIGRyYXdiYWNrIGZvciB0aGUgaW1wbGVtZW50YXRp b24gb2YgdGhlIG5ldyBpZGVudGlmaWVyIHdpdGhpbiBjYXJyaWVyIG5ldHdvcmtzLiBDYXJy aWVycyBhcyBteSBlbXBsb3llciwgd2hlcmUgSGFkcmllbCdzIHNlc3Npb24taWQgaXMgYWxy ZWFkeSBpbXBsZW1lbnRlZCwgd2lsbCBuZXZlciBzd2l0Y2ggdG8gdGhlIG5ldyBpZGVudGlm aWVyLiBUaGV5IHdpbGwgcmVxdWlyZSB0aGUgb2xkIGlkZW50aWZpZXIgZm9yIGFueSBuZXcg c3lzdGVtcyB0aGV5IGJ1eSwgaW5jbHVkaW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLg0KDQpC ZWNhdXNlIEhhZHJpZWwncyBzZXNzaW9uLWlkIGlzIHVzZWQgaW4gdGhlIDNHUFAgSU1TIHNw ZWNpZmljYXRpb3MsIEkgYXNzdW1lIHRoYXQgdGhlIHNpdHVhdGlvbiBpcyB0aGUgc2FtZSBm b3Igb3RoZXIgY2FycmllcnMgdXNpbmcgSU1TLg0KDQpUaGFuayB5b3UNCkxhdXJhDQoNCg0K DQoyMDEzLzcvMjkgSGFkcmllbCBLYXBsYW4gPGhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb208 bWFpbHRvOmhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20+Pg0KDQpJIHRoaW5rIHRoZXJlIG5l ZWRzIHNvbWUgZGlzY3Vzc2lvbiBhbmQganVzdGlmaWNhdGlvbiBmb3Igd2h5IHRoZSBzZXNz LWlkIHZhbHVlIG9yZGVyL3BsYWNlbWVudCBpcyBzd2FwcGVkIGluIFNJUCByZXNwb25zZXMg YW5kIHVwc3RyZWFtIHJlcXVlc3RzLCBpbnN0ZWFkIG9mIGJlaW5nIGtlcHQgdGhlIHNhbWUg b3JkZXIgdGhyb3VnaG91dC4gIFRoaXMgb3JkZXItY2hhbmdpbmcgYnJlYWtzIGJhY2t3YXJk IGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgb2xkZXIgU2Vzc2lvbi1JRCBpbmRpdmlkdWFsIGRy YWZ0LCBhbmQgaXMgYXJndWFibHkgaGFyZGVyIHRvIHVzZS9maW5kIGluIGxvZ3MgYW5kIHdp cmVzaGFyayBmb3IgdHJvdWJsZXNob290aW5nIHB1cnBvc2VzLiAgSSB0aGluayBzb21lb25l IG1lbnRpb25lZCBzb21lIHJlYXNvbiB0aGlzIHJlLW9yZGVyaW5nIHdhcyBuZWNlc3Nhcnks IGJ1dCBJIGNhbid0IHJlY2FsbCB3aGF0IGl0IGlzIGFuZCBJIGRvbid0IHNlZSBpdCBleHBs YWluZWQgaW4gdGhlIGRyYWZ0Lg0KDQotaGFkcmllbA0KDQoNCk9uIEp1bCA4LCAyMDEzLCBh dCA4OjQxIFBNLCAiRFJBR0UsIEtlaXRoIChLZWl0aCkiIDxrZWl0aC5kcmFnZUBhbGNhdGVs LWx1Y2VudC5jb208bWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdy b3RlOg0KDQo+IChBcyBXRyBjb2NoYWlyKQ0KPg0KPiBBcyB3ZWxsIGFzIHJldmlld2luZyB0 aGUgZG9jdW1lbnQgZ2VuZXJhbGx5LCBpdCB3b3VsZCBiZSB1c2VmdWwgaWYgdGhlIFdHIG1l bWJlcnNoaXAgY291bGQgaW5kaWNhdGUgYW55IGlzc3VlcyB0aGV5IHRoaW5rIG5lZWQgZmFj ZSB0byBmYWNlIGRpc2N1c3Npb24gdGltZSBpbiBCZXJsaW4uDQo+DQo+IE9yIGlzIGV2ZXJ5 dGhpbmcgZ29pbmcgcGVyZmVjdGx5Pw0KPg0KPiBBcGFydCBmcm9tIHdoYXQgaXMgbGlzdGVk IGJlbG93LCBpcyBhbnl0aGluZyBlbHNlIG1pc3NpbmcgZnJvbSB0aGUgZG9jdW1lbnQ/DQo+ DQo+IFJlZ2FyZHMNCj4NCj4gS2VpdGgNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBpbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmluc2lwaWQt Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZg0KPj4gT2YgUGF1bCBF LiBKb25lcw0KPj4gU2VudDogMDkgSnVseSAyMDEzIDAwOjE3DQo+PiBUbzogaW5zaXBpZEBp ZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFtJbnNpcGlk XSBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC0wMQ0KPj4NCj4+IEZvbGtzLA0KPj4N Cj4+IEkgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1pbnNpcGlkLXNlc3Np b24taWQgZm9yIHlvdXINCj4+IGNvbnNpZGVyYXRpb24uDQo+Pg0KPj4gT25lIHNpZ25pZmlj YW50IGFkZGl0aW9uIGlzIG9uZSB0byBhZGRyZXNzIGEgY29tbWVudCBMYXVyYSBoYWQgYWJv dXQNCj4+IGVuc3VyaW5nIHRoYXQgaW50ZXJtZWRpYXJ5IGRldmljZXMgY2FuIGNvbnNpc3Rl bnRseSByZS1jcmVhdGUgYSBVVUlEIGFuZA0KPj4gcmVtYWluIHN0YXRlbGVzcy4gIE5ldyB0 ZXh0IGlzIGludHJvZHVjZWQgaW4gU2VjdGlvbiA0LjEgdGhhdCBkZXNjcmliZXMNCj4+IGhv dw0KPj4gc3VjaCBlbnRpdGllcyBjYW4gY29uc3RydWN0IHRoZSBVVUlEcy4NCj4+DQo+PiBT ZWN0aW9uIDYgd2FzIGFsc28gcmV2aXNlZCB3aXRoIHRleHQgdG8gZXhwbGFpbiB0aGF0IHRo ZSBVVUlEIG9yZGVyDQo+PiByZWxhdGVzDQo+PiB0byB3aG8gc2VuZHMgdGhlIG1lc3NhZ2Uu ICBJdCBhbHNvIGRpc2N1c3NlcyB0aGUgbG9uZ2V2aXR5IG9mIHRoZSBVVUlELA0KPj4gbG9n Z2luZywgYW5kIGNoYW5nZXMgdG8gdGhlICJyZW1vdGUiIFVVSUQuDQo+Pg0KPj4gUHJldmlv dXNseSwgcmVxdWVzdHMgd2VyZSBtYWRlIGZvciBhZGRpdGlvbmFsIGNhbGwgZmxvd3MuICBU aG9zZSB3ZXJlIG5vdA0KPj4gYWRkZWQgdG8gdGhlIGRvY3VtZW50LCAgYnV0IHRoZSByZXF1 ZXN0cyBhcmUgbGlzdGVkIGFzIFRPRE8gaXRlbXMgaW4NCj4+IHNlY3Rpb24ocykgdW5kZXIg c2VjdGlvbiA5LiAgVGhlcmUgaXMgYWxzbyBhIFRPRE8gZm9yIHNlY3Rpb24gOSByZWxhdGVk IHRvDQo+PiByZXF1ZXN0ZWQgY2hhbmdlcyB0byBzZWN0aW9uIDkgdG8gbWFrZSBpdCBjbGVh cmVkIHRoZSB0ZXh0IGlzIGp1c3QNCj4+IGV4YW1wbGVzLg0KPj4NCj4+IFBhdWwNCj4+DQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IGluc2lwaWQgbWFpbGluZyBsaXN0DQo+PiBpbnNpcGlkQGlldGYub3JnPG1haWx0bzpp bnNpcGlkQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pbnNpcGlkDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IGluc2lwaWQgbWFpbGluZyBsaXN0DQo+IGluc2lwaWRAaWV0Zi5vcmc8 bWFpbHRvOmluc2lwaWRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaW5zaXBpZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KaW5zaXBpZCBtYWlsaW5nIGxpc3QNCmluc2lwaWRAaWV0Zi5v cmc8bWFpbHRvOmluc2lwaWRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2luc2lwaWQNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNt aXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRl cmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGlj YWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9u LiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhl IGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5 IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBz eXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rp b24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5v dCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= --_000_BBF5DDFE515C3946BC18D733B20DAD2338DED5BDXMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCkkgYWxzbyBj b25jdXIgd2l0aCBMYXVyYSdzIHJlY29sbGVjdGlvbi4gVGhhdCBhZ3JlZW1lbnQgd2FzIHRo ZSBiYXNpcyB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgSm9uZXMgZHJhZnQgYXMgdGhlIFdH IGRyYWZ0Ljxicj4NCjxicj4NCkFuZHJldzwvZm9udD48YnI+DQombmJzcDs8YnI+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PGI+RnJvbTwvYj46IExhdXJhIExpZXNzIFttYWlsdG86bGF1cmEubGllc3MuZHRAZ29v Z2xlbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjogVHVlc2RheSwgSnVseSAzMCwgMjAx MyAwNjoxOCBBTSBDZW50cmFsIFN0YW5kYXJkIFRpbWU8YnI+DQo8Yj5UbzwvYj46IEhhZHJp ZWwgS2FwbGFuICZsdDtoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tJmd0OyA8YnI+DQo8Yj5D YzwvYj46IERSQUdFLCBLZWl0aCAoS2VpdGgpICZsdDtrZWl0aC5kcmFnZUBhbGNhdGVsLWx1 Y2VudC5jb20mZ3Q7OyBpbnNpcGlkQGlldGYub3JnICZsdDtpbnNpcGlkQGlldGYub3JnJmd0 Ow0KPGJyPg0KPGI+U3ViamVjdDwvYj46IFJlOiBbSW5zaXBpZF0gZHJhZnQtaWV0Zi1pbnNp cGlkLXNlc3Npb24taWQtMDEgPGJyPg0KPC9mb250PiZuYnNwOzxicj4NCjwvZGl2Pg0KSSBh Z3JlZSB3aXRoIEhhZHJpZWwuJm5ic3A7IElmIEkgcmVtZW1iZXIgY29ycmVjdGx5LCB3ZSBo YWQgYW4gYWdyZWVtZW50IGluIHRoZSBXRyB0aGF0IHRoZSBpZGVudGlmaWVyIGRlZmluZWQg aGVyZSBoYXMgdG8gYmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIHRoZSBzZXNzaW9uLWlk IGlkZW50aWZpZXIgZGVmaW5lZCBpbiBIYWRyaWVsJ3MgZHJhZnQgYW5kIHRoYXQgYSByZWZl cmVuY2UgdG8gdGhpcyBkcmFmdCBoYXMgdG8gYmUgYWRkZWQuDQo8YnI+DQo8YnI+DQpCYWNr d2FyZCBpbmNvbXBhdGliaWxpdHkgd2l0aCBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCB3b3VsZCBi ZSBhIGJpZyBkcmF3YmFjayBmb3IgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBuZXcgaWRl bnRpZmllciB3aXRoaW4gY2FycmllciBuZXR3b3Jrcy4gQ2FycmllcnMgYXMgbXkgZW1wbG95 ZXIsIHdoZXJlIEhhZHJpZWwncyBzZXNzaW9uLWlkIGlzIGFscmVhZHkgaW1wbGVtZW50ZWQs IHdpbGwgbmV2ZXIgc3dpdGNoIHRvIHRoZSBuZXcgaWRlbnRpZmllci4NCiBUaGV5IHdpbGwg cmVxdWlyZSB0aGUgb2xkIGlkZW50aWZpZXIgZm9yIGFueSBuZXcgc3lzdGVtcyB0aGV5IGJ1 eSwgaW5jbHVkaW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLg0KPGJyPg0KPGJyPg0KQmVjYXVz ZSBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCBpcyB1c2VkIGluIHRoZSAzR1BQIElNUyBzcGVjaWZp Y2F0aW9zLCBJIGFzc3VtZSB0aGF0IHRoZSBzaXR1YXRpb24gaXMgdGhlIHNhbWUgZm9yIG90 aGVyIGNhcnJpZXJzIHVzaW5nIElNUy4NCjxicj4NCjxicj4NClRoYW5rIHlvdTxicj4NCkxh dXJhICZuYnNwOyAmbmJzcDsgPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPjIwMTMvNy8yOSBIYWRyaWVsIEthcGxhbiA8c3BhbiBkaXI9Imx0ciI+ Jmx0OzxhIGhyZWY9Im1haWx0bzpoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbTwvYT4mZ3Q7PC9zcGFuPjxicj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJy Pg0KSSB0aGluayB0aGVyZSBuZWVkcyBzb21lIGRpc2N1c3Npb24gYW5kIGp1c3RpZmljYXRp b24gZm9yIHdoeSB0aGUgc2Vzcy1pZCB2YWx1ZSBvcmRlci9wbGFjZW1lbnQgaXMgc3dhcHBl ZCBpbiBTSVAgcmVzcG9uc2VzIGFuZCB1cHN0cmVhbSByZXF1ZXN0cywgaW5zdGVhZCBvZiBi ZWluZyBrZXB0IHRoZSBzYW1lIG9yZGVyIHRocm91Z2hvdXQuICZuYnNwO1RoaXMgb3JkZXIt Y2hhbmdpbmcgYnJlYWtzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgb2xkZXIN CiBTZXNzaW9uLUlEIGluZGl2aWR1YWwgZHJhZnQsIGFuZCBpcyBhcmd1YWJseSBoYXJkZXIg dG8gdXNlL2ZpbmQgaW4gbG9ncyBhbmQgd2lyZXNoYXJrIGZvciB0cm91Ymxlc2hvb3Rpbmcg cHVycG9zZXMuICZuYnNwO0kgdGhpbmsgc29tZW9uZSBtZW50aW9uZWQgc29tZSByZWFzb24g dGhpcyByZS1vcmRlcmluZyB3YXMgbmVjZXNzYXJ5LCBidXQgSSBjYW4ndCByZWNhbGwgd2hh dCBpdCBpcyBhbmQgSSBkb24ndCBzZWUgaXQgZXhwbGFpbmVkIGluIHRoZSBkcmFmdC48YnI+ DQo8c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KLWhh ZHJpZWw8YnI+DQo8L2ZvbnQ+PC9zcGFuPg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxkaXYg Y2xhc3M9Img1Ij48YnI+DQo8YnI+DQpPbiBKdWwgOCwgMjAxMywgYXQgODo0MSBQTSwgJnF1 b3Q7RFJBR0UsIEtlaXRoIChLZWl0aCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzprZWl0 aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20iPmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgKEFzIFdHIGNvY2hhaXIpPGJy Pg0KJmd0Ozxicj4NCiZndDsgQXMgd2VsbCBhcyByZXZpZXdpbmcgdGhlIGRvY3VtZW50IGdl bmVyYWxseSwgaXQgd291bGQgYmUgdXNlZnVsIGlmIHRoZSBXRyBtZW1iZXJzaGlwIGNvdWxk IGluZGljYXRlIGFueSBpc3N1ZXMgdGhleSB0aGluayBuZWVkIGZhY2UgdG8gZmFjZSBkaXNj dXNzaW9uIHRpbWUgaW4gQmVybGluLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9yIGlzIGV2ZXJ5 dGhpbmcgZ29pbmcgcGVyZmVjdGx5Pzxicj4NCiZndDs8YnI+DQomZ3Q7IEFwYXJ0IGZyb20g d2hhdCBpcyBsaXN0ZWQgYmVsb3csIGlzIGFueXRoaW5nIGVsc2UgbWlzc2luZyBmcm9tIHRo ZSBkb2N1bWVudD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRzPGJyPg0KJmd0Ozxicj4N CiZndDsgS2VpdGg8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86aW5zaXBpZC1i b3VuY2VzQGlldGYub3JnIj5pbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZyI+aW5zaXBpZC1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmPGJyPg0KJmd0OyZndDsgT2YgUGF1bCBFLiBK b25lczxicj4NCiZndDsmZ3Q7IFNlbnQ6IDA5IEp1bHkgMjAxMyAwMDoxNzxicj4NCiZndDsm Z3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBbSW5zaXBpZF0gZHJhZnQtaWV0Zi1p bnNpcGlkLXNlc3Npb24taWQtMDE8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZvbGtz LDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBv ZiBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZCBmb3IgeW91cjxicj4NCiZndDsmZ3Q7 IGNvbnNpZGVyYXRpb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbmUgc2lnbmlm aWNhbnQgYWRkaXRpb24gaXMgb25lIHRvIGFkZHJlc3MgYSBjb21tZW50IExhdXJhIGhhZCBh Ym91dDxicj4NCiZndDsmZ3Q7IGVuc3VyaW5nIHRoYXQgaW50ZXJtZWRpYXJ5IGRldmljZXMg Y2FuIGNvbnNpc3RlbnRseSByZS1jcmVhdGUgYSBVVUlEIGFuZDxicj4NCiZndDsmZ3Q7IHJl bWFpbiBzdGF0ZWxlc3MuICZuYnNwO05ldyB0ZXh0IGlzIGludHJvZHVjZWQgaW4gU2VjdGlv biA0LjEgdGhhdCBkZXNjcmliZXM8YnI+DQomZ3Q7Jmd0OyBob3c8YnI+DQomZ3Q7Jmd0OyBz dWNoIGVudGl0aWVzIGNhbiBjb25zdHJ1Y3QgdGhlIFVVSURzLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgU2VjdGlvbiA2IHdhcyBhbHNvIHJldmlzZWQgd2l0aCB0ZXh0IHRvIGV4 cGxhaW4gdGhhdCB0aGUgVVVJRCBvcmRlcjxicj4NCiZndDsmZ3Q7IHJlbGF0ZXM8YnI+DQom Z3Q7Jmd0OyB0byB3aG8gc2VuZHMgdGhlIG1lc3NhZ2UuICZuYnNwO0l0IGFsc28gZGlzY3Vz c2VzIHRoZSBsb25nZXZpdHkgb2YgdGhlIFVVSUQsPGJyPg0KJmd0OyZndDsgbG9nZ2luZywg YW5kIGNoYW5nZXMgdG8gdGhlICZxdW90O3JlbW90ZSZxdW90OyBVVUlELjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgUHJldmlvdXNseSwgcmVxdWVzdHMgd2VyZSBtYWRlIGZvciBh ZGRpdGlvbmFsIGNhbGwgZmxvd3MuICZuYnNwO1Rob3NlIHdlcmUgbm90PGJyPg0KJmd0OyZn dDsgYWRkZWQgdG8gdGhlIGRvY3VtZW50LCAmbmJzcDtidXQgdGhlIHJlcXVlc3RzIGFyZSBs aXN0ZWQgYXMgVE9ETyBpdGVtcyBpbjxicj4NCiZndDsmZ3Q7IHNlY3Rpb24ocykgdW5kZXIg c2VjdGlvbiA5LiAmbmJzcDtUaGVyZSBpcyBhbHNvIGEgVE9ETyBmb3Igc2VjdGlvbiA5IHJl bGF0ZWQgdG88YnI+DQomZ3Q7Jmd0OyByZXF1ZXN0ZWQgY2hhbmdlcyB0byBzZWN0aW9uIDkg dG8gbWFrZSBpdCBjbGVhcmVkIHRoZSB0ZXh0IGlzIGp1c3Q8YnI+DQomZ3Q7Jmd0OyBleGFt cGxlcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFBhdWw8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBpbnNpcGlkIG1haWxpbmcgbGlz dDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzppbnNpcGlkQGlldGYub3JnIj5pbnNp cGlkQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZDwvYT48YnI+DQomZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyBpbnNpcGlkIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmlu c2lwaWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lw aWQ8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQppbnNpcGlkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzppbnNpcGlkQGlldGYub3JnIj5pbnNpcGlkQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5z aXBpZDwvYT48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGlu ZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBi eSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMp LCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5z bWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338DED5BDXMB104ADSrimnet_-- From atle.monrad@ericsson.com Tue Jul 30 07:36:34 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9403621E80EA for ; Tue, 30 Jul 2013 07:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOIlEY25VIHR for ; Tue, 30 Jul 2013 07:36:21 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2482621E80F5 for ; Tue, 30 Jul 2013 07:36:06 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-0c-51f7cf5565fa Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 33.39.05990.55FC7F15; Tue, 30 Jul 2013 16:36:05 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.48]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Tue, 30 Jul 2013 16:36:05 +0200 From: Atle Monrad To: Andrew Allen , "laura.liess.dt@googlemail.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-01 Thread-Index: AQHOjTD/qDE6qvPOB0SmbQD1X8AOIpl9SLtA Date: Tue, 30 Jul 2013 14:36:04 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C14F175@ESESSMB203.ericsson.se> References: In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7D2F7D7ADBA812449F25F4A69922881C14F175ESESSMB203ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Vjf0/PdAg4MzFC3uz9vKaPFp0ydm i/n3nzFZPG08y2gx54qhA6tH67O9rB6zGtayezydMJndY8mSn0weH5/eYglgjeKySUnNySxL LdK3S+DKeP95G1tB2x7Gip3N/1kbGDu2M3YxcnJICJhI/Lk3iQnCFpO4cG89WxcjF4eQwGFG iVU7vrJCOIsZJU7cOQTWwSagI3Hu5x2whIjAMkaJ7ual7CAJZoE8ibUrHwAlODiEBcwl1r4u BwmLCFhIrL77iRnCNpK4tmQiWDmLgKrE95/PwWxeAW+JjrvTmSGW9TNK3Jh8ixFkDqeAp8SH I4EgJqOArMTcJl6ITeISt57MhzpaQGLJnvPMELaoxMvH/1ghbCWJxiVPWCHq8yWWdP5jgVgl KHFy5hOWCYyis5CMmoWkbBaSsllAm5kFNCXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7Kkb2 3MTMnPRyo02MwHg8uOW36g7GO+dEDjFKc7AoifNu1jsTKCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFx9iKPe4tnfky7+SF+SrFdc/eK/4s3Jl43WvJ7pdCJiFjZK83vFZ8cO7D7mdGESZwf 3joEysyoDD0uwsV/I7WARdZC6GJvrgCfkwBfzqvcC5tUw/ouzt788cKiziLpv8yGbd11Z2xn 5Hleu5PdFSIqv5ef+cSk81V2aUe1Ja9eu8Zz46i3R4K1EktxRqKhFnNRcSIAgrTCk5UCAAA= Cc: "keith.drage@alcatel-lucent.com" , "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:36:37 -0000 --_000_7D2F7D7ADBA812449F25F4A69922881C14F175ESESSMB203ericsso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSeKAmWQgbGlrZSB0byB0ZWFtIHVwIHdpdGggSGFkcmllbCwgTGF1cmEsIFJvbGFuZCBh bmQgQW5kcmV3IG9uIHRoZSBzdXBwb3J0IGZvciBub3QgYnJlYWtpbmcgdGhlIEJXIGNvbXBhdGli aWxpdHkuDQoNCnRoYW5rcw0KL2F0bGUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KDQpBdGxlIE1vbnJhZA0KM0dQUCBDVCBDaGFpcm1hbg0KDQpHcm91cCBGdW5jdGlvbiBU ZWNobm9sb2d5IOKAkyBTdGFuZGFyZGl6YXRpb24gYW5kIFRlY2huaWNhbCBSZWd1bGF0aW9uDQpF cmljc3Nvbg0KDQoNCkZyb206IGluc2lwaWQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmluc2lw aWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyBBbGxlbg0KU2VudDogMzAu IGp1bGkgMjAxMyAxNjoyOA0KVG86IGxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tOyBoYWRy aWVsLmthcGxhbkBvcmFjbGUuY29tDQpDYzoga2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29t OyBpbnNpcGlkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0luc2lwaWRdIGRyYWZ0LWlldGYtaW5z aXBpZC1zZXNzaW9uLWlkLTAxDQoNCg0KSSBhbHNvIGNvbmN1ciB3aXRoIExhdXJhJ3MgcmVjb2xs ZWN0aW9uLiBUaGF0IGFncmVlbWVudCB3YXMgdGhlIGJhc2lzIHRvIG1vdmUgZm9yd2FyZCB3aXRo IHRoZSBKb25lcyBkcmFmdCBhcyB0aGUgV0cgZHJhZnQuDQoNCkFuZHJldw0KDQpGcm9tOiBMYXVy YSBMaWVzcyBbbWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tXQ0KU2VudDogVHVl c2RheSwgSnVseSAzMCwgMjAxMyAwNjoxOCBBTSBDZW50cmFsIFN0YW5kYXJkIFRpbWUNClRvOiBI YWRyaWVsIEthcGxhbiA8aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbTxtYWlsdG86aGFkcmllbC5r YXBsYW5Ab3JhY2xlLmNvbT4+DQpDYzogRFJBR0UsIEtlaXRoIChLZWl0aCkgPGtlaXRoLmRyYWdl QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29t Pj47IGluc2lwaWRAaWV0Zi5vcmc8bWFpbHRvOmluc2lwaWRAaWV0Zi5vcmc+IDxpbnNpcGlkQGll dGYub3JnPG1haWx0bzppbnNpcGlkQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSW5zaXBpZF0g ZHJhZnQtaWV0Zi1pbnNpcGlkLXNlc3Npb24taWQtMDENCg0KSSBhZ3JlZSB3aXRoIEhhZHJpZWwu ICBJZiBJIHJlbWVtYmVyIGNvcnJlY3RseSwgd2UgaGFkIGFuIGFncmVlbWVudCBpbiB0aGUgV0cg dGhhdCB0aGUgaWRlbnRpZmllciBkZWZpbmVkIGhlcmUgaGFzIHRvIGJlIGJhY2t3YXJkIGNvbXBh dGlibGUgd2l0aCB0aGUgc2Vzc2lvbi1pZCBpZGVudGlmaWVyIGRlZmluZWQgaW4gSGFkcmllbCdz IGRyYWZ0IGFuZCB0aGF0IGEgcmVmZXJlbmNlIHRvIHRoaXMgZHJhZnQgaGFzIHRvIGJlIGFkZGVk Lg0KDQpCYWNrd2FyZCBpbmNvbXBhdGliaWxpdHkgd2l0aCBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCB3 b3VsZCBiZSBhIGJpZyBkcmF3YmFjayBmb3IgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBuZXcg aWRlbnRpZmllciB3aXRoaW4gY2FycmllciBuZXR3b3Jrcy4gQ2FycmllcnMgYXMgbXkgZW1wbG95 ZXIsIHdoZXJlIEhhZHJpZWwncyBzZXNzaW9uLWlkIGlzIGFscmVhZHkgaW1wbGVtZW50ZWQsIHdp bGwgbmV2ZXIgc3dpdGNoIHRvIHRoZSBuZXcgaWRlbnRpZmllci4gVGhleSB3aWxsIHJlcXVpcmUg dGhlIG9sZCBpZGVudGlmaWVyIGZvciBhbnkgbmV3IHN5c3RlbXMgdGhleSBidXksIGluY2x1ZGlu ZyBjb25mZXJlbmNpbmcgc3lzdGVtcy4NCg0KQmVjYXVzZSBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCBp cyB1c2VkIGluIHRoZSAzR1BQIElNUyBzcGVjaWZpY2F0aW9zLCBJIGFzc3VtZSB0aGF0IHRoZSBz aXR1YXRpb24gaXMgdGhlIHNhbWUgZm9yIG90aGVyIGNhcnJpZXJzIHVzaW5nIElNUy4NCg0KVGhh bmsgeW91DQpMYXVyYQ0KDQoNCjIwMTMvNy8yOSBIYWRyaWVsIEthcGxhbiA8aGFkcmllbC5rYXBs YW5Ab3JhY2xlLmNvbTxtYWlsdG86aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbT4+DQoNCkkgdGhp bmsgdGhlcmUgbmVlZHMgc29tZSBkaXNjdXNzaW9uIGFuZCBqdXN0aWZpY2F0aW9uIGZvciB3aHkg dGhlIHNlc3MtaWQgdmFsdWUgb3JkZXIvcGxhY2VtZW50IGlzIHN3YXBwZWQgaW4gU0lQIHJlc3Bv bnNlcyBhbmQgdXBzdHJlYW0gcmVxdWVzdHMsIGluc3RlYWQgb2YgYmVpbmcga2VwdCB0aGUgc2Ft ZSBvcmRlciB0aHJvdWdob3V0LiAgVGhpcyBvcmRlci1jaGFuZ2luZyBicmVha3MgYmFja3dhcmQg Y29tcGF0aWJpbGl0eSB3aXRoIHRoZSBvbGRlciBTZXNzaW9uLUlEIGluZGl2aWR1YWwgZHJhZnQs IGFuZCBpcyBhcmd1YWJseSBoYXJkZXIgdG8gdXNlL2ZpbmQgaW4gbG9ncyBhbmQgd2lyZXNoYXJr IGZvciB0cm91Ymxlc2hvb3RpbmcgcHVycG9zZXMuICBJIHRoaW5rIHNvbWVvbmUgbWVudGlvbmVk IHNvbWUgcmVhc29uIHRoaXMgcmUtb3JkZXJpbmcgd2FzIG5lY2Vzc2FyeSwgYnV0IEkgY2FuJ3Qg cmVjYWxsIHdoYXQgaXQgaXMgYW5kIEkgZG9uJ3Qgc2VlIGl0IGV4cGxhaW5lZCBpbiB0aGUgZHJh ZnQuDQoNCi1oYWRyaWVsDQoNCg0KT24gSnVsIDgsIDIwMTMsIGF0IDg6NDEgUE0sICJEUkFHRSwg S2VpdGggKEtlaXRoKSIgPGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86a2Vp dGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPj4gd3JvdGU6DQoNCj4gKEFzIFdHIGNvY2hhaXIp DQo+DQo+IEFzIHdlbGwgYXMgcmV2aWV3aW5nIHRoZSBkb2N1bWVudCBnZW5lcmFsbHksIGl0IHdv dWxkIGJlIHVzZWZ1bCBpZiB0aGUgV0cgbWVtYmVyc2hpcCBjb3VsZCBpbmRpY2F0ZSBhbnkgaXNz dWVzIHRoZXkgdGhpbmsgbmVlZCBmYWNlIHRvIGZhY2UgZGlzY3Vzc2lvbiB0aW1lIGluIEJlcmxp bi4NCj4NCj4gT3IgaXMgZXZlcnl0aGluZyBnb2luZyBwZXJmZWN0bHk/DQo+DQo+IEFwYXJ0IGZy b20gd2hhdCBpcyBsaXN0ZWQgYmVsb3csIGlzIGFueXRoaW5nIGVsc2UgbWlzc2luZyBmcm9tIHRo ZSBkb2N1bWVudD8NCj4NCj4gUmVnYXJkcw0KPg0KPiBLZWl0aA0KPg0KPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGluc2lwaWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmDQo+PiBPZiBQYXVs IEUuIEpvbmVzDQo+PiBTZW50OiAwOSBKdWx5IDIwMTMgMDA6MTcNCj4+IFRvOiBpbnNpcGlkQGll dGYub3JnPG1haWx0bzppbnNpcGlkQGlldGYub3JnPg0KPj4gU3ViamVjdDogW0luc2lwaWRdIGRy YWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9uLWlkLTAxDQo+Pg0KPj4gRm9sa3MsDQo+Pg0KPj4gSSBw b3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZCBmb3Ig eW91cg0KPj4gY29uc2lkZXJhdGlvbi4NCj4+DQo+PiBPbmUgc2lnbmlmaWNhbnQgYWRkaXRpb24g aXMgb25lIHRvIGFkZHJlc3MgYSBjb21tZW50IExhdXJhIGhhZCBhYm91dA0KPj4gZW5zdXJpbmcg dGhhdCBpbnRlcm1lZGlhcnkgZGV2aWNlcyBjYW4gY29uc2lzdGVudGx5IHJlLWNyZWF0ZSBhIFVV SUQgYW5kDQo+PiByZW1haW4gc3RhdGVsZXNzLiAgTmV3IHRleHQgaXMgaW50cm9kdWNlZCBpbiBT ZWN0aW9uIDQuMSB0aGF0IGRlc2NyaWJlcw0KPj4gaG93DQo+PiBzdWNoIGVudGl0aWVzIGNhbiBj b25zdHJ1Y3QgdGhlIFVVSURzLg0KPj4NCj4+IFNlY3Rpb24gNiB3YXMgYWxzbyByZXZpc2VkIHdp dGggdGV4dCB0byBleHBsYWluIHRoYXQgdGhlIFVVSUQgb3JkZXINCj4+IHJlbGF0ZXMNCj4+IHRv IHdobyBzZW5kcyB0aGUgbWVzc2FnZS4gIEl0IGFsc28gZGlzY3Vzc2VzIHRoZSBsb25nZXZpdHkg b2YgdGhlIFVVSUQsDQo+PiBsb2dnaW5nLCBhbmQgY2hhbmdlcyB0byB0aGUgInJlbW90ZSIgVVVJ RC4NCj4+DQo+PiBQcmV2aW91c2x5LCByZXF1ZXN0cyB3ZXJlIG1hZGUgZm9yIGFkZGl0aW9uYWwg Y2FsbCBmbG93cy4gIFRob3NlIHdlcmUgbm90DQo+PiBhZGRlZCB0byB0aGUgZG9jdW1lbnQsICBi dXQgdGhlIHJlcXVlc3RzIGFyZSBsaXN0ZWQgYXMgVE9ETyBpdGVtcyBpbg0KPj4gc2VjdGlvbihz KSB1bmRlciBzZWN0aW9uIDkuICBUaGVyZSBpcyBhbHNvIGEgVE9ETyBmb3Igc2VjdGlvbiA5IHJl bGF0ZWQgdG8NCj4+IHJlcXVlc3RlZCBjaGFuZ2VzIHRvIHNlY3Rpb24gOSB0byBtYWtlIGl0IGNs ZWFyZWQgdGhlIHRleHQgaXMganVzdA0KPj4gZXhhbXBsZXMuDQo+Pg0KPj4gUGF1bA0KPj4NCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g aW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4+IGluc2lwaWRAaWV0Zi5vcmc8bWFpbHRvOmluc2lwaWRA aWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lw aWQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g aW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4gaW5zaXBpZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBp ZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlk DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppbnNp cGlkIG1haWxpbmcgbGlzdA0KaW5zaXBpZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZA0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwg KGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Ig b3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGlu Zm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRo YW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5 IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0 ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2Yg dGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3Jp emVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= --_000_7D2F7D7ADBA812449F25F4A69922881C14F175ESESSMB203ericsso_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZZCBsaWtl IHRvIHRlYW0gdXAgd2l0aCBIYWRyaWVsLCBMYXVyYSwgUm9sYW5kIGFuZCBBbmRyZXcgb24gdGhl IHN1cHBvcnQgZm9yIG5vdCBicmVha2luZyB0aGUgQlcgY29tcGF0aWJpbGl0eS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PnRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vYXRsZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8Yj5BdGxlIE1vbnJhZDwvYj48YnI+DQozR1BQIENUIENo YWlybWFuPGJyPg0KPGJyPg0KR3JvdXAgRnVuY3Rpb24gVGVjaG5vbG9neSDigJMgU3RhbmRhcmRp emF0aW9uIGFuZCBUZWNobmljYWwgUmVndWxhdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCkVyaWNzc29uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGluc2lwaWQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Omluc2lwaWQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmV3IEFs bGVuPGJyPg0KPGI+U2VudDo8L2I+IDMwLiBqdWxpIDIwMTMgMTY6Mjg8YnI+DQo8Yj5Ubzo8L2I+ IGxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tOyBoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29t PGJyPg0KPGI+Q2M6PC9iPiBrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb207IGluc2lwaWRA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJbnNpcGlkXSBkcmFmdC1pZXRmLWlu c2lwaWQtc2Vzc2lvbi1pZC0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+ DQpJIGFsc28gY29uY3VyIHdpdGggTGF1cmEncyByZWNvbGxlY3Rpb24uIFRoYXQgYWdyZWVtZW50 IHdhcyB0aGUgYmFzaXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlIEpvbmVzIGRyYWZ0IGFzIHRo ZSBXRyBkcmFmdC48YnI+DQo8YnI+DQpBbmRyZXc8L3NwYW4+PGJyPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjogTGF1cmEgTGllc3MgWzxhIGhyZWY9Im1haWx0bzpsYXVyYS5saWVz cy5kdEBnb29nbGVtYWlsLmNvbSI+bWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ8L2I+OiBUdWVzZGF5LCBKdWx5IDMwLCAyMDEzIDA2OjE4IEFN IENlbnRyYWwgU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvPC9iPjogSGFkcmllbCBLYXBsYW4gJmx0 OzxhIGhyZWY9Im1haWx0bzpoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tIj5oYWRyaWVsLmthcGxh bkBvcmFjbGUuY29tPC9hPiZndDsNCjxicj4NCjxiPkNjPC9iPjogRFJBR0UsIEtlaXRoIChLZWl0 aCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20iPmtl aXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmlu c2lwaWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86 aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8Yj5TdWJq ZWN0PC9iPjogUmU6IFtJbnNpcGlkXSBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC0wMSA8 YnI+DQo8L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBhZ3JlZSB3aXRoIEhhZHJpZWwu Jm5ic3A7IElmIEkgcmVtZW1iZXIgY29ycmVjdGx5LCB3ZSBoYWQgYW4gYWdyZWVtZW50IGluIHRo ZSBXRyB0aGF0IHRoZSBpZGVudGlmaWVyIGRlZmluZWQgaGVyZSBoYXMgdG8gYmUgYmFja3dhcmQg Y29tcGF0aWJsZSB3aXRoIHRoZSBzZXNzaW9uLWlkIGlkZW50aWZpZXIgZGVmaW5lZCBpbiBIYWRy aWVsJ3MgZHJhZnQgYW5kIHRoYXQNCiBhIHJlZmVyZW5jZSB0byB0aGlzIGRyYWZ0IGhhcyB0byBi ZSBhZGRlZC4gPGJyPg0KPGJyPg0KQmFja3dhcmQgaW5jb21wYXRpYmlsaXR5IHdpdGggSGFkcmll bCdzIHNlc3Npb24taWQgd291bGQgYmUgYSBiaWcgZHJhd2JhY2sgZm9yIHRoZSBpbXBsZW1lbnRh dGlvbiBvZiB0aGUgbmV3IGlkZW50aWZpZXIgd2l0aGluIGNhcnJpZXIgbmV0d29ya3MuIENhcnJp ZXJzIGFzIG15IGVtcGxveWVyLCB3aGVyZSBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCBpcyBhbHJlYWR5 IGltcGxlbWVudGVkLCB3aWxsIG5ldmVyIHN3aXRjaCB0byB0aGUgbmV3IGlkZW50aWZpZXIuDQog VGhleSB3aWxsIHJlcXVpcmUgdGhlIG9sZCBpZGVudGlmaWVyIGZvciBhbnkgbmV3IHN5c3RlbXMg dGhleSBidXksIGluY2x1ZGluZyBjb25mZXJlbmNpbmcgc3lzdGVtcy4NCjxicj4NCjxicj4NCkJl Y2F1c2UgSGFkcmllbCdzIHNlc3Npb24taWQgaXMgdXNlZCBpbiB0aGUgM0dQUCBJTVMgc3BlY2lm aWNhdGlvcywgSSBhc3N1bWUgdGhhdCB0aGUgc2l0dWF0aW9uIGlzIHRoZSBzYW1lIGZvciBvdGhl ciBjYXJyaWVycyB1c2luZyBJTVMuDQo8YnI+DQo8YnI+DQpUaGFuayB5b3U8YnI+DQpMYXVyYSAm bmJzcDsgJm5ic3A7IDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjIwMTMvNy8yOSBIYWRyaWVsIEthcGxhbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5oYWRyaWVs LmthcGxhbkBvcmFjbGUuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCkkgdGhpbmsgdGhlcmUgbmVlZHMgc29tZSBkaXNjdXNzaW9uIGFuZCBqdXN0 aWZpY2F0aW9uIGZvciB3aHkgdGhlIHNlc3MtaWQgdmFsdWUgb3JkZXIvcGxhY2VtZW50IGlzIHN3 YXBwZWQgaW4gU0lQIHJlc3BvbnNlcyBhbmQgdXBzdHJlYW0gcmVxdWVzdHMsIGluc3RlYWQgb2Yg YmVpbmcga2VwdCB0aGUgc2FtZSBvcmRlciB0aHJvdWdob3V0LiAmbmJzcDtUaGlzIG9yZGVyLWNo YW5naW5nIGJyZWFrcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIG9sZGVyDQogU2Vz c2lvbi1JRCBpbmRpdmlkdWFsIGRyYWZ0LCBhbmQgaXMgYXJndWFibHkgaGFyZGVyIHRvIHVzZS9m aW5kIGluIGxvZ3MgYW5kIHdpcmVzaGFyayBmb3IgdHJvdWJsZXNob290aW5nIHB1cnBvc2VzLiAm bmJzcDtJIHRoaW5rIHNvbWVvbmUgbWVudGlvbmVkIHNvbWUgcmVhc29uIHRoaXMgcmUtb3JkZXJp bmcgd2FzIG5lY2Vzc2FyeSwgYnV0IEkgY2FuJ3QgcmVjYWxsIHdoYXQgaXQgaXMgYW5kIEkgZG9u J3Qgc2VlIGl0IGV4cGxhaW5lZCBpbiB0aGUgZHJhZnQuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi1oYWRyaWVsPC9zcGFuPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KT24gSnVsIDgsIDIwMTMsIGF0IDg6NDEgUE0sICZxdW90O0RSQUdFLCBLZWl0aCAo S2VpdGgpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNl bnQuY29tIj5rZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQo8YnI+DQomZ3Q7IChBcyBXRyBjb2NoYWlyKTxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIHdlbGwg YXMgcmV2aWV3aW5nIHRoZSBkb2N1bWVudCBnZW5lcmFsbHksIGl0IHdvdWxkIGJlIHVzZWZ1bCBp ZiB0aGUgV0cgbWVtYmVyc2hpcCBjb3VsZCBpbmRpY2F0ZSBhbnkgaXNzdWVzIHRoZXkgdGhpbmsg bmVlZCBmYWNlIHRvIGZhY2UgZGlzY3Vzc2lvbiB0aW1lIGluIEJlcmxpbi48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBPciBpcyBldmVyeXRoaW5nIGdvaW5nIHBlcmZlY3RseT88YnI+DQomZ3Q7PGJyPg0K Jmd0OyBBcGFydCBmcm9tIHdoYXQgaXMgbGlzdGVkIGJlbG93LCBpcyBhbnl0aGluZyBlbHNlIG1p c3NpbmcgZnJvbSB0aGUgZG9jdW1lbnQ/PGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkczxicj4N CiZndDs8YnI+DQomZ3Q7IEtlaXRoPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmluc2lw aWQtYm91bmNlc0BpZXRmLm9yZyI+aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmciPmluc2lwaWQtYm91bmNl c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZjxicj4NCiZndDsmZ3Q7IE9mIFBhdWwgRS4gSm9uZXM8 YnI+DQomZ3Q7Jmd0OyBTZW50OiAwOSBKdWx5IDIwMTMgMDA6MTc8YnI+DQomZ3Q7Jmd0OyBUbzog PGEgaHJlZj0ibWFpbHRvOmluc2lwaWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyZndDsgU3ViamVjdDogW0luc2lwaWRdIGRyYWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9u LWlkLTAxPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBGb2xrcyw8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IEkgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1pbnNpcGlk LXNlc3Npb24taWQgZm9yIHlvdXI8YnI+DQomZ3Q7Jmd0OyBjb25zaWRlcmF0aW9uLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgT25lIHNpZ25pZmljYW50IGFkZGl0aW9uIGlzIG9uZSB0byBh ZGRyZXNzIGEgY29tbWVudCBMYXVyYSBoYWQgYWJvdXQ8YnI+DQomZ3Q7Jmd0OyBlbnN1cmluZyB0 aGF0IGludGVybWVkaWFyeSBkZXZpY2VzIGNhbiBjb25zaXN0ZW50bHkgcmUtY3JlYXRlIGEgVVVJ RCBhbmQ8YnI+DQomZ3Q7Jmd0OyByZW1haW4gc3RhdGVsZXNzLiAmbmJzcDtOZXcgdGV4dCBpcyBp bnRyb2R1Y2VkIGluIFNlY3Rpb24gNC4xIHRoYXQgZGVzY3JpYmVzPGJyPg0KJmd0OyZndDsgaG93 PGJyPg0KJmd0OyZndDsgc3VjaCBlbnRpdGllcyBjYW4gY29uc3RydWN0IHRoZSBVVUlEcy48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNlY3Rpb24gNiB3YXMgYWxzbyByZXZpc2VkIHdpdGgg dGV4dCB0byBleHBsYWluIHRoYXQgdGhlIFVVSUQgb3JkZXI8YnI+DQomZ3Q7Jmd0OyByZWxhdGVz PGJyPg0KJmd0OyZndDsgdG8gd2hvIHNlbmRzIHRoZSBtZXNzYWdlLiAmbmJzcDtJdCBhbHNvIGRp c2N1c3NlcyB0aGUgbG9uZ2V2aXR5IG9mIHRoZSBVVUlELDxicj4NCiZndDsmZ3Q7IGxvZ2dpbmcs IGFuZCBjaGFuZ2VzIHRvIHRoZSAmcXVvdDtyZW1vdGUmcXVvdDsgVVVJRC48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IFByZXZpb3VzbHksIHJlcXVlc3RzIHdlcmUgbWFkZSBmb3IgYWRkaXRp b25hbCBjYWxsIGZsb3dzLiAmbmJzcDtUaG9zZSB3ZXJlIG5vdDxicj4NCiZndDsmZ3Q7IGFkZGVk IHRvIHRoZSBkb2N1bWVudCwgJm5ic3A7YnV0IHRoZSByZXF1ZXN0cyBhcmUgbGlzdGVkIGFzIFRP RE8gaXRlbXMgaW48YnI+DQomZ3Q7Jmd0OyBzZWN0aW9uKHMpIHVuZGVyIHNlY3Rpb24gOS4gJm5i c3A7VGhlcmUgaXMgYWxzbyBhIFRPRE8gZm9yIHNlY3Rpb24gOSByZWxhdGVkIHRvPGJyPg0KJmd0 OyZndDsgcmVxdWVzdGVkIGNoYW5nZXMgdG8gc2VjdGlvbiA5IHRvIG1ha2UgaXQgY2xlYXJlZCB0 aGUgdGV4dCBpcyBqdXN0PGJyPg0KJmd0OyZndDsgZXhhbXBsZXMuPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBQYXVsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyZndDsgaW5zaXBpZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86 aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQ8 L2E+PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgaW5zaXBpZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h aWx0bzppbnNpcGlkQGlldGYub3JnIj5pbnNpcGlkQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlkIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlk PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KaW5zaXBpZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aW5z aXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQ8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0 YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdl ZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9y LWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5v bi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbg0KIGJ5IGFu eW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1l ZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBm cm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVw cm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uDQogYnkgdW5pbnRlbmRlZCByZWNpcGllbnRz IGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7D2F7D7ADBA812449F25F4A69922881C14F175ESESSMB203ericsso_-- From md3135@att.com Tue Jul 30 07:52:57 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E6F21F9D05 for ; Tue, 30 Jul 2013 07:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47WBb+SB4GcD for ; Tue, 30 Jul 2013 07:52:46 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1CA21F9C8E for ; Tue, 30 Jul 2013 07:52:41 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a33d7f15.6c2f8940.4294126.00-563.11850117.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jul 2013 14:52:42 +0000 (UTC) X-MXL-Hash: 51f7d33a25f1b2a8-93ef5ac0404ba77e115c2b345b9a78274eba50db Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 833d7f15.0.4294115.00-256.11850070.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 30 Jul 2013 14:52:40 +0000 (UTC) X-MXL-Hash: 51f7d338771515fc-8a18d215b4e12a96c4b4b074a108c18da37fd054 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6UEqdhA008674; Tue, 30 Jul 2013 10:52:40 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6UEqWgV008530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 10:52:35 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 30 Jul 2013 14:52:20 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 10:52:20 -0400 From: "DOLLY, MARTIN C" To: Atle Monrad , Andrew Allen , "laura.liess.dt@googlemail.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-01 Thread-Index: AQHOjTD/6MM0LQpTnEe2zRKfMc+53pl9jOkA///BaKA= Date: Tue, 30 Jul 2013 14:52:20 +0000 Message-ID: References: <7D2F7D7ADBA812449F25F4A69922881C14F175@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C14F175@ESESSMB203.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.86.232] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365602240CE5MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: Dam_Text, public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=a2pnhbHd5kkA:10 a=GpD0Vx1SHgMA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=JIxeRlDgl] X-AnalysisOut: [0AA:10 a=48vgC7mUAAAA:8 a=mK_AVkanAAAA:8 a=yPCof4ZbAAAA:8 ] X-AnalysisOut: [a=gxZvrgisAAAA:8 a=iAyMfWh_kpwYfvg_clYA:9 a=QEXdDO2ut3YA:1] X-AnalysisOut: [0 a=lZB815dzVvQA:10 a=9xyTavCNlvEA:10 a=7DSvI1NPTFQA:10 a=] X-AnalysisOut: [3FZX-ydVlcEA:10 a=7QxddtPLqaBJgjhl:21 a=B27frMG_OCBPU_TG:2] X-AnalysisOut: [1 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=H8fnuc2dWjXUCkMC0TMA] X-AnalysisOut: [:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a] X-AnalysisOut: [=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=7tYc7uCU7kzXIAoo:21 a] X-AnalysisOut: [=WAoz5Dc_t4upCAxE:21 a=KNag4l_JPrCQ-DR3:21] Cc: "keith.drage@alcatel-lucent.com" , "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:52:58 -0000 --_000_E42CCDDA6722744CB241677169E8365602240CE5MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEuNQ0KDQpGcm9tOiBpbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppbnNpcGlkLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBdGxlIE1vbnJhZA0KU2VudDogVHVlc2RheSwg SnVseSAzMCwgMjAxMyAxMDozNiBBTQ0KVG86IEFuZHJldyBBbGxlbjsgbGF1cmEubGllc3MuZHRA Z29vZ2xlbWFpbC5jb207IGhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20NCkNjOiBrZWl0aC5kcmFn ZUBhbGNhdGVsLWx1Y2VudC5jb207IGluc2lwaWRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSW5z aXBpZF0gZHJhZnQtaWV0Zi1pbnNpcGlkLXNlc3Npb24taWQtMDENCg0KSGkNCg0KSeKAmWQgbGlr ZSB0byB0ZWFtIHVwIHdpdGggSGFkcmllbCwgTGF1cmEsIFJvbGFuZCBhbmQgQW5kcmV3IG9uIHRo ZSBzdXBwb3J0IGZvciBub3QgYnJlYWtpbmcgdGhlIEJXIGNvbXBhdGliaWxpdHkuDQoNCnRoYW5r cw0KL2F0bGUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQpBdGxlIE1v bnJhZA0KM0dQUCBDVCBDaGFpcm1hbg0KDQpHcm91cCBGdW5jdGlvbiBUZWNobm9sb2d5IOKAkyBT dGFuZGFyZGl6YXRpb24gYW5kIFRlY2huaWNhbCBSZWd1bGF0aW9uDQpFcmljc3Nvbg0KDQoNCkZy b206IGluc2lwaWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYu b3JnPiBbbWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJl dyBBbGxlbg0KU2VudDogMzAuIGp1bGkgMjAxMyAxNjoyOA0KVG86IGxhdXJhLmxpZXNzLmR0QGdv b2dsZW1haWwuY29tPG1haWx0bzpsYXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbT47IGhhZHJp ZWwua2FwbGFuQG9yYWNsZS5jb208bWFpbHRvOmhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20+DQpD Yzoga2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzprZWl0aC5kcmFnZUBhbGNh dGVsLWx1Y2VudC5jb20+OyBpbnNpcGlkQGlldGYub3JnPG1haWx0bzppbnNpcGlkQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtJbnNpcGlkXSBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC0w MQ0KDQoNCkkgYWxzbyBjb25jdXIgd2l0aCBMYXVyYSdzIHJlY29sbGVjdGlvbi4gVGhhdCBhZ3Jl ZW1lbnQgd2FzIHRoZSBiYXNpcyB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgSm9uZXMgZHJhZnQg YXMgdGhlIFdHIGRyYWZ0Lg0KDQpBbmRyZXcNCg0KRnJvbTogTGF1cmEgTGllc3MgW21haWx0bzps YXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMzAsIDIw MTMgMDY6MTggQU0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lDQpUbzogSGFkcmllbCBLYXBsYW4gPGhh ZHJpZWwua2FwbGFuQG9yYWNsZS5jb208bWFpbHRvOmhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20+ Pg0KQ2M6IERSQUdFLCBLZWl0aCAoS2VpdGgpIDxrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5j b208bWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT4+OyBpbnNpcGlkQGlldGYu b3JnPG1haWx0bzppbnNpcGlkQGlldGYub3JnPiA8aW5zaXBpZEBpZXRmLm9yZzxtYWlsdG86aW5z aXBpZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0luc2lwaWRdIGRyYWZ0LWlldGYtaW5zaXBp ZC1zZXNzaW9uLWlkLTAxDQoNCkkgYWdyZWUgd2l0aCBIYWRyaWVsLiAgSWYgSSByZW1lbWJlciBj b3JyZWN0bHksIHdlIGhhZCBhbiBhZ3JlZW1lbnQgaW4gdGhlIFdHIHRoYXQgdGhlIGlkZW50aWZp ZXIgZGVmaW5lZCBoZXJlIGhhcyB0byBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggdGhlIHNl c3Npb24taWQgaWRlbnRpZmllciBkZWZpbmVkIGluIEhhZHJpZWwncyBkcmFmdCBhbmQgdGhhdCBh IHJlZmVyZW5jZSB0byB0aGlzIGRyYWZ0IGhhcyB0byBiZSBhZGRlZC4NCg0KQmFja3dhcmQgaW5j b21wYXRpYmlsaXR5IHdpdGggSGFkcmllbCdzIHNlc3Npb24taWQgd291bGQgYmUgYSBiaWcgZHJh d2JhY2sgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgbmV3IGlkZW50aWZpZXIgd2l0aGlu IGNhcnJpZXIgbmV0d29ya3MuIENhcnJpZXJzIGFzIG15IGVtcGxveWVyLCB3aGVyZSBIYWRyaWVs J3Mgc2Vzc2lvbi1pZCBpcyBhbHJlYWR5IGltcGxlbWVudGVkLCB3aWxsIG5ldmVyIHN3aXRjaCB0 byB0aGUgbmV3IGlkZW50aWZpZXIuIFRoZXkgd2lsbCByZXF1aXJlIHRoZSBvbGQgaWRlbnRpZmll ciBmb3IgYW55IG5ldyBzeXN0ZW1zIHRoZXkgYnV5LCBpbmNsdWRpbmcgY29uZmVyZW5jaW5nIHN5 c3RlbXMuDQoNCkJlY2F1c2UgSGFkcmllbCdzIHNlc3Npb24taWQgaXMgdXNlZCBpbiB0aGUgM0dQ UCBJTVMgc3BlY2lmaWNhdGlvcywgSSBhc3N1bWUgdGhhdCB0aGUgc2l0dWF0aW9uIGlzIHRoZSBz YW1lIGZvciBvdGhlciBjYXJyaWVycyB1c2luZyBJTVMuDQoNClRoYW5rIHlvdQ0KTGF1cmENCg0K MjAxMy83LzI5IEhhZHJpZWwgS2FwbGFuIDxoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPG1haWx0 bzpoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPj4NCg0KSSB0aGluayB0aGVyZSBuZWVkcyBzb21l IGRpc2N1c3Npb24gYW5kIGp1c3RpZmljYXRpb24gZm9yIHdoeSB0aGUgc2Vzcy1pZCB2YWx1ZSBv cmRlci9wbGFjZW1lbnQgaXMgc3dhcHBlZCBpbiBTSVAgcmVzcG9uc2VzIGFuZCB1cHN0cmVhbSBy ZXF1ZXN0cywgaW5zdGVhZCBvZiBiZWluZyBrZXB0IHRoZSBzYW1lIG9yZGVyIHRocm91Z2hvdXQu ICBUaGlzIG9yZGVyLWNoYW5naW5nIGJyZWFrcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGgg dGhlIG9sZGVyIFNlc3Npb24tSUQgaW5kaXZpZHVhbCBkcmFmdCwgYW5kIGlzIGFyZ3VhYmx5IGhh cmRlciB0byB1c2UvZmluZCBpbiBsb2dzIGFuZCB3aXJlc2hhcmsgZm9yIHRyb3VibGVzaG9vdGlu ZyBwdXJwb3Nlcy4gIEkgdGhpbmsgc29tZW9uZSBtZW50aW9uZWQgc29tZSByZWFzb24gdGhpcyBy ZS1vcmRlcmluZyB3YXMgbmVjZXNzYXJ5LCBidXQgSSBjYW4ndCByZWNhbGwgd2hhdCBpdCBpcyBh bmQgSSBkb24ndCBzZWUgaXQgZXhwbGFpbmVkIGluIHRoZSBkcmFmdC4NCg0KLWhhZHJpZWwNCg0K DQpPbiBKdWwgOCwgMjAxMywgYXQgODo0MSBQTSwgIkRSQUdFLCBLZWl0aCAoS2VpdGgpIiA8a2Vp dGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1 Y2VudC5jb20+PiB3cm90ZToNCg0KPiAoQXMgV0cgY29jaGFpcikNCj4NCj4gQXMgd2VsbCBhcyBy ZXZpZXdpbmcgdGhlIGRvY3VtZW50IGdlbmVyYWxseSwgaXQgd291bGQgYmUgdXNlZnVsIGlmIHRo ZSBXRyBtZW1iZXJzaGlwIGNvdWxkIGluZGljYXRlIGFueSBpc3N1ZXMgdGhleSB0aGluayBuZWVk IGZhY2UgdG8gZmFjZSBkaXNjdXNzaW9uIHRpbWUgaW4gQmVybGluLg0KPg0KPiBPciBpcyBldmVy eXRoaW5nIGdvaW5nIHBlcmZlY3RseT8NCj4NCj4gQXBhcnQgZnJvbSB3aGF0IGlzIGxpc3RlZCBi ZWxvdywgaXMgYW55dGhpbmcgZWxzZSBtaXNzaW5nIGZyb20gdGhlIGRvY3VtZW50Pw0KPg0KPiBS ZWdhcmRzDQo+DQo+IEtlaXRoDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogaW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppbnNpcGlkLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYNCj4+IE9mIFBhdWwgRS4gSm9uZXMNCj4+IFNlbnQ6 IDA5IEp1bHkgMjAxMyAwMDoxNw0KPj4gVG86IGluc2lwaWRAaWV0Zi5vcmc8bWFpbHRvOmluc2lw aWRAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBbSW5zaXBpZF0gZHJhZnQtaWV0Zi1pbnNpcGlkLXNl c3Npb24taWQtMDENCj4+DQo+PiBGb2xrcywNCj4+DQo+PiBJIHBvc3RlZCBhIG5ldyB2ZXJzaW9u IG9mIGRyYWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9uLWlkIGZvciB5b3VyDQo+PiBjb25zaWRlcmF0 aW9uLg0KPj4NCj4+IE9uZSBzaWduaWZpY2FudCBhZGRpdGlvbiBpcyBvbmUgdG8gYWRkcmVzcyBh IGNvbW1lbnQgTGF1cmEgaGFkIGFib3V0DQo+PiBlbnN1cmluZyB0aGF0IGludGVybWVkaWFyeSBk ZXZpY2VzIGNhbiBjb25zaXN0ZW50bHkgcmUtY3JlYXRlIGEgVVVJRCBhbmQNCj4+IHJlbWFpbiBz dGF0ZWxlc3MuICBOZXcgdGV4dCBpcyBpbnRyb2R1Y2VkIGluIFNlY3Rpb24gNC4xIHRoYXQgZGVz Y3JpYmVzDQo+PiBob3cNCj4+IHN1Y2ggZW50aXRpZXMgY2FuIGNvbnN0cnVjdCB0aGUgVVVJRHMu DQo+Pg0KPj4gU2VjdGlvbiA2IHdhcyBhbHNvIHJldmlzZWQgd2l0aCB0ZXh0IHRvIGV4cGxhaW4g dGhhdCB0aGUgVVVJRCBvcmRlcg0KPj4gcmVsYXRlcw0KPj4gdG8gd2hvIHNlbmRzIHRoZSBtZXNz YWdlLiAgSXQgYWxzbyBkaXNjdXNzZXMgdGhlIGxvbmdldml0eSBvZiB0aGUgVVVJRCwNCj4+IGxv Z2dpbmcsIGFuZCBjaGFuZ2VzIHRvIHRoZSAicmVtb3RlIiBVVUlELg0KPj4NCj4+IFByZXZpb3Vz bHksIHJlcXVlc3RzIHdlcmUgbWFkZSBmb3IgYWRkaXRpb25hbCBjYWxsIGZsb3dzLiAgVGhvc2Ug d2VyZSBub3QNCj4+IGFkZGVkIHRvIHRoZSBkb2N1bWVudCwgIGJ1dCB0aGUgcmVxdWVzdHMgYXJl IGxpc3RlZCBhcyBUT0RPIGl0ZW1zIGluDQo+PiBzZWN0aW9uKHMpIHVuZGVyIHNlY3Rpb24gOS4g IFRoZXJlIGlzIGFsc28gYSBUT0RPIGZvciBzZWN0aW9uIDkgcmVsYXRlZCB0bw0KPj4gcmVxdWVz dGVkIGNoYW5nZXMgdG8gc2VjdGlvbiA5IHRvIG1ha2UgaXQgY2xlYXJlZCB0aGUgdGV4dCBpcyBq dXN0DQo+PiBleGFtcGxlcy4NCj4+DQo+PiBQYXVsDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBpbnNpcGlkIG1haWxpbmcgbGlz dA0KPj4gaW5zaXBpZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9yZz4NCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpbnNpcGlkIG1haWxpbmcgbGlz dA0KPiBpbnNpcGlkQGlldGYub3JnPG1haWx0bzppbnNpcGlkQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmluc2lwaWQgbWFpbGluZyBsaXN0DQpp bnNpcGlkQGlldGYub3JnPG1haWx0bzppbnNpcGlkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlkDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFu c21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFs IHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHBy aXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ug b2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBi eSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4NCg== --_000_E42CCDDA6722744CB241677169E8365602240CE5MISOUT7MSGUSR9I_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiYjNDM7MS41PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaW5zaXBpZC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5BdGxlIE1vbnJhZDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDMw LCAyMDEzIDEwOjM2IEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZXcgQWxsZW47IGxhdXJhLmxpZXNz LmR0QGdvb2dsZW1haWwuY29tOyBoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPGJyPg0KPGI+Q2M6 PC9iPiBrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb207IGluc2lwaWRAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJbnNpcGlkXSBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lv bi1pZC0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKA mWQgbGlrZSB0byB0ZWFtIHVwIHdpdGggSGFkcmllbCwgTGF1cmEsIFJvbGFuZCBhbmQgQW5kcmV3 IG9uIHRoZSBzdXBwb3J0IGZvciBub3QgYnJlYWtpbmcgdGhlIEJXIGNvbXBhdGliaWxpdHkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj50aGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L2F0bGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGI+QXRsZSBNb25yYWQ8L2I+PGJyPg0KM0dQ UCBDVCBDaGFpcm1hbjxicj4NCjxicj4NCkdyb3VwIEZ1bmN0aW9uIFRlY2hub2xvZ3kg4oCTIFN0 YW5kYXJkaXphdGlvbiBhbmQgVGVjaG5pY2FsIFJlZ3VsYXRpb248L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQpFcmljc3Nvbjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmluc2lwaWQt Ym91bmNlc0BpZXRmLm9yZyI+aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0i bWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmluc2lwaWQtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHJldyBBbGxlbjxicj4NCjxiPlNl bnQ6PC9iPiAzMC4ganVsaSAyMDEzIDE2OjI4PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWls dG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb20iPmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1h aWwuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tIj5o YWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbSI+a2VpdGguZHJhZ2VAYWxjYXRlbC1s dWNlbnQuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzppbnNpcGlkQGlldGYub3JnIj5pbnNpcGlk QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0luc2lwaWRdIGRyYWZ0LWll dGYtaW5zaXBpZC1zZXNzaW9uLWlkLTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pjxicj4NCkkgYWxzbyBjb25jdXIgd2l0aCBMYXVyYSdzIHJlY29sbGVjdGlvbi4gVGhhdCBhZ3Jl ZW1lbnQgd2FzIHRoZSBiYXNpcyB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgSm9uZXMgZHJhZnQg YXMgdGhlIFdHIGRyYWZ0Ljxicj4NCjxicj4NCkFuZHJldzwvc3Bhbj48YnI+DQombmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+OiBMYXVyYSBMaWVzcyBbPGEgaHJlZj0ibWFpbHRvOmxhdXJh LmxpZXNzLmR0QGdvb2dsZW1haWwuY29tIj5tYWlsdG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFp bC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDwvYj46IFR1ZXNkYXksIEp1bHkgMzAsIDIwMTMgMDY6 MTggQU0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBIYWRyaWVsIEthcGxh biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20iPmhhZHJpZWwu a2FwbGFuQG9yYWNsZS5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+Q2M8L2I+OiBEUkFHRSwgS2VpdGgg KEtlaXRoKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNv bSI+a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWls dG86aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1h aWx0bzppbnNpcGlkQGlldGYub3JnIj5pbnNpcGlkQGlldGYub3JnPC9hPiZndDsNCjxicj4NCjxi PlN1YmplY3Q8L2I+OiBSZTogW0luc2lwaWRdIGRyYWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9uLWlk LTAxIDxicj4NCjwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGFncmVlIHdpdGggSGFk cmllbC4mbmJzcDsgSWYgSSByZW1lbWJlciBjb3JyZWN0bHksIHdlIGhhZCBhbiBhZ3JlZW1lbnQg aW4gdGhlIFdHIHRoYXQgdGhlIGlkZW50aWZpZXIgZGVmaW5lZCBoZXJlIGhhcyB0byBiZSBiYWNr d2FyZCBjb21wYXRpYmxlIHdpdGggdGhlIHNlc3Npb24taWQgaWRlbnRpZmllciBkZWZpbmVkIGlu IEhhZHJpZWwncyBkcmFmdCBhbmQgdGhhdA0KIGEgcmVmZXJlbmNlIHRvIHRoaXMgZHJhZnQgaGFz IHRvIGJlIGFkZGVkLiA8YnI+DQo8YnI+DQpCYWNrd2FyZCBpbmNvbXBhdGliaWxpdHkgd2l0aCBI YWRyaWVsJ3Mgc2Vzc2lvbi1pZCB3b3VsZCBiZSBhIGJpZyBkcmF3YmFjayBmb3IgdGhlIGltcGxl bWVudGF0aW9uIG9mIHRoZSBuZXcgaWRlbnRpZmllciB3aXRoaW4gY2FycmllciBuZXR3b3Jrcy4g Q2FycmllcnMgYXMgbXkgZW1wbG95ZXIsIHdoZXJlIEhhZHJpZWwncyBzZXNzaW9uLWlkIGlzIGFs cmVhZHkgaW1wbGVtZW50ZWQsIHdpbGwgbmV2ZXIgc3dpdGNoIHRvIHRoZSBuZXcgaWRlbnRpZmll ci4NCiBUaGV5IHdpbGwgcmVxdWlyZSB0aGUgb2xkIGlkZW50aWZpZXIgZm9yIGFueSBuZXcgc3lz dGVtcyB0aGV5IGJ1eSwgaW5jbHVkaW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLg0KPGJyPg0KPGJy Pg0KQmVjYXVzZSBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCBpcyB1c2VkIGluIHRoZSAzR1BQIElNUyBz cGVjaWZpY2F0aW9zLCBJIGFzc3VtZSB0aGF0IHRoZSBzaXR1YXRpb24gaXMgdGhlIHNhbWUgZm9y IG90aGVyIGNhcnJpZXJzIHVzaW5nIElNUy4NCjxicj4NCjxicj4NClRoYW5rIHlvdTxicj4NCkxh dXJhICZuYnNwOyAmbmJzcDsgPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MjAxMy83LzI5IEhhZHJpZWwgS2FwbGFuICZsdDs8YSBocmVmPSJt YWlsdG86aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhhZHJpZWwu a2FwbGFuQG9yYWNsZS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KSSB0aGluayB0aGVyZSBuZWVkcyBzb21lIGRpc2N1c3Npb24gYW5kIGp1c3Rp ZmljYXRpb24gZm9yIHdoeSB0aGUgc2Vzcy1pZCB2YWx1ZSBvcmRlci9wbGFjZW1lbnQgaXMgc3dh cHBlZCBpbiBTSVAgcmVzcG9uc2VzIGFuZCB1cHN0cmVhbSByZXF1ZXN0cywgaW5zdGVhZCBvZiBi ZWluZyBrZXB0IHRoZSBzYW1lIG9yZGVyIHRocm91Z2hvdXQuICZuYnNwO1RoaXMgb3JkZXItY2hh bmdpbmcgYnJlYWtzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgb2xkZXINCiBTZXNz aW9uLUlEIGluZGl2aWR1YWwgZHJhZnQsIGFuZCBpcyBhcmd1YWJseSBoYXJkZXIgdG8gdXNlL2Zp bmQgaW4gbG9ncyBhbmQgd2lyZXNoYXJrIGZvciB0cm91Ymxlc2hvb3RpbmcgcHVycG9zZXMuICZu YnNwO0kgdGhpbmsgc29tZW9uZSBtZW50aW9uZWQgc29tZSByZWFzb24gdGhpcyByZS1vcmRlcmlu ZyB3YXMgbmVjZXNzYXJ5LCBidXQgSSBjYW4ndCByZWNhbGwgd2hhdCBpdCBpcyBhbmQgSSBkb24n dCBzZWUgaXQgZXhwbGFpbmVkIGluIHRoZSBkcmFmdC48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LWhhZHJpZWw8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQpPbiBKdWwgOCwgMjAxMywgYXQgODo0MSBQTSwgJnF1b3Q7RFJBR0UsIEtlaXRoIChL ZWl0aCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2Vu dC5jb20iPmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N Cjxicj4NCiZndDsgKEFzIFdHIGNvY2hhaXIpPGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgd2VsbCBh cyByZXZpZXdpbmcgdGhlIGRvY3VtZW50IGdlbmVyYWxseSwgaXQgd291bGQgYmUgdXNlZnVsIGlm IHRoZSBXRyBtZW1iZXJzaGlwIGNvdWxkIGluZGljYXRlIGFueSBpc3N1ZXMgdGhleSB0aGluayBu ZWVkIGZhY2UgdG8gZmFjZSBkaXNjdXNzaW9uIHRpbWUgaW4gQmVybGluLjxicj4NCiZndDs8YnI+ DQomZ3Q7IE9yIGlzIGV2ZXJ5dGhpbmcgZ29pbmcgcGVyZmVjdGx5Pzxicj4NCiZndDs8YnI+DQom Z3Q7IEFwYXJ0IGZyb20gd2hhdCBpcyBsaXN0ZWQgYmVsb3csIGlzIGFueXRoaW5nIGVsc2UgbWlz c2luZyBmcm9tIHRoZSBkb2N1bWVudD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRzPGJyPg0K Jmd0Ozxicj4NCiZndDsgS2VpdGg8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86aW5zaXBp ZC1ib3VuY2VzQGlldGYub3JnIj5pbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZyI+aW5zaXBpZC1ib3VuY2Vz QGlldGYub3JnPC9hPl0gT24gQmVoYWxmPGJyPg0KJmd0OyZndDsgT2YgUGF1bCBFLiBKb25lczxi cj4NCiZndDsmZ3Q7IFNlbnQ6IDA5IEp1bHkgMjAxMyAwMDoxNzxicj4NCiZndDsmZ3Q7IFRvOiA8 YSBocmVmPSJtYWlsdG86aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7Jmd0OyBTdWJqZWN0OiBbSW5zaXBpZF0gZHJhZnQtaWV0Zi1pbnNpcGlkLXNlc3Npb24t aWQtMDE8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZvbGtzLDxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgSSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLWluc2lwaWQt c2Vzc2lvbi1pZCBmb3IgeW91cjxicj4NCiZndDsmZ3Q7IGNvbnNpZGVyYXRpb24uPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbmUgc2lnbmlmaWNhbnQgYWRkaXRpb24gaXMgb25lIHRvIGFk ZHJlc3MgYSBjb21tZW50IExhdXJhIGhhZCBhYm91dDxicj4NCiZndDsmZ3Q7IGVuc3VyaW5nIHRo YXQgaW50ZXJtZWRpYXJ5IGRldmljZXMgY2FuIGNvbnNpc3RlbnRseSByZS1jcmVhdGUgYSBVVUlE IGFuZDxicj4NCiZndDsmZ3Q7IHJlbWFpbiBzdGF0ZWxlc3MuICZuYnNwO05ldyB0ZXh0IGlzIGlu dHJvZHVjZWQgaW4gU2VjdGlvbiA0LjEgdGhhdCBkZXNjcmliZXM8YnI+DQomZ3Q7Jmd0OyBob3c8 YnI+DQomZ3Q7Jmd0OyBzdWNoIGVudGl0aWVzIGNhbiBjb25zdHJ1Y3QgdGhlIFVVSURzLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU2VjdGlvbiA2IHdhcyBhbHNvIHJldmlzZWQgd2l0aCB0 ZXh0IHRvIGV4cGxhaW4gdGhhdCB0aGUgVVVJRCBvcmRlcjxicj4NCiZndDsmZ3Q7IHJlbGF0ZXM8 YnI+DQomZ3Q7Jmd0OyB0byB3aG8gc2VuZHMgdGhlIG1lc3NhZ2UuICZuYnNwO0l0IGFsc28gZGlz Y3Vzc2VzIHRoZSBsb25nZXZpdHkgb2YgdGhlIFVVSUQsPGJyPg0KJmd0OyZndDsgbG9nZ2luZywg YW5kIGNoYW5nZXMgdG8gdGhlICZxdW90O3JlbW90ZSZxdW90OyBVVUlELjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgUHJldmlvdXNseSwgcmVxdWVzdHMgd2VyZSBtYWRlIGZvciBhZGRpdGlv bmFsIGNhbGwgZmxvd3MuICZuYnNwO1Rob3NlIHdlcmUgbm90PGJyPg0KJmd0OyZndDsgYWRkZWQg dG8gdGhlIGRvY3VtZW50LCAmbmJzcDtidXQgdGhlIHJlcXVlc3RzIGFyZSBsaXN0ZWQgYXMgVE9E TyBpdGVtcyBpbjxicj4NCiZndDsmZ3Q7IHNlY3Rpb24ocykgdW5kZXIgc2VjdGlvbiA5LiAmbmJz cDtUaGVyZSBpcyBhbHNvIGEgVE9ETyBmb3Igc2VjdGlvbiA5IHJlbGF0ZWQgdG88YnI+DQomZ3Q7 Jmd0OyByZXF1ZXN0ZWQgY2hhbmdlcyB0byBzZWN0aW9uIDkgdG8gbWFrZSBpdCBjbGVhcmVkIHRo ZSB0ZXh0IGlzIGp1c3Q8YnI+DQomZ3Q7Jmd0OyBleGFtcGxlcy48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFBhdWw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 Jmd0OyBpbnNpcGlkIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpp bnNpcGlkQGlldGYub3JnIj5pbnNpcGlkQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZDwv YT48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyBpbnNpcGlkIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFp bHRvOmluc2lwaWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQ8 L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQppbnNpcGlkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppbnNp cGlkQGlldGYub3JnIj5pbnNpcGlkQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSA8YnI+DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2Vk IG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3It Y2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9u LXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uDQogYnkgYW55 b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVk aWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZy b20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXBy b2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24NCiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMg aXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E42CCDDA6722744CB241677169E8365602240CE5MISOUT7MSGUSR9I_-- From hadriel.kaplan@oracle.com Tue Jul 30 12:38:59 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C7B21E80A1 for ; Tue, 30 Jul 2013 12:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkt2dS+wuX+Q for ; Tue, 30 Jul 2013 12:38:53 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6099521E80C1 for ; Tue, 30 Jul 2013 12:38:53 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6UJcn5M008372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jul 2013 19:38:50 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6UJcl5Y024994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 19:38:48 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6UJcl6W024987; Tue, 30 Jul 2013 19:38:47 GMT Received: from [10.13.52.191] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Jul 2013 12:38:47 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51F7A26B.1000704@ericsson.com> Date: Tue, 30 Jul 2013 15:38:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F7A26B.1000704@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: insipid@ietf.org Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 19:38:59 -0000 Uhhh... just to be clear, I was making an individual comment in that = email, not a corporate position statement or any some such. My point was that since the use-cases people are planning to do for = INSIPID's Session-ID have now gone far beyond troubleshooting, the odds = are we can't rely on it always being passed through end-to-end from = originating Enterprises through various service providers to the = far-end, without being modified in-transit. I can't *prove* it won't = be, but that's just my hunch, since we've seen this movie play out = before. The good news is we don't need the Session-ID to be used in STIR for = caller-id verification, so there's nothing to worry about. :) -hadriel On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo = wrote: > Hi, >=20 > I just got a publication request for the requirements document: >=20 > http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 >=20 > The following is one of the requirements in the draft, which was one = of > the main reasons for creating this WG: >=20 >> REQ3: The solution must require that the identifier, if present, = pass >> unchanged through SIP B2BUAs or other intermediaries. >=20 > Hadriel, who works for an important SBC vendor and is one of the = authors > of the requirements document, sent the comments below to the STIR list = a > couple of weeks ago (see email below). >=20 > How should I interpret those comments in the context of my AD review = of > this document and, even more importantly, as the responsible AD for = this > WG (as you know, we have had many scope-related discussions in the = past)? >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > -------- Original Message -------- > Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR = Charter) > Date: Tue, 16 Jul 2013 10:21:13 -0400 > From: Hadriel Kaplan > To: Richard Shockey > CC: IETF STIR Mail List >=20 >=20 > On Jul 16, 2013, at 9:35 AM, "Richard Shockey" = wrote: >=20 >> I actually believe INSIPID is equally important to the overall task > since it >> is the track and trace elements of this that can ultimately enable = some >> enforcement. I wish there was some more discussion on how the = mechanisms >> would work at the edge SIP/SS7 network gateways since that clearly = has > been >> the center of most of the reported problems. I still think something > needs >> to be done to police that traffic but that is still ultimately a > regulatory >> effort. >=20 > I agree we need a tracking/tracing mechanism, but in my opinion we > cannot and should not rely on INSIPID Session-ID at all for that. = They > have gone beyond benign troubleshooting-type purposes now, which means > there is absolutely no guarantee the Session-ID will make it intact > across service providers in all cases. In fact, my hunch is it won't. >=20 > Regardless, the Session-ID isn't what we really need for tracing a bad > caller-id call. Even without Session-ID, the service provider's CDRs = or > logs can be used to trace it back to the peering connection and peer > upstream provider the call came in from. What we also need is a list = of > SPIDs the call request has crossed through, so we can trace it back > further upstream. Kinda like a Via header, but with very different > properties and purpose. We've talked about doing that before, back = when > there was talk about creating a registry of SPIDs. What ever happened > to having a registry of SPIDs? >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Tue Jul 30 19:39:14 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9DF21F9B19 for ; Tue, 30 Jul 2013 19:39:14 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+Vd8VJgrVHI for ; Tue, 30 Jul 2013 19:39:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 28D7F21F9B18 for ; Tue, 30 Jul 2013 19:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6719; q=dns/txt; s=iport; t=1375238345; x=1376447945; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=jwaqQqH7751H1E4AQBghJasjIVTAKheJ1sLpvjUq4Xw=; b=F/otsCQX6dK2S72W9f6u6G3du6D+xZ3ZA3D61iFlHatbI0scABk+3ev0 MxzxgeFuBKHhOvzH2HZJnOiWCHKPdaP+TIBB2Qq8PZcg0fKg7kcjPhhzI l+J4nSf5CuJbv/xJ8Kc29Me5ikK9zfMocfd89Eh4wkM6Km8TiNqJlg6q4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAHB3+FGtJXG8/2dsb2JhbABbgwY1vmiBHBZ0giQBAQEEAQEBNQItBwsMBAcEDgMEAQEBCRUJBw8KDh8JCAYBEod+Aw8Mr3QNiFoEjQ2BKIFJBwaEAwOJKopelSODMh4 X-IronPort-AV: E=Sophos;i="4.89,783,1367971200"; d="scan'208";a="241598250" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 31 Jul 2013 02:39:02 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6V2d1jv001608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 02:39:01 GMT Message-Id: <201307310239.r6V2d1jv001608@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Jul 2013 21:38:20 -0500 To: Andrew Allen , "laura.liess.dt@googlemail.com" , "hadriel.kaplan@oracle.com" From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "keith.drage@alcatel-lucent.com" , "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 02:39:14 -0000 I don't concur with Laura's recollection. The WG agreement was that we (the Jones draft authors) had to try as hard as we could to be backwards compatible with something that's only in draft form. That's why we put into the Jones draft a backwards compatibility section, which has holes in it - because it was Christer's lab that was the only one doing the testing, and the Jones draft authors haven't heard any new information from him since last summer (even though we've asked that several questions be answered last August and/or September). From the initial indiv-00 version of the Jones draft, that Session-ID has been in two parts. The Kaplan draft, and what's been implemented before it reached RFC status, was a 1-part Session-ID. We've made every attempt to address how a 2-part value can be backwards compatible with a 1-part value, but there are certain circumstances in which that compatibility just isn't there. I find it interesting that Laura's note to the list includes the line "... Carriers as my employer, where Hadriel's session-id is already implemented, will never switch to the new identifier...". I remember a company saying that same thing about the SIP Diversion header, which predated the History-Info header by like 5 years, and still the History-Info header was the one to make it to Standard-track RFC. James At 09:28 AM 7/30/2013, Andrew Allen wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338DED5BDXMB104ADSrimnet_" > > >I also concur with Laura's recollection. That agreement was the >basis to move forward with the Jones draft as the WG draft. > >Andrew > >From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >Sent: Tuesday, July 30, 2013 06:18 AM Central Standard Time >To: Hadriel Kaplan >Cc: DRAGE, Keith (Keith) ; >insipid@ietf.org >Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 > >I agree with Hadriel. If I remember correctly, we had an agreement >in the WG that the identifier defined here has to be backward >compatible with the session-id identifier defined in Hadriel's draft >and that a reference to this draft has to be added. > >Backward incompatibility with Hadriel's session-id would be a big >drawback for the implementation of the new identifier within carrier >networks. Carriers as my employer, where Hadriel's session-id is >already implemented, will never switch to the new identifier. They >will require the old identifier for any new systems they buy, >including conferencing systems. > >Because Hadriel's session-id is used in the 3GPP IMS specificatios, >I assume that the situation is the same for other carriers using IMS. > >Thank you >Laura > > > >2013/7/29 Hadriel Kaplan ><hadriel.kaplan@oracle.com> > >I think there needs some discussion and justification for why the >sess-id value order/placement is swapped in SIP responses and >upstream requests, instead of being kept the same order >throughout. This order-changing breaks backward compatibility with >the older Session-ID individual draft, and is arguably harder to >use/find in logs and wireshark for troubleshooting purposes. I >think someone mentioned some reason this re-ordering was necessary, >but I can't recall what it is and I don't see it explained in the draft. > >-hadriel > > >On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" ><keith.drage@alcatel-lucent.com> wrote: > > > (As WG cochair) > > > > As well as reviewing the document generally, it would be useful > if the WG membership could indicate any issues they think need face > to face discussion time in Berlin. > > > > Or is everything going perfectly? > > > > Apart from what is listed below, is anything else missing from > the document? > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: insipid-bounces@ietf.org > [mailto:insipid-bounces@ietf.org] On Behalf > >> Of Paul E. Jones > >> Sent: 09 July 2013 00:17 > >> To: insipid@ietf.org > >> Subject: [Insipid] draft-ietf-insipid-session-id-01 > >> > >> Folks, > >> > >> I posted a new version of draft-ietf-insipid-session-id for your > >> consideration. > >> > >> One significant addition is one to address a comment Laura had about > >> ensuring that intermediary devices can consistently re-create a UUID and > >> remain stateless. New text is introduced in Section 4.1 that describes > >> how > >> such entities can construct the UUIDs. > >> > >> Section 6 was also revised with text to explain that the UUID order > >> relates > >> to who sends the message. It also discusses the longevity of the UUID, > >> logging, and changes to the "remote" UUID. > >> > >> Previously, requests were made for additional call flows. Those were not > >> added to the document, but the requests are listed as TODO items in > >> section(s) under section 9. There is also a TODO for section 9 related to > >> requested changes to section 9 to make it cleared the text is just > >> examples. > >> > >> Paul > >> > >> > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid > > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain >confidential information, privileged material (including material >protected by the solicitor-client or other applicable privileges), >or constitute non-public information. Any use of this information by >anyone other than the intended recipient is prohibited. If you have >received this transmission in error, please immediately reply to the >sender and delete this information from your system. Use, >dissemination, distribution, or reproduction of this transmission by >unintended recipients is not authorized and may be unlawful. >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jan.van.geel@belgacom.be Wed Jul 31 00:03:32 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7349811E80E4 for ; Wed, 31 Jul 2013 00:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMmBpGpUMpP9 for ; Wed, 31 Jul 2013 00:03:28 -0700 (PDT) Received: from mx13.belgacom.be (mx13.belgacom.be [195.13.15.233]) by ietfa.amsl.com (Postfix) with ESMTP id EDD2421F9CCA for ; Wed, 31 Jul 2013 00:03:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,785,1367964000"; d="scan'208,217";a="30749287" Received: from a03007.bgc.net ([10.120.129.162]) by mx13.belgacom.be with ESMTP; 31 Jul 2013 09:03:23 +0200 X-TM-IMSS-Message-ID: <07c8381e0001a08c@belgacom.be> Received: from A04027.BGC.NET ([10.121.135.24]) by belgacom.be ([10.120.129.162]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 07c8381e0001a08c ; Wed, 31 Jul 2013 09:03:22 +0200 Received: from A04067.BGC.NET ([10.121.135.38]) by A04027.BGC.NET ([10.121.135.24]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 09:03:22 +0200 From: "VAN GEEL Jan (CIS/SCC)" To: "insipid@ietf.org" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-01 Thread-Index: AQHOjRabmctqSkDEFUmO3YQ4AN20Cpl9JkuAgAACPQCAAASMAIABMIAw Date: Wed, 31 Jul 2013 07:03:21 +0000 Message-ID: <1E97FFD1485F1142BC075FF145A53A1E312C48@A04067.BGC.NET> References: <7D2F7D7ADBA812449F25F4A69922881C14F175@ESESSMB203.ericsson.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.28.34] Content-Type: multipart/alternative; boundary="_000_1E97FFD1485F1142BC075FF145A53A1E312C48A04067BGCNET_" MIME-Version: 1.0 Cc: Andrew Allen , "keith.drage@alcatel-lucent.com" , "hadriel.kaplan@oracle.com" , "DOLLY, MARTIN C" , Atle Monrad , "laura.liess.dt@googlemail.com" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:03:32 -0000 --_000_1E97FFD1485F1142BC075FF145A53A1E312C48A04067BGCNET_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IOKAnG5vdCBicmVha2luZyB0aGUgQlcgY29tcGF0aWJpbGl0eeKAnQ0KDQpTbyAg KzENCg0KSmFuIFZhbiBHZWVsDQpJVCBhbmQgTmV0d29yayBTcGVjaWFsaXN0DQpCZWxnYWNvbSBD SVMvU0NDL0ZWQw0KVGVsOiArMzIgMiAyMDIgMTAzNQ0KVGVsOiArMzIgMiAyMDcgOTAzMg0KRW1h aWwgOiBqYW4udmFuLmdlZWxAYmVsZ2Fjb20uYmU8bWFpbHRvOmphbi52YW4uZ2VlbEBiZWxnYWNv bS5iZT4NCg0KRnJvbTogaW5zaXBpZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aW5zaXBpZC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRE9MTFksIE1BUlRJTiBDDQpTZW50OiBUdWVz ZGF5IDMwIEp1bHkgMjAxMyAxNjo1Mg0KVG86IEF0bGUgTW9ucmFkOyBBbmRyZXcgQWxsZW47IGxh dXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tOyBoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tDQpD Yzoga2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tOyBpbnNpcGlkQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0luc2lwaWRdIGRyYWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9uLWlkLTAxDQoNCisx LjUNCg0KRnJvbTogaW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppbnNpcGlkLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQXRsZSBNb25yYWQNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMzAsIDIwMTMgMTA6MzYgQU0NClRv OiBBbmRyZXcgQWxsZW47IGxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tPG1haWx0bzpsYXVy YS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbT47IGhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb208bWFp bHRvOmhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20+DQpDYzoga2VpdGguZHJhZ2VAYWxjYXRlbC1s dWNlbnQuY29tPG1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+OyBpbnNpcGlk QGlldGYub3JnPG1haWx0bzppbnNpcGlkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJbnNpcGlk XSBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC0wMQ0KDQpIaQ0KDQpJ4oCZZCBsaWtlIHRv IHRlYW0gdXAgd2l0aCBIYWRyaWVsLCBMYXVyYSwgUm9sYW5kIGFuZCBBbmRyZXcgb24gdGhlIHN1 cHBvcnQgZm9yIG5vdCBicmVha2luZyB0aGUgQlcgY29tcGF0aWJpbGl0eS4NCg0KdGhhbmtzDQov YXRsZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCkF0bGUgTW9ucmFk DQozR1BQIENUIENoYWlybWFuDQoNCkdyb3VwIEZ1bmN0aW9uIFRlY2hub2xvZ3kg4oCTIFN0YW5k YXJkaXphdGlvbiBhbmQgVGVjaG5pY2FsIFJlZ3VsYXRpb24NCkVyaWNzc29uDQoNCg0KRnJvbTog aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3IEFs bGVuDQpTZW50OiAzMC4ganVsaSAyMDEzIDE2OjI4DQpUbzogbGF1cmEubGllc3MuZHRAZ29vZ2xl bWFpbC5jb208bWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tPjsgaGFkcmllbC5r YXBsYW5Ab3JhY2xlLmNvbTxtYWlsdG86aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbT4NCkNjOiBr ZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwt bHVjZW50LmNvbT47IGluc2lwaWRAaWV0Zi5vcmc8bWFpbHRvOmluc2lwaWRAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW0luc2lwaWRdIGRyYWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9uLWlkLTAxDQoN Cg0KSSBhbHNvIGNvbmN1ciB3aXRoIExhdXJhJ3MgcmVjb2xsZWN0aW9uLiBUaGF0IGFncmVlbWVu dCB3YXMgdGhlIGJhc2lzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBKb25lcyBkcmFmdCBhcyB0 aGUgV0cgZHJhZnQuDQoNCkFuZHJldw0KDQpGcm9tOiBMYXVyYSBMaWVzcyBbbWFpbHRvOmxhdXJh LmxpZXNzLmR0QGdvb2dsZW1haWwuY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAzMCwgMjAxMyAw NjoxOCBBTSBDZW50cmFsIFN0YW5kYXJkIFRpbWUNClRvOiBIYWRyaWVsIEthcGxhbiA8aGFkcmll bC5rYXBsYW5Ab3JhY2xlLmNvbTxtYWlsdG86aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbT4+DQpD YzogRFJBR0UsIEtlaXRoIChLZWl0aCkgPGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTxt YWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPj47IGluc2lwaWRAaWV0Zi5vcmc8 bWFpbHRvOmluc2lwaWRAaWV0Zi5vcmc+IDxpbnNpcGlkQGlldGYub3JnPG1haWx0bzppbnNpcGlk QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSW5zaXBpZF0gZHJhZnQtaWV0Zi1pbnNpcGlkLXNl c3Npb24taWQtMDENCg0KSSBhZ3JlZSB3aXRoIEhhZHJpZWwuICBJZiBJIHJlbWVtYmVyIGNvcnJl Y3RseSwgd2UgaGFkIGFuIGFncmVlbWVudCBpbiB0aGUgV0cgdGhhdCB0aGUgaWRlbnRpZmllciBk ZWZpbmVkIGhlcmUgaGFzIHRvIGJlIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCB0aGUgc2Vzc2lv bi1pZCBpZGVudGlmaWVyIGRlZmluZWQgaW4gSGFkcmllbCdzIGRyYWZ0IGFuZCB0aGF0IGEgcmVm ZXJlbmNlIHRvIHRoaXMgZHJhZnQgaGFzIHRvIGJlIGFkZGVkLg0KDQpCYWNrd2FyZCBpbmNvbXBh dGliaWxpdHkgd2l0aCBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCB3b3VsZCBiZSBhIGJpZyBkcmF3YmFj ayBmb3IgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBuZXcgaWRlbnRpZmllciB3aXRoaW4gY2Fy cmllciBuZXR3b3Jrcy4gQ2FycmllcnMgYXMgbXkgZW1wbG95ZXIsIHdoZXJlIEhhZHJpZWwncyBz ZXNzaW9uLWlkIGlzIGFscmVhZHkgaW1wbGVtZW50ZWQsIHdpbGwgbmV2ZXIgc3dpdGNoIHRvIHRo ZSBuZXcgaWRlbnRpZmllci4gVGhleSB3aWxsIHJlcXVpcmUgdGhlIG9sZCBpZGVudGlmaWVyIGZv ciBhbnkgbmV3IHN5c3RlbXMgdGhleSBidXksIGluY2x1ZGluZyBjb25mZXJlbmNpbmcgc3lzdGVt cy4NCg0KQmVjYXVzZSBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCBpcyB1c2VkIGluIHRoZSAzR1BQIElN UyBzcGVjaWZpY2F0aW9zLCBJIGFzc3VtZSB0aGF0IHRoZSBzaXR1YXRpb24gaXMgdGhlIHNhbWUg Zm9yIG90aGVyIGNhcnJpZXJzIHVzaW5nIElNUy4NCg0KVGhhbmsgeW91DQpMYXVyYQ0KMjAxMy83 LzI5IEhhZHJpZWwgS2FwbGFuIDxoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPG1haWx0bzpoYWRy aWVsLmthcGxhbkBvcmFjbGUuY29tPj4NCg0KSSB0aGluayB0aGVyZSBuZWVkcyBzb21lIGRpc2N1 c3Npb24gYW5kIGp1c3RpZmljYXRpb24gZm9yIHdoeSB0aGUgc2Vzcy1pZCB2YWx1ZSBvcmRlci9w bGFjZW1lbnQgaXMgc3dhcHBlZCBpbiBTSVAgcmVzcG9uc2VzIGFuZCB1cHN0cmVhbSByZXF1ZXN0 cywgaW5zdGVhZCBvZiBiZWluZyBrZXB0IHRoZSBzYW1lIG9yZGVyIHRocm91Z2hvdXQuICBUaGlz IG9yZGVyLWNoYW5naW5nIGJyZWFrcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIG9s ZGVyIFNlc3Npb24tSUQgaW5kaXZpZHVhbCBkcmFmdCwgYW5kIGlzIGFyZ3VhYmx5IGhhcmRlciB0 byB1c2UvZmluZCBpbiBsb2dzIGFuZCB3aXJlc2hhcmsgZm9yIHRyb3VibGVzaG9vdGluZyBwdXJw b3Nlcy4gIEkgdGhpbmsgc29tZW9uZSBtZW50aW9uZWQgc29tZSByZWFzb24gdGhpcyByZS1vcmRl cmluZyB3YXMgbmVjZXNzYXJ5LCBidXQgSSBjYW4ndCByZWNhbGwgd2hhdCBpdCBpcyBhbmQgSSBk b24ndCBzZWUgaXQgZXhwbGFpbmVkIGluIHRoZSBkcmFmdC4NCg0KLWhhZHJpZWwNCg0KDQpPbiBK dWwgOCwgMjAxMywgYXQgODo0MSBQTSwgIkRSQUdFLCBLZWl0aCAoS2VpdGgpIiA8a2VpdGguZHJh Z2VAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5j b20+PiB3cm90ZToNCg0KPiAoQXMgV0cgY29jaGFpcikNCj4NCj4gQXMgd2VsbCBhcyByZXZpZXdp bmcgdGhlIGRvY3VtZW50IGdlbmVyYWxseSwgaXQgd291bGQgYmUgdXNlZnVsIGlmIHRoZSBXRyBt ZW1iZXJzaGlwIGNvdWxkIGluZGljYXRlIGFueSBpc3N1ZXMgdGhleSB0aGluayBuZWVkIGZhY2Ug dG8gZmFjZSBkaXNjdXNzaW9uIHRpbWUgaW4gQmVybGluLg0KPg0KPiBPciBpcyBldmVyeXRoaW5n IGdvaW5nIHBlcmZlY3RseT8NCj4NCj4gQXBhcnQgZnJvbSB3aGF0IGlzIGxpc3RlZCBiZWxvdywg aXMgYW55dGhpbmcgZWxzZSBtaXNzaW5nIGZyb20gdGhlIGRvY3VtZW50Pw0KPg0KPiBSZWdhcmRz DQo+DQo+IEtlaXRoDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTog aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppbnNpcGlkLWJvdW5jZXNA aWV0Zi5vcmc+XSBPbiBCZWhhbGYNCj4+IE9mIFBhdWwgRS4gSm9uZXMNCj4+IFNlbnQ6IDA5IEp1 bHkgMjAxMyAwMDoxNw0KPj4gVG86IGluc2lwaWRAaWV0Zi5vcmc8bWFpbHRvOmluc2lwaWRAaWV0 Zi5vcmc+DQo+PiBTdWJqZWN0OiBbSW5zaXBpZF0gZHJhZnQtaWV0Zi1pbnNpcGlkLXNlc3Npb24t aWQtMDENCj4+DQo+PiBGb2xrcywNCj4+DQo+PiBJIHBvc3RlZCBhIG5ldyB2ZXJzaW9uIG9mIGRy YWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9uLWlkIGZvciB5b3VyDQo+PiBjb25zaWRlcmF0aW9uLg0K Pj4NCj4+IE9uZSBzaWduaWZpY2FudCBhZGRpdGlvbiBpcyBvbmUgdG8gYWRkcmVzcyBhIGNvbW1l bnQgTGF1cmEgaGFkIGFib3V0DQo+PiBlbnN1cmluZyB0aGF0IGludGVybWVkaWFyeSBkZXZpY2Vz IGNhbiBjb25zaXN0ZW50bHkgcmUtY3JlYXRlIGEgVVVJRCBhbmQNCj4+IHJlbWFpbiBzdGF0ZWxl c3MuICBOZXcgdGV4dCBpcyBpbnRyb2R1Y2VkIGluIFNlY3Rpb24gNC4xIHRoYXQgZGVzY3JpYmVz DQo+PiBob3cNCj4+IHN1Y2ggZW50aXRpZXMgY2FuIGNvbnN0cnVjdCB0aGUgVVVJRHMuDQo+Pg0K Pj4gU2VjdGlvbiA2IHdhcyBhbHNvIHJldmlzZWQgd2l0aCB0ZXh0IHRvIGV4cGxhaW4gdGhhdCB0 aGUgVVVJRCBvcmRlcg0KPj4gcmVsYXRlcw0KPj4gdG8gd2hvIHNlbmRzIHRoZSBtZXNzYWdlLiAg SXQgYWxzbyBkaXNjdXNzZXMgdGhlIGxvbmdldml0eSBvZiB0aGUgVVVJRCwNCj4+IGxvZ2dpbmcs IGFuZCBjaGFuZ2VzIHRvIHRoZSAicmVtb3RlIiBVVUlELg0KPj4NCj4+IFByZXZpb3VzbHksIHJl cXVlc3RzIHdlcmUgbWFkZSBmb3IgYWRkaXRpb25hbCBjYWxsIGZsb3dzLiAgVGhvc2Ugd2VyZSBu b3QNCj4+IGFkZGVkIHRvIHRoZSBkb2N1bWVudCwgIGJ1dCB0aGUgcmVxdWVzdHMgYXJlIGxpc3Rl ZCBhcyBUT0RPIGl0ZW1zIGluDQo+PiBzZWN0aW9uKHMpIHVuZGVyIHNlY3Rpb24gOS4gIFRoZXJl IGlzIGFsc28gYSBUT0RPIGZvciBzZWN0aW9uIDkgcmVsYXRlZCB0bw0KPj4gcmVxdWVzdGVkIGNo YW5nZXMgdG8gc2VjdGlvbiA5IHRvIG1ha2UgaXQgY2xlYXJlZCB0aGUgdGV4dCBpcyBqdXN0DQo+ PiBleGFtcGxlcy4NCj4+DQo+PiBQYXVsDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBpbnNpcGlkIG1haWxpbmcgbGlzdA0KPj4g aW5zaXBpZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpbnNpcGlkIG1haWxpbmcgbGlzdA0KPiBp bnNpcGlkQGlldGYub3JnPG1haWx0bzppbnNpcGlkQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmluc2lwaWQgbWFpbGluZyBsaXN0DQppbnNpcGlk QGlldGYub3JnPG1haWx0bzppbnNpcGlkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pbnNpcGlkDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Np b24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3Rl Y3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVn ZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmlu dGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KKioqKiogRGlzY2xhaW1lciAq KioqKg0KaHR0cDovL3d3dy5iZWxnYWNvbS5iZS9tYWlsZGlzY2xhaW1lcg0K --_000_1E97FFD1485F1142BC075FF145A53A1E312C48A04067BGCNET_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hfQ0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiJ9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZX0NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIn0NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIn0NCnNwYW4uaG9lbnpiDQoJ e30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RH0NCnNwYW4uRW1haWxTdHlsZTIxDQoJe2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RH0NCnNwYW4uRW1haWxTdHlsZTIy DQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RH0N Ci5Nc29DaHBEZWZhdWx0DQoJe2ZvbnQtc2l6ZToxMC4wcHR9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdH0NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7fQ0KLS0+DQo8L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0Qi Pkkgc3VwcG9ydCDigJxub3QgYnJlYWtpbmcgdGhlIEJXIGNvbXBhdGliaWxpdHnigJ08L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsg Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPlNvJm5ic3A7ICYjNDM7 MTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsdWUiPkphbiBWYW4gR2VlbDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6Ymx1ZSI+DQo8YnI+DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsdWUiPklUIGFuZCBOZXR3b3JrIFNwZWNpYWxp c3Q8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6Ymx1ZSI+DQo8YnI+ DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsdWUiPkJlbGdhY29t IENJUy9TQ0MvRlZDPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJs dWUiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibHVl Ij5UZWw6ICYjNDM7MzIgMiAyMDIgMTAzNTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7OyBjb2xvcjpibHVlIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsgY29sb3I6Ymx1ZSI+VGVsOiAmIzQzOzMyIDIgMjA3IDkwMzI8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6Ymx1ZSI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsdWUiPkVtYWlsIDoNCjxhIGhyZWY9Im1haWx0bzpqYW4u dmFuLmdlZWxAYmVsZ2Fjb20uYmUiPmphbi52YW4uZ2VlbEBiZWxnYWNvbS5iZTwvYT48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6Ymx1ZSI+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsg Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0OyBwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaW5zaXBpZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5ET0xMWSwgTUFS VElOIEM8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSAzMCBKdWx5IDIwMTMgMTY6NTI8YnI+DQo8 Yj5Ubzo8L2I+IEF0bGUgTW9ucmFkOyBBbmRyZXcgQWxsZW47IGxhdXJhLmxpZXNzLmR0QGdvb2ds ZW1haWwuY29tOyBoYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPGJyPg0KPGI+Q2M6PC9iPiBrZWl0 aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb207IGluc2lwaWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtJbnNpcGlkXSBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC0wMTwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiYjNDM7MS41PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lOyBib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRm Lm9yZyI+aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmluc2lw aWQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkF0bGUgTW9ucmFkPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIEp1bHkgMzAsIDIwMTMgMTA6MzYgQU08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJldyBBbGxlbjsg PGEgaHJlZj0ibWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tIj5sYXVyYS5saWVz cy5kdEBnb29nbGVtYWlsLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86aGFkcmllbC5rYXBsYW5A b3JhY2xlLmNvbSI+aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbTwvYT48YnI+DQo8Yj5DYzo8L2I+ IDxhIGhyZWY9Im1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20iPmtlaXRoLmRy YWdlQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86aW5zaXBpZEBpZXRm Lm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJbnNp cGlkXSBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC0wMTwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+SGk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+SeKA mWQgbGlrZSB0byB0ZWFtIHVwIHdpdGggSGFkcmllbCwgTGF1cmEsIFJvbGFuZCBhbmQgQW5kcmV3 IG9uIHRoZSBzdXBwb3J0IGZvciBub3QgYnJlYWtpbmcgdGhlIEJXIGNvbXBhdGliaWxpdHkuPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGNvbG9yOiMxRjQ5N0QiPnRoYW5rczwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+ L2F0bGU8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3 RCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8Yj5BdGxlIE1vbnJhZDwvYj48YnI+DQozR1BQIENUIENoYWlybWFuPGJyPg0KPGJy Pg0KR3JvdXAgRnVuY3Rpb24gVGVjaG5vbG9neSDigJMgU3RhbmRhcmRpemF0aW9uIGFuZCBUZWNo bmljYWwgUmVndWxhdGlvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7IGNvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+PGJyPg0KRXJpY3Nzb248L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7IGJvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDsgcGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86aW5zaXBpZC1ib3VuY2VzQGll dGYub3JnIj5pbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86aW5z aXBpZC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmV3IEFsbGVuPGJyPg0KPGI+U2VudDo8L2I+IDMw LiBqdWxpIDIwMTMgMTY6Mjg8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpsYXVyYS5s aWVzcy5kdEBnb29nbGVtYWlsLmNvbSI+bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb208L2E+ Ow0KPGEgaHJlZj0ibWFpbHRvOmhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20iPmhhZHJpZWwua2Fw bGFuQG9yYWNsZS5jb208L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86a2VpdGgu ZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tIj5rZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmluc2lwaWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSW5zaXBpZF0gZHJhZnQtaWV0Zi1pbnNpcGlk LXNlc3Npb24taWQtMDE8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OiMxRjQ5N0QiPjxicj4NCkkgYWxzbyBjb25jdXIgd2l0aCBMYXVyYSdzIHJlY29sbGVjdGlvbi4g VGhhdCBhZ3JlZW1lbnQgd2FzIHRoZSBiYXNpcyB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgSm9u ZXMgZHJhZnQgYXMgdGhlIFdHIGRyYWZ0Ljxicj4NCjxicj4NCkFuZHJldzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KJm5ic3A7PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lOyBib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+OiBMYXVyYSBMaWVzcyBbPGEgaHJlZj0ibWFpbHRvOmxhdXJhLmxp ZXNzLmR0QGdvb2dsZW1haWwuY29tIj5tYWlsdG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDwvYj46IFR1ZXNkYXksIEp1bHkgMzAsIDIwMTMgMDY6MTgg QU0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBIYWRyaWVsIEthcGxhbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb20iPmhhZHJpZWwua2Fw bGFuQG9yYWNsZS5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+Q2M8L2I+OiBEUkFHRSwgS2VpdGggKEtl aXRoKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbSI+ a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0 bzppbnNpcGlkQGlldGYub3JnIj5pbnNpcGlkQGlldGYub3JnPC9hPiZndDsNCjxicj4NCjxiPlN1 YmplY3Q8L2I+OiBSZTogW0luc2lwaWRdIGRyYWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9uLWlkLTAx IDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+SSBhZ3JlZSB3aXRoIEhhZHJpZWwuJm5ic3A7IElmIEkgcmVtZW1iZXIg Y29ycmVjdGx5LCB3ZSBoYWQgYW4gYWdyZWVtZW50IGluIHRoZSBXRyB0aGF0IHRoZSBpZGVudGlm aWVyIGRlZmluZWQgaGVyZSBoYXMgdG8gYmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIHRoZSBz ZXNzaW9uLWlkIGlkZW50aWZpZXIgZGVmaW5lZCBpbiBIYWRyaWVsJ3MNCiBkcmFmdCBhbmQgdGhh dCBhIHJlZmVyZW5jZSB0byB0aGlzIGRyYWZ0IGhhcyB0byBiZSBhZGRlZC4gPGJyPg0KPGJyPg0K QmFja3dhcmQgaW5jb21wYXRpYmlsaXR5IHdpdGggSGFkcmllbCdzIHNlc3Npb24taWQgd291bGQg YmUgYSBiaWcgZHJhd2JhY2sgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgbmV3IGlkZW50 aWZpZXIgd2l0aGluIGNhcnJpZXIgbmV0d29ya3MuIENhcnJpZXJzIGFzIG15IGVtcGxveWVyLCB3 aGVyZSBIYWRyaWVsJ3Mgc2Vzc2lvbi1pZCBpcyBhbHJlYWR5IGltcGxlbWVudGVkLCB3aWxsIG5l dmVyIHN3aXRjaCB0byB0aGUgbmV3IGlkZW50aWZpZXIuDQogVGhleSB3aWxsIHJlcXVpcmUgdGhl IG9sZCBpZGVudGlmaWVyIGZvciBhbnkgbmV3IHN5c3RlbXMgdGhleSBidXksIGluY2x1ZGluZyBj b25mZXJlbmNpbmcgc3lzdGVtcy4NCjxicj4NCjxicj4NCkJlY2F1c2UgSGFkcmllbCdzIHNlc3Np b24taWQgaXMgdXNlZCBpbiB0aGUgM0dQUCBJTVMgc3BlY2lmaWNhdGlvcywgSSBhc3N1bWUgdGhh dCB0aGUgc2l0dWF0aW9uIGlzIHRoZSBzYW1lIGZvciBvdGhlciBjYXJyaWVycyB1c2luZyBJTVMu DQo8YnI+DQo8YnI+DQpUaGFuayB5b3U8YnI+DQpMYXVyYSAmbmJzcDsgJm5ic3A7IDwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjIwMTMv Ny8yOSBIYWRyaWVsIEthcGxhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhZHJpZWwua2FwbGFuQG9y YWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5oYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPC9hPiZn dDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NCkkgdGhpbmsgdGhlcmUgbmVlZHMgc29tZSBkaXNjdXNzaW9uIGFuZCBqdXN0aWZpY2F0aW9u IGZvciB3aHkgdGhlIHNlc3MtaWQgdmFsdWUgb3JkZXIvcGxhY2VtZW50IGlzIHN3YXBwZWQgaW4g U0lQIHJlc3BvbnNlcyBhbmQgdXBzdHJlYW0gcmVxdWVzdHMsIGluc3RlYWQgb2YgYmVpbmcga2Vw dCB0aGUgc2FtZSBvcmRlciB0aHJvdWdob3V0LiAmbmJzcDtUaGlzIG9yZGVyLWNoYW5naW5nIGJy ZWFrcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIG9sZGVyDQogU2Vzc2lvbi1JRCBp bmRpdmlkdWFsIGRyYWZ0LCBhbmQgaXMgYXJndWFibHkgaGFyZGVyIHRvIHVzZS9maW5kIGluIGxv Z3MgYW5kIHdpcmVzaGFyayBmb3IgdHJvdWJsZXNob290aW5nIHB1cnBvc2VzLiAmbmJzcDtJIHRo aW5rIHNvbWVvbmUgbWVudGlvbmVkIHNvbWUgcmVhc29uIHRoaXMgcmUtb3JkZXJpbmcgd2FzIG5l Y2Vzc2FyeSwgYnV0IEkgY2FuJ3QgcmVjYWxsIHdoYXQgaXQgaXMgYW5kIEkgZG9uJ3Qgc2VlIGl0 IGV4cGxhaW5lZCBpbiB0aGUgZHJhZnQuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi Pjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi1oYWRyaWVsPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PGJyPg0KPGJyPg0KT24gSnVsIDgsIDIwMTMsIGF0IDg6NDEgUE0sICZxdW90O0RSQUdFLCBL ZWl0aCAoS2VpdGgpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2VpdGguZHJhZ2VAYWxjYXRl bC1sdWNlbnQuY29tIj5rZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQomZ3Q7IChBcyBXRyBjb2NoYWlyKTxicj4NCiZndDs8YnI+DQomZ3Q7IEFz IHdlbGwgYXMgcmV2aWV3aW5nIHRoZSBkb2N1bWVudCBnZW5lcmFsbHksIGl0IHdvdWxkIGJlIHVz ZWZ1bCBpZiB0aGUgV0cgbWVtYmVyc2hpcCBjb3VsZCBpbmRpY2F0ZSBhbnkgaXNzdWVzIHRoZXkg dGhpbmsgbmVlZCBmYWNlIHRvIGZhY2UgZGlzY3Vzc2lvbiB0aW1lIGluIEJlcmxpbi48YnI+DQom Z3Q7PGJyPg0KJmd0OyBPciBpcyBldmVyeXRoaW5nIGdvaW5nIHBlcmZlY3RseT88YnI+DQomZ3Q7 PGJyPg0KJmd0OyBBcGFydCBmcm9tIHdoYXQgaXMgbGlzdGVkIGJlbG93LCBpcyBhbnl0aGluZyBl bHNlIG1pc3NpbmcgZnJvbSB0aGUgZG9jdW1lbnQ/PGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJk czxicj4NCiZndDs8YnI+DQomZ3Q7IEtlaXRoPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRv Omluc2lwaWQtYm91bmNlc0BpZXRmLm9yZyI+aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPC9hPiBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmciPmluc2lwaWQt Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZjxicj4NCiZndDsmZ3Q7IE9mIFBhdWwgRS4g Sm9uZXM8YnI+DQomZ3Q7Jmd0OyBTZW50OiAwOSBKdWx5IDIwMTMgMDA6MTc8YnI+DQomZ3Q7Jmd0 OyBUbzogPGEgaHJlZj0ibWFpbHRvOmluc2lwaWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsgU3ViamVjdDogW0luc2lwaWRdIGRyYWZ0LWlldGYtaW5zaXBpZC1z ZXNzaW9uLWlkLTAxPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBGb2xrcyw8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1p bnNpcGlkLXNlc3Npb24taWQgZm9yIHlvdXI8YnI+DQomZ3Q7Jmd0OyBjb25zaWRlcmF0aW9uLjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT25lIHNpZ25pZmljYW50IGFkZGl0aW9uIGlzIG9u ZSB0byBhZGRyZXNzIGEgY29tbWVudCBMYXVyYSBoYWQgYWJvdXQ8YnI+DQomZ3Q7Jmd0OyBlbnN1 cmluZyB0aGF0IGludGVybWVkaWFyeSBkZXZpY2VzIGNhbiBjb25zaXN0ZW50bHkgcmUtY3JlYXRl IGEgVVVJRCBhbmQ8YnI+DQomZ3Q7Jmd0OyByZW1haW4gc3RhdGVsZXNzLiAmbmJzcDtOZXcgdGV4 dCBpcyBpbnRyb2R1Y2VkIGluIFNlY3Rpb24gNC4xIHRoYXQgZGVzY3JpYmVzPGJyPg0KJmd0OyZn dDsgaG93PGJyPg0KJmd0OyZndDsgc3VjaCBlbnRpdGllcyBjYW4gY29uc3RydWN0IHRoZSBVVUlE cy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNlY3Rpb24gNiB3YXMgYWxzbyByZXZpc2Vk IHdpdGggdGV4dCB0byBleHBsYWluIHRoYXQgdGhlIFVVSUQgb3JkZXI8YnI+DQomZ3Q7Jmd0OyBy ZWxhdGVzPGJyPg0KJmd0OyZndDsgdG8gd2hvIHNlbmRzIHRoZSBtZXNzYWdlLiAmbmJzcDtJdCBh bHNvIGRpc2N1c3NlcyB0aGUgbG9uZ2V2aXR5IG9mIHRoZSBVVUlELDxicj4NCiZndDsmZ3Q7IGxv Z2dpbmcsIGFuZCBjaGFuZ2VzIHRvIHRoZSAmcXVvdDtyZW1vdGUmcXVvdDsgVVVJRC48YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFByZXZpb3VzbHksIHJlcXVlc3RzIHdlcmUgbWFkZSBmb3Ig YWRkaXRpb25hbCBjYWxsIGZsb3dzLiAmbmJzcDtUaG9zZSB3ZXJlIG5vdDxicj4NCiZndDsmZ3Q7 IGFkZGVkIHRvIHRoZSBkb2N1bWVudCwgJm5ic3A7YnV0IHRoZSByZXF1ZXN0cyBhcmUgbGlzdGVk IGFzIFRPRE8gaXRlbXMgaW48YnI+DQomZ3Q7Jmd0OyBzZWN0aW9uKHMpIHVuZGVyIHNlY3Rpb24g OS4gJm5ic3A7VGhlcmUgaXMgYWxzbyBhIFRPRE8gZm9yIHNlY3Rpb24gOSByZWxhdGVkIHRvPGJy Pg0KJmd0OyZndDsgcmVxdWVzdGVkIGNoYW5nZXMgdG8gc2VjdGlvbiA5IHRvIG1ha2UgaXQgY2xl YXJlZCB0aGUgdGV4dCBpcyBqdXN0PGJyPg0KJmd0OyZndDsgZXhhbXBsZXMuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBQYXVsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsgaW5zaXBpZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lu c2lwaWQ8L2E+PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgaW5zaXBpZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzppbnNpcGlkQGlldGYub3JnIj5pbnNpcGlkQGlldGYub3JnPC9hPjxicj4NCiZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlk IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p bnNpcGlkPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KaW5zaXBpZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQ8L2E+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21pc3Np b24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3Rl Y3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVn ZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbg0KIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGll bnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uDQogYnkg dW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuIDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBj b2xvcj0iQmx1ZSIgc2l6ZT0iMiI+PGJyPg0KKioqKiogRGlzY2xhaW1lciAqKioqKjxicj4NCmh0 dHA6Ly93d3cuYmVsZ2Fjb20uYmUvbWFpbGRpc2NsYWltZXI8YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_1E97FFD1485F1142BC075FF145A53A1E312C48A04067BGCNET_-- From rjsparks@nostrum.com Wed Jul 31 00:18:02 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3FD21E8090 for ; Wed, 31 Jul 2013 00:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIZ+MAO4o4Qm for ; Wed, 31 Jul 2013 00:18:01 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB5C021E8051 for ; Wed, 31 Jul 2013 00:18:00 -0700 (PDT) Received: from dhcp-632b.meeting.ietf.org (dhcp-632b.meeting.ietf.org [130.129.99.43]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6V7HwTw046268 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Wed, 31 Jul 2013 02:17:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51F8BA2B.3030100@nostrum.com> Date: Wed, 31 Jul 2013 09:18:03 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: insipid@ietf.org References: <51F7A26B.1000704@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 130.129.99.43 is authenticated by a trusted mechanism) Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:18:02 -0000 On 7/30/13 9:38 PM, Hadriel Kaplan wrote: > Uhhh... just to be clear, I was making an individual comment in that email, not a corporate position statement or any some such. > > My point was that since the use-cases people are planning to do for INSIPID's Session-ID have now gone far beyond troubleshooting, the odds are we can't rely on it always being passed through end-to-end from originating Enterprises through various service providers to the far-end, without being modified in-transit. I can't *prove* it won't be, but that's just my hunch, since we've seen this movie play out before. > > The good news is we don't need the Session-ID to be used in STIR for caller-id verification, so there's nothing to worry about. Hadriel - This wasn't a question about STIR, it was a question about the publication of this INSIPID document. Look again at the requirement called out from the document below. Is your assertion that the proposed solution is not going to satisfy that requirement, or are you saying there's a problem with this requirement document being inconsistent (by requiring things that won't pass unchanged through intermediaries). If the latter, please re-engage the working group and fix the document (you are on the author list). RjS > :) > > -hadriel > > > On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> I just got a publication request for the requirements document: >> >> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 >> >> The following is one of the requirements in the draft, which was one of >> the main reasons for creating this WG: >> >>> REQ3: The solution must require that the identifier, if present, pass >>> unchanged through SIP B2BUAs or other intermediaries. >> Hadriel, who works for an important SBC vendor and is one of the authors >> of the requirements document, sent the comments below to the STIR list a >> couple of weeks ago (see email below). >> >> How should I interpret those comments in the context of my AD review of >> this document and, even more importantly, as the responsible AD for this >> WG (as you know, we have had many scope-related discussions in the past)? >> >> Thanks, >> >> Gonzalo >> >> >> -------- Original Message -------- >> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) >> Date: Tue, 16 Jul 2013 10:21:13 -0400 >> From: Hadriel Kaplan >> To: Richard Shockey >> CC: IETF STIR Mail List >> >> >> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" wrote: >> >>> I actually believe INSIPID is equally important to the overall task >> since it >>> is the track and trace elements of this that can ultimately enable some >>> enforcement. I wish there was some more discussion on how the mechanisms >>> would work at the edge SIP/SS7 network gateways since that clearly has >> been >>> the center of most of the reported problems. I still think something >> needs >>> to be done to police that traffic but that is still ultimately a >> regulatory >>> effort. >> I agree we need a tracking/tracing mechanism, but in my opinion we >> cannot and should not rely on INSIPID Session-ID at all for that. They >> have gone beyond benign troubleshooting-type purposes now, which means >> there is absolutely no guarantee the Session-ID will make it intact >> across service providers in all cases. In fact, my hunch is it won't. >> >> Regardless, the Session-ID isn't what we really need for tracing a bad >> caller-id call. Even without Session-ID, the service provider's CDRs or >> logs can be used to trace it back to the peering connection and peer >> upstream provider the call came in from. What we also need is a list of >> SPIDs the call request has crossed through, so we can trace it back >> further upstream. Kinda like a Via header, but with very different >> properties and purpose. We've talked about doing that before, back when >> there was talk about creating a registry of SPIDs. What ever happened >> to having a registry of SPIDs? >> >> -hadriel >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Wed Jul 31 00:37:43 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D917921E8127 for ; Wed, 31 Jul 2013 00:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.651 X-Spam-Level: X-Spam-Status: No, score=-110.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDvSEFEEO4ek for ; Wed, 31 Jul 2013 00:37:37 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8121E811F for ; Wed, 31 Jul 2013 00:37:37 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6V7bWSL007653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 Jul 2013 02:37:34 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6V7bQTd027616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 09:37:32 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 31 Jul 2013 09:37:29 +0200 From: "DRAGE, Keith (Keith)" To: Robert Sparks , "insipid@ietf.org" , Gonzalo Camarillo Thread-Topic: [Insipid] Will the identifier pass unchanged through B2BUAs? Thread-Index: AQHOjReO8cw2BxP87EWgI7e79yRYZ5l9fRcAgADDY4CAACXZQA== Date: Wed, 31 Jul 2013 07:37:28 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0784C2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> In-Reply-To: <51F8BA2B.3030100@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:37:44 -0000 I am getting very confused here. Is there a problem with this requirement in the requirements document? If not, then lets move on with the requirements document. Is there a problem with the solutions document? If so it is a working group item - make sure it contains what the working g= roup wants. The original authors no longer have responsibility for the tech= nical direction, only for making sure it contains what the working group wa= nts. Hadriel may be on the author list, but you are a member of the working= group. Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Robert Sparks > Sent: 31 July 2013 08:18 > To: insipid@ietf.org > Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? >=20 > On 7/30/13 9:38 PM, Hadriel Kaplan wrote: > > Uhhh... just to be clear, I was making an individual comment in that > email, not a corporate position statement or any some such. > > > > My point was that since the use-cases people are planning to do for > INSIPID's Session-ID have now gone far beyond troubleshooting, the odds > are we can't rely on it always being passed through end-to-end from > originating Enterprises through various service providers to the far-end, > without being modified in-transit. I can't *prove* it won't be, but > that's just my hunch, since we've seen this movie play out before. > > > > The good news is we don't need the Session-ID to be used in STIR for > caller-id verification, so there's nothing to worry about. > Hadriel - >=20 > This wasn't a question about STIR, it was a question about the > publication of this INSIPID document. >=20 > Look again at the requirement called out from the document below. >=20 > Is your assertion that the proposed solution is not going to satisfy > that requirement, or are you saying there's a problem with this > requirement document being inconsistent (by requiring things that won't > pass unchanged through intermediaries). If the latter, please re-engage > the working group and fix the document (you are on the author list). >=20 > RjS > > :) > > > > -hadriel > > > > > > On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo > wrote: > > > >> Hi, > >> > >> I just got a publication request for the requirements document: > >> > >> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 > >> > >> The following is one of the requirements in the draft, which was one o= f > >> the main reasons for creating this WG: > >> > >>> REQ3: The solution must require that the identifier, if present, > pass > >>> unchanged through SIP B2BUAs or other intermediaries. > >> Hadriel, who works for an important SBC vendor and is one of the > authors > >> of the requirements document, sent the comments below to the STIR list > a > >> couple of weeks ago (see email below). > >> > >> How should I interpret those comments in the context of my AD review o= f > >> this document and, even more importantly, as the responsible AD for > this > >> WG (as you know, we have had many scope-related discussions in the > past)? > >> > >> Thanks, > >> > >> Gonzalo > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR > Charter) > >> Date: Tue, 16 Jul 2013 10:21:13 -0400 > >> From: Hadriel Kaplan > >> To: Richard Shockey > >> CC: IETF STIR Mail List > >> > >> > >> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" > wrote: > >> > >>> I actually believe INSIPID is equally important to the overall task > >> since it > >>> is the track and trace elements of this that can ultimately enable > some > >>> enforcement. I wish there was some more discussion on how the > mechanisms > >>> would work at the edge SIP/SS7 network gateways since that clearly ha= s > >> been > >>> the center of most of the reported problems. I still think something > >> needs > >>> to be done to police that traffic but that is still ultimately a > >> regulatory > >>> effort. > >> I agree we need a tracking/tracing mechanism, but in my opinion we > >> cannot and should not rely on INSIPID Session-ID at all for that. The= y > >> have gone beyond benign troubleshooting-type purposes now, which means > >> there is absolutely no guarantee the Session-ID will make it intact > >> across service providers in all cases. In fact, my hunch is it won't. > >> > >> Regardless, the Session-ID isn't what we really need for tracing a bad > >> caller-id call. Even without Session-ID, the service provider's CDRs > or > >> logs can be used to trace it back to the peering connection and peer > >> upstream provider the call came in from. What we also need is a list > of > >> SPIDs the call request has crossed through, so we can trace it back > >> further upstream. Kinda like a Via header, but with very different > >> properties and purpose. We've talked about doing that before, back > when > >> there was talk about creating a registry of SPIDs. What ever happened > >> to having a registry of SPIDs? > >> > >> -hadriel > >> > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir > >> > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From rjsparks@nostrum.com Wed Jul 31 00:47:09 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF51021E8111 for ; Wed, 31 Jul 2013 00:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otUp8HVckGrL for ; Wed, 31 Jul 2013 00:47:08 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4821E8132 for ; Wed, 31 Jul 2013 00:47:07 -0700 (PDT) Received: from dhcp-632b.meeting.ietf.org (dhcp-632b.meeting.ietf.org [130.129.99.43]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6V7l2sG049284 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 02:47:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51F8C0FA.1090505@nostrum.com> Date: Wed, 31 Jul 2013 09:47:06 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B0784C2@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0784C2@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 130.129.99.43 is authenticated by a trusted mechanism) Cc: "insipid@ietf.org" , Gonzalo Camarillo Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:47:09 -0000 On 7/31/13 9:37 AM, DRAGE, Keith (Keith) wrote: > I am getting very confused here. > > Is there a problem with this requirement in the requirements document? That's the question. More specifically, is this requirement conflicting with some other requirement in this document? Is Hadriel's comment below saying the group is requiring a solution that won't work, or is he saying the proposed solution doesn't meet the requirements? > > If not, then lets move on with the requirements document. > > Is there a problem with the solutions document? > > If so it is a working group item - make sure it contains what the working group wants. The original authors no longer have responsibility for the technical direction, only for making sure it contains what the working group wants. Hadriel may be on the author list, but you are a member of the working group. > > Regards > > Keith > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Robert Sparks >> Sent: 31 July 2013 08:18 >> To: insipid@ietf.org >> Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? >> >> On 7/30/13 9:38 PM, Hadriel Kaplan wrote: >>> Uhhh... just to be clear, I was making an individual comment in that >> email, not a corporate position statement or any some such. >>> My point was that since the use-cases people are planning to do for >> INSIPID's Session-ID have now gone far beyond troubleshooting, the odds >> are we can't rely on it always being passed through end-to-end from >> originating Enterprises through various service providers to the far-end, >> without being modified in-transit. I can't *prove* it won't be, but >> that's just my hunch, since we've seen this movie play out before. >>> The good news is we don't need the Session-ID to be used in STIR for >> caller-id verification, so there's nothing to worry about. >> Hadriel - >> >> This wasn't a question about STIR, it was a question about the >> publication of this INSIPID document. >> >> Look again at the requirement called out from the document below. >> >> Is your assertion that the proposed solution is not going to satisfy >> that requirement, or are you saying there's a problem with this >> requirement document being inconsistent (by requiring things that won't >> pass unchanged through intermediaries). If the latter, please re-engage >> the working group and fix the document (you are on the author list). >> >> RjS >>> :) >>> >>> -hadriel >>> >>> >>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo >> wrote: >>>> Hi, >>>> >>>> I just got a publication request for the requirements document: >>>> >>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 >>>> >>>> The following is one of the requirements in the draft, which was one of >>>> the main reasons for creating this WG: >>>> >>>>> REQ3: The solution must require that the identifier, if present, >> pass >>>>> unchanged through SIP B2BUAs or other intermediaries. >>>> Hadriel, who works for an important SBC vendor and is one of the >> authors >>>> of the requirements document, sent the comments below to the STIR list >> a >>>> couple of weeks ago (see email below). >>>> >>>> How should I interpret those comments in the context of my AD review of >>>> this document and, even more importantly, as the responsible AD for >> this >>>> WG (as you know, we have had many scope-related discussions in the >> past)? >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR >> Charter) >>>> Date: Tue, 16 Jul 2013 10:21:13 -0400 >>>> From: Hadriel Kaplan >>>> To: Richard Shockey >>>> CC: IETF STIR Mail List >>>> >>>> >>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" >> wrote: >>>>> I actually believe INSIPID is equally important to the overall task >>>> since it >>>>> is the track and trace elements of this that can ultimately enable >> some >>>>> enforcement. I wish there was some more discussion on how the >> mechanisms >>>>> would work at the edge SIP/SS7 network gateways since that clearly has >>>> been >>>>> the center of most of the reported problems. I still think something >>>> needs >>>>> to be done to police that traffic but that is still ultimately a >>>> regulatory >>>>> effort. >>>> I agree we need a tracking/tracing mechanism, but in my opinion we >>>> cannot and should not rely on INSIPID Session-ID at all for that. They >>>> have gone beyond benign troubleshooting-type purposes now, which means >>>> there is absolutely no guarantee the Session-ID will make it intact >>>> across service providers in all cases. In fact, my hunch is it won't. >>>> >>>> Regardless, the Session-ID isn't what we really need for tracing a bad >>>> caller-id call. Even without Session-ID, the service provider's CDRs >> or >>>> logs can be used to trace it back to the peering connection and peer >>>> upstream provider the call came in from. What we also need is a list >> of >>>> SPIDs the call request has crossed through, so we can trace it back >>>> further upstream. Kinda like a Via header, but with very different >>>> properties and purpose. We've talked about doing that before, back >> when >>>> there was talk about creating a registry of SPIDs. What ever happened >>>> to having a registry of SPIDs? >>>> >>>> -hadriel >>>> >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>> >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Wed Jul 31 01:05:59 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A14021F9B11 for ; Wed, 31 Jul 2013 01:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.648 X-Spam-Level: X-Spam-Status: No, score=-110.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18kInxmnPoVe for ; Wed, 31 Jul 2013 01:05:53 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 84B5121F9B53 for ; Wed, 31 Jul 2013 01:05:52 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6V85kaB021627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 Jul 2013 03:05:47 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6V85jDW011295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 10:05:45 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 31 Jul 2013 10:05:45 +0200 From: "DRAGE, Keith (Keith)" To: Robert Sparks Thread-Topic: [Insipid] Will the identifier pass unchanged through B2BUAs? Thread-Index: AQHOjReO8cw2BxP87EWgI7e79yRYZ5l9fRcAgADDY4CAACXZQP//4kUAgAAlg4A= Date: Wed, 31 Jul 2013 08:05:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B078508@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B0784C2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <51F8C0FA.1090505@nostrum.com> In-Reply-To: <51F8C0FA.1090505@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "insipid@ietf.org" , Gonzalo Camarillo Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:05:59 -0000 > That's the question. More specifically, is this requirement conflicting > with some other requirement in this document? None of the comments so far have given me enough information to evaluate th= is. Can someone please elaborate. > Is Hadriel's comment below saying the group is requiring a solution that > won't work, or is he saying the proposed solution doesn't meet the > requirements? That is not necessarily a problem of the requirements document. If this occ= urs, the the solutions document in an informative place dealing with confor= mance to the requirements document will identify the inability to meet the = requirement and the reason why.=20 However, I do not have enough information to understand whether we will be = needing that or not, because I do not understand whether we have a problem. Regards Keith > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: 31 July 2013 08:47 > To: DRAGE, Keith (Keith) > Cc: insipid@ietf.org; Gonzalo Camarillo > Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? >=20 > On 7/31/13 9:37 AM, DRAGE, Keith (Keith) wrote: > > I am getting very confused here. > > > > Is there a problem with this requirement in the requirements document? > That's the question. More specifically, is this requirement conflicting > with some other requirement in this document? > Is Hadriel's comment below saying the group is requiring a solution that > won't work, or is he saying the proposed solution doesn't meet the > requirements? > > > > If not, then lets move on with the requirements document. > > > > Is there a problem with the solutions document? > > > > If so it is a working group item - make sure it contains what the > working group wants. The original authors no longer have responsibility > for the technical direction, only for making sure it contains what the > working group wants. Hadriel may be on the author list, but you are a > member of the working group. > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf > >> Of Robert Sparks > >> Sent: 31 July 2013 08:18 > >> To: insipid@ietf.org > >> Subject: Re: [Insipid] Will the identifier pass unchanged through > B2BUAs? > >> > >> On 7/30/13 9:38 PM, Hadriel Kaplan wrote: > >>> Uhhh... just to be clear, I was making an individual comment in that > >> email, not a corporate position statement or any some such. > >>> My point was that since the use-cases people are planning to do for > >> INSIPID's Session-ID have now gone far beyond troubleshooting, the odd= s > >> are we can't rely on it always being passed through end-to-end from > >> originating Enterprises through various service providers to the far- > end, > >> without being modified in-transit. I can't *prove* it won't be, but > >> that's just my hunch, since we've seen this movie play out before. > >>> The good news is we don't need the Session-ID to be used in STIR for > >> caller-id verification, so there's nothing to worry about. > >> Hadriel - > >> > >> This wasn't a question about STIR, it was a question about the > >> publication of this INSIPID document. > >> > >> Look again at the requirement called out from the document below. > >> > >> Is your assertion that the proposed solution is not going to satisfy > >> that requirement, or are you saying there's a problem with this > >> requirement document being inconsistent (by requiring things that won'= t > >> pass unchanged through intermediaries). If the latter, please re-engag= e > >> the working group and fix the document (you are on the author list). > >> > >> RjS > >>> :) > >>> > >>> -hadriel > >>> > >>> > >>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo > >> wrote: > >>>> Hi, > >>>> > >>>> I just got a publication request for the requirements document: > >>>> > >>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 > >>>> > >>>> The following is one of the requirements in the draft, which was one > of > >>>> the main reasons for creating this WG: > >>>> > >>>>> REQ3: The solution must require that the identifier, if present= , > >> pass > >>>>> unchanged through SIP B2BUAs or other intermediaries. > >>>> Hadriel, who works for an important SBC vendor and is one of the > >> authors > >>>> of the requirements document, sent the comments below to the STIR > list > >> a > >>>> couple of weeks ago (see email below). > >>>> > >>>> How should I interpret those comments in the context of my AD review > of > >>>> this document and, even more importantly, as the responsible AD for > >> this > >>>> WG (as you know, we have had many scope-related discussions in the > >> past)? > >>>> Thanks, > >>>> > >>>> Gonzalo > >>>> > >>>> > >>>> -------- Original Message -------- > >>>> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR > >> Charter) > >>>> Date: Tue, 16 Jul 2013 10:21:13 -0400 > >>>> From: Hadriel Kaplan > >>>> To: Richard Shockey > >>>> CC: IETF STIR Mail List > >>>> > >>>> > >>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" > >> wrote: > >>>>> I actually believe INSIPID is equally important to the overall task > >>>> since it > >>>>> is the track and trace elements of this that can ultimately enable > >> some > >>>>> enforcement. I wish there was some more discussion on how the > >> mechanisms > >>>>> would work at the edge SIP/SS7 network gateways since that clearly > has > >>>> been > >>>>> the center of most of the reported problems. I still think > something > >>>> needs > >>>>> to be done to police that traffic but that is still ultimately a > >>>> regulatory > >>>>> effort. > >>>> I agree we need a tracking/tracing mechanism, but in my opinion we > >>>> cannot and should not rely on INSIPID Session-ID at all for that. > They > >>>> have gone beyond benign troubleshooting-type purposes now, which > means > >>>> there is absolutely no guarantee the Session-ID will make it intact > >>>> across service providers in all cases. In fact, my hunch is it won'= t. > >>>> > >>>> Regardless, the Session-ID isn't what we really need for tracing a > bad > >>>> caller-id call. Even without Session-ID, the service provider's CDR= s > >> or > >>>> logs can be used to trace it back to the peering connection and peer > >>>> upstream provider the call came in from. What we also need is a lis= t > >> of > >>>> SPIDs the call request has crossed through, so we can trace it back > >>>> further upstream. Kinda like a Via header, but with very different > >>>> properties and purpose. We've talked about doing that before, back > >> when > >>>> there was talk about creating a registry of SPIDs. What ever > happened > >>>> to having a registry of SPIDs? > >>>> > >>>> -hadriel > >>>> > >>>> _______________________________________________ > >>>> stir mailing list > >>>> stir@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/stir > >>>> > >>>> _______________________________________________ > >>>> insipid mailing list > >>>> insipid@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/insipid > >>> _______________________________________________ > >>> insipid mailing list > >>> insipid@ietf.org > >>> https://www.ietf.org/mailman/listinfo/insipid > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid From rjsparks@nostrum.com Wed Jul 31 01:18:01 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ABC21F9017 for ; Wed, 31 Jul 2013 01:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y03yFvuqzYiJ for ; Wed, 31 Jul 2013 01:18:00 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 129EF21F8763 for ; Wed, 31 Jul 2013 01:17:14 -0700 (PDT) Received: from dhcp-632b.meeting.ietf.org (dhcp-632b.meeting.ietf.org [130.129.99.43]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6V8H6Wf054798 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 03:17:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51F8C807.1080801@nostrum.com> Date: Wed, 31 Jul 2013 10:17:11 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B0784C2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <51F8C0FA.1090505@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B078508@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B078508@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 130.129.99.43 is authenticated by a trusted mechanism) Cc: "insipid@ietf.org" , Gonzalo Camarillo Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:18:01 -0000 On 7/31/13 10:05 AM, DRAGE, Keith (Keith) wrote: >> That's the question. More specifically, is this requirement conflicting >> with some other requirement in this document? > None of the comments so far have given me enough information to evaluate this. Can someone please elaborate. That was the point of asking Hadriel for clarification. > >> Is Hadriel's comment below saying the group is requiring a solution that >> won't work, or is he saying the proposed solution doesn't meet the >> requirements? > That is not necessarily a problem of the requirements document. If this occurs, the the solutions document in an informative place dealing with conformance to the requirements document will identify the inability to meet the requirement and the reason why. > > However, I do not have enough information to understand whether we will be needing that or not, because I do not understand whether we have a problem. > > Regards > > Keith > > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: 31 July 2013 08:47 >> To: DRAGE, Keith (Keith) >> Cc: insipid@ietf.org; Gonzalo Camarillo >> Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? >> >> On 7/31/13 9:37 AM, DRAGE, Keith (Keith) wrote: >>> I am getting very confused here. >>> >>> Is there a problem with this requirement in the requirements document? >> That's the question. More specifically, is this requirement conflicting >> with some other requirement in this document? >> Is Hadriel's comment below saying the group is requiring a solution that >> won't work, or is he saying the proposed solution doesn't meet the >> requirements? >>> If not, then lets move on with the requirements document. >>> >>> Is there a problem with the solutions document? >>> >>> If so it is a working group item - make sure it contains what the >> working group wants. The original authors no longer have responsibility >> for the technical direction, only for making sure it contains what the >> working group wants. Hadriel may be on the author list, but you are a >> member of the working group. >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf >>>> Of Robert Sparks >>>> Sent: 31 July 2013 08:18 >>>> To: insipid@ietf.org >>>> Subject: Re: [Insipid] Will the identifier pass unchanged through >> B2BUAs? >>>> On 7/30/13 9:38 PM, Hadriel Kaplan wrote: >>>>> Uhhh... just to be clear, I was making an individual comment in that >>>> email, not a corporate position statement or any some such. >>>>> My point was that since the use-cases people are planning to do for >>>> INSIPID's Session-ID have now gone far beyond troubleshooting, the odds >>>> are we can't rely on it always being passed through end-to-end from >>>> originating Enterprises through various service providers to the far- >> end, >>>> without being modified in-transit. I can't *prove* it won't be, but >>>> that's just my hunch, since we've seen this movie play out before. >>>>> The good news is we don't need the Session-ID to be used in STIR for >>>> caller-id verification, so there's nothing to worry about. >>>> Hadriel - >>>> >>>> This wasn't a question about STIR, it was a question about the >>>> publication of this INSIPID document. >>>> >>>> Look again at the requirement called out from the document below. >>>> >>>> Is your assertion that the proposed solution is not going to satisfy >>>> that requirement, or are you saying there's a problem with this >>>> requirement document being inconsistent (by requiring things that won't >>>> pass unchanged through intermediaries). If the latter, please re-engage >>>> the working group and fix the document (you are on the author list). >>>> >>>> RjS >>>>> :) >>>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo >>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I just got a publication request for the requirements document: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 >>>>>> >>>>>> The following is one of the requirements in the draft, which was one >> of >>>>>> the main reasons for creating this WG: >>>>>> >>>>>>> REQ3: The solution must require that the identifier, if present, >>>> pass >>>>>>> unchanged through SIP B2BUAs or other intermediaries. >>>>>> Hadriel, who works for an important SBC vendor and is one of the >>>> authors >>>>>> of the requirements document, sent the comments below to the STIR >> list >>>> a >>>>>> couple of weeks ago (see email below). >>>>>> >>>>>> How should I interpret those comments in the context of my AD review >> of >>>>>> this document and, even more importantly, as the responsible AD for >>>> this >>>>>> WG (as you know, we have had many scope-related discussions in the >>>> past)? >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR >>>> Charter) >>>>>> Date: Tue, 16 Jul 2013 10:21:13 -0400 >>>>>> From: Hadriel Kaplan >>>>>> To: Richard Shockey >>>>>> CC: IETF STIR Mail List >>>>>> >>>>>> >>>>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" >>>> wrote: >>>>>>> I actually believe INSIPID is equally important to the overall task >>>>>> since it >>>>>>> is the track and trace elements of this that can ultimately enable >>>> some >>>>>>> enforcement. I wish there was some more discussion on how the >>>> mechanisms >>>>>>> would work at the edge SIP/SS7 network gateways since that clearly >> has >>>>>> been >>>>>>> the center of most of the reported problems. I still think >> something >>>>>> needs >>>>>>> to be done to police that traffic but that is still ultimately a >>>>>> regulatory >>>>>>> effort. >>>>>> I agree we need a tracking/tracing mechanism, but in my opinion we >>>>>> cannot and should not rely on INSIPID Session-ID at all for that. >> They >>>>>> have gone beyond benign troubleshooting-type purposes now, which >> means >>>>>> there is absolutely no guarantee the Session-ID will make it intact >>>>>> across service providers in all cases. In fact, my hunch is it won't. >>>>>> >>>>>> Regardless, the Session-ID isn't what we really need for tracing a >> bad >>>>>> caller-id call. Even without Session-ID, the service provider's CDRs >>>> or >>>>>> logs can be used to trace it back to the peering connection and peer >>>>>> upstream provider the call came in from. What we also need is a list >>>> of >>>>>> SPIDs the call request has crossed through, so we can trace it back >>>>>> further upstream. Kinda like a Via header, but with very different >>>>>> properties and purpose. We've talked about doing that before, back >>>> when >>>>>> there was talk about creating a registry of SPIDs. What ever >> happened >>>>>> to having a registry of SPIDs? >>>>>> >>>>>> -hadriel >>>>>> >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>> >>>>>> _______________________________________________ >>>>>> insipid mailing list >>>>>> insipid@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>> _______________________________________________ >>>>> insipid mailing list >>>>> insipid@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/insipid >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid From hadriel.kaplan@oracle.com Wed Jul 31 01:47:59 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB6621F93C4 for ; Wed, 31 Jul 2013 01:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shQwQ4yFwv8p for ; Wed, 31 Jul 2013 01:47:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 52F0421F9F20 for ; Wed, 31 Jul 2013 01:40:38 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6V8eIEq001227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 08:40:19 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6V8eG2f002655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 08:40:17 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6V8eGon010522; Wed, 31 Jul 2013 08:40:16 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jul 2013 01:40:16 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51F8BA2B.3030100@nostrum.com> Date: Wed, 31 Jul 2013 04:40:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: insipid@ietf.org Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:47:59 -0000 No, there's nothing wrong with the requirements document. My email = wasn't about the requirements document, nor addressed to INSIPID - it = was an email in the STIR mailing list related to using an INSIPID = Session-ID for caller-id verification purposes. That's all. The INSIPID requirements doc is fine. -hadriel On Jul 31, 2013, at 3:18 AM, Robert Sparks wrote: > On 7/30/13 9:38 PM, Hadriel Kaplan wrote: >> Uhhh... just to be clear, I was making an individual comment in that = email, not a corporate position statement or any some such. >>=20 >> My point was that since the use-cases people are planning to do for = INSIPID's Session-ID have now gone far beyond troubleshooting, the odds = are we can't rely on it always being passed through end-to-end from = originating Enterprises through various service providers to the = far-end, without being modified in-transit. I can't *prove* it won't = be, but that's just my hunch, since we've seen this movie play out = before. >>=20 >> The good news is we don't need the Session-ID to be used in STIR for = caller-id verification, so there's nothing to worry about. > Hadriel - >=20 > This wasn't a question about STIR, it was a question about the = publication of this INSIPID document. >=20 > Look again at the requirement called out from the document below. >=20 > Is your assertion that the proposed solution is not going to satisfy = that requirement, or are you saying there's a problem with this = requirement document being inconsistent (by requiring things that won't = pass unchanged through intermediaries). If the latter, please re-engage = the working group and fix the document (you are on the author list). >=20 > RjS >> :) >>=20 >> -hadriel >>=20 >>=20 >> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo = wrote: >>=20 >>> Hi, >>>=20 >>> I just got a publication request for the requirements document: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 >>>=20 >>> The following is one of the requirements in the draft, which was one = of >>> the main reasons for creating this WG: >>>=20 >>>> REQ3: The solution must require that the identifier, if present, = pass >>>> unchanged through SIP B2BUAs or other intermediaries. >>> Hadriel, who works for an important SBC vendor and is one of the = authors >>> of the requirements document, sent the comments below to the STIR = list a >>> couple of weeks ago (see email below). >>>=20 >>> How should I interpret those comments in the context of my AD review = of >>> this document and, even more importantly, as the responsible AD for = this >>> WG (as you know, we have had many scope-related discussions in the = past)? >>>=20 >>> Thanks, >>>=20 >>> Gonzalo >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR = Charter) >>> Date: Tue, 16 Jul 2013 10:21:13 -0400 >>> From: Hadriel Kaplan >>> To: Richard Shockey >>> CC: IETF STIR Mail List >>>=20 >>>=20 >>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" = wrote: >>>=20 >>>> I actually believe INSIPID is equally important to the overall task >>> since it >>>> is the track and trace elements of this that can ultimately enable = some >>>> enforcement. I wish there was some more discussion on how the = mechanisms >>>> would work at the edge SIP/SS7 network gateways since that clearly = has >>> been >>>> the center of most of the reported problems. I still think = something >>> needs >>>> to be done to police that traffic but that is still ultimately a >>> regulatory >>>> effort. >>> I agree we need a tracking/tracing mechanism, but in my opinion we >>> cannot and should not rely on INSIPID Session-ID at all for that. = They >>> have gone beyond benign troubleshooting-type purposes now, which = means >>> there is absolutely no guarantee the Session-ID will make it intact >>> across service providers in all cases. In fact, my hunch is it = won't. >>>=20 >>> Regardless, the Session-ID isn't what we really need for tracing a = bad >>> caller-id call. Even without Session-ID, the service provider's = CDRs or >>> logs can be used to trace it back to the peering connection and peer >>> upstream provider the call came in from. What we also need is a = list of >>> SPIDs the call request has crossed through, so we can trace it back >>> further upstream. Kinda like a Via header, but with very different >>> properties and purpose. We've talked about doing that before, back = when >>> there was talk about creating a registry of SPIDs. What ever = happened >>> to having a registry of SPIDs? >>>=20 >>> -hadriel >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From rjsparks@nostrum.com Wed Jul 31 02:09:44 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ADA11E80F4 for ; Wed, 31 Jul 2013 02:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huqMvYzpMrfU for ; Wed, 31 Jul 2013 02:09:42 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CFF2B21F9223 for ; Wed, 31 Jul 2013 02:00:08 -0700 (PDT) Received: from dhcp-632b.meeting.ietf.org (dhcp-632b.meeting.ietf.org [130.129.99.43]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6V901sw059325 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 04:00:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51F8D216.50904@nostrum.com> Date: Wed, 31 Jul 2013 11:00:06 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan , "insipid@ietf.org" References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> In-Reply-To: <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 130.129.99.43 is authenticated by a trusted mechanism) Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:09:44 -0000 On 7/31/13 10:40 AM, Hadriel Kaplan wrote: > No, there's nothing wrong with the requirements document. My email wasn't about the requirements document, nor addressed to INSIPID - it was an email in the STIR mailing list related to using an INSIPID Session-ID for caller-id verification purposes. That's all. > > The INSIPID requirements doc is fine. Your mail, whether it was to INSIPID or not, says that INSIPIDs current trajectory will fail to meet the requirement in this document (and will, in fact, fail to achieve the goal in its charter or even its name). I take this response to say you believe that failure is in the proposed solution document, not the requirements document. What do we need to change, then, in the proposed solution to not fail to meet the chartered goal (specifically the requirement called out below). RjS > > -hadriel > > > On Jul 31, 2013, at 3:18 AM, Robert Sparks wrote: > >> On 7/30/13 9:38 PM, Hadriel Kaplan wrote: >>> Uhhh... just to be clear, I was making an individual comment in that email, not a corporate position statement or any some such. >>> >>> My point was that since the use-cases people are planning to do for INSIPID's Session-ID have now gone far beyond troubleshooting, the odds are we can't rely on it always being passed through end-to-end from originating Enterprises through various service providers to the far-end, without being modified in-transit. I can't *prove* it won't be, but that's just my hunch, since we've seen this movie play out before. >>> >>> The good news is we don't need the Session-ID to be used in STIR for caller-id verification, so there's nothing to worry about. >> Hadriel - >> >> This wasn't a question about STIR, it was a question about the publication of this INSIPID document. >> >> Look again at the requirement called out from the document below. >> >> Is your assertion that the proposed solution is not going to satisfy that requirement, or are you saying there's a problem with this requirement document being inconsistent (by requiring things that won't pass unchanged through intermediaries). If the latter, please re-engage the working group and fix the document (you are on the author list). >> >> RjS >>> :) >>> >>> -hadriel >>> >>> >>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo wrote: >>> >>>> Hi, >>>> >>>> I just got a publication request for the requirements document: >>>> >>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 >>>> >>>> The following is one of the requirements in the draft, which was one of >>>> the main reasons for creating this WG: >>>> >>>>> REQ3: The solution must require that the identifier, if present, pass >>>>> unchanged through SIP B2BUAs or other intermediaries. >>>> Hadriel, who works for an important SBC vendor and is one of the authors >>>> of the requirements document, sent the comments below to the STIR list a >>>> couple of weeks ago (see email below). >>>> >>>> How should I interpret those comments in the context of my AD review of >>>> this document and, even more importantly, as the responsible AD for this >>>> WG (as you know, we have had many scope-related discussions in the past)? >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) >>>> Date: Tue, 16 Jul 2013 10:21:13 -0400 >>>> From: Hadriel Kaplan >>>> To: Richard Shockey >>>> CC: IETF STIR Mail List >>>> >>>> >>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" wrote: >>>> >>>>> I actually believe INSIPID is equally important to the overall task >>>> since it >>>>> is the track and trace elements of this that can ultimately enable some >>>>> enforcement. I wish there was some more discussion on how the mechanisms >>>>> would work at the edge SIP/SS7 network gateways since that clearly has >>>> been >>>>> the center of most of the reported problems. I still think something >>>> needs >>>>> to be done to police that traffic but that is still ultimately a >>>> regulatory >>>>> effort. >>>> I agree we need a tracking/tracing mechanism, but in my opinion we >>>> cannot and should not rely on INSIPID Session-ID at all for that. They >>>> have gone beyond benign troubleshooting-type purposes now, which means >>>> there is absolutely no guarantee the Session-ID will make it intact >>>> across service providers in all cases. In fact, my hunch is it won't. >>>> >>>> Regardless, the Session-ID isn't what we really need for tracing a bad >>>> caller-id call. Even without Session-ID, the service provider's CDRs or >>>> logs can be used to trace it back to the peering connection and peer >>>> upstream provider the call came in from. What we also need is a list of >>>> SPIDs the call request has crossed through, so we can trace it back >>>> further upstream. Kinda like a Via header, but with very different >>>> properties and purpose. We've talked about doing that before, back when >>>> there was talk about creating a registry of SPIDs. What ever happened >>>> to having a registry of SPIDs? >>>> >>>> -hadriel >>>> >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>> >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From christer.holmberg@ericsson.com Wed Jul 31 02:19:27 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFBC21F99AC for ; Wed, 31 Jul 2013 02:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.922 X-Spam-Level: X-Spam-Status: No, score=-5.922 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoJel6J8tZB6 for ; Wed, 31 Jul 2013 02:19:12 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3894121E80BE for ; Wed, 31 Jul 2013 02:16:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-f2-51f8d5ef6fd1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EA.1E.00725.FE5D8F15; Wed, 31 Jul 2013 11:16:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Wed, 31 Jul 2013 11:16:31 +0200 From: Christer Holmberg To: James Polk , Andrew Allen , "laura.liess.dt@googlemail.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-01 Thread-Index: AQHOjZcEGJ9B9+pdQO+VryJ4gzrSmZl+gRwA Date: Wed, 31 Jul 2013 09:16:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4143BC@ESESSMB209.ericsson.se> References: <201307310239.r6V2d1jv001608@rcdn-core2-1.cisco.com> In-Reply-To: <201307310239.r6V2d1jv001608@rcdn-core2-1.cisco.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvre77qz8CDa536Fvcn7eV0eLTpk/M FvPvP2Oy2LGm0OJp41lGizlXDB3YPFqf7WX1mNWwlt1jyu+NrB5PJ0xm91iy5CeTx8ent1gC 2KK4bFJSczLLUov07RK4MuYd/chccM+2Yu+8TqYGxgPGXYycHBICJhLdLy4xQ9hiEhfurWfr YuTiEBI4zCjR/X8llLOEUeLlmnssXYwcHGwCFhLd/7RB4iICRxklTn9/yQjSzSyQJ7F25QNW EFtYwFzi+8O/bCC2CFD96rufmCFsI4mVz+eDxVkEVCWe/H4DVs8r4Cvxf9lLJhBbSOAYo8SB 4+kgNqeAo0TLswawOCPQdd9PrWGC2CUu8eHgdairBSSW7DkPZYtKvHz8jxXCVpL4seESC0S9 nsSNqVPYIGxtiWULXzND7BWUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXG25i BEbcwS2/dXcwnjoncohRmoNFSZx3k96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MUo8V n82QusIW/GqrrPb/63y1RyQ+2VVIxe5Mm3p3f+/yJ7Jzfyt5LeR3KL7VHGNROIGvW6mKj//x ljUxWxISVldXLuzIqKp5snbue1OrvrPyKxiWhO6OvPXMqvqyXPsMbp/EUMaujA0ZjUzfBRfc 4V2+QD2/NTTeT8rTTveOmN/j2NhovjVKLMUZiYZazEXFiQB54lgThgIAAA== Cc: "keith.drage@alcatel-lucent.com" , "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:19:27 -0000 Hi, I apologize if there are some questions I was expected to answer, and have = failed to do so. Having said that, I HAVE previously given comments regarding the backward c= ompatibility of the INSIPID solution, and how it can be made backward compa= tible. One issue I have raised is regarding the changing or order (depending on in= which direction the identifier is sent).=20 I have also indicated that a "Kaplan entity" will not add any parts to the = session-id, and the INSIPID solution need to be prepared for that Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org]= Puolesta James Polk L=E4hetetty: 31. hein=E4kuuta 2013 5:38 Vastaanottaja: Andrew Allen; laura.liess.dt@googlemail.com; hadriel.kaplan@= oracle.com Kopio: keith.drage@alcatel-lucent.com; insipid@ietf.org Aihe: Re: [Insipid] draft-ietf-insipid-session-id-01 I don't concur with Laura's recollection. The WG agreement was that we (the Jones draft authors) had to try as hard a= s we could to be backwards compatible with something that's only in draft f= orm. That's why we put into the Jones draft a backwards compatibility secti= on, which has holes in it - because it was Christer's lab that was the only= one doing the testing, and the Jones draft authors haven't heard any new i= nformation from him since last summer (even though we've asked that several= questions be answered last August and/or September). From the initial indiv-00 version of the Jones draft, that Session-ID has = been in two parts. The Kaplan draft, and what's been implemented before it = reached RFC status, was a 1-part Session-ID.=20 We've made every attempt to address how a 2-part value can be backwards com= patible with a 1-part value, but there are certain circumstances in which t= hat compatibility just isn't there. I find it interesting that Laura's note to the list includes the line "... = Carriers as my employer, where Hadriel's session-id is already implemented,= will never switch to the new identifier...". I remember a company saying t= hat same thing about the SIP Diversion header, which predated the History-I= nfo header by like 5 years, and still the History-Info header was the one t= o make it to Standard-track RFC. James At 09:28 AM 7/30/2013, Andrew Allen wrote: >Content-Language: en-US >Content-Type: multipart/alternative; >=20 >boundary=3D"_000_BBF5DDFE515C3946BC18D733B20DAD2338DED5BDXMB104ADSrimnet_" > > >I also concur with Laura's recollection. That agreement was the basis=20 >to move forward with the Jones draft as the WG draft. > >Andrew > >From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >Sent: Tuesday, July 30, 2013 06:18 AM Central Standard Time >To: Hadriel Kaplan >Cc: DRAGE, Keith (Keith) ;=20 >insipid@ietf.org >Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 > >I agree with Hadriel. If I remember correctly, we had an agreement in=20 >the WG that the identifier defined here has to be backward compatible=20 >with the session-id identifier defined in Hadriel's draft and that a=20 >reference to this draft has to be added. > >Backward incompatibility with Hadriel's session-id would be a big=20 >drawback for the implementation of the new identifier within carrier=20 >networks. Carriers as my employer, where Hadriel's session-id is=20 >already implemented, will never switch to the new identifier. They will=20 >require the old identifier for any new systems they buy, including=20 >conferencing systems. > >Because Hadriel's session-id is used in the 3GPP IMS specificatios, I=20 >assume that the situation is the same for other carriers using IMS. > >Thank you >Laura > > > >2013/7/29 Hadriel Kaplan ><hadriel.kaplan@oracle.com> > >I think there needs some discussion and justification for why the=20 >sess-id value order/placement is swapped in SIP responses and upstream=20 >requests, instead of being kept the same order throughout. This=20 >order-changing breaks backward compatibility with the older Session-ID=20 >individual draft, and is arguably harder to use/find in logs and=20 >wireshark for troubleshooting purposes. I think someone mentioned some=20 >reason this re-ordering was necessary, but I can't recall what it is=20 >and I don't see it explained in the draft. > >-hadriel > > >On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)"=20 ><keith.drage@alcatel-lucent.com> wr= ote: > > > (As WG cochair) > > > > As well as reviewing the document generally, it would be useful > if the WG membership could indicate any issues they think need face to=20 > face discussion time in Berlin. > > > > Or is everything going perfectly? > > > > Apart from what is listed below, is anything else missing from > the document? > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: insipid-bounces@ietf.org > [mailto:insipid-bounces@ietf.org] On Behalf > >> Of Paul E. Jones > >> Sent: 09 July 2013 00:17 > >> To: insipid@ietf.org > >> Subject: [Insipid] draft-ietf-insipid-session-id-01 > >> > >> Folks, > >> > >> I posted a new version of draft-ietf-insipid-session-id for your=20 > >> consideration. > >> > >> One significant addition is one to address a comment Laura had=20 > >> about ensuring that intermediary devices can consistently re-create=20 > >> a UUID and remain stateless. New text is introduced in Section 4.1=20 > >> that describes how such entities can construct the UUIDs. > >> > >> Section 6 was also revised with text to explain that the UUID order=20 > >> relates to who sends the message. It also discusses the longevity=20 > >> of the UUID, logging, and changes to the "remote" UUID. > >> > >> Previously, requests were made for additional call flows. Those=20 > >> were not added to the document, but the requests are listed as=20 > >> TODO items in > >> section(s) under section 9. There is also a TODO for section 9=20 > >> related to requested changes to section 9 to make it cleared the=20 > >> text is just examples. > >> > >> Paul > >> > >> > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid > > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain confidential=20 >information, privileged material (including material protected by the=20 >solicitor-client or other applicable privileges), or constitute=20 >non-public information. Any use of this information by anyone other=20 >than the intended recipient is prohibited. If you have received this=20 >transmission in error, please immediately reply to the sender and=20 >delete this information from your system. Use, dissemination,=20 >distribution, or reproduction of this transmission by unintended=20 >recipients is not authorized and may be unlawful. >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From hadriel.kaplan@oracle.com Wed Jul 31 02:59:09 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00E21F9DBA for ; Wed, 31 Jul 2013 02:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89QLTdzXfjaO for ; Wed, 31 Jul 2013 02:59:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7172E21F9DB4 for ; Wed, 31 Jul 2013 02:59:03 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6V9x1gJ012985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 09:59:02 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6V9x0TT013120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 09:59:01 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6V9x0ZK020169; Wed, 31 Jul 2013 09:59:00 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jul 2013 02:59:00 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51F8D216.50904@nostrum.com> Date: Wed, 31 Jul 2013 05:58:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "insipid@ietf.org" Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:59:09 -0000 I don't think it's a failure of specification, in either requirements or = solution; and it's not fair to hold up work or raise a red flag just = because of a personal hunch. I am not asking to hold up anything, nor = raising a red flag for INSIPID. It's just a personal observation that = when we use things for more than their originally intended use-case, or = when it becomes complicated, interoperability issues happen or other = motivations exist, that end up with having SBCs changing stuff. When we began the INSIPID work, back in DISPATCH, there was general = agreement/understanding that we couldn't make mandatory compliance = statements for B2BUAs and expect them to comply to it simply because = it's in an RFC. Instead, we had to define mechanisms which a B2BUA = would have no need to change/muddle-with, that its operators would want = to leave alone, for some beneficial purpose that the operators/owners of = the B2BUAs would want. =20 So when I submitted the Session-ID draft, the main goal/use-case for it = was to help troubleshooting. After much discussion of things that could = go wrong with any other use of it, there was some consensus that if we = use Session-ID for anything else, then things will go wrong somewhere or = people will want to control it, resulting in B2BUAs modifying the value = somewhere or other. Thus it would lose the troubleshooting value a bit, = and lose the end-to-end property in some cases. The truth is we in the IETF don't care much about having a new header = simply/only for troubleshooting purposes. We're not good about = Operations-type considerations in the IETF RAI group. We want new = features. So when I ask people what they're planning to use Session-ID = for if not just troubleshooting, the answers I get are for call-control = related purposes: things like QoS bandwidth CAC, out-of-dialog message = correlation, and various "policies". By definition, that means the = Session-ID string will have a direct correlation to whether = calls/messages/mechanisms fail or succeed, and thus my hunch is SBCs = will end up changing the string in certain scenarios to make it match or = not-match other calls/messages. It's just a hunch, and I have no proof, = though I can already imagine scenarios where we'd end up doing that. But this is just a personal observation, and there's nothing wrong with = INSIPID continuing down the path it's on since it's clear people want it = for the purposes they want it for. I was only commenting in the STIR = list, that for *STIR* purposes we couldn't rely on it for end-to-end = caller-id verification. -hadriel On Jul 31, 2013, at 5:00 AM, Robert Sparks wrote: > On 7/31/13 10:40 AM, Hadriel Kaplan wrote: >> No, there's nothing wrong with the requirements document. My email = wasn't about the requirements document, nor addressed to INSIPID - it = was an email in the STIR mailing list related to using an INSIPID = Session-ID for caller-id verification purposes. That's all. >>=20 >> The INSIPID requirements doc is fine. > Your mail, whether it was to INSIPID or not, says that INSIPIDs = current trajectory will fail to meet the requirement in this document > (and will, in fact, fail to achieve the goal in its charter or even = its name). >=20 > I take this response to say you believe that failure is in the = proposed solution document, not the requirements document. >=20 > What do we need to change, then, in the proposed solution to not fail = to meet the chartered goal (specifically the requirement called out = below). >=20 > RjS >>=20 >> -hadriel >>=20 >>=20 >> On Jul 31, 2013, at 3:18 AM, Robert Sparks = wrote: >>=20 >>> On 7/30/13 9:38 PM, Hadriel Kaplan wrote: >>>> Uhhh... just to be clear, I was making an individual comment in = that email, not a corporate position statement or any some such. >>>>=20 >>>> My point was that since the use-cases people are planning to do for = INSIPID's Session-ID have now gone far beyond troubleshooting, the odds = are we can't rely on it always being passed through end-to-end from = originating Enterprises through various service providers to the = far-end, without being modified in-transit. I can't *prove* it won't = be, but that's just my hunch, since we've seen this movie play out = before. >>>>=20 >>>> The good news is we don't need the Session-ID to be used in STIR = for caller-id verification, so there's nothing to worry about. >>> Hadriel - >>>=20 >>> This wasn't a question about STIR, it was a question about the = publication of this INSIPID document. >>>=20 >>> Look again at the requirement called out from the document below. >>>=20 >>> Is your assertion that the proposed solution is not going to satisfy = that requirement, or are you saying there's a problem with this = requirement document being inconsistent (by requiring things that won't = pass unchanged through intermediaries). If the latter, please re-engage = the working group and fix the document (you are on the author list). >>>=20 >>> RjS >>>> :) >>>>=20 >>>> -hadriel >>>>=20 >>>>=20 >>>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I just got a publication request for the requirements document: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 >>>>>=20 >>>>> The following is one of the requirements in the draft, which was = one of >>>>> the main reasons for creating this WG: >>>>>=20 >>>>>> REQ3: The solution must require that the identifier, if = present, pass >>>>>> unchanged through SIP B2BUAs or other intermediaries. >>>>> Hadriel, who works for an important SBC vendor and is one of the = authors >>>>> of the requirements document, sent the comments below to the STIR = list a >>>>> couple of weeks ago (see email below). >>>>>=20 >>>>> How should I interpret those comments in the context of my AD = review of >>>>> this document and, even more importantly, as the responsible AD = for this >>>>> WG (as you know, we have had many scope-related discussions in the = past)? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Gonzalo >>>>>=20 >>>>>=20 >>>>> -------- Original Message -------- >>>>> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR = Charter) >>>>> Date: Tue, 16 Jul 2013 10:21:13 -0400 >>>>> From: Hadriel Kaplan >>>>> To: Richard Shockey >>>>> CC: IETF STIR Mail List >>>>>=20 >>>>>=20 >>>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" = wrote: >>>>>=20 >>>>>> I actually believe INSIPID is equally important to the overall = task >>>>> since it >>>>>> is the track and trace elements of this that can ultimately = enable some >>>>>> enforcement. I wish there was some more discussion on how the = mechanisms >>>>>> would work at the edge SIP/SS7 network gateways since that = clearly has >>>>> been >>>>>> the center of most of the reported problems. I still think = something >>>>> needs >>>>>> to be done to police that traffic but that is still ultimately a >>>>> regulatory >>>>>> effort. >>>>> I agree we need a tracking/tracing mechanism, but in my opinion we >>>>> cannot and should not rely on INSIPID Session-ID at all for that. = They >>>>> have gone beyond benign troubleshooting-type purposes now, which = means >>>>> there is absolutely no guarantee the Session-ID will make it = intact >>>>> across service providers in all cases. In fact, my hunch is it = won't. >>>>>=20 >>>>> Regardless, the Session-ID isn't what we really need for tracing a = bad >>>>> caller-id call. Even without Session-ID, the service provider's = CDRs or >>>>> logs can be used to trace it back to the peering connection and = peer >>>>> upstream provider the call came in from. What we also need is a = list of >>>>> SPIDs the call request has crossed through, so we can trace it = back >>>>> further upstream. Kinda like a Via header, but with very = different >>>>> properties and purpose. We've talked about doing that before, = back when >>>>> there was talk about creating a registry of SPIDs. What ever = happened >>>>> to having a registry of SPIDs? >>>>>=20 >>>>> -hadriel >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>> _______________________________________________ >>>>> insipid mailing list >>>>> insipid@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/insipid >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >=20 From keith.drage@alcatel-lucent.com Wed Jul 31 03:13:35 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67D21F9FCF for ; Wed, 31 Jul 2013 03:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.646 X-Spam-Level: X-Spam-Status: No, score=-110.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwYDLV8fmKhV for ; Wed, 31 Jul 2013 03:13:29 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9821F9FA7 for ; Wed, 31 Jul 2013 03:13:28 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6VADPCj008032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 Jul 2013 05:13:27 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6VADPRp013718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 12:13:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 31 Jul 2013 12:13:25 +0200 From: "DRAGE, Keith (Keith)" To: Robert Sparks , Hadriel Kaplan , "insipid@ietf.org" Thread-Topic: [Insipid] Will the identifier pass unchanged through B2BUAs? Thread-Index: AQHOjReO8cw2BxP87EWgI7e79yRYZ5l9fRcAgADDY4CAABb6gIAABYkAgAAk6RA= Date: Wed, 31 Jul 2013 10:13:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B078784@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> In-Reply-To: <51F8D216.50904@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:13:35 -0000 If the deployer of an SBC wants to break the Session-ID header field, then = they will break it. They will also break the Alternative-to-Session-ID-for-= SBCs-that-break-Session-ID header field, and so on. It seems to me we are just back in the paradigm that we design header field= s that we say to SBC deployers that really you should pass these through, b= ut at the end of the day, there will always be someone with a desire to bre= ak them.=20 We know this happens, there is nothing we can do about it except warn. Further, the INSIPID group does have limitations on what it is working on, = for example: REQ9: It must be possible to correlate two end-to-end sessions when the sessions are created by a third party controller using 3PCC procedures shown in Figure 1 of RFC 3725 [7]. Is not a requirement that one entity knows all the session identifiers in u= se on all the other legs. Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Robert Sparks > Sent: 31 July 2013 10:00 > To: Hadriel Kaplan; insipid@ietf.org > Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? >=20 > On 7/31/13 10:40 AM, Hadriel Kaplan wrote: > > No, there's nothing wrong with the requirements document. My email > wasn't about the requirements document, nor addressed to INSIPID - it was > an email in the STIR mailing list related to using an INSIPID Session-ID > for caller-id verification purposes. That's all. > > > > The INSIPID requirements doc is fine. > Your mail, whether it was to INSIPID or not, says that INSIPIDs current > trajectory will fail to meet the requirement in this document > (and will, in fact, fail to achieve the goal in its charter or even its > name). >=20 > I take this response to say you believe that failure is in the proposed > solution document, not the requirements document. >=20 > What do we need to change, then, in the proposed solution to not fail to > meet the chartered goal (specifically the requirement called out below). >=20 > RjS > > > > -hadriel > > > > > > On Jul 31, 2013, at 3:18 AM, Robert Sparks wrote= : > > > >> On 7/30/13 9:38 PM, Hadriel Kaplan wrote: > >>> Uhhh... just to be clear, I was making an individual comment in that > email, not a corporate position statement or any some such. > >>> > >>> My point was that since the use-cases people are planning to do for > INSIPID's Session-ID have now gone far beyond troubleshooting, the odds > are we can't rely on it always being passed through end-to-end from > originating Enterprises through various service providers to the far-end, > without being modified in-transit. I can't *prove* it won't be, but > that's just my hunch, since we've seen this movie play out before. > >>> > >>> The good news is we don't need the Session-ID to be used in STIR for > caller-id verification, so there's nothing to worry about. > >> Hadriel - > >> > >> This wasn't a question about STIR, it was a question about the > publication of this INSIPID document. > >> > >> Look again at the requirement called out from the document below. > >> > >> Is your assertion that the proposed solution is not going to satisfy > that requirement, or are you saying there's a problem with this > requirement document being inconsistent (by requiring things that won't > pass unchanged through intermediaries). If the latter, please re-engage > the working group and fix the document (you are on the author list). > >> > >> RjS > >>> :) > >>> > >>> -hadriel > >>> > >>> > >>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo > wrote: > >>> > >>>> Hi, > >>>> > >>>> I just got a publication request for the requirements document: > >>>> > >>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 > >>>> > >>>> The following is one of the requirements in the draft, which was one > of > >>>> the main reasons for creating this WG: > >>>> > >>>>> REQ3: The solution must require that the identifier, if present, > pass > >>>>> unchanged through SIP B2BUAs or other intermediaries. > >>>> Hadriel, who works for an important SBC vendor and is one of the > authors > >>>> of the requirements document, sent the comments below to the STIR > list a > >>>> couple of weeks ago (see email below). > >>>> > >>>> How should I interpret those comments in the context of my AD review > of > >>>> this document and, even more importantly, as the responsible AD for > this > >>>> WG (as you know, we have had many scope-related discussions in the > past)? > >>>> > >>>> Thanks, > >>>> > >>>> Gonzalo > >>>> > >>>> > >>>> -------- Original Message -------- > >>>> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR > Charter) > >>>> Date: Tue, 16 Jul 2013 10:21:13 -0400 > >>>> From: Hadriel Kaplan > >>>> To: Richard Shockey > >>>> CC: IETF STIR Mail List > >>>> > >>>> > >>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" > wrote: > >>>> > >>>>> I actually believe INSIPID is equally important to the overall task > >>>> since it > >>>>> is the track and trace elements of this that can ultimately enable > some > >>>>> enforcement. I wish there was some more discussion on how the > mechanisms > >>>>> would work at the edge SIP/SS7 network gateways since that clearly > has > >>>> been > >>>>> the center of most of the reported problems. I still think > something > >>>> needs > >>>>> to be done to police that traffic but that is still ultimately a > >>>> regulatory > >>>>> effort. > >>>> I agree we need a tracking/tracing mechanism, but in my opinion we > >>>> cannot and should not rely on INSIPID Session-ID at all for that. > They > >>>> have gone beyond benign troubleshooting-type purposes now, which > means > >>>> there is absolutely no guarantee the Session-ID will make it intact > >>>> across service providers in all cases. In fact, my hunch is it won'= t. > >>>> > >>>> Regardless, the Session-ID isn't what we really need for tracing a > bad > >>>> caller-id call. Even without Session-ID, the service provider's CDR= s > or > >>>> logs can be used to trace it back to the peering connection and peer > >>>> upstream provider the call came in from. What we also need is a lis= t > of > >>>> SPIDs the call request has crossed through, so we can trace it back > >>>> further upstream. Kinda like a Via header, but with very different > >>>> properties and purpose. We've talked about doing that before, back > when > >>>> there was talk about creating a registry of SPIDs. What ever > happened > >>>> to having a registry of SPIDs? > >>>> > >>>> -hadriel > >>>> > >>>> _______________________________________________ > >>>> stir mailing list > >>>> stir@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/stir > >>>> > >>>> _______________________________________________ > >>>> insipid mailing list > >>>> insipid@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/insipid > >>> _______________________________________________ > >>> insipid mailing list > >>> insipid@ietf.org > >>> https://www.ietf.org/mailman/listinfo/insipid > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Wed Jul 31 03:27:13 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED9A21F9F5B for ; Wed, 31 Jul 2013 03:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtei-dDE5K2E for ; Wed, 31 Jul 2013 03:27:08 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id CA44C21F9FF1 for ; Wed, 31 Jul 2013 03:27:07 -0700 (PDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 6yRG1m0021wfjNsA7yT7gt; Wed, 31 Jul 2013 10:27:07 +0000 Received: from dhcp-15fb.meeting.ietf.org ([130.129.21.251]) by omta23.emeryville.ca.mail.comcast.net with comcast id 6yQx1m00G5R2GH68jyR0WB; Wed, 31 Jul 2013 10:25:05 +0000 Message-ID: <51F8E5F3.6050101@alum.mit.edu> Date: Wed, 31 Jul 2013 12:24:51 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: insipid@ietf.org References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> In-Reply-To: <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@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=1375266427; bh=iLoJ3pNK8wrVpCmmLi8fGV+AZnkfXJbOcdlU4mkng9Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K2F31aJkQnoo2vbTw7GPoiGxS3Py5Z/LMYdS0Fj8KeuWOCG00MrtDbj1JlMEV/gfp fgLzNsaPgtwA6f8LzwehJtRFS0ScVNzrDsj2BaFccLe44WzRdSGkGHFIbR9Y2cQ9qv 8OOT04lbbOVlcUVfbnEXhogj5vEczQlJGGSc3nclbwDJo4gHepwMP5CDXvX5sw5J1l zT10rRqXA7da/wfsmh7rdWKkarcBQARjGopeHrbN0b7lY5n7qcsuDHLrym7zfjFNy+ c/TidbK7FdBeud8WrXeGqPpGrW4j+nWQz4xW40w83FsFVX6iesNvMm3JgbCaEfytOP NNb62bNrfCZwg== Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:27:14 -0000 On 7/31/13 11:58 AM, Hadriel Kaplan wrote: > > I don't think it's a failure of specification, in either requirements or solution; and it's not fair to hold up work or raise a red flag just because of a personal hunch. I am not asking to hold up anything, nor raising a red flag for INSIPID. It's just a personal observation that when we use things for more than their originally intended use-case, or when it becomes complicated, interoperability issues happen or other motivations exist, that end up with having SBCs changing stuff. > > When we began the INSIPID work, back in DISPATCH, there was general agreement/understanding that we couldn't make mandatory compliance statements for B2BUAs and expect them to comply to it simply because it's in an RFC. Instead, we had to define mechanisms which a B2BUA would have no need to change/muddle-with, that its operators would want to leave alone, for some beneficial purpose that the operators/owners of the B2BUAs would want. > > So when I submitted the Session-ID draft, the main goal/use-case for it was to help troubleshooting. After much discussion of things that could go wrong with any other use of it, there was some consensus that if we use Session-ID for anything else, then things will go wrong somewhere or people will want to control it, resulting in B2BUAs modifying the value somewhere or other. Thus it would lose the troubleshooting value a bit, and lose the end-to-end property in some cases. > > The truth is we in the IETF don't care much about having a new header simply/only for troubleshooting purposes. We're not good about Operations-type considerations in the IETF RAI group. We want new features. So when I ask people what they're planning to use Session-ID for if not just troubleshooting, the answers I get are for call-control related purposes: things like QoS bandwidth CAC, out-of-dialog message correlation, and various "policies". By definition, that means the Session-ID string will have a direct correlation to whether calls/messages/mechanisms fail or succeed, and thus my hunch is SBCs will end up changing the string in certain scenarios to make it match or not-match other calls/messages. It's just a hunch, and I have no proof, though I can already imagine scenarios where we'd end up doing that. > > But this is just a personal observation, and there's nothing wrong with INSIPID continuing down the path it's on since it's clear people want it for the purposes they want it for. I was only commenting in the STIR list, that for *STIR* purposes we couldn't rely on it for end-to-end caller-id verification. Well, the point of doing the work was to get an id that would survive e2e, in spite of b2buas, for use in *some* way or ways. If it is likely not to survive e2e, for whatever reason, then ISTM there is no point in progressing the work. The fact that you are only offering a "hunch" about survivability doesn't make it a strong justification for giving up on the work. We aren't likely to get any definitive answers. But maybe we can solicit opinions from those who might have influence over the survivability of the session id. Maybe we can ensure that it will survive if we promise not to use it for anything useful. Just plunging ahead in blissful ignorance doesn't seem like a good plan. Thanks, Paul > -hadriel > > > On Jul 31, 2013, at 5:00 AM, Robert Sparks wrote: > >> On 7/31/13 10:40 AM, Hadriel Kaplan wrote: >>> No, there's nothing wrong with the requirements document. My email wasn't about the requirements document, nor addressed to INSIPID - it was an email in the STIR mailing list related to using an INSIPID Session-ID for caller-id verification purposes. That's all. >>> >>> The INSIPID requirements doc is fine. >> Your mail, whether it was to INSIPID or not, says that INSIPIDs current trajectory will fail to meet the requirement in this document >> (and will, in fact, fail to achieve the goal in its charter or even its name). >> >> I take this response to say you believe that failure is in the proposed solution document, not the requirements document. >> >> What do we need to change, then, in the proposed solution to not fail to meet the chartered goal (specifically the requirement called out below). >> >> RjS >>> >>> -hadriel >>> >>> >>> On Jul 31, 2013, at 3:18 AM, Robert Sparks wrote: >>> >>>> On 7/30/13 9:38 PM, Hadriel Kaplan wrote: >>>>> Uhhh... just to be clear, I was making an individual comment in that email, not a corporate position statement or any some such. >>>>> >>>>> My point was that since the use-cases people are planning to do for INSIPID's Session-ID have now gone far beyond troubleshooting, the odds are we can't rely on it always being passed through end-to-end from originating Enterprises through various service providers to the far-end, without being modified in-transit. I can't *prove* it won't be, but that's just my hunch, since we've seen this movie play out before. >>>>> >>>>> The good news is we don't need the Session-ID to be used in STIR for caller-id verification, so there's nothing to worry about. >>>> Hadriel - >>>> >>>> This wasn't a question about STIR, it was a question about the publication of this INSIPID document. >>>> >>>> Look again at the requirement called out from the document below. >>>> >>>> Is your assertion that the proposed solution is not going to satisfy that requirement, or are you saying there's a problem with this requirement document being inconsistent (by requiring things that won't pass unchanged through intermediaries). If the latter, please re-engage the working group and fix the document (you are on the author list). >>>> >>>> RjS >>>>> :) >>>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I just got a publication request for the requirements document: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08 >>>>>> >>>>>> The following is one of the requirements in the draft, which was one of >>>>>> the main reasons for creating this WG: >>>>>> >>>>>>> REQ3: The solution must require that the identifier, if present, pass >>>>>>> unchanged through SIP B2BUAs or other intermediaries. >>>>>> Hadriel, who works for an important SBC vendor and is one of the authors >>>>>> of the requirements document, sent the comments below to the STIR list a >>>>>> couple of weeks ago (see email below). >>>>>> >>>>>> How should I interpret those comments in the context of my AD review of >>>>>> this document and, even more importantly, as the responsible AD for this >>>>>> WG (as you know, we have had many scope-related discussions in the past)? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter) >>>>>> Date: Tue, 16 Jul 2013 10:21:13 -0400 >>>>>> From: Hadriel Kaplan >>>>>> To: Richard Shockey >>>>>> CC: IETF STIR Mail List >>>>>> >>>>>> >>>>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" wrote: >>>>>> >>>>>>> I actually believe INSIPID is equally important to the overall task >>>>>> since it >>>>>>> is the track and trace elements of this that can ultimately enable some >>>>>>> enforcement. I wish there was some more discussion on how the mechanisms >>>>>>> would work at the edge SIP/SS7 network gateways since that clearly has >>>>>> been >>>>>>> the center of most of the reported problems. I still think something >>>>>> needs >>>>>>> to be done to police that traffic but that is still ultimately a >>>>>> regulatory >>>>>>> effort. >>>>>> I agree we need a tracking/tracing mechanism, but in my opinion we >>>>>> cannot and should not rely on INSIPID Session-ID at all for that. They >>>>>> have gone beyond benign troubleshooting-type purposes now, which means >>>>>> there is absolutely no guarantee the Session-ID will make it intact >>>>>> across service providers in all cases. In fact, my hunch is it won't. >>>>>> >>>>>> Regardless, the Session-ID isn't what we really need for tracing a bad >>>>>> caller-id call. Even without Session-ID, the service provider's CDRs or >>>>>> logs can be used to trace it back to the peering connection and peer >>>>>> upstream provider the call came in from. What we also need is a list of >>>>>> SPIDs the call request has crossed through, so we can trace it back >>>>>> further upstream. Kinda like a Via header, but with very different >>>>>> properties and purpose. We've talked about doing that before, back when >>>>>> there was talk about creating a registry of SPIDs. What ever happened >>>>>> to having a registry of SPIDs? >>>>>> >>>>>> -hadriel >>>>>> >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>> >>>>>> _______________________________________________ >>>>>> insipid mailing list >>>>>> insipid@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>> _______________________________________________ >>>>> insipid mailing list >>>>> insipid@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/insipid >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From hadriel.kaplan@oracle.com Wed Jul 31 04:04:39 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A68711E8172 for ; Wed, 31 Jul 2013 04:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX75vQxKJNxx for ; Wed, 31 Jul 2013 04:04:32 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6A621F9654 for ; Wed, 31 Jul 2013 04:04:31 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6VB4S2i020458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 11:04:29 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 r6VB4R54020696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 11:04:28 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VB4R7e013441; Wed, 31 Jul 2013 11:04:27 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jul 2013 04:04:27 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51F8E5F3.6050101@alum.mit.edu> Date: Wed, 31 Jul 2013 07:04:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> <51F8E5F3.6050101@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: insipid@ietf.org Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:04:39 -0000 On Jul 31, 2013, at 6:24 AM, Paul Kyzivat wrote: > Well, the point of doing the work was to get an id that would survive = e2e, in spite of b2buas, for use in *some* way or ways. If it is likely = not to survive e2e, for whatever reason, then ISTM there is no point in = progressing the work. Sure there is: for the use-cases people have in mind. Afaict, that's = mostly around correlating multiple SIP dialogs of the same conference or = 3PCC scenario, and applying policies on such matching cases. Those = use-cases don't actually need true, world-wide end-to-end survival. = They only need to survive through *some* B2BUAs, not all; and only = in/across some domains, not all; and only in certain scenarios, not all. The goal has never really been to simply "get an ID that would survive = e2e" - it's been to get something we could use for some *purpose*. I = believe an e2e identifier would be quite useful for a troubleshooting = purpose, and so long as it was used for only that then the odds of = someone wanting to change it would be minimized. But if people use it = for other purposes, then each and every purpose it is used for expands = the scenarios and likelihood in which someone would need to change it = and no longer make it truly e2e. That's *ok* - it just means it's not = going to be as useful for troubleshooting as it could have been, is all. = It's not doom and gloom. > The fact that you are only offering a "hunch" about survivability = doesn't make it a strong justification for giving up on the work. We = aren't likely to get any definitive answers. But maybe we can solicit = opinions from those who might have influence over the survivability of = the session id. Maybe we can ensure that it will survive if we promise = not to use it for anything useful. How can we promise not to use it for anything useful? We already know = some people want to use it for things that are useful *for them*. -hadriel From Peter.Dawes@vodafone.com Wed Jul 31 05:02:23 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF9321E8125 for ; Wed, 31 Jul 2013 05:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd2YwHdQkGo6 for ; Wed, 31 Jul 2013 05:02:15 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6954321F8F3C for ; Wed, 31 Jul 2013 05:01:09 -0700 (PDT) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailout01.vodafone.com (Postfix) with ESMTP id C6B602E1B8D for ; Wed, 31 Jul 2013 14:01:07 +0200 (CEST) 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 mailint01.vodafone.com (Postfix) with ESMTPS id AE69D2E16F2; Wed, 31 Jul 2013 14:01:07 +0200 (CEST) Received: from VOEXC17W.internal.vodafone.com (145.230.101.19) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 31 Jul 2013 14:01:06 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.36]) by voexc17w.internal.vodafone.com ([145.230.101.19]) with mapi id 14.03.0146.002; Wed, 31 Jul 2013 14:01:05 +0200 From: "Dawes, Peter, Vodafone Group" To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [Insipid] Will the identifier pass unchanged through B2BUAs? Thread-Index: AQHOjcmV1RbjBbVSDk6WQXLo0Sn9D5l+W5kAgAAQcgCAAAc8gIAACw0AgAAruLA= Date: Wed, 31 Jul 2013 12:01:05 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE91746@VOEXM31W.internal.vodafone.com> References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> <51F8E5F3.6050101@alum.mit.edu> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid@ietf.org" Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:02:23 -0000 Hello All, The question from Gonzalo was about REQ3: REQ3: The solution must require that the identifier, if present, pass unchanged through SIP B2BUAs or other intermediaries. My interpretation was that 1) the solution document must contain the text "= SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header fi= eld value." and 2) no future drafts/RFCs are allowed to specify that a SIP = B2BUA or intermediary may change the Session-ID header field value. This is simplistic but I think it meets REQ3. The discussion on Gonzalo's q= uestion seems to me to be about a different requirement along the lines of = "how the Session-ID header field is generated and used must be compared wit= h generation and use of header fields that a SIP B2BUA or other intermediar= y removes or modifies to ensure that a SIP B2BUA or other intermediary does= not have any reason to remove the Session-ID: header field." Regards, Peter -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Hadriel Kaplan Sent: 31 July 2013 13:04 To: Paul Kyzivat Cc: insipid@ietf.org Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? On Jul 31, 2013, at 6:24 AM, Paul Kyzivat wrote: > Well, the point of doing the work was to get an id that would survive e2e= , in spite of b2buas, for use in *some* way or ways. If it is likely not to= survive e2e, for whatever reason, then ISTM there is no point in progressi= ng the work. Sure there is: for the use-cases people have in mind. Afaict, that's most= ly around correlating multiple SIP dialogs of the same conference or 3PCC s= cenario, and applying policies on such matching cases. Those use-cases don= 't actually need true, world-wide end-to-end survival. They only need to s= urvive through *some* B2BUAs, not all; and only in/across some domains, not= all; and only in certain scenarios, not all. The goal has never really been to simply "get an ID that would survive e2e"= - it's been to get something we could use for some *purpose*. I believe a= n e2e identifier would be quite useful for a troubleshooting purpose, and s= o long as it was used for only that then the odds of someone wanting to cha= nge it would be minimized. But if people use it for other purposes, then e= ach and every purpose it is used for expands the scenarios and likelihood i= n which someone would need to change it and no longer make it truly e2e. T= hat's *ok* - it just means it's not going to be as useful for troubleshooti= ng as it could have been, is all. It's not doom and gloom. > The fact that you are only offering a "hunch" about survivability doesn't= make it a strong justification for giving up on the work. We aren't likely= to get any definitive answers. But maybe we can solicit opinions from thos= e who might have influence over the survivability of the session id. Maybe = we can ensure that it will survive if we promise not to use it for anything= useful. How can we promise not to use it for anything useful? We already know some= people want to use it for things that are useful *for them*. -hadriel _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From Peter.Dawes@vodafone.com Wed Jul 31 05:34:43 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C324B11E81A3 for ; Wed, 31 Jul 2013 05:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.486 X-Spam-Level: X-Spam-Status: No, score=-4.486 tagged_above=-999 required=5 tests=[AWL=-2.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWXimadsgkOB for ; Wed, 31 Jul 2013 05:34:38 -0700 (PDT) Received: from mailout11.vodafone.com (mailout11.vodafone.com [195.232.224.80]) by ietfa.amsl.com (Postfix) with ESMTP id DF41611E818F for ; Wed, 31 Jul 2013 05:32:08 -0700 (PDT) Received: from mailint11.vodafone.com (localhost [127.0.0.1]) by mailout11.vodafone.com (Postfix) with ESMTP id 8C13E2A09BF for ; Wed, 31 Jul 2013 14:31:55 +0200 (CEST) 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 mailint11.vodafone.com (Postfix) with ESMTPS id 7B17B2A0836; Wed, 31 Jul 2013 14:31:55 +0200 (CEST) Received: from VOEXC11W.internal.vodafone.com (145.230.101.13) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 31 Jul 2013 14:31:55 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.36]) by voexc11w.internal.vodafone.com ([145.230.101.13]) with mapi id 14.03.0146.002; Wed, 31 Jul 2013 14:31:54 +0200 From: "Dawes, Peter, Vodafone Group" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) Thread-Index: AQHOh090Gf3fTJI8hUe/mT1XtHhuh5l9lmLQ Date: Wed, 31 Jul 2013 12:31:53 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> References: <51EDEF82.3060908@alum.mit.edu> In-Reply-To: <51EDEF82.3060908@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:34:44 -0000 Hello Paul, Thanks for the questions, I can add some discussion of these points by expa= nding on the potential solutions clause 7 in the next version of the draft.= Extra text will be along the lines of the answers below. =20 1) For "when some servers are expected to be dialog stateful. Also if loggi= ng is to stop after some period of time." The stateful entities can be the sending and receiving UA, and a SIP proxy = if the UAs do not insert and echo the log-me marker (REQ5, REQ6). I can des= cribe this behaviour in the potential solutions. How logging stops is hinted at in clause 4 but I can give examples in the p= otential solutions. I do not propose that the draft specifies how logging i= s configured to be started and stopped though, the main focus of the draft = is to add a marker for sessions of interest to logging.=20 2) For " Is free text good enough for identifying test cases? Isn't there p= ossibility of collision? Since there is likely to be resistance to meaningf= ul names that might tunnel information, perhaps these should be random numb= ers." These are good questions, it might well be that the Session-ID: value becom= es the test case identifier.=20 3) For protocol to transmit the logs, RFC 6872 "The Common Log Format (CLF)= for the Session Initiation Protocol (SIP): Framework and Information Model= " has been suggested so I will look into this.=20 4) For " trust by the server doing the logging of the log server, and autho= rization by the log server of those sending logs " I think mechanisms exist= for mutual authentication of sender and receiver so I can add something. I will also try to ensure that the descriptions of proposed solutions cover= all aspects of the draft (log server, test case id) and thanks for spottin= g the syntax error in Fig. 3. Regards, Peter -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 23 July 2013 04:51 To: insipid@ietf.org Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) Some questions about this draft: The requirements and other discussion imply certain behavior by servers tha= t support this. I'd like to hear more explicit discussion of what that expe= cted behavior is, within the potential solutions. E.g., when some servers are expected to be dialog stateful. Also if logging= is to stop after some period of time. Section 7.1: This says the header is first inserted by the UAC. There might be reason to= have it inserted by the UAS in some cases, or even a proxy or B2BUA based = on policy for debugging a UA that can't be controlled. Is free text good enough for identifying test cases? Isn't there possibilit= y of collision? Since there is likely to be resistance to meaningful names = that might tunnel information, perhaps these should be random numbers. I want to hear more about sending the address of the server collecting logs= . For this to be useful there must be an explicit or implicit protocol used= to transmit the logs. Is there one such protocol or many?=20 If many, how do you know which will be supported? What about trust by the s= erver doing the logging of the log server, and authorization by the log ser= ver of those sending logs? Will all servers doing logging want to use a ser= ver chosen by the one inserting the logme request? Section 7.2: Where does the test case id go with this solution? In Figure 3 the call-info in the figure is syntactically incorrect. The par= ameter is a domain name, but it is required to be a URL. Thanks, Paul _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From mary.ietf.barnes@gmail.com Wed Jul 31 05:39:21 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2DF11E8178 for ; Wed, 31 Jul 2013 05:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.497 X-Spam-Level: X-Spam-Status: No, score=-101.497 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7aIoHKHKgOX for ; Wed, 31 Jul 2013 05:39:19 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0FE21F9D1E for ; Wed, 31 Jul 2013 05:37:49 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cr7so380295qab.15 for ; Wed, 31 Jul 2013 05:37:48 -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=ykdS69pXkDf81d54AET0B3tvgAltMfPuww4HRnF+hh4=; b=D8aiXuV7u8nnWFL8McpHqRWjxQJ0+0WZHBWgyygU6520biMkcEwIcewlWTyUwx7Dig Xl4RV56ZOmffv5u5Dp3e4xygLSI3+5uUxW+5tqFlIs36bVrjLJwH2fWtWSVn/YEIh8Kq Iuu8XsBi2a9i0uPKMBOfBfl61bNhyXgIJ3KJXyal97MTjIkCmTfDWApxgSkJyCo1NiF2 MCx5ucM+4KV6ekADWR5RtcZw3U3nV5QOsxlkXMg4jBcs0+p8DZbDup6tA36CS96en0Un PBOubswnAvKWqISIezjjwsraDawfoq+MdxQ9nBTSDhVHe2ncWuCwneoDdhlBxUUDjBjZ uTUQ== MIME-Version: 1.0 X-Received: by 10.49.28.9 with SMTP id x9mr8438435qeg.8.1375274268672; Wed, 31 Jul 2013 05:37:48 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Wed, 31 Jul 2013 05:37:48 -0700 (PDT) In-Reply-To: <201307310239.r6V2d1jv001608@rcdn-core2-1.cisco.com> References: <201307310239.r6V2d1jv001608@rcdn-core2-1.cisco.com> Date: Wed, 31 Jul 2013 07:37:48 -0500 Message-ID: From: Mary Barnes To: James Polk Content-Type: multipart/alternative; boundary=047d7bdc077440c86104e2cdfea3 Cc: "insipid@ietf.org" , Andrew Allen , "keith.drage@alcatel-lucent.com" , "hadriel.kaplan@oracle.com" , "laura.liess.dt@googlemail.com" Subject: Re: [Insipid] draft-ietf-insipid-session-id-01 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:39:21 -0000 --047d7bdc077440c86104e2cdfea3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 30, 2013 at 9:38 PM, James Polk wrote: > I don't concur with Laura's recollection. > [MB] Laura's recollection is correct based on the WG minutes from IETF-85: http://www.ietf.org/proceedings/85/minutes/minutes-85-insipid The minutes state the following: Nobody in the room objected against that the draft-jones-insipid-session-id-01.txt describes backward compatibility to the session-id as defined in the Kaplan draft (draft-kaplan-dispatch-session-id). Chairs - Any objections to the backwards compatibility as described in -01 version - No objections noted. Decision: to keep the new draft backwards compatible with regard to draft-kaplan-dispatch-session-id [/MB] > The WG agreement was that we (the Jones draft authors) had to try as hard > as we could to be backwards compatible with something that's only in draft > form. That's why we put into the Jones draft a backwards compatibility > section, which has holes in it - because it was Christer's lab that was the > only one doing the testing, and the Jones draft authors haven't heard any > new information from him since last summer (even though we've asked that > several questions be answered last August and/or September). > > From the initial indiv-00 version of the Jones draft, that Session-ID has > been in two parts. The Kaplan draft, and what's been implemented before it > reached RFC status, was a 1-part Session-ID. We've made every attempt to > address how a 2-part value can be backwards compatible with a 1-part value, > but there are certain circumstances in which that compatibility just isn't > there. > I find it interesting that Laura's note to the list includes the line "... > Carriers as my employer, where Hadriel's session-id is already implemented, > will never switch to the new identifier...". I remember a company saying > that same thing about the SIP Diversion header, which predated the > History-Info header by like 5 years, and still the History-Info header was > the one to make it to Standard-track RFC. > [MB] Most everyone I know that supports History-Info also still supports Diversion. Also, there was an end run and Diversion was published on the independent stream. So, in the end we lost that battle. Personally, I think this "must be backwards" is a bad idea, but that was the consensus of this WG. [/MB] > > James > > At 09:28 AM 7/30/2013, Andrew Allen wrote: > >> Content-Language: en-US >> Content-Type: multipart/alternative; >> >> boundary="_000_**BBF5DDFE515C3946BC18D733B20DAD** >> 2338DED5BDXMB104ADSrimnet_" >> >> >> >> I also concur with Laura's recollection. That agreement was the basis to >> move forward with the Jones draft as the WG draft. >> >> Andrew >> >> From: Laura Liess [mailto:laura.liess.dt@**googlemail.com >> ] >> Sent: Tuesday, July 30, 2013 06:18 AM Central Standard Time >> To: Hadriel Kaplan >> Cc: DRAGE, Keith (Keith) >; >> insipid@ietf.org >> Subject: Re: [Insipid] draft-ietf-insipid-session-id-**01 >> >> I agree with Hadriel. If I remember correctly, we had an agreement in >> the WG that the identifier defined here has to be backward compatible with >> the session-id identifier defined in Hadriel's draft and that a reference >> to this draft has to be added. >> >> Backward incompatibility with Hadriel's session-id would be a big >> drawback for the implementation of the new identifier within carrier >> networks. Carriers as my employer, where Hadriel's session-id is already >> implemented, will never switch to the new identifier. They will require the >> old identifier for any new systems they buy, including conferencing systems. >> >> Because Hadriel's session-id is used in the 3GPP IMS specificatios, I >> assume that the situation is the same for other carriers using IMS. >> >> Thank you >> Laura >> >> >> >> 2013/7/29 Hadriel Kaplan < >> >hadriel.kaplan@**oracle.com > >> >> >> I think there needs some discussion and justification for why the sess-id >> value order/placement is swapped in SIP responses and upstream requests, >> instead of being kept the same order throughout. This order-changing >> breaks backward compatibility with the older Session-ID individual draft, >> and is arguably harder to use/find in logs and wireshark for >> troubleshooting purposes. I think someone mentioned some reason this >> re-ordering was necessary, but I can't recall what it is and I don't see it >> explained in the draft. >> >> -hadriel >> >> >> On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" <> keith.drage@alcatel-**lucent.com > >> keith.drage@**alcatel-lucent.com > wrote: >> >> > (As WG cochair) >> > >> > As well as reviewing the document generally, it would be useful if the >> WG membership could indicate any issues they think need face to face >> discussion time in Berlin. >> > >> > Or is everything going perfectly? >> > >> > Apart from what is listed below, is anything else missing from the >> document? >> > >> > Regards >> > >> > Keith >> > >> >> -----Original Message----- >> >> From: > >> insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.**org] >> On Behalf >> >> Of Paul E. Jones >> >> Sent: 09 July 2013 00:17 >> >> To: insip**id@ietf.org >> >> Subject: [Insipid] draft-ietf-insipid-session-id-**01 >> >> >> >> Folks, >> >> >> >> I posted a new version of draft-ietf-insipid-session-id for your >> >> consideration. >> >> >> >> One significant addition is one to address a comment Laura had about >> >> ensuring that intermediary devices can consistently re-create a UUID >> and >> >> remain stateless. New text is introduced in Section 4.1 that describes >> >> how >> >> such entities can construct the UUIDs. >> >> >> >> Section 6 was also revised with text to explain that the UUID order >> >> relates >> >> to who sends the message. It also discusses the longevity of the UUID, >> >> logging, and changes to the "remote" UUID. >> >> >> >> Previously, requests were made for additional call flows. Those were >> not >> >> added to the document, but the requests are listed as TODO items in >> >> section(s) under section 9. There is also a TODO for section 9 >> related to >> >> requested changes to section 9 to make it cleared the text is just >> >> examples. >> >> >> >> Paul >> >> >> >> >> >> ______________________________**_________________ >> >> insipid mailing list >> >> insip**id@ietf.org >> >> >> https://www.ietf.org/mailman/**listinfo/insipid >> > ______________________________**_________________ >> > insipid mailing list >> > insip**id@ietf.org >> >> > https://www.ietf.org/mailman/**listinfo/insipid >> >> ______________________________**_________________ >> insipid mailing list >> insip**id@ietf.org >> >> https://www.ietf.org/mailman/**listinfo/insipid >> >> >> ------------------------------**------------------------------**--------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-public >> information. Any use of this information by anyone other than the intended >> recipient is prohibited. If you have received this transmission in error, >> please immediately reply to the sender and delete this information from >> your system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be unlawful. >> ______________________________**_________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/**listinfo/insipid >> > > ______________________________**_________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/**listinfo/insipid > --047d7bdc077440c86104e2cdfea3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 30, 2013 at 9:38 PM, James Polk <<= a href=3D"mailto:jmpolk@cisco.com" target=3D"_blank">jmpolk@cisco.com&g= t; wrote:
I don't con= cur with Laura's recollection.
[MB] Laura's recollection is correct based on the WG = minutes from IETF-85:
The minutes state the following:
Nobody in the room objected against=
 that the draft-jones-insipid-session-id-01.txt describes backward compatib=
ility to the session-id as defined in the Kaplan draft (draft-kaplan-dispat=
ch-session-id).

Chairs - Any objections to the backwards compatibility as described in
-01 version - No objections noted.

Decision: to keep the new draft backwards compatible with regard to draft-k=
aplan-dispatch-session-id
[/MB]

The WG agreement was that we (the Jones draft authors) had to try as hard a= s we could to be backwards compatible with something that's only in dra= ft form. That's why we put into the Jones draft a backwards compatibili= ty section, which has holes in it - because it was Christer's lab that = was the only one doing the testing, and the Jones draft authors haven't= heard any new information from him since last summer (even though we'v= e asked that several questions be answered last August and/or September).
>From the initial indiv-00 version of the Jones draft, that Session-ID has b= een in two parts. The Kaplan draft, and what's been implemented before = it reached RFC status, was a 1-part Session-ID. We've made every attemp= t to address how a 2-part value can be backwards compatible with a 1-part v= alue, but there are certain circumstances in which that compatibility just = isn't there.=A0

I find it interesting that Laura's note to the list includes the line &= quot;... Carriers as my employer, where Hadriel's session-id is already= implemented, will never switch to the new identifier...". I remember = a company saying that same thing about the SIP Diversion header, which pred= ated the History-Info header by like 5 years, and still the History-Info he= ader was the one to make it to Standard-track RFC.
[MB] Most everyone I know that supports History-Info also= still supports Diversion. =A0Also, there was an end run and Diversion was = published on the independent stream. =A0So, in the end we lost that battle.= =A0Personally, I think this "must be backwards" is a bad idea, b= ut that was the consensus of this WG. [/MB]=A0

James

At 09:28 AM 7/30/2013, Andrew Allen wrote:
Content-Language: en-US
Content-Type: multipart/alternative;

boundary=3D"_000_BBF5DDFE515C3946BC18D733B20DAD2338DED5B= DXMB104ADSrimnet_"



I also concur with Laura's recollection. That agreement was the basis t= o move forward with the Jones draft as the WG draft.

Andrew

From: Laura Liess [mailto:laura.liess.dt@googlemail.com]
Sent: Tuesday, July 30, 2013 06:18 AM Central Standard Time
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
Cc: DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com>; insipid@ietf.org <insipid@ietf.org>= ;
Subject: Re: [Insipid] draft-ietf-insipid-session-id-01

I agree with Hadriel. =A0If I remember correctly, we had an agreement in th= e WG that the identifier defined here has to be backward compatible with th= e session-id identifier defined in Hadriel's draft and that a reference= to this draft has to be added.

Backward incompatibility with Hadriel's session-id would be a big drawb= ack for the implementation of the new identifier within carrier networks. C= arriers as my employer, where Hadriel's session-id is already implement= ed, will never switch to the new identifier. They will require the old iden= tifier for any new systems they buy, including conferencing systems.

Because Hadriel's session-id is used in the 3GPP IMS specificatios, I a= ssume that the situation is the same for other carriers using IMS.

Thank you
Laura



2013/7/29 Hadriel Kaplan <<mailto:hadriel.kaplan@oracle.com>hadriel.kaplan@<= /u>oracle.com>


I think there needs some discussion and justification for why the sess-id v= alue order/placement is swapped in SIP responses and upstream requests, ins= tead of being kept the same order throughout. =A0This order-changing breaks= backward compatibility with the older Session-ID individual draft, and is = arguably harder to use/find in logs and wireshark for troubleshooting purpo= ses. =A0I think someone mentioned some reason this re-ordering was necessar= y, but I can't recall what it is and I don't see it explained in th= e draft.

-hadriel


On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" <<mailto= :keith.= drage@alcatel-lucent.com>keith.drage@alcatel-lucent.com&g= t; wrote:

> (As WG cochair)
>
> As well as reviewing the document generally, it would be useful if the= WG membership could indicate any issues they think need face to face discu= ssion time in Berlin.
>
> Or is everything going perfectly?
>
> Apart from what is listed below, is anything else missing from the doc= ument?
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: <mailto:insipid-bounces@ietf.org>insipid-bounces@ietf.org [mailto= :insipid-boun= ces@ietf.org] On Behalf
>> Of Paul E. Jones
>> Sent: 09 July 2013 00:17
>> To: <mailto:insipid@ietf.org>insipid@ietf.org
>> Subject: [Insipid] draft-ietf-insipid-session-id-01
>>
>> Folks,
>>
>> I posted a new version of draft-ietf-insipid-session-id for your >> consideration.
>>
>> One significant addition is one to address a comment Laura had abo= ut
>> ensuring that intermediary devices can consistently re-create a UU= ID and
>> remain stateless. =A0New text is introduced in Section 4.1 that de= scribes
>> how
>> such entities can construct the UUIDs.
>>
>> Section 6 was also revised with text to explain that the UUID orde= r
>> relates
>> to who sends the message. =A0It also discusses the longevity of th= e UUID,
>> logging, and changes to the "remote" UUID.
>>
>> Previously, requests were made for additional call flows. =A0Those= were not
>> added to the document, =A0but the requests are listed as TODO item= s in
>> section(s) under section 9. =A0There is also a TODO for section 9 = related to
>> requested changes to section 9 to make it cleared the text is just=
>> examples.
>>
>> Paul
>>
>>
>> _______________________________________________
>> insipid mailing list
>> <mailto:i= nsipid@ietf.org>insipid@ietf.org

>> https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> <mailto:insip= id@ietf.org>in= sipid@ietf.org

> https://www.ietf.org/mailman/listinfo/insipid

_______________________________________________
insipid mailing list
<mailto:insipid@ie= tf.org>insipid@ietf.org

https://www.ietf.org/mailman/listinfo/insipid


-------------------------------------------------------------= --------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.
_______________________________________________
insipid mailing list
insipid@ietf.org<= br> https://www.ietf.org/mailman/listinfo/insipid

_______________________________________________
insipid mailing list
insipid@ietf.org<= br> https://www.ietf.org/mailman/listinfo/insipid

--047d7bdc077440c86104e2cdfea3-- From Peter.Dawes@vodafone.com Wed Jul 31 05:54:17 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9167F21F99CD for ; Wed, 31 Jul 2013 05:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=-0.943, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVVHjzEchR7E for ; Wed, 31 Jul 2013 05:54:12 -0700 (PDT) Received: from mailout07.vodafone.com (mailout07.vodafone.com [195.232.224.76]) by ietfa.amsl.com (Postfix) with ESMTP id 153C821F9DA0 for ; Wed, 31 Jul 2013 05:54:09 -0700 (PDT) Received: from mailint07.vodafone.com (localhost [127.0.0.1]) by mailout07.vodafone.com (Postfix) with ESMTP id D7EB422178F for ; Wed, 31 Jul 2013 14:54:06 +0200 (CEST) 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.vodafone.com (Postfix) with ESMTPS id CAA9322173F; Wed, 31 Jul 2013 14:54:06 +0200 (CEST) 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.3.146.2; Wed, 31 Jul 2013 14:54:06 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.36]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.03.0146.002; Wed, 31 Jul 2013 14:54:05 +0200 From: "Dawes, Peter, Vodafone Group" To: "Javier Martinez (mjavier)" , "Vijay K. Gurbani" , "insipid@ietf.org" Thread-Topic: [dispatch] Proposed charter for work on logging Thread-Index: Ac4LyOtf/7ujcRPHQoOZ6+wpJgfGIAR6wVFQEpuAXZAAEl09AAFUv0EQATHPHoAG2YcJIA== Date: Wed, 31 Jul 2013 12:54:05 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917F3@VOEXM31W.internal.vodafone.com> References: <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6D673@VOEXM31W.internal.vodafone.com> <51BA382E.4040605@bell-labs.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6EC89@VOEXM31W.internal.vodafone.com> <040624DCD17A4644A389FC9078A50B7541011B@xmb-rcd-x10.cisco.com> In-Reply-To: <040624DCD17A4644A389FC9078A50B7541011B@xmb-rcd-x10.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] [dispatch] Proposed charter for work on logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:54:17 -0000 Hi Javier, I am replying on the insipid mailing list as discussion has moved here from= dispatch.=20 The scenario you describe is what motivated the requirements draft and it w= ould be very helpful to hear your views as discussion progresses. Regards, Peter -----Original Message----- From: Javier Martinez (mjavier) [mailto:mjavier@cisco.com]=20 Sent: 26 June 2013 19:56 To: Dawes, Peter, Vodafone Group; Vijay K. Gurbani; dispatch@ietf.org Subject: RE: [dispatch] Proposed charter for work on logging Hi Peter, I agree with the utility of the marker proposal. In large SIP network deplo= yments it is a challenge collecting logs and debug traces during trouble s= hooting sessions, even with a single vendor deployments. In most situation= s you end up with large amounts of data to sort through to extract the sess= ions, or files of interest from multiple boxes, in others you end up missi= ng pieces of information. There is a need for an automated way to extract the specific logs of intere= st in multi-vendor deployments. This proposal is also a great complement to the "End-to-End Session Id" pr= oposal. I would be glad to help in any way to get an implementation proposal going, Regards Javier -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dawes, Peter, Vodafone Group Sent: Thursday, June 20, 2013 8:05 AM To: Vijay K. Gurbani; dispatch@ietf.org Subject: Re: [dispatch] Proposed charter for work on logging Hi Vijay, The utility of a marker is that currently there is no SIP protocol mechanis= m to indicate that signalling is of interest to logging, so it is not a log= ging format issue but an issue of making regression testing and troubleshoo= ting scaleable by not having to log everything.=20 Thanks for the pointer to RFC 6872, I will take a look at it. Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Vijay K. Gurbani Sent: 13 June 2013 22:23 To: dispatch@ietf.org Subject: Re: [dispatch] Proposed charter for work on logging On 06/13/2013 06:17 AM, Dawes, Peter, Vodafone Group wrote: > Hello All, Following on from the comments at IETF#86=20 > (http://www.ietf.org/proceedings/86/minutes/minutes-86-dispatch), > where there was mild support for working on logging, I have updated=20 > the log me requirements draft with 3 potential solutions (in clause > 7) which can meet the requirements > (http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-02.t= xt). > Opinions and comments on these or any other potential solutions would=20 > be very welcome. Peter: I am not being a contrarian, just being curious. What is the utility of a log-me marker if all traffic is logged through a m= echanism such as SIP CLF? > It was commented at IETF#86 that a security analysis is needed so I=20 > would like to understand if any scenarios exist with potential=20 > security threats in order to add them to requirements. In many cases,=20 > a network simply logs the signalling that passes through it so no new=20 > security issues are created. Collecting end-to-end logging for=20 > signalling that crosses multiple networks must not compromise security=20 > or privacy, but I would expect networks to remove any security=20 > sensitive fields before forwarding signalling regardless of whether=20 > that signalling is of interest to logging. We went through discussions related to all of the above points during the S= IP CLF work. See the Security Consideration section of [1]; it may provide= you some answers. [1] http://tools.ietf.org/html/rfc6872 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___= ____________________________________________ 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 hadriel.kaplan@oracle.com Wed Jul 31 07:34:00 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC621E811D for ; Wed, 31 Jul 2013 07:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSXKo3DDuOeH for ; Wed, 31 Jul 2013 07:33:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A003C21F962D for ; Wed, 31 Jul 2013 07:33:53 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6VEXomr031145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 14:33:51 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VEXn18025948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 14:33:50 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VEXnoA026029; Wed, 31 Jul 2013 14:33:49 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jul 2013 07:33:49 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE91746@VOEXM31W.internal.vodafone.com> Date: Wed, 31 Jul 2013 10:33:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <72B7836E-BA8A-4473-8A3D-2FD391AB62FC@oracle.com> References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> <51F8E5F3.6050101@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE91746@VOEXM31W.internal.vodafone.com> To: "Dawes, Peter, Vodafone Group" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "insipid@ietf.org" , Paul Kyzivat Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:34:00 -0000 On Jul 31, 2013, at 8:01 AM, "Dawes, Peter, Vodafone Group" = wrote: > The question from Gonzalo was about REQ3: >=20 > REQ3: The solution must require that the identifier, if present, pass > unchanged through SIP B2BUAs or other intermediaries. >=20 > My interpretation was that 1) the solution document must contain the = text "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID = header field value." and 2) no future drafts/RFCs are allowed to specify = that a SIP B2BUA or intermediary may change the Session-ID header field = value. Right. It's kinda silly requirement wording, but yes ISTM that a = statement in a solution document stating "SIP B2BUAs or other = intermediaries MUST NOT change the Session-ID header field value", would = indeed satisfy REQ3.=20 > This is simplistic but I think it meets REQ3. The discussion on = Gonzalo's question seems to me to be about a different requirement along = the lines of "how the Session-ID header field is generated and used must = be compared with generation and use of header fields that a SIP B2BUA or = other intermediary removes or modifies to ensure that a SIP B2BUA or = other intermediary does not have any reason to remove the Session-ID: = header field." Yup. Basically a "why do we think the MUST statement generated by REQ3 = would actually be followed or not". -hadriel From pkyzivat@alum.mit.edu Wed Jul 31 09:50:31 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA33921E80CB for ; Wed, 31 Jul 2013 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRIhG2YL5FJc for ; Wed, 31 Jul 2013 09:50:26 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id E76B121E808D for ; Wed, 31 Jul 2013 09:50:20 -0700 (PDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 71lw1m0081wfjNs014qJPj; Wed, 31 Jul 2013 16:50:18 +0000 Received: from dhcp-4066.meeting.ietf.org ([130.129.64.102]) by omta23.emeryville.ca.mail.comcast.net with comcast id 74o31m00q2CN8kq8j4o6xo; Wed, 31 Jul 2013 16:48:15 +0000 Message-ID: <51F93FC3.40206@alum.mit.edu> Date: Wed, 31 Jul 2013 18:48:03 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> <51F8E5F3.6050101@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE91746@VOEXM31W.internal.vodafone.com> <72B7836E-BA8A-4473-8A3D-2FD391AB62FC@oracle.com> In-Reply-To: <72B7836E-BA8A-4473-8A3D-2FD391AB62FC@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=1375289418; bh=V+sJ07+5S132LFYoN7xkxAB0dgIRQpI6BF5C9Pa2Wz8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=h2dNwyLX/Dqhcgr5HDLmMfu+1m326kH31ws678oc3LGhVC9rUbPTQBpVC7d/27mLT UajtGMffjiQXZQUsSHQIH8yenbxDZ3DJO0EWAJVwc+IR7PKuGA3jXrFLEoCi8HbLBd kxWzDylpb7uCK4c8PdHSjXhxY1q5uAIaJHX40/ufuvMpfPdJ8CT6tTD6Te64H7Ern+ hZJYp0lMqRNmyrHMTn8zBVOEsSgh/5bpY5Sw5wlDGrvapFt3zd9BDTk1+HlN8E2J4Q gmPQHUtSXw4VZNrkDb8JVOmiwBmp0h3k98GerQy34dd9vLfIrKTFidAToz+U3pAn+D VnRi2TU2l9exQ== Cc: "Dawes, Peter, Vodafone Group" , "insipid@ietf.org" Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 16:50:32 -0000 On 7/31/13 4:33 PM, Hadriel Kaplan wrote: > > On Jul 31, 2013, at 8:01 AM, "Dawes, Peter, Vodafone Group" wrote: > >> The question from Gonzalo was about REQ3: >> >> REQ3: The solution must require that the identifier, if present, pass >> unchanged through SIP B2BUAs or other intermediaries. >> >> My interpretation was that 1) the solution document must contain the text "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header field value." and 2) no future drafts/RFCs are allowed to specify that a SIP B2BUA or intermediary may change the Session-ID header field value. > > Right. It's kinda silly requirement wording, but yes ISTM that a statement in a solution document stating "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header field value", would indeed satisfy REQ3. > > >> This is simplistic but I think it meets REQ3. The discussion on Gonzalo's question seems to me to be about a different requirement along the lines of "how the Session-ID header field is generated and used must be compared with generation and use of header fields that a SIP B2BUA or other intermediary removes or modifies to ensure that a SIP B2BUA or other intermediary does not have any reason to remove the Session-ID: header field." > > Yup. Basically a "why do we think the MUST statement generated by REQ3 would actually be followed or not". Because if they don't follow it then any product that wants to claim conformance to a feature that requires session-id will fail in the presence of such B2BUA. If those features are themselves valuable, then people will demand products that conform to them. Yes, I know that is naive, but its all the leverage we have. Thanks, Paul From hadriel.kaplan@oracle.com Wed Jul 31 15:56:52 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E016621F9301 for ; Wed, 31 Jul 2013 15:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxrBai0zO68B for ; Wed, 31 Jul 2013 15:56:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5819621F9DBD for ; Wed, 31 Jul 2013 15:56:46 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6VMuiv1018951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 22:56:45 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VMuhvg000292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 22:56:44 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VMuhr9021379; Wed, 31 Jul 2013 22:56:43 GMT Received: from [10.13.52.222] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jul 2013 15:56:43 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51F93FC3.40206@alum.mit.edu> Date: Wed, 31 Jul 2013 18:24:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DBF0FDC-8866-4957-BEA6-8C1D7A4617FF@oracle.com> References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> <51F8E5F3.6050101@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE91746@VOEXM31W.internal.vodafone.com> <72B7836E-BA8A-4473-8A3D-2FD391AB62FC@oracle.com> <51F93FC3.40206@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: insipid@ietf.org Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 22:56:53 -0000 On Jul 31, 2013, at 12:48 PM, Paul Kyzivat = wrote: >>> This is simplistic but I think it meets REQ3. The discussion on = Gonzalo's question seems to me to be about a different requirement along = the lines of "how the Session-ID header field is generated and used must = be compared with generation and use of header fields that a SIP B2BUA or = other intermediary removes or modifies to ensure that a SIP B2BUA or = other intermediary does not have any reason to remove the Session-ID: = header field." >>=20 >> Yup. Basically a "why do we think the MUST statement generated by = REQ3 would actually be followed or not". >=20 > Because if they don't follow it then any product that wants to claim = conformance to a feature that requires session-id will fail in the = presence of such B2BUA. If those features are themselves valuable, then = people will demand products that conform to them. It's not the "products that conform to them" that's the issue, it's = whether the operators/admins of the products want them to do it and = whether it's possible to do without breaking something else. =20 Take the Call-ID header, for example - even if there weren't a security = problem with revealing IP Addresses, fundamentally there are call = scenarios that simply don't work if the Call-ID is left unchanged by = B2BUAs. Some of the scenarios are very subtle and only show up in = certain deployments; others are more obvious, like out-of-dialog REFER = handling. B2BUA products don't change the Call-ID because it's fun, = they change it to make things *work*.[1] So if a new feature/mechanism = is defined in the IETF which relies on Call-ID remaining unchanged, it = doesn't matter if the product vendor and owner/admins want to support = the new feature; it's giving them a choice of: "to get this new feature, = you must break other features". > Yes, I know that is naive, but its all the leverage we have. It's not naive - it *is* all the leverage we have. The entire concept = of INSIPID and STRAW docs is that a purchaser of equipment who wants = feature X in RFC Y, tells its vendors to comply with RFC Y; if the = vendors don't do RFC Y, then they can't have feature X.=20 The challenge is when we use RFC Y to accomplish multiple different = features Z and W, we run the risk that not all of X+Z+W are achievable = simultaneously, in practice. So in the Session-ID case, if it turns out = a SBC has to change a Session-ID to match/not-match others in order to = make calls work right, vs. leaving it alone for troubleshooting = purposes, it will invariably choose to change it to make calls work = instead of help troubleshooting, as will its owner. Calls have to = work... the spice must flow. Thus when faced with the STIR stuff needing to do caller-id = verification, in my opinion it would be safer to not use Session-ID, = than rely on it surviving e2e. I don't *know* it won't survive e2e, = since Session-ID hasn't gotten much deployment yet. It's just a hunch = based on the use-cases people have in mind for it. They're not "benign" = use-cases; they affect calls failing or succeeding. -hadriel [1] This isn't entirely the case - I've been told by some B2BUA vendors = that their internal architecture limits their ability to do certain = things transparently, such as Call-ID handling. I won't name who they = are because I was told in confidence, but they don't all attend the IETF = and it's not my place to represent their views/issues. From paulej@packetizer.com Wed Jul 31 21:38:16 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B2621F9B60 for ; Wed, 31 Jul 2013 21:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1onf34PHs0En for ; Wed, 31 Jul 2013 21:38:11 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D593B21F8EFE for ; Wed, 31 Jul 2013 21:38:10 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r714c8nc021911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Aug 2013 00:38:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375331888; bh=kjztwlllic5sOIs91v7b/1GZC13mukLPWMX+EZXuQSs=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=X89YpUzPqsTzmAYjMfL1v0Eiaa0o+aGmNxTCj2c3lj3TwePr4vs34HGOMIlHp+5je p7zl6h6n8Z3dTZuX6n9HE1AbuSP0TasdxpQVQpSaI29OK35bNrbD0G+prETpKMDY/3 Swui0cNLM9pyHgehk0iZ2jkxL+sZQZzvdGqEXBiM= From: "Paul E. Jones" To: Date: Thu, 1 Aug 2013 00:38:16 -0400 Message-ID: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6ObL8bHmdBy9j3R4y13v8TdvwiwQ== Content-Language: en-us Subject: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 04:38:16 -0000 Folks, I step away for a couple of days and the floodgate opens. :) I think it's important to understand why we proposed using a two-part Session Identifier. The reason is that we have to be able to effectively deal with things like forking, call transfer, park, bridging, conferencing, etc. When initiating a call and using a single UUID value, that has the potential to go end-to-end. However, if a call is forked there are multiple "ends". How do we track each of those? For proper diagnostics and troubleshooting, it would be ideal to be able to identify which devices have an issue. Once a call has been placed, there is a Session-ID established between Alice and Bob. If Alice (in one country) transfers Bob (perhaps in the same or different country) to a some location in a high-toll country, who pays the bill? Well, to address that, we do call transfer locally on PBXes. The PBX maintains control over the call and Alice would pay the bill for the call transfer. But if Alice was talking to Carol before the transfer, there is a Session-ID for that call. If Bob is put in communication with Carol, what is the Session-ID value? Bob had one and Carol had a different one. What is the new ID? It's issues like this that led us to using a two-part value. In this way, we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice transfers the call to Carol, each device understands that the Session-ID changed to {B,C}. Not only that, but intermediaries along the path that were not privy to signaling that resulted in this change can take note of the fact the value changed. This can provide a useful historical record, since previously they might see a call to Carol identified as {A,C}, but then it changed to {B,C}. This property extends quite naturally to other signaling scenarios, as it allows one to identify a call end-to-end, but also establish some relationship between other calls that shared at least one UUID value out of the two. Hadriel mentioned the desire to use the Session-ID to correlate media flows and calls. That's certainly something Cisco would like to do, but it is not the driver behind the solution. Having a valid end-to-end identifier (in whatever form) allows us to do that. We're not suggesting to fit the solution to meet that business use case, but rather we just want a solution that allows us to properly identify calls end-to-end and we recognize that, due to various service interactions in the network, these UUID values can change. I would hope that UUID values will not change to the extent that SBCs change them for business reasons. It would certainly defeat the point. Hadriel might be right that an SBC vendor might manipulate those values at the request of a customer, but I would hope said customer appreciates that such a request effectively breaks the end-to-end model. We can't do much about that if they do go down that path. As for backward-compatibility, the simplest approach (IMO) is to just use a header value not already in use. Originally, we had proposed Session-UUID. That was changed at the request of the group to be Session-ID. However, when we have a two UUID solution interacting with a one-UUID solution, we immediately face some challenges. What happens if an older system sends this: Session-ID: X But then receives this: Session-ID: Y; remote=X Does this break things? If so, how do current implementations deal with such things as mid-call transfers that happen on a PBX like the one I described above? We could switch the order like this: Session-ID: X; remote=Y However, that does not work for similar reasons. If we have a call transfer where Alice transfers a call with Bob to Carol, then each has a different idea about what the proper value is for the first position. Originally, the proposed solution did not indicate position information and just had single UUID values going in each direction. We then proposed a concatenated string (X:Y). However, that presented the same issues for the call transfer case, so we indicate values by position (sender's value first), so it is clear what value the receive thinks the remote end has for the local end. It might be wrong, but that will be corrected in the following response. (Intermediaries can take note of the change.) So, that's why we are where we are. There has been an effort to maintain backward-compatibility, but there are challenges in meeting that requirement. Where it falls short, we do not know: we've not been told explicitly what the issues are. Further, if there are such issues, we need to also understand how those would be handled in the face of call transfer or "joining" a call locally on a PBX. Those are real-world scenarios that we must address. Anyway, nothing is set in stone. Anything can be changed, but I would hope we can find a solution that works for the enterprise use cases as well as the service provider networks. Paul