From nobody Thu Apr 3 13:55:53 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185861A0197 for ; Thu, 3 Apr 2014 13:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVxbJ3LjUOmX for ; Thu, 3 Apr 2014 13:55:46 -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 4728F1A0186 for ; Thu, 3 Apr 2014 13:55:46 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta15.westchester.pa.mail.comcast.net with comcast id lWmt1n0090SCNGk5FYvhVY; Thu, 03 Apr 2014 20:55:41 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta09.westchester.pa.mail.comcast.net with comcast id lYvh1n00M1KKtkw3VYvhf6; Thu, 03 Apr 2014 20:55:41 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s33Kte3Q009520; Thu, 3 Apr 2014 16:55:40 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s33Ktea1009519; Thu, 3 Apr 2014 16:55:40 -0400 Date: Thu, 3 Apr 2014 16:55:40 -0400 Message-Id: <201404032055.s33Ktea1009519@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Andrew Allen In-reply-to: (aallen@blackberry.com) References: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396558541; bh=8TvyVENyDNkzbo3mdqxCo84SeIFv/HhUUXBngHjthW8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=V5Fs2R0EXyEcw+Cjwud3BML647ELZkW2KS86bZ/S9/Y4RH6uk9QmtKj0ZBWCPuoQt +uMfsh7tnbFS6moBdqLFV3lNNOmG6bAHgqu+lsoM8a9o3Eh+yZt9krPUpRi6FMnw5V d4tac1XBs2lHIsrjpWfYxcJD4p1vL3/K4Xf9OYEeWxZpbvnzQem03BIISqYgCkdxiR OWbPJ2+wE/qtkBNwFZoI0Z+AwhEnpPjskbXjnAGxKmSoPGL+uP9R4jC2l5oEbQbmDL 9sR9+uBNuDwzj3UPQQdSKgCVcz6eewd31y/4UyIK3Rdp71PNOip5OkJ5WlONT18hD/ 4B7YDdT2p+UIQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Q2bqaz8uvCg1_cKOVtNc0P2PLKg Cc: sipcore@ietf.org Subject: [sipcore] B2BUAs and Contact header field parameters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 20:55:51 -0000 > From: Andrew Allen > > In addition as I state in my draft modifying the Contact header > field means either the media feature tags of the remote UA are lost > or the B2BUA is saying if you send a request to this address > (including potentially after this session has ended) you can expect > that this feature is supported. > > Having B2BUAs only include feature tags they understand to my view > means no innovation and no new services. B2BUAs have then become the > switches of old needing all to be updated or reconfigured to support > any new services. > From draft-allen-dispatch-routing-out-of-dialog-request-00: One way B2BUAs have have addressed this problem is by acting as two UAs back-to-back with the Contact URI being overwritten to be the URI of the B2BUA. However this means that GRUU of the UA is overwritten by the B2BUA and the meaning of the Contact header field parameters becomes obscure. Do the Contact header field parameters reflect the capabilities of the Contact address (i.e the B2BUA) or do they capabilities of the B2BUA then the identfication of the capabilities of the remote UAS has been lost. If they reflect the capabilities of the remote UA then they falsely identify that the B2BUA contact address has the capabilities of the remote UA. Looking again at draft-allen-dispatch-routing-out-of-dialog-request-00, I don't think you explicitly describe a mechanism to fix this problem. I believe that the implied solution is that in the new dialog, the contact URI remains the same as that of the far end of the original dialog, and the media feature tags of the contact URI are maintained, that is, they describe the far end of the original dialog. It seems to me that the "natural" way to avoid this problem is that when a B2BUA passes through a dialog, it needs to provide as its contact URI in the new dialog a URI which is connected in some manner with the contact URI of the far end of the original dialog. That is, different outgoing dialogs are going to need different contact URIs, precisely so that the B2BUA can forward incoming OOD requests to the correct destination. I've been calling these URIs "contact aliases", and I think that is what Hadriel means by "global contacts" (when they aren't also marked as GRUUs). Within this context, the media feature tags on different contact URIs can be different (since the other entities should not be confusing the media future tags of different contact URIs). Which media feature tags the B2BUA passes through from the original request should depend on its policies and the support that it provides for the various media features. That is, the media feature tags on the outgoing request describe the media feature tags of the original far end *as they are accessible through the B2BUA*. However, I've not had to deal with this problem in practice. Are there impediments to this "natural" solution? Do you have specific examples of problems that need to be avoided? Dale From nobody Thu Apr 3 14:20:16 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337041A02A6 for ; Thu, 3 Apr 2014 14:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp-Ma4sFq5Vl for ; Thu, 3 Apr 2014 14:20:02 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 5599D1A029B for ; Thu, 3 Apr 2014 14:20:02 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id lTuj1n0081ap0As55ZKyDv; Thu, 03 Apr 2014 21:19:58 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id lZKx1n00J1KKtkw3iZKxfR; Thu, 03 Apr 2014 21:19:57 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s33LJuTs010814; Thu, 3 Apr 2014 17:19:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s33LJuB7010813; Thu, 3 Apr 2014 17:19:56 -0400 Date: Thu, 3 Apr 2014 17:19:56 -0400 Message-Id: <201404032119.s33LJuB7010813@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Hadriel Kaplan In-reply-to: (hadriel.kaplan@oracle.com) References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <201403211931.s2LJVs4B010647@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396559998; bh=CoX9Up5pIUQyZu2tZpnEf7x3N9XWYsk1UBtemBj3SLQ=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Wa1xuyyTjJh+iVN7L7VQZbAV1CULP0m5PxObrWJ4QC4OaflL93eKkR3laNnvTuSPW YgX/E1EaYcc8WX4GO3joivkNm9mHcdQKermClT8x0kdwVYXdkBZIZIGnszvP06VsD0 skyAOcx0wQfJoH3JoIBUZcRi9Kvcjg1sLGFLN+MyeM9C8AVl0GJdQutkpa6veJFNXc SHGJQK7czzc29p33p9fi5ax9wYNI4ipC3TFNQCDTa58M4RCaf1zz8JoUkSsCj+1rgN JkuNDeoeZK+SITmTmSxdEEFF+7DDKWYPCHq2Je+YdnYmWkr59Dy4MXiLbZdrCk+uQZ QZTrxGxSJFQNA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/xEMi4T_yaI4gBcEgqvclUeYUCEs Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 21:20:11 -0000 > From: Hadriel Kaplan > > On Mar 21, 2014, at 3:31 PM, Dale R. Worley wrote: > > I'm curious what you mean by "just behave like they're normal contact > > URIs". My understanding is that the contact URI is used for whatever > > it's used for *because* it's the contact URI. If it's marked as a > > GRUU, that presumably is a hint that your odds of success are higher, > > but what would you do differently? > > You would send out-of-dialog REFERs, and you could (in theory) store > the GRUU for future use indefinitely, such as in an address book. When you say "You would send out-of-dialog REFERs", it sounds like this is the *bulk* of the problems you're encountering. So let me ask, "If no UA ever sent out-of-dialog REFERs, would the problems you see with GRUUs vanish?" Obviously, one shouldn't retain GRUUs indefinitely, since they're not addresses of record, and they're intrinsically bound to specific contact addresses, which are expected to change. In a perfect world, 3261 would be updated so that the From/To URI provided by the far end would always be its AoR, so that the near end could store it properly. (Whereas now, the destination's From/To URI is fixed by the originator. IIRC, there is a proposal out there to change this, but there has been nervousness about whether it is upward-compatible with current systems.) > [A global contact is] just a Contact URI that encodes information in > itself such that it's uniquely related to the original Contact for > the original dialog. This sounds like what I've been calling a "contact alias". > The userinfo portion has sufficient information for the SBC to > figure out which original Contact URI to use as a target for an > out-of-dialog request (or to match to some internal dialog state). Of course, the additional information could be put into a URI parameter instead of the userinfo. Dale From nobody Sun Apr 6 18:43:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749361A063B for ; Sun, 6 Apr 2014 18:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAfTZtfqMaCr for ; Sun, 6 Apr 2014 18:43:12 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 52A831A01F0 for ; Sun, 6 Apr 2014 18:43:12 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta10.westchester.pa.mail.comcast.net with comcast id mpWR1n0021ZXKqc5Apj69i; Mon, 07 Apr 2014 01:43:06 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id mpj61n00X1KKtkw3hpj6l4; Mon, 07 Apr 2014 01:43:06 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s371h5Rm024145; Sun, 6 Apr 2014 21:43:05 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s371h4xT024144; Sun, 6 Apr 2014 21:43:04 -0400 Date: Sun, 6 Apr 2014 21:43:04 -0400 Message-Id: <201404070143.s371h4xT024144@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) To: Andrew Allen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396834986; bh=xBcXS+qnk4k62Ontnu46tWVB4ddG0Ul+Xnfw/UfeEuc=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=vAJJ4ROvESVAN0nLfneNEDEfvSvnfFQHE79Ez+aZz2UGCOR2EL0wQ3EKrv5WF+rx5 9UDnH9NMXTqBKIWZFqXG4kOrcmUjQt2i/xxtKAbSwO63ZAIKjMWgTy1tuubT2VcFDi QeWurUvXpWZEJMgR3NPZX4JcPQSz28pzO9ZePj5ofWVou0lSZY9pwComfwCaWaKx88 36FSnPl7BTgIRtMKdSaGD1v95uiK4PGHCzgKJqsS0KdeEbpMY4gxclidQxDMkZgsxH qop1I3DGaqQHmMQo0fJsiAWdtBXSw5x9zSRLkyuSk6nGCIGFPhVQ3NmfTapRgNqB2t oVvPOE+cQsXrA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/yscd0RyNotBTthXQLux9sE1O3Y0 Cc: sipcore@ietf.org Subject: [sipcore] Recording the addresses of intermediaries for OOD requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 01:43:17 -0000 draft-allen-dispatch-routing-out-of-dialog-request-00 says in section 2: What is needed is a way for intermediaries that need to receive and manipulate or process mid session requests to indicate that mid session out of dialog requests that relate to the dialog of the session being established, to indicate a URI to be included in the Route header of such out of dialog requests so that the request will route by the intermediary. One question that arises is if a dialog passes through two intermediaries that need to record themselves this way. Whatever mechanism is used must be able to record (implicitly or explicitly) the addresses of two or more intermediaries. This doesn't seem to be intrinsically difficult for any of the proposed mechanisms (section 3), but the use of the chosen mechanism in case of multiple intermediaries needs to be documented if it is not implicitly specified by other parts of SIP. One potential solution that is not listed in section 3 is the use of a header part of the Contact URI to provide a Route header for the OOD request. (This has been mentioned before.) E.g., Contact: ua@example.com?Route=%3csbc%40example.com%3blr%3e specifies a Route header "". This would be somewhat more verbose than some of the proposals (new header field, new rr-param), but about as verbose as others (new URI parameter). Since this mechanism is already implemented but is not considered a solution to the problem, there is presumably a reason why it is not workable. That should be documented in the draft. Dale From nobody Tue Apr 8 13:49:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8661A070E for ; Tue, 8 Apr 2014 13:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUXcRXwKTmeA for ; Tue, 8 Apr 2014 13:49:14 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id EB4A71A06E5 for ; Tue, 8 Apr 2014 13:49:13 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta08.westchester.pa.mail.comcast.net with comcast id nWsN1n00317dt5G58YpDpU; Tue, 08 Apr 2014 20:49:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id nYpD1n00T3ZTu2S3ZYpDvf; Tue, 08 Apr 2014 20:49:13 +0000 Message-ID: <534460C9.6050907@alum.mit.edu> Date: Tue, 08 Apr 2014 16:49:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <201404070143.s371h4xT024144@hobgoblin.ariadne.com> In-Reply-To: <201404070143.s371h4xT024144@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396990153; bh=Vmu7AW79zmV04xzHn8gD5dgaBfSEKPsha9mJebbS3/I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WAu2LTWyP+EzJoIq5Cw2HCAtxfj7luenhCOwFsNm0ZJI8CkHEvqwqDW2/5wWAVry1 ZjMqGqSr2Gp5wDHHAZBsXDZJ8VyqhayvBPNKdBw/ai7v6urUPRbd/8ArPbR0HDS9Kv qrmKOMA+Uul7YnAgaLhBrMKRxRZezDRoUuod2J0KM9dBlPrEOU4Uz64hsuLyGFnQ+o oQCLeLZGkUXuRC4IDKAbJTzK0Q7TC5UXI5AbyHKtGHI1C8ZIoj+WEm6THkX7mb5TJ3 8KUTuzv5zFM3c1tJbAw/qQUOi8u2/Vs6JyMyEGKr+N+X5Z3RwFpDUdrjpvYG+PwSvI /y8ll8SzAOSfQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/1GWOWF_IrzgXznB3hX8SVh4jlxk Subject: Re: [sipcore] Recording the addresses of intermediaries for OOD requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 20:49:15 -0000 On 4/6/14 9:43 PM, Dale R. Worley wrote: > One potential solution that is not listed in section 3 is the use of a > header part of the Contact URI to provide a Route header for the OOD > request. (This has been mentioned before.) E.g., > > Contact: ua@example.com?Route=%3csbc%40example.com%3blr%3e > > specifies a Route header "". This would be > somewhat more verbose than some of the proposals (new header field, > new rr-param), but about as verbose as others (new URI parameter). > > Since this mechanism is already implemented but is not considered a > solution to the problem, there is presumably a reason why it is not > workable. That should be documented in the draft. IMO, if this is a problem that needs solving, then this seems like a good solution. When using URIs with embedded header fields, there are already warnings to consider carefully which ones to trust and which ones not to. That applies here. But it applies regardless of the solution. Another issue is how this route is to interact with any other route that the client is predisposed to use for new OOD requests. (E.g., an outbound proxy.) Does this route *replace* that? Or is it *merged* in some way? Thanks, Paul From nobody Wed Apr 9 08:47:01 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E5D1A0392 for ; Wed, 9 Apr 2014 08:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rWJFZzhnRlJ for ; Wed, 9 Apr 2014 08:46:57 -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 48D3F1A032F for ; Wed, 9 Apr 2014 08:46:57 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id no321n0031vXlb85FrmwC6; Wed, 09 Apr 2014 15:46:56 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta17.westchester.pa.mail.comcast.net with comcast id nrmw1n00C1KKtkw3drmwVS; Wed, 09 Apr 2014 15:46:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s39FktqW009032; Wed, 9 Apr 2014 11:46:55 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s39Fkt7S009031; Wed, 9 Apr 2014 11:46:55 -0400 Date: Wed, 9 Apr 2014 11:46:55 -0400 Message-Id: <201404091546.s39Fkt7S009031@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <534460C9.6050907@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201404070143.s371h4xT024144@hobgoblin.ariadne.com> <534460C9.6050907@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397058416; bh=ufd9IFNbewl6pYjQsZv8E99jB/R3VWYiC1m26opL3AQ=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=CkFr6+xpM9AI467I8o6cimwgh7TMUF7kJ/WhfOlfrvqkF737aOT2JxU36/DI2xyhs blwlo6pCgDf4JsYutQ0oXSCwS/1BH7z6bNLNbJBi5IfplG+0lBIxCcCpPWdCo0Vr6m 2mFQ0A723f6g0FFsWPkWmaZBUimroAthbuxI34MF4TZBB09VVZIdvyteQqQz3RcPhr yTx0Bwhp+WNdMKQgTFv7HkaI0YTYkZb0KCGWv4yMLpAR1sDtFm4KwBeIR7rfc/OVyK LuyFMOyRzcCUdE7z5Rk9rFqCiZVmyxQT3qPmXLS4pag9pwm0vCvCC+yb/8XF9YR6hT nyHRTcFWj0aRg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/6BpFX0kjCg7RZAkepDoNLK2UIUE Cc: sipcore@ietf.org Subject: Re: [sipcore] Recording the addresses of intermediaries for OOD requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:46:59 -0000 > From: Paul Kyzivat > > IMO, if this is a problem that needs solving, then this [using > ?Route=...] seems like a good solution. > > When using URIs with embedded header fields, there are already warnings > to consider carefully which ones to trust and which ones not to. That > applies here. But it applies regardless of the solution. The baseline advice is in RFC 3261 section 19.1.5, "Forming Requests from a URI". Though it says: An implementation SHOULD NOT honor any requested Route header field values in order to not be used as an unwitting agent in malicious attacks. I have a vague memory that the current BCP has a different opinion. And any technique that specifies intermediaries for OOD dialogs will present similar problems regarding attacks. > Another issue is how this route is to interact with any other route that > the client is predisposed to use for new OOD requests. (E.g., an > outbound proxy.) Does this route *replace* that? Or is it *merged* in > some way? I've been assuming that the configured outbound proxy is put as the first Route value and the Route(s) specified in the URI follow it. That is, the request goes first to the outbound proxy, which then forwards it to the first specified Route URI. But I don't have any practical experience with the situation. Again, any technique that specifies intermediaries for OOD dialogs will present similar problems. We probably need to specify how it is to be handled in order to prevent chaos. Does anyone have practical experience with this? Dale From nobody Thu Apr 10 09:11:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1251A01FF for ; Thu, 10 Apr 2014 09:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVafgltz580j for ; Thu, 10 Apr 2014 09:11:05 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id ADC471A023A for ; Thu, 10 Apr 2014 09:11:05 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id oBxa1n00127AodY5AGB4fX; Thu, 10 Apr 2014 16:11:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id oGB41n00d3ZTu2S3fGB4Uy; Thu, 10 Apr 2014 16:11:04 +0000 Message-ID: <5346C298.3030601@alum.mit.edu> Date: Thu, 10 Apr 2014 12:11:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: SIPCORE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397146264; bh=413dOjanP4/RFbN4w7aBt0xi5Gmi1lLtDQjpBoewsCA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rSDsx7j2+cTc3jMzwC2mZj2CB1NfhXhn6U84zxrxcH9BIu9Qsn4o9BqpKcjNmYY86 e1P8SmHc1XCB9KP8Gv867mhXc0pZ/VcTRCdj5EwjMaIx4KfaR2/jsZ/K4SeKE+L+Lr qEm4DSW7Lw9iziFDlrQAG1gwAyuJdW2v38SMXsX9EEUJfkIBqbGYbuFKwxObxZEI3q dIwLmt83rGv7papFYxPLH7Ip2QMGiKH/kAGsz9dcyYuDmnfWXZ6bDyOfyFZ5mjUuFg zVLv3xyZ6Q8qUMvTintcUWvmMQmivnlOOw7+vRm6zZzchA3bd2VMMLV1ULtFtVIg1G EMzKiGQAhsBeg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/PfZBBbIyD8lSj7gWmC8V1wsjr4w Subject: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 16:11:07 -0000 Gonzalo, Thanks for the poke. Yes, we agreed on milestone text: June 2014 Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs And we said we would make a formal call for adoption. ** This is a formal call for adoption of draft-johansson-sip-dual-stack as a WG draft. Please indicate your preference for adopting this draft, pro or con, on this maililng list. (Note: adopting the draft doesn't mean it will be published as-is. Further edits will be based on wg consensus.) Thanks, Paul (as sipcore co-chair) On 4/9/14 1:19 PM, Gonzalo Salgueiro (gsalguei) wrote: > Hi Chairs - > > With respect to the following item from the SIPCORE meeting in London: > > ++++++++++++++++++++++++++++++++++++++++ > * draft-johansson-sip-dual-stack > > Action: split the action item into two: one for the DNS part, and another for the remainder of Happy Eyeballs. Discuss the milestone text on the list. > > Action: call for adoption of draft-johansson-dispatch-dane-sip on the list for the DNS part. > ++++++++++++++++++++++++++++++++++++++++ > > > The first action item was one I sent to the list weeks ago: http://www.ietf.org/mail-archive/web/sipcore/current/msg05992.html > > There have been no arguments against the two word edit to the previously agreed upon milestone. Is it OK to move froward with the edit? > > Can we begin the call for adoption of the draft in question, so the work can begin to progress? > > Cheers, > > Gonzalo > From nobody Thu Apr 10 09:34:46 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC951A0330 for ; Thu, 10 Apr 2014 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSbLvRvzfa8I for ; Thu, 10 Apr 2014 09:34:43 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with SMTP id 1735C1A032B for ; Thu, 10 Apr 2014 09:34:43 -0700 (PDT) Received: from mail-wi0-f177.google.com ([209.85.212.177]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKU0bIIoDDto1/OyB1mgVtLpIuVSn92BZq@postini.com; Thu, 10 Apr 2014 09:34:42 PDT Received: by mail-wi0-f177.google.com with SMTP id cc10so5324277wib.4 for ; Thu, 10 Apr 2014 09:34:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IjtlD+9IZnUioa15Nc7vJ87FwZVtRKDe43FogErCz0w=; b=GO/ifN9bcggY36MLaly40W8Fi+qzhnE1d06izQTkJU8aKerQYb4n2NuA2H4zkHTXUe 2yZlhGwJDdWK9dceNLJ76QJjVks8eduE5l9aqRVrW/loc+bysWURWwfv8Bfc3kwJkRt9 QSx+MXXYERckZYRlAJIWoiJOWrePo4hVvqE3265ur30UOKT2iAmKZDl5rOio7xr/MFV2 7oyLDCb1Vlst0wfTpo6vyLDbxYwMpw1f1KkoZzSGqOrznb2KOH7z2cc1n1JVlXz6F5sN V30IkLGj009x2WsftUqUes5eotSQrPAKJrAVA0ObiCn5UAtPdHe9eTFR3pBAuSmEinoX 7EEQ== X-Gm-Message-State: ALoCoQnANINXahuq+f/HQXtdCXvMO9/CKGoY++81qWbmWqLQXn+oogHHg5IeykXYTrOPj38fVGcRwcFe26HFvoZYPW+S57uwRlag1MgJ6evvt7mGfNR6Y5qUfATWalBfvVyyDIzCMSwR X-Received: by 10.194.92.81 with SMTP id ck17mr16210946wjb.14.1397147681128; Thu, 10 Apr 2014 09:34:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.92.81 with SMTP id ck17mr16210939wjb.14.1397147681052; Thu, 10 Apr 2014 09:34:41 -0700 (PDT) Received: by 10.194.77.205 with HTTP; Thu, 10 Apr 2014 09:34:40 -0700 (PDT) In-Reply-To: <5346C298.3030601@alum.mit.edu> References: <5346C298.3030601@alum.mit.edu> Date: Thu, 10 Apr 2014 17:34:40 +0100 Message-ID: From: Michael Procter To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/lHTVFYXv3aVmnaoHs9Hk6p_VqBQ Cc: SIPCORE Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 16:34:45 -0000 On 10 April 2014 17:11, Paul Kyzivat wrote: > ** This is a formal call for adoption of draft-johansson-sip-dual-stack as a > WG draft. I support adoption of this draft. From nobody Fri Apr 11 12:30:52 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6921A03BC for ; Fri, 11 Apr 2014 12:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys0i58kXgYRa for ; Fri, 11 Apr 2014 12:30:44 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA061A03F7 for ; Fri, 11 Apr 2014 12:30:41 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pv20so3923091lab.10 for ; Fri, 11 Apr 2014 12:30:40 -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=wTAN4hKyS2k4UhnYB2jqnBGXW8C0FhwI+BDIIj2FJd0=; b=Zce3sjzBw8ce4zhlZbWpVAvtnAYhryr0kaMmBCwltF35lqOM/Nxoy1CpOP2aRE0WLv TpRJz/QMGxm3tul1Z2l0MwcXJtfPnW/1Vv7OEizK14Np45cLcrjjc4lqI716e6ytNCgF b97MPG9hJ/IqE34lEWRT4TevVkwP83VuqO4defF7YZtF9IUX9qHRpaEJYZpV5TC3Tpv+ xULxXh2mOT2csY/1I4OZKsKKZUkJ9ilCwI5o5gz93xt6DRBTlBOtm8g8LpiTvaoFLXyV 20JBeqREKAr454ikD73qo3gCF0ZYZdWzki48ckwhyTBsB1DJm18j+NIyVDnB8z6UI6Xo Kkyg== MIME-Version: 1.0 X-Received: by 10.112.61.199 with SMTP id s7mr252576lbr.25.1397244639986; Fri, 11 Apr 2014 12:30:39 -0700 (PDT) Received: by 10.114.63.144 with HTTP; Fri, 11 Apr 2014 12:30:39 -0700 (PDT) In-Reply-To: References: <5346C298.3030601@alum.mit.edu> Date: Fri, 11 Apr 2014 15:30:39 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Michael Procter Content-Type: multipart/alternative; boundary=001a1133d17a6e49e504f6c95efc Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/nz3h1-yVHz9ZL1gT6GZBWykhNvo Cc: SIPCORE Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:30:49 -0000 --001a1133d17a6e49e504f6c95efc Content-Type: text/plain; charset=ISO-8859-1 I too support the adoption of this draft. Regards, Rifaat On Thu, Apr 10, 2014 at 12:34 PM, Michael Procter wrote: > On 10 April 2014 17:11, Paul Kyzivat wrote: > > ** This is a formal call for adoption of draft-johansson-sip-dual-stack > as a > > WG draft. > > I support adoption of this draft. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a1133d17a6e49e504f6c95efc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I too support the adoption of this draft.

Regards,
=A0Rifaat



On Thu, Apr 10, 2014 at 12:34 = PM, Michael Procter <michael@voip.co.uk> wrote:
On 10 April 2014 17:11, Paul= Kyzivat <pkyzivat@alum.mit.edu= > wrote:
> ** This is a formal call for adoption of draft-johansson-sip-dual-stac= k as a
> WG draft.

I support adoption of this draft.

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

--001a1133d17a6e49e504f6c95efc-- From nobody Fri Apr 11 12:43:02 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4752B1A0767 for ; Fri, 11 Apr 2014 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAe4YFFEzj8q for ; Fri, 11 Apr 2014 12:42:58 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id A34F01A0309 for ; Fri, 11 Apr 2014 12:42:57 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id bs8so1563961wib.11 for ; Fri, 11 Apr 2014 12:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U1TXVBo4/3tyzjXEWxA7/E8FepUuooDM3mPcy82etFw=; b=D1ngBuReiN+2RQAcM29iOKq/Sg0g8NUPoKIVcBrxQ+j4NTXyjtCXu5df8+U870768G m0GHSuph7Te72mB2H+9Dc4k41R/We9kIFZttvWCInKqV8tzPJw5BZLBH5F4gmJa1FAcs ZNaJm+lrUzuBV2KMwncjYK7CKWjFU0Y9K2RCWao1K+Lgqc0KqVDsLam5HaOrsgktZP/Q mAuFKqY6nrVNY7TVo8rsk8txEGOXrB7/lu/n00Y0kAmIAUjAscbmJrw0PIeFfsDIVmPS KNHGb9NVqDEreFgxQfBPrZgnySP/7Jr4QNWFcTJOPW57NogZqGPHDKYze7klZEPpCif3 ehWQ== MIME-Version: 1.0 X-Received: by 10.180.149.143 with SMTP id ua15mr4797507wib.36.1397245375783; Fri, 11 Apr 2014 12:42:55 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Fri, 11 Apr 2014 12:42:55 -0700 (PDT) In-Reply-To: <5346C298.3030601@alum.mit.edu> References: <5346C298.3030601@alum.mit.edu> Date: Fri, 11 Apr 2014 14:42:55 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c38e7049a87804f6c98a2f Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/fCRFYQEdj1oIdIcTntXDpdclY30 Cc: SIPCORE Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:43:00 -0000 --001a11c38e7049a87804f6c98a2f Content-Type: text/plain; charset=ISO-8859-1 I support the adoption of this draft as a WG document. Mary On Thu, Apr 10, 2014 at 11:11 AM, Paul Kyzivat wrote: > Gonzalo, > > Thanks for the poke. > > Yes, we agreed on milestone text: > > June 2014 Request publication of DNS look-up procedures for dual-stack > client and server handling of SIP URIs > > And we said we would make a formal call for adoption. > > ** This is a formal call for adoption of draft-johansson-sip-dual-stack as > a WG draft. > > Please indicate your preference for adopting this draft, pro or con, on > this maililng list. > > (Note: adopting the draft doesn't mean it will be published as-is. Further > edits will be based on wg consensus.) > > Thanks, > Paul (as sipcore co-chair) > > On 4/9/14 1:19 PM, Gonzalo Salgueiro (gsalguei) wrote: > >> Hi Chairs - >> >> With respect to the following item from the SIPCORE meeting in London: >> >> ++++++++++++++++++++++++++++++++++++++++ >> * draft-johansson-sip-dual-stack >> >> Action: split the action item into two: one for the DNS part, and another >> for the remainder of Happy Eyeballs. Discuss the milestone text on the list. >> >> Action: call for adoption of draft-johansson-dispatch-dane-sip on the >> list for the DNS part. >> ++++++++++++++++++++++++++++++++++++++++ >> >> >> The first action item was one I sent to the list weeks ago: >> http://www.ietf.org/mail-archive/web/sipcore/current/msg05992.html >> >> There have been no arguments against the two word edit to the previously >> agreed upon milestone. Is it OK to move froward with the edit? >> >> Can we begin the call for adoption of the draft in question, so the work >> can begin to progress? >> >> Cheers, >> >> Gonzalo >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c38e7049a87804f6c98a2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support the adoption of this draft as a WG document.
Mary


On Thu, Apr 10, 2014 at 11:11 AM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:
Gonzalo,

Thanks for the poke.

Yes, we agreed on milestone text:

June 2014 =A0Request publication of DNS look-up procedures for dual-stack c= lient and server handling of SIP URIs

And we said we would make a formal call for adoption.

** This is a formal call for adoption of draft-johansson-sip-dual-stack as = a WG draft.

Please indicate your preference for adopting this draft, pro or con, on thi= s maililng list.

(Note: adopting the draft doesn't mean it will be published as-is. Furt= her edits will be based on wg consensus.)

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul (as sipcore co-chair)

On 4/9/14 1:19 PM, Gonzalo Salgueiro (gsalguei) wrote:
Hi Chairs -

With respect to the following item from the SIPCORE meeting in London:

++++++++++++++++++++++++++++++++++++++++
* draft-johansson-sip-dual-stack

Action: split the action item into two: one for the DNS part, and another f= or the remainder of Happy Eyeballs. Discuss the milestone text on the list.=

Action: call for adoption of draft-johansson-dispatch-dane-sip on th= e list for the DNS part.
++++++++++++++++++++++++++++++++++++++++


The first action item was one I sent to the list weeks ago: http://www.ietf.org/mail-archive/web/sipcore/current/m= sg05992.html

There have been no arguments against the two word edit to the previously ag= reed upon milestone. =A0Is it OK to move froward with the edit?

Can we begin the call for adoption of the draft in question, so the work ca= n begin to progress?

Cheers,

Gonzalo


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

--001a11c38e7049a87804f6c98a2f-- From nobody Fri Apr 11 13:41:21 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167B61A03B7 for ; Fri, 11 Apr 2014 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuyeZm2Yj__U for ; Fri, 11 Apr 2014 13:41:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A01A81A02EA for ; Fri, 11 Apr 2014 13:41:14 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3BKeihL017769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Apr 2014 20:40:44 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3BKehUE028325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Apr 2014 20:40:43 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3BKegB1028301; Fri, 11 Apr 2014 20:40:42 GMT Received: from [10.0.1.10] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Apr 2014 13:40:42 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <201404070143.s371h4xT024144@hobgoblin.ariadne.com> Date: Fri, 11 Apr 2014 16:40:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <10EA250C-C276-4886-891E-CAB2C36EDD0A@oracle.com> References: <201404070143.s371h4xT024144@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/MvCzUeEx9S3N4jhOttX8AQF0fpc Cc: sipcore@ietf.org Subject: Re: [sipcore] Recording the addresses of intermediaries for OOD requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:41:19 -0000 On Apr 6, 2014, at 9:43 PM, Dale R. Worley wrote: > One potential solution that is not listed in section 3 is the use of a > header part of the Contact URI to provide a Route header for the OOD > request. (This has been mentioned before.) E.g., >=20 > Contact: ua@example.com?Route=3D%3csbc%40example.com%3blr%3e >=20 > specifies a Route header "". This would be > somewhat more verbose than some of the proposals (new header field, > new rr-param), but about as verbose as others (new URI parameter). >=20 > Since this mechanism is already implemented but is not considered a > solution to the problem, there is presumably a reason why it is not > workable. That should be documented in the draft. It won't work. For one thing, the next SBC in the chain can't just leave that thing = there, since it reveals the upstream host machine. They'd have to = encrypt/cookify both the "ua@example.com" as well the embedded Route = header portion. But more importantly, there's no guarantee that the receiving UAS will = use those embedded Route headers as real Route headers in out-of-dialog = requests. There's just too much crap out there to think that will work = reliably - it's far easier/safer to simply embed the info (in = encrypted/cookified form) in the Contact user portion, and replace the = Contact. (and an SBC is a B2BUA, and B2BUA's really *should* replace the = Contact) -hadriel From nobody Fri Apr 11 13:50:42 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939771A041B for ; Fri, 11 Apr 2014 13:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJlZ749UQvlO for ; Fri, 11 Apr 2014 13:50:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AA1DD1A0767 for ; Fri, 11 Apr 2014 13:50:35 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3BKoPVP011944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Apr 2014 20:50:25 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3BKoOSE000855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2014 20:50:24 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s3BKoOOH001002; Fri, 11 Apr 2014 20:50:24 GMT Received: from [10.0.1.10] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Apr 2014 13:50:23 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <201404032119.s33LJuB7010813@hobgoblin.ariadne.com> Date: Fri, 11 Apr 2014 16:50:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71783201-1C34-416E-AEE2-0AE06FA73A13@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <201403211931.s2LJVs4B010647@hobgoblin.ariadne.com> <201404032119.s33LJuB7010813@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/6CSA27kZwRYu4f0ro_PkhorGtwM Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:50:40 -0000 On Apr 3, 2014, at 5:19 PM, Dale R. Worley wrote: >> From: Hadriel Kaplan >>=20 >> On Mar 21, 2014, at 3:31 PM, Dale R. Worley = wrote: >>> I'm curious what you mean by "just behave like they're normal = contact >>> URIs". My understanding is that the contact URI is used for = whatever >>> it's used for *because* it's the contact URI. If it's marked as a >>> GRUU, that presumably is a hint that your odds of success are = higher, >>> but what would you do differently? >>=20 >> You would send out-of-dialog REFERs, and you could (in theory) store >> the GRUU for future use indefinitely, such as in an address book. >=20 > When you say "You would send out-of-dialog REFERs", it sounds like > this is the *bulk* of the problems you're encountering. So let me > ask, "If no UA ever sent out-of-dialog REFERs, would the problems you > see with GRUUs vanish?" I don't know. REFER is the main one for out-of-dialog messages to a = previously received in-dialog Contact that I see. I seem to recall some problems with out-of-dialog Subscriptions[1] to = in-dialog Contacts too, but that was a long time ago and not = GRUU-specific. [1] I can't remember what it was a Subscription for - dialog-event = package maybe? Or maybe KPML? >> The userinfo portion has sufficient information for the SBC to >> figure out which original Contact URI to use as a target for an >> out-of-dialog request (or to match to some internal dialog state). >=20 > Of course, the additional information could be put into a URI > parameter instead of the user info. Sure, though I think putting it in userinfo is more likely to work every = time. -hadriel From nobody Fri Apr 18 13:46:03 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05C1A02F2 for ; Fri, 18 Apr 2014 13:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r45n1eIDvIIx for ; Fri, 18 Apr 2014 13:46:00 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACB91A02EB for ; Fri, 18 Apr 2014 13:46:00 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id rVmh1n00627AodY59YlvHp; Fri, 18 Apr 2014 20:45:55 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta19.westchester.pa.mail.comcast.net with comcast id rYlv1n00J1KKtkw3fYlvER; Fri, 18 Apr 2014 20:45:55 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3IKjtco006989 for ; Fri, 18 Apr 2014 16:45:55 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3IKjsJm006988; Fri, 18 Apr 2014 16:45:54 -0400 Date: Fri, 18 Apr 2014 16:45:54 -0400 Message-Id: <201404182045.s3IKjsJm006988@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <5346C298.3030601@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <5346C298.3030601@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397853955; bh=DhTqnITR0JQzhK9VDfgRWHZq1QROdePccmmtM4IGJnI=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=tI87pn4QaVFuPaVdj9QGG9WUYoukVrUzKYb1ljVj0IQ8nE6KNm4ooLflhaI5/zV6z /L7Plh60A8NV9WLtty2eBMZy4U6RvAqkT6BTVdAZI9rNb4UirYpf4TAOJepTFrToIw Km5qCwUdPWaIMPymUd4mmtFU7gZR58oQjw2Uy55Tz/TSN8jgphkwAg/qrreVOGBo/V pakm3t8Erukf9dCamrrW1Vdc8I1d/Mwk24WuhVfNhTabnKZZhxnPhaKAmCopADw0rI 1ViLQLjYwbDfesYdDSoSC7CN920rLGBZU0i1gnLKdVmPdYYPzfZXcYJql63AixnMd0 GWZf1glx2OKKw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/-_45ReST4kue2bYdo4JDv-3wMNE Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 20:46:01 -0000 > From: Paul Kyzivat > ** This is a formal call for adoption of draft-johansson-sip-dual-stack > as a WG draft. I definitely support this, as we are going to need quality dual-stack support during the addressing transition era. Dale From nobody Mon Apr 21 12:51:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4041A0276 for ; Mon, 21 Apr 2014 12:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0jsjPBDTatU for ; Mon, 21 Apr 2014 12:51:07 -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 2D69F1A0257 for ; Mon, 21 Apr 2014 12:51:07 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id siKJ1n0071swQuc51jr280; Mon, 21 Apr 2014 19:51:02 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta15.westchester.pa.mail.comcast.net with comcast id sjr11n00Q1KKtkw3bjr1Kl; Mon, 21 Apr 2014 19:51:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3LJp0EW009618; Mon, 21 Apr 2014 15:51:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3LJp0in009617; Mon, 21 Apr 2014 15:51:00 -0400 Date: Mon, 21 Apr 2014 15:51:00 -0400 Message-Id: <201404211951.s3LJp0in009617@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Hadriel Kaplan In-reply-to: <10EA250C-C276-4886-891E-CAB2C36EDD0A@oracle.com> (hadriel.kaplan@oracle.com) References: <201404070143.s371h4xT024144@hobgoblin.ariadne.com> <10EA250C-C276-4886-891E-CAB2C36EDD0A@oracle.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398109862; bh=ERnAdCgO20joP3x8I9/AXVmIsn8Zl06zSxy1QoCcadQ=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=e8VjoYJ2jEiqe/OLRPZwEQeiqucd+vTvxewMtFZFo1du588AMYfsviNqx3Yx26MH1 13DtXiCioBKM3O//Glx2rgNHNzCiOpKq3WExKhwYf0GScW9OQKLOUmQ088z0qyviAA PteagljdA2eE3EvIGgCFrDHs5AdArG6uSyQTRNb4mZqH9/WiuK+qTjpfjA39YpCeV+ K6r+e+uVTy3htTcCbcyV/6gVAeui1msOw+YJIbKPr6smo94nphp8ooIuhKpePjOfYL 2KUkDIzjcWyYYTVK7vhlTKZ+7CP+DScxnKItCQyVBv2v080oaBHvRzuPItKZ5dhhOQ c0sUOTIiRJqWg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/chPEGhVFdJXgACrTQdUw97vgKIk Cc: sipcore@ietf.org Subject: Re: [sipcore] Recording the addresses of intermediaries for OOD requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:51:10 -0000 [sorry for not responding to these faster] > From: Hadriel Kaplan > > Contact: ua@example.com?Route=%3csbc%40example.com%3blr%3e > It won't work. > > For one thing, the next SBC in the chain can't just leave that thing > there, since it reveals the upstream host machine. They'd have to > encrypt/cookify both the "ua@example.com" as well the embedded Route > header portion. What is the prohibition on "reveals the upstream host machine"? > But more importantly, there's no guarantee that the receiving UAS > will use those embedded Route headers as real Route headers in > out-of-dialog requests. There's just too much crap out there to > think that will work reliably I think you mean, "There are far too many devices that won't properly process a Route header component of a URI". Am I right? > From: Hadriel Kaplan > > When you say "You would send out-of-dialog REFERs", it sounds like > > this is the *bulk* of the problems you're encountering. So let me > > ask, "If no UA ever sent out-of-dialog REFERs, would the problems you > > see with GRUUs vanish?" > > I don't know. REFER is the main one for out-of-dialog messages to a > previously received in-dialog Contact that I see. > > I seem to recall some problems with out-of-dialog Subscriptions[1] > to in-dialog Contacts too, but that was a long time ago and not > GRUU-specific. People have mentioned SUBSCRIBE as well. What makes the problem with REFER to be GRUU-specific? What I'm trying to do is to turn "It won't work." into a clear list of the problems that are causing things not to work. Dale From nobody Tue Apr 22 13:46:12 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE1E1A0077 for ; Tue, 22 Apr 2014 13:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2DbB6ZUJSyq for ; Tue, 22 Apr 2014 13:43:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DEF1A025C for ; Tue, 22 Apr 2014 13:43:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422204340.4351.71908.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 13:43:40 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/BETimPNmyUVaNaGVbCTglbRCf9Y X-Mailman-Approved-At: Tue, 22 Apr 2014 13:46:10 -0700 Subject: [sipcore] Milestones changed for sipcore WG X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 20:43:49 -0000 Changed milestone "Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/sipcore/charter/ From nobody Fri Apr 25 03:37:56 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425481A0164 for ; Fri, 25 Apr 2014 03:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oES0CN6RFz14 for ; Fri, 25 Apr 2014 03:37:54 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E31A71A013B for ; Fri, 25 Apr 2014 03:37:53 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 0B79323F04F0; Fri, 25 Apr 2014 12:37:47 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.60]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Fri, 25 Apr 2014 12:37:46 +0200 From: "Hutton, Andrew" To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft Thread-Index: AQHPW0c2jWUAuRFImkaqWPGyYrIbI5siGAoQ Date: Fri, 25 Apr 2014 10:37:46 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D7E41B@MCHP04MSX.global-ad.net> References: <5346C298.3030601@alum.mit.edu> <201404182045.s3IKjsJm006988@hobgoblin.ariadne.com> In-Reply-To: <201404182045.s3IKjsJm006988@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/pDkGwWPEuAsgRVukkBPLRL1Rs68 Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 10:37:55 -0000 +1 I support the adoption of this draft it is a problem area we need some clar= ity on. The SIP Forum is looking at starting to work on a SIPconnect2.0 specificati= on and this is something that will probably be needed. Regards Andy > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. > Worley > Sent: 18 April 2014 21:46 > To: sipcore@ietf.org > Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual- > stack as WG draft >=20 > > From: Paul Kyzivat >=20 > > ** This is a formal call for adoption of draft-johansson-sip-dual- > stack > > as a WG draft. >=20 > I definitely support this, as we are going to need quality dual-stack > support during the addressing transition era. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Apr 25 07:38:00 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795191A0300 for ; Fri, 25 Apr 2014 07:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GSZmiCwialv for ; Fri, 25 Apr 2014 07:37:56 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id E011D1A026F for ; Fri, 25 Apr 2014 07:37:55 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l6so3228399qcy.38 for ; Fri, 25 Apr 2014 07:37:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=KcktyzOob3RmAPDr9OECgH35Nxiy46AcabxcHdNzvrg=; b=AiuXFyjHf9aV9sBLZbmMFmDidaIFkJ9UEvnznmec6zVWECMlRswD4f6ltapMrQspkl xkz3u1h0GPtOsaZrAatNSah0aMWK6uq4dlh6WlxxzEc8nDWXYhNSLLAldb+YaelwUTWw Wd1ySqGPv2hbMkHbbfZ4X37Ib36Jf1WXZfROpq6b7J9oSM3axypvzGG1SopZ7VsRRl7q OWH6dITWOet03635USBtNJA9J+zxHRk2rtb2m03/ZkMgqI0hE1wLwLldI+smEa+mTeH5 UPUZGytkVfVJTCGDf3pZQaiA/nmWR9gWxt6ouhZUBJeljuWcEzRMr1vMXC820I0mxr+s a9sA== X-Gm-Message-State: ALoCoQk6wNG/4f2duwlMira3eaR1w76dUwRJeGfHnn6lrowmnnAKMSgtA7cZsbNjB3OMKrOxoYga X-Received: by 10.140.30.99 with SMTP id c90mr11346565qgc.13.1398436658986; Fri, 25 Apr 2014 07:37:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Fri, 25 Apr 2014 07:37:18 -0700 (PDT) In-Reply-To: <5346C298.3030601@alum.mit.edu> References: <5346C298.3030601@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 25 Apr 2014 16:37:18 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/DGP0ImZM_xmz7CzsNAmFBB7foDQ Cc: SIPCORE Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:37:57 -0000 +1, this is a need. 2014-04-10 18:11 GMT+02:00 Paul Kyzivat : > Gonzalo, > > Thanks for the poke. > > Yes, we agreed on milestone text: > > June 2014 Request publication of DNS look-up procedures for dual-stack > client and server handling of SIP URIs > > And we said we would make a formal call for adoption. > > ** This is a formal call for adoption of draft-johansson-sip-dual-stack a= s a > WG draft. > > Please indicate your preference for adopting this draft, pro or con, on t= his > maililng list. > > (Note: adopting the draft doesn't mean it will be published as-is. Furthe= r > edits will be based on wg consensus.) > > Thanks, > Paul (as sipcore co-chair) > > On 4/9/14 1:19 PM, Gonzalo Salgueiro (gsalguei) wrote: >> >> Hi Chairs - >> >> With respect to the following item from the SIPCORE meeting in London: >> >> ++++++++++++++++++++++++++++++++++++++++ >> * draft-johansson-sip-dual-stack >> >> Action: split the action item into two: one for the DNS part, and anothe= r >> for the remainder of Happy Eyeballs. Discuss the milestone text on the l= ist. >> >> Action: call for adoption of draft-johansson-dispatch-dane-sip on the li= st >> for the DNS part. >> ++++++++++++++++++++++++++++++++++++++++ >> >> >> The first action item was one I sent to the list weeks ago: >> http://www.ietf.org/mail-archive/web/sipcore/current/msg05992.html >> >> There have been no arguments against the two word edit to the previously >> agreed upon milestone. Is it OK to move froward with the edit? >> >> Can we begin the call for adoption of the draft in question, so the work >> can begin to progress? >> >> Cheers, >> >> Gonzalo >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=20 I=C3=B1aki Baz Castillo From nobody Fri Apr 25 09:36:31 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF221A0584 for ; Fri, 25 Apr 2014 09:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlpuI4i2xyur for ; Fri, 25 Apr 2014 09:36:26 -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 289271A02C1 for ; Fri, 25 Apr 2014 09:36:26 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id uCQm1n0021YDfWL5FGcKhQ; Fri, 25 Apr 2014 16:36:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id uGcK1n0083ZTu2S3gGcK7k; Fri, 25 Apr 2014 16:36:19 +0000 Message-ID: <535A8F03.8070504@alum.mit.edu> Date: Fri, 25 Apr 2014 12:36:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <5346C298.3030601@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398443779; bh=PZDkQYBn3eIHt2FvHanOBUohPQ/5VlHWn8rHlaitjTo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JyLDZ3kdZxS2qheIZNnxRXsfdxpN+9v3lGkR+aiREX3qJ7CioZnHgaFlD/GQo7TyO CUAR7p6TyYDhmHdghGXAkWdfZhkQUGn54OcWQsNMMsCTsWLGJM5E+qiBKnakgqoXOo NkzdTTswCiy4CiaZQc641V/uwF+y9H1Iv+1okvyc/YC8GigfxPgUTWRUGUw91FRVmN 7Us9QnY1ayHw+o9//a3WK3IUs36f5bQlIuwjfGLEqyBsPLEtMR3eLb4bSA/1XfoHzj W2z+B65xTCedYMIuXIIXfItdjQPJyzYu1wWETfJTO8mdh4xsi8Y97cI12AFfrF9ENa 2t23m0yF6NFdw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/6f0qmaDQ-ANG3fvYM15nMC4wNKk Cc: SIPCORE Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:36:27 -0000 I am calling consensus on adopting this draft. The milestone has been updated to support it. Olle - can you please resubmit as a wg draft? Thanks, Paul On 4/25/14 10:37 AM, Iñaki Baz Castillo wrote: > +1, this is a need. > > 2014-04-10 18:11 GMT+02:00 Paul Kyzivat : >> Gonzalo, >> >> Thanks for the poke. >> >> Yes, we agreed on milestone text: >> >> June 2014 Request publication of DNS look-up procedures for dual-stack >> client and server handling of SIP URIs >> >> And we said we would make a formal call for adoption. >> >> ** This is a formal call for adoption of draft-johansson-sip-dual-stack as a >> WG draft. >> >> Please indicate your preference for adopting this draft, pro or con, on this >> maililng list. >> >> (Note: adopting the draft doesn't mean it will be published as-is. Further >> edits will be based on wg consensus.) >> >> Thanks, >> Paul (as sipcore co-chair) >> >> On 4/9/14 1:19 PM, Gonzalo Salgueiro (gsalguei) wrote: >>> >>> Hi Chairs - >>> >>> With respect to the following item from the SIPCORE meeting in London: >>> >>> ++++++++++++++++++++++++++++++++++++++++ >>> * draft-johansson-sip-dual-stack >>> >>> Action: split the action item into two: one for the DNS part, and another >>> for the remainder of Happy Eyeballs. Discuss the milestone text on the list. >>> >>> Action: call for adoption of draft-johansson-dispatch-dane-sip on the list >>> for the DNS part. >>> ++++++++++++++++++++++++++++++++++++++++ >>> >>> >>> The first action item was one I sent to the list weeks ago: >>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05992.html >>> >>> There have been no arguments against the two word edit to the previously >>> agreed upon milestone. Is it OK to move froward with the edit? >>> >>> Can we begin the call for adoption of the draft in question, so the work >>> can begin to progress? >>> >>> Cheers, >>> >>> Gonzalo >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > > From nobody Fri Apr 25 09:59:36 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C21A0658 for ; Fri, 25 Apr 2014 09:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMgjFHkWIGm1 for ; Fri, 25 Apr 2014 09:59:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BA6091A00CB for ; Fri, 25 Apr 2014 09:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2603; q=dns/txt; s=iport; t=1398445160; x=1399654760; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BZV+b1kKo7/qNs26SDWtEQ5Gk78udGy9zdM2mDg5w8Q=; b=CPimXo2gStQlCnOKBibh30IrOo7o9VLSd6oGBnOIPN+1Q24lTFCU2qsp fSO7FK28hBDWGnpWu00BEO/ZmitGxTziJmHNtyKDf6TiwGlwTUTOyla3k N+mrAeabGpEqgKRBqVb8JewD5Qb7SCbmhtKjZ6/6RtVFlaKpjD1tylfxj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHOTWlOtJA2D/2dsb2JhbABZDoJ4T1e8Z4ZnUYETFnSCJQEBAQMBAQEBGlELBQsCAQgOCi4nCyUCBA4FCYgwCA3KNBeOBQMBARwzAgWDJIEVBIkzj1KSXIJxQIFyOQ X-IronPort-AV: E=Sophos;i="4.97,928,1389744000"; d="scan'208";a="320444030" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 25 Apr 2014 16:59:20 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3PGxKsC024031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 16:59:20 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 11:59:19 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft Thread-Index: AQHPYKSDayXhxsHlE0+j/Yv3z1fdz5si4e2A Date: Fri, 25 Apr 2014 16:59:19 +0000 Message-ID: <305E05BA-593B-4D66-9479-3D9607DB8580@cisco.com> References: <5346C298.3030601@alum.mit.edu> <535A8F03.8070504@alum.mit.edu> In-Reply-To: <535A8F03.8070504@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.155.23] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7A90C43041865240A471ABEC40F8156E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/B96rN7QHfda_fyJyqmr5fJiEcxI Cc: SIPCORE Subject: Re: [sipcore] Call for adoption of draft-johansson-sip-dual-stack as WG draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:59:29 -0000 On Apr 25, 2014, at 12:36 PM, Paul Kyzivat wrote: > I am calling consensus on adopting this draft. > The milestone has been updated to support it. >=20 > Olle - can you please resubmit as a wg draft? Done. Thanks, -G >=20 > Thanks, > Paul >=20 > On 4/25/14 10:37 AM, I=F1aki Baz Castillo wrote: >> +1, this is a need. >>=20 >> 2014-04-10 18:11 GMT+02:00 Paul Kyzivat : >>> Gonzalo, >>>=20 >>> Thanks for the poke. >>>=20 >>> Yes, we agreed on milestone text: >>>=20 >>> June 2014 Request publication of DNS look-up procedures for dual-stack >>> client and server handling of SIP URIs >>>=20 >>> And we said we would make a formal call for adoption. >>>=20 >>> ** This is a formal call for adoption of draft-johansson-sip-dual-stack= as a >>> WG draft. >>>=20 >>> Please indicate your preference for adopting this draft, pro or con, on= this >>> maililng list. >>>=20 >>> (Note: adopting the draft doesn't mean it will be published as-is. Furt= her >>> edits will be based on wg consensus.) >>>=20 >>> Thanks, >>> Paul (as sipcore co-chair) >>>=20 >>> On 4/9/14 1:19 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>>=20 >>>> Hi Chairs - >>>>=20 >>>> With respect to the following item from the SIPCORE meeting in London: >>>>=20 >>>> ++++++++++++++++++++++++++++++++++++++++ >>>> * draft-johansson-sip-dual-stack >>>>=20 >>>> Action: split the action item into two: one for the DNS part, and anot= her >>>> for the remainder of Happy Eyeballs. Discuss the milestone text on the= list. >>>>=20 >>>> Action: call for adoption of draft-johansson-dispatch-dane-sip on the = list >>>> for the DNS part. >>>> ++++++++++++++++++++++++++++++++++++++++ >>>>=20 >>>>=20 >>>> The first action item was one I sent to the list weeks ago: >>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05992.html >>>>=20 >>>> There have been no arguments against the two word edit to the previous= ly >>>> agreed upon milestone. Is it OK to move froward with the edit? >>>>=20 >>>> Can we begin the call for adoption of the draft in question, so the wo= rk >>>> can begin to progress? >>>>=20 >>>> Cheers, >>>>=20 >>>> Gonzalo >>>>=20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Apr 25 10:08:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6901A0681; Fri, 25 Apr 2014 10:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuBJqFOrI4K1; Fri, 25 Apr 2014 10:07:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 048241A068D; Fri, 25 Apr 2014 10:07:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140425170755.6422.60116.idtracker@ietfa.amsl.com> Date: Fri, 25 Apr 2014 10:07:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/H1u7kAx_T0DIiZekof_cMRphR2g Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-dns-dual-stack-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:08:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Authors : Olle E. Johansson Gonzalo Salgueiro Filename : draft-ietf-sipcore-dns-dual-stack-00.txt Pages : 7 Date : 2014-04-25 Abstract: RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document supplements the DNS procedures described in RFC 3263 for dual-stack SIP implementations and ensures that they properly align to the optimizations detailed by Happy Eyeballs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-dns-dual-stack-00 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 nobody Wed Apr 30 07:07:21 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B406E1A6FBC for ; Wed, 30 Apr 2014 07:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6UqJ46LdKhc for ; Wed, 30 Apr 2014 07:07:17 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1F81A6FC6 for ; Wed, 30 Apr 2014 07:07:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-b3-536103921d4f Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A8.E9.05066.29301635; Wed, 30 Apr 2014 16:07:15 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.175]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Wed, 30 Apr 2014 16:07:14 +0200 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: Precondition and status confirmation requested by offerer Thread-Index: Ac9kfAqFF4+CTba/RkSzA0VskAi+OA== Date: Wed, 30 Apr 2014 14:07:14 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101126C0371@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101126C0371ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje5k5sRgg78nWS2+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPm7brAWTCyrOPzjP1sD46SMLkZODgkBE4lj8+6wQthiEhfu rWfrYuTiEBI4yijRdPk6O4SzhFHi3evjjCBVbAJ6EhO3HAHrEBHQlFj+bSs7iC0s4CRx5dE3 Noi4u8TPhTvZIWw9iaXvWsFsFgFVid+zt7GA2LwCvhInO9+D1TMKyEpc/dMLNp9ZQFzi1pP5 TBAXCUgs2XOeGcIWlXj5+B/UpYoS7U8boOrzJaZeWgY1U1Di5MwnLBMYhWYhGTULSdksJGUQ cR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZg VBzc8ttqB+PB546HGAU4GJV4eIu/RAYLsSaWFVfmHmKU5mBREuedtMg9WEggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOjjkaWt1ajdJT4nCO/smyKV/yf+zU4Ob2gtVVx3kx+uXuaG98I2kdW +eTY1rfW3ef7MLfygvaHDZzBsy6/cj++3mW1gctOV+37gUl6rd+2hc92aa0yv21wxHKh+rt3 c18p7MksWLufv7Lg6bJT/BcFyo8HXivV/3KksvvIuXtXNhi/UVWTKLmhxFKckWioxVxUnAgA xRA7SmsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/smdkxv4JB8qejz3N8fxi2fKPxC8 Subject: [sipcore] Precondition and status confirmation requested by offerer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:07:19 -0000 --_000_39B5E4D390E9BD4890E2B31079006101126C0371ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, can you please help me with a question related to precondition handling in = RFC3312? Scenario: Bob receives an SDP offer O1 containing (not all lines are shown): m=3Daudio a=3Dcurr:qos local sendrecv a=3Dcurr:qos remote none a=3Ddes:qos mandatory local sendrecv a=3Ddes:qos mandatory remote sendrecv a=3Dconf:qos remote sendrecv Bob has needed resources and generates and sends an SDP answer A1 containin= g (not all lines are shown): m=3Daudio a=3Dcurr:qos local sendrecv a=3Dcurr:qos remote sendrecv a=3Ddes:qos mandatory local sendrecv a=3Ddes:qos mandatory remote sendrecv Question: Does "a=3Dconf:qos remote sendrecv" included in SDP offer O1 mandate Bob to= send an additional SDP offer O2 immediately after sending the SDP answer A= 1? RFC3312 seems to mandate sending such additional SDP offer since it states: -------------------- The confirm-status attribute MAY be used in both offers and answers. This attribute represents a threshold for the resource reservation. >>When this threshold is reached or surpassed, the user agent MUST send an offer to the peer user agent, reflecting the new current status of the media line as soon as allowed by the SIP offer/answer rules<<. If this threshold is crossed again (e.g., the network stops providing resources for the media stream), the user agent MUST send a new offer as well, as soon as allowed by the SIP offer/answer rules. >>If a peer has requested confirmation on a particular stream, an agent MUST mark that stream with a flag in its local status table. When all the rows with this flag have a "Current" value of "yes", the user agent MUST send a new offer to the peer.<< This offer will contain the current status of resource reservation in the current-status attributes. Later, if any of the rows with this flag transition to "No", a new offer MUST be sent as well. -------------------- However: - sending of such additional SDP offer O2 should not be necessary since SDP= answer A1 indicates that Bob's resources are reserved. - if order of the SDP answer A1 and the additional SDP offer O2 is swapped = on the way to the remote UA, then the remote UA rejects the UPDATE request = carrying the additional offer O2 with 491 (Request Pending) response. The situation above occurs with third party call control. I am aware that i= n regular two party calls, it should not occur. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101126C0371ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

can you please help me with a question related to preco= ndition handling in RFC3312?

 

Scenario:

 

Bob receives an SDP offer O1 containing (not all lines = are shown):

 

      m=3Daudio <port> &= lt;proto> <fmt>

      a=3Dcurr:qos local sendr= ecv

      a=3Dcurr:qos remote none=

      a=3Ddes:qos mandatory lo= cal sendrecv

      a=3Ddes:qos mandatory re= mote sendrecv

      a=3Dconf:qos remote send= recv

 

Bob has needed resources and generates and sends an SDP= answer A1 containing (not all lines are shown):

 

      m=3Daudio <port> &= lt;proto> <fmt>

      a=3Dcurr:qos local sendr= ecv

      a=3Dcurr:qos remote send= recv

      a=3Ddes:qos mandatory lo= cal sendrecv

      a=3Ddes:qos mandatory re= mote sendrecv

 

Question:

 

Does "a=3Dconf:qos remote sendrecv" included = in SDP offer O1 mandate Bob to send an additional SDP offer O2 immediately = after sending the SDP answer A1?

 

RFC3312 seems to mandate sending such additional SDP of= fer since it states:

--------------------

   The confirm-status attribute MAY be used i= n both offers and answers.

   This attribute represents a threshold for = the resource reservation.

   >>When this threshold is reached or = surpassed, the user agent MUST send

   an offer to the peer user agent, reflectin= g the new current status of

   the media line as soon as allowed by the S= IP offer/answer rules<<.  If

   this threshold is crossed again (e.g., the= network stops providing

   resources for the media stream), the user = agent MUST send a new offer

   as well, as soon as allowed by the SIP off= er/answer rules.

 

   >>If a peer has requested confirmati= on on a particular stream, an agent

   MUST mark that stream with a flag in its l= ocal status table.  When

   all the rows with this flag have a "C= urrent" value of "yes", the user

   agent MUST send a new offer to the peer.&l= t;<  This offer will contain the

   current status of resource reservation in = the current-status

   attributes.  Later, if any of the row= s with this flag transition to

   "No", a new offer MUST be sent a= s well.

--------------------

 

However:

- sending of such additional SDP offer O2 should not be= necessary since SDP answer A1 indicates that Bob's resources are reserved.=

- if order of the SDP answer A1 and the additional SDP = offer O2 is swapped on the way to the remote UA, then the remote UA rejects= the UPDATE request carrying the additional offer O2 with 491 (Request Pending) response.

 

The situation above occurs with third party call contro= l. I am aware that in regular two party calls, it should not occur.

 

Kind regards

 

Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B31079006101126C0371ESESSMB301erics_-- From nobody Wed Apr 30 07:37:37 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642C71A08FC for ; Wed, 30 Apr 2014 07:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi4W6trV1w3z for ; Wed, 30 Apr 2014 07:37:35 -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 172AB1A08D7 for ; Wed, 30 Apr 2014 07:37:34 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id wD9N1n0021swQuc51EdZei; Wed, 30 Apr 2014 14:37:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id wEdZ1n00F3ZTu2S3bEdZxn; Wed, 30 Apr 2014 14:37:33 +0000 Message-ID: <53610AAD.1020102@alum.mit.edu> Date: Wed, 30 Apr 2014 10:37:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sipcore@ietf.org, Gonzalo Camarillo References: <39B5E4D390E9BD4890E2B31079006101126C0371@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101126C0371@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398868653; bh=+lXTppIdgeVthC5XJSRWaatVSTt7VuZe0FpLfDEae+4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cDYjk/nBodFbfC4yVLy4rxYmF1ANe1Xm4fblCZuN/AaOXnf8LIvNUVoMorM5poqc6 FZTIjHzgUg3Jn9cpkqCH/n9J3fZhxAx/Kn0KTXjAef1Xe5y08dzog8lUmUEWH0voPi T4j/dJCFdmqAqpztsLKhGdd8RMshX2IPKmFUf9gQ2OZf5UX6tNFwZ/ohI3Gw5Y3+5v wUuz9Pruf21LQv3tSujK71Tyc8T7iookohjElyBslHYyBC0Zs5cwyWk44KalhdZ6fU iX5gThQJItQIC5dWxwA1iGRtWkzLQ5Gp86NM8nX6Hb6IvopQjE7hnJAQgNVsp5e7jU Z38LDe4zB0QvQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/G9pkkcmQc01xs1eB4fkEhdVK4XI Subject: Re: [sipcore] Precondition and status confirmation requested by offerer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:37:36 -0000 Ivo, I just skimmed this, but before digging into it I think we need to settle on the proper place to discuss it. My first thought was that it is not really a sip thing and ought to be discussed in mmusic. But looking back I see the the drafts leading to 3312 were processed in the sip wg. Since sipcore and dispatch are the descendents of the sip wg, maybe sipcore isn't wrong. Normally I would say that mmusic would be the right place to deal with a SDP issue such as this. But mmusic is fully engaged in other things now, and this would likely get lost there. So for the time being I guess we might as well discuss it in sipcore. Perhaps we can have an opinion on this by Gonzalo, since he was editor of 3312 and its update 4032. Thanks, Paul On 4/30/14 10:07 AM, Ivo Sedlacek wrote: > Hello, > > can you please help me with a question related to precondition handling > in RFC3312? > > Scenario: > > Bob receives an SDP offer O1 containing (not all lines are shown): > > m=audio > > a=curr:qos local sendrecv > > a=curr:qos remote none > > a=des:qos mandatory local sendrecv > > a=des:qos mandatory remote sendrecv > > a=conf:qos remote sendrecv > > Bob has needed resources and generates and sends an SDP answer A1 > containing (not all lines are shown): > > m=audio > > a=curr:qos local sendrecv > > a=curr:qos remote sendrecv > > a=des:qos mandatory local sendrecv > > a=des:qos mandatory remote sendrecv > > Question: > > Does "a=conf:qos remote sendrecv" included in SDP offer O1 mandate Bob > to send an additional SDP offer O2 immediately after sending the SDP > answer A1? > > RFC3312 seems to mandate sending such additional SDP offer since it states: > > -------------------- > > The confirm-status attribute MAY be used in both offers and answers. > > This attribute represents a threshold for the resource reservation. > > >>When this threshold is reached or surpassed, the user agent MUST send > > an offer to the peer user agent, reflecting the new current status of > > the media line as soon as allowed by the SIP offer/answer rules<<. If > > this threshold is crossed again (e.g., the network stops providing > > resources for the media stream), the user agent MUST send a new offer > > as well, as soon as allowed by the SIP offer/answer rules. > > >>If a peer has requested confirmation on a particular stream, an agent > > MUST mark that stream with a flag in its local status table. When > > all the rows with this flag have a "Current" value of "yes", the user > > agent MUST send a new offer to the peer.<< This offer will contain the > > current status of resource reservation in the current-status > > attributes. Later, if any of the rows with this flag transition to > > "No", a new offer MUST be sent as well. > > -------------------- > > However: > > - sending of such additional SDP offer O2 should not be necessary since > SDP answer A1 indicates that Bob's resources are reserved. > > - if order of the SDP answer A1 and the additional SDP offer O2 is > swapped on the way to the remote UA, then the remote UA rejects the > UPDATE request carrying the additional offer O2 with 491 (Request > Pending) response. > > The situation above occurs with third party call control. I am aware > that in regular two party calls, it should not occur. > > Kind regards > > Ivo Sedlacek > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Apr 30 07:59:13 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF6B1A08F1; Wed, 30 Apr 2014 07:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfkRIy0YtVpW; Wed, 30 Apr 2014 07:59:02 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id D238E1A6F03; Wed, 30 Apr 2014 07:59:01 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f8so3069665wiw.3 for ; Wed, 30 Apr 2014 07:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fqEnbk3NtDjBfvTicvyD2IDrmrbNul8l3p+5pEOGATw=; b=x+Vvhx1JGgjXCD0v5KLbLf7h6Uu16JIUdPDYh5mjKxBp8E97mDN2077Gkz7TZa8MGG nKEY7sDpYUI75ADBe9IGB+PwoTbtqQ+XChX4Yn4PKC3ugRLgUSUB9fM2+f4b7hM7xVtZ rRjP4TxFVh/MBLCHYJ6kdOuQhlg/jlD6d8pR5/4zMBx6rF4jH3zySp2nyVxzJzNX4Z9m 43P9HGg9S+GbcHRiiXxsOL2fSehNqxbT2Ke7SrpdawMJ/ni0vdt2don7KaTrLUaJOa6p ntrAtmCt9CHi14t8DQg3qFh360fw1lwvlPcTZY8gvjQuIB0tOhOUYFg7TFbfNbPvSd5k Jx3Q== MIME-Version: 1.0 X-Received: by 10.180.74.39 with SMTP id q7mr4056990wiv.36.1398869939771; Wed, 30 Apr 2014 07:58:59 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Wed, 30 Apr 2014 07:58:59 -0700 (PDT) In-Reply-To: <53602729.474be00a.2f3d.66aaSMTPIN_ADDED_BROKEN@mx.google.com> References: <53602729.474be00a.2f3d.66aaSMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 30 Apr 2014 09:58:59 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH , SIPCORE , "ecrit@ietf.org Org" Content-Type: multipart/mixed; boundary=f46d04374abfd8f46904f843c9f2 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/in-hkTy72NM9RYChS43K85alWns Subject: [sipcore] Fwd: [SIPForum-techwg] Call for Comments on SIPconnect 2.0 Charter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:59:09 -0000 --f46d04374abfd8f46904f843c9f2 Content-Type: multipart/alternative; boundary=f46d04374abfd8f46504f843c9f0 --f46d04374abfd8f46504f843c9f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm forwarding this as I think this new activity might be of interest to the community. In particular, since the focus is adding recommendations for the following to the SIP Connect specification (available at SIPconnect Technical Recommendation Documents and Presentations ): =E2=80=A2 Update the security model based on existing standards to authenti= cate and authorize utilization of the service provider=E2=80=99s resources by an IP = PBX. The security model should also define methods for ensuring the confidentiality and authenticity of messages exchanged between the service provider and IP PBX. =E2=80=A2 Specify the consensus method for supporting IPV6 and IPV4/6 Dual = Stack components within the reference architecture. =E2=80=A2 Specify the consensus method for supporting secure media (SRTP). =E2=80=A2 Specify the consensus method for supporting Video enabled devices= . =E2=80=A2 Specify the consensus method for supporting emergency calling (NG911/NG112) and the transport of location information. Please do not reply to this email but rather provide comments on the SIP Forum Tech WG mailing list. The SIP Forum is a totally open organization (i.e., you don't have to be a Full Member to participate in discussions - just to vote), so joining the mailing list to provide feedback is straightforward: http://www.sipforum.org/content/view/28/139/ Regards, Mary ---------- Forwarded message ---------- From: Marc Robins Date: Tue, Apr 29, 2014 at 5:24 PM Subject: [SIPForum-techwg] Call for Comments on SIPconnect 2.0 Charter To: techwg@sipforum.org Dear SIP Forum TechWG Members, The SIP Forum has officially begun the process of restarting the work of the TechWG, focusing on the next version of SIPconnect -- SIPconnect 2.0. A draft SIPconnect 2.0 Task Group Charter is attached to this message, and a formal call for comments is now being made. Please review this charter, and respond with any comments by the deadline of May 15, 2014. In addition, please contact me directly if you wish to contribute to the work as an active participant. All best, Marc ************************* Marc Robins President and Managing Director SIPNOC 2014 Program Chair SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* SIPNOC 2014 Registration is Open! SIPit 31 Registration is Open! _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --f46d04374abfd8f46504f843c9f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm forwarding this as I think this new activity might= be of interest to the community. =C2=A0In particular, since the focus is a= dding recommendations for the following to the SIP Connect specification (a= vailable at=C2=A0SIPconnect Technica= l Recommendation Documents and Presentations):

=E2=80=A2 Update the security model based on existing standards to authenticate an= d authorize utilization of the service provider=E2=80=99s resources by an I= P PBX. The security model should also define methods for ensuring the confi= dentiality and authenticity of messages exchanged between the service provi= der and IP PBX.
=E2=80=A2 Specify the cons= ensus method for supporting IPV6 and IPV4/6 Dual Stack components within th= e reference architecture.
=E2=80=A2 Specify the consensus method for supporting secure media (SR= TP).
=E2=80=A2 Specify the cons= ensus method for supporting Video enabled devices.
=E2=80=A2 Specify the consensus method for su= pporting emergency calling (NG911/NG112) and the transport of location info= rmation.

Please do not reply to this email but rather provide co= mments on the SIP Forum Tech WG mailing list.=C2=A0The SIP Forum is a total= ly open organization (i.e., you don't have to be a Full Member to parti= cipate in discussions - just to vote), so joining the mailing list to provi= de feedback is straightforward:
=

Regards,
Mary



---------- Forwarded message ----------<= br>From: Marc Robins &l= t;marc.robins= @sipforum.org>
Date: Tue, Apr 29, 2014 at 5:24 PM
Subject: [SIPForum-techwg] Call for C= omments on SIPconnect 2.0 Charter
To: techwg@sipforum.org


Dear SIP Forum TechWG Members,

=C2=A0

The = SIP Forum has officially begun the process of restarting the work of the Te= chWG, focusing on the next version of SIPconnect -- SIPconnect 2.0.<= u>

=C2=A0

A dra= ft SIPconnect 2.0 Task Group Charter is attached to this message, and a for= mal call for comments is now being made.

=C2=A0

Please review this charter, and respond with any com= ments by the deadline of May 15, 2014.

=C2=A0

In addition, please cont= act me directly if you wish to contribute to the work as an active particip= ant.

=C2=A0

All b= est,

=C2=A0

Marc

=C2=A0=

*************************

Marc Robi= ns

President and Managing Director<= u>

SIPNOC 2014 Program Chair=

SIP Forum

http://www.sipforum.org

Mobile: 203-829-6307

SkypeMe! marcrobins

=C2=A0

********************= *****

=C2=A0

SIPNOC 2014 Registration is Open!

=C2=A0

SIPit 31 Registration is Open!

=C2=A0


____________= ___________________________________
techwg mailing list
Send mail to: tech= wg@sipforum.org
Unsubscribe or edit options at: =C2=A0http://sipforum.org/mailman/listinfo/t= echwg


--f46d04374abfd8f46504f843c9f0-- --f46d04374abfd8f46904f843c9f2 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="SIPconnect_2_0_Charter_Draft.docx" Content-Disposition: attachment; filename="SIPconnect_2_0_Charter_Draft.docx" Content-Transfer-Encoding: base64 X-Attachment-Id: 46429a0d304b128d_0.1 UEsDBBQABgAIAAAAIQAwySgMcgEAAKUFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMluwjAQvVfqP0S+Vomhh6qqCBy6HFuk0g8w9gSsepPHbH/fSaBR1UKQClwiJeO3+OXZg9HammwJ EbV3JesXPZaBk15pNyvZx+Qlv2cZJuGUMN5ByTaAbDS8vhpMNgEwI7TDks1TCg+co5yDFVj4AI4m lY9WJHqNMx6E/BQz4Le93h2X3iVwKU81BxsOnqASC5Oy5zV93jqJYJBlj9uFtVbJRAhGS5HIKV86 9Usl3ykUhGzW4FwHvCEbjO9VqCeHBXa4N4omagXZWMT0KizZ4CsfFVdeLiztoeim2ePTV5WW0OJr thC9BETK3JqinVih3bf/gz7cwk4hEvL8RlrqoyYwbQzg+R1sebvkKaxx9AE5leNkfajrp0Dl9D8C xKSh7c/B/BFSovQvsfkdc9f2myomOnTAm2f/5AwamqOSFZ3LiZgaOFnvT/1b6qMmVjB9v1j6P8i7 jLT9kz7+I4zvO6tG72kdby7Z4RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03 Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1 nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDaqRepYAEAAJ0E AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKxUTU/CQBC9m/gfmj1jlyIWYyhc1ISDF8WzWbrTj9D9yO5g4d87NkJLxHrp pdl5Td97OzOv8+VeVcEnOF8anbAoHLMAdGpkqfOEva+fb+5Z4FFoKSqjIWEH8Gy5uL6av0IlkD7y RWl9QCzaJ6xAtA+c+7QAJXxoLGh6kxmnBFLpcm5FuhU58Ml4HHPX5WCLM85gJRPmVvKWBeuDJeX/ uU2WlSk8mnSnQOMFCe4BkW7miVO4HDBhRyQkn4xftjAb0gJSa6DVb0rePKM+D5MhPXg8VDTHtglN 3ScfDSmvd2oDjubQOjhBfSbiIU1kRuNabKrOLE5Qn4m7IU0UtNmuKvW27cTPmtd1HfrSUnR2qglO apSlBNJeG/uduxEBH9KkSmiOwm9HdKa61pURkuelHE1nMV8hKDpO4ogfJV6MpDQ97RGcFn/u/HTI a9awefuVvA547Dc/+6ksvgAAAP//AwBQSwMEFAAGAAgAAAAhAFXBZKd9DwAAqmQAABEAAAB3b3Jk L2RvY3VtZW50LnhtbOxc3W4bNxa+X2DfgdDeOIAsS6pjp9paRRMnXQP7Yzhuu3cFNUNpZj0znJIc yepVX2OBXaDP0kfpk+x3SM5oRpZkJ1WyUiMDiaT54c/h4eF3vnPIL768TxM2FUrHMrto9TrdFhNZ IMM4m1y0vrl9c/yixbThWcgTmYmL1lzo1pfDP/7hi9kglEGRiswwFJHpwRR3I2PywcmJDiKRct2R uchwcyxVyg1+qslJytVdkR8HMs25iUdxEpv5Sb/bPWv5YuRFq1DZwBdxnMaBklqODb0ykONxHAj/ Ub6hnlKve/PSN9nWeKJEgjbITEdxrsvS0vctDV2MykKmmzoxTZPyuVn+lNpCxWcYjzRxzZ5JFeZK BkJrXL10N6sSe91NdXsBUhHVG09pQrPOsiUpj7OqGNKOpfGvBq+DwTtxdZ9QUYuOQBZD6NJIhnP6 zNlsAF0Mby5a3W7/8+dn569a5aVLMeZFYmp37BvXij6U+0h4NsHzU55ctER2/PXL1snwixN/G585 PUafDyrrXZ6fnvZWVebvfJzKXnS7vUtMBieGa+rsw/p1zgMMPR7iYyOg/5i1s0ES0xD0T6sfN0WC C7wwkqQwG8jC0DN/nSaliHruhheeeiMzo3FPcG2+0jG/aN3GqdDs72LGbmTKMdizQaAfXrbFj9z/ r7T9DGQiVVVP7+z8xQtXmf6xvNo/La+8olrtoLlryyMGaeABqxjX1N2uF1Nt5Hev8bOBNY0DGi2M Q66EFmoqWsO3V9eBzDIRGNbvdBnpo3FaavtT9rQ29uWlver88JbrO/a1kkXOXkVcQVMbXV05DZv6 f9PocCmFmiFoPn6YLk83cI9JtmkPP65kG7ajb/9KSwEdqNmJ2UD/uAXbsZX6aBLfRoLVZvetCKIs DnjCbgRWQICl0AIOFmvGMxanuVTAVobFWVhoo+b4EpsYz0wFMxE3bFTESaiZzJi4j7Uho3/1+vaN h2QKt4xkoRjDrDPOUmEiGTLgLRSE6eatDCAOGwkzEyJjV9fs+uU/qfqQfSvxi2wSMBUDopjGoVAs w5NS3em2fUbnIojHMRYBzpQYCwV0iKpUEMUGBqxQoo3rPxSxEiGVYSSE6YofC073fUHobCIILjoJ KKxNGnURiuHoOLVZC57iqqZG5kIo6u2T2607jxuXpk4/alyaj+/xFFhpaZu9e1QY56dn593nBABo Gd5jYcwG0TwXCkjojqlBHF601FVoOxZhhkk1hxtkMWkFOd5hIf7oluRb57qxXqe3rP9VN98XVbwL UlsLdn75eRsAZ2tyjbiGTYEhtE5pksyZgkGCgQvZaA6ba+03eyNVkbIjPCvH7G9k7VivzfrdXu/Z wczAtVqN0rdhZppW6almptevnJ6NHtB2HJ2tKCMJy7uuJa5tQLLtuTZbaS6hm6uM8TAEQAGeaM4U mlWhmIoEjE8IpFDDQIFQNL8Ct+wT7LDQBA8q7ugfgg0TxdMnzKzXl+eXr/vlIvTomnVQpq37yVtT pu+iONGmpimN5avm8Nfc/T2ZKMRkPvT61y6DOz7tV/cGeIO8mBH5NZaKgu+AxbRC+TADs9hEsbMU lX/TNBubhnzTVN8927haSArSmWTxj/B0rDeH3itynuw/mExIZxbFABckFu9peUPpfSrNxoWi1xj5 ZOTs3QmRMzAq5PdxI6yU4UfNSi+MXCznfxn4aqHuNPVuG2v0+5EuhzV6A3e6NbN66xmI38/UGjqq dF2H9tJ6Nufk0mK3X5ZvSBR2jenFomDNHPwrwQJH+2IxWNBUuKvFGosF5S05JKaLnOix9mJNqTFH jpwqGabS9tlqxkUyjpPE2lRvRWs2USK8yUeJqFDoOr0i2PFZ97x3/nI13Ny9NWhYAeqSNAMMP3bd DcGpHW/q6p4pHXGYm7qzZyPXZuzty1e//vTvjZ3arzFaDYksqVzXy5Uk9IdALQdncHedwV9+/uXn xnTeBkz9kIz1doikdyFYPx5f9C6tAokVBwheTwfwdRDHApv+/X0Xf9/HvW4frLo2c0pCmMWhiQbd P0cinkRm0Ouc5qbF5CBS2uAd/z2TOuIhHve/7RdazC08vmj9qd8H+YNAmbwTeGtMQUGSi20CvqzL 7Wg6LDeH+PEj6RbbmH3vZ26fRuMeElk+ahYOcb+v7xEINgDy/yhMXpgmTvn/6cuBVPgIpMJqJHeL cCkzlOIzsSk+M3K64L2FBRIEGov5fvu3fF1f9pN5APb24c11/do/wn0po25Tx34XPhTxyotsonXd 3U/9tES5y2ha1zFS0P0ax2FzvawZxP0cJM5IAREG1sJQikQV9qlRdC4Nrcz6QpoKYh2Uq6aRKkZ0 oA0Dj5EaS6lwLi3NBTNs+LjirZbz0zqMKO7mDDjSz/Aqlh8XQ5n7qIrbt0BJcimy6xCrKjlFEbZp paJ8N3wiwQ2E5KSIQ065bT5khSgNIjQzG7EBZVnLuEsER3peilT0GCltTOZ2D0HbFu5S3BC0yQK6 yml7A5vw3MZ6qhS+kuMsU+NCxGzi8RyB8xHXgnK0S8FWDKedFjqSRYJEFRCrTvwQ40J4+LEsrIWQ O+xtgUAT9dJWgK6RwDJprASSAqKgbi6NJMa2DPkji5HWjmbXKJ6fqzhFUsC0jHKF0haL5MNxAs/M DSqV7Ru9VIXLBERF9MiDcX1CUsC2vbs9xpQrgfhBPrSQrN/5cZDPZvk8P++dPn9dRUFq7EnzzieQ rLVyfjWZjkNSEoRk6dFy0u0N2kmw7ekGORNI0giv+US8BAS4s5uZ1mzkQZooywuVS421z65gTZe4 iWQ8xsEjDt4iUY6y6rF8TpHI0XaI4rjAGm5XyoJ2DlhowfRcG5FigcSOAB8WpTcDIBGVzI/L4pbB Ay3XCwxEGzixZQxJOUxiqVXsyCEXnjxDG3zi/lK2SG3o9i8euo62ANBZYi0MvwMKDQJZYC9GiUQk sJ0PyhEwg8wsQgFUEwpjBsiIkCrikAzp8IRhEXwmmLi8nYLurpfqjsP/4VcGfY/A2bOE0jvbto8L 5A7IubLThcHGXkp7so7CKM6cXwDRWp2MJ4SMoY0ktVSEMWdG8UxTvJ8VtKuV3dxeb3L/ep+fvegu tobuuhhP3m7oz443fvU0cm5YQxNgOa318qaQ5gftNWIBXBS4LDTysJc8m3v7UxodPJDblAyoh4C9 GiUxdmSTdrCppK1JsK60PZ0daXJhYDQ3acaeRf6/E6Ob21frOrTjqjFss790Put/1mYhnPrAIAHU bzmjLHDMcTlhv/70n1HCgzuWRzhA4Nef/ttmwgSdZ4wSgAWOHshC2q5W8gTOUAQRDbxmU9oadhR3 YEHJzpA2pXzuHWBrhEOy15UvTtaXmAayK6RvKDyXUFL9zFmupvUR98hPyiY+VRXq9sB4l7wBrFMg rI6Sxw2Ln03Q9nLFgIWH/27mbc87+CZSeTnH9hJ41f4JNlYyhYWjNvp1Bn3qMGTWI1dWw/0lBgM5 T2VvCU9I6u80FjM0FBKl/YQQtMUOviHULYsbAFqwgiH1yhbQhCY+5ckyLo1cU5rKBEokBF7nA9os kjNYfeWaY2epPa/BVuDNtm3cQpCVHpQpSCuXBxoe9BtHOmSI5SYJOlYfLGAcN89x0WqNG1Bfo1BI OAYZwUOeY7vWzuz722PaoAbzdt3ivJUpKDdHFpVazOToX5g1loHyt2oID0TeoGFft+LENfDHGs83 K1K3wydOFkcudN1OZty7Qoq828xsj2FAs6oXFgc8jAQlUmJLYteGxt3Pr3Ckg3+ENiuiGH8OxNnT 4udIx8c7iRibi9bpC9+i7aS0bCWRee88RzP8JrfZ+DB3DV2rzSxyoDZRBbuXULoa+WGRWrUNHCsO eacCmw+gsd5Z8oyv31LOhKPHH+77XtqCjiUPpp9We78NfJ1Md9xarRHg0evOBICGQiCBJd69m/ls XTf3T3WGT+DtN02GcqdXjWxsPn4wuXQcz8OTdvr274OelvEbT9rZygpBKUlv7dEUbtM2qK84WNBY 2LqNJa5yMMW9ERm5kIgTWjNV4npPpgF/YvO34ECd3kSVEGO1rTsod/NgqQOe2OpcXFZucc8RRr15 g5Nu4Nk58raKJdcIXq1lgMNjSn8WWAQkZTkJ/BZEq/koZRFK3p05cMDUD85b+6QNvMPUvx9QtAYO ruvgjoPb4afg62gRFIpyeFKJvBmbngPGsXYa18L8EjNYQCagAhG3cxEhuiAVIiHMRUSqMAiee8A2 0vYvYgBloYj7BCKpcnsc277UGG/CeaKrI8DcAWDWAwP3qdF00OhUFyXjOBLSpSQRPKpaS/0jFpWO 4pqg5gWd9yiL59y0p+ChhnF/PEjeePwA9g9gvwb2ocyatBt5fYsD7zyMIYW/uv72zIYA8OX05Ixd FpS7ZigIAUIiRxjCHnO6OJ7i/VF+Q03fS6tdCUT++OOAKhLwwBrS8Y4lR7pLh8V+EBf2Ma221h95 pzZcfkQB5SedRfbbNdQdjHzQUHhN5eGjnybJUtPQ/wEAAP//1FTBjtowEP0VK6f20CVJAwtoQdqC inooQlD1bpxJsOTYke2Q0q/vjJOwS9netxyC53nseeOZeeBPJmeFscw1dW2sl7pkP2UOhoHmRwU5 y+EsBbiHp1E790v62vCtl0/tvGZoOpnvF1EcJ7PJNF5FA7SzBE4RX0+u4BoK3ih/774L0Poxy5Io 3LzDMO1cN1W3kOqs8OYzV+gYjfq9b/mAJYQhuesBV3NB2bTzI2CCsIiSOCYenfnceNO74A7hvPCA lCfBSUmNJ9LsauwbhQDHU11wqSm0ggJzyaY9I9txtV+N9g63gTv/7CRfRD9kBY5toWV7U3FN8YS7 h0NewigsSJ9rGn5dTPf7imYDsqI44VXSgFF9iAX+1z0bdAg1uikIPeA7oou9xX5Vak4lwXeuLTiw Z4iWhxqELC7Mn4AJox1o1zhWvdm4UIEtQYsLE1xhBUt207SY8PAU1Gyr1SQeT6kS/+/rfNhuZkky 2m6SJP34z2zfeeGXHGeJ6ust145UiJmCKSO4l0YzqXF8q7B+uKkntXiQiqGEryRkgLrUk05XBvC1 CN0pTj8UigftCJMF+tPmS68vN8M1MHAg/O6muf6K+BaNAx4ixulsPHlcdaJXHmjEW1SktNeeE67H U9ShIA11+Z1THG9qxLNOnqwsT3jTYB6N96Z6sTuNGnZPwHOSucc4tH5hTFC93iwbH8w+HCoRyUs/ lOQTWORGbKwM+ocyuZNeIMvPKJydBHevESToaPJLWOCRpgLtl38AAAD//wMAUEsDBBQABgAIAAAA IQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3Ya B3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhe kjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61 jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTg GMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNur mZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaW Ms1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3 u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/j og8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+e HT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z2 7MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlm mXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuL E8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2 aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrw dEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1x VQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20MXFw5hgL44uvH FZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2Uz2cttLPaCmVX 9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklxYkojeMzquoMLBTZrkODqI6qiQYRTaLDr niYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85oxVN4KzMVq5k REHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W733twtxgsX6SIZ 4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kEz7yk8/ZEOrKk nJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSowzWFtfucwk4d SIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aURbTv7mpVSPlFE DKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0z2QLN3lcyGDe SuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+gMbB1A6IFriL hWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExElcSVqRV7RA4J G+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT0OT2L0Ss2FXt erM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H6T+w/1HhM/tl Qm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9YWwt2Vn8fU5j F82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0wwTclgaH1HJg8 gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQAQESW/NQMAAH0HAAARAAAAd29yZC9zZXR0aW5n cy54bWycVWGPozYQ/V7p/gPi82UDLIQEHXvShs1dq932VO5+gIGBWGtjy3bCpr++Y8CX3ZaeTv0U +715j/F4PPnw8YUz7wxKU9HnfngT+B70tWho3+X+t6+H1db3tCF9Q5joIfcvoP2Pd+9++TBkGozB MO2hRa8zkfsn1We6PgInesVprYQWrVnVgmeibWkN848/K1TuH42R2Xo9i26EhB7dWqE4MfpGqG49 KQtRnzj0Zh0FwWatgBGDCesjldq58f/rhp86OpPzjw5x5szFDWHwo8j5uINQzXfFz6RnBVKJGrTG ynI2HZcT2jsbzX7GZ6rnI60UUZdXJnd4bX8Jwb0hOxN0qkCbAzU+7iWoGguc+1G489c2sBG/C1NQ LRm5fCEd3IsTtoGioEca8xRtaYgBVGsJjI09UzMgmO2QdYpwTvCOJ2SyhJacmPlKqtII6bJIo2D6 Yn0kitQGVClJjW570RslmIsbE9oLLhXWZ1bgjpjRG1u40TZvu/hTCONkQRAWaRyHk8Kyr5jdZhvs F5n/1ES7ZJMuam6DNEzvl9ySNIyThyUmjTdpkCwxW5v4ZonZbcM0XNTsivQh3i5p9vtNkCwyD0Va PERLmkNxW+wWz3M4JPsotZr1VHCsPM/sS/qi3OqAt+fxqdH2hFeKEu/JvjVU8axSz/e0d3wF+Obh NVOeKkeuVhOhOWHsgB3iCHxmE9NglxbQjsbsiaju6jy2Fs/UItpA+9t3N9v+oD4pcZKT66CI/LVv EHYfDON49qO9eaTc4fpUlU7V45N7ReGb+eOsrOH6WqAhMzglwVbokfSd60foV99KGzpkNVOlnaTw RKTEp4AhVRfmPqPd0YT2fRnc4XN8HjdVF81cNHK4s9y4IbU9GUbPCxswLTFqXlyxW4fdXrHYYfEV SxyWXLGNwzYWO15wpuBQeMaJ5ZYWbwVjYoDmswNz/1/QVAR9JBLwXu3MwAYT2QjgpY2Ad87gBQcW NHaCaUkbTl5yPwmjsZnnaBxe4mTexFonGyzfoF5DDMG/wPGq3ojHJv9HLjgeoabYkOWFV9cRdTMl zqg2JUicZkYoPPI4bN+Pztf/zbu/AQAA//8DAFBLAwQUAAYACAAAACEABeE5FTkBAACkAgAAFAAA AHdvcmQvd2ViU2V0dGluZ3MueG1slFLLbsMgELxX6j9Y3BvcRHJbK3akKMqppzb9AALrGAlYBMRu 8vXd2H2kj0NzYtmdGWZ3mS9erck6CFGjq9jtJGcZOIlKu13FXjbrm3uWxSScEgYdVOwAkS3q66t5 X/awfYaUCBkzUnGxDBVrU/Il51G2YEWcoAdHtQaDFYmuYcexabSEFcq9BZf4NM8LHsCIRA5iq31k 72r9f9R6DMoHlBAjGbFm1LNCO1aTR6W7+H5mfalVxWbTu2L2MCuKob5FdVjpjmqdMNQ/4ye0FeER mvSRzT+zT3rX/pHeoP+NXWJKaH/kyc9ShdMb6YvjaLKMgPFYMZo/BV5ImvUQSzRIcxX7hKMNc+bs Mub2m6PLuOG880uofFjC0PQY1vPxHPaCPmmrj7DGsAzYRwi0AKqf/a36DQAA//8DAFBLAwQUAAYA CAAAACEAIRjiroAIAACIQQAADwAAAHdvcmQvc3R5bGVzLnhtbNxc31PbOBB+v5n7Hzx+unugkIQm B9O0Q+lxMEMpJTB9VmyFeHCsnOXwo3/9rVa249hxvIvNdOb6QLAs7ber3f1WgLYfPj0vQudRxjpQ 0djtvTtwHRl5yg+i+7F7d3u295fr6EREvghVJMfui9Tup4+///bh6VgnL6HUDgiI9HE8dudJsjze 39feXC6EfqeWMoJ3MxUvRAKP8f2+ms0CT35R3moho2S/f3Aw3I9lKBIA1/Ngqd1U2hNF2pOK/WWs PKk1aLsIrbyFCCL3I6jnK++LnIlVmGjzGF/H6WP6hB9nKkq083QstBcEt6A4mLgIIhWfn0Q6cOGN FDo50YHY+nJuZm194+mkIO1z4AfuvkHUP0HmowjHbr+fjZwaDTbGQhHdZ2My2rubFDUZu/nQFOSO XRHvTU6MsH00M/ssmLvcMB6eUJWl8GDjAEfMEgkOBH8YnDAwju6PhtnDzSqEAbFKVAqCAgCsKBYe SzsOfgUvT2yUwFs5u1Teg/QnCbwYu4gFg3cX13Gg4iB5GbtHRwYTBidyEZwHvi9NUKZjd9E88OWP uYzutPTX49/PMMRSiZ5aRQmoPxxhFITa//vZk0sTYiA6EsbDV2ZBaMTqAg4qtArW2tiBEioO/ptB 9qwPt6LMpTBp5KD+O4HQ6lVroL6xqGgAymXpOmgv4rC9iPftRWDwttuLUXstgDzbesTGRiEq6U5N lGeDr7gPg6MdIWtWVKKocUUlaBpXVGKkcUUlJBpXVCKgcUXF4Y0rKv5tXFFx584VnkDiKkfRAHeD lNi3QRJKs34nAfVaUl1aapxrEYv7WCznjimsZbV3keVkNU1oqiKdvp4sJ0msovvGHYHqbFL31Zz8 92I5FzqAE03D1vdbbv2tmIbS+ScO/Eao9zb4KjbhwWRrCbsOhSfnKvRl7NzKZ+tRxvor5UzsKaNR uZZuvQzu54kzmWPJbQQb1mx6/U5Y+ZeBxj3YmUzDGlOahJN8OKyJy3rhX6UfrBbZ1hBOI0PL5ww3 lyBQxd1bdGhcVM2uRiuMAygm2HLBNwHlE/S3xYUv3/iYor8tRa+UT9DfFq5Xysf42O1fNtN8EfGD Q0qvETt3T1Wo4tkqzHKgkR5G7AzOIWgmsJM4l08iiRE7gzfo0znxPPjJjRKnbF+seZSBwnaHRcFk o9vCdkqJ9noMi9gOKmH1GVjtuJYBxCbdG/kYmF88cYsBsnR+1mxM50HNDkAJIp2hv69U0nyG7tdw HhXlIoJfl2jp0NAGNZlHRUvjydY7ho/bFT4GULsKyABqVwoZQDXxUX/myWsiHaR9cWRgsWk5r2IY dmRmHrGZOQfilYCO6ibh/FWTvfWxUK2bBBS2g6p1k4DC9k6pluV1k4DVWd0kYNVUjXofFTmVYxS7 bhaB8pMAwaJuyJsA1A15E4C6IW8CUHvybgbpjrwJWGxuyDm1SN4EIJzC+VE/ByqSNwGIzQ2W7dLf GWV1D6Xs/uG2A/ImoLAdVCVvAgrbO3XkTcDCKZxIKGHlVEfA6oa8CUDdkDcBqBvyJgB1Q94EoG7I mwDUnrybQbojbwIWmxtyTi2SNwGITQ85UJG8CUA4hcMNW8kbs/7NyZuAwnZQlbwJKGzvlAg1P6QS sNgOKmHl5E3AwimcYEixMLg5RnVD3gSLuiFvAlA35E0A6oa8CUDtybsZpDvyJmCxuSHn1CJ5E4DY 9JADFcmbAMTmhq3kjcn45uRNQGE7qEreBBS2d0qEmvMcAYvtoBJWTt4ELIyX1uRNAMIprwXiWNQN eRMs6oa8CUDdkDcBqD15N4N0R94ELDY35JxaJG8CEJsecqAieROA2NywlbwxR96cvAkobAdVyZuA wvZOiVBz8iZgsR1UwsqpjoDVDXkTgDAwW5M3AQinvAIIs4jjpm7Im2BRN+RNAGpP3s0g3ZE3AYvN DTmnFsmbAMSmhxyoSN4EIDY3mHu2cF+UfD21VxME1HsG2a0GMmC/xklUwNTAGzmTMXQyyebbIS0B MwsZiDXhQTXxs1IPDu1i96AmQMhQwTQMFF7pfsFbOoVGhMFoRyfB7bdT59w2wFTWYUht3ryB7qFi uxC2J5nGIdAzeVlCy84yu1lupEGDkOnrSluAsA/tAhqC0rYes9j0+cBEbKpKh/Hvtikqfg89b342 5+Cgf/R+ODpNG5xQZIMSOWxqZh/7jYrAWQNQ2ug1FdC29M10IVXUgparh2w8E3c6F7Hd4HX7RjYn 7eGot6b3ZXR4mN63r7R7TSU05cGe9my/l308gfYube9qp/uadoWls/CpOiltFjvEv4mZh81msadj tUrM8OVjmCmPatnuMbPF0JiHHxuteGP3NlhAc+GVfHJu1ELgFbGsFW/rS2zF2/rG09VhDICp/Xqq 8XPdmTcY2n3XP9edeXYMtEZ14bMmRDzwmvCgnW5HnKbdEvkFNuyVKEdtTUsFqloNiNTV6wO4nbdx wReG6vVOTBvBDp2xzWBngjk4pTZi05Bt0jC/kocGJNPQRgd8cxGZbIXOUAw1ywr+s7CA8P5UhuFX gbGUqGX91FDOEvu2d4BHqZKoqUoStahfH2OnAWqyTQBscVEZ+2iMqN/7aLWYyhhaBXfs/5UyR5AK xUCDBY7XhAX0U+Kbpl2v120jnr2Vhq2ZGGIuc+8Ga5VjOX3p9J01qZXYcGtOoO7buLE2yuyLTWYv cuH/i2w2imJej2yW/pDTLdFi+l6dP+Ddn3anSl4olsoqyVCjCUhyo7QWHfArixFEeQr/68JgXWX6 h2luFqqMHQM9OVVmR1aK5TKUe56KoMM/kf6eKfCyEhbbZ2HyleKjPkvrPE5kljx4z+G0F5uUr2i5 fsPT7G3iOI0gz7SWQK3AE90B/Ds7S7kpGzT/NwFUVtC56tZsc/TH/wAAAP//AwBQSwMEFAAGAAgA AAAhAGd0rgpfAQAAhgIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAISSX0/DIBTF3038Dg3vHS2bi5KWxT9ZfHCJ0RqNbwh3W2OBBtjqvr20 3eoWTXyk59wf51yazb5UFW3ButLoHKWjBEWghZGlXuXopZjHlyhynmvJK6MhRztwaMbOzzJRU2Es PFpTg/UluCiQtKOiztHa+5pi7MQaFHej4NBBXBqruA9Hu8I1F598BZgkyRQr8Fxyz3ELjOuBiPZI KQZkvbFVB5ACQwUKtHc4HaX4x+vBKvfnQKccOVXpd3XotI97zJaiFwf3lysHY9M0o2bcxQj5U/y2 eHjuqsalbnclALFMCioscG8su9bSQhPdb7w3OsNHSrvFiju/CAtfliBvdixacCuiJ/MRWBn+rbcj FrZl+2DsonMMx3Bp17G/GWQUUtO+40F5Hd/eFXPESJJO4oTEJCnSKZ0QmiTvbbST+bZF/0HtA/5L nMTkqiCEkvEp8QBgXeLTP4d9AwAA//8DAFBLAwQUAAYACAAAACEA78WDmjoDAADGGwAAEgAAAHdv cmQvbnVtYmVyaW5nLnhtbOxZ3W7aMBS+n7R3QL5v8wMFippWrGmlTlM1aZ12HYIp1mI7sh0ou+zL 7BH2WH2FHds4DWiKaMlFJuWG4PNrfzmJ/Z1cXD3RrLfCQhLOIhSc+qiHWcrnhD1G6PvD7ckY9aRK 2DzJOMMR2mCJri4/frhYT1hBZ1iAYQ9iMDlZgXqpVD7xPJkuMU3kKc8xA+WCC5ooGIpHjybiZ5Gf pJzmiSIzkhG18ULfH6JtGB6hQrDJNsQJJangki+UdpnwxYKkeHtxHuKQvNYz5mlBMVMmoydwBnPg TC5JLl00+t5osMSlC7KqW8SKZs5unR+SbS6SNeBMMzvtNRfzXPAUSwnS2CrLiIFfl3sLoA5Rehwy hd2cbiY0IawMo8tj7/6XN+8Ubp5nc3s61OtCAItLKKZkJpVIUnVf0N7O6G4eId+YMEnmoFslWYTC 6+mgfx1MkaedaZEp8gWvcPawybGzMdJMS62VonnmdHEc3/ifzodWk620gsDF5YKSF8oZB9YK6v2W lsJZkWVYlf4P+KlUvTz/KeWfUxclw4utef5V6FkrWPP26mwgBYL/OZcRGoW+juK9GhKm16/jWC0M lgl7NI9qf+ist9GFTSJuOVMSLBOZEhKhbxs641B+4DoFQHcEhEHgOV4kAKddgPwFhhZwF97EhUkB WHryVegCHVbB0wUPlX4ZBOa2HQUlbwDIYDBwk3eQV5E0ao3HW6G85oUgWPTu8bqC5770WFDD5kF9 ef7dAKxhUJbcv2A16vfA+gPqWW8/8EIui3RXdiyk/dZCOh7XVWqo1e2EdNBWSOG9WAepUbcT0rO2 Qjro1+5MRt1OSOGM2fQG1cy79Myv3aKMup2QjloL6ah2ezrT6nZCCoyrnVU6HNRuT0bdFkjhhFqh FPqkWhnCJCsjzTDsUbXKMIbTOB5OR317Uno7wwjiOByf34zLkxYk7RhGxzB0X+VQsrbPJSxj25ce exzuGAbQ4I5h6K5CxzAi9NY+TccwdlpfTbQWOobROKQdw2ge0o5hVHveTTz4/zfDgO49HPLh95VR 7NAMUJpeumtIgaUmJjtu4f7XkDvd8zdu5jME8BrjZq/2+9vlXwAAAP//AwBQSwMEFAAGAAgAAAAh ABDbLFv4AQAAJwcAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzUlN9vmzAQx98n7X9Afl8xDvnRqKTq j+VxD1urPjtggiVsI58Tmv9+ZyBN23hakTZNS0RI7o7j+OT7vavrZ1VHe2FBGp2R5IKSSOjcFFJv M/L4sP6yIBE4rgteGy0ychBArlefP121y9JoBxFer2FpM1I51yzjGPJKKA4XphEac6Wxijv8abex KUuZi3uT75TQLmaUzmIrau7w3lDJBsjQrf1It9bYorEmFwA4rKr7fopLTVbDdFG71Fzh1D8OamPq Lt5wbUAkmNrzOiN0iu+EMjzmdIbnKZ2T2DfIK25BuJdC1odLrmR9OEatUVz3iUa6vDrG99xKvqlF nwK5xcQONhRvOLxIH0kQ+tsIO6uZvI3kXZ/Fq6swgn1eOuP4cf/3nIF4kEpA9E200fducl/wnghD CjM6QRIpHgy/pWEi9M8QQR1QdrOYn4i8fjakdiKCYuw4Bol0z5+s177m40TuzM5KYT2ToD4Y6mJC L5GD1wZDJmNoKFMIGxJIKZ9Fca6Of8viCY3knQ9BEtOjwE7nsC6CTuE7Z/ry/8Iod7yWGyuDIBhd d1LwkkhRHPgZBhE0CLQSYBSJGw+cfe2EjXZAq6c+QOe3gx1OBsH1/RuD0MuxBuEKQfBfkPArol8V fmWMIzF+eYZJUJr+HRLDFoXVTwAAAP//AwBQSwMEFAAGAAgAAAAhAFZEYyzpAQAA5QMAABAACAFk b2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFNNb9sw DL0P2H8wfG+UrzVFoKgYUgw9bGuAOO1Zk+lEmCwJEhs0+/Wj7MZVtp7qE/lIPz4/0vz2pTXFEULU zq7KyWhcFmCVq7Xdr8pd9e3qpiwiSltL4yysyhPE8lZ8/sQ3wXkIqCEWRGHjqjwg+iVjUR2glXFE ZUuVxoVWIqVhz1zTaAV3Tj23YJFNx+NrBi8Itob6yg+EZc+4POJHSWunkr74WJ08CRa8gtYbiSB+ JjlmVDtsORtQXjmUptItiPmE8CHjG7mHKKac9QF/cqGO4vrLnLM+5OuDDFIhWShmixm9nQH8q/dG K4nkrvihVXDRNVg8dD4UiYCzvIWTN1tQz0HjSYw5y1P+XVuSkib0EWkLch+kP0RxkwQOGd8qaWBN DohGmgicvQH8HmTa7kZqUsyPuDyCQheKqP/Qfqdl8UtGSL6tyqMMWlok/1Jbn3Sx8RGDqDQa4qZa n3dh3pbHei5IOfVScNmYwF4DFS7VdRPiQ0Pfhu+IneRiOw291ExOFg4z/mFdu9ZLexI7q5sTre81 TX7/jjtfubt0OK9GXoLZ8p80HrZeKlrRfLZY5GeQlfiWrgVq2uuZ8A3g92R6MGkqnZDdQ33u+b+Q Duux/2vFZDoa09Nd0hmjcxh+J/EXAAD//wMAUEsBAi0AFAAGAAgAAAAhADDJKAxyAQAApQUAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MA AABOAgAACwAAAAAAAAAAAAAAAACrAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA2qkXqWAB AACdBAAAHAAAAAAAAAAAAAAAAADPBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQIt ABQABgAIAAAAIQBVwWSnfQ8AAKpkAAARAAAAAAAAAAAAAAAAAHEJAAB3b3JkL2RvY3VtZW50Lnht bFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAAAB0ZAAB3b3JkL3RoZW1l L3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAEBElvzUDAAB9BwAAEQAAAAAAAAAAAAAAAADmHwAA d29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEABeE5FTkBAACkAgAAFAAAAAAAAAAAAAAA AABKIwAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAIRjiroAIAACIQQAADwAA AAAAAAAAAAAAAAC1JAAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAGd0rgpfAQAAhgIA ABEAAAAAAAAAAAAAAAAAYi0AAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAO/Fg5o6 AwAAxhsAABIAAAAAAAAAAAAAAAAA+C8AAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAA IQAQ2yxb+AEAACcHAAASAAAAAAAAAAAAAAAAAGIzAAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAU AAYACAAAACEAVkRjLOkBAADlAwAAEAAAAAAAAAAAAAAAAACKNQAAZG9jUHJvcHMvYXBwLnhtbFBL BQYAAAAADAAMAAEDAACpOAAAAAA= --f46d04374abfd8f46904f843c9f2--