From nobody Thu Dec 1 02:56:45 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8DC129624; Thu, 1 Dec 2016 02:56:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148058980380.10340.6597188713544549661.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2016 02:56:43 -0800 Archived-At: Cc: sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_char?= =?utf-8?q?ter-ietf-sipcore-03-00=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 10:56:44 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-sipcore-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sipcore/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do you already have new milestones? From nobody Thu Dec 1 03:15:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2912941E; Thu, 1 Dec 2016 03:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AdvuaAl4_fdY; Thu, 1 Dec 2016 03:14:55 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC20129C80; Thu, 1 Dec 2016 03:13:40 -0800 (PST) X-AuditID: c1b4fb30-c294498000000c18-a2-584005e314a7 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 3D.75.03096.3E500485; Thu, 1 Dec 2016 12:13:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Thu, 1 Dec 2016 12:13:38 +0100 From: Christer Holmberg To: Mirja Kuehlewind , The IESG Thread-Topic: =?iso-8859-1?Q?[sipcore]_Mirja_K=FChlewind's_No_Objection_on_charter-ietf?= =?iso-8859-1?Q?-sipcore-03-00:_(with_COMMENT)?= Thread-Index: AQHSS8GdLpRD5OKjoE+Ok7Y9drMMW6Dy8uOA Date: Thu, 1 Dec 2016 11:13:37 +0000 Message-ID: References: <148058980380.10340.6597188713544549661.idtracker@ietfa.amsl.com> In-Reply-To: <148058980380.10340.6597188713544549661.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9EBB93F2BD3895478782A721F97679E0@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2J7oO5jVocIg18rBSxm/JnIbPHi+kdm i97PC5ktvv7YxObA4rFkyU8mj5aPC1kDmKK4bFJSczLLUov07RK4Mo5Mu85SsI6ronXKO+YG xlscXYycHBICJhI3ft1j7GLk4hASWMcosefSQjYIZxGjxJ/zS4EyHBxsAhYS3f+0QUwRAReJ 2V85QXqZBRIkLs94zQRSLizQxSjx+FsjWK+IQDejxL13newgVSICRhInFjQxg9gsAioSTXMv MIHYvALWEm0vv7OC2EICvhLH+1eA1XMK+EkcXjuREcRmFBCT+H5qDRPENnGJW0/mM0FcLSCx ZM95ZghbVOLl43+sIMeJCuhJrLkfBmJKCChJTNuaBtGpJ3Fj6hQ2CNtaYvaCHlYIW1ti2cLX zBDXCEqcnPmEZQKj+Cwky2YhaZ+FpH0WkvZZSNoXMLKuYhQtTi1Oyk03MtJLLcpMLi7Oz9PL Sy3ZxAiMwINbfhvsYHz53PEQowAHoxIPb8FLuwgh1sSy4srcQ4wSHMxKIrypLA4RQrwpiZVV qUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTAu81nlHsj487ILj7Nr +u55FWd9lixeKNLywjzkXrrA+twKxhAFjyZ/v/U3dt2ePKFyT11dCIfyo1XSSVtzQvUsH6xx UEk9mDWHT9Lu2k33fbYPMhb6uBX0216KVHLe8p6B7+4Zk4CfL5n5d39cWJUlnfwssnzXvl4u u7OP+WPsbFn493TvbFZiKc5INNRiLipOBACeS3fkvAIAAA== Archived-At: Cc: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Subject: Re: [sipcore] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_ch?= =?iso-8859-1?q?arter-ietf-sipcore-03-00=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 11:14:58 -0000 Hi, Some time ago, I submitted the following draft: https://tools.ietf.org/id/draft-holmberg-sipcore-content-id-00.txt The need for the draft came up during discussions in ECRIT, but I there are other use-cases too. For example, in figure 3 of RFC 5368 Content-ID is used as a SIP header field parameter. Sorry for hijacking the thread, but since Mirja asked :) Regards, Christer On 01/12/16 12:56, "sipcore on behalf of Mirja Kuehlewind" wrote: >Mirja K=FChlewind has entered the following ballot position for >charter-ietf-sipcore-03-00: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/charter-ietf-sipcore/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Do you already have new milestones? > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Dec 1 06:59:01 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723681293E1; Thu, 1 Dec 2016 06:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 J_L1EP09SPdD; Thu, 1 Dec 2016 06:58:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E691293F3; Thu, 1 Dec 2016 06:58:57 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uB1Ewu5I052280 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 1 Dec 2016 08:58:57 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Mirja Kuehlewind" Date: Thu, 01 Dec 2016 08:58:57 -0600 Message-ID: <93A25069-70B1-42E0-AB84-E4D4CC12E718@nostrum.com> In-Reply-To: <148058980380.10340.6597188713544549661.idtracker@ietfa.amsl.com> References: <148058980380.10340.6597188713544549661.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: sipcore@ietf.org, The IESG , sipcore-chairs@ietf.org Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_char?= =?utf-8?q?ter-ietf-sipcore-03-00=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 14:58:59 -0000 On 1 Dec 2016, at 4:56, Mirja Kuehlewind wrote: > Mirja Kühlewind has entered the following ballot position for > charter-ietf-sipcore-03-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-sipcore/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Do you already have new milestones? For the moment, it would be the same milestones. They are likely to adopt some new drafts that have been discussed in dispatch in the near future, but that hasn't happened yet. From nobody Thu Dec 1 07:31:07 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A13129482; Thu, 1 Dec 2016 07:31:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148060626400.10396.14893007483574692517.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2016 07:31:04 -0800 Archived-At: Cc: sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] Benoit Claise's No Objection on charter-ietf-sipcore-03-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 15:31:04 -0000 Benoit Claise has entered the following ballot position for charter-ietf-sipcore-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sipcore/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No milestones? From nobody Fri Dec 2 09:46:59 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BA7129715; Fri, 2 Dec 2016 09:46:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148070081514.29689.2088095583369538068.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 09:46:55 -0800 Archived-At: Cc: sipcore@ietf.org, The IESG , sipcore-chairs@ietf.org Subject: [sipcore] WG Action: Rechartered Session Initiation Protocol Core (sipcore) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:46:55 -0000 The Session Initiation Protocol Core (sipcore) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Session Initiation Protocol Core (sipcore) ----------------------------------------------------------------------- Current status: Active WG Chairs: Jean Mahoney Adam Roach Assigned Area Director: Ben Campbell Applications and Real-Time Area Directors: Ben Campbell Alissa Cooper Alexey Melnikov Mailing list: Address: sipcore@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/sipcore Archive: https://mailarchive.ietf.org/arch/browse/sipcore/ Charter: https://datatracker.ietf.org/doc/charter-ietf-sipcore/ The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the SIP protocol, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 6665. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications named above as well as specifications pertaining to small, self-contained SIP protocol extensions. The process and requirements for new SIP extensions are documented in RFC5727, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. 3. Standards-track extensions and new features must be generally applicable, and not applicable only to a specific set of session types. 4. Simpler solutions that solve a given problem should be favored over more complex solutions. The primary source of change requirements to the core SIP specifications (enumerated above) will be a) interoperability problems that stem from ambiguous, or under-defined specification, and b) requirements from other working groups in the ART Area. The primary source of new protocol extensions is the DISPATCH working group, which will generally make the determination regarding whether new SIP-related work warrants a new working group or belongs in an existing one. Milestones: Done - INFO package framework to IESG (PS) Done - Termination of early dialog prior to final response to IESG (PS) Done - Invite Transaction Handling Correction to IESG (PS) Done - Extension for use in etags in conditional notification to IESG (PS) Done - SIP Events throttling mechanism to IESG (PS) Done - Presence Scaling Requirements to IESG as Info Done - Mechanism for indicating support for keep-alives (PS) Done - Example security flows to IESG (Informational) Done - Location Conveyance with SIP to IESG (PS) Done - Error corrections and clarifications to RFC3265 to IESG (PS) Dropped - WGLC on requirements for a mechanism to indicate proxy capabilities to both endpoints and other proxies in the path of a REGISTER transaction or a dialog-forming transaction. Done - Delivering request-URI and parameters to UAS via proxy to IESG (PS) Done - Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS) Done - WebSockets transport definition for SIP to the IESG (proposed standard) Jun 2014 - Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs From nobody Fri Dec 9 07:07:05 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CBC129498 for ; Fri, 9 Dec 2016 07:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 htYCx7kb6rWu for ; Fri, 9 Dec 2016 07:07:01 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B4C129445 for ; Fri, 9 Dec 2016 07:07:01 -0800 (PST) Received: from pps.filterd (m0085114.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uB9F6ohH027496 for ; Fri, 9 Dec 2016 10:07:00 -0500 Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) by mx0b-001d8301.pphosted.com with ESMTP id 277gtu3bg1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 09 Dec 2016 10:07:00 -0500 Received: by mail-lf0-f71.google.com with SMTP id b14so1053933lfg.6 for ; Fri, 09 Dec 2016 07:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=jiutN6RJj+eJKOPrvSvzuU32hEa95MM5EKNgo1/QTxM=; b=YjuG7m9rysHDR5tkl0dGsJDbOnWgAhxfsexKP8voDqpLVpGEMnqHiLT6ZfwiOajE25 jxBocv+H76Ld/tQYH8JSuLDJAsaq7NbrVJWS1Afx2874dhiNMM5z9/mRPiJ+5yu7E++8 eQRmjZFRjlnUlivUuPDPnlOb1uxNkOkDoFa1FrbG1ShQhRPsYg4zzB6hUp8TmMspRXvF lp/yOn/DSPoEOA+jni1FKzqcMLKK5oCUHVg9qaBD+6rvUtT2/6lAzQuT6ZwO/zaaqSj0 nNOUHJrzjdaUIJlGgb/RUvnWS5JQddMur0OaByfaSNGSu10BIftw+c0bM5vFZ+Pty4rj 9QYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=jiutN6RJj+eJKOPrvSvzuU32hEa95MM5EKNgo1/QTxM=; b=dxiCpjnv7yogpTGAqcG2onKPFZq/wDDJtixEEGevJAhCTuyM0EI9xGDdN6mzwZQ9YH rrlBzDy7E2jmC+glRz3FXghPz84t+mr3M+VPil5SSMpcDRITwj5FlwTnHJqBHq386UZ8 lO+sl21OxBNzmx3qZ6lNGetGvXnCR5YZH7u0LsC3fMEDyP4ulu4LCstQsmyHJZdlK+fU sTuXJq76cLaT/yRjNwMzC/j1kX4PchHpsvwbFH2E8hZJ6Gm3yTHlrEqCzk9enDIEqJpk jF8dw+0KZktgtaRmy7SHzvu//w6R6AcF2K3pJ0+N5vb9t9SQXa674eMH4X9/h4V2aZ0A ZrgA== X-Gm-Message-State: AKaTC03136n3iMf0Pt6z4/QxmxlwNRJIuXadRC+6DJ46iR6/PcExH2Cjmz1pEkxiA/YC1OUuh7UPig2a6YHo/83BI0vTpqWoCMfwXYK55P10Njd4lKWbOSPKAE9og9SBdIt3YEjkkmWByzxA X-Received: by 10.25.0.194 with SMTP id 185mr3743071lfa.53.1481296017958; Fri, 09 Dec 2016 07:06:57 -0800 (PST) X-Received: by 10.25.0.194 with SMTP id 185mr3743063lfa.53.1481296017674; Fri, 09 Dec 2016 07:06:57 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJSLa8ZRHC5AnRqRb2MGt0A15LhFQ== Date: Fri, 9 Dec 2016 10:06:56 -0500 Message-ID: <8fac9923135637ee57e59a865d197c96@mail.gmail.com> To: "Petersen, Jan 1. (Nokia - DE/Munich)" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-09_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:07:03 -0000 > So as a result, the UAC may receive the provisional response > to the INVITE, immediately followed by the final response > 2xx to the INVITE. However, the UAC may still send the PRACK > for the provisional response here, but the UAS has already > terminated the transaction when this "late" PRACK is received. > Consequently the UAS responds to this "late" PRACK with a > 481 Call/Transaction Does Not Exist, which in turn causes > the UAC to terminate the already established and ongoing > SIP session. Since the dialog has been terminated, returning 481 sounds acceptable (although some vendors completely ignore the RFC 3261 section 12.2.2 mandate). RFC 3262 section 3: "PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261." RFC 3261 section 12.2.2: "If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction." > Can you please clarify how SIP UAs (UAC and UAS and even > SIP Proxies) should handle and solve such a race condition? > Especially, is the PRACK transaction directly affecting the > corresponding SIP dialog, such that a late negative response > to the PRACK received on UAC side (after the 2xx final > response to the INVITE has been received already before) is > justifying to execute the release of the already successfully > established session by the UAC? Before deciding to send BYE or CANCEL because of 481 response to PRACK, you should be aware of forking and potential to send 481 on a known dialog. Similar to CANCEL processing, a 481 response can be sent for PRACK even though the UAS is still aware of the dialog. Thus if you receive 481, you might not want to send BYE for the specific dialog. If I recall correctly, RFC 5057 discusses 481 for CANCEL but neglects to indicate the same behavior for PRACK. Because of forking, a 481 response to PRACK does not necessarily justify cancelling the INVITE or releasing the call. For instance during a forking situation where the PRACK was associated with a different dialog, releasing an answered call because received 481 for PRACK on non-answered dialog does not seem to be justified. Similarly even if you didn't want the call to be answered on the dialog associated with 481, you might want to still allow the call to be answered on one of the other dialogs. > What exactly is meant by ". but[the UAS] MUST be prepared to > process PRACK requests for those outstanding responses"? In my opinion, it means that it is an expected situation and don't ignore the PRACK. For example during forking, a CANCEL sent by proxy/b2bua may have already caused delivery of 487/ACK for INVITE. The UAS likely won't wait indefinitely for the PRACK. Some vendors think RFC 3261 section 12.2.2 applies to the late PRACK (i.e. they return 481). Other vendors continue to time for PRACK (or wait indefinitely) and are willing to somehow comply with the SDP offer/answer rules (i.e. they return 2xx). Also my recollection is that RFC 3261 (section 16.6?) allows call stateful proxies to reject requests for unknown dialogs. Thus they might return 481 for PRACK. From nobody Fri Dec 9 07:19:52 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250331294B1 for ; Fri, 9 Dec 2016 07:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 eXoqVqSJfwmU for ; Fri, 9 Dec 2016 07:19:49 -0800 (PST) Received: from mx0b-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A28512949A for ; Fri, 9 Dec 2016 07:19:49 -0800 (PST) Received: from pps.filterd (m0103508.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uB9F6dLL019154 for ; Fri, 9 Dec 2016 10:19:48 -0500 Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by mx0b-001d8301.pphosted.com with ESMTP id 277gttkckc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 09 Dec 2016 10:19:48 -0500 Received: by mail-lf0-f70.google.com with SMTP id x143so1160383lfd.7 for ; Fri, 09 Dec 2016 07:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=jKZ1tkA+2e7oML3xlbht/eqbi8+iYhbpIIGq3IOOFWg=; b=T+ukn8eHftqE8XPxlNqzgy5VscoycoWUc6qT2U1/AvaXhzzKsZz1uQZTQ/ogTPvVwA Rcfeb/+FrQj+N+VuR9AZZ2NAZGNIhUwqQmOxNQQKeQnX2zcQ+4RimWUnXWofUTotUPF6 lf6mYbiuckEEsexBLtmpx/KMeKQeMSBKKu4FOD5FMea0nkY6URaEmYi/JqS2wO+ciBq/ 0YiNnQrSgplJCBqvZYjgUwDeNCud0DTcYgpfAK5IIDwQrcToEbMgVQP7brqtixkWivq4 Kd4/kTmOzM9vQ+z/kRuCQOMR8znZShrAnEcS6DA9iO/RxEbVU4vobjDPri3k/KSXvgsC 1LSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=jKZ1tkA+2e7oML3xlbht/eqbi8+iYhbpIIGq3IOOFWg=; b=JoPRJj/wHLUJO5hqWK5QX1kkP93BmLhicTQJuaX1FfMs/xGy9aBQ9g6eQm3pnDAeGC fmDsPvtlR/FxV13EThXpvIMcxw5rPCXHXCQqolcxDVuQBu/D5TbzeZ3PPvXQQ8qCoHle husOte5TsunUSqKfSclr5B6wLZG76tGDc0zh/aLJPUJ2hJTYfEbPFUbNmR+KFr+DW/1j PGZ69amy11rcUXa8eOdWAIAywv6eUd7LcxQLk2a74mG8kwbWS443P7hXGXrIWs4jdp6M xx36fXsDoSK3yJUzFgL/5qFtRXG3WByXGZCU0Y7yj1QECiuyf+Cw/pB769TRdb94MUHl yrJw== X-Gm-Message-State: AKaTC02vVYf1YJW+XKqzNCI/qEe5yGnpb/r1GjoxyjFs4nvypH2HqTWqitL7pQRldDql/MxaSbl5Jd4Fpf2R81K0IGY4NQtjUSipLQ+TFZyyR7kktIpuR/IRYFui3MbIaOvMyE/W9WHy6n13 X-Received: by 10.46.78.1 with SMTP id c1mr32869445ljb.39.1481296786478; Fri, 09 Dec 2016 07:19:46 -0800 (PST) X-Received: by 10.46.78.1 with SMTP id c1mr32869439ljb.39.1481296786247; Fri, 09 Dec 2016 07:19:46 -0800 (PST) From: Brett Tate References: <0e45e6a2-7988-5845-8c9d-448c206bf2d5@nostrum.com> In-Reply-To: <0e45e6a2-7988-5845-8c9d-448c206bf2d5@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKblA6zzww6AD9oQ927Jf/9kG+rigGir3tPn2AeYcA= Date: Fri, 9 Dec 2016 10:19:44 -0500 Message-ID: To: Robert Sparks , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-09_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:19:51 -0000 Hi, > It means that it must keep enough state to not return a 481. That sounds like a stretch. > (A UAS that 481s such a PRACK has not followed the requirement). Returning 481 follows earlier text within the section (although some vendors ignore the indication to process the PRACK according to RFC 3261 section 12.2.2). RFC 3262 section 3: "PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261." RFC 3261 section 12.2.2: "If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction." From nobody Fri Dec 9 07:50:53 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC52D129869 for ; Fri, 9 Dec 2016 07:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 agFwwos3IncK for ; Fri, 9 Dec 2016 07:50:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B63912986A for ; Fri, 9 Dec 2016 07:50:35 -0800 (PST) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uB9FoWSW099834 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 9 Dec 2016 09:50:33 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: Brett Tate , sipcore@ietf.org References: <0e45e6a2-7988-5845-8c9d-448c206bf2d5@nostrum.com> From: Robert Sparks Message-ID: Date: Fri, 9 Dec 2016 09:50:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:50:42 -0000 Hi Brett - You cut away too much context. On 12/9/16 9:19 AM, Brett Tate wrote: > Hi, > >> It means that it must keep enough state to not return a 481. > That sounds like a stretch. No - I'm not trying to stretch the text - that was exactly the intent of it. > > >> (A UAS that 481s such a PRACK has not followed the requirement). > Returning 481 follows earlier text within the section (although some > vendors ignore the indication to process the PRACK according to RFC 3261 > section 12.2.2). > > RFC 3262 section 3: "PRACK is like any other request within a dialog, and > the UAS core processes it according to the procedures of Sections 8.2 and > 12.2.2 of RFC 3261." > > RFC 3261 section 12.2.2: "If the UAS wishes to reject the request because > it does not wish to recreate the dialog, it MUST respond to the request > with a 481 (Call/Transaction Does Not Exist) status code and pass that to > the server transaction." And you are leaving out exactly the MUST from 3262 that was added to cover this edge condition (which is the one Jan was asking about). Yes, if we were writing the text today, we could make it far clearer - as its written, you have to infer what "be prepared to process" means. But the overwhelming majority of implementations so far have been able to do so. From nobody Sun Dec 11 19:15:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE5612957A for ; Sun, 11 Dec 2016 19:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 k0ujBZ-7iabG for ; Sun, 11 Dec 2016 19:15:15 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C562129579 for ; Sun, 11 Dec 2016 19:15:15 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-06v.sys.comcast.net with SMTP id GH58cf9kQTERUGH58cf3k5; Mon, 12 Dec 2016 03:15:14 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-18v.sys.comcast.net with SMTP id GH56c6wtgk82QGH57cwc9W; Mon, 12 Dec 2016 03:15:14 +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 uBC3E7sg006592; Sun, 11 Dec 2016 22:14:07 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBC3E6Lg006589; Sun, 11 Dec 2016 22:14:06 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Petersen\, Jan 1. \(Nokia - DE\/Munich\)" In-Reply-To: (jan.1.petersen@nokia.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 11 Dec 2016 22:14:06 -0500 Message-ID: <871sxddekh.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfH8hMraBVDJAQyTxNYuu5op2aRBG2/NWmWCge8iY+myNhiXpvXBztuVE+SlHkvyGKHICR46WFbCu0hC23hjdO2LiWuI/DDQaDoITKtF4Xnrg+ZK3KZ+a iYF5fE5Of/u2qdfsGPD3/BVEETgjtDarzHJd++BQPxiQPwWlbO9xnTeFaavchyIg5thiNiaAoJcmHMEj83wCMMqkGb6KfuSFVCo= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 03:15:16 -0000 "Petersen, Jan 1. (Nokia - DE/Munich)" writes: > So as a result, the UAC may receive the provisional response to the > INVITE, immediately followed by the final response 2xx to the > INVITE. However, the UAC may still send the PRACK for the provisional > response here, but the UAS has already terminated the transaction when > this "late" PRACK is received. Consequently the UAS responds to this > "late" PRACK with a 481 Call/Transaction Does Not Exist, which in turn > causes the UAC to terminate the already established and ongoing SIP > session. I don't see what the problem is. RFC 3262 section 3 says: A matching PRACK is defined as one within the same dialog as the response, and whose method, CSeq-num, and response-num in the RAck header field match, respectively, the method from the CSeq, the sequence number from the CSeq, and the sequence number from the RSeq of the reliable provisional response. If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response. In the case you describe, the UAC has sent a PRACK, and UAS sees the PRACK is "matching", and so the UAS MUST send a 200 response to the PRACK. The fact that the UAS has sent a final response to the INVITE transaction is irrelevant. I suppose there is some ambiguity if the UAS has terminated the *dialog* before the PRACK arrives, because it might be argued that the PRACK should receive a 481 response because it is within a terminated dialog. But whether such a PRACK gets a 481 or a 200 response makes no difference in practice. Dale From nobody Mon Dec 12 05:22:57 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED448129B16 for ; Mon, 12 Dec 2016 05:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 J6mqGWCCxzjl for ; Mon, 12 Dec 2016 05:22:54 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B868129B48 for ; Mon, 12 Dec 2016 05:22:05 -0800 (PST) Received: from pps.filterd (m0103510.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBCDJpnT004062 for ; Mon, 12 Dec 2016 08:22:04 -0500 Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by mx0a-001d8301.pphosted.com with ESMTP id 278faxb0h4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 12 Dec 2016 08:22:04 -0500 Received: by mail-wm0-f70.google.com with SMTP id w13so13350022wmw.0 for ; Mon, 12 Dec 2016 05:22:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=svw6W+FYv5BBmcsEzMzctDAiys3SFfQ9kGykLKyX2uk=; b=ezY6SzoQSPJj0RYpMZQrQrzMd0KgYDBQW3+xKN+h/caPhC1cWyb7iLe5X18OXdbA+e n4ORDX5V6pkrzf4PP/Nlm7oyl/mr9D02gTZ9Gn1oMoKPkYnqQev1bzAtq0h4Uy7nuAhU 3rGWmQxOLVUrwwSL5YetDoEzL2K4Lt35ug74GDtAG8uSI5R6mDrg+fk2UO2OE6C4UhnK rmRFd6PHZMxHyP0ZNez+t++JbWOhT6nGcexap3JrpKhG0KKiD7wwMQ87F43Ic4V0rCVd XofZEVdlT01hZYOOC7hum6JQzoob/LgMv7PSp9+rS4ITZhIbRuA/QzZeoaedCNOHZICJ VQRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=svw6W+FYv5BBmcsEzMzctDAiys3SFfQ9kGykLKyX2uk=; b=E5evqYaT0VnP/Cq9HvBbermn+8agqbAyryr45jarIBHIy+unGiz7hDj9rl1ziZeJnb ZZwEAwBZl5brHoW3iceaB4fphVVoVMxZGmLKU7pk9Te9gqdAjtwS9UztCsmTif1hsRtB wV//f6Dm4eS34Ko1O0oZhEVAx8f2EY8h5F2NIAaZOvusQhy33Kmrf5Mlq2ZeELIEntT4 y/18KfCQY64QhmftT1EffzNrWYsPcJ9Xk3YxPMXWUqPT0Etcp2ves6pmFBkAL6AitsbT 3E/uXjuK8ZbbB9wM7V/lNXcfLotCSjME/rrGs4FylUWSUA5FAoZCY6yGmqR02osJbB8e 1bKg== X-Gm-Message-State: AKaTC01vkJ4+GUaJNBaElanM0pOzb8JHLSA0QATFabblXSoToeTRqEDw28Eik+c6/7ERKzB+gg9APzfYpCqOK5UKjnrmu72Jmo2RAH4P8gK0NUYChWkpYYVA36MR9xwfp2KLVfnDr4lDYWWA X-Received: by 10.25.199.198 with SMTP id x189mr31814183lff.164.1481548922388; Mon, 12 Dec 2016 05:22:02 -0800 (PST) X-Received: by 10.25.199.198 with SMTP id x189mr31814177lff.164.1481548922123; Mon, 12 Dec 2016 05:22:02 -0800 (PST) From: Brett Tate References: (jan.1.petersen@nokia.com) <871sxddekh.fsf@hobgoblin.ariadne.com> In-Reply-To: <871sxddekh.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHLSdKuE3lL05/6u7wWJtmVy8A6ZqESSsLw Date: Mon, 12 Dec 2016 08:22:00 -0500 Message-ID: <83ece9dfcf759c1de1f52b9febcbcb22@mail.gmail.com> To: "Dale R. Worley" , "Petersen, Jan 1. (Nokia - DE/Munich)" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-12_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 13:22:56 -0000 Hi, > I don't see what the problem is. RFC 3262 section 3 says: > In the case you describe, the UAC has sent a PRACK, and > UAS sees the PRACK is "matching", and so the UAS MUST > send a 200 response to the PRACK. The fact that the UAS > has sent a final response to the INVITE transaction is > irrelevant. In my opinion, that requires the paragraph to be applied out of context since the dialog has been terminated and RFC 3262 previously indicated that RFC 3261 section 12.2.2 applies. It seems like the debate falls into the usual division of those that interpret RFC 3262 as though "PRACK is like any other request within a dialog" and those that don't. The "open issue" is mentioned within RFC 6337 section 2.3. > I suppose there is some ambiguity if the UAS has terminated > the *dialog* before the PRACK arrives, because it might be > argued that the PRACK should receive a 481 response because > it is within a terminated dialog. But whether such a PRACK > gets a 481 or a 200 response makes no difference in practice. Unfortunately, sending 481 to PRACK causes at least one vendor to send CANCEL or BYE (even if 481 was associated with an early dialog that does not match the answered call). From nobody Mon Dec 12 07:44:26 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22726129C8B for ; Mon, 12 Dec 2016 07:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 lHH1Uho99YcP for ; Mon, 12 Dec 2016 07:44:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD93129C61 for ; Mon, 12 Dec 2016 07:44:18 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCFhwb8021388 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Dec 2016 09:43:59 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: SIPCORE Date: Mon, 12 Dec 2016 09:43:57 -0600 Message-ID: <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> In-Reply-To: <20161212103155.CE434B801D8@rfc-editor.org> References: <20161212103155.CE434B801D8@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: Jonathan Rosenberg , shraddha.soni2@cognizant.com, aamelnikov@fastmail.fm, alissa@cooperw.in, drage@alcatel-lucent.com, Gonzalo.Camarillo@ericsson.com, wtm@research.att.com, dean.willis@softarmor.com Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 15:44:25 -0000 Do people have thoughts on this errata report? My initial inclination that, while the suggestion may be technically correct, the mentioned SHOULD merely parrots the similar SHOULD in RFC 3311 (UPDATE method), which is where the authoritative text lives. (This is why I've started pushing back on redundant 2119 keywords ;-) ) Has anyone observed breakage in the wild due to a peer not doing this? Thanks! Ben. On 12 Dec 2016, at 4:31, RFC Errata System wrote: > The following errata report has been submitted for RFC3312, > "Integration of Resource Management and Session Initiation Protocol > (SIP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3312&eid=4883 > > -------------------------------------- > Type: Technical > Reported by: Shraddha Soni > > Section: 11 > > Original Text > ------------- > Therefore, a user agent > including preconditions in the SDP MUST support the PRACK and > UPDATE > methods. Consequently, it MUST include the "100rel" [7] tag in the > Supported header field and SHOULD include an Allow header field > with > the "UPDATE" tag [5]. > > Corrected Text > -------------- > Therefore, a user agent > including preconditions in the SDP MUST support the PRACK and > UPDATE > methods. Consequently, it MUST include the "100rel" [7] tag in the > Supported header field and MUST include an Allow header field with > the "UPDATE" tag [5]. > > Notes > ----- > As stated in first line in the mentioned paragraph, the user agent > MUST support the UPDATE method, hence even in Allow header field also, > UPDATE method MUST be included. > > As per RFC 2119 > "SHOULD -This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. " > > Here in precondition case, whether any chance of ignoring the UPDATE > method happens ? > > As per RFC 3261 > Section 8.2.1 states - > "The Allow header field MUST list the set of methods supported by the > UAS > generating the message. ... If the method is one supported by the > server, processing continues." > > and also in RFC 3261 Sections 20.5 states- > "All methods, including ACK and CANCEL, understood by the UA MUST be > included in the list of methods in the Allow header field, when > present." > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC3312 (draft-ietf-sip-manyfolks-resource-07) > -------------------------------------- > Title : Integration of Resource Management and Session > Initiation Protocol (SIP) > Publication Date : October 2002 > Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J. > Rosenberg > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From nobody Mon Dec 12 08:13:19 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746E8129CD7 for ; Mon, 12 Dec 2016 08:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 HmiZkXMmLhjt for ; Mon, 12 Dec 2016 08:13:15 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFC6129CC7 for ; Mon, 12 Dec 2016 08:12:24 -0800 (PST) X-AuditID: c1b4fb25-00bff700000042ea-b1-584ecc645035 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 38.43.17130.46CCE485; Mon, 12 Dec 2016 17:12:22 +0100 (CET) Received: from [100.94.10.51] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.319.2; Mon, 12 Dec 2016 17:12:37 +0100 To: Ben Campbell , SIPCORE References: <20161212103155.CE434B801D8@rfc-editor.org> <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> From: Gonzalo Camarillo Message-ID: Date: Mon, 12 Dec 2016 18:12:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2J7oG7aGb8Ig83HlCz2vz/EZDH9zF9G i/mdp9ktdl3RsliwdCOrxfKDV5gt/vxdxmrx9ccmNou5cx4zO3B6tD7by+ox5fdGVo8Xcw8w enx58pLJY+epA2weS5b8ZPKYtfMJi8f/J/NZPC4u+cYYwBnFZZOSmpNZllqkb5fAlbHh6BLm gj8yFbP/z2NuYLwi1sXIySEhYCKx69VDxi5GLg4hgXWMEi92fWEESQgJrGKUaHiXB2ILC5hL LD7+mxXEFhGwk2idcZEZoiZH4taXI2wgzcwC5xgl3tx9wAKSYBOwkNhy6z6YzStgL/H36Qwm EJtFQFWiae00MFtUIEZiyfF5UDWCEidnPgGzOYHqHzx7D7aMWcBA4siiOVC2vMT2t3OgFmtL LH/WwjKBUWAWkvZZSFpmIWlZwMi8ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwRg5u+a26 g/HyG8dDjAIcjEo8vAW7/SKEWBPLiitzDzFKcDArifA6nAIK8aYkVlalFuXHF5XmpBYfYpTm YFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwMhT79AtK+v3WfnDgpf7N3/dzLnT0WeVse88 Vdtt4rZMiZJXuD3aOspys2ybn/KbWVoeDLEqvjL75T6DJZvEtJNSuRpWTI5viNzzKui4wh8L lopH/hztnwTfyXm4zj1hYxZhyKk6T5P7ba/epReqMTeNjgq9lLMy2HrnweXfIobfp3atucjZ o8RSnJFoqMVcVJwIACWd9FqNAgAA Archived-At: Cc: Jonathan Rosenberg , shraddha.soni2@cognizant.com, aamelnikov@fastmail.fm, alissa@cooperw.in, drage@alcatel-lucent.com, wtm@research.att.com, dean.willis@softarmor.com Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:13:17 -0000 Hi Ben, yes, this is a classic example of a redundant 2119 keyword. Cheers, Gonzalo On 12/12/2016 5:43 PM, Ben Campbell wrote: > Do people have thoughts on this errata report? > > My initial inclination that, while the suggestion may be technically > correct, the mentioned SHOULD merely parrots the similar SHOULD in RFC > 3311 (UPDATE method), which is where the authoritative text lives. > (This is why I've started pushing back on redundant 2119 keywords ;-) ) > > Has anyone observed breakage in the wild due to a peer not doing this? > > Thanks! > > Ben. > > On 12 Dec 2016, at 4:31, RFC Errata System wrote: > >> The following errata report has been submitted for RFC3312, >> "Integration of Resource Management and Session Initiation Protocol >> (SIP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3312&eid=4883 >> >> -------------------------------------- >> Type: Technical >> Reported by: Shraddha Soni >> >> Section: 11 >> >> Original Text >> ------------- >> Therefore, a user agent >> including preconditions in the SDP MUST support the PRACK and UPDATE >> methods. Consequently, it MUST include the "100rel" [7] tag in the >> Supported header field and SHOULD include an Allow header field with >> the "UPDATE" tag [5]. >> >> Corrected Text >> -------------- >> Therefore, a user agent >> including preconditions in the SDP MUST support the PRACK and UPDATE >> methods. Consequently, it MUST include the "100rel" [7] tag in the >> Supported header field and MUST include an Allow header field with >> the "UPDATE" tag [5]. >> >> Notes >> ----- >> As stated in first line in the mentioned paragraph, the user agent >> MUST support the UPDATE method, hence even in Allow header field also, >> UPDATE method MUST be included. >> >> As per RFC 2119 >> "SHOULD -This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. " >> >> Here in precondition case, whether any chance of ignoring the UPDATE >> method happens ? >> >> As per RFC 3261 >> Section 8.2.1 states - >> "The Allow header field MUST list the set of methods supported by the UAS >> generating the message. ... If the method is one supported by the >> server, processing continues." >> >> and also in RFC 3261 Sections 20.5 states- >> "All methods, including ACK and CANCEL, understood by the UA MUST be >> included in the list of methods in the Allow header field, when >> present." >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3312 (draft-ietf-sip-manyfolks-resource-07) >> -------------------------------------- >> Title : Integration of Resource Management and Session >> Initiation Protocol (SIP) >> Publication Date : October 2002 >> Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG From nobody Mon Dec 12 08:25:52 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B96129454 for ; Mon, 12 Dec 2016 08:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 TLMTNUgxm26D for ; Mon, 12 Dec 2016 08:25:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED16129D11 for ; Mon, 12 Dec 2016 08:24:18 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCGO4Xd025131 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Dec 2016 10:24:05 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Gonzalo Camarillo" Date: Mon, 12 Dec 2016 10:24:04 -0600 Message-ID: In-Reply-To: References: <20161212103155.CE434B801D8@rfc-editor.org> <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: Jonathan Rosenberg , shraddha.soni2@cognizant.com, aamelnikov@fastmail.fm, alissa@cooperw.in, SIPCORE , drage@alcatel-lucent.com, dean.willis@softarmor.com Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:25:51 -0000 I'm inclined to mark this as "hold for update", since a real fix would involve (at least) two RFCs, and I assume this is not actively causing problems for implementors. If anyone is aware of related implementation/deployment problems, please speak up. Thanks! Ben. On 12 Dec 2016, at 10:12, Gonzalo Camarillo wrote: > Hi Ben, > > yes, this is a classic example of a redundant 2119 keyword. > > Cheers, > > Gonzalo > > On 12/12/2016 5:43 PM, Ben Campbell wrote: >> Do people have thoughts on this errata report? >> >> My initial inclination that, while the suggestion may be technically >> correct, the mentioned SHOULD merely parrots the similar SHOULD in >> RFC >> 3311 (UPDATE method), which is where the authoritative text lives. >> (This is why I've started pushing back on redundant 2119 keywords ;-) >> ) >> >> Has anyone observed breakage in the wild due to a peer not doing >> this? >> >> Thanks! >> >> Ben. >> >> On 12 Dec 2016, at 4:31, RFC Errata System wrote: >> >>> The following errata report has been submitted for RFC3312, >>> "Integration of Resource Management and Session Initiation Protocol >>> (SIP)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3312&eid=4883 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Shraddha Soni >>> >>> Section: 11 >>> >>> Original Text >>> ------------- >>> Therefore, a user agent >>> including preconditions in the SDP MUST support the PRACK and >>> UPDATE >>> methods. Consequently, it MUST include the "100rel" [7] tag in >>> the >>> Supported header field and SHOULD include an Allow header field >>> with >>> the "UPDATE" tag [5]. >>> >>> Corrected Text >>> -------------- >>> Therefore, a user agent >>> including preconditions in the SDP MUST support the PRACK and >>> UPDATE >>> methods. Consequently, it MUST include the "100rel" [7] tag in >>> the >>> Supported header field and MUST include an Allow header field >>> with >>> the "UPDATE" tag [5]. >>> >>> Notes >>> ----- >>> As stated in first line in the mentioned paragraph, the user agent >>> MUST support the UPDATE method, hence even in Allow header field >>> also, >>> UPDATE method MUST be included. >>> >>> As per RFC 2119 >>> "SHOULD -This word, or the adjective "RECOMMENDED", mean that there >>> may exist valid reasons in particular circumstances to ignore a >>> particular item, but the full implications must be understood and >>> carefully weighed before choosing a different course. " >>> >>> Here in precondition case, whether any chance of ignoring the UPDATE >>> method happens ? >>> >>> As per RFC 3261 >>> Section 8.2.1 states - >>> "The Allow header field MUST list the set of methods supported by >>> the UAS >>> generating the message. ... If the method is one supported by the >>> server, processing continues." >>> >>> and also in RFC 3261 Sections 20.5 states- >>> "All methods, including ACK and CANCEL, understood by the UA MUST be >>> included in the list of methods in the Allow header field, when >>> present." >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC3312 (draft-ietf-sip-manyfolks-resource-07) >>> -------------------------------------- >>> Title : Integration of Resource Management and Session >>> Initiation Protocol (SIP) >>> Publication Date : October 2002 >>> Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J. >>> Rosenberg >>> Category : PROPOSED STANDARD >>> Source : Session Initiation Protocol >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 12 08:40:50 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCF3129D6A for ; Mon, 12 Dec 2016 08:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 ZQsljsCJSkbi for ; Mon, 12 Dec 2016 08:40:48 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E822C129D8C for ; Mon, 12 Dec 2016 08:37:00 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-06v.sys.comcast.net with SMTP id GTapcft7CTERUGTb2cgK8E; Mon, 12 Dec 2016 16:37:00 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-20v.sys.comcast.net with SMTP id GTb0cIP4VX36LGTb1c53yu; Mon, 12 Dec 2016 16:36:59 +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 uBCGZv2O027188; Mon, 12 Dec 2016 11:35:58 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBCGZv5e027185; Mon, 12 Dec 2016 11:35:57 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: <83ece9dfcf759c1de1f52b9febcbcb22@mail.gmail.com> (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 12 Dec 2016 11:35:57 -0500 Message-ID: <874m2914wi.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBQBzNPsZMbv4ALoXkstlJ/X72SedwjL+sqIjWyqAgx8bJGfHlRKWDIO5cZU1LBvztiIbBg+Z5vz7Qgsud6l7rBfLBc0Xg9hDm+kHAKkZfPwEEgEbPRb rhgSm/+zhWFUwJiC9PlCTF45t3L+2qJmHFdQRNq5eXKs7EMNlNofQlwk6rfIPLx4eXDqX0R5vfFkfsogBq4KShFxHjyRRk1S8NBogTYhcm5+ff1Wh3pPCtQT etuFt0r6h/wEIVWs3TUakA== Archived-At: Cc: sipcore@ietf.org, jan.1.petersen@nokia.com Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:40:49 -0000 OK, there's some context I'm losing here. Quoting from Jan Petersen's original message: > The issue occurs if the UAS is responding with an (subsequent) > provisional response to the INVITE request, using 100rel, while the > shortly afterwards the UAS is actually sending the final response to > the INVITE, before the PRACK to the provisional response has been > received by the UAS: > ... > So as a result, the UAC may receive the provisional response to the > INVITE, immediately followed by the final response 2xx to the > INVITE. However, the UAC may still send the PRACK for the provisional > response here, but the UAS has already terminated the transaction when > this "late" PRACK is received. ... As I read it, Jan is only discussing the case when the final response for the INVITE is 2xx, i.e., the dialog becomes established. (I believe that the issue is "What does a UAS do when it receives a PRACK for a provisional response, when the provisional response's transaction has completed?" It seems to me that the plain answer in RFC 3262 is that the UAS must send a 2xx response.) However, Brett writes: > In my opinion, that requires the paragraph to be applied out of context > since the dialog has been terminated and RFC 3262 previously indicated > that RFC 3261 section 12.2.2 applies. What I don't understand is the part about "the dialog has been terminated". It seems to me to be clear in Jan's case that the dialog has *not* been terminated. And there is a second part to this conversation: Brett Tate writes: >> I suppose there is some ambiguity if the UAS has terminated >> the *dialog* before the PRACK arrives, because it might be >> argued that the PRACK should receive a 481 response because >> it is within a terminated dialog. But whether such a PRACK >> gets a 481 or a 200 response makes no difference in practice. > > Unfortunately, sending 481 to PRACK causes at least one vendor to send > CANCEL or BYE (even if 481 was associated with an early dialog that does > not match the answered call). It seems to me that's the vendor's problem. I'd think when the UAC receives a 4xx response to a PRACK sent within an early dialog (which by hypothesis is in the process of being terminated with a 4xx response to the INVITE), then the UAC could terminate the early dialog but it must leave the overall dialog unaffected. Compare with when when the UAS sends a provisional response with an answer: Then the UAC can send an UPDATE with a new offer to the UAS within the early dialog. If the UAS doesn't like the offer, it can reject the UPDATE with any of a number of 4xx responses. But that response doesn't terminate the early dialog with that UAS, nor the overall dialog. (RFC 3311, section 5.3) Dale From nobody Mon Dec 12 09:31:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA8A129D76 for ; Mon, 12 Dec 2016 09:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 lhTchE_ba7Pl for ; Mon, 12 Dec 2016 09:31:05 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7937129B90 for ; Mon, 12 Dec 2016 09:31:04 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-11v.sys.comcast.net with SMTP id GUOHcau90BhTgGURLcPHpx; Mon, 12 Dec 2016 17:31:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1481563863; bh=mu97ONqUNb172BdrkfzXH9ao+EmnlWOtJJhogHNhVVE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=KrrtR4iwyfhk766T5M0tUKoclV06tVa0/rGx/d9V4FifEbxFg8ofL47oFFUrEHMj0 Jb5eEsYE7X2Q78CQ7GhGcLAXGzsBOhgVJTQDyNlMBsAwd/qDRtRXwHu/RzUfb2yCye md/gqx0SZRrdDR1vpa4ND4skXHed2r0HFMdTQ3RaSOB5csleB0wc3A/z2uK7wLeWIl ob2dnQhhjd6v0ptBC8gimxnT16zTVGlQ3gZ/xziwQKcszw8Snf0iwHNrorTpFHhLI5 /rQEZZgZh+qj/Mk87LkT8izHJCBxi+LWyIqHxGL3Xhrj7KgNrypaoR3HG3iXn+QVjl xp7KFWn8QhA2Q== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-03v.sys.comcast.net with SMTP id GURKco4fgvU3WGURLc9NAc; Mon, 12 Dec 2016 17:31:03 +0000 To: sipcore@ietf.org References: <20161212103155.CE434B801D8@rfc-editor.org> <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> From: Paul Kyzivat Message-ID: Date: Mon, 12 Dec 2016 12:31:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKIsUn/ZjJvRUP06CJKCDy22hIqxHAaxuy1eLIhoCDF6zx4++YEraNLWE0obfSZO9Kfk3u6CXGvV624i7fQ25U4Op+ITs52MTYiGfEFcvO9Kpw7ls+Fe wqwhSoGJ5weFFO97m6LtFnRZedufoKWMSXBxkc7vDRqSKaLisYcF157dIQ8UXA+EY1WOv3t1jCtp8g== Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 17:31:08 -0000 I have always been troubled by the detailed semantics of Allow and other similar headers. IIUC this originated in HTTP. In that context its meaning is transactional - the requester is indicating what headers it will allow in the response to this one request. In that context it is fine. But in SIP the meaning has been broadened. It is assumed to apply to usage beyond the current transaction - to future transactions, even requests going in the other direction. But it has never been made clear how much beyond the current transaction it applies. It is impossible to indicate precisely which headers will be allowed in the future because many of them are allowed only in certain contexts. Also, a UA may support a *lot* of header fields, and may not want to list them all simply to reduce the size of the message. In the current case, indicating support of the option (100rel) implies that a set of header fields will be used. Listing all of those in Allow is at least redundant. I guess this rambling doesn't really affect the conclusion on this erratum. I'm not sure there is a practical solution to this problem. Perhaps we ought to clarify that Allow in a request MUST indicate header fields allowed in responses to that request, and SHOULD (MAY?) also indicate header fields that might be allowed in requests directed toward it. Thanks, Paul On 12/12/16 10:43 AM, Ben Campbell wrote: > Do people have thoughts on this errata report? > > My initial inclination that, while the suggestion may be technically > correct, the mentioned SHOULD merely parrots the similar SHOULD in RFC > 3311 (UPDATE method), which is where the authoritative text lives. > (This is why I've started pushing back on redundant 2119 keywords ;-) ) > > Has anyone observed breakage in the wild due to a peer not doing this? > > Thanks! > > Ben. > > On 12 Dec 2016, at 4:31, RFC Errata System wrote: > >> The following errata report has been submitted for RFC3312, >> "Integration of Resource Management and Session Initiation Protocol >> (SIP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3312&eid=4883 >> >> -------------------------------------- >> Type: Technical >> Reported by: Shraddha Soni >> >> Section: 11 >> >> Original Text >> ------------- >> Therefore, a user agent >> including preconditions in the SDP MUST support the PRACK and UPDATE >> methods. Consequently, it MUST include the "100rel" [7] tag in the >> Supported header field and SHOULD include an Allow header field with >> the "UPDATE" tag [5]. >> >> Corrected Text >> -------------- >> Therefore, a user agent >> including preconditions in the SDP MUST support the PRACK and UPDATE >> methods. Consequently, it MUST include the "100rel" [7] tag in the >> Supported header field and MUST include an Allow header field with >> the "UPDATE" tag [5]. >> >> Notes >> ----- >> As stated in first line in the mentioned paragraph, the user agent >> MUST support the UPDATE method, hence even in Allow header field also, >> UPDATE method MUST be included. >> >> As per RFC 2119 >> "SHOULD -This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. " >> >> Here in precondition case, whether any chance of ignoring the UPDATE >> method happens ? >> >> As per RFC 3261 >> Section 8.2.1 states - >> "The Allow header field MUST list the set of methods supported by the UAS >> generating the message. ... If the method is one supported by the >> server, processing continues." >> >> and also in RFC 3261 Sections 20.5 states- >> "All methods, including ACK and CANCEL, understood by the UA MUST be >> included in the list of methods in the Allow header field, when >> present." >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3312 (draft-ietf-sip-manyfolks-resource-07) >> -------------------------------------- >> Title : Integration of Resource Management and Session >> Initiation Protocol (SIP) >> Publication Date : October 2002 >> Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Dec 12 10:18:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F79129484 for ; Mon, 12 Dec 2016 10:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 CCWMJUhc7-68 for ; Mon, 12 Dec 2016 10:18:40 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3691128BA2 for ; Mon, 12 Dec 2016 10:18:40 -0800 (PST) Received: from pps.filterd (m0085114.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBCIFNl6028638 for ; Mon, 12 Dec 2016 13:18:40 -0500 Received: from mail-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by mx0b-001d8301.pphosted.com with ESMTP id 278dx2cpft-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 12 Dec 2016 13:18:40 -0500 Received: by mail-wj0-f199.google.com with SMTP id he10so27828580wjc.6 for ; Mon, 12 Dec 2016 10:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-transfer-encoding; bh=7fRlIGV8QRybSx5cMHvlTCRTdtbUFkPTyQ040xeZ9sA=; b=L1wOWFgqINmsa3y3v0la5aJfFEElpfY5ohqXzLj158LjDQ71pJ9hmZUH0yV00XRWQG M6a1DjhWDu9GiT9t23Cy9nB0xEuYyjvdCKWf9CJrmaK1WaXPEbviHTBVIdt1eWyd3hO8 w6ftdx44csT6xum7h+dnJ3IjOthww85+v0M4bD97X/ogSsIvYNAD/JXvS273Y976a1IW O3fn0QHxBHnUcznTZxTqIVzwiL1AyHzLrhBMnxJcb8Q/grSx1ZFd79tWPYpFtVmQQ0t1 k4k0sFjqXCDHqPus9ucnn4lVtisZ6ydqHK2Om98aM2L7Tm9x13JprEKz8OEdxHYEyQEu 4W3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-transfer-encoding; bh=7fRlIGV8QRybSx5cMHvlTCRTdtbUFkPTyQ040xeZ9sA=; b=f0+JQnjqZYQXCjPwPG2igpXr1jngLq1qERcPO9H9B6SVwMmDekjJmddffYPmuErKLC LBCTguAsYBjyCnGdov4GZ4nDUeTBgCeC/5G0/HWQ4x7Kq/43YDusmW6aCNQhgnAsDWqN xr8z9oLPY22uWBt+CshBXEUdJBsbImxp4oIBOLsTx5XydbNJPjqesIT3gapWIVBGZEIW CSDUlPeaDoJ9pht4j6tkQp/D/JxzpelUrFBCWfk4L1oYjJoDOUCuf8Yw5/Wy+LYt3iMf mLPC5Jo5rUj8iWW+veNTDAvii6QCK6ZLSBDAilJELIb5WbRyomvW/xufUP9rmMzu+nri Jedw== X-Gm-Message-State: AKaTC02RuZMpnOfQiKUGvhv3LNG1eyy/92gZIM4XLAvKLPGteMfP3TSuYXpM6R8f1UPxEAGURggPlq4dbqIZvjXLTFuQbhwnN3fxCT4YO2SbTOK445BVSmrv1famO3XY+VGZ2yaU5bVj5jJj X-Received: by 10.25.152.142 with SMTP id a136mr25344274lfe.113.1481566718175; Mon, 12 Dec 2016 10:18:38 -0800 (PST) X-Received: by 10.25.152.142 with SMTP id a136mr25344254lfe.113.1481566717663; Mon, 12 Dec 2016 10:18:37 -0800 (PST) From: Brett Tate References: <0e45e6a2-7988-5845-8c9d-448c206bf2d5@nostrum.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKblA6zzww6AD9oQ927Jf/9kG+rigGir3tPAp32+H8CfAx705876eUA Date: Mon, 12 Dec 2016 13:18:36 -0500 Message-ID: <2c4196697fa614c537757ce9e44be12b@mail.gmail.com> To: Robert Sparks , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-12_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:18:42 -0000 Hi Robert, > You cut away too much context. Sorry; I re-added the question portion. I also may have incorrectly misinterpreting if you think the behavior is the same or different if the dialog has been terminated. >>>> What exactly is meant by "... but[the UAS] MUST be prepared >>>> to process PRACK requests for those outstanding responses"? >>>> Does "process" refers to respond with a 2xx, or to provide >>>> any final response, i.e. even a negative response =E2=80=93 >>>> compared to just dropping it without any response? >>> >>> It means that it must keep enough state to not >>> return a 481. >> >> That sounds like a stretch. > > No - I'm not trying to stretch the text - that > was exactly the intent of it. I agree if the dialog has not been terminated; otherwise ... That interpretation ignores the earlier "PRACK is like any other request within a dialog" text to process PRACK according to RFC 3261 section 12.2.2= . I always hesitate to discuss "intent" in regards to RFC 3262 since members of the working group had vastly different interpretations about the validit= y of a UAS to return responses other than 200 or 481. See "open issue" discussed within RFC 6337 section 2.3. If your interpretation also applies on a terminated dialog, this seems like the usual debate between those that think "PRACK is like any other request within a dialog" and those that don't. Does sipcore ever plan to close the "open issue" through errata or rfc3262bis? >>> (A UAS that 481s such a PRACK has not followed the >>> requirement). >> >> Returning 481 follows earlier text within the section (although >> some vendors ignore the indication to process the PRACK according >> to RFC 3261 section 12.2.2). >> >> RFC 3262 section 3: "PRACK is like any other request within a >> dialog, and the UAS core processes it according to the procedures >> of Sections 8.2 and 12.2.2 of RFC 3261." >> >> RFC 3261 section 12.2.2: "If the UAS wishes to reject the request >> because it does not wish to recreate the dialog, it MUST respond >> to the request with a 481 (Call/Transaction Does Not Exist) >> status code and pass that to the server transaction." > > And you are leaving out exactly the MUST from 3262 that was > added to cover this edge condition (which is the one Jan was > asking about). I agree if Jan was solely asking about situation where the dialog has not been terminated; otherwise ... As far as I know, the "MUST be prepared to process PRACK" text does mean th= e potential to process PRACK like any other request within dialog (which migh= t include returning 481 if the dialog was terminated). From nobody Mon Dec 12 10:48:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49DB1294A6 for ; Mon, 12 Dec 2016 10:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 G85qwkCGEk9J for ; Mon, 12 Dec 2016 10:48:15 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EEF12949E for ; Mon, 12 Dec 2016 10:48:15 -0800 (PST) Received: from pps.filterd (m0103510.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBCIj2SE010294 for ; Mon, 12 Dec 2016 13:48:15 -0500 Received: from mail-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by mx0a-001d8301.pphosted.com with ESMTP id 278faxcnv1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 12 Dec 2016 13:48:15 -0500 Received: by mail-wj0-f199.google.com with SMTP id j10so28124681wjb.3 for ; Mon, 12 Dec 2016 10:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=zH3RdMrShiWfWZ6xYCdNBXr+9p3/cgF47kYG9xhPY6E=; b=b3612cs9w/8KYDOl7jDoR2WcAGU+XCr4AisKmJ8A74H0Wk7O4OVZic44+Q9nEskzSW XooqG5Y/vN4sCJnFH4vi6cEyHvkY2v1a/9vjPBAyWgWfl0MCEyqpaMIIIUuHz95o8+6i 4p+HVv1dqBdGM1j97o8aHcgPy4+7znm56BTl9bX/K0EYsOeAKdmQ8eNqLnBffGtSJEhA 4Zz1DieoufO/4Fn+e+TdHvQIoQVQDbYks/llHUXVkwGWUkq1KGKc25UXrOg5pbVlmezP Ky3Llmr6yjF6Wz4jVPpCuZwuXh4iAhKUsIjcds13Cz2IYeuPfO9KvIFtCWbnvrWIMuco 2G1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=zH3RdMrShiWfWZ6xYCdNBXr+9p3/cgF47kYG9xhPY6E=; b=A8XgRlqb0EERZgHL1+EWinCgk7aQN046A2mXkoeKQH/vLyoFm5AoHLz6EuPE/m+vqZ rixznMd/+wdFErcJmTaZYc/xbRQB0TAcAEfQIVgLCiRIeIhALmGUb+FiJqGkAp/we5RI I8dAsh3fL85n5DXcMh8Icb3GEGcckqTazQ2tKqSHruRN9lR2XBsLkg2prOp6Qi9GyoAi znLj4calI7YS9TBbEe7h8TR4pwTKUKeEySSJYKQ3CZaV3HFL1FJwGlYzzC0rn7NWrjf8 OEHtf+xvI3GWuBHXPfENcDrMAEE8leuD2e3MpDDmyKGs3NFxetBXjCIX5GY5TYDaXo2Q 9jJA== X-Gm-Message-State: AKaTC02pssaslZ3vYLd+DDm+6yNmkj5JzscyeDHcRWWYei/Mw69m8892Th0QME+96uBgkaN0Hw3so6X4zjeNP+6jkMfLjQxd70vezFkBjbfCE0ORK2n07TxTxXgodU65DH5WfILULfwWlqNn X-Received: by 10.25.152.142 with SMTP id a136mr25379309lfe.113.1481568493207; Mon, 12 Dec 2016 10:48:13 -0800 (PST) X-Received: by 10.25.152.142 with SMTP id a136mr25379300lfe.113.1481568492963; Mon, 12 Dec 2016 10:48:12 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJUqD4002kns0rWSPm7kq9ipZF3FQ== Date: Mon, 12 Dec 2016 13:48:11 -0500 Message-ID: <5bf65fca34aca07a9cfb7d393e3a6ded@mail.gmail.com> To: "Dale R. Worley" , jan.1.petersen@nokia.com, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-12_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:48:16 -0000 Hi, Sorry about that. My answer involved PRACK being received on the non-answered terminated dialog (e.g. after 487/ACK) during a forked INVITE situation. Jan's question may have been only associated non-forking situation involving late PRACK received on the answered/confirmed dialog. -brett From nobody Mon Dec 12 10:50:25 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A431296C7 for ; Mon, 12 Dec 2016 10:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 SKw58MpPBbmV for ; Mon, 12 Dec 2016 10:50:12 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4B41296A2 for ; Mon, 12 Dec 2016 10:50:11 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id E3DC73616C95D; Mon, 12 Dec 2016 18:50:05 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBCIo69A015461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Dec 2016 18:50:06 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uBCIo00X024476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Dec 2016 18:50:00 GMT Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.138]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Mon, 12 Dec 2016 19:50:00 +0100 From: "Drage, Keith (Nokia - GB)" To: Ben Campbell , Gonzalo Camarillo Thread-Topic: [ALU] Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) Thread-Index: AQHSVJQytSoIcVOoo0KUqDvWAzAZJ6EEnyug Date: Mon, 12 Dec 2016 18:49:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFC80D9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20161212103155.CE434B801D8@rfc-editor.org> <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jonathan Rosenberg , "shraddha.soni2@cognizant.com" , "aamelnikov@fastmail.fm" , SIPCORE , "alissa@cooperw.in" , "dean.willis@softarmor.com" Subject: Re: [sipcore] [ALU] Re: [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:50:15 -0000 Agree. Keith -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: 12 December 2016 16:24 To: Gonzalo Camarillo Cc: SIPCORE ; Jonathan Rosenberg ; shr= addha.soni2@cognizant.com; aamelnikov@fastmail.fm; alissa@cooperw.in; Drage= , Keith (Nokia - GB) ; dean.willis@softarmor.com Subject: [ALU] Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) I'm inclined to mark this as "hold for update", since a real fix would invo= lve (at least) two RFCs, and I assume this is not actively causing problems= for implementors. If anyone is aware of related implementation/deployment problems, please sp= eak up. Thanks! Ben. On 12 Dec 2016, at 10:12, Gonzalo Camarillo wrote: > Hi Ben, > > yes, this is a classic example of a redundant 2119 keyword. > > Cheers, > > Gonzalo > > On 12/12/2016 5:43 PM, Ben Campbell wrote: >> Do people have thoughts on this errata report? >> >> My initial inclination that, while the suggestion may be technically=20 >> correct, the mentioned SHOULD merely parrots the similar SHOULD in=20 >> RFC >> 3311 (UPDATE method), which is where the authoritative text lives. >> (This is why I've started pushing back on redundant 2119 keywords ;-) >> ) >> >> Has anyone observed breakage in the wild due to a peer not doing=20 >> this? >> >> Thanks! >> >> Ben. >> >> On 12 Dec 2016, at 4:31, RFC Errata System wrote: >> >>> The following errata report has been submitted for RFC3312,=20 >>> "Integration of Resource Management and Session Initiation Protocol=20 >>> (SIP)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D3312&eid=3D4883 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Shraddha Soni >>> >>> Section: 11 >>> >>> Original Text >>> ------------- >>> Therefore, a user agent >>> including preconditions in the SDP MUST support the PRACK and=20 >>> UPDATE >>> methods. Consequently, it MUST include the "100rel" [7] tag in=20 >>> the >>> Supported header field and SHOULD include an Allow header field=20 >>> with >>> the "UPDATE" tag [5]. >>> >>> Corrected Text >>> -------------- >>> Therefore, a user agent >>> including preconditions in the SDP MUST support the PRACK and=20 >>> UPDATE >>> methods. Consequently, it MUST include the "100rel" [7] tag in=20 >>> the >>> Supported header field and MUST include an Allow header field=20 >>> with >>> the "UPDATE" tag [5]. >>> >>> Notes >>> ----- >>> As stated in first line in the mentioned paragraph, the user agent=20 >>> MUST support the UPDATE method, hence even in Allow header field=20 >>> also, UPDATE method MUST be included. >>> >>> As per RFC 2119 >>> "SHOULD -This word, or the adjective "RECOMMENDED", mean that there >>> may exist valid reasons in particular circumstances to ignore a >>> particular item, but the full implications must be understood and >>> carefully weighed before choosing a different course. " >>> >>> Here in precondition case, whether any chance of ignoring the UPDATE=20 >>> method happens ? >>> >>> As per RFC 3261 >>> Section 8.2.1 states - >>> "The Allow header field MUST list the set of methods supported by=20 >>> the UAS >>> generating the message. ... If the method is one supported by the=20 >>> server, processing continues." >>> >>> and also in RFC 3261 Sections 20.5 states- "All methods, including=20 >>> ACK and CANCEL, understood by the UA MUST be >>> included in the list of methods in the Allow header field, when >>> present." >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please=20 >>> use "Reply All" to discuss whether it should be verified or=20 >>> rejected. When a decision is reached, the verifying party can log in=20 >>> to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC3312 (draft-ietf-sip-manyfolks-resource-07) >>> -------------------------------------- >>> Title : Integration of Resource Management and Session >>> Initiation Protocol (SIP) >>> Publication Date : October 2002 >>> Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J.=20 >>> Rosenberg >>> Category : PROPOSED STANDARD >>> Source : Session Initiation Protocol >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 12 11:31:33 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C418B12940F for ; Mon, 12 Dec 2016 11:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XYJ0olwhYd9c for ; Mon, 12 Dec 2016 11:31:29 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD34129417 for ; Mon, 12 Dec 2016 11:31:29 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 8000BAA760303; Mon, 12 Dec 2016 19:31:23 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBCJVLlo004247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Dec 2016 19:31:26 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uBCJVEt2029228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Dec 2016 19:31:20 GMT Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.138]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Mon, 12 Dec 2016 20:31:17 +0100 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] [Technical Errata Reported] RFC3312 (4883) Thread-Index: AQHSVI6ib2u8q0oX7UyT0vZdo3sfTKEEgSMAgAAi/CA= Date: Mon, 12 Dec 2016 19:31:16 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFC814D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20161212103155.CE434B801D8@rfc-editor.org> <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 19:31:31 -0000 Yes, but seriously, is this something we need to worry about now. Getting t= his perfect is not something we should be addressing in an errata, and is i= f we opened an update, is the world really going to implement the update. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 12 December 2016 17:31 To: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) I have always been troubled by the detailed semantics of Allow and other si= milar headers. IIUC this originated in HTTP. In that context its meaning is transactional = - the requester is indicating what headers it will allow in the response to= this one request. In that context it is fine. But in SIP the meaning has been broadened. It is assumed to apply to usage = beyond the current transaction - to future transactions, even requests goin= g in the other direction. But it has never been made clear how much beyond = the current transaction it applies. It is impossible to indicate precisely = which headers will be allowed in the future because many of them are allowe= d only in certain contexts. Also, a UA may support a *lot* of header fields= , and may not want to list them all simply to reduce the size of the messag= e. In the current case, indicating support of the option (100rel) implies that= a set of header fields will be used. Listing all of those in Allow is at l= east redundant. I guess this rambling doesn't really affect the conclusion on this erratum.= I'm not sure there is a practical solution to this problem.=20 Perhaps we ought to clarify that Allow in a request MUST indicate header fi= elds allowed in responses to that request, and SHOULD (MAY?) also indicate = header fields that might be allowed in requests directed toward it. Thanks, Paul On 12/12/16 10:43 AM, Ben Campbell wrote: > Do people have thoughts on this errata report? > > My initial inclination that, while the suggestion may be technically=20 > correct, the mentioned SHOULD merely parrots the similar SHOULD in RFC > 3311 (UPDATE method), which is where the authoritative text lives. > (This is why I've started pushing back on redundant 2119 keywords ;-) =20 > ) > > Has anyone observed breakage in the wild due to a peer not doing this? > > Thanks! > > Ben. > > On 12 Dec 2016, at 4:31, RFC Errata System wrote: > >> The following errata report has been submitted for RFC3312,=20 >> "Integration of Resource Management and Session Initiation Protocol=20 >> (SIP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D3312&eid=3D4883 >> >> -------------------------------------- >> Type: Technical >> Reported by: Shraddha Soni >> >> Section: 11 >> >> Original Text >> ------------- >> Therefore, a user agent >> including preconditions in the SDP MUST support the PRACK and UPDATE >> methods. Consequently, it MUST include the "100rel" [7] tag in the >> Supported header field and SHOULD include an Allow header field with >> the "UPDATE" tag [5]. >> >> Corrected Text >> -------------- >> Therefore, a user agent >> including preconditions in the SDP MUST support the PRACK and UPDATE >> methods. Consequently, it MUST include the "100rel" [7] tag in the >> Supported header field and MUST include an Allow header field with >> the "UPDATE" tag [5]. >> >> Notes >> ----- >> As stated in first line in the mentioned paragraph, the user agent=20 >> MUST support the UPDATE method, hence even in Allow header field=20 >> also, UPDATE method MUST be included. >> >> As per RFC 2119 >> "SHOULD -This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. " >> >> Here in precondition case, whether any chance of ignoring the UPDATE=20 >> method happens ? >> >> As per RFC 3261 >> Section 8.2.1 states - >> "The Allow header field MUST list the set of methods supported by the UA= S >> generating the message. ... If the method is one supported by the=20 >> server, processing continues." >> >> and also in RFC 3261 Sections 20.5 states- "All methods, including=20 >> ACK and CANCEL, understood by the UA MUST be >> included in the list of methods in the Allow header field, when >> present." >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please=20 >> use "Reply All" to discuss whether it should be verified or rejected.=20 >> When a decision is reached, the verifying party can log in to change=20 >> the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3312 (draft-ietf-sip-manyfolks-resource-07) >> -------------------------------------- >> Title : Integration of Resource Management and Session >> Initiation Protocol (SIP) >> Publication Date : October 2002 >> Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 12 12:25:40 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441A4129771 for ; Mon, 12 Dec 2016 12:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 7YHujKBdeLOd for ; Mon, 12 Dec 2016 12:25:36 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F3912978B for ; Mon, 12 Dec 2016 12:25:33 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-10v.sys.comcast.net with SMTP id GX9Eckqjm5wROGXADcIMes; Mon, 12 Dec 2016 20:25:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1481574333; bh=oDhL3Rj/qzxPpEOO0oScBrzj35DKviW751L2b5Qb26w=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=pKz6vRTCd8Y1tLlh9WkVrdmeQryN7Be1Q/ReKUuOCaWTtIN8Pb30DJgo8CLWi0UZL N+htkN5wg/T8weWbgq1sCEjzNTCVo3KLyvnygvNtvZTXGWKD7B5pJMJKPNKgUDgX0p NsLaacJNUJHf6BqqI63O4lJXJ7HnYr4O3t683lnsJLvPLxlb5x7qhioJVPpSqiGTjk r6m4THFCjTOriQf9YyXxJlnG9bN69TVoNmN4/KC5c2yANcYBbPqvwhiq7YZ08GG+2C yLjBRxrtryZiFZxV9cUOSdMDxGgKfTc/Ee9cMQapep81WbJswfD9ET0OTNsEer55up CTxjp1quycH4Q== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-10v.sys.comcast.net with SMTP id GXACcv5Vv6d0CGXACc511j; Mon, 12 Dec 2016 20:25:32 +0000 To: sipcore@ietf.org References: <20161212103155.CE434B801D8@rfc-editor.org> <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> <949EF20990823C4C85C18D59AA11AD8BADFC814D@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: Date: Mon, 12 Dec 2016 15:25:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADFC814D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLH05CW8kwxV7JyNnNmsDofclwo4eagCEszkwMUPNjTLClNhgovsoCSCaIXKxilUzcnYifN1ZHa/D9I2PGpVtrEzIdB3rst4qXR7Gy1Anxu8fXLotd4B SKnw4PNJStQM434703OpL1wyB4cT+8YOl8uYktEjN+dJ3IPX2PTC7AXAWIhEEEjk/mm2TKfl+tt5vg== Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 20:25:38 -0000 On 12/12/16 2:31 PM, Drage, Keith (Nokia - GB) wrote: > Yes, but seriously, is this something we need to worry about now. Getting this perfect is not something we should be addressing in an errata, and is if we opened an update, is the world really going to implement the update. I agree it isn't something to address in the errata, except as some context for if/when this eventually gets taken up. Thanks, Paul > Keith > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 12 December 2016 17:31 > To: sipcore@ietf.org > Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) > > I have always been troubled by the detailed semantics of Allow and other similar headers. > > IIUC this originated in HTTP. In that context its meaning is transactional - the requester is indicating what headers it will allow in the response to this one request. In that context it is fine. > > But in SIP the meaning has been broadened. It is assumed to apply to usage beyond the current transaction - to future transactions, even requests going in the other direction. But it has never been made clear how much beyond the current transaction it applies. It is impossible to indicate precisely which headers will be allowed in the future because many of them are allowed only in certain contexts. Also, a UA may support a *lot* of header fields, and may not want to list them all simply to reduce the size of the message. > > In the current case, indicating support of the option (100rel) implies that a set of header fields will be used. Listing all of those in Allow is at least redundant. > > I guess this rambling doesn't really affect the conclusion on this erratum. I'm not sure there is a practical solution to this problem. > Perhaps we ought to clarify that Allow in a request MUST indicate header fields allowed in responses to that request, and SHOULD (MAY?) also indicate header fields that might be allowed in requests directed toward it. > > Thanks, > Paul > > On 12/12/16 10:43 AM, Ben Campbell wrote: >> Do people have thoughts on this errata report? >> >> My initial inclination that, while the suggestion may be technically >> correct, the mentioned SHOULD merely parrots the similar SHOULD in RFC >> 3311 (UPDATE method), which is where the authoritative text lives. >> (This is why I've started pushing back on redundant 2119 keywords ;-) >> ) >> >> Has anyone observed breakage in the wild due to a peer not doing this? >> >> Thanks! >> >> Ben. >> >> On 12 Dec 2016, at 4:31, RFC Errata System wrote: >> >>> The following errata report has been submitted for RFC3312, >>> "Integration of Resource Management and Session Initiation Protocol >>> (SIP)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3312&eid=4883 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Shraddha Soni >>> >>> Section: 11 >>> >>> Original Text >>> ------------- >>> Therefore, a user agent >>> including preconditions in the SDP MUST support the PRACK and UPDATE >>> methods. Consequently, it MUST include the "100rel" [7] tag in the >>> Supported header field and SHOULD include an Allow header field with >>> the "UPDATE" tag [5]. >>> >>> Corrected Text >>> -------------- >>> Therefore, a user agent >>> including preconditions in the SDP MUST support the PRACK and UPDATE >>> methods. Consequently, it MUST include the "100rel" [7] tag in the >>> Supported header field and MUST include an Allow header field with >>> the "UPDATE" tag [5]. >>> >>> Notes >>> ----- >>> As stated in first line in the mentioned paragraph, the user agent >>> MUST support the UPDATE method, hence even in Allow header field >>> also, UPDATE method MUST be included. >>> >>> As per RFC 2119 >>> "SHOULD -This word, or the adjective "RECOMMENDED", mean that there >>> may exist valid reasons in particular circumstances to ignore a >>> particular item, but the full implications must be understood and >>> carefully weighed before choosing a different course. " >>> >>> Here in precondition case, whether any chance of ignoring the UPDATE >>> method happens ? >>> >>> As per RFC 3261 >>> Section 8.2.1 states - >>> "The Allow header field MUST list the set of methods supported by the UAS >>> generating the message. ... If the method is one supported by the >>> server, processing continues." >>> >>> and also in RFC 3261 Sections 20.5 states- "All methods, including >>> ACK and CANCEL, understood by the UA MUST be >>> included in the list of methods in the Allow header field, when >>> present." >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or rejected. >>> When a decision is reached, the verifying party can log in to change >>> the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC3312 (draft-ietf-sip-manyfolks-resource-07) >>> -------------------------------------- >>> Title : Integration of Resource Management and Session >>> Initiation Protocol (SIP) >>> Publication Date : October 2002 >>> Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg >>> Category : PROPOSED STANDARD >>> Source : Session Initiation Protocol >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Dec 12 13:05:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF92129471 for ; Mon, 12 Dec 2016 13:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 GlDvfTbVhMu7 for ; Mon, 12 Dec 2016 13:05:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD8F1297B8 for ; Mon, 12 Dec 2016 13:05:27 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCL5Qtl051758 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 12 Dec 2016 15:05:27 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" From: Adam Roach Message-ID: Date: Mon, 12 Dec 2016 15:05:25 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:05:32 -0000 [as chair] I've seen significant support for adoption of draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and no objections. Our revised charter that includes scope for this kind of item has been approved. The document is now adopted by SIPCORE. I have asked the author to submit subsequent versions of the document as draft-ietf-sipcore-status-unwanted. Given the relatively uncomplicated mechanism being described and the requests for expedited processing, we will be starting our working group last call on the document today. In recognition that the upcoming winter holidays will take some portion of many participants' attention, and that many people will observe a New Year's Holiday on January 2nd, we will run this last call for three weeks, ending on January 3rd. Please review the document and provide comments on before that date. /a From nobody Mon Dec 12 13:50:30 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D354E12945C; Mon, 12 Dec 2016 13:50:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 13:50:24 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:50:25 -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 of the IETF. Title : A SIP Response Code for Unwanted Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-status-unwanted-00.txt Pages : 6 Date : 2016-12-12 Abstract: This document defines the 666 (Unwanted) SIP response code, allowing called parties to indicate that the call was unwanted. The terminating SIP entity may use this information to adjust future call handling behavior for this called party or more broadly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-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 Mon Dec 12 13:53:48 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175251294F2 for ; Mon, 12 Dec 2016 13:53:46 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 aCXhtfpUCUtl for ; Mon, 12 Dec 2016 13:53:43 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A455112945C for ; Mon, 12 Dec 2016 13:53:43 -0800 (PST) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBCLoBLb019667 for ; Mon, 12 Dec 2016 21:53:43 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0056.outbound.protection.outlook.com [23.103.198.56]) by mx0a-0024ed01.pphosted.com with ESMTP id 2788rh9eby-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 12 Dec 2016 21:53:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MKnS3n4U6zPCXCucuNut9B8DapHC/UJFFrbsaEC1tbU=; b=lt3lt8q338yWZgf4fi5njhN2HNoVZ6lvdo4KVZxlxg6mJe1v/RdbQRHM8BhiDJxuNXg+jvd6Ef9j86aQWle1gIjWpv4C1yVub2fxt302+Gb6cGYwMXLvAffKGMh35nOtrTJTJMkut0K84X89v7DUjnv+GJDx2maF3fVZuuiUZk8= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Mon, 12 Dec 2016 21:53:41 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0771.014; Mon, 12 Dec 2016 21:53:41 +0000 From: Henning Schulzrinne To: "sipcore@ietf.org" Thread-Topic: Draft draft-schulzrinne-sipcore-callinfo-spam Thread-Index: AdJUwa+lzsc4VwQzTgKnMSj0uYaReg== Date: Mon, 12 Dec 2016 21:53:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 23ac005a-bdc3-4781-585d-08d422d95675 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:xSW9BeC/T93JFMKNF8xweFC8Ae1ZaAMtjFMmQNruo9H85gMPIwUSSyJ+5kFAlP4oNDpz3BipMFVcrXC6CFHToz+pnopJSAqJC9rml8t5Ua/Q1XM+P3b7y1zD3fMLBi3rP7tnoScbQ8Cf2DqNRgEnzkZesucTLFVxPW9zurhjVEIcCMuvAqPFdjmitpGfr7+u4dYqJFN3jYMg8p1bDokITI4FjOvoEoksIK9va8TU+n0dhmSzGSZ3c7N98w9yMdyXKxdV9P6GmeMHYtMrtCpZ0lab3EOBJOrr2VWUvCFy2O2ZyaHBwidI6v5pWsTQqcBjtiwkMZee4d4nisG7LfCD44Ewaq/WRRPWdKCz0v01EjpwScnHPvvK3Edl9KNf5BoBWPXHasFkOhHtBBgtzmeakmVSllORNuDPY4jbwXzEPzApGjka+HW2bSgOpfn6SS/RwhFjyER49vHrTYRavtAThA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39850400002)(39450400003)(199003)(189002)(81156014)(106356001)(3660700001)(1730700003)(3280700002)(76576001)(81166006)(110136003)(189998001)(99286002)(54356999)(68736007)(8676002)(105586002)(7696004)(50986999)(9686002)(790700001)(102836003)(558084003)(33656002)(3846002)(74316002)(8936002)(66066001)(6436002)(2900100001)(6506006)(101416001)(6116002)(6916009)(122556002)(2906002)(7736002)(2351001)(107886002)(86362001)(2501003)(38730400001)(97736004)(230783001)(5640700002)(5660300001)(77096006)(19609705001)(450100001)(5630700001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06343D6057D9436DAF70ECAAEA980CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2016 21:53:41.9270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-12_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [sipcore] Draft draft-schulzrinne-sipcore-callinfo-spam X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:53:46 -0000 --_000_CY1PR09MB06343D6057D9436DAF70ECAAEA980CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the feedback received, I have updated the draft from the -dispatch= - version. Given the wide-ranging and sometimes contradictory suggestions, = I've tried to find a middle ground on wording. If I failed to incorporate y= our suggestion or comment, please let me (and the list) know. Henning --_000_CY1PR09MB06343D6057D9436DAF70ECAAEA980CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on the feedback received, I have updated the d= raft from the –dispatch- version. Given the wide-ranging and sometime= s contradictory suggestions, I’ve tried to find a middle ground on wo= rding. If I failed to incorporate your suggestion or comment, please let me (and the list) know.

 

Henning

--_000_CY1PR09MB06343D6057D9436DAF70ECAAEA980CY1PR09MB0634namp_-- From nobody Mon Dec 12 14:03:05 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2108F12945C for ; Mon, 12 Dec 2016 14:03:04 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 G6rb3FvG08Re for ; Mon, 12 Dec 2016 14:03:02 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C64129507 for ; Mon, 12 Dec 2016 14:03:01 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBCLseVJ025212 for ; Mon, 12 Dec 2016 22:03:00 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0055.outbound.protection.outlook.com [23.103.198.55]) by mx0b-0024ed01.pphosted.com with ESMTP id 2789hu9c6j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 12 Dec 2016 22:03:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=udt7INDz5kBjyLO4N1LE5EOc6ky/8M5sdD0Di8nd75A=; b=BceEd/Oceb9yRerrCzG65NUDoPx0ZLcsk80PCz2I5B5fd4ILHG3pL1mxtmbWZYVGo21Y1MFCIKN1WyYpLPMaOGfQKlI+zIyFVLCvbImJ8tjuA7tA6nl6m073ru9jT3ukZFuM7hmW/daVn+Bsq68+2/JgWD0VULXA20fREJAsCQo= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Mon, 12 Dec 2016 22:02:59 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0771.014; Mon, 12 Dec 2016 22:02:59 +0000 From: Henning Schulzrinne To: "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-status-unwanted Thread-Index: AdJUwknMjWKjxTTUQBS4ZGOfGU3dJg== Date: Mon, 12 Dec 2016 22:02:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 4e27999e-08ae-4c51-06c7-08d422daa283 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:2Yo0mBd8KQYXZlTk3PLi0EzU/rswUulL3f7qJspSRycC8CZ6FBRoglde+VOqEvXqiXw8kLO+agQGkYwIAyo4Zfb3q6iuoAKndlPLZnVM2EUJxmnro51ihA+0s6kaWa2z9Vl9bJGktcA92QRN9xmkja1ioGlE55lUAKvvXBfXjS3cTy+h0k9caZvtnlUaP23lrhiwuyy0Y5QUb0dNIgXyarmqBZKGA4fc/FZb42av+5TfzLxVQfHutZ9gkYJGvbAEJz6Y8rr8ZLJL50BaRxDM2J+qbef5oyygm8D8aTQ67x6kQr15hR5tjotmf0YrVF+OcZ0cg6JYbLGDZvkxJ99ydfLmRoqBY8xCWpH2rIBSjoeDSfDJgn2TLJ22HepaecxfcqNVuPJ7VX9pCkHZHdHLrZ85uAKssPG8ZaLeCuJqCBmPl92fokPXOjMiJcMqyOxxuUk2UeEzV0Sb5OTSSZhhPQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(268895828855973)(140570224273261)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39840400002)(39450400003)(39410400002)(199003)(189002)(101416001)(7696004)(92566002)(189998001)(15188445003)(76576001)(110136003)(38730400001)(230783001)(68736007)(66066001)(2900100001)(6436002)(2501003)(606005)(77096006)(6916009)(106356001)(3280700002)(1730700003)(105586002)(8676002)(33656002)(97736004)(5660300001)(6506006)(5640700002)(2351001)(86362001)(107886002)(9686002)(7906003)(102836003)(8936002)(99286002)(5630700001)(81166006)(81156014)(3660700001)(74316002)(790700001)(6116002)(54356999)(50986999)(3846002)(2906002)(19609705001)(450100001)(122556002)(7736002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634FF35D05DFD52676D4496EA980CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2016 22:02:58.9162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-12_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [sipcore] draft-ietf-sipcore-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 22:03:04 -0000 --_000_CY1PR09MB0634FF35D05DFD52676D4496EA980CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the feedback received, I have updated the 666 draft. I tried to th= read the needle between the comments that suggested more prescriptive wordi= ng about how SIP entities should handle this and opinions that this would b= e largely implementation dependent, just like for spam filters, within a br= oad outline of options (per-user handling, statistical techniques, incorpor= ation of other signals such as call durations or "age" of number, etc.). Gi= ven the wide-ranging and somewhat non-conclusive discussion, specific wordi= ng suggestions would be particularly helpful. The only part that's new is a feature capability that allows the registrar = to indicate whether it supports this option. The motivation was to allow UA= s to show a "spam" button only if it is actually meaningful, to avoid makin= g it similar to the pedestrian crosswalk buttons in New York City (http://w= ww.nytimes.com/2016/10/28/us/placebo-buttons-elevators-crosswalks.html?_r= =3D0). I'll leave it to others, trained in psychology or sadism, whether pl= acebo "spam" buttons would lead to higher customer satisfaction. Henning --_000_CY1PR09MB0634FF35D05DFD52676D4496EA980CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on the feedback received, I have updated the 6= 66 draft. I tried to thread the needle between the comments that suggested = more prescriptive wording about how SIP entities should handle this and opi= nions that this would be largely implementation dependent, just like for spam filters, within a broad outline of options (= per-user handling, statistical techniques, incorporation of other signals s= uch as call durations or “age” of number, etc.). Given the wide= -ranging and somewhat non-conclusive discussion, specific wording suggestions would be particularly helpful.

 

The only part that’s new is a feature capabili= ty that allows the registrar to indicate whether it supports this option. T= he motivation was to allow UAs to show a “spam” button only if = it is actually meaningful, to avoid making it similar to the pedestrian crosswalk buttons in New York City (http://www.nytimes.com/2016/10/28/us/placebo-buttons-elevators-crosswalk= s.html?_r=3D0). I’ll leave it to others, trained in psychology or sadism, whether placebo “spam” button= s would lead to higher customer satisfaction.

 

Henning

--_000_CY1PR09MB0634FF35D05DFD52676D4496EA980CY1PR09MB0634namp_-- From nobody Mon Dec 12 16:16:16 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BD8129EEC for ; Mon, 12 Dec 2016 16:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 QqM9xdY_08UN for ; Mon, 12 Dec 2016 16:16:13 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BA0129F50 for ; Mon, 12 Dec 2016 16:15:50 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-08v.sys.comcast.net with SMTP id Gakzcjx3RvjKCGal3cAU8F; Tue, 13 Dec 2016 00:15:49 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-06v.sys.comcast.net with SMTP id Gal1cK7y3SSqwGal2c0sPv; Tue, 13 Dec 2016 00:15:49 +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 uBD0Egx9011593 for ; Mon, 12 Dec 2016 19:14:42 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBD0EgaO011590; Mon, 12 Dec 2016 19:14:42 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 12 Dec 2016 19:14:41 -0500 Message-ID: <87wpf4y9am.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCZzwkP1qIbW7R5Z4sEweZqTsdYeqQ9983Ni8acHTnzmxvJxY1qXAs0TJCZiOwWEEDCJMtTMcwmHNYyDQU732XCBm1ZSGicFSGh4IiLhl6ukXTN5CvJI /75DKYBzNTB2vtrq489aDKeNwzf7Oxo/b6ZQjMSE2UVLBmysetcQLeev Archived-At: Subject: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 00:16:15 -0000 This is the start of getting the Happy Eyeballs for SIP work going in the working group. The authors (Olle Johansson, Gonzalo Salgueiro, Dale Worley) are working with the following strategy (at this time): The first tranche is the case where (1) alternative addresses are provided by A and AAAA records based on one host name, i.e., we are not considering multiple SRV records, and (2) all of the targets use connection-oriented protocols. This case is the closest to the Happy Eyeballs for HTTP work that has already been done, though it has some additional requirements (in particular, the fact that connections can be idle for a considerable time, but at unpredictable times, the client wants to use the connection in a soft-real-time way). The current draft is named draft-worley-sip-he-connection-01. (We'll be revising the name.) Our idea is to start with an exposition that is not too far beyond the work for HTTP, so that the discussion remains manageable. In later stages, we will produce successive expansions until the entire SIP operational space is covered. The expansions can be done by any of several methods: - Produce successive RFCs, each of which incorporates the preceding RFC but extends it to additional operational space. Thus, each RFC obsoletes and extends its predecessor, so that an implementer only has to read the current RFC of the sequence. (This is the method that we prefer at present.) - Produce successive drafts, each of which covers a larger operational space and progress the last one to an RFC. This will slow the standardization of the earlier tranches of the work but reduce the overhead of formalizing the drafts as RFCs. - Produce a series of RFCs, each of which updates the preceding RFCs. This seems like the least desirable strategy, as it requires an implementer to read several RFCs and collate their provisions. Let the discussion begin, both on the work and on the plan for the work! Dale From nobody Mon Dec 12 23:29:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DC912954A for ; Mon, 12 Dec 2016 23:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 X3p_eDmlEWqx for ; Mon, 12 Dec 2016 23:29:11 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05871293FF for ; Mon, 12 Dec 2016 23:29:10 -0800 (PST) X-AuditID: c1b4fb2d-e97ff7000000561e-c4-584fa3447866 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 33.C9.22046.443AF485; Tue, 13 Dec 2016 08:29:09 +0100 (CET) Received: from [100.94.10.51] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.319.2; Tue, 13 Dec 2016 08:29:26 +0100 To: "Drage, Keith (Nokia - GB)" , Ben Campbell References: <20161212103155.CE434B801D8@rfc-editor.org> <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> <949EF20990823C4C85C18D59AA11AD8BADFC80D9@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Gonzalo Camarillo Message-ID: Date: Tue, 13 Dec 2016 09:29:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADFC80D9@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7n67rYv8Ig4fbuCz2vz/EZDH9zF9G i/mdp9ktdl3Rslh+8AqzxYYtx1ks/vxdxmrx9ccmNgcOjym/N7J6vJh7gNHjy5OXTB47Tx1g 81iy5CeTx91bl5g8Zu18wuJxcck3xgCOKC6blNSczLLUIn27BK6MRf9fMxXM0ahY3XSGrYGx TaGLkZNDQsBEYsu0+exdjFwcQgLrGCVmHW5kBUkICaxilGjeow5iCwt4S3zrbmcDsUUEIiVW HZwH1bCKSeL3yimMIA6zwAImiSPXX4FVsQlYSGy5dZ8FxOYVsJeY9quLqYuRg4NFQFXi/WYv kLCoQIzEkuPzoEoEJU7OfMICUsIpECtxrF8TJMwsYCBxZNEcVghbXmL72znMELdpSyx/1sIy gVFgFpLuWUhaZiFpWcDIvIpRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMBoObvmtu4Nx9WvH Q4wCHIxKPLwFu/0ihFgTy4orcw8xSnAwK4nwXljgHyHEm5JYWZValB9fVJqTWnyIUZqDRUmc 12zl/XAhgfTEktTs1NSC1CKYLBMHp1QD42y+qQ6fJHNPccT2u3U/mL5OqHRr3pxGz3pl+fSr rhcmqd0TzxYNy25eW67M/eH7Ub09/TcVfrsJWdml/G+X/ftYWo531xWZY5ftXb9k6dcvvvDK aIX8G86KlGCbMquyfTcuRU1c9/JDXZRQl+r57Nr5a2KMfBtObmEN6ZU3c/FdnxfB4/lNiaU4 I9FQi7moOBEAlr2ndoICAAA= Archived-At: Cc: Jonathan Rosenberg , "shraddha.soni2@cognizant.com" , "aamelnikov@fastmail.fm" , SIPCORE , "alissa@cooperw.in" , "dean.willis@softarmor.com" Subject: Re: [sipcore] [ALU] Re: [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 07:29:13 -0000 I also agree with your assessment and proposed way forward Ben. Just do it! Cheers, Gonzalo On 12/12/2016 8:49 PM, Drage, Keith (Nokia - GB) wrote: > Agree. > > Keith > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 12 December 2016 16:24 > To: Gonzalo Camarillo > Cc: SIPCORE ; Jonathan Rosenberg ; shraddha.soni2@cognizant.com; aamelnikov@fastmail.fm; alissa@cooperw.in; Drage, Keith (Nokia - GB) ; dean.willis@softarmor.com > Subject: [ALU] Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) > > I'm inclined to mark this as "hold for update", since a real fix would involve (at least) two RFCs, and I assume this is not actively causing problems for implementors. > > If anyone is aware of related implementation/deployment problems, please speak up. > > Thanks! > > Ben. > > On 12 Dec 2016, at 10:12, Gonzalo Camarillo wrote: > >> Hi Ben, >> >> yes, this is a classic example of a redundant 2119 keyword. >> >> Cheers, >> >> Gonzalo >> >> On 12/12/2016 5:43 PM, Ben Campbell wrote: >>> Do people have thoughts on this errata report? >>> >>> My initial inclination that, while the suggestion may be technically >>> correct, the mentioned SHOULD merely parrots the similar SHOULD in >>> RFC >>> 3311 (UPDATE method), which is where the authoritative text lives. >>> (This is why I've started pushing back on redundant 2119 keywords ;-) >>> ) >>> >>> Has anyone observed breakage in the wild due to a peer not doing >>> this? >>> >>> Thanks! >>> >>> Ben. >>> >>> On 12 Dec 2016, at 4:31, RFC Errata System wrote: >>> >>>> The following errata report has been submitted for RFC3312, >>>> "Integration of Resource Management and Session Initiation Protocol >>>> (SIP)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3312&eid=4883 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Shraddha Soni >>>> >>>> Section: 11 >>>> >>>> Original Text >>>> ------------- >>>> Therefore, a user agent >>>> including preconditions in the SDP MUST support the PRACK and >>>> UPDATE >>>> methods. Consequently, it MUST include the "100rel" [7] tag in >>>> the >>>> Supported header field and SHOULD include an Allow header field >>>> with >>>> the "UPDATE" tag [5]. >>>> >>>> Corrected Text >>>> -------------- >>>> Therefore, a user agent >>>> including preconditions in the SDP MUST support the PRACK and >>>> UPDATE >>>> methods. Consequently, it MUST include the "100rel" [7] tag in >>>> the >>>> Supported header field and MUST include an Allow header field >>>> with >>>> the "UPDATE" tag [5]. >>>> >>>> Notes >>>> ----- >>>> As stated in first line in the mentioned paragraph, the user agent >>>> MUST support the UPDATE method, hence even in Allow header field >>>> also, UPDATE method MUST be included. >>>> >>>> As per RFC 2119 >>>> "SHOULD -This word, or the adjective "RECOMMENDED", mean that there >>>> may exist valid reasons in particular circumstances to ignore a >>>> particular item, but the full implications must be understood and >>>> carefully weighed before choosing a different course. " >>>> >>>> Here in precondition case, whether any chance of ignoring the UPDATE >>>> method happens ? >>>> >>>> As per RFC 3261 >>>> Section 8.2.1 states - >>>> "The Allow header field MUST list the set of methods supported by >>>> the UAS >>>> generating the message. ... If the method is one supported by the >>>> server, processing continues." >>>> >>>> and also in RFC 3261 Sections 20.5 states- "All methods, including >>>> ACK and CANCEL, understood by the UA MUST be >>>> included in the list of methods in the Allow header field, when >>>> present." >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party can log in >>>> to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC3312 (draft-ietf-sip-manyfolks-resource-07) >>>> -------------------------------------- >>>> Title : Integration of Resource Management and Session >>>> Initiation Protocol (SIP) >>>> Publication Date : October 2002 >>>> Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J. >>>> Rosenberg >>>> Category : PROPOSED STANDARD >>>> Source : Session Initiation Protocol >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 13 03:45:28 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87A5129C42 for ; Tue, 13 Dec 2016 03:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 HZdHg4QEAv4C for ; Tue, 13 Dec 2016 03:45:25 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0068.outbound.protection.outlook.com [104.47.32.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A7F129A72 for ; Tue, 13 Dec 2016 03:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZyKnLYmn2VyKKsxKIq7UDTKr5hmbnNaedDXXJ53AK/g=; b=tBBL4BwbrEbGqlRZrkOseq8pGWsSuNNk1ayt5dIFbEvzFJXD7adNSFO+0m7KCIlQD5qEcrISUEOf+gkY3xXos+fSONtOanj5EtSklj9MuYsHGrtofjr6Bh0JmhsR1W1sWkcmBo2Dt3HkQa2fIpHfBePqVtF38fTfMbYP36f+4Ls= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Tue, 13 Dec 2016 11:45:22 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0771.014; Tue, 13 Dec 2016 11:45:22 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSVNYkRj/FKGerzk2IPpPFNc5xDqEFo1zA Date: Tue, 13 Dec 2016 11:45:22 +0000 Message-ID: References: <87wpf4y9am.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wpf4y9am.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: d89255e2-8722-4d6e-ee8f-08d4234d85aa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:VelwiZ4NbXlyY7xj9kQh4FcPP8kuBDBru/Ni5RhMSkm6lrDulJMD4xKQndzDaz+whIAQgEl+X8C1ZxvqDPYiJyJNUIo+h3Mk47CiC4R8xA5u4f+PMwQY1tkSIFjhLbTmS3j6wdaCQ9gT1AINWXvyLn9di5credjpKtiOGZzd3huxExRFXsfmhx/WylxCwpu1BwGOCl1Y0d660cFBKjDOqzYFPI35ghSSZKggw5no6TxjyejGxPhh1/arGqgWoG9Bf0+UxB0BmD0NYRrbJdNnYfUq/71DeoC67KpmQNUVsnSqJdmwnownQz8dJSTcUE4ceT5rwQhFXxSaAm8684eUepfQrHZHbbjHtXLRIeUQ8Ax0pVv3UMRUmK6yARc0idroHV3Ibyhzg30Uc6W7sOUq8mgVyROqQekEFwJmbzz+CgxRKYZAhVRQqGYmDtWpSNypo8zjCOn1SIGOU1p9X6ggow== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 01559F388D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39410400002)(39840400002)(199003)(13464003)(189002)(377454003)(189998001)(97736004)(7696004)(107886002)(5001770100001)(8676002)(105586002)(106116001)(106356001)(2950100002)(99286002)(7736002)(305945005)(74316002)(86362001)(33656002)(122556002)(5660300001)(101416001)(2900100001)(76176999)(8936002)(50986999)(54356999)(66066001)(77096006)(6436002)(6506006)(81166006)(81156014)(92566002)(2906002)(3280700002)(3660700001)(229853002)(38730400001)(2501003)(9686002)(68736007)(102836003)(76576001)(3846002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2016 11:45:22.5846 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 11:45:28 -0000 RFC7984 =3D> why not OPTIONS for testing without changing "status" DNS SRV Records =3D> not necessarily pointing to the same server's differen= t IP Address families, could be multiple servers with each different addres= s families =3D> should be addressed by Happy-Eyeballs Why only "connection oriented"? Fast /reliable/secure failover is another p= roblem=20 Please see inline for comments/questions. =20 Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worl= ey > Sent: Monday, December 12, 2016 7:15 PM > To: sipcore@ietf.org > Subject: [sipcore] Happy Eyeballs for SIP >=20 > This is the start of getting the Happy Eyeballs for SIP work going in the > working group. >=20 > The authors (Olle Johansson, Gonzalo Salgueiro, Dale Worley) are working > with the following strategy (at this time): The first tranche is the cas= e where > (1) alternative addresses are provided by A and AAAA records based on one > host name, i.e., we are not considering multiple SRV records, and (2) all= of > the targets use connection-oriented protocols. [TOLGA]=20 i- Why only A/AAAA records? What about cases where a different SRV record i= s used for each supported address family? AFAIU this type of configuration = is already mentioned in RFC7984.=20 RFC3263 is a bit vague regarding what needs to be done if there are multipl= e SRV records: "If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each." Does this mean "for all transports for the selected -according to priority/= weight- SRV Record" or "for all transport/SRV Record pairs". I tend to think the former but RFC7984 seems to differ: "For example, consider a server with DNS name example.com, with TCP transport specified. The relevant SRV records for example.com are: _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. The processing of [RFC2782] results in this ordered list of target domain names: sip-1.example.com sip-2.example.com" Then it lists all addresses for both of the SRV Records. Granted, it mentio= ns that addresses are not interleaved but nonetheless it assumes that a que= ry is performed for both of the SRV Records. I am not sure what the right i= nterpretation should be here but it is not well-defined to say the least. T= o me, it seems like RFC7984 should be updating RFC3263 normatively in this = aspect as well -to promote the RFC7984 defined behavior-. And IMHO it would= be up to the Happy-Eyeballs draft to define how addresses from multiple SR= V Records should be used. Cases, where a dual-stack entity does not know wh= ether IPv4/IPv6 is preferred and multiple SRV records are used for differen= t address families on different servers should be covered as well. ii- Why only for connection-oriented protocols? I think the generic problem= happy-eyeballs addresses and what is targeted with draft-worley-sip-he-con= nection-01 are different. The former can be a building block for the latter= but that shouldn't mean that it should be restricted by it IMHO. Is there = any technical reason why happy-eyeballs is not applicable -by itself- for S= IP over UDP? > This case is the closest to the Happy Eyeballs for HTTP work that has alr= eady > been done, though it has some additional requirements (in particular, the > fact that connections can be idle for a considerable time, but at unpredi= ctable > times, the client wants to use the connection in a soft-real-time way). >=20 > The current draft is named draft-worley-sip-he-connection-01. (We'll be > revising the name.) >=20 > Our idea is to start with an exposition that is not too far beyond the wo= rk for > HTTP, so that the discussion remains manageable. In later stages, we wil= l > produce successive expansions until the entire SIP operational space is > covered. The expansions can be done by any of several methods: >=20 > - Produce successive RFCs, each of which incorporates the preceding RFC > but extends it to additional operational space. Thus, each RFC > obsoletes and extends its predecessor, so that an implementer only has > to read the current RFC of the sequence. (This is the method that we > prefer at present.) >=20 > - Produce successive drafts, each of which covers a larger operational > space and progress the last one to an RFC. This will slow the > standardization of the earlier tranches of the work but reduce the > overhead of formalizing the drafts as RFCs. >=20 > - Produce a series of RFCs, each of which updates the preceding RFCs. > This seems like the least desirable strategy, as it requires an > implementer to read several RFCs and collate their provisions. [TOLGA] Please the second approach. It wouldn't significantly matter whethe= r iterations of ideas/algorithms are captured in a series of RFCs/drafts in= terms of adaptation. An RFC is supposed to be "complete" according to the = best of our knowledge at a given time. So, I strongly would suggest to go w= ith "multiple drafts" approach (Option-2). >=20 > Let the discussion begin, both on the work and on the plan for the work! >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 13 03:52:00 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C071295E0 for ; Tue, 13 Dec 2016 03:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 x8qE4iqTORt6 for ; Tue, 13 Dec 2016 03:51:56 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0042.outbound.protection.outlook.com [104.47.40.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB5B1295AB for ; Tue, 13 Dec 2016 03:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dKkDfSanxIdhrEKEccd//HmmmSPxj0QZbTVbuC7Fns8=; b=X7tkaijLSWlW3C8UaqG+yzh5u6tpYy3JsL7gBEALXp7/zWDdOnCrFxG7tCP+NisfFCl4GU0gFwRezxXMjynwYy/DbiMtQL/s883dp6UPJSvR1Ec+I73zrwN0z8T850OFgYJmCOKGrpanNfxkvtRVdOiI8lTjm7kbDxuylLYMqOQ= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Tue, 13 Dec 2016 11:51:54 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0771.014; Tue, 13 Dec 2016 11:51:54 +0000 From: "Asveren, Tolga" To: "Asveren, Tolga" , "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSVNYkRj/FKGerzk2IPpPFNc5xDqEFo1zAgAAhL5A= Date: Tue, 13 Dec 2016 11:51:53 +0000 Message-ID: References: <87wpf4y9am.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:2KvKOBozOPWBAMhS11kv2F49uNbyZJz5CMdy17os+yXDYXIkiMpnA/1rhVTfQmpKuJ9/hQ0XtyqLilmrVisbQHisU/OYAUrGmP/p6MuYQzQABHAqchSnnnHH7RKL4gHrxO8gl65xXfMRvWp5mcAll9w0yOGMdoIpCH/R5LRdPi3IeOBWBAFslnsn4b/ZU08pipLIURFfQ9Q0jx6Nx7nRkzJeX+v/wiqvrZmTLTFS32uEOMPmr+GA6yx4IJ5wtNk/UIRGgQ82u9UiiUMhtE2CIYr6BNUyrRnrZFycLPW/j3S25QEU5doleVMFEC6cCiP9s2nGLfnI+ZyGyhU9FL4UxdXZibuCA7mwnV4YK2O4/q9QwT4WAC6v7MMjlBksOJUAIfxC9nIwDD2j4VJYEQOhxPmyZ7qBZ6rsBVRoZqfKtxDlXSQcNMc91EBiKTDQ9k7lGNuUVesVMlU2qq7j/dZI0Q== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(13464003)(199003)(377454003)(189002)(74316002)(66066001)(92566002)(305945005)(81166006)(81156014)(8936002)(2900100001)(5660300001)(2950100002)(2501003)(7696004)(189998001)(68736007)(33656002)(86362001)(229853002)(107886002)(99286002)(106356001)(106116001)(38730400001)(3660700001)(3846002)(2906002)(6436002)(105586002)(5001770100001)(54356999)(6116002)(76176999)(97736004)(8676002)(101416001)(122556002)(7736002)(3280700002)(50986999)(102836003)(77096006)(76576001)(6506006)(9686002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 39575610-5c66-4dfd-0513-08d4234e6ee9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01559F388D received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2016 11:51:53.9817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 11:51:58 -0000 Please disregard everything before "Please see inline for comments/question= s" :-) Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, > Tolga > Sent: Tuesday, December 13, 2016 6:45 AM > To: Dale R. Worley ; sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs for SIP >=20 > RFC7984 =3D> why not OPTIONS for testing without changing "status" > DNS SRV Records =3D> not necessarily pointing to the same server's differ= ent > IP Address families, could be multiple servers with each different addres= s > families =3D> should be addressed by Happy-Eyeballs >=20 > Why only "connection oriented"? Fast /reliable/secure failover is another > problem >=20 > Please see inline for comments/questions. >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. > > Worley > > Sent: Monday, December 12, 2016 7:15 PM > > To: sipcore@ietf.org > > Subject: [sipcore] Happy Eyeballs for SIP > > > > This is the start of getting the Happy Eyeballs for SIP work going in > > the working group. > > > > The authors (Olle Johansson, Gonzalo Salgueiro, Dale Worley) are > > working with the following strategy (at this time): The first tranche > > is the case where > > (1) alternative addresses are provided by A and AAAA records based on > > one host name, i.e., we are not considering multiple SRV records, and > > (2) all of the targets use connection-oriented protocols. > [TOLGA] > i- Why only A/AAAA records? What about cases where a different SRV record > is used for each supported address family? AFAIU this type of configurati= on is > already mentioned in RFC7984. > RFC3263 is a bit vague regarding what needs to be done if there are multi= ple > SRV records: > "If no NAPTR records are found, the client constructs SRV queries for > those transport protocols it supports, and does a query for each." > Does this mean "for all transports for the selected -according to > priority/weight- SRV Record" or "for all transport/SRV Record pairs". > I tend to think the former but RFC7984 seems to differ: > "For example, consider a server with DNS name example.com, with TCP > transport specified. The relevant SRV records for example.com are: >=20 > _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. > _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. >=20 > The processing of [RFC2782] results in this ordered list of target > domain names: >=20 > sip-1.example.com > sip-2.example.com" > Then it lists all addresses for both of the SRV Records. Granted, it ment= ions > that addresses are not interleaved but nonetheless it assumes that a quer= y is > performed for both of the SRV Records. I am not sure what the right > interpretation should be here but it is not well-defined to say the least= . To > me, it seems like RFC7984 should be updating RFC3263 normatively in this > aspect as well -to promote the RFC7984 defined behavior-. And IMHO it > would be up to the Happy-Eyeballs draft to define how addresses from > multiple SRV Records should be used. Cases, where a dual-stack entity doe= s > not know whether IPv4/IPv6 is preferred and multiple SRV records are used > for different address families on different servers should be covered as = well. >=20 > ii- Why only for connection-oriented protocols? I think the generic probl= em > happy-eyeballs addresses and what is targeted with draft-worley-sip-he- > connection-01 are different. The former can be a building block for the l= atter > but that shouldn't mean that it should be restricted by it IMHO. Is there= any > technical reason why happy-eyeballs is not applicable -by itself- for SIP= over > UDP? >=20 > > This case is the closest to the Happy Eyeballs for HTTP work that has > > already been done, though it has some additional requirements (in > > particular, the fact that connections can be idle for a considerable > > time, but at unpredictable times, the client wants to use the connectio= n in > a soft-real-time way). > > > > The current draft is named draft-worley-sip-he-connection-01. (We'll > > be revising the name.) > > > > Our idea is to start with an exposition that is not too far beyond the > > work for HTTP, so that the discussion remains manageable. In later > > stages, we will produce successive expansions until the entire SIP > > operational space is covered. The expansions can be done by any of > several methods: > > > > - Produce successive RFCs, each of which incorporates the preceding RFC > > but extends it to additional operational space. Thus, each RFC > > obsoletes and extends its predecessor, so that an implementer only ha= s > > to read the current RFC of the sequence. (This is the method that we > > prefer at present.) > > > > - Produce successive drafts, each of which covers a larger operational > > space and progress the last one to an RFC. This will slow the > > standardization of the earlier tranches of the work but reduce the > > overhead of formalizing the drafts as RFCs. > > > > - Produce a series of RFCs, each of which updates the preceding RFCs. > > This seems like the least desirable strategy, as it requires an > > implementer to read several RFCs and collate their provisions. > [TOLGA] Please the second approach. It wouldn't significantly matter > whether iterations of ideas/algorithms are captured in a series of RFCs/d= rafts > in terms of adaptation. An RFC is supposed to be "complete" according to = the > best of our knowledge at a given time. So, I strongly would suggest to go= with > "multiple drafts" approach (Option-2). > > > > Let the discussion begin, both on the work and on the plan for the work= ! > > > > Dale > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 13 06:46:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA756129AE3 for ; Tue, 13 Dec 2016 06:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 O67sMdoQ4VDW for ; Tue, 13 Dec 2016 06:46:21 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E22129AC6 for ; Tue, 13 Dec 2016 06:45:56 -0800 (PST) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-05v.sys.comcast.net with SMTP id GoJWc0UuafyWhGoL5cZKBN; Tue, 13 Dec 2016 14:45:55 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-07v.sys.comcast.net with SMTP id GoL4cubBXx0GlGoL4crHDL; Tue, 13 Dec 2016 14: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 uBDEirdD004175; Tue, 13 Dec 2016 09:44:53 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBDEirIC004172; Tue, 13 Dec 2016 09:44:53 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: (paul.kyzivat@comcast.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 13 Dec 2016 09:44:53 -0500 Message-ID: <878trjyjkq.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIIJOtkY2iCfyqmmZEh+VnOG+U+Wo6ujbtg/xPPvEoSvBIjl9StzTa8LD9PkSLmIwUKMs7awXqHYQ5oor5EwuNFH/QHLNJurRQQD3+uWN/eMuDNXtEcE Eo3KD6SkZ+0j/n5/T5Oi34W+N+dYeSbbv0JRg+h4/73S3er2AhI8NwGmn8+9qMaga2f02p7UV57vtNJZfSrL7yNdnDO7R5L2ruo= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 14:46:23 -0000 Of course, Ben's suggestion is the best way to handle the erratum (assuming there are no problems in practice). Paul Kyzivat writes: > I have always been troubled by the detailed semantics of Allow and other > similar headers. My memory is that there was a discussion some years back in which all the angles of this problem were discussed, with the conclusion being that when the UAC sends a request, the headers it has received in previous requests and responses are only hints because the current request may go to a different destination. I.e., the scope of the information provided by headers is always unclear. So the UAC should usually simply attempt to use the extensions that it desires to use, and have an appropriate fallback strategy if that fails. Dale From nobody Tue Dec 13 07:26:23 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF061293F5 for ; Tue, 13 Dec 2016 07:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 H_b7mvMtMw97 for ; Tue, 13 Dec 2016 07:26:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788D0129404 for ; Tue, 13 Dec 2016 07:26:18 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBDFPxX9064420 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Dec 2016 09:26:00 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Gonzalo Camarillo" Date: Tue, 13 Dec 2016 09:26:00 -0600 Message-ID: <1739B99A-B4F0-4C17-9F24-8EBFCB60BC28@nostrum.com> In-Reply-To: References: <20161212103155.CE434B801D8@rfc-editor.org> <10E46F9A-E73C-4F21-918B-1663DAF3E2EB@nostrum.com> <949EF20990823C4C85C18D59AA11AD8BADFC80D9@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: "shraddha.soni2@cognizant.com" , Jonathan Rosenberg , "aamelnikov@fastmail.fm" , SIPCORE , "alissa@cooperw.in" , "dean.willis@softarmor.com" Subject: Re: [sipcore] [ALU] [Technical Errata Reported] RFC3312 (4883) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 15:26:22 -0000 It is done. Ben. On 13 Dec 2016, at 1:29, Gonzalo Camarillo wrote: > I also agree with your assessment and proposed way forward Ben. Just > do it! > > Cheers, > > Gonzalo > > On 12/12/2016 8:49 PM, Drage, Keith (Nokia - GB) wrote: >> Agree. >> >> Keith >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 12 December 2016 16:24 >> To: Gonzalo Camarillo >> Cc: SIPCORE ; Jonathan Rosenberg >> ; shraddha.soni2@cognizant.com; >> aamelnikov@fastmail.fm; alissa@cooperw.in; Drage, Keith (Nokia - GB) >> ; dean.willis@softarmor.com >> Subject: [ALU] Re: [sipcore] [Technical Errata Reported] RFC3312 >> (4883) >> >> I'm inclined to mark this as "hold for update", since a real fix >> would involve (at least) two RFCs, and I assume this is not actively >> causing problems for implementors. >> >> If anyone is aware of related implementation/deployment problems, >> please speak up. >> >> Thanks! >> >> Ben. >> >> On 12 Dec 2016, at 10:12, Gonzalo Camarillo wrote: >> >>> Hi Ben, >>> >>> yes, this is a classic example of a redundant 2119 keyword. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 12/12/2016 5:43 PM, Ben Campbell wrote: >>>> Do people have thoughts on this errata report? >>>> >>>> My initial inclination that, while the suggestion may be >>>> technically >>>> correct, the mentioned SHOULD merely parrots the similar SHOULD in >>>> RFC >>>> 3311 (UPDATE method), which is where the authoritative text lives. >>>> (This is why I've started pushing back on redundant 2119 keywords >>>> ;-) >>>> ) >>>> >>>> Has anyone observed breakage in the wild due to a peer not doing >>>> this? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> On 12 Dec 2016, at 4:31, RFC Errata System wrote: >>>> >>>>> The following errata report has been submitted for RFC3312, >>>>> "Integration of Resource Management and Session Initiation >>>>> Protocol >>>>> (SIP)". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=3312&eid=4883 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Shraddha Soni >>>>> >>>>> Section: 11 >>>>> >>>>> Original Text >>>>> ------------- >>>>> Therefore, a user agent >>>>> including preconditions in the SDP MUST support the PRACK and >>>>> UPDATE >>>>> methods. Consequently, it MUST include the "100rel" [7] tag in >>>>> the >>>>> Supported header field and SHOULD include an Allow header field >>>>> with >>>>> the "UPDATE" tag [5]. >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> Therefore, a user agent >>>>> including preconditions in the SDP MUST support the PRACK and >>>>> UPDATE >>>>> methods. Consequently, it MUST include the "100rel" [7] tag in >>>>> the >>>>> Supported header field and MUST include an Allow header field >>>>> with >>>>> the "UPDATE" tag [5]. >>>>> >>>>> Notes >>>>> ----- >>>>> As stated in first line in the mentioned paragraph, the user agent >>>>> MUST support the UPDATE method, hence even in Allow header field >>>>> also, UPDATE method MUST be included. >>>>> >>>>> As per RFC 2119 >>>>> "SHOULD -This word, or the adjective "RECOMMENDED", mean that >>>>> there >>>>> may exist valid reasons in particular circumstances to ignore a >>>>> particular item, but the full implications must be understood >>>>> and >>>>> carefully weighed before choosing a different course. " >>>>> >>>>> Here in precondition case, whether any chance of ignoring the >>>>> UPDATE >>>>> method happens ? >>>>> >>>>> As per RFC 3261 >>>>> Section 8.2.1 states - >>>>> "The Allow header field MUST list the set of methods supported by >>>>> the UAS >>>>> generating the message. ... If the method is one supported by >>>>> the >>>>> server, processing continues." >>>>> >>>>> and also in RFC 3261 Sections 20.5 states- "All methods, including >>>>> ACK and CANCEL, understood by the UA MUST be >>>>> included in the list of methods in the Allow header field, when >>>>> present." >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This erratum is currently posted as "Reported". If necessary, >>>>> please >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. When a decision is reached, the verifying party can log >>>>> in >>>>> to change the status and edit the report, if necessary. >>>>> >>>>> -------------------------------------- >>>>> RFC3312 (draft-ietf-sip-manyfolks-resource-07) >>>>> -------------------------------------- >>>>> Title : Integration of Resource Management and >>>>> Session >>>>> Initiation Protocol (SIP) >>>>> Publication Date : October 2002 >>>>> Author(s) : G. Camarillo, Ed., W. Marshall, Ed., J. >>>>> Rosenberg >>>>> Category : PROPOSED STANDARD >>>>> Source : Session Initiation Protocol >>>>> Area : Real-time Applications and Infrastructure >>>>> Stream : IETF >>>>> Verifying Party : IESG >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 13 07:53:48 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96182129B56 for ; Tue, 13 Dec 2016 07:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 JIli_FVfMhvp for ; Tue, 13 Dec 2016 07:53:45 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DD4129407 for ; Tue, 13 Dec 2016 07:53:44 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-08v.sys.comcast.net with SMTP id GpOPckneUvjKCGpOicByFk; Tue, 13 Dec 2016 15:53:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1481644424; bh=dfDha5/UlMnShExcOuAJyWH5fUoXTIhqNIy6AFjQuT0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=mxSseSMQ9/NnODSCsI7q9bkR7Gc6L3X+CqwsgOeSvH/BJKVILOPSIKgmvBH+U2tDB 3h5bW+OjYznQdzKC8zIJEJnqs4QDcu6lQ8L28jIsYVvsWCFF5ugfz2Vfez/QUt4KWp CkLYqxPc8MkuZmwokDl1WsfA2iCWAt6WShDwPkWJpherspel/4qJc0b359O572Nivz kRGk8bc9BcSUpR+MTegQY4GsUsh0qutYo25FfSEjTIG6aQZa3l042txCbN0GHr7gf7 OchRlSeTNXNnYks7vfkkm60CE1IMGUAnTcbYlDiWT3APNspLfRdMe3B4N9KyVWh7rj yqZjbldE5kbPQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-18v.sys.comcast.net with SMTP id GpOhcDiXrk82QGpOhczqQY; Tue, 13 Dec 2016 15:53:44 +0000 To: sipcore@ietf.org References: <87wpf4y9am.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <4fbcbcd2-907e-92ed-455d-039eacfb7b16@comcast.net> Date: Tue, 13 Dec 2016 10:53:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <87wpf4y9am.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfOZxqH7qbhDQy7GSwYH/D/fxftIUp1k1Vq6SJZsh1FgQlnWQZFZB5PpIE28ha8cj1vQgwb9H7F1v7DxZyQRg7dEv7y2VfZOkbBaiU2LpCNZB/U6BM3Zl 8acEZ7Spu2+Gq6d55XemoRCj9slRzoKNHl4faYpfs0xVL8ENmvCbcKy0rzrEpmusYuSnBmFFXRvNuw== Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 15:53:46 -0000 On 12/12/16 7:14 PM, Dale R. Worley wrote: > Our idea is to start with an exposition that is not too far beyond the > work for HTTP, so that the discussion remains manageable. In later > stages, we will produce successive expansions until the entire SIP > operational space is covered. The expansions can be done by any of > several methods: > > - Produce successive RFCs, each of which incorporates the preceding RFC > but extends it to additional operational space. Thus, each RFC > obsoletes and extends its predecessor, so that an implementer only has > to read the current RFC of the sequence. (This is the method that we > prefer at present.) > > - Produce successive drafts, each of which covers a larger operational > space and progress the last one to an RFC. This will slow the > standardization of the earlier tranches of the work but reduce the > overhead of formalizing the drafts as RFCs. > > - Produce a series of RFCs, each of which updates the preceding RFCs. > This seems like the least desirable strategy, as it requires an > implementer to read several RFCs and collate their provisions. How long do you imagine this process will take? ISTM that (2) is the most desirable, unless it takes a very long time. If it say more than a year between extensions then *maybe* (1) or (3) would make sense. Also, if you need operational experience with an earlier phase befor moving on then one of the stages approaches will be justified. Thanks, Paul From nobody Tue Dec 13 08:06:16 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09A1296B4 for ; Tue, 13 Dec 2016 08:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.098 X-Spam-Level: X-Spam-Status: No, score=-107.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 mLT3rxo22E8z for ; Tue, 13 Dec 2016 08:06:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B14129B46 for ; Tue, 13 Dec 2016 08:06:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3E609B81746; Tue, 13 Dec 2016 08:06:11 -0800 (PST) To: christer.holmberg@ericsson.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, mahoney@nostrum.com, adam@nostrum.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161213160611.3E609B81746@rfc-editor.org> Date: Tue, 13 Dec 2016 08:06:11 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, sipcore@ietf.org Subject: [sipcore] [Technical Errata Reported] RFC6228 (4886) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 16:06:15 -0000 The following errata report has been submitted for RFC6228, "Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6228&eid=4886 -------------------------------------- Type: Technical Reported by: Brett Tate Section: 5 Original Text ------------- If the Supported header field of an initial dialog initiation request does not contain a "199" option-tag, the UAC MUST NOT send a 199 response on any early dialog associated with the request. Corrected Text -------------- If the Supported header field of an initial dialog initiation request does not contain a "199" option-tag, the UAS MUST NOT send a 199 response on any early dialog associated with the request. Notes ----- Changed "UAC" to "UAS" since the UAC does not send responses. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6228 (draft-ietf-sipcore-199-06) -------------------------------------- Title : Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog Publication Date : May 2011 Author(s) : C. Holmberg Category : PROPOSED STANDARD Source : Session Initiation Protocol Core RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Tue Dec 13 08:12:53 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206AC1204D9 for ; Tue, 13 Dec 2016 08:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 h48lKrWNSyPw for ; Tue, 13 Dec 2016 08:12:50 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F188C129407 for ; Tue, 13 Dec 2016 08:12:48 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBDGCbNY070637 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Dec 2016 10:12:38 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: christer.holmberg@ericsson.com, brett@broadsoft.com Date: Tue, 13 Dec 2016 10:12:37 -0600 Message-ID: <96EF061E-F3FC-4BAC-9F50-ABBBB8B6F51B@nostrum.com> In-Reply-To: <20161213160611.3E609B81746@rfc-editor.org> References: <20161213160611.3E609B81746@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: sipcore@ietf.org, alissa@cooperw.in, aamelnikov@fastmail.fm Subject: Re: [sipcore] [Technical Errata Reported] RFC6228 (4886) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 16:12:52 -0000 Hi, this seems like an editorial issue to me, in that I assume UAC was a typo. Do people think this will cause implementation errors? Or more to the point, has anyone experienced implementation errors due to this? Thanks! Ben. On 13 Dec 2016, at 10:06, RFC Errata System wrote: > The following errata report has been submitted for RFC6228, > "Session Initiation Protocol (SIP) Response Code for Indication of > Terminated Dialog". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6228&eid=4886 > > -------------------------------------- > Type: Technical > Reported by: Brett Tate > > Section: 5 > > Original Text > ------------- > If the Supported header field of an initial dialog initiation > request > does not contain a "199" option-tag, the UAC MUST NOT send a 199 > response on any early dialog associated with the request. > > > Corrected Text > -------------- > If the Supported header field of an initial dialog initiation > request > does not contain a "199" option-tag, the UAS MUST NOT send a 199 > response on any early dialog associated with the request. > > > Notes > ----- > Changed "UAC" to "UAS" since the UAC does not send responses. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6228 (draft-ietf-sipcore-199-06) > -------------------------------------- > Title : Session Initiation Protocol (SIP) Response Code > for Indication of Terminated Dialog > Publication Date : May 2011 > Author(s) : C. Holmberg > Category : PROPOSED STANDARD > Source : Session Initiation Protocol Core RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From nobody Tue Dec 13 08:34:32 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F149C129B9B for ; Tue, 13 Dec 2016 08:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 5Ojd_QiEMP0j for ; Tue, 13 Dec 2016 08:34:25 -0800 (PST) Received: from mx0b-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D97F129BAE for ; Tue, 13 Dec 2016 08:33:48 -0800 (PST) Received: from pps.filterd (m0103508.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBDGUbGb015112 for ; Tue, 13 Dec 2016 11:33:47 -0500 Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by mx0b-001d8301.pphosted.com with ESMTP id 27a4wnb51q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 13 Dec 2016 11:33:47 -0500 Received: by mail-lf0-f70.google.com with SMTP id 96so1825298lfs.7 for ; Tue, 13 Dec 2016 08:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=XOJPGrzpnggLm/pqP8V+dO5fJdYBg1G9guAzBGjAuac=; b=ZlEA4PlJtqU6J8194OQmJQHWcjNt8YioB6O3Jb7rGciI3GxCl+DTFeTVpasmpcgoxP 1hkXmvd8m50lA3I72wpC5izJtDVNH6oXs9saXcc/WpB/+EyKuUOnZaVxm9SDvRPW0iUA q0qC5rLsHjphbevwjRydaNnpXj61no7/dTb3anw4bFRBxMCewT0D2jU6uDABiJjQ88Pa AjaALckJozoUU1a6b+Jf+mcbVxywUBsd/BICcwGxhtUP0V5mozWTxXj2DBNxi9PUvYfL ZLlcxQ+IDa+4tKdUeRIstad933tFrzJ8FvDFrBketk1wkaTl6YDavTqXUAjWcu8wb91Y jrqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=XOJPGrzpnggLm/pqP8V+dO5fJdYBg1G9guAzBGjAuac=; b=k3b1eaR9nvqM7X6kW+xMgdsAKOgVi6ztR7Ub+lSRGEbADn0GNVkp4VB66LT/PUzuyY AG5lSFsou4rnrOItOxG0oK9ozbmNidAVEb8yh3iQ1H6ItiE+jLA6RlecEXAX/vGJoQJE xevwy1kUOhCW+onTbayciqC0npfDUX22Jkxi9cLjVk0+3qUsavjJbiI9hnii0JyCkBO5 6ZfYrN2cRxsh3lxpRXs+9lvF/hnF4wxIIYVEiDzyTLQByEO6NR6ps38Tp24TBJk+maAm /gSwfjbamorQ7hlCwcIUHMGumZFp1acoGYAMlP082uZyI6tK1bpB5m5VsKPxgFYWNcgn B13A== X-Gm-Message-State: AKaTC01IzotX8npMzEb1cIxBZN2kiBe1FMN/CgmuicbQGpQm0LbWnQunoMy/XxKWFBl2/kzch0SjM3fSW9aDXIiAEnu/uepwQp2oP8o8ymlEw/GaBY2r5zhuUHqBWzxtJ6q/rXBNal6uYdKv X-Received: by 10.25.219.69 with SMTP id s66mr28320660lfg.116.1481646825741; Tue, 13 Dec 2016 08:33:45 -0800 (PST) X-Received: by 10.25.219.69 with SMTP id s66mr28320652lfg.116.1481646825472; Tue, 13 Dec 2016 08:33:45 -0800 (PST) From: Brett Tate References: <20161213160611.3E609B81746@rfc-editor.org> <96EF061E-F3FC-4BAC-9F50-ABBBB8B6F51B@nostrum.com> In-Reply-To: <96EF061E-F3FC-4BAC-9F50-ABBBB8B6F51B@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKZTWd6JYRBm5Nu2V9pPePLCFWGzgNiVDZ/n10KcbA= Date: Tue, 13 Dec 2016 11:33:43 -0500 Message-ID: To: Ben Campbell , christer.holmberg@ericsson.com Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-13_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: sipcore@ietf.org, alissa@cooperw.in, aamelnikov@fastmail.fm Subject: Re: [sipcore] [Technical Errata Reported] RFC6228 (4886) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 16:34:31 -0000 Hi, I agree that it is a typo. However excluding the fix, I didn't find text imposing the same mandate on the UAS. Thus, I marked the errata type as technical. So far, I've only noticed the issue of UAS ignoring the mandate within documentation instead of a deployed implementation. > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, December 13, 2016 11:13 AM > To: christer.holmberg@ericsson.com; brett@broadsoft.com > Cc: alissa@cooperw.in; aamelnikov@fastmail.fm; mahoney@nostrum.com; > adam@nostrum.com; sipcore@ietf.org > Subject: Re: [Technical Errata Reported] RFC6228 (4886) > > Hi, this seems like an editorial issue to me, in that I assume UAC was a > typo. Do people think this will cause implementation errors? Or more to the > point, has anyone experienced implementation errors due to this? > > Thanks! > > Ben. > > On 13 Dec 2016, at 10:06, RFC Errata System wrote: > > > The following errata report has been submitted for RFC6228, "Session > > Initiation Protocol (SIP) Response Code for Indication of Terminated > > Dialog". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6228&eid=4886 > > > > -------------------------------------- > > Type: Technical > > Reported by: Brett Tate > > > > Section: 5 > > > > Original Text > > ------------- > > If the Supported header field of an initial dialog initiation > > request > > does not contain a "199" option-tag, the UAC MUST NOT send a 199 > > response on any early dialog associated with the request. > > > > > > Corrected Text > > -------------- > > If the Supported header field of an initial dialog initiation > > request > > does not contain a "199" option-tag, the UAS MUST NOT send a 199 > > response on any early dialog associated with the request. > > > > > > Notes > > ----- > > Changed "UAC" to "UAS" since the UAC does not send responses. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party can log in to change > > the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6228 (draft-ietf-sipcore-199-06) > > -------------------------------------- > > Title : Session Initiation Protocol (SIP) Response Code > > for Indication of Terminated Dialog > > Publication Date : May 2011 > > Author(s) : C. Holmberg > > Category : PROPOSED STANDARD > > Source : Session Initiation Protocol Core RAI > > Area : Real-time Applications and Infrastructure > > Stream : IETF > > Verifying Party : IESG From nobody Tue Dec 13 08:37:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E5912944C for ; Tue, 13 Dec 2016 08:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=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 Ujz8UJgR3ykS for ; Tue, 13 Dec 2016 08:37:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D181412944D for ; Tue, 13 Dec 2016 08:37:30 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBDGbHhr073169 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Dec 2016 10:37:18 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Brett Tate" Date: Tue, 13 Dec 2016 10:37:16 -0600 Message-ID: <022A9343-233C-4BD1-9DC3-70280808D3D0@nostrum.com> In-Reply-To: References: <20161213160611.3E609B81746@rfc-editor.org> <96EF061E-F3FC-4BAC-9F50-ABBBB8B6F51B@nostrum.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: aamelnikov@fastmail.fm, sipcore@ietf.org, alissa@cooperw.in Subject: Re: [sipcore] [Technical Errata Reported] RFC6228 (4886) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 16:37:33 -0000 I see your point. I lean towards verifying the report. Christer: thoughts? On 13 Dec 2016, at 10:33, Brett Tate wrote: > Hi, > > I agree that it is a typo. However excluding the fix, I didn't find text > imposing the same mandate on the UAS. Thus, I marked the errata type as > technical. > > So far, I've only noticed the issue of UAS ignoring the mandate within > documentation instead of a deployed implementation. > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, December 13, 2016 11:13 AM >> To: christer.holmberg@ericsson.com; brett@broadsoft.com >> Cc: alissa@cooperw.in; aamelnikov@fastmail.fm; mahoney@nostrum.com; >> adam@nostrum.com; sipcore@ietf.org >> Subject: Re: [Technical Errata Reported] RFC6228 (4886) >> >> Hi, this seems like an editorial issue to me, in that I assume UAC was a >> typo. Do people think this will cause implementation errors? Or more to > the >> point, has anyone experienced implementation errors due to this? >> >> Thanks! >> >> Ben. >> >> On 13 Dec 2016, at 10:06, RFC Errata System wrote: >> >>> The following errata report has been submitted for RFC6228, "Session >>> Initiation Protocol (SIP) Response Code for Indication of Terminated >>> Dialog". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=6228&eid=4886 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Brett Tate >>> >>> Section: 5 >>> >>> Original Text >>> ------------- >>> If the Supported header field of an initial dialog initiation >>> request >>> does not contain a "199" option-tag, the UAC MUST NOT send a 199 >>> response on any early dialog associated with the request. >>> >>> >>> Corrected Text >>> -------------- >>> If the Supported header field of an initial dialog initiation >>> request >>> does not contain a "199" option-tag, the UAS MUST NOT send a 199 >>> response on any early dialog associated with the request. >>> >>> >>> Notes >>> ----- >>> Changed "UAC" to "UAS" since the UAC does not send responses. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or rejected. >>> When a decision is reached, the verifying party can log in to change >>> the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC6228 (draft-ietf-sipcore-199-06) >>> -------------------------------------- >>> Title : Session Initiation Protocol (SIP) Response Code >>> for Indication of Terminated Dialog >>> Publication Date : May 2011 >>> Author(s) : C. Holmberg >>> Category : PROPOSED STANDARD >>> Source : Session Initiation Protocol Core RAI >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG From nobody Tue Dec 13 09:22:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F99E12958A for ; Tue, 13 Dec 2016 09:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 FxYXqE2KrpmK for ; Tue, 13 Dec 2016 09:22:19 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EFF129446 for ; Tue, 13 Dec 2016 09:22:19 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-03v.sys.comcast.net with SMTP id GqlgcBJ94MppVGqmQcfYk7; Tue, 13 Dec 2016 17:22:18 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-05v.sys.comcast.net with SMTP id GqmPcu2X3HGXvGqmQcpxv4; Tue, 13 Dec 2016 17:22:18 +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 uBDHLBXN020240; Tue, 13 Dec 2016 12:21:11 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBDHLB4b020237; Tue, 13 Dec 2016 12:21:11 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 13 Dec 2016 12:21:11 -0500 Message-ID: <87shprvj7c.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfPXWYkWDyqfcJQhWVbFT9u/Xdgbm7NyD6LArP2I2PV7+P0AwRNGIJ1HHZ9OAUR919w2QDCwbKcg2UDXKfDPhQ8Z83Q8QYasIDlQFUt3Y4LSR2FmuiBXk 2qK8bnWKNcbRqDupADqbcToH1dcRiYf6PeIprheenjapx9qrdHSXDoHygM3uhks3WV61q+btyJD7nNy4OspnP/rwvXVsgiaGxNE= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 17:22:21 -0000 "Asveren, Tolga" writes: >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley >> Sent: Monday, December 12, 2016 7:15 PM >> To: sipcore@ietf.org >> Subject: [sipcore] Happy Eyeballs for SIP >> >> This is the start of getting the Happy Eyeballs for SIP work going in the >> working group. >> >> The authors (Olle Johansson, Gonzalo Salgueiro, Dale Worley) are >> working with the following strategy (at this time): The first >> tranche is the case where (1) alternative addresses are provided by A >> and AAAA records based on one host name, i.e., we are not considering >> multiple SRV records, and (2) all of the targets use >> connection-oriented protocols. > > i- Why only A/AAAA records? What about cases where a different SRV > record is used for each supported address family? AFAIU this type of > configuration is already mentioned in RFC7984. Indeed, that configuration is mentioned in 7984, and was inserted into 7984 because it is such a common configuration. However, we decided to not handle SRV in this tranche because a comprehensive approach to SRV is complicated and nobody has yet proposed a solution that promises to meet the desiderata, viz.: - achieve the Happy Eyeballs effect, that is, traffic will be very rarely delayed by unreachability of one or more of the targets - achieve the specified effect of SRV, that is, among the set of targets which are reachable, over the long run, the traffic will be distributed among them according to the specified priorities and weights in the SRV records > RFC3263 is a bit vague regarding what needs to be done if there are > multiple SRV records: > "If no NAPTR records are found, the client constructs SRV queries for > those transport protocols it supports, and does a query for each." > Does this mean "for all transports for the selected -according to > priority/weight- SRV Record" or "for all transport/SRV Record pairs". Well, since the priorities/weights are extracted from the SRV records, the priorities/weights cannot affect how the SRV records are queried for. My interpretation is "for each transport that the client supports and that is permitted by the URI scheme and the 'transport' option of the URI (if any), the client constructs an SRV query for the URI scheme, the transport and the target domain name". Of course, if there are multiple SRV records for a scheme/transport/domain name combination, the single query will return all of them. Thus, a query for sip/TCP/example.com would return the two SRV records you quoted: > I tend to think the former but RFC7984 seems to differ: > "For example, consider a server with DNS name example.com, with TCP > transport specified. The relevant SRV records for example.com are: > > _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. > _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. Once all the SRV records are obtained, the priority/weight processing is applied to them. Although it is not specified in RFC 2782 (SRV records), the standard practice seems to be that all of the SRV records obtained for all of the protocols are considered as a single set for priority/weight processing, which generates an ordered list of the target domain names of the SRV records. (Of course, in this example, that is not relevant, since both of the SRV records are for TCP, and so are obtained by one SRV query, while the UDP SRV query obtains no records.) > The processing of [RFC2782] results in this ordered list of target > domain names: > > sip-1.example.com > sip-2.example.com" > Then it lists all addresses for both of the SRV Records. Granted, it > mentions that addresses are not interleaved but nonetheless it assumes > that a query is performed for both of the SRV Records. Actually, one query was done, for _sip._tcp.example.com, and it returned both records. > I am not sure > what the right interpretation should be here but it is not > well-defined to say the least. To me, it seems like RFC7984 should be > updating RFC3263 normatively in this aspect as well -to promote the > RFC7984 defined behavior-. And IMHO it would be up to the > Happy-Eyeballs draft to define how addresses from multiple SRV Records > should be used. Cases, where a dual-stack entity does not know whether > IPv4/IPv6 is preferred and multiple SRV records are used for different > address families on different servers should be covered as well. Can you give an example where the procedures of RFC 2782 aren't sufficient to resolve this problem? > ii- Why only for connection-oriented protocols? I think the generic > problem happy-eyeballs addresses and what is targeted with > draft-worley-sip-he-connection-01 are different. The former can be a > building block for the latter but that shouldn't mean that it should > be restricted by it IMHO. Is there any technical reason why > happy-eyeballs is not applicable -by itself- for SIP over UDP? The *concept* of Happy Eyeballs can, should, and will be applied to UDP, but the *details* are going to be considerably different from the details for TCP. For the first tranche, we are attempting to stay near what has been done for HTTP, so we are limiting the scope to connection-oriented protocols. Dale From nobody Tue Dec 13 12:13:47 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC39B1295B9 for ; Tue, 13 Dec 2016 12:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 UXg7VF6dvuWR for ; Tue, 13 Dec 2016 12:13:44 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F5B1293EC for ; Tue, 13 Dec 2016 12:13:44 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-03v.sys.comcast.net with SMTP id GtRXcBY5oMppVGtSJcg5cV; Tue, 13 Dec 2016 20:13:43 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-07v.sys.comcast.net with SMTP id GtSJcReYZurzaGtSJcL4qH; Tue, 13 Dec 2016 20:13:43 +0000 To: sipcore@ietf.org References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu> Date: Tue, 13 Dec 2016 15:13:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDLUTx1QTjDsMje6NNMPrrpcfz56wH6ZKAeuVzBOmrOO8XTWPs6Vz8ElOtHvS5WIYysjgNBJYplVFcATP5sprMCbZNOYIsFOczIQmzMEUYjnmVvnWjWM xistKU4D4HiRe9Uv6zgLbeW7hz7wkQtIglBnJencr7cXkH+5TK3fQiqu Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 20:13:46 -0000 I reviewed this new version. I have a couple of suggestions for small wording changes: * Section 1: The wording of the following: ... The called party or a automata acting on her behalf uses this to indicate that future calls from the same caller are also unwanted. is odd. AFAIK, the "called party" here is a person who interacts with the called UA to indicate that the call is unwanted. The called party doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA, acting as an automata, may generate the response without a stimulus from the called party. I suggest the following to replace the above: ... The called user agent (UAS), based on input from the called party or internal logic, uses this code to indicate that this call and future calls from the same caller are unwanted. * Section 2: This section has some text having a similar issue: None of the existing 4xx, 5xx or 6xx response codes allow the called party to convey that they not only reject this call, e.g., using 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere), 603 (Decline) or 606 (Not Acceptable), but that the caller is unwanted. I suggest: None of the existing 4xx, 5xx or 6xx response codes signify that calls from this caller are unwanted by the called party. Otherwise I like it. Thanks, Paul On 12/12/16 4:50 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core of the IETF. > > Title : A SIP Response Code for Unwanted Calls > Author : Henning Schulzrinne > Filename : draft-ietf-sipcore-status-unwanted-00.txt > Pages : 6 > Date : 2016-12-12 > > Abstract: > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call was unwanted. The > terminating SIP entity may use this information to adjust future call > handling behavior for this called party or more broadly. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-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/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Dec 14 00:25:57 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27578129680; Wed, 14 Dec 2016 00:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ojxjLF4LKLrr; Wed, 14 Dec 2016 00:25:53 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9AE2129486; Wed, 14 Dec 2016 00:25:53 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id v78so9828529ybe.3; Wed, 14 Dec 2016 00:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uNKOwYK3yiFtErc2lbDAMLL8hbBQzPTzfnHr1jVsCWk=; b=V6SFDhWsBOj4eazsGS6ncXYHtxqU3vi4y4DWvYXlN2ceM8mfmNFv3+C8qohLBx/D6C wVfJHKYD/WpWekteGB6ByEsJ3kXmVLNxzv1nbIasKodcgCSCnSmynsrbJifYMNAHcsz1 FvHuEpXS4hj6c7wvyYVaaTsXUm3hIjWPz0YJEa1auU4HZRxRphlAoykPizldxIgb9h92 UTfJXZtBnSRxi0X5gLyO5b2fL7CaqvMCIgLiVJaXguwNSKnXjW2KBuN1aaeFSQ5g5qNt pqjw0ZnDp+/IR2iqZTaLUSA0dU/YjGkgLEXGPP0lkJsWDBu299F3Bz3ilY5EtNMmbEa6 lWwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uNKOwYK3yiFtErc2lbDAMLL8hbBQzPTzfnHr1jVsCWk=; b=ecKreSVmJxuxlWiJcrqL/Uj1A9rz/PN4P5UPc5g6OEtP01EWa3vHzRz3KwxxEMExEE qZFqScPsgn1irp80PUBxDC8VfPjwW8yMzlw+bH/XmPARJk4d5ZFjr6v3wF5l+Zdq5GyU F4Ab8HiZak6FyAyo6bEufyFffFjmnN1vybYtq2Fx/vD7OaM8P2MyRi635hhnORi86x3O Fop7JSe1rqbS7eKjdx+HRuqgl1nkuDG3aefccLetmpA1qSQCuAWDij+5u+MmI/Hrp+TE d15at0GB7P9+arqYXhIPkvQr3v9u6T9hmvT9GmgIlk+XK84P/cIjDhevH+79sEFB9E6l BZQA== X-Gm-Message-State: AKaTC00QnmiUPvQPu36akgxUM+nZOZ/jcrkAfF5Y5liElwSaiHoLlrp6wwZzM6SnsIah+rIWRWhx2tMD6+twiA== X-Received: by 10.129.56.2 with SMTP id f2mr99516119ywa.51.1481703952827; Wed, 14 Dec 2016 00:25:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.105.131 with HTTP; Wed, 14 Dec 2016 00:25:52 -0800 (PST) In-Reply-To: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> From: Alberto Llamas Date: Wed, 14 Dec 2016 09:25:52 +0100 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a114c7932c5489b05439a1545 Archived-At: Cc: sipcore@ietf.org, i-d-announce@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 08:25:56 -0000 --001a114c7932c5489b05439a1545 Content-Type: text/plain; charset=UTF-8 Hello, Wouldn't be useful to include a desirable UAC behavior when serial/parallel forking?. Something like if the UAC receive the unwanted message when doing serial or parallel forking is recommended the UAC stop the forking process? Regards, On Mon, Dec 12, 2016 at 10:50 PM, wrote: > > 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 of the > IETF. > > Title : A SIP Response Code for Unwanted Calls > Author : Henning Schulzrinne > Filename : draft-ietf-sipcore-status-unwanted-00.txt > Pages : 6 > Date : 2016-12-12 > > Abstract: > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call was unwanted. The > terminating SIP entity may use this information to adjust future call > handling behavior for this called party or more broadly. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-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/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > -- Alberto Llamas Telecommunications Engineer Digium Certified Asterisk Professional (dCap) --001a114c7932c5489b05439a1545 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Wouldn't be useful to includ= e a desirable UAC behavior when serial/parallel forking?. Something like if= the UAC receive the unwanted message when doing serial or parallel forking= is recommended =C2=A0the UAC =C2=A0stop the forking process?

Regards,

On Mon, Dec 12, 2016 at 10:50 PM, <= ;internet-dra= fts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Session Initiation Protocol Core of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A SIP Response Code for Unwanted Calls
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Henn= ing Schulzrinne
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sipcore-status-unwanted-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-12-12

Abstract:
=C2=A0 =C2=A0This document defines the 666 (Unwanted) SIP response code, al= lowing
=C2=A0 =C2=A0called parties to indicate that the call was unwanted.=C2=A0 T= he
=C2=A0 =C2=A0terminating SIP entity may use this information to adjust futu= re call
=C2=A0 =C2=A0handling behavior for this called party or more broadly.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/

There's also a htmlized version available at:
https://tools.ietf.org/html/dr= aft-ietf-sipcore-status-unwanted-00


Please note that it may take a couple of minutes from the time of submissio= n
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/

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



--
Alberto Llamas
Telec= ommunications Engineer
Digium C= ertified Asterisk Professional (dCap)

--001a114c7932c5489b05439a1545-- From nobody Wed Dec 14 04:35:30 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C481129A71 for ; Wed, 14 Dec 2016 04:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 XupTaqy5XatW for ; Wed, 14 Dec 2016 04:35:27 -0800 (PST) Received: from mx0b-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91075129A6C for ; Wed, 14 Dec 2016 04:35:27 -0800 (PST) Received: from pps.filterd (m0103508.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBECZNbs022988 for ; Wed, 14 Dec 2016 07:35:26 -0500 Received: from mail-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by mx0b-001d8301.pphosted.com with ESMTP id 27a4wnfhfh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 14 Dec 2016 07:35:26 -0500 Received: by mail-wj0-f199.google.com with SMTP id hb5so8368170wjc.2 for ; Wed, 14 Dec 2016 04:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=6/ijG1WMrxepZd2NwUnv94NYVokaWiKuEYwy/PuDGfE=; b=DIJOLJG5l5kMjWTQo/qjj0mxoFoYkN+47EJ3wZNHHkhvfM6UZoBwiKH3lvOoNc2hy6 eUMGZGNGy0BjvE4nYrnty5WJT+ymeSiDIZeytRF/L3e0HInV6zUBlxBfj2yjxSaNIgCw rR+xqT7zO9dC4LqAW/sWtCjp7q8xIwb5UQ5r/HgqGCIQ2KHnEHd24YBiLwXSkLjEDoTp 72Rfag9q35/dHXZm9WTMcVax8B4YwXmxXZsMFcagcB6pBTGk84HySItamx/Qsi6OS7D5 HbQNpaDd3t4nciRtbqUwQwFn/0IVyTS8ak4nlyFruveC/uKAEmB1RrC8x6fN0QQ9FPgv /D6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=6/ijG1WMrxepZd2NwUnv94NYVokaWiKuEYwy/PuDGfE=; b=HThYEFhZl/+Hi+lx1jeW47Hds7DoTi5pneALAKDcR4o0IaT1jKnTlu4Q3M149cg3m1 xjy6Pe/dLgdrmfl7m1iBeiizqYHtIXTdZUQAKkvT5tZvGfJm0Cf3W9tr4HRrUNUY5fgO +ki5hJKCAIyGJy1kTH7USN2+AbGVJOUkZokQfbXmxiiWyWOWHARwSot1H41o1AYKZEL5 yFbTx/m8F8YZGWX+EYidk30GxsVghGqy8trbr7aOUcDaOdtrHDPs98RkIafbxrpPPoh+ ApgrkkrHfeJIn2KWSCfuQ/F+WVkXRpdRwh4Oe7xpiMCDbQyIDKL94J4s2gFHnrApjIDv Bd9g== X-Gm-Message-State: AKaTC03F3ZGMq9DwR+T8k8h3haFfNSOcreU2ic36Zq7RxRhxgY3Y4HEBwpu1VQxbgJtRwAuFPw0C+XQWE9C0EnYha+5PKPKSC/0Tc7hrlhUyngWUUqY/QtmGyOR+OcvhflvWDmxDwcF519r1 X-Received: by 10.25.161.8 with SMTP id k8mr13066233lfe.165.1481718925321; Wed, 14 Dec 2016 04:35:25 -0800 (PST) X-Received: by 10.25.161.8 with SMTP id k8mr13066223lfe.165.1481718925090; Wed, 14 Dec 2016 04:35:25 -0800 (PST) From: Brett Tate References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIOCroxNbZpXiRg+Pi0XzF8v8wqYwGbcSUAoIMJU4A= Date: Wed, 14 Dec 2016 07:35:23 -0500 Message-ID: <7bf9793827ef219d822fd5c0f1fe1faa@mail.gmail.com> To: Alberto Llamas , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-14_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 12:35:29 -0000 > Wouldn't be useful to include a desirable UAC behavior when > serial/parallel forking?. Something like if the UAC receive > the unwanted message when doing serial or parallel forking > is recommended the UAC stop the forking process? Concerning "UAC stop the forking process", I assume that you referring to the proxies that process the 666 response. It looks like RFC 3261 section 16.7 already covers it. RFC 3261 section 16.7: "If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context." From nobody Wed Dec 14 05:29:45 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD23129670 for ; Wed, 14 Dec 2016 05:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 A_xceQSNiO5c for ; Wed, 14 Dec 2016 05:29:43 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C69812965E for ; Wed, 14 Dec 2016 05:29:43 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id d128so15271373ybh.2 for ; Wed, 14 Dec 2016 05:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gOfU/elntoN8GDMnxtRP2OphwZ1HrPgFWIcp0JjBS9s=; b=friONHtACSDzM+TAKtBOQpeA2Aa6or3eQrKypus2u/r3TVY2Bs8a9ZQygpflQmF3bz oL6088l7h/xZd44k6uEMKoFC77sWHv4S0BCX8HYhN3kEjwh5B0m/yaZvV68sbsiGOup/ KYq9ZQ+y3wYFSfO8IXY0ad82XhNILuS1Q7QMBtfMW+UsT0gYAGUxVAdkGd6ZkIYwWHSS jNu1zay73qneyU3zSx7H4vTS2sJLzwOgHOKENNB7GQsTIFsTy3K8UOOdVAZ/07kZ+r4Y RajiNQhqCJvwrD1RGqIIZp0ZPqB/xNq3ycP2FXsQlB/wEhHIAdVF2SKeLw95PBONEQ2G kgmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gOfU/elntoN8GDMnxtRP2OphwZ1HrPgFWIcp0JjBS9s=; b=T8MJawqt1K8gmKnNIzW1c08eGYFGDT7vpWXddEb8eB3RmeQPA6INYaH4rlHqDNoDZZ 3u/xCMYIgEZYTDsEDaVwx64vbBMoVUXjSskL2hqfyoSNNZK3KSsbHVqL2LqRXGGeFseg Wl1HflPlFy73BBx2SB92Aq8SDz4NDgdeamYHUa0IDjv2ai+1QhHqWoLSwOIIU2xB7kGr VpOneDyDYjy1A5bcFJiDeLJgFQKXUUi5R9sw+s2aDDkdLKbnxVR6tVDnHTT6Y4iW75Dd YQG7G2qAXfWz05TkrgKgguXC2mdHKM+dDfVa7UfoXDAEw5XSC/gjgcFPh9xjcRlGuddG d0nA== X-Gm-Message-State: AKaTC00ohDqzMkuG8d2Lt2NlGPnmqr5geesHVdd48Nb3sYwsdas6JaCugE/Y+dT1y8r+AYpMEMactI2PG6uOZQ== X-Received: by 10.129.56.2 with SMTP id f2mr100382898ywa.51.1481722182332; Wed, 14 Dec 2016 05:29:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.105.131 with HTTP; Wed, 14 Dec 2016 05:29:41 -0800 (PST) In-Reply-To: <7bf9793827ef219d822fd5c0f1fe1faa@mail.gmail.com> References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> <7bf9793827ef219d822fd5c0f1fe1faa@mail.gmail.com> From: Alberto Llamas Date: Wed, 14 Dec 2016 14:29:41 +0100 Message-ID: To: Brett Tate Content-Type: multipart/alternative; boundary=001a114c7932558ff705439e5410 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 13:29:44 -0000 --001a114c7932558ff705439e5410 Content-Type: text/plain; charset=UTF-8 Hello Brett, Thanks for the reply and yes, my concern is covered by RFC 3261 section 16.7 Regards, On Wed, Dec 14, 2016 at 1:35 PM, Brett Tate wrote: > > Wouldn't be useful to include a desirable UAC behavior when > > serial/parallel forking?. Something like if the UAC receive > > the unwanted message when doing serial or parallel forking > > is recommended the UAC stop the forking process? > > Concerning "UAC stop the forking process", I assume that you referring to > the proxies that process the 666 response. It looks like RFC 3261 section > 16.7 already covers it. > > RFC 3261 section 16.7: "If a 6xx response is received, it is not > immediately > forwarded, but the stateful proxy SHOULD cancel all client pending > transactions as described in Section 10, and it MUST NOT create any new > branches in this context." > -- Alberto Llamas Telecommunications Engineer Digium Certified Asterisk Professional (dCap) --001a114c7932558ff705439e5410 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Brett,

Thanks for the reply and y= es, my concern is covered =C2=A0by =C2=A0R= FC 3261 section 16.7

=
Regards,

On Wed, Dec 14= , 2016 at 1:35 PM, Brett Tate <brett@broadsoft.com> wrote:=
> Wouldn't be us= eful to include a desirable UAC behavior when
> serial/parallel forking?. Something like if the UAC receive
> the unwanted message when doing serial or parallel forking
> is recommended=C2=A0 the UAC=C2=A0 stop the forking process?

Concerning "UAC stop the forking process", I assume that y= ou referring to
the proxies that process the 666 response.=C2=A0 It looks like RFC 3261 sec= tion
16.7 already covers it.

RFC 3261 section 16.7: "If a 6xx response is received, it is not immed= iately
forwarded, but the stateful proxy SHOULD cancel all client pending
transactions as described in Section 10, and it MUST NOT create any new
branches in this context."



--
Alberto Llamas
Telec= ommunications Engineer
Digium C= ertified Asterisk Professional (dCap)

--001a114c7932558ff705439e5410-- From nobody Wed Dec 14 08:16:05 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D5112985F for ; Wed, 14 Dec 2016 08:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 y72-sQmbm9tP for ; Wed, 14 Dec 2016 08:16:03 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1452812940E for ; Wed, 14 Dec 2016 08:16:03 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-11v.sys.comcast.net with SMTP id HCDSctNpL6nWCHCDqc8mLV; Wed, 14 Dec 2016 16:16:02 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-03v.sys.comcast.net with SMTP id HCDocS0fE2G28HCDpc1ajF; Wed, 14 Dec 2016 16:16: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 uBEGF0g5029228; Wed, 14 Dec 2016 11:15:00 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBEGExCs029225; Wed, 14 Dec 2016 11:14:59 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: tasveren@sonusnet.com, sipcore@ietf.org In-Reply-To: <87shprvj7c.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 14 Dec 2016 11:14:58 -0500 Message-ID: <87eg1atrlp.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEZZtA7ols4303vsknFPZs6FUWs7JCKcoZpsR83cWITPwOU17uf1NySNjGRVfKDoukYCco1vApuA0DVBkD+hB61eo2AMe74r3r6AnMKDC1cvTdiZILse kLduC2WMoX6rxteb90du9q0Op/1kFMgGIoTX5EbUDre5C7Jt+wfezsB7YJ5UDsskY6YgvlU2656fwS3hXKSxvoY24IjNNvc2tAM= Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 16:16:04 -0000 worley@ariadne.com (Dale R. Worley) writes: > Although it is not specified in RFC 2782 (SRV records), the standard > practice seems to be that all of the SRV records obtained for all of the > protocols are considered as a single set for priority/weight processing, > which generates an ordered list of the target domain names of the SRV > records. Thinking about the issue again, I believe that I am incorrect here. In the one implementation I know deeply, if two transports are queried for, the SRV records are first sorted based on their transport, then by their SRV priority. Either UDP is placed before TCP or vice-versa, depending on the message length, more or less based on section 18.1.1 of RFC 3261 -- short messages prefer UDP and long ones prefer TCP. Dale From nobody Wed Dec 14 09:11:17 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B556112951D for ; Wed, 14 Dec 2016 09:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 Oppjp2Cjevr9 for ; Wed, 14 Dec 2016 09:11:12 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0060.outbound.protection.outlook.com [104.47.40.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5481129E94 for ; Wed, 14 Dec 2016 09:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pUy5P3TLMkSeUV+hmgWDCgkigCkWgALtTkhqwS7qACI=; b=M/t7VAjv/2eylMk4trbZmZqAEk1Bw6wnJLkpFazG61jd+g8lAp4afxwi1GAhqG5Ue81edzqwj6cx6GQs/nW7b0Rtcyqq5459PCMg3Y47fqIlrpziTMHM9fdc4GcTFprqAWfDfuV3V+AZvEuKaro+cWPlOkH+RjbzASinj9ZVIFk= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Wed, 14 Dec 2016 17:11:02 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 17:11:02 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSVWVMRj/FKGerzk2IPpPFNc5xDqEGPnvw Date: Wed, 14 Dec 2016 17:11:01 +0000 Message-ID: References: (tasveren@sonusnet.com) <87shprvj7c.fsf@hobgoblin.ariadne.com> In-Reply-To: <87shprvj7c.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 365b3273-282a-456a-1ba2-08d424442e71 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:fjieEnB7acVqQ/1Ytr/vBPyfFsXxuSWR1+aZA3AomM2tzBs4KyK8i5PS/z7EiiSo2udAgLL2r9LiDULRcRfQ6q0mnuP2l37fxNdqS8CD84Ci9LD2yG9jJeY60Fa7VS1yv8+Qccz+C0hOM5GRuFYuJBS3UlDU4NroXqXTgeQV45HdtwmRS33yfmDOxDtkv2EyRIAKz7X2/ivkbTlb26vIAYIuvRIF8lSKcqWSpmzgOOrvyKWvAnfQGG6uhtSnms5fLsBVPyJT3Qvfkr8aKMARgSVcYUkQYq1I3+TMGZM0mHLBXRqTNu5haCEKUdoG/U3EqeYJSR6+A4CYjgQntd8wjiYU7Bz0ALPt2GAPkei57XoJpDUHau9ik2NSdZxO4M7Sy59lVJTdemY3xFC5lz9XkofW6nS/JLNNLCsSrb56KowtvJ0SrmOdZDF9vNBDd+BgY+VRAJe7BtcSwvxTmzN/OA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123558021)(20161123560025)(20161123564025)(20161123562025)(6047074)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(39450400003)(39410400002)(39840400002)(199003)(13464003)(377454003)(189002)(8676002)(2900100001)(6916009)(189998001)(81156014)(6506006)(6436002)(66066001)(110136003)(106116001)(38730400001)(9686002)(25786008)(92566002)(122556002)(74316002)(86362001)(77096006)(81166006)(8936002)(106356001)(2950100002)(105586002)(7696004)(229853002)(33656002)(3280700002)(99286002)(5660300001)(68736007)(305945005)(3660700001)(76576001)(102836003)(6116002)(54356999)(76176999)(3846002)(50986999)(7736002)(2906002)(101416001)(4326007)(97736004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 17:11:01.9681 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 17:11:14 -0000 Inline... Thanks, Tolga > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Tuesday, December 13, 2016 12:21 PM > To: Asveren, Tolga > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs for SIP >=20 > "Asveren, Tolga" writes: > >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. > >> Worley > >> Sent: Monday, December 12, 2016 7:15 PM > >> To: sipcore@ietf.org > >> Subject: [sipcore] Happy Eyeballs for SIP > >> > >> This is the start of getting the Happy Eyeballs for SIP work going in > >> the working group. > >> > >> The authors (Olle Johansson, Gonzalo Salgueiro, Dale Worley) are > >> working with the following strategy (at this time): The first > >> tranche is the case where (1) alternative addresses are provided by A > >> and AAAA records based on one host name, i.e., we are not considering > >> multiple SRV records, and (2) all of the targets use > >> connection-oriented protocols. > > > > i- Why only A/AAAA records? What about cases where a different SRV > > record is used for each supported address family? AFAIU this type of > > configuration is already mentioned in RFC7984. >=20 > Indeed, that configuration is mentioned in 7984, and was inserted into > 7984 because it is such a common configuration. However, we decided to > not handle SRV in this tranche because a comprehensive approach to SRV is > complicated and nobody has yet proposed a solution that promises to meet > the desiderata, viz.: >=20 > - achieve the Happy Eyeballs effect, that is, traffic will be very > rarely delayed by unreachability of one or more of the targets >=20 > - achieve the specified effect of SRV, that is, among the set of targets > which are reachable, over the long run, the traffic will be > distributed among them according to the specified priorities and > weights in the SRV records [TOLGA] I understand that "perfect outcome" may be hard to describe -let al= one to achieve- especially considering various deployment models/expectatio= ns. OTOH, I would think that allowing some freedom in terms of ordering cou= ld be all what needs to be mentioned in the specification, e.g.=20 Rather than: One ought to use the SRV records according to their weight/priority where e= ventually only one of them is the winner and is resolved This: One may resolve all/a sub-set of available SRV records by also considering = IP Address Family and IP Address Family can be also considered for the orde= r of the queries=20 I can provide text/edit the document if we can reach a conclusion/consensus= on this point. >=20 > > RFC3263 is a bit vague regarding what needs to be done if there are > > multiple SRV records: > > "If no NAPTR records are found, the client constructs SRV queries fo= r > > those transport protocols it supports, and does a query for each." > > Does this mean "for all transports for the selected -according to > > priority/weight- SRV Record" or "for all transport/SRV Record pairs". >=20 > Well, since the priorities/weights are extracted from the SRV records, th= e > priorities/weights cannot affect how the SRV records are queried for. My > interpretation is "for each transport that the client supports and that i= s > permitted by the URI scheme and the 'transport' option of the URI (if any= ), > the client constructs an SRV query for the URI scheme, the transport and = the > target domain name". Of course, if there are multiple SRV records for a > scheme/transport/domain name combination, the single query will return al= l > of them. Thus, a query for sip/TCP/example.com would return the two SRV > records you quoted: >=20 > > I tend to think the former but RFC7984 seems to differ: > > "For example, consider a server with DNS name example.com, with TCP > > transport specified. The relevant SRV records for example.com are: > > > > _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. > > _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. >=20 > Once all the SRV records are obtained, the priority/weight processing is > applied to them. >=20 > Although it is not specified in RFC 2782 (SRV records), the standard prac= tice > seems to be that all of the SRV records obtained for all of the protocols= are > considered as a single set for priority/weight processing, which generate= s an > ordered list of the target domain names of the SRV records. (Of course, = in > this example, that is not relevant, since both of the SRV records are for= TCP, > and so are obtained by one SRV query, while the UDP SRV query obtains no > records.) >=20 > > The processing of [RFC2782] results in this ordered list of target > > domain names: > > > > sip-1.example.com > > sip-2.example.com" >=20 > > Then it lists all addresses for both of the SRV Records. Granted, it > > mentions that addresses are not interleaved but nonetheless it assumes > > that a query is performed for both of the SRV Records. >=20 > Actually, one query was done, for _sip._tcp.example.com, and it returned > both records. >=20 > > I am not sure > > what the right interpretation should be here but it is not > > well-defined to say the least. To me, it seems like RFC7984 should be > > updating RFC3263 normatively in this aspect as well -to promote the > > RFC7984 defined behavior-. And IMHO it would be up to the > > Happy-Eyeballs draft to define how addresses from multiple SRV Records > > should be used. Cases, where a dual-stack entity does not know whether > > IPv4/IPv6 is preferred and multiple SRV records are used for different > > address families on different servers should be covered as well. >=20 > Can you give an example where the procedures of RFC 2782 aren't sufficien= t > to resolve this problem? [TOLGA] "Usage Rules" section of RFC2782 seem to imply: i- A list is prepared by querying all SRV records. Queries are performed by= the priority/weight based ordering. ii- And then there is "freedom" in terms of selecting the server to actuall= y use. I think i- is where some improvement could be useful in the context of happ= y-eyeballs. The IP Address Family can be used as a third parameter -in addi= tion to priority/weight- when ordering DNS queries. Granted, one may argue = that all queries can be performed in parallel but still some clarification = text in the specification could be a good idea to highlight this and preven= t any confusion. >=20 > > ii- Why only for connection-oriented protocols? I think the generic > > problem happy-eyeballs addresses and what is targeted with > > draft-worley-sip-he-connection-01 are different. The former can be a > > building block for the latter but that shouldn't mean that it should > > be restricted by it IMHO. Is there any technical reason why > > happy-eyeballs is not applicable -by itself- for SIP over UDP? >=20 > The *concept* of Happy Eyeballs can, should, and will be applied to UDP, = but > the *details* are going to be considerably different from the details for= TCP. > For the first tranche, we are attempting to stay near what has been done = for > HTTP, so we are limiting the scope to connection-oriented protocols. [TOLGA] I think one issue was regarding the "probing" for UDP. With TCP, co= nnection establishment provides information about the quality of the connec= tion toward the server. Why not using OPTIONS for UDP? It wouldn't change t= he "SIP state" and wouldn't cause any distraction to end users/devices. >=20 > Dale From nobody Thu Dec 15 11:16:33 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA091296C0 for ; Thu, 15 Dec 2016 11:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 R4xgRJWqC7RL for ; Thu, 15 Dec 2016 11:16:27 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9A7129406 for ; Thu, 15 Dec 2016 11:16:27 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-02v.sys.comcast.net with SMTP id HbVacQ7NpoagNHbVyck2sh; Thu, 15 Dec 2016 19:16:26 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-11v.sys.comcast.net with SMTP id HbVxcp1e247uMHbVyc7zTE; Thu, 15 Dec 2016 19:16:26 +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 uBFJGPrn001243; Thu, 15 Dec 2016 14:16:25 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBFJGOLE001240; Thu, 15 Dec 2016 14:16:24 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 15 Dec 2016 14:16:24 -0500 Message-ID: <87k2b1ovef.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfNOQPwRo0N+bX//+1ieIadsA91saDqUH/6gUIkHnJoZPLD1FI2uhe2wcjXLwdefwlBKL40G/IqSuquzOfxOHXibgyoXLhihs20hV6nztew0QLLmpkB4E m+qO6usXiaqVOsnJ6is33dKLKCj+unrRNVLne6/fbhuJTugfR4qeOUk+SuIvA3ecQphDri9IP5Bcctlct/0tebRXpvbqmvA2cN8= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 19:16:29 -0000 "Asveren, Tolga" writes: >> However, we decided to >> not handle SRV in this tranche because a comprehensive approach to SRV is >> complicated and nobody has yet proposed a solution that promises to meet >> the desiderata, viz.: >> >> - achieve the Happy Eyeballs effect, that is, traffic will be very >> rarely delayed by unreachability of one or more of the targets >> >> - achieve the specified effect of SRV, that is, among the set of targets >> which are reachable, over the long run, the traffic will be >> distributed among them according to the specified priorities and >> weights in the SRV records > [TOLGA] I understand that "perfect outcome" may be hard to describe > -let alone to achieve- especially considering various deployment > models/expectations. OTOH, I would think that allowing some freedom in > terms of ordering could be all what needs to be mentioned in the > specification, e.g. > Rather than: > One ought to use the SRV records according to their weight/priority > where eventually only one of them is the winner and is resolved I'm not sure that "only one of [the SRV records] ... is resolved" is correct. If there are two SRV records and, for the one with the lowest priority value, the address(es) for the target name cannot be contacted, the client is required to attempt to contact the address(es) for the target name of the other SRV record. > This: > One may resolve all/a sub-set of available SRV records by also > considering IP Address Family and IP Address Family can be also > considered for the order of the queries > > I can provide text/edit the document if we can reach a > conclusion/consensus on this point. I suspect that allowing the client unlimited authority to reorder the target addresses based on IP address family will allow behaviors that we do not want to allow. In particular, if the SRV records give one IP address family over the other family, and the client can contact both addresses, we want the client to respect that declared priority. (This is a variation on the example in RFC 7984.) >> > I am not sure >> > what the right interpretation should be here but it is not >> > well-defined to say the least. To me, it seems like RFC7984 should be >> > updating RFC3263 normatively in this aspect as well -to promote the >> > RFC7984 defined behavior-. And IMHO it would be up to the >> > Happy-Eyeballs draft to define how addresses from multiple SRV Records >> > should be used. Cases, where a dual-stack entity does not know whether >> > IPv4/IPv6 is preferred and multiple SRV records are used for different >> > address families on different servers should be covered as well. >> >> Can you give an example where the procedures of RFC 2782 aren't sufficient >> to resolve this problem? > [TOLGA] "Usage Rules" section of RFC2782 seem to imply: > i- A list is prepared by querying all SRV records. Queries are > performed by the priority/weight based ordering. > ii- And then there is "freedom" in terms of selecting the server to > actually use. The freedom allowed by RFC 2782 is limited. Actually, the only variation allowed in the order of contacting the addresses is due to the use of random numbers in selecting between records of the same priority. (section "The format of the SRV RR" item "Weight") > I think i- is where some improvement could be useful in the context of > happy-eyeballs. The IP Address Family can be used as a third parameter > -in addition to priority/weight- when ordering DNS queries. Granted, > one may argue that all queries can be performed in parallel but still > some clarification text in the specification could be a good idea to > highlight this and prevent any confusion. Remember that only one DNS query is needed to obtain *all* the SRV records for a particular domain name and transport. >> The *concept* of Happy Eyeballs can, should, and will be applied to UDP, but >> the *details* are going to be considerably different from the details for TCP. >> For the first tranche, we are attempting to stay near what has been done for >> HTTP, so we are limiting the scope to connection-oriented protocols. > [TOLGA] I think one issue was regarding the "probing" for UDP. With > TCP, connection establishment provides information about the quality > of the connection toward the server. Why not using OPTIONS for UDP? It > wouldn't change the "SIP state" and wouldn't cause any distraction to > end users/devices. Yes, that would work. But as I said, UDP is not included in this tranche. Dale From nobody Thu Dec 15 11:58:10 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282E41295D6 for ; Thu, 15 Dec 2016 11:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 4El4r6dKbotp for ; Thu, 15 Dec 2016 11:58:06 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0068.outbound.protection.outlook.com [104.47.33.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7BE12951B for ; Thu, 15 Dec 2016 11:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qZM0jXAfi8fkML848yUtBk9nRs0Redf4PTlQqvq4n24=; b=Pig4+8Rdf5L09S1CiNSugjL9XbYErD0TpPZh6v158lxFTvYm+73vPjn3aEctz5E7n3K0tZ6X8GhNWDdlydVU/qvv+Z4T4IU77+/bxpTJNTJ2wk0nO2K/wmtMkrSK/lBlKJh4TcBZIKwTuuTrX/4jRTjh02LucDBUZjKH6gXohKg= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Thu, 15 Dec 2016 19:58:04 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.014; Thu, 15 Dec 2016 19:58:04 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSVwe5Rj/FKGerzk2IPpPFNc5xDqEJaukQ Date: Thu, 15 Dec 2016 19:58:03 +0000 Message-ID: References: (tasveren@sonusnet.com) <87k2b1ovef.fsf@hobgoblin.ariadne.com> In-Reply-To: <87k2b1ovef.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 4e5c0465-a9fc-4741-42c7-08d42524ae65 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:8vBHJRP6RJSeZF8n5t8eLRFOWmjve8KdqwXYdvB0nBlUqMZaArjPCBEuaBoraTLzCeg4+310ztMwkXylmlPUUMNE/STf3UKjgBSv94WXSg+l07HB/dCKqqJBMRi60yTUTU4I2QT3/wX0E6uSwxsViNge1WMcjOcrh7zIOgxCvakjzmKqd82qhwUO9XZG3zL3Z3gHtwr4ELPFeUYmXK4Sv9I9KneF8nQxOj91TO26dsCH4tbiL8ye3bij4qIgdXqudgX1NGcRy9Xen2ASndk0MBE8+YgEgxGmdU2cQ6X6kXhbw43W+ZAVvosVm67YhGY6lyZizVuZRxYdWoggEp8t9eWy8ggG4bUo7MuQf5KrGRNguvU72FOVbos1HqL7bJ7/TtpzmKHuu5zNgJohHP3dQ3atm1z1L7eQ+YIdlXS0a26XtD2vfd4OYK0CzxO5k2xgI/OPFeI/YcD/6eyHTBMFbg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39830400002)(39410400002)(39450400003)(199003)(377454003)(13464003)(189002)(86362001)(76176999)(4326007)(54356999)(33656002)(50986999)(66066001)(8676002)(2906002)(97736004)(102836003)(3846002)(6116002)(101416001)(6506006)(229853002)(3660700001)(76576001)(77096006)(8936002)(38730400001)(3280700002)(6436002)(5660300001)(25786008)(68736007)(7696004)(110136003)(122556002)(99286002)(9686002)(81166006)(2900100001)(106116001)(7736002)(305945005)(74316002)(189998001)(105586002)(81156014)(6916009)(106356001)(92566002)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 19:58:03.9113 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 19:58:09 -0000 Trying to summarize: i- It is fine to target connection-oriented transport protocols first but I= hope that does not imply that UDP never will be covered. I personally woul= d favor a single RFC for all transports -initial versions of the draft can = address/focus on connection-oriented ones- but could survive with multiple = specifications as well. ii- I feel stronger about the need to address SRV records rather than limit= ing the solution to A/AAAA. Granted, an entity can do stupid things with th= e freedom of ordering of queries by also considering IP Address Family but = that is a given with any new degree of freedom. It is a direct consequence = thereof. Providing use cases/warnings about possible issues could address t= his concern in a satisfactory way IMHO. Thanks, Tolga > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Thursday, December 15, 2016 2:16 PM > To: Asveren, Tolga > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs for SIP >=20 > "Asveren, Tolga" writes: > >> However, we decided to > >> not handle SRV in this tranche because a comprehensive approach to > >> SRV is complicated and nobody has yet proposed a solution that > >> promises to meet the desiderata, viz.: > >> > >> - achieve the Happy Eyeballs effect, that is, traffic will be very > >> rarely delayed by unreachability of one or more of the targets > >> > >> - achieve the specified effect of SRV, that is, among the set of targe= ts > >> which are reachable, over the long run, the traffic will be > >> distributed among them according to the specified priorities and > >> weights in the SRV records >=20 > > [TOLGA] I understand that "perfect outcome" may be hard to describe > > -let alone to achieve- especially considering various deployment > > models/expectations. OTOH, I would think that allowing some freedom in > > terms of ordering could be all what needs to be mentioned in the > > specification, e.g. >=20 > > Rather than: >=20 > > One ought to use the SRV records according to their weight/priority > > where eventually only one of them is the winner and is resolved >=20 > I'm not sure that "only one of [the SRV records] ... is resolved" is corr= ect. If > there are two SRV records and, for the one with the lowest priority value= , > the address(es) for the target name cannot be contacted, the client is > required to attempt to contact the address(es) for the target name of the > other SRV record. >=20 > > This: >=20 > > One may resolve all/a sub-set of available SRV records by also > > considering IP Address Family and IP Address Family can be also > > considered for the order of the queries > > > > I can provide text/edit the document if we can reach a > > conclusion/consensus on this point. >=20 > I suspect that allowing the client unlimited authority to reorder the tar= get > addresses based on IP address family will allow behaviors that we do not > want to allow. In particular, if the SRV records give one IP address fam= ily > over the other family, and the client can contact both addresses, we want > the client to respect that declared priority. (This is a variation on th= e example > in RFC 7984.) >=20 > >> > I am not sure > >> > what the right interpretation should be here but it is not > >> > well-defined to say the least. To me, it seems like RFC7984 should > >> > be updating RFC3263 normatively in this aspect as well -to promote > >> > the > >> > RFC7984 defined behavior-. And IMHO it would be up to the > >> > Happy-Eyeballs draft to define how addresses from multiple SRV > >> > Records should be used. Cases, where a dual-stack entity does not > >> > know whether > >> > IPv4/IPv6 is preferred and multiple SRV records are used for > >> > different address families on different servers should be covered as > well. > >> > >> Can you give an example where the procedures of RFC 2782 aren't > >> sufficient to resolve this problem? >=20 > > [TOLGA] "Usage Rules" section of RFC2782 seem to imply: >=20 > > i- A list is prepared by querying all SRV records. Queries are > > performed by the priority/weight based ordering. >=20 > > ii- And then there is "freedom" in terms of selecting the server to > > actually use. >=20 > The freedom allowed by RFC 2782 is limited. Actually, the only variation > allowed in the order of contacting the addresses is due to the use of ran= dom > numbers in selecting between records of the same priority. > (section "The format of the SRV RR" item "Weight") >=20 > > I think i- is where some improvement could be useful in the context of > > happy-eyeballs. The IP Address Family can be used as a third parameter > > -in addition to priority/weight- when ordering DNS queries. Granted, > > one may argue that all queries can be performed in parallel but still > > some clarification text in the specification could be a good idea to > > highlight this and prevent any confusion. >=20 > Remember that only one DNS query is needed to obtain *all* the SRV > records for a particular domain name and transport. >=20 > >> The *concept* of Happy Eyeballs can, should, and will be applied to > >> UDP, but the *details* are going to be considerably different from the > details for TCP. > >> For the first tranche, we are attempting to stay near what has been > >> done for HTTP, so we are limiting the scope to connection-oriented > protocols. >=20 > > [TOLGA] I think one issue was regarding the "probing" for UDP. With > > TCP, connection establishment provides information about the quality > > of the connection toward the server. Why not using OPTIONS for UDP? It > > wouldn't change the "SIP state" and wouldn't cause any distraction to > > end users/devices. >=20 > Yes, that would work. But as I said, UDP is not included in this tranche= . >=20 > Dale From nobody Fri Dec 16 00:50:57 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C54A126579 for ; Fri, 16 Dec 2016 00:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 q5wmEMeGFXUL for ; Fri, 16 Dec 2016 00:50:52 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3F7129AF1 for ; Fri, 16 Dec 2016 00:50:51 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 7F23D6C05; Fri, 16 Dec 2016 09:50:43 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 16 Dec 2016 09:50:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:50:55 -0000 > On 15 Dec 2016, at 20:58, Asveren, Tolga = wrote: >=20 > Trying to summarize: >=20 > i- It is fine to target connection-oriented transport protocols first = but I hope that does not imply that UDP never will be covered. I = personally would favor a single RFC for all transports -initial versions = of the draft can address/focus on connection-oriented ones- but could = survive with multiple specifications as well. At the last SIPcore IETF meeting we decided to split up the work in = chewable bits. Separating connection oriented from the much more complex connectionless area was one decision in order to make = progress fast in the Connection oriented space. > ii- I feel stronger about the need to address SRV records rather than = limiting the solution to A/AAAA. Granted, an entity can do stupid things = with the freedom of ordering of queries by also considering IP Address = Family but that is a given with any new degree of freedom. It is a = direct consequence thereof. Providing use cases/warnings about possible = issues could address this concern in a satisfactory way IMHO. If there is a problem, we need to work on it, but I would like to = suggest that we limit the scope for each doc to get it faster through the process. We have a lot of related problems to cover, like selection of interfaces = when we have multiple interfaces. In regards to the current draft for connection-oriented SIP flows, I am = not happy about copying a lot of text from the Happy Eyeballs RFC into = this doc.=20 Happy Eyeballs is a large solution space and the important part of the = RFC is the requirements - the solutions vary.=20 Copying text from that RFC could mean we copy stuff that is out of scope = and already old compared with today=E2=80=99s implementations and=20 that we by accident limit the solution space for SIP, which would be = unfortunate. The SIP solution for setting up a connection is in no=20 way different from other protocols and thus I think we will be better = off and have a smoother path to publication by just pointing to the = Happy Eyeballs RFC than starting to copy parts without us authors having current = implementation experience. Let=E2=80=99s keep the connection-oriented draft short and sweet and = just get it to publication and then dive heads down into UDP. That=E2=80=99s an area where no work has been done before (as far = as I know) and we will propably end up producing an outbound-light or something else.=20 The implementation I work with currently send a simple OPTIONs without = SDP to test both address families and then select based on our preferences and responses. We do = prefer IPv6 in this case, as IPv4 is hiding behind an ugly carrier grade nat. As this is a mobile app, registration = and calls happen within a short time and no=20 flows are kept for long. Desktop phones have flows that goes on for a = very long time and network properties may change during that time, so we need more regular discovery. /O >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: Dale R. Worley [mailto:worley@ariadne.com] >> Sent: Thursday, December 15, 2016 2:16 PM >> To: Asveren, Tolga >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Happy Eyeballs for SIP >>=20 >> "Asveren, Tolga" writes: >>>> However, we decided to >>>> not handle SRV in this tranche because a comprehensive approach to >>>> SRV is complicated and nobody has yet proposed a solution that >>>> promises to meet the desiderata, viz.: >>>>=20 >>>> - achieve the Happy Eyeballs effect, that is, traffic will be very >>>> rarely delayed by unreachability of one or more of the targets >>>>=20 >>>> - achieve the specified effect of SRV, that is, among the set of = targets >>>> which are reachable, over the long run, the traffic will be >>>> distributed among them according to the specified priorities and >>>> weights in the SRV records >>=20 >>> [TOLGA] I understand that "perfect outcome" may be hard to describe >>> -let alone to achieve- especially considering various deployment >>> models/expectations. OTOH, I would think that allowing some freedom = in >>> terms of ordering could be all what needs to be mentioned in the >>> specification, e.g. >>=20 >>> Rather than: >>=20 >>> One ought to use the SRV records according to their weight/priority >>> where eventually only one of them is the winner and is resolved >>=20 >> I'm not sure that "only one of [the SRV records] ... is resolved" is = correct. If >> there are two SRV records and, for the one with the lowest priority = value, >> the address(es) for the target name cannot be contacted, the client = is >> required to attempt to contact the address(es) for the target name of = the >> other SRV record. >>=20 >>> This: >>=20 >>> One may resolve all/a sub-set of available SRV records by also >>> considering IP Address Family and IP Address Family can be also >>> considered for the order of the queries >>>=20 >>> I can provide text/edit the document if we can reach a >>> conclusion/consensus on this point. >>=20 >> I suspect that allowing the client unlimited authority to reorder the = target >> addresses based on IP address family will allow behaviors that we do = not >> want to allow. In particular, if the SRV records give one IP address = family >> over the other family, and the client can contact both addresses, we = want >> the client to respect that declared priority. (This is a variation = on the example >> in RFC 7984.) >>=20 >>>>> I am not sure >>>>> what the right interpretation should be here but it is not >>>>> well-defined to say the least. To me, it seems like RFC7984 should >>>>> be updating RFC3263 normatively in this aspect as well -to promote >>>>> the >>>>> RFC7984 defined behavior-. And IMHO it would be up to the >>>>> Happy-Eyeballs draft to define how addresses from multiple SRV >>>>> Records should be used. Cases, where a dual-stack entity does not >>>>> know whether >>>>> IPv4/IPv6 is preferred and multiple SRV records are used for >>>>> different address families on different servers should be covered = as >> well. >>>>=20 >>>> Can you give an example where the procedures of RFC 2782 aren't >>>> sufficient to resolve this problem? >>=20 >>> [TOLGA] "Usage Rules" section of RFC2782 seem to imply: >>=20 >>> i- A list is prepared by querying all SRV records. Queries are >>> performed by the priority/weight based ordering. >>=20 >>> ii- And then there is "freedom" in terms of selecting the server to >>> actually use. >>=20 >> The freedom allowed by RFC 2782 is limited. Actually, the only = variation >> allowed in the order of contacting the addresses is due to the use of = random >> numbers in selecting between records of the same priority. >> (section "The format of the SRV RR" item "Weight") >>=20 >>> I think i- is where some improvement could be useful in the context = of >>> happy-eyeballs. The IP Address Family can be used as a third = parameter >>> -in addition to priority/weight- when ordering DNS queries. Granted, >>> one may argue that all queries can be performed in parallel but = still >>> some clarification text in the specification could be a good idea to >>> highlight this and prevent any confusion. >>=20 >> Remember that only one DNS query is needed to obtain *all* the SRV >> records for a particular domain name and transport. >>=20 >>>> The *concept* of Happy Eyeballs can, should, and will be applied to >>>> UDP, but the *details* are going to be considerably different from = the >> details for TCP. >>>> For the first tranche, we are attempting to stay near what has been >>>> done for HTTP, so we are limiting the scope to connection-oriented >> protocols. >>=20 >>> [TOLGA] I think one issue was regarding the "probing" for UDP. With >>> TCP, connection establishment provides information about the quality >>> of the connection toward the server. Why not using OPTIONS for UDP? = It >>> wouldn't change the "SIP state" and wouldn't cause any distraction = to >>> end users/devices. >>=20 >> Yes, that would work. But as I said, UDP is not included in this = tranche. >>=20 >> Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Dec 16 05:43:36 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02DA129A4D for ; Fri, 16 Dec 2016 05:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 zbYe31-lMj68 for ; Fri, 16 Dec 2016 05:43:31 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0080.outbound.protection.outlook.com [104.47.33.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAA012988A for ; Fri, 16 Dec 2016 05:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SDn+CrGMgzBnO2L8zkPzK1IIsva4J3n+/ErXolFodIQ=; b=HCfSE5F1YB8x0R3ctdd+cvP9bUfWgvSBxG67VTpNYMRF9ZSDGhTt0eD5V4t03VysugWFwX5C3abK3r2daqBw8Zl59dMKHPrOnFXoqFYJuZfSdmrwPfdecTlFsJ5wcNKwQ7nmHLHQqG4jZg2eREvtcoIJ+ckYMG4GutQwbDTsr60= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Fri, 16 Dec 2016 13:43:28 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.014; Fri, 16 Dec 2016 13:43:28 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSVwe5Rj/FKGerzk2IPpPFNc5xDqEJaukQgADZ/gCAADHpcA== Date: Fri, 16 Dec 2016 13:43:28 +0000 Message-ID: References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> In-Reply-To: <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 165c0c6f-fb3c-41d6-324a-08d425b98487 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:Ty0p7yJidcRQvUn0nUx9ey0XjDP/UCIQ41fvj805Tb31DkmOoQWQk0m/z4DjlhlqxgZZRWbDmxs6o2fVdrrkm5Y9727i7fbsZBvslX2WYmKahkUFssC2mJ0dBoVIQ3bixkZMS6w5DloroD3SQXJNotoaBDJVfxYBDuaqjO2uoBDFKskHi455uBGw0r0wpq2Tm84YB5zQMkir+XOzop06+93rKN7mH4ZT+KNZ7lyWb19UEZ1N776yU69FK5eNHBsjZZJdTbKZ6o6jWRL3mz3THGKHrtuyg/ultJ5lFMG4MuSyAjtGBAb5P/4PgHy7/15TfY2HCRiqN+8517UWLXk7+ybkWgx5g3ga7jhh35epOXOjRjPqJGw9VkFs72VHJK7+4Sm7Xf5GPnoueJDxNIhSbIKH8VOVO91McVCZ5Jo5EgyCLxtIaeic+2p69aSJ9V28BGrC1Uszlb5Nggl72XyvVg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(6047074)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39830400002)(39410400002)(39450400003)(189002)(13464003)(24454002)(377454003)(199003)(2906002)(76176999)(305945005)(92566002)(2900100001)(5660300001)(229853002)(189998001)(3846002)(54356999)(97736004)(81156014)(8936002)(8676002)(81166006)(4326007)(38730400001)(6916009)(77096006)(7696004)(6506006)(9686002)(68736007)(2950100002)(25786008)(110136003)(6436002)(74316002)(105586002)(106356001)(93886004)(6116002)(86362001)(106116001)(50986999)(122556002)(101416001)(7736002)(102836003)(76576001)(3280700002)(99286002)(3660700001)(33656002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 13:43:28.5740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:43:35 -0000 SW5saW5lLi4uDQoNClRoYW5rcywNClRvbGdhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogT2xsZSBFLiBKb2hhbnNzb24gW21haWx0bzpvZWpAZWR2aW5hLm5ldF0NCj4g U2VudDogRnJpZGF5LCBEZWNlbWJlciAxNiwgMjAxNiAzOjUxIEFNDQo+IFRvOiBBc3ZlcmVuLCBU b2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KPiBDYzogT2xsZSBFIEpvaGFuc3NvbiA8b2Vq QGVkdmluYS5uZXQ+OyBEYWxlIFIuIFdvcmxleQ0KPiA8d29ybGV5QGFyaWFkbmUuY29tPjsgc2lw Y29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEhhcHB5IEV5ZWJhbGxzIGZv ciBTSVANCj4gDQo+IA0KPiA+IE9uIDE1IERlYyAyMDE2LCBhdCAyMDo1OCwgQXN2ZXJlbiwgVG9s Z2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPiBUcnlpbmcgdG8g c3VtbWFyaXplOg0KPiA+DQo+ID4gaS0gSXQgaXMgZmluZSB0byB0YXJnZXQgY29ubmVjdGlvbi1v cmllbnRlZCB0cmFuc3BvcnQgcHJvdG9jb2xzIGZpcnN0IGJ1dCBJIGhvcGUNCj4gdGhhdCBkb2Vz IG5vdCBpbXBseSB0aGF0IFVEUCBuZXZlciB3aWxsIGJlIGNvdmVyZWQuIEkgcGVyc29uYWxseSB3 b3VsZCBmYXZvcg0KPiBhIHNpbmdsZSBSRkMgZm9yIGFsbCB0cmFuc3BvcnRzIC1pbml0aWFsIHZl cnNpb25zIG9mIHRoZSBkcmFmdCBjYW4gYWRkcmVzcy9mb2N1cw0KPiBvbiBjb25uZWN0aW9uLW9y aWVudGVkIG9uZXMtIGJ1dCBjb3VsZCBzdXJ2aXZlIHdpdGggbXVsdGlwbGUgc3BlY2lmaWNhdGlv bnMNCj4gYXMgd2VsbC4NCj4gQXQgdGhlIGxhc3QgU0lQY29yZSBJRVRGIG1lZXRpbmcgd2UgZGVj aWRlZCB0byBzcGxpdCB1cCB0aGUgd29yayBpbiBjaGV3YWJsZQ0KPiBiaXRzLiBTZXBhcmF0aW5n IGNvbm5lY3Rpb24gb3JpZW50ZWQgZnJvbSB0aGUgbXVjaCBtb3JlIGNvbXBsZXgNCj4gY29ubmVj dGlvbmxlc3MgYXJlYSB3YXMgb25lIGRlY2lzaW9uIGluIG9yZGVyIHRvIG1ha2UgcHJvZ3Jlc3Mg ZmFzdCBpbiB0aGUNCj4gQ29ubmVjdGlvbiBvcmllbnRlZCBzcGFjZS4NCltUT0xHQV0gVW5kZXJz dG9vZC4gQXMgc2FpZCBiZWZvcmUgdGhvdWdoLCB0aGlzIGNvdWxkIGJlIGFjaGlldmVkIHdpdGgg YSBzaW5nbGUgUkZDL3Byb2dyZXNzaXZlIHZlcnNpb25zIG9mIGRyYWZ0cyBhcyB3ZWxsIElNSE8u IE9UT0gsIEkgd291bGRu4oCZdCBjcnkgbXVjaCBvdmVyIGhhdmluZyBtdWx0aXBsZSBSRkNzIGVp dGhlci4gIFNvLCBJIGd1ZXNzIHRoaXMgbWVhbnMgImNvbnNlbnN1cyByZWFjaGVkIi4NCj4gDQo+ IA0KPiA+IGlpLSBJIGZlZWwgc3Ryb25nZXIgYWJvdXQgdGhlIG5lZWQgdG8gYWRkcmVzcyBTUlYg cmVjb3JkcyByYXRoZXIgdGhhbg0KPiBsaW1pdGluZyB0aGUgc29sdXRpb24gdG8gQS9BQUFBLiBH cmFudGVkLCBhbiBlbnRpdHkgY2FuIGRvIHN0dXBpZCB0aGluZ3Mgd2l0aA0KPiB0aGUgZnJlZWRv bSBvZiBvcmRlcmluZyBvZiBxdWVyaWVzIGJ5IGFsc28gY29uc2lkZXJpbmcgSVAgQWRkcmVzcyBG YW1pbHkgYnV0DQo+IHRoYXQgaXMgYSBnaXZlbiB3aXRoIGFueSBuZXcgZGVncmVlIG9mIGZyZWVk b20uIEl0IGlzIGEgZGlyZWN0IGNvbnNlcXVlbmNlDQo+IHRoZXJlb2YuIFByb3ZpZGluZyB1c2Ug Y2FzZXMvd2FybmluZ3MgYWJvdXQgcG9zc2libGUgaXNzdWVzIGNvdWxkIGFkZHJlc3MNCj4gdGhp cyBjb25jZXJuIGluIGEgc2F0aXNmYWN0b3J5IHdheSBJTUhPLg0KPiBJZiB0aGVyZSBpcyBhIHBy b2JsZW0sIHdlIG5lZWQgdG8gd29yayBvbiBpdCwgYnV0IEkgd291bGQgbGlrZSB0byBzdWdnZXN0 IHRoYXQNCj4gd2UgbGltaXQgdGhlIHNjb3BlIGZvciBlYWNoIGRvYyB0byBnZXQgaXQgZmFzdGVy IHRocm91Z2ggdGhlIHByb2Nlc3MuDQo+IA0KPiBXZSBoYXZlIGEgbG90IG9mIHJlbGF0ZWQgcHJv YmxlbXMgdG8gY292ZXIsIGxpa2Ugc2VsZWN0aW9uIG9mIGludGVyZmFjZXMgd2hlbg0KPiB3ZSBo YXZlIG11bHRpcGxlIGludGVyZmFjZXMuDQpbVE9MR0FdIEkgdGhpbmsgY292ZXJpbmcgU1JWIHJl Y29yZHMgaXMgY3JpdGljYWwuIFRoZXkgYXJlIHVzZWQgd2lkZWx5IGluIHByYWN0aWNlOyBmb3Ig dmFyaW91cyByZWFzb25zIGFuZCBpbiBkaWZmZXJlbnQgbW9kZWxzLiBJIGRvbuKAmXQgdGhpbmsg YnVyeWluZyBvdXIgaGVhZCBpbnRvIHNhbmQgd291bGQgbWFrZSB0aGlzIGlzc3VlIGRpc2FwcGVh ci4gV2UgbWF5IHRha2UgYSAicHJhY3RpY2FsIiBhcHByb2FjaCB0aG91Z2guIEkgdGhpbmsgOTAl IG9mIHV0aWxpdHkgY291bGQgYmUgYWNoaWV2ZWQgYnkgYWRkcmVzc2luZyAxMCUgb2YgY29tcGxl eGl0eS4gU29tZSBleHRyYSBmcmVlZG9tIG9uIG9yZGVyaW5nL3NlbGVjdGlvbiBvZiBxdWVyaWVz IHdvdWxkIGdvIGEgbG9uZyB3YXkuDQpJbiBnZW5lcmFsLCBJIGFtIGFsc28gYmFmZmxlZCB3aHkg cGxhdGZvcm0gcmVsYXRlZCBpc3N1ZXMsIGUuZy4gaW50ZXJmYWNlIHNlbGVjdGlvbiwgaXMgc29t ZXRoaW5nIHRvIGJlIGRlZmluZWQgaW4gYSBTSVAgcmVsYXRlZCBSRkMuIEdyYW50ZWQsIGEgc29s dXRpb24gc2hvdWxkIGJlIGltcGxlbWVudGFibGUgYnV0IGRlZmluaW5nIGhvdyB0byBzZWxlY3Qg dGhlIHJpZ2h0IGludGVyZmFjZSwgZS5nLiB3aGljaCBzeXN0ZW0gY2FsbCBmb3IgYSBwYXJ0aWN1 bGFyIE9TLCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhpcyBSRkMuIFNwZWNpZmljYXRpb24gY2FuIHRh bGsgYWJvdXQgdGhlIG5lZWQgcGFja2V0cyB0YWtpbmcgdGhlIGNvcnJlY3QvaW50ZW5kZWQgcGF0 aCBidXQgaG93IHRoaXMgaXMgYWNoaWV2ZWQgb24gYSBnaXZlbiBwbGF0Zm9ybSBpcyBhbiBpbXBs ZW1lbnRhdGlvbiBpc3N1ZSBJTUhPLiBCdXQgdGhlbiwgbWF5YmUgdGhlIGZvcm1lciBpcyBhbHJl YWR5IHdoYXQgeW91IG1lYW50Lg0KPiANCj4gSW4gcmVnYXJkcyB0byB0aGUgY3VycmVudCBkcmFm dCBmb3IgY29ubmVjdGlvbi1vcmllbnRlZCBTSVAgZmxvd3MsIEkgYW0gbm90DQo+IGhhcHB5IGFi b3V0IGNvcHlpbmcgYSBsb3Qgb2YgdGV4dCBmcm9tIHRoZSBIYXBweSBFeWViYWxscyBSRkMgaW50 byB0aGlzIGRvYy4NCj4gDQo+IEhhcHB5IEV5ZWJhbGxzIGlzIGEgIGxhcmdlIHNvbHV0aW9uIHNw YWNlIGFuZCB0aGUgaW1wb3J0YW50IHBhcnQgb2YgdGhlIFJGQyBpcw0KPiB0aGUgcmVxdWlyZW1l bnRzIC0gdGhlIHNvbHV0aW9ucyB2YXJ5Lg0KPiBDb3B5aW5nIHRleHQgZnJvbSB0aGF0IFJGQyBj b3VsZCBtZWFuIHdlIGNvcHkgc3R1ZmYgdGhhdCBpcyBvdXQgb2Ygc2NvcGUgYW5kDQo+IGFscmVh ZHkgb2xkIGNvbXBhcmVkIHdpdGggdG9kYXnigJlzIGltcGxlbWVudGF0aW9ucyBhbmQgdGhhdCB3 ZSBieSBhY2NpZGVudA0KPiBsaW1pdCB0aGUgc29sdXRpb24gc3BhY2UgZm9yIFNJUCwgd2hpY2gg d291bGQgYmUgdW5mb3J0dW5hdGUuIFRoZSBTSVAgc29sdXRpb24NCj4gZm9yIHNldHRpbmcgdXAg YSBjb25uZWN0aW9uIGlzIGluIG5vIHdheSBkaWZmZXJlbnQgZnJvbSBvdGhlciBwcm90b2NvbHMg YW5kDQo+IHRodXMgSSB0aGluayB3ZSB3aWxsIGJlIGJldHRlciBvZmYgYW5kIGhhdmUgYSBzbW9v dGhlciBwYXRoIHRvIHB1YmxpY2F0aW9uIGJ5DQo+IGp1c3QgcG9pbnRpbmcgdG8gdGhlIEhhcHB5 IEV5ZWJhbGxzIFJGQyB0aGFuIHN0YXJ0aW5nIHRvIGNvcHkgcGFydHMgd2l0aG91dCB1cw0KPiBh dXRob3JzIGhhdmluZyBjdXJyZW50IGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2UuDQo+IA0KPiBM ZXTigJlzIGtlZXAgdGhlIGNvbm5lY3Rpb24tb3JpZW50ZWQgZHJhZnQgc2hvcnQgYW5kIHN3ZWV0 IGFuZCBqdXN0IGdldCBpdCB0bw0KPiBwdWJsaWNhdGlvbiBhbmQgdGhlbiBkaXZlIGhlYWRzIGRv d24gaW50byBVRFAuIFRoYXTigJlzIGFuIGFyZWEgd2hlcmUgbm8NCj4gd29yayBoYXMgYmVlbiBk b25lIGJlZm9yZSAoYXMgZmFyIGFzIEkga25vdykgYW5kIHdlIHdpbGwgcHJvcGFibHkgZW5kIHVw DQo+IHByb2R1Y2luZyBhbiBvdXRib3VuZC1saWdodCBvciBzb21ldGhpbmcgZWxzZS4NCltUT0xH QV0gTWF5YmUsIEkgYW0gbm90IGFzIG9wdGltaXN0aWMgYXMgeW91IHRob3VnaCAoZXNwZWNpYWxs eSB3aGVuIGNvbnNpZGVyaW5nIHVzZSBvZiBEVExTKQ0KPiANCj4gVGhlIGltcGxlbWVudGF0aW9u IEkgd29yayB3aXRoIGN1cnJlbnRseSBzZW5kIGEgc2ltcGxlIE9QVElPTnMgd2l0aG91dA0KPiBT RFAgdG8gdGVzdCBib3RoIGFkZHJlc3MgZmFtaWxpZXMgYW5kIHRoZW4gc2VsZWN0IGJhc2VkIG9u IG91ciBwcmVmZXJlbmNlcw0KPiBhbmQgcmVzcG9uc2VzLiBXZSBkbyBwcmVmZXIgSVB2NiBpbiB0 aGlzIGNhc2UsIGFzIElQdjQgaXMgaGlkaW5nIGJlaGluZCBhbiB1Z2x5DQo+IGNhcnJpZXIgZ3Jh ZGUgbmF0LiBBcyB0aGlzIGlzIGEgbW9iaWxlIGFwcCwgcmVnaXN0cmF0aW9uIGFuZCBjYWxscyBo YXBwZW4gd2l0aGluDQo+IGEgc2hvcnQgdGltZSBhbmQgbm8gZmxvd3MgYXJlIGtlcHQgZm9yIGxv bmcuIERlc2t0b3AgcGhvbmVzIGhhdmUgZmxvd3MgdGhhdA0KPiBnb2VzIG9uIGZvciBhIHZlcnkg bG9uZyB0aW1lIGFuZCBuZXR3b3JrIHByb3BlcnRpZXMgbWF5IGNoYW5nZSBkdXJpbmcgdGhhdA0K PiB0aW1lLCBzbyB3ZSBuZWVkIG1vcmUgcmVndWxhciBkaXNjb3ZlcnkuDQpbVE9MR0FdIFNwZWNp ZmljYXRpb24gZm9yIFVEUCB3b3VsZCBtZW50aW9uIGFib3V0IHVzZSBvZiBPUFRJT05TIGFuZCBt YXliZSBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0IHNvbWUgdXNlIGNhc2VzIGJ1dCB0aGUgZXhh Y3Qgc2VtYW50aWNzIG9mIHdoYXQvaG93IGlzIHByZWZlcnJlZCBzaG91bGRu4oCZdCBiZSBub3Jt YXRpdmVseSBkZWZpbmVkLg0KPiANCj4gDQo+IC9PDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gVG9s Z2ENCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBEYWxl IFIuIFdvcmxleSBbbWFpbHRvOndvcmxleUBhcmlhZG5lLmNvbV0NCj4gPj4gU2VudDogVGh1cnNk YXksIERlY2VtYmVyIDE1LCAyMDE2IDI6MTYgUE0NCj4gPj4gVG86IEFzdmVyZW4sIFRvbGdhIDx0 YXN2ZXJlbkBzb251c25ldC5jb20+DQo+ID4+IENjOiBzaXBjb3JlQGlldGYub3JnDQo+ID4+IFN1 YmplY3Q6IFJlOiBbc2lwY29yZV0gSGFwcHkgRXllYmFsbHMgZm9yIFNJUA0KPiA+Pg0KPiA+PiAi QXN2ZXJlbiwgVG9sZ2EiIDx0YXN2ZXJlbkBzb251c25ldC5jb20+IHdyaXRlczoNCj4gPj4+PiBI b3dldmVyLCB3ZSBkZWNpZGVkIHRvDQo+ID4+Pj4gbm90IGhhbmRsZSBTUlYgaW4gdGhpcyB0cmFu Y2hlIGJlY2F1c2UgYSBjb21wcmVoZW5zaXZlIGFwcHJvYWNoIHRvDQo+ID4+Pj4gU1JWIGlzIGNv bXBsaWNhdGVkIGFuZCBub2JvZHkgaGFzIHlldCBwcm9wb3NlZCBhIHNvbHV0aW9uIHRoYXQNCj4g Pj4+PiBwcm9taXNlcyB0byBtZWV0IHRoZSBkZXNpZGVyYXRhLCB2aXouOg0KPiA+Pj4+DQo+ID4+ Pj4gLSBhY2hpZXZlIHRoZSBIYXBweSBFeWViYWxscyBlZmZlY3QsIHRoYXQgaXMsIHRyYWZmaWMg d2lsbCBiZSB2ZXJ5DQo+ID4+Pj4gIHJhcmVseSBkZWxheWVkIGJ5IHVucmVhY2hhYmlsaXR5IG9m IG9uZSBvciBtb3JlIG9mIHRoZSB0YXJnZXRzDQo+ID4+Pj4NCj4gPj4+PiAtIGFjaGlldmUgdGhl IHNwZWNpZmllZCBlZmZlY3Qgb2YgU1JWLCB0aGF0IGlzLCBhbW9uZyB0aGUgc2V0IG9mIHRhcmdl dHMNCj4gPj4+PiAgd2hpY2ggYXJlIHJlYWNoYWJsZSwgb3ZlciB0aGUgbG9uZyBydW4sIHRoZSB0 cmFmZmljIHdpbGwgYmUNCj4gPj4+PiAgZGlzdHJpYnV0ZWQgYW1vbmcgdGhlbSBhY2NvcmRpbmcg dG8gdGhlIHNwZWNpZmllZCBwcmlvcml0aWVzIGFuZA0KPiA+Pj4+ICB3ZWlnaHRzIGluIHRoZSBT UlYgcmVjb3Jkcw0KPiA+Pg0KPiA+Pj4gW1RPTEdBXSBJIHVuZGVyc3RhbmQgdGhhdCAicGVyZmVj dCBvdXRjb21lIiBtYXkgYmUgaGFyZCB0byBkZXNjcmliZQ0KPiA+Pj4gLWxldCBhbG9uZSB0byBh Y2hpZXZlLSBlc3BlY2lhbGx5IGNvbnNpZGVyaW5nIHZhcmlvdXMgZGVwbG95bWVudA0KPiA+Pj4g bW9kZWxzL2V4cGVjdGF0aW9ucy4gT1RPSCwgSSB3b3VsZCB0aGluayB0aGF0IGFsbG93aW5nIHNv bWUgZnJlZWRvbQ0KPiBpbg0KPiA+Pj4gdGVybXMgb2Ygb3JkZXJpbmcgY291bGQgYmUgYWxsIHdo YXQgbmVlZHMgdG8gYmUgbWVudGlvbmVkIGluIHRoZQ0KPiA+Pj4gc3BlY2lmaWNhdGlvbiwgZS5n Lg0KPiA+Pg0KPiA+Pj4gUmF0aGVyIHRoYW46DQo+ID4+DQo+ID4+PiBPbmUgb3VnaHQgdG8gdXNl IHRoZSBTUlYgcmVjb3JkcyBhY2NvcmRpbmcgdG8gdGhlaXIgd2VpZ2h0L3ByaW9yaXR5DQo+ID4+ PiB3aGVyZSBldmVudHVhbGx5IG9ubHkgb25lIG9mIHRoZW0gaXMgdGhlIHdpbm5lciBhbmQgaXMg cmVzb2x2ZWQNCj4gPj4NCj4gPj4gSSdtIG5vdCBzdXJlIHRoYXQgIm9ubHkgb25lIG9mIFt0aGUg U1JWIHJlY29yZHNdIC4uLiBpcyByZXNvbHZlZCIgaXMgY29ycmVjdC4NCj4gSWYNCj4gPj4gdGhl cmUgYXJlIHR3byBTUlYgcmVjb3JkcyBhbmQsIGZvciB0aGUgb25lIHdpdGggdGhlIGxvd2VzdCBw cmlvcml0eSB2YWx1ZSwNCj4gPj4gdGhlIGFkZHJlc3MoZXMpIGZvciB0aGUgdGFyZ2V0IG5hbWUg Y2Fubm90IGJlIGNvbnRhY3RlZCwgdGhlIGNsaWVudCBpcw0KPiA+PiByZXF1aXJlZCB0byBhdHRl bXB0IHRvIGNvbnRhY3QgdGhlIGFkZHJlc3MoZXMpIGZvciB0aGUgdGFyZ2V0IG5hbWUgb2YgdGhl DQo+ID4+IG90aGVyIFNSViByZWNvcmQuDQo+ID4+DQo+ID4+PiBUaGlzOg0KPiA+Pg0KPiA+Pj4g T25lIG1heSByZXNvbHZlIGFsbC9hIHN1Yi1zZXQgb2YgYXZhaWxhYmxlIFNSViByZWNvcmRzIGJ5 IGFsc28NCj4gPj4+IGNvbnNpZGVyaW5nIElQIEFkZHJlc3MgRmFtaWx5IGFuZCBJUCBBZGRyZXNz IEZhbWlseSBjYW4gYmUgYWxzbw0KPiA+Pj4gY29uc2lkZXJlZCBmb3IgdGhlIG9yZGVyIG9mIHRo ZSBxdWVyaWVzDQo+ID4+Pg0KPiA+Pj4gSSBjYW4gcHJvdmlkZSB0ZXh0L2VkaXQgdGhlIGRvY3Vt ZW50IGlmIHdlIGNhbiByZWFjaCBhDQo+ID4+PiBjb25jbHVzaW9uL2NvbnNlbnN1cyBvbiB0aGlz IHBvaW50Lg0KPiA+Pg0KPiA+PiBJIHN1c3BlY3QgdGhhdCBhbGxvd2luZyB0aGUgY2xpZW50IHVu bGltaXRlZCBhdXRob3JpdHkgdG8gcmVvcmRlciB0aGUgdGFyZ2V0DQo+ID4+IGFkZHJlc3NlcyBi YXNlZCBvbiBJUCBhZGRyZXNzIGZhbWlseSB3aWxsIGFsbG93IGJlaGF2aW9ycyB0aGF0IHdlIGRv IG5vdA0KPiA+PiB3YW50IHRvIGFsbG93LiAgSW4gcGFydGljdWxhciwgaWYgdGhlIFNSViByZWNv cmRzIGdpdmUgb25lIElQIGFkZHJlc3MgZmFtaWx5DQo+ID4+IG92ZXIgdGhlIG90aGVyIGZhbWls eSwgYW5kIHRoZSBjbGllbnQgY2FuIGNvbnRhY3QgYm90aCBhZGRyZXNzZXMsIHdlIHdhbnQNCj4g Pj4gdGhlIGNsaWVudCB0byByZXNwZWN0IHRoYXQgZGVjbGFyZWQgcHJpb3JpdHkuICAoVGhpcyBp cyBhIHZhcmlhdGlvbiBvbiB0aGUNCj4gZXhhbXBsZQ0KPiA+PiBpbiBSRkMgNzk4NC4pDQo+ID4+ DQo+ID4+Pj4+IEkgYW0gbm90IHN1cmUNCj4gPj4+Pj4gd2hhdCB0aGUgcmlnaHQgaW50ZXJwcmV0 YXRpb24gc2hvdWxkIGJlIGhlcmUgYnV0IGl0IGlzIG5vdA0KPiA+Pj4+PiB3ZWxsLWRlZmluZWQg dG8gc2F5IHRoZSBsZWFzdC4gVG8gbWUsIGl0IHNlZW1zIGxpa2UgUkZDNzk4NCBzaG91bGQNCj4g Pj4+Pj4gYmUgdXBkYXRpbmcgUkZDMzI2MyBub3JtYXRpdmVseSBpbiB0aGlzIGFzcGVjdCBhcyB3 ZWxsIC10byBwcm9tb3RlDQo+ID4+Pj4+IHRoZQ0KPiA+Pj4+PiBSRkM3OTg0IGRlZmluZWQgYmVo YXZpb3ItLiBBbmQgSU1ITyBpdCB3b3VsZCBiZSB1cCB0byB0aGUNCj4gPj4+Pj4gSGFwcHktRXll YmFsbHMgZHJhZnQgdG8gZGVmaW5lIGhvdyBhZGRyZXNzZXMgZnJvbSBtdWx0aXBsZSBTUlYNCj4g Pj4+Pj4gUmVjb3JkcyBzaG91bGQgYmUgdXNlZC4gQ2FzZXMsIHdoZXJlIGEgZHVhbC1zdGFjayBl bnRpdHkgZG9lcyBub3QNCj4gPj4+Pj4ga25vdyB3aGV0aGVyDQo+ID4+Pj4+IElQdjQvSVB2NiBp cyBwcmVmZXJyZWQgYW5kIG11bHRpcGxlIFNSViByZWNvcmRzIGFyZSB1c2VkIGZvcg0KPiA+Pj4+ PiBkaWZmZXJlbnQgYWRkcmVzcyBmYW1pbGllcyBvbiBkaWZmZXJlbnQgc2VydmVycyBzaG91bGQg YmUgY292ZXJlZCBhcw0KPiA+PiB3ZWxsLg0KPiA+Pj4+DQo+ID4+Pj4gQ2FuIHlvdSBnaXZlIGFu IGV4YW1wbGUgd2hlcmUgdGhlIHByb2NlZHVyZXMgb2YgUkZDIDI3ODIgYXJlbid0DQo+ID4+Pj4g c3VmZmljaWVudCB0byByZXNvbHZlIHRoaXMgcHJvYmxlbT8NCj4gPj4NCj4gPj4+IFtUT0xHQV0g ICJVc2FnZSBSdWxlcyIgc2VjdGlvbiBvZiBSRkMyNzgyIHNlZW0gdG8gaW1wbHk6DQo+ID4+DQo+ ID4+PiBpLSBBIGxpc3QgaXMgcHJlcGFyZWQgYnkgcXVlcnlpbmcgYWxsIFNSViByZWNvcmRzLiBR dWVyaWVzIGFyZQ0KPiA+Pj4gcGVyZm9ybWVkIGJ5IHRoZSBwcmlvcml0eS93ZWlnaHQgYmFzZWQg b3JkZXJpbmcuDQo+ID4+DQo+ID4+PiBpaS0gQW5kIHRoZW4gdGhlcmUgaXMgImZyZWVkb20iIGlu IHRlcm1zIG9mIHNlbGVjdGluZyB0aGUgc2VydmVyIHRvDQo+ID4+PiBhY3R1YWxseSB1c2UuDQo+ ID4+DQo+ID4+IFRoZSBmcmVlZG9tIGFsbG93ZWQgYnkgUkZDIDI3ODIgaXMgbGltaXRlZC4gIEFj dHVhbGx5LCB0aGUgb25seSB2YXJpYXRpb24NCj4gPj4gYWxsb3dlZCBpbiB0aGUgb3JkZXIgb2Yg Y29udGFjdGluZyB0aGUgYWRkcmVzc2VzIGlzIGR1ZSB0byB0aGUgdXNlIG9mDQo+IHJhbmRvbQ0K PiA+PiBudW1iZXJzIGluIHNlbGVjdGluZyBiZXR3ZWVuIHJlY29yZHMgb2YgdGhlIHNhbWUgcHJp b3JpdHkuDQo+ID4+IChzZWN0aW9uICJUaGUgZm9ybWF0IG9mIHRoZSBTUlYgUlIiIGl0ZW0gIldl aWdodCIpDQo+ID4+DQo+ID4+PiBJIHRoaW5rIGktIGlzIHdoZXJlIHNvbWUgaW1wcm92ZW1lbnQg Y291bGQgYmUgdXNlZnVsIGluIHRoZSBjb250ZXh0IG9mDQo+ID4+PiBoYXBweS1leWViYWxscy4g VGhlIElQIEFkZHJlc3MgRmFtaWx5IGNhbiBiZSB1c2VkIGFzIGEgdGhpcmQgcGFyYW1ldGVyDQo+ ID4+PiAtaW4gYWRkaXRpb24gdG8gcHJpb3JpdHkvd2VpZ2h0LSB3aGVuIG9yZGVyaW5nIEROUyBx dWVyaWVzLiBHcmFudGVkLA0KPiA+Pj4gb25lIG1heSBhcmd1ZSB0aGF0IGFsbCBxdWVyaWVzIGNh biBiZSBwZXJmb3JtZWQgaW4gcGFyYWxsZWwgYnV0IHN0aWxsDQo+ID4+PiBzb21lIGNsYXJpZmlj YXRpb24gdGV4dCBpbiB0aGUgc3BlY2lmaWNhdGlvbiBjb3VsZCBiZSBhIGdvb2QgaWRlYSB0bw0K PiA+Pj4gaGlnaGxpZ2h0IHRoaXMgYW5kIHByZXZlbnQgYW55IGNvbmZ1c2lvbi4NCj4gPj4NCj4g Pj4gUmVtZW1iZXIgdGhhdCBvbmx5IG9uZSBETlMgcXVlcnkgaXMgbmVlZGVkIHRvIG9idGFpbiAq YWxsKiB0aGUgU1JWDQo+ID4+IHJlY29yZHMgZm9yIGEgcGFydGljdWxhciBkb21haW4gbmFtZSBh bmQgdHJhbnNwb3J0Lg0KPiA+Pg0KPiA+Pj4+IFRoZSAqY29uY2VwdCogb2YgSGFwcHkgRXllYmFs bHMgY2FuLCBzaG91bGQsIGFuZCB3aWxsIGJlIGFwcGxpZWQgdG8NCj4gPj4+PiBVRFAsIGJ1dCB0 aGUgKmRldGFpbHMqIGFyZSBnb2luZyB0byBiZSBjb25zaWRlcmFibHkgZGlmZmVyZW50IGZyb20g dGhlDQo+ID4+IGRldGFpbHMgZm9yIFRDUC4NCj4gPj4+PiBGb3IgdGhlIGZpcnN0IHRyYW5jaGUs IHdlIGFyZSBhdHRlbXB0aW5nIHRvIHN0YXkgbmVhciB3aGF0IGhhcyBiZWVuDQo+ID4+Pj4gZG9u ZSBmb3IgSFRUUCwgc28gd2UgYXJlIGxpbWl0aW5nIHRoZSBzY29wZSB0byBjb25uZWN0aW9uLW9y aWVudGVkDQo+ID4+IHByb3RvY29scy4NCj4gPj4NCj4gPj4+IFtUT0xHQV0gSSB0aGluayBvbmUg aXNzdWUgd2FzIHJlZ2FyZGluZyB0aGUgInByb2JpbmciIGZvciBVRFAuIFdpdGgNCj4gPj4+IFRD UCwgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHByb3ZpZGVzIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBxdWFsaXR5DQo+ID4+PiBvZiB0aGUgY29ubmVjdGlvbiB0b3dhcmQgdGhlIHNlcnZlci4gV2h5 IG5vdCB1c2luZyBPUFRJT05TIGZvciBVRFA/DQo+IEl0DQo+ID4+PiB3b3VsZG4ndCBjaGFuZ2Ug dGhlICJTSVAgc3RhdGUiIGFuZCB3b3VsZG4ndCBjYXVzZSBhbnkgZGlzdHJhY3Rpb24gdG8NCj4g Pj4+IGVuZCB1c2Vycy9kZXZpY2VzLg0KPiA+Pg0KPiA+PiBZZXMsIHRoYXQgd291bGQgd29yay4g IEJ1dCBhcyBJIHNhaWQsIFVEUCBpcyBub3QgaW5jbHVkZWQgaW4gdGhpcyB0cmFuY2hlLg0KPiA+ Pg0KPiA+PiBEYWxlDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gc2lwY29yZUBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K DQo= From nobody Fri Dec 16 05:49:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72794129CED for ; Fri, 16 Dec 2016 05:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1xEvZdP7uzwl for ; Fri, 16 Dec 2016 05:49:18 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1B6129A49 for ; Fri, 16 Dec 2016 05:49:14 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 4CE7C6C07; Fri, 16 Dec 2016 14:48:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 16 Dec 2016 14:48:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:49:21 -0000 > On 16 Dec 2016, at 14:43, Asveren, Tolga = wrote: >=20 > Inline... >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: Olle E. Johansson [mailto:oej@edvina.net] >> Sent: Friday, December 16, 2016 3:51 AM >> To: Asveren, Tolga >> Cc: Olle E Johansson ; Dale R. Worley >> ; sipcore@ietf.org >> Subject: Re: [sipcore] Happy Eyeballs for SIP >>=20 >>=20 >>> On 15 Dec 2016, at 20:58, Asveren, Tolga >> wrote: >>>=20 >>> Trying to summarize: >>>=20 >>> i- It is fine to target connection-oriented transport protocols = first but I hope >> that does not imply that UDP never will be covered. I personally = would favor >> a single RFC for all transports -initial versions of the draft can = address/focus >> on connection-oriented ones- but could survive with multiple = specifications >> as well. >> At the last SIPcore IETF meeting we decided to split up the work in = chewable >> bits. Separating connection oriented from the much more complex >> connectionless area was one decision in order to make progress fast = in the >> Connection oriented space. > [TOLGA] Understood. As said before though, this could be achieved with = a single RFC/progressive versions of drafts as well IMHO. OTOH, I = wouldn=E2=80=99t cry much over having multiple RFCs either. So, I guess = this means "consensus reached=E2=80=9D. :-) >>=20 >>=20 >>> ii- I feel stronger about the need to address SRV records rather = than >> limiting the solution to A/AAAA. Granted, an entity can do stupid = things with >> the freedom of ordering of queries by also considering IP Address = Family but >> that is a given with any new degree of freedom. It is a direct = consequence >> thereof. Providing use cases/warnings about possible issues could = address >> this concern in a satisfactory way IMHO. >> If there is a problem, we need to work on it, but I would like to = suggest that >> we limit the scope for each doc to get it faster through the process. >>=20 >> We have a lot of related problems to cover, like selection of = interfaces when >> we have multiple interfaces. > [TOLGA] I think covering SRV records is critical. They are used widely = in practice; for various reasons and in different models. I don=E2=80=99t = think burying our head into sand would make this issue disappear. We may = take a "practical" approach though. I think 90% of utility could be = achieved by addressing 10% of complexity. Some extra freedom on = ordering/selection of queries would go a long way. We already did that RFC - was there something wrong or missing in that? > In general, I am also baffled why platform related issues, e.g. = interface selection, is something to be defined in a SIP related RFC. = Granted, a solution should be implementable but defining how to select = the right interface, e.g. which system call for a particular OS, does = not belong to this RFC. Specification can talk about the need packets = taking the correct/intended path but how this is achieved on a given = platform is an implementation issue IMHO. But then, maybe the former is = already what you meant. We need to figure out what part of this that is SIP-specific. But yes, = every SIP developer seems to be hitting multiple interfaces,=20 especially when moving to mobile platforms. >>=20 >> In regards to the current draft for connection-oriented SIP flows, I = am not >> happy about copying a lot of text from the Happy Eyeballs RFC into = this doc. >>=20 >> Happy Eyeballs is a large solution space and the important part of = the RFC is >> the requirements - the solutions vary. >> Copying text from that RFC could mean we copy stuff that is out of = scope and >> already old compared with today=E2=80=99s implementations and that we = by accident >> limit the solution space for SIP, which would be unfortunate. The SIP = solution >> for setting up a connection is in no way different from other = protocols and >> thus I think we will be better off and have a smoother path to = publication by >> just pointing to the Happy Eyeballs RFC than starting to copy parts = without us >> authors having current implementation experience. >>=20 >> Let=E2=80=99s keep the connection-oriented draft short and sweet and = just get it to >> publication and then dive heads down into UDP. That=E2=80=99s an area = where no >> work has been done before (as far as I know) and we will propably end = up >> producing an outbound-light or something else. > [TOLGA] Maybe, I am not as optimistic as you though (especially when = considering use of DTLS) DTLS for SIP/UDP is not specified yet, so as of now that is out of = scope. But I do agree that it will be interesting. >>=20 >> The implementation I work with currently send a simple OPTIONs = without >> SDP to test both address families and then select based on our = preferences >> and responses. We do prefer IPv6 in this case, as IPv4 is hiding = behind an ugly >> carrier grade nat. As this is a mobile app, registration and calls = happen within >> a short time and no flows are kept for long. Desktop phones have = flows that >> goes on for a very long time and network properties may change during = that >> time, so we need more regular discovery. > [TOLGA] Specification for UDP would mention about use of OPTIONS and = maybe provide information about some use cases but the exact semantics = of what/how is preferred shouldn=E2=80=99t be normatively defined. We have to remember that OPTIONS may cause media-related issues as it is = currently specified. In my platform we know the behaviour of the other endpoints = so it caused no harm. We may need to specify PING. Or just sending an unknown method and = getting an error code - just to provoke a response. Sending HELLOOLLE = sip:oej@edvina.net will always generate an error, unless someone out there use the = HELLOOLLE method=E2=80=A6 /O >>=20 >>=20 >> /O >>>=20 >>> Thanks, >>> Tolga >>>=20 >>>> -----Original Message----- >>>> From: Dale R. Worley [mailto:worley@ariadne.com] >>>> Sent: Thursday, December 15, 2016 2:16 PM >>>> To: Asveren, Tolga >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] Happy Eyeballs for SIP >>>>=20 >>>> "Asveren, Tolga" writes: >>>>>> However, we decided to >>>>>> not handle SRV in this tranche because a comprehensive approach = to >>>>>> SRV is complicated and nobody has yet proposed a solution that >>>>>> promises to meet the desiderata, viz.: >>>>>>=20 >>>>>> - achieve the Happy Eyeballs effect, that is, traffic will be = very >>>>>> rarely delayed by unreachability of one or more of the targets >>>>>>=20 >>>>>> - achieve the specified effect of SRV, that is, among the set of = targets >>>>>> which are reachable, over the long run, the traffic will be >>>>>> distributed among them according to the specified priorities and >>>>>> weights in the SRV records >>>>=20 >>>>> [TOLGA] I understand that "perfect outcome" may be hard to = describe >>>>> -let alone to achieve- especially considering various deployment >>>>> models/expectations. OTOH, I would think that allowing some = freedom >> in >>>>> terms of ordering could be all what needs to be mentioned in the >>>>> specification, e.g. >>>>=20 >>>>> Rather than: >>>>=20 >>>>> One ought to use the SRV records according to their = weight/priority >>>>> where eventually only one of them is the winner and is resolved >>>>=20 >>>> I'm not sure that "only one of [the SRV records] ... is resolved" = is correct. >> If >>>> there are two SRV records and, for the one with the lowest priority = value, >>>> the address(es) for the target name cannot be contacted, the client = is >>>> required to attempt to contact the address(es) for the target name = of the >>>> other SRV record. >>>>=20 >>>>> This: >>>>=20 >>>>> One may resolve all/a sub-set of available SRV records by also >>>>> considering IP Address Family and IP Address Family can be also >>>>> considered for the order of the queries >>>>>=20 >>>>> I can provide text/edit the document if we can reach a >>>>> conclusion/consensus on this point. >>>>=20 >>>> I suspect that allowing the client unlimited authority to reorder = the target >>>> addresses based on IP address family will allow behaviors that we = do not >>>> want to allow. In particular, if the SRV records give one IP = address family >>>> over the other family, and the client can contact both addresses, = we want >>>> the client to respect that declared priority. (This is a variation = on the >> example >>>> in RFC 7984.) >>>>=20 >>>>>>> I am not sure >>>>>>> what the right interpretation should be here but it is not >>>>>>> well-defined to say the least. To me, it seems like RFC7984 = should >>>>>>> be updating RFC3263 normatively in this aspect as well -to = promote >>>>>>> the >>>>>>> RFC7984 defined behavior-. And IMHO it would be up to the >>>>>>> Happy-Eyeballs draft to define how addresses from multiple SRV >>>>>>> Records should be used. Cases, where a dual-stack entity does = not >>>>>>> know whether >>>>>>> IPv4/IPv6 is preferred and multiple SRV records are used for >>>>>>> different address families on different servers should be = covered as >>>> well. >>>>>>=20 >>>>>> Can you give an example where the procedures of RFC 2782 aren't >>>>>> sufficient to resolve this problem? >>>>=20 >>>>> [TOLGA] "Usage Rules" section of RFC2782 seem to imply: >>>>=20 >>>>> i- A list is prepared by querying all SRV records. Queries are >>>>> performed by the priority/weight based ordering. >>>>=20 >>>>> ii- And then there is "freedom" in terms of selecting the server = to >>>>> actually use. >>>>=20 >>>> The freedom allowed by RFC 2782 is limited. Actually, the only = variation >>>> allowed in the order of contacting the addresses is due to the use = of >> random >>>> numbers in selecting between records of the same priority. >>>> (section "The format of the SRV RR" item "Weight") >>>>=20 >>>>> I think i- is where some improvement could be useful in the = context of >>>>> happy-eyeballs. The IP Address Family can be used as a third = parameter >>>>> -in addition to priority/weight- when ordering DNS queries. = Granted, >>>>> one may argue that all queries can be performed in parallel but = still >>>>> some clarification text in the specification could be a good idea = to >>>>> highlight this and prevent any confusion. >>>>=20 >>>> Remember that only one DNS query is needed to obtain *all* the SRV >>>> records for a particular domain name and transport. >>>>=20 >>>>>> The *concept* of Happy Eyeballs can, should, and will be applied = to >>>>>> UDP, but the *details* are going to be considerably different = from the >>>> details for TCP. >>>>>> For the first tranche, we are attempting to stay near what has = been >>>>>> done for HTTP, so we are limiting the scope to = connection-oriented >>>> protocols. >>>>=20 >>>>> [TOLGA] I think one issue was regarding the "probing" for UDP. = With >>>>> TCP, connection establishment provides information about the = quality >>>>> of the connection toward the server. Why not using OPTIONS for = UDP? >> It >>>>> wouldn't change the "SIP state" and wouldn't cause any distraction = to >>>>> end users/devices. >>>>=20 >>>> Yes, that would work. But as I said, UDP is not included in this = tranche. >>>>=20 >>>> Dale >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Dec 16 14:28:07 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B9112948B for ; Fri, 16 Dec 2016 14:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 wLhLMyXBEqWV for ; Fri, 16 Dec 2016 14:28:02 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B5D129473 for ; Fri, 16 Dec 2016 14:28:01 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-04v.sys.comcast.net with SMTP id I0yoc5DBAGIgtI0yucTa9e; Fri, 16 Dec 2016 22:28:00 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-09v.sys.comcast.net with SMTP id I0ytcQdRlnS0qI0yucXxtm; Fri, 16 Dec 2016 22:28:00 +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 uBGMRwNQ011854; Fri, 16 Dec 2016 17:27:58 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBGMRw8h011851; Fri, 16 Dec 2016 17:27:58 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: tasveren@sonusnet.com, sipcore@ietf.org In-Reply-To: <87k2b1ovef.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 16 Dec 2016 17:27:57 -0500 Message-ID: <87oa0bmrv6.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMnBsHtX3syHuty1ycUP1vQyg7gfT9LnDLpHD4x1a3Ow+lR2QjGiyd1qU4PXDOHd6RXUcyn3Woz0PwLpFUhZ9MlVXk84mT01280Te4sz4wjUTeAC2ITL dh7hMrI5WFYZOVcreRM9I/8eVkpj4MlElFRFg2GQ9y+a4EQGgMkHYUjmcav+g0KHTJcFkMyISXKSSB3kdRfh/tsn6moGVV8/KjI= Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 22:28:05 -0000 worley@ariadne.com (Dale R. Worley) writes: > "Asveren, Tolga" writes: >> [TOLGA] I think one issue was regarding the "probing" for UDP. With >> TCP, connection establishment provides information about the quality >> of the connection toward the server. Why not using OPTIONS for UDP? It >> wouldn't change the "SIP state" and wouldn't cause any distraction to >> end users/devices. > > Yes, that would work. But as I said, UDP is not included in this > tranche. Indeed, OPTIONS is relatively high-overhead but has the significant benefit that it can be used with *any* transport to probe that transport's connectivity. So I expect OPTIONS to become a more prominent technique in later tranches. Dale From nobody Fri Dec 16 14:40:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854AA129473 for ; Fri, 16 Dec 2016 14:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 S8nbkiADToa3 for ; Fri, 16 Dec 2016 14:40:22 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB19F1293EC for ; Fri, 16 Dec 2016 14:40:22 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-01v.sys.comcast.net with SMTP id I18scFeZEP4DhI1AscQsaX; Fri, 16 Dec 2016 22:40:22 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-11v.sys.comcast.net with SMTP id I1Aqctatuy32lI1ArcqNe9; Fri, 16 Dec 2016 22:40:22 +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 uBGMeKmu013122; Fri, 16 Dec 2016 17:40:20 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBGMeJu7013108; Fri, 16 Dec 2016 17:40:19 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 16 Dec 2016 17:40:19 -0500 Message-ID: <87lgvfmrak.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfM1UtiY/HmHRdCzBXMn3troba8cpSYzu419HJbgGfd5cDkDbZHfVPFd9AXR75y88Q2sZKmksv83Mo2s7OebuUufMHO14dQrQyGMlcZtVtNSoeyAc7ixL 2ZVI7XCMwCl2uuDLT1a5pd3y2VZvksRZSsUXX589sXIt5K1nFLgdS+sIrc3bOcEEtH48hdew4y3MOg== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 22:40:23 -0000 "Olle E. Johansson" writes: > We have to remember that OPTIONS may cause media-related issues as it > is currently specified. In my platform we know the behaviour of the > other endpoints so it caused no harm. We may need to specify PING. Or > just sending an unknown method and getting an error code - just to > provoke a response. Sending HELLOOLLE sip:oej@edvina.net will always > generate an error, unless someone out there use the HELLOOLLE > method... The advantage of OPTIONS with "Max-Forwards: 0" is that the first proxy to receive it must return a response, either 2xx or 483. (Or 486 if it's a UA that's unwilling to accept a call at the moment!) Without Max-Forwards, the request passes transparently through proxies and only when it reaches a UA is a response generated. But it's not clear to me what "media-related issues" there are for OPTIONS. My understanding of RFC 3261 is that the UAC is required to not change the state of the element that generates the response. Or are there slightly-out-of-spec elements that have behaviors that we need to worry about? Dale From nobody Sat Dec 17 04:50:26 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389011294E6 for ; Sat, 17 Dec 2016 04:50:25 -0800 (PST) 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=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VisuoFPQwZpm for ; Sat, 17 Dec 2016 04:50:23 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2420612940C for ; Sat, 17 Dec 2016 04:50:21 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 3D09D6C07; Sat, 17 Dec 2016 13:50:07 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <87lgvfmrak.fsf@hobgoblin.ariadne.com> Date: Sat, 17 Dec 2016 13:50:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87lgvfmrak.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 12:50:25 -0000 > On 16 Dec 2016, at 23:40, Dale R. Worley wrote: >=20 > "Olle E. Johansson" writes: >> We have to remember that OPTIONS may cause media-related issues as it >> is currently specified. In my platform we know the behaviour of the >> other endpoints so it caused no harm. We may need to specify PING. Or >> just sending an unknown method and getting an error code - just to >> provoke a response. Sending HELLOOLLE sip:oej@edvina.net will always >> generate an error, unless someone out there use the HELLOOLLE >> method... >=20 > The advantage of OPTIONS with "Max-Forwards: 0" is that the first = proxy > to receive it must return a response, either 2xx or 483. (Or 486 if > it's a UA that's unwilling to accept a call at the moment!) Without > Max-Forwards, the request passes transparently through proxies and = only > when it reaches a UA is a response generated. >=20 > But it's not clear to me what "media-related issues" there are for > OPTIONS. My understanding of RFC 3261 is that the UAC is required to > not change the state of the element that generates the response. Or = are > there slightly-out-of-spec elements that have behaviors that we need = to > worry about? To do options right in a software Asterisk I would have to authenticate because it=E2=80=99s only after authentication I can answer the same way = as I would answer if this was a proper Invite with SDP. So if anyone wants to use OPTIONs for discovery as it was meant it would mean = authentication as well. Using Options as Ping has kind of taken this away so no one really use Options for discovery any more since the answer differs from an INVITE. The question is can we base a new RFC on this misuse or do we need to document the misuse and modify OPTIONs too? /O= From nobody Sat Dec 17 07:47:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBBC1294BD for ; Sat, 17 Dec 2016 07:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 ekSUQ_tsxW5d for ; Sat, 17 Dec 2016 07:47:39 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0060.outbound.protection.outlook.com [104.47.36.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDC8128B37 for ; Sat, 17 Dec 2016 07:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qvf0saObDxx/tCbF7QH5tlsSou313UwI0V+/+nHvzIs=; b=aSj7kI1M3DgwhFEZO1ZcWMrT00HN10JNlkX/ZkadMJ4VndPl+hPwTSnrPSl1aaUqPDwnr0HWyhx8pC5fKeySPNtyJChLezIz+3TpcoLvO5A+iEUwgDsFbHgDPaxovfzrsHyY9EZLH1OZEGsvdW0hYtH0YrDI1lcm29zkKyXFyrA= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Sat, 17 Dec 2016 15:47:37 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.014; Sat, 17 Dec 2016 15:47:37 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" , "Dale R. Worley" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSV+1gRj/FKGerzk2IPpPFNc5xDqEMGE6AgAAvmNA= Date: Sat, 17 Dec 2016 15:47:37 +0000 Message-ID: References: <87lgvfmrak.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: dbd645c1-4ab1-4522-6911-08d4269406d8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:RgoWwjl3zO+lInaFH+qTTHS5c64fuuEIG9E3euo+FKBWT9rDORi5Zi7V9Y3VJpli7YZ34McmkiChIWHRq5dwvDjpvvQ0SFB4IVUYM0XYSB4d2LmFtD/5padFe7fuS5hH5Dnb7tBvQiKQ9Bh/sVPywP8npaSFeysfzhAETMDESL38QVuuHhgOA+KrfZaqJS2qGEilpPCBkE2BSkXExosMrEXn0LzeyZtuWK+61tTonITXkwsSqvzxtONC1l/jSKz899Bk9/R1Br5VO5yl4z4kKGqj4Qhq+q9stTekp6Z3msnqYiaafv9emQNGj5LJUDA7t9tgiJh5oWD+Mae4JuRefx9MCfYYDVmvUYAZjfMOZNTGeLcgqRWFzKDJzwkVlim5yeqtaiMqtYdezjJXW+GMiBXgJJYmSL6bCo3cjD0mYc6zRJiIaYhtzY8YF+OwSd9jqXE5Wu22rDE3hKM1P8QqfA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558021)(6072148)(6047074); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0159AC2B97 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(189002)(199003)(13464003)(57704003)(24454002)(101416001)(76176999)(50986999)(122556002)(102836003)(106356001)(74316002)(86362001)(6116002)(106116001)(105586002)(76576001)(7736002)(3660700001)(3280700002)(99286002)(33656002)(66066001)(8676002)(81166006)(8936002)(3846002)(77096006)(2900100001)(54356999)(4326007)(81156014)(97736004)(5001770100001)(92566002)(2906002)(5660300001)(189998001)(305945005)(2950100002)(25786008)(6436002)(7696004)(229853002)(38730400001)(68736007)(6506006)(9686002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2016 15:47:37.4160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 15:47:42 -0000 aS0gQSBzaW5nbGUgaW1wbGVtZW50YXRpb24gZG9lcyBpdCBjZXJ0YWluIHdheSBkb2VzIG5vdCBt ZWFuIGl0IGlzIHBlciBzcGVjaWZpY2F0aW9uL2RvbmUgdGhlIHNhbWUgd2F5IGJ5IGFsbCBvdGhl ciBlbnRpdGllcy9pbXBsZW1lbnRhdGlvbnMuIEkgYW0gYXdhcmUgb2YgbWFueSBkZXBsb3ltZW50 cyB1c2luZyBPUFRJT05TIGZvciBwaW5nL2tlZXBhbGl2ZS9wcm9iZSB3aXRoIHN1Y2Nlc3MgYW5k IHdpdGhvdXQgYW55IGlzc3Vlcy4gSU1ITywgT1BUSU9OUyBkZWZpbml0ZWx5IHNob3VsZCBiZSBt ZW50aW9uZWQgYXMgb25lIG9mIHRoZSBhbHRlcm5hdGl2ZXMuDQoNCmlpLSBJIGRvbuKAmXQgdGhp bmsgInVua25vd24gbWV0aG9kIiBzaG91bGQgYmUgcGFydCBvZiB0aGUgc3BlY2lmaWNhdGlvbi4g VGhhdCBpcyB0b28gbXVjaCBvZiBhIGhhY2sgSU1ITy4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xsZSBFLg0KPiBKb2hhbnNzb24NCj4g U2VudDogU2F0dXJkYXksIERlY2VtYmVyIDE3LCAyMDE2IDc6NTAgQU0NCj4gVG86IERhbGUgUi4g V29ybGV5IDx3b3JsZXlAYXJpYWRuZS5jb20+DQo+IENjOiBzaXBjb3JlQGlldGYub3JnOyBPbGxl IEUgSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD4NCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBI YXBweSBFeWViYWxscyBmb3IgU0lQDQo+IA0KPiANCj4gPiBPbiAxNiBEZWMgMjAxNiwgYXQgMjM6 NDAsIERhbGUgUi4gV29ybGV5IDx3b3JsZXlAYXJpYWRuZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4g Ik9sbGUgRS4gSm9oYW5zc29uIiA8b2VqQGVkdmluYS5uZXQ+IHdyaXRlczoNCj4gPj4gV2UgaGF2 ZSB0byByZW1lbWJlciB0aGF0IE9QVElPTlMgbWF5IGNhdXNlIG1lZGlhLXJlbGF0ZWQgaXNzdWVz IGFzIGl0DQo+ID4+IGlzIGN1cnJlbnRseSBzcGVjaWZpZWQuIEluIG15IHBsYXRmb3JtIHdlIGtu b3cgdGhlIGJlaGF2aW91ciBvZiB0aGUNCj4gPj4gb3RoZXIgZW5kcG9pbnRzIHNvIGl0IGNhdXNl ZCBubyBoYXJtLiBXZSBtYXkgbmVlZCB0byBzcGVjaWZ5IFBJTkcuIE9yDQo+ID4+IGp1c3Qgc2Vu ZGluZyBhbiB1bmtub3duIG1ldGhvZCBhbmQgZ2V0dGluZyBhbiBlcnJvciBjb2RlIC0ganVzdCB0 bw0KPiA+PiBwcm92b2tlIGEgcmVzcG9uc2UuIFNlbmRpbmcgSEVMTE9PTExFIHNpcDpvZWpAZWR2 aW5hLm5ldCB3aWxsIGFsd2F5cw0KPiA+PiBnZW5lcmF0ZSBhbiBlcnJvciwgdW5sZXNzIHNvbWVv bmUgb3V0IHRoZXJlIHVzZSB0aGUgSEVMTE9PTExFDQo+ID4+IG1ldGhvZC4uLg0KPiA+DQo+ID4g VGhlIGFkdmFudGFnZSBvZiBPUFRJT05TIHdpdGggIk1heC1Gb3J3YXJkczogMCIgaXMgdGhhdCB0 aGUgZmlyc3QNCj4gPiBwcm94eSB0byByZWNlaXZlIGl0IG11c3QgcmV0dXJuIGEgcmVzcG9uc2Us IGVpdGhlciAyeHggb3IgNDgzLiAgKE9yDQo+ID4gNDg2IGlmIGl0J3MgYSBVQSB0aGF0J3MgdW53 aWxsaW5nIHRvIGFjY2VwdCBhIGNhbGwgYXQgdGhlIG1vbWVudCEpDQo+ID4gV2l0aG91dCBNYXgt Rm9yd2FyZHMsIHRoZSByZXF1ZXN0IHBhc3NlcyB0cmFuc3BhcmVudGx5IHRocm91Z2ggcHJveGll cw0KPiA+IGFuZCBvbmx5IHdoZW4gaXQgcmVhY2hlcyBhIFVBIGlzIGEgcmVzcG9uc2UgZ2VuZXJh dGVkLg0KPiA+DQo+ID4gQnV0IGl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoYXQgIm1lZGlhLXJlbGF0 ZWQgaXNzdWVzIiB0aGVyZSBhcmUgZm9yDQo+ID4gT1BUSU9OUy4gIE15IHVuZGVyc3RhbmRpbmcg b2YgUkZDIDMyNjEgaXMgdGhhdCB0aGUgVUFDIGlzIHJlcXVpcmVkIHRvDQo+ID4gbm90IGNoYW5n ZSB0aGUgc3RhdGUgb2YgdGhlIGVsZW1lbnQgdGhhdCBnZW5lcmF0ZXMgdGhlIHJlc3BvbnNlLiAg T3INCj4gPiBhcmUgdGhlcmUgc2xpZ2h0bHktb3V0LW9mLXNwZWMgZWxlbWVudHMgdGhhdCBoYXZl IGJlaGF2aW9ycyB0aGF0IHdlDQo+ID4gbmVlZCB0byB3b3JyeSBhYm91dD8NCj4gDQo+IFRvIGRv IG9wdGlvbnMgcmlnaHQgaW4gYSBzb2Z0d2FyZSBBc3RlcmlzayBJIHdvdWxkIGhhdmUgdG8gYXV0 aGVudGljYXRlDQo+IGJlY2F1c2UgaXTigJlzIG9ubHkgYWZ0ZXIgYXV0aGVudGljYXRpb24gSSBj YW4gYW5zd2VyIHRoZSBzYW1lIHdheSBhcyBJIHdvdWxkDQo+IGFuc3dlciBpZiB0aGlzIHdhcyBh IHByb3BlciBJbnZpdGUgd2l0aCBTRFAuIFNvIGlmIGFueW9uZSB3YW50cyB0byB1c2UNCj4gT1BU SU9OcyBmb3IgZGlzY292ZXJ5IGFzIGl0IHdhcyBtZWFudCBpdCB3b3VsZCBtZWFuIGF1dGhlbnRp Y2F0aW9uIGFzIHdlbGwuDQo+IFVzaW5nIE9wdGlvbnMgYXMgUGluZyBoYXMga2luZCBvZiB0YWtl biB0aGlzIGF3YXkgc28gbm8gb25lIHJlYWxseSB1c2UNCj4gT3B0aW9ucyBmb3IgZGlzY292ZXJ5 IGFueSBtb3JlIHNpbmNlIHRoZSBhbnN3ZXIgZGlmZmVycyBmcm9tIGFuIElOVklURS4NCj4gDQo+ IFRoZSBxdWVzdGlvbiBpcyBjYW4gd2UgYmFzZSBhIG5ldyBSRkMgb24gdGhpcyBtaXN1c2Ugb3Ig ZG8gd2UgbmVlZCB0bw0KPiBkb2N1bWVudCB0aGUgbWlzdXNlIGFuZCBtb2RpZnkgT1BUSU9OcyB0 b28/DQo+IA0KPiAvTw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From nobody Sun Dec 18 01:50:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4EE1296BD for ; Sun, 18 Dec 2016 01:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 xNEsuAla5B83 for ; Sun, 18 Dec 2016 01:50:06 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0068.outbound.protection.outlook.com [104.47.42.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AEC1296B9 for ; Sun, 18 Dec 2016 01:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FzMkUfBkDAx1j3P9bB523exvfxDjnp+BgcgkNqe0I04=; b=UDM5InYRtejASlvBJvPBh7trrgsZC3ifYc9l0z8w3f4GwNzHEXYduwohK8a4KDYseqMjJc+SGJtfq7YgsnBa92ypqapA6doS2e+bZ7YN+XDgbX/Z6/hfdttCAdeSF16VP5jvh9xFneVYYH/HJi4EPsG6a5t+8ecf4F5DmpTQGaM= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Sun, 18 Dec 2016 09:50:04 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.014; Sun, 18 Dec 2016 09:50:04 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSVwe5Rj/FKGerzk2IPpPFNc5xDqEJaukQgADZ/gCAADHpcIAAIWMAgALJowA= Date: Sun, 18 Dec 2016 09:50:04 +0000 Message-ID: References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> In-Reply-To: <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: d2a4c4dc-d654-4be4-8bcd-08d4272b3e03 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:lpctOM6wrnleyWBJ7Bd7DKJEXPshJazukRrWo1SCx0jN2bVaMwOaC70MLu5foAaAvA2BLAriNS8DQGNKiLtVSDwvedxHZQt7LAvgIIV0tXYgI/J4IC6jZ1Qn7Xr9aq51IOUczwXVI911L/wrQz/tavdOdNsZVTSi4NX1jl8+WC+R7poV6FV5+OzNxgmd1FChhg+fz/TEo6+wsw+8vzkuWnkgDqzyTrRvhTyIriCMN/EXQqIssYw/w6dwKqpGwEJKXY5A2HGpYWoPAjsPQjZrvRKytf2zQDm3olzV5HCuOKMtOHNYzskBi9pwYH4WWg4w4UT2nv5kqZHJolvcj58QmVfKSFi4oXRAv0eichiQLgLrMnn017DG3pWujnLiOC0BU3XpwoKjYuw0fy3lsbBJk9c9rkIb4emreMq4Gk9sRo4xlYsnTHtTRrHuAzzfLZGbti5TGPOE3KQiAanwq8hXpQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558021)(6047074)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 01604FB62B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(305945005)(74316002)(4326007)(6116002)(8676002)(102836003)(81156014)(81166006)(6436002)(6506006)(3846002)(229853002)(92566002)(66066001)(106116001)(106356001)(99286002)(105586002)(8936002)(97736004)(76176999)(68736007)(110136003)(33656002)(5660300001)(93886004)(3280700002)(9686002)(54356999)(50986999)(2906002)(7736002)(25786008)(77096006)(122556002)(38730400001)(2900100001)(3660700001)(7696004)(101416001)(189998001)(86362001)(76576001)(6916009)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2016 09:50:04.0706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 09:50:08 -0000 PiBEVExTIGZvciBTSVAvVURQIGlzIG5vdCBzcGVjaWZpZWQgeWV0LCBzbyBhcyBvZiBub3cgdGhh dCBpcyBvdXQgb2Ygc2NvcGUuDQo+IEJ1dCBJIGRvIGFncmVlIHRoYXQgaXQgd2lsbCBiZSBpbnRl cmVzdGluZy4NCltUT0xHQV0gUHJvYmFibHkgeW91IGFyZSByZWZlcnJpbmcgdG8gIlNJUCtEMlUi IGN1cnJlbnRseSBub3QgYmVpbmcgaW4gdGhlIElBTkEgUmVnaXN0cnkuIEkgdGhpbmsgaXQgc2hv dWxkLiBJIHdpbGwgY3JhZnQgYSBkcmFmdCBmb3IgdGhhdC4gDQpPbiBhbm90aGVyIG5vdGUsIHN0 YXRpYyBjb25maWd1cmF0aW9ucyAoZS5nLiBib3RoIElQdjQvSVB2NiBBZGRyZXNzZXMgYXJlIHBy b3Zpc2lvbmVkIGZvciBhIHRhcmdldCwgYnkgd2hhdGV2ZXIgbWVhbnMpIGFuZCBESENQIGJhc2Vk IGxlYXJuaW5nIG9mIGFkZHJlc3NlcyBmb3IgU0lQIFNlcnZlcnMgKFJGQzMzNjEsIFJGQzMzMTkp IHNob3VsZCBiZSBjb25zaWRlcmVkLiBTbywgIEkgdGhpbmsgU0lQL1VEUC9EVExTIGlzICJhbGxv d2VkIiBhZnRlcmFsbC4gQW5kIGl0IGlzIGNvbm5lY3Rpb24tb3JpZW50ZWQsIHRoZXJlZm9yZSBz aG91bGQgYmUgY292ZXJlZCBieSBoYXBweS1lYXJiYWxscyBJTUhPLg0K From nobody Sun Dec 18 02:58:13 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B23129793 for ; Sun, 18 Dec 2016 02:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DOldjr49k8_R for ; Sun, 18 Dec 2016 02:58:08 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A460912955A for ; Sun, 18 Dec 2016 02:58:07 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 085B36C07; Sun, 18 Dec 2016 11:57:47 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 18 Dec 2016 11:57:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 10:58:11 -0000 > On 18 Dec 2016, at 10:50, Asveren, Tolga = wrote: >=20 >> DTLS for SIP/UDP is not specified yet, so as of now that is out of = scope. >> But I do agree that it will be interesting. > [TOLGA] Probably you are referring to "SIP+D2U" currently not being in = the IANA Registry. I think it should. I will craft a draft for that.=20 > On another note, static configurations (e.g. both IPv4/IPv6 Addresses = are provisioned for a target, by whatever means) and DHCP based learning = of addresses for SIP Servers (RFC3361, RFC3319) should be considered. = So, I think SIP/UDP/DTLS is "allowed" afterall. And it is = connection-oriented, therefore should be covered by happy-earballs IMHO. There is simply no standard for DTLS as a transport for SIP. = http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-tr= ansport I agree it would be a good thing, but it requires more work than adding = it to the NAPTR registry. /O= From nobody Sun Dec 18 03:20:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC317129759 for ; Sun, 18 Dec 2016 03:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 XcQxG__lHpPV for ; Sun, 18 Dec 2016 03:20:35 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0063.outbound.protection.outlook.com [104.47.33.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3360F129462 for ; Sun, 18 Dec 2016 03:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LTTXfyqMQ6+S9inTN09GeV9lGI2yUTJuB0U6xvzonVc=; b=jZyhjLeesx1lQvkic1sgMNmKd0nshRUAUkCGv9h5gmE8plnps1fzL+Aj2++2Y5IL1VSDlXii8DvJ2XuamnGSYGK3Du32Nusc6SeuOwpwoFRq7yxojj/wyot58zwClSe4lBQjfmUylE7rTekki7n4OkK/0i2MttBVVEz28ECHfJo= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Sun, 18 Dec 2016 11:20:32 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.014; Sun, 18 Dec 2016 11:20:32 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSVwe5Rj/FKGerzk2IPpPFNc5xDqEJaukQgADZ/gCAADHpcIAAIWMAgALJowCAACsugIAABTLA Date: Sun, 18 Dec 2016 11:20:32 +0000 Message-ID: References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> In-Reply-To: <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 48b06c5f-fd0e-4446-b9f6-08d42737e1a9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:Y7pPfECtF2CrWl8SXWFPYOjgCWFHAJqSVFeM0Pszf1ODbsIBarKKz1iM0oyGlScyahao5qoe8St0f5Dt+GNAwNarU6R9C7V7krFf5Ksu7XHenb7xnlQvMpkbiSVI9fcYDMhp1LiG8vCLvqVNTkcypdiWa+RyO+2ADir1v0jLeLsMRBbEt9FcRKTsRUGI3L9VYYL33IuW/TgngwPi1xEZDk0tn8r3xws1q4762oYTElGlwFh0DBVnN5IaNF6U7DsAmWTybYTHgCRdWfwfrCa/08zwzQd6BLV4cZSEUAKDj95lvAYSAHwB/PR55db11yIb0a756GuFWLBUgMPGGGPoX0zkd/EfKZqWKk5Wfnx6fVlPKBLW/2clZL9zjjdeBru9GnAb3kzrxCOMj8g///YqVRXsBokrWIPYzPTfJOh8hshnbhAa3FxhtSXVog9gVO82q+UFq/9FEOlo1+8ktux0lQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558021)(6047074)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 01604FB62B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(13464003)(189002)(377454003)(199003)(305945005)(74316002)(4326007)(6116002)(8676002)(102836003)(81166006)(81156014)(6436002)(6506006)(3846002)(92566002)(229853002)(66066001)(106116001)(106356001)(99286002)(105586002)(8936002)(76176999)(68736007)(97736004)(110136003)(33656002)(5660300001)(93886004)(3280700002)(50986999)(9686002)(54356999)(2906002)(1720100001)(7736002)(25786008)(77096006)(122556002)(38730400001)(2900100001)(3660700001)(101416001)(7696004)(189998001)(86362001)(76576001)(2950100002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2016 11:20:32.6702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 11:20:38 -0000 One correction for my previous message: "SIP+D2U" =3D> "SIPS+D2U" And yes, there is yet another IANA Registry to be updated as you mentioned = and some other work, mea culpa.=20 There obviously will be a need to extend syntax for relevant SIP headers/pa= rameters and semantics to use it as one of the valid protocols. OTOH, I don= 't think there would be thorny issues and it would be mostly replicating wh= at has been done/said about other transport protocols. Thanks, Tolga > -----Original Message----- > From: Olle E. Johansson [mailto:oej@edvina.net] > Sent: Sunday, December 18, 2016 5:58 AM > To: Asveren, Tolga > Cc: Olle E Johansson ; Dale R. Worley > ; sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs for SIP >=20 >=20 > > On 18 Dec 2016, at 10:50, Asveren, Tolga > wrote: > > > >> DTLS for SIP/UDP is not specified yet, so as of now that is out of sco= pe. > >> But I do agree that it will be interesting. > > [TOLGA] Probably you are referring to "SIP+D2U" currently not being in = the > IANA Registry. I think it should. I will craft a draft for that. > > On another note, static configurations (e.g. both IPv4/IPv6 Addresses a= re > provisioned for a target, by whatever means) and DHCP based learning of > addresses for SIP Servers (RFC3361, RFC3319) should be considered. So, I > think SIP/UDP/DTLS is "allowed" afterall. And it is connection-oriented, > therefore should be covered by happy-earballs IMHO. >=20 > There is simply no standard for DTLS as a transport for SIP. > http://www.iana.org/assignments/sip-parameters/sip- > parameters.xhtml#sip-transport >=20 > I agree it would be a good thing, but it requires more work than adding i= t to > the NAPTR registry. > /O From nobody Sun Dec 18 04:23:07 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2A41294B8 for ; Sun, 18 Dec 2016 04:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4h4SZTA6g9RD for ; Sun, 18 Dec 2016 04:23:03 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E070612947A for ; Sun, 18 Dec 2016 04:23:01 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 66DDB6C38; Sun, 18 Dec 2016 13:22:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 18 Dec 2016 13:22:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 12:23:05 -0000 > On 18 Dec 2016, at 12:20, Asveren, Tolga = wrote: >=20 > One correction for my previous message: > "SIP+D2U" =3D> "SIPS+D2U" >=20 > And yes, there is yet another IANA Registry to be updated as you = mentioned and some other work, mea culpa.=20 > There obviously will be a need to extend syntax for relevant SIP = headers/parameters and semantics to use it as one of the valid = protocols. OTOH, I don't think there would be thorny issues and it would = be mostly replicating what has been done/said about other transport = protocols. Dale and I had a discussion about it at SIPit and it=E2=80=99s an = interesting mix of connection-less and connection-oriented that needs some documentation. But I do think it will help a lot of large-scale = platforms. /O >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: Olle E. Johansson [mailto:oej@edvina.net] >> Sent: Sunday, December 18, 2016 5:58 AM >> To: Asveren, Tolga >> Cc: Olle E Johansson ; Dale R. Worley >> ; sipcore@ietf.org >> Subject: Re: [sipcore] Happy Eyeballs for SIP >>=20 >>=20 >>> On 18 Dec 2016, at 10:50, Asveren, Tolga >> wrote: >>>=20 >>>> DTLS for SIP/UDP is not specified yet, so as of now that is out of = scope. >>>> But I do agree that it will be interesting. >>> [TOLGA] Probably you are referring to "SIP+D2U" currently not being = in the >> IANA Registry. I think it should. I will craft a draft for that. >>> On another note, static configurations (e.g. both IPv4/IPv6 = Addresses are >> provisioned for a target, by whatever means) and DHCP based learning = of >> addresses for SIP Servers (RFC3361, RFC3319) should be considered. = So, I >> think SIP/UDP/DTLS is "allowed" afterall. And it is = connection-oriented, >> therefore should be covered by happy-earballs IMHO. >>=20 >> There is simply no standard for DTLS as a transport for SIP. >> http://www.iana.org/assignments/sip-parameters/sip- >> parameters.xhtml#sip-transport >>=20 >> I agree it would be a good thing, but it requires more work than = adding it to >> the NAPTR registry. >> /O From nobody Sun Dec 18 05:49:26 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E311E12941A for ; Sun, 18 Dec 2016 05:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 SkHkc6b6r6-8 for ; Sun, 18 Dec 2016 05:49:21 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0043.outbound.protection.outlook.com [104.47.37.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C22128B38 for ; Sun, 18 Dec 2016 05:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9JtPkT8N+GvsaVo9VPb2Hc/b6y10NVdXjDKUnlQ+9qo=; b=EVNhiLrZ/Rw+OwvzYRu/9gji4iCSwYKzDW9dbI0GR2f1Nj1AWcQ7M8iNbhURepwot+9tbYLJfEYuC68yO0PfnV1Ro3FvV+ovhqlknd2Gm0ClICmxpeP/Ak3j/chJ/RppSMYX9OWjm2g9LkGEjAwOAF36JP4+8MCG2zxn/ZNe8D4= Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2343.namprd03.prod.outlook.com (10.166.93.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Sun, 18 Dec 2016 13:49:19 +0000 Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.0789.018; Sun, 18 Dec 2016 13:49:19 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" Thread-Topic: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem Thread-Index: AdJZFHrOvyU+dWmrSZmJnOs13D51Dg== Date: Sun, 18 Dec 2016 13:49:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 3797829a-c8f2-41b3-0c59-08d4274caa6b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2343; x-microsoft-exchange-diagnostics: 1; CO2PR03MB2343; 7:HeL4E56NthbqFfulWNlSjG7i7LRm1s6+xg1X8GguanAgWmh6JgarEzQv1CPxtPpfQi6yu59XBGaHz8YAeRrsIjffVuZYcwEZfDk8VkmO4l8QGTsg4JZiPjMkOGTZBvQBNyjMeN+HB6ogtFbbIzXtXqSUU3Ef/OzmuRZrxNpQyYH7XljS9v+7c/shVQi5n1I4ScI8V1QIWznmhZD+h5Y5g6hYmgKeVwgLurALyHxC1OHFYS4aSJIp/BQYWvXG7QMll+WrhDZe2F6dcqs0C7o++lqH87jGvZ1Wu4TzxnLmbYSEusK8l9FxH0EKtSnJSaurBtE24AB8T/xgBkaSD9cWtVpeUoT+oHOuqcnuLnvQyGAOnkhD4BUmJHvxhBg88Q+wKE/oVb5H08PMJ5/sTeGf/ceS3J7UbewT+e4RRRFbOpmxCzqcztiX3KRuvHHk9fcwfzhTytGOiMMyQrzEI7rOTw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(150554046322364)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:CO2PR03MB2343; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2343; x-forefront-prvs: 01604FB62B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(305945005)(66066001)(74316002)(99286002)(7736002)(81156014)(81166006)(8676002)(68736007)(122556002)(189998001)(8936002)(9686002)(54356999)(101416001)(50986999)(3660700001)(3280700002)(106356001)(105586002)(76576001)(33656002)(2906002)(4326007)(92566002)(2900100001)(86362001)(3846002)(102836003)(6116002)(6436002)(77096006)(38730400001)(6506006)(25786008)(229853002)(97736004)(6916009)(110136003)(7696004)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2343; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2016 13:49:19.2939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2343 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 13:49:24 -0000 Slightly changing the subject line for easier tracking... I think it would be useful to get on a common understanding/consensus on "w= hat needs to be covered and in which document" as far as use of multiple IP= Address Families/Multiple Interfaces are concerned. Here is a first attemp= t for "Summary of Happiness": A) Use of Multiple IP Address Families i- RFC2782 Defines how to resolve SRV Records All SRVs are resolved with DNS query ordering according to priority/weight Does not mandate any procedure regarding how/in which order learned address= ed are used ii- RFC6555=20 Defines parallel connection attempt for different IP address families.=20 Restricts itself -I don't know exactly why- to a single hostname for IPv4/I= Pv6 and does not cover other ways of learning IP Addresses, e.g. provisioni= ng, DHCP based. AFAICS, procedure described in this specification can be ap= plied for those cases as well.=20 Use of mechanism is allowed for connectionless transports as long as reques= t/response semantics are achieved by application layer iii- RFC7984 Defines DNS lookup for all IP address families instead of just one of them The end result is that all SRV records are fully resolved. I think this cov= ers all cases like multiple SRVs for a single IP address family as well alt= hough it is not directly mentioned in the specification. =09 iv- draft-worley-sip-he-connection-00 Defines SIP related procedures to use RFC6555 for SIP. This includes probin= g/keep-alive for existing connections, using an existing connection for all= requests. Would any "fast-failover after connection failure", e.g. toward the standby= server after failure of the primary server, related procedures be in scope= ? For connection oriented protocols, any possible recommendations/improveme= nts in this area would probably be limited to reusing the TLS connection. I= s there anything SIP specific, which could help here? B) Use of Multiple Interfaces v- I think the ideal place to cover this would be RFC6555-bis (also by cons= idering other restrictions as mentioned in ii- above). I wouldn't think tha= t there would be a need for defining anything new in draft-worley-sip-he-co= nnection-00 (?). C) Connectionless protocols Will be handled by another draft D) SIP/UDP/DTLS Requires a new draft Thanks, Tolga From nobody Sun Dec 18 05:52:11 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3534129413 for ; Sun, 18 Dec 2016 05:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 WIvwfv8O6GTz for ; Sun, 18 Dec 2016 05:52:07 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0057.outbound.protection.outlook.com [104.47.37.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEB8128B38 for ; Sun, 18 Dec 2016 05:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Xm2TaTqBUe5j2Nrdxi60jb2bd6YqgvZzaNngEb7hc08=; b=gcKMKVDXNcbejpuRcIFLbwO5f++guE5oq1etLnLQc9fjyTbBixIyZiEur2h+EN5NkZYY+AUuBIfPRYQXd+IKaGnYkxQ8KeBZ7a9n0E4z8DVR/g8XIrGeZTaOk4Jelok/0OLPSeDy1YOJi+1zG+s2IUlB40KbgO/ZyYrxwG4yqjM= Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2343.namprd03.prod.outlook.com (10.166.93.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Sun, 18 Dec 2016 13:52:06 +0000 Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.0789.018; Sun, 18 Dec 2016 13:52:06 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport Thread-Index: AQHSWSl+tEa6q1kNm0GLCEVThq2kbKENuKdw Date: Sun, 18 Dec 2016 13:52:06 +0000 Message-ID: References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: fe4775b5-a9d8-402a-5bfa-08d4274d0e1b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2343; x-microsoft-exchange-diagnostics: 1; CO2PR03MB2343; 7:U1glELFfDwZIVN3xfAxARriqVsPx7ezb+feHP7soEbzt6g+CdhRRbR3iklBCliyZ7cNpJviMct1Kmbsi/YNNh41vRYyH5W7X1hizo/Vqhw069w32+p0toCxZ+MSUqXbi2yftE2alW3JwJT6LS/gHrVwldvOrjF9WAqW5IGwcr5PQVqj8Evx03gTHb2h01RbfRflN8f4TF4/Bk2/h7L1QO8TrNerrHnnNL7VJy5HzqbtoCuhobYl+QgqR2QN6cnEnvA2jJijseQ8OGcRmooIwyIHTHe6wMAPxxBMyCjzQNni9wj3u1G9ybxRtJFWVUoaXXy8gy7U8tk+z7Ox9rIOAoBcihWkIMfaCkGj1jR+dT/jOcL/lVL6e1xz+xdHltjiNUC6Ay/yGueA1v0f//pzGxbX6M9SS+TQVLSf4hh3d1D5wKzi/RK2fDBerONI2AEB6LCqPomE8fWU9IU8HhVoxoA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:CO2PR03MB2343; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2343; x-forefront-prvs: 01604FB62B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(377454003)(189002)(24454002)(13464003)(25786008)(6436002)(77096006)(38730400001)(6506006)(1720100001)(229853002)(92566002)(2900100001)(33656002)(2906002)(4326007)(3846002)(102836003)(6116002)(86362001)(110136003)(7696004)(5660300001)(2950100002)(6916009)(97736004)(189998001)(106116001)(122556002)(8936002)(9686002)(81166006)(81156014)(68736007)(8676002)(305945005)(7736002)(66066001)(74316002)(99286002)(105586002)(106356001)(93886004)(3280700002)(3660700001)(76576001)(50986999)(101416001)(76176999)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2343; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2016 13:52:06.6189 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2343 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 13:52:10 -0000 WWVzLCBkZWZpbml0ZWx5IHVzZWZ1bCBpbiBwcmFjdGljZS4gSSBjZXJ0YWlubHkgYW0gaW50ZXJl c3RlZCBpbiB3b3JraW5nIG9uIHRoZSBuZWVkZWQgc3BlY2lmaWNhdGlvbi4gSXMgdGhlcmUgYSBy ZWFzb24gd2h5IHRoZSB3b3JrIHNob3VsZCBub3Qgc3RhcnQgYXMgYSBwYXJhbGxlbCBhY3Rpdml0 eT8gDQoNClRoYW5rcywNClRvbGdhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogT2xsZSBFLiBKb2hhbnNzb24gW21haWx0bzpvZWpAZWR2aW5hLm5ldF0NCj4gU2VudDog U3VuZGF5LCBEZWNlbWJlciAxOCwgMjAxNiA3OjIzIEFNDQo+IFRvOiBBc3ZlcmVuLCBUb2xnYSA8 dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KPiBDYzogT2xsZSBFIEpvaGFuc3NvbiA8b2VqQGVkdmlu YS5uZXQ+OyBEYWxlIFIuIFdvcmxleQ0KPiA8d29ybGV5QGFyaWFkbmUuY29tPjsgc2lwY29yZUBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEhhcHB5IEV5ZWJhbGxzIGZvciBTSVAg LSBEVExTIGFzIGEgU0lQIHRyYW5zcG9ydA0KPiANCj4gDQo+ID4gT24gMTggRGVjIDIwMTYsIGF0 IDEyOjIwLCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KPiB3cm90ZToN Cj4gPg0KPiA+IE9uZSBjb3JyZWN0aW9uIGZvciBteSBwcmV2aW91cyBtZXNzYWdlOg0KPiA+ICJT SVArRDJVIiA9PiAiU0lQUytEMlUiDQo+ID4NCj4gPiBBbmQgeWVzLCB0aGVyZSBpcyB5ZXQgYW5v dGhlciBJQU5BIFJlZ2lzdHJ5IHRvIGJlIHVwZGF0ZWQgYXMgeW91DQo+IG1lbnRpb25lZCBhbmQg c29tZSBvdGhlciB3b3JrLCBtZWEgY3VscGEuDQo+ID4gVGhlcmUgb2J2aW91c2x5IHdpbGwgYmUg YSBuZWVkIHRvIGV4dGVuZCBzeW50YXggZm9yIHJlbGV2YW50IFNJUA0KPiBoZWFkZXJzL3BhcmFt ZXRlcnMgYW5kIHNlbWFudGljcyB0byB1c2UgaXQgYXMgb25lIG9mIHRoZSB2YWxpZCBwcm90b2Nv bHMuDQo+IE9UT0gsIEkgZG9uJ3QgdGhpbmsgdGhlcmUgd291bGQgYmUgdGhvcm55IGlzc3VlcyBh bmQgaXQgd291bGQgYmUgbW9zdGx5DQo+IHJlcGxpY2F0aW5nIHdoYXQgaGFzIGJlZW4gZG9uZS9z YWlkIGFib3V0IG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbHMuDQo+IA0KPiBEYWxlIGFuZCBJIGhh ZCBhIGRpc2N1c3Npb24gYWJvdXQgaXQgYXQgU0lQaXQgYW5kIGl04oCZcyBhbiBpbnRlcmVzdGlu ZyBtaXggb2YNCj4gY29ubmVjdGlvbi1sZXNzIGFuZCBjb25uZWN0aW9uLW9yaWVudGVkIHRoYXQg bmVlZHMgc29tZSBkb2N1bWVudGF0aW9uLg0KPiBCdXQgSSBkbyB0aGluayBpdCB3aWxsIGhlbHAg YSBsb3Qgb2YgbGFyZ2Utc2NhbGUgcGxhdGZvcm1zLg0KPiANCj4gL08NCj4gPg0KPiA+IFRoYW5r cywNCj4gPiBUb2xnYQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ IEZyb206IE9sbGUgRS4gSm9oYW5zc29uIFttYWlsdG86b2VqQGVkdmluYS5uZXRdDQo+ID4+IFNl bnQ6IFN1bmRheSwgRGVjZW1iZXIgMTgsIDIwMTYgNTo1OCBBTQ0KPiA+PiBUbzogQXN2ZXJlbiwg VG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4NCj4gPj4gQ2M6IE9sbGUgRSBKb2hhbnNzb24g PG9lakBlZHZpbmEubmV0PjsgRGFsZSBSLiBXb3JsZXkNCj4gPj4gPHdvcmxleUBhcmlhZG5lLmNv bT47IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBIYXBweSBF eWViYWxscyBmb3IgU0lQDQo+ID4+DQo+ID4+DQo+ID4+PiBPbiAxOCBEZWMgMjAxNiwgYXQgMTA6 NTAsIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+DQo+ID4+IHdyb3RlOg0K PiA+Pj4NCj4gPj4+PiBEVExTIGZvciBTSVAvVURQIGlzIG5vdCBzcGVjaWZpZWQgeWV0LCBzbyBh cyBvZiBub3cgdGhhdCBpcyBvdXQgb2Ygc2NvcGUuDQo+ID4+Pj4gQnV0IEkgZG8gYWdyZWUgdGhh dCBpdCB3aWxsIGJlIGludGVyZXN0aW5nLg0KPiA+Pj4gW1RPTEdBXSBQcm9iYWJseSB5b3UgYXJl IHJlZmVycmluZyB0byAiU0lQK0QyVSIgY3VycmVudGx5IG5vdCBiZWluZw0KPiA+Pj4gaW4gdGhl DQo+ID4+IElBTkEgUmVnaXN0cnkuIEkgdGhpbmsgaXQgc2hvdWxkLiBJIHdpbGwgY3JhZnQgYSBk cmFmdCBmb3IgdGhhdC4NCj4gPj4+IE9uIGFub3RoZXIgbm90ZSwgc3RhdGljIGNvbmZpZ3VyYXRp b25zIChlLmcuIGJvdGggSVB2NC9JUHY2DQo+ID4+PiBBZGRyZXNzZXMgYXJlDQo+ID4+IHByb3Zp c2lvbmVkIGZvciBhIHRhcmdldCwgYnkgd2hhdGV2ZXIgbWVhbnMpIGFuZCBESENQIGJhc2VkIGxl YXJuaW5nDQo+ID4+IG9mIGFkZHJlc3NlcyBmb3IgU0lQIFNlcnZlcnMgKFJGQzMzNjEsIFJGQzMz MTkpIHNob3VsZCBiZSBjb25zaWRlcmVkLg0KPiA+PiBTbywgIEkgdGhpbmsgU0lQL1VEUC9EVExT IGlzICJhbGxvd2VkIiBhZnRlcmFsbC4gQW5kIGl0IGlzDQo+ID4+IGNvbm5lY3Rpb24tb3JpZW50 ZWQsIHRoZXJlZm9yZSBzaG91bGQgYmUgY292ZXJlZCBieSBoYXBweS1lYXJiYWxscw0KPiBJTUhP Lg0KPiA+Pg0KPiA+PiBUaGVyZSBpcyBzaW1wbHkgbm8gc3RhbmRhcmQgZm9yIERUTFMgYXMgYSB0 cmFuc3BvcnQgZm9yIFNJUC4NCj4gPj4gaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9z aXAtcGFyYW1ldGVycy9zaXAtDQo+ID4+IHBhcmFtZXRlcnMueGh0bWwjc2lwLXRyYW5zcG9ydA0K PiA+Pg0KPiA+PiBJIGFncmVlIGl0IHdvdWxkIGJlIGEgZ29vZCB0aGluZywgYnV0IGl0IHJlcXVp cmVzIG1vcmUgd29yayB0aGFuDQo+ID4+IGFkZGluZyBpdCB0byB0aGUgTkFQVFIgcmVnaXN0cnku DQo+ID4+IC9PDQoNCg== From nobody Sun Dec 18 07:58:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACBF1294DA for ; Sun, 18 Dec 2016 07:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sSF-hpLOaSmE for ; Sun, 18 Dec 2016 07:58:19 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9EE1293DA for ; Sun, 18 Dec 2016 07:58:18 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 98F516C38; Sun, 18 Dec 2016 16:58:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 18 Dec 2016 16:57:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BBEB7E7-D02B-44A4-960C-077AC51F3BD0@edvina.net> References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 15:58:22 -0000 > On 18 Dec 2016, at 14:52, Asveren, Tolga = wrote: >=20 > Yes, definitely useful in practice. I certainly am interested in = working on the needed specification. Is there a reason why the work = should not start as a parallel activity?=20 No, if there are people interested that=E2=80=99s fine. I suspect it has = to start in dispatch, but the chairs can explain more. /O >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: Olle E. Johansson [mailto:oej@edvina.net] >> Sent: Sunday, December 18, 2016 7:23 AM >> To: Asveren, Tolga >> Cc: Olle E Johansson ; Dale R. Worley >> ; sipcore@ietf.org >> Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP = transport >>=20 >>=20 >>> On 18 Dec 2016, at 12:20, Asveren, Tolga >> wrote: >>>=20 >>> One correction for my previous message: >>> "SIP+D2U" =3D> "SIPS+D2U" >>>=20 >>> And yes, there is yet another IANA Registry to be updated as you >> mentioned and some other work, mea culpa. >>> There obviously will be a need to extend syntax for relevant SIP >> headers/parameters and semantics to use it as one of the valid = protocols. >> OTOH, I don't think there would be thorny issues and it would be = mostly >> replicating what has been done/said about other transport protocols. >>=20 >> Dale and I had a discussion about it at SIPit and it=E2=80=99s an = interesting mix of >> connection-less and connection-oriented that needs some = documentation. >> But I do think it will help a lot of large-scale platforms. >>=20 >> /O >>>=20 >>> Thanks, >>> Tolga >>>=20 >>>> -----Original Message----- >>>> From: Olle E. Johansson [mailto:oej@edvina.net] >>>> Sent: Sunday, December 18, 2016 5:58 AM >>>> To: Asveren, Tolga >>>> Cc: Olle E Johansson ; Dale R. Worley >>>> ; sipcore@ietf.org >>>> Subject: Re: [sipcore] Happy Eyeballs for SIP >>>>=20 >>>>=20 >>>>> On 18 Dec 2016, at 10:50, Asveren, Tolga >>>> wrote: >>>>>=20 >>>>>> DTLS for SIP/UDP is not specified yet, so as of now that is out = of scope. >>>>>> But I do agree that it will be interesting. >>>>> [TOLGA] Probably you are referring to "SIP+D2U" currently not = being >>>>> in the >>>> IANA Registry. I think it should. I will craft a draft for that. >>>>> On another note, static configurations (e.g. both IPv4/IPv6 >>>>> Addresses are >>>> provisioned for a target, by whatever means) and DHCP based = learning >>>> of addresses for SIP Servers (RFC3361, RFC3319) should be = considered. >>>> So, I think SIP/UDP/DTLS is "allowed" afterall. And it is >>>> connection-oriented, therefore should be covered by happy-earballs >> IMHO. >>>>=20 >>>> There is simply no standard for DTLS as a transport for SIP. >>>> http://www.iana.org/assignments/sip-parameters/sip- >>>> parameters.xhtml#sip-transport >>>>=20 >>>> I agree it would be a good thing, but it requires more work than >>>> adding it to the NAPTR registry. >>>> /O >=20 From nobody Sun Dec 18 08:30:26 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2C8129517 for ; Sun, 18 Dec 2016 08:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UQLTToJFuO9z for ; Sun, 18 Dec 2016 08:30:24 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE92D129515 for ; Sun, 18 Dec 2016 08:30:23 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id AB4206C38; Sun, 18 Dec 2016 17:30:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 18 Dec 2016 17:29:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C636F5F-F96E-4553-8EAD-31D36CE375BA@edvina.net> References: To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 16:30:25 -0000 > On 18 Dec 2016, at 14:49, Asveren, Tolga = wrote: >=20 > iv- draft-worley-sip-he-connection-00 > Defines SIP related procedures to use RFC6555 for SIP. ONLY for connection-oriented protocols. > This includes probing/keep-alive for existing connections, using an = existing connection for all requests. > Would any "fast-failover after connection failure", e.g. toward the = standby server after failure of the primary server, related procedures = be in scope? For connection oriented protocols, any possible = recommendations/improvements in this area would probably be limited to = reusing the TLS connection. Is there anything SIP specific, which could = help here? Isn=E2=80=99t that why we have SIP Outbound? /O= From nobody Sun Dec 18 08:32:20 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1412947D for ; Sun, 18 Dec 2016 08:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1ZI35KE_DRfm for ; Sun, 18 Dec 2016 08:32:17 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3E2129515 for ; Sun, 18 Dec 2016 08:32:16 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id CFB356C38; Sun, 18 Dec 2016 17:32:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 18 Dec 2016 17:32:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86BDF0AB-DA41-4C83-8D1D-56EC8FE46C02@edvina.net> References: To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 16:32:19 -0000 > On 18 Dec 2016, at 14:49, Asveren, Tolga = wrote: >=20 > B) Use of Multiple Interfaces > v- I think the ideal place to cover this would be RFC6555-bis (also by = considering other restrictions as mentioned in ii- above). I wouldn't = think that there would be a need for defining anything new in = draft-worley-sip-he-connection-00 (?). A question here is how this works with SIP outbound - do we need two = outbound connections per interface? How do we handle reg-id and failover in that case? It=E2=80=99s like inventing ICE for SIP=E2=80=A6 :-) /O= From nobody Sun Dec 18 08:46:03 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F2F129515 for ; Sun, 18 Dec 2016 08:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 FOLhWZl0tHce for ; Sun, 18 Dec 2016 08:45:59 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DEA128B37 for ; Sun, 18 Dec 2016 08:45:59 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-05v.sys.comcast.net with SMTP id Iea7cPJj7GIG7Ieb0cNv5t; Sun, 18 Dec 2016 16:45:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1482079558; bh=df0k6uZQlthu337uoxPpzwGjzVZnNF5xpZMJubPUMpw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AIjOuGO39fQHwy2kYjaX89lfo8V/oP7bXEet/RzOjvmWZRcfWaJF3x8qPSan12A4T ZBRYsBMAl7a2z1Zq3BCspCYCFiYe9L4TNohIkvp9xUj/HDkM1Av2Q5cxYYVQrtmwQQ Kslwp0PKs4Gb+B181yZ/gRThBu/fMf3d+BTFaI0dbd1yjDK/Neo93Pkh2SPDzlij5H rEqBQINIHglpwQPAgAaw8vn3XTvX+rMZ3Qjn2lEQ1VP5lD7MQ0KfKSjVFNhad1YQ3m b31FRUhsccrFQTqPHN2OUBnjlSfnDrgOhyAFwo7M5hdfBJA9YZVYp6U5acVk9+EExE lmkzfZ2VY3Bdg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-07v.sys.comcast.net with SMTP id Ieb0cIITqDKuRIeb0cwNB7; Sun, 18 Dec 2016 16:45:58 +0000 To: sipcore@ietf.org References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> <6BBEB7E7-D02B-44A4-960C-077AC51F3BD0@edvina.net> From: Paul Kyzivat Message-ID: Date: Sun, 18 Dec 2016 11:45:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <6BBEB7E7-D02B-44A4-960C-077AC51F3BD0@edvina.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDGl0KZ/bO7z6OYVOXXoTTgEV+3/Cw3V3LZ7giVTH8ddxtbe/lTvPVZr+iJrslQRR7dj8GpT/PGXehYUGEwcP5HY+H2+Y49Nk798Y4jMo+hNcVWiPFac qE7OKrgDyA8q6W4b5f3BmS9fM5nrsSBCthGB0FxXPx3pyeor+tBaD1moGihwfKvACmnSkFriKZ2PCg== Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 16:46:01 -0000 On 12/18/16 10:57 AM, Olle E. Johansson wrote: > >> On 18 Dec 2016, at 14:52, Asveren, Tolga wrote: >> >> Yes, definitely useful in practice. I certainly am interested in working on the needed specification. Is there a reason why the work should not start as a parallel activity? > No, if there are people interested that’s fine. I suspect it has to start in dispatch, but the chairs can explain more. I don't believe it must start in Dispatch. It clearly falls in scope of sipcore, even without the recent recharter. But I think it will need a new milestone. Thanks, Paul > /O >> >> Thanks, >> Tolga >> >>> -----Original Message----- >>> From: Olle E. Johansson [mailto:oej@edvina.net] >>> Sent: Sunday, December 18, 2016 7:23 AM >>> To: Asveren, Tolga >>> Cc: Olle E Johansson ; Dale R. Worley >>> ; sipcore@ietf.org >>> Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport >>> >>> >>>> On 18 Dec 2016, at 12:20, Asveren, Tolga >>> wrote: >>>> >>>> One correction for my previous message: >>>> "SIP+D2U" => "SIPS+D2U" >>>> >>>> And yes, there is yet another IANA Registry to be updated as you >>> mentioned and some other work, mea culpa. >>>> There obviously will be a need to extend syntax for relevant SIP >>> headers/parameters and semantics to use it as one of the valid protocols. >>> OTOH, I don't think there would be thorny issues and it would be mostly >>> replicating what has been done/said about other transport protocols. >>> >>> Dale and I had a discussion about it at SIPit and it’s an interesting mix of >>> connection-less and connection-oriented that needs some documentation. >>> But I do think it will help a lot of large-scale platforms. >>> >>> /O >>>> >>>> Thanks, >>>> Tolga >>>> >>>>> -----Original Message----- >>>>> From: Olle E. Johansson [mailto:oej@edvina.net] >>>>> Sent: Sunday, December 18, 2016 5:58 AM >>>>> To: Asveren, Tolga >>>>> Cc: Olle E Johansson ; Dale R. Worley >>>>> ; sipcore@ietf.org >>>>> Subject: Re: [sipcore] Happy Eyeballs for SIP >>>>> >>>>> >>>>>> On 18 Dec 2016, at 10:50, Asveren, Tolga >>>>> wrote: >>>>>> >>>>>>> DTLS for SIP/UDP is not specified yet, so as of now that is out of scope. >>>>>>> But I do agree that it will be interesting. >>>>>> [TOLGA] Probably you are referring to "SIP+D2U" currently not being >>>>>> in the >>>>> IANA Registry. I think it should. I will craft a draft for that. >>>>>> On another note, static configurations (e.g. both IPv4/IPv6 >>>>>> Addresses are >>>>> provisioned for a target, by whatever means) and DHCP based learning >>>>> of addresses for SIP Servers (RFC3361, RFC3319) should be considered. >>>>> So, I think SIP/UDP/DTLS is "allowed" afterall. And it is >>>>> connection-oriented, therefore should be covered by happy-earballs >>> IMHO. >>>>> >>>>> There is simply no standard for DTLS as a transport for SIP. >>>>> http://www.iana.org/assignments/sip-parameters/sip- >>>>> parameters.xhtml#sip-transport >>>>> >>>>> I agree it would be a good thing, but it requires more work than >>>>> adding it to the NAPTR registry. >>>>> /O >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sun Dec 18 17:41:27 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C601512945F for ; Sun, 18 Dec 2016 17:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 ZzkG7lLrwALu for ; Sun, 18 Dec 2016 17:41:24 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2BD126D73 for ; Sun, 18 Dec 2016 17:41:24 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-01v.sys.comcast.net with SMTP id Imx5cIXipP4DhImxAcVV0B; Mon, 19 Dec 2016 01:41:24 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-11v.sys.comcast.net with SMTP id Imx7c2WgUy32lImx8ctwLZ; Mon, 19 Dec 2016 01:41:24 +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 uBJ1eLC8017130; Sun, 18 Dec 2016 20:40:21 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBJ1eKF6017127; Sun, 18 Dec 2016 20:40:20 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 18 Dec 2016 20:40:20 -0500 Message-ID: <87mvfs3ddn.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfFNDEP+RV9W0L+XzsNdsHkHTw0sGh5Trg0Cn6UnBTasJ1mHb+Li7Y/KDw8aauEo42k6K+WG3CT34+s6FONz6lPjJlSw5EyXWuP3CwDRjrAsfFHXKiXU5 c5A2inUdEfvwFO0HKhMubhB1IvrVWVkczCjJL6C/XYF17GjQbn/euqAsHvUmNw3KC9QwkMvj6bLHoGIoaYBZfRKvzSiN20jFBM4kZg8FRddoBngm5egMDt5g Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 01:41:26 -0000 "Olle E. Johansson" writes: >> One correction for my previous message: >> "SIP+D2U" => "SIPS+D2U" >> >> There obviously will be a need to extend syntax for relevant SIP >> headers/parameters and semantics to use it as one of the valid >> protocols. OTOH, I don't think there would be thorny issues and it >> would be mostly replicating what has been done/said about other >> transport protocols. > > Dale and I had a discussion about it at SIPit and it's an interesting > mix of connection-less and connection-oriented that needs > some documentation. But I do think it will help a lot of large-scale platforms. Though I remember discussions with Roman Shpount that DTLS has some serious deficiencies for really large-scale systems. It seems like a design adjustment might be needed for DTLS to be really usable for SIP signaling. There was a discussion on Sipcore back in March. Dale From nobody Sun Dec 18 18:54:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1D11294E2 for ; Sun, 18 Dec 2016 18:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 74QXqfetJkMy for ; Sun, 18 Dec 2016 18:54:56 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E81127071 for ; Sun, 18 Dec 2016 18:54:56 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-04v.sys.comcast.net with SMTP id Io5tcI6uUrdcjIo6JcuNgJ; Mon, 19 Dec 2016 02:54:55 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-01v.sys.comcast.net with SMTP id Io6IcsoveBFdOIo6Jcmbri; Mon, 19 Dec 2016 02:54: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 uBJ2rrrZ024344; Sun, 18 Dec 2016 21:53:53 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBJ2rrKR024341; Sun, 18 Dec 2016 21:53:53 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 18 Dec 2016 21:53:53 -0500 Message-ID: <87eg1439z2.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCzzYs6ayOpKmGEom6Mt9L4Cdd7gX5aLLyXAuZ0JU2v9c4hkRXKpPYuwKnrshKxgK9gtUhqSlQ311orrCT82wZwnRsOXIk8dUBR09c6ipIzVr9ASOSyS KMyzse/7zw1BvPxjK7SekhbuzJ0hYmkDYOTXosQyqBGIHg2L/JRIIPM6R2P8qm1DBJ+0CgoLQmqCB6e+8lWc1Y1M1t7BWa4JvZI= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 02:54:57 -0000 "Asveren, Tolga" writes: > I think it would be useful to get on a common understanding/consensus > on "what needs to be covered and in which document" as far as use of > multiple IP Address Families/Multiple Interfaces are concerned. Here > is a first attempt for "Summary of Happiness": The current plan has been to discuss topics incrementally in order to keep the scope of each incremental technical discussion small enough that it will come to an end. If we throw everything into the discussion at once, it will be difficult to both discuss things thoroughly and come to a consensus. > ii- RFC6555 > Defines parallel connection attempt for different IP address families. > Restricts itself -I don't know exactly why- to a single hostname for > IPv4/IPv6 and does not cover other ways of learning IP Addresses, > e.g. provisioning, DHCP based. AFAICS, procedure described in this > specification can be applied for those cases as well. That's because RFC 6555 discusses the case of HTTP, where there is a single host name, the domain name from the HTTP URL. There *are* no other ways of learning an IP address in HTTP. > iv- draft-worley-sip-he-connection-00 > Would any "fast-failover after connection failure", e.g. toward the > standby server after failure of the primary server, related procedures > be in scope? For connection oriented protocols, any possible > recommendations/improvements in this area would probably be limited to > reusing the TLS connection. Is there anything SIP specific, which > could help here? Fast failover is, in effect, in scope because in a failure situation, what Happy Eyeballs attempts to do with the next SIP message is deliver it quickly. > B) Use of Multiple Interfaces > v- I think the ideal place to cover this would be RFC6555-bis (also by > considering other restrictions as mentioned in ii- above). I wouldn't > think that there would be a need for defining anything new in > draft-worley-sip-he-connection-00 (?). The subtle problem with multiple interfaces is that there can be multiple interfaces that might be able to connect to a particular target address. Currently in IPv6, the source address selection algorithm of RFC 6724 chooses which interface is to be used to contact a particular target address. But IIRC Roman Shpount noted that there are times when RFC 6724 gives a non-working result. It looks like in the long run we want H.E. to be able to use alternative source addresses if necessary. Dale From nobody Sun Dec 18 19:00:28 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A941294EB for ; Sun, 18 Dec 2016 19:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 9LlUOP4hhSu2 for ; Sun, 18 Dec 2016 19:00:27 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B167127071 for ; Sun, 18 Dec 2016 19:00:27 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-09v.sys.comcast.net with SMTP id IoBZcSnhF5lLvIoBfcTKKw; Mon, 19 Dec 2016 03:00:27 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-05v.sys.comcast.net with SMTP id IoBbcU9XzzYm9IoBdc4Ew1; Mon, 19 Dec 2016 03:00:27 +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 uBJ2xN9N024888; Sun, 18 Dec 2016 21:59:23 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBJ2xLna024883; Sun, 18 Dec 2016 21:59:21 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 18 Dec 2016 21:59:21 -0500 Message-ID: <87a8bs39py.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJKTw9psEy+5BW4WYxab6mMO53q1CZNvd+0rHxcupN6NgLn2puX9QZMRijmWNfv/xFPFPmEVXXN6nrICoPQ8gfDmlX4OjRtvic5dMcQqNDEGRkbI3Te1 5pJSzMXDwmtPNQOlXL64bI2lmdZbPkbQuWTHr2rnrJShfRE+IGeYhitMcceX5t+kmnyrp6ReXZDtNg== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 03:00:28 -0000 "Olle E. Johansson" writes: > To do options right in a software Asterisk I would have to authenticate > because it's only after authentication I can answer the same way as I > would answer if this was a proper Invite with SDP. So if anyone wants > to use OPTIONs for discovery as it was meant it would mean authentication > as well. Using Options as Ping has kind of taken this away so no one > really use Options for discovery any more since the answer differs > from an INVITE. I don't see what the problem is, even if OPTIONS demands authentication. If the client sends OPTIONS and receives back a 401 or 407 response, then clearly the communication path is working. Dale From nobody Sun Dec 18 19:07:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A37129466 for ; Sun, 18 Dec 2016 19:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 oLUv73cahGYM for ; Sun, 18 Dec 2016 19:07:11 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1C3129454 for ; Sun, 18 Dec 2016 19:07:11 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-12v.sys.comcast.net with SMTP id IoHYcIgSelNFyIoIAcCaAy; Mon, 19 Dec 2016 03:07:10 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-15v.sys.comcast.net with SMTP id IoI7cdNkSoA3MIoI8crFjs; Mon, 19 Dec 2016 03:07:10 +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 uBJ362V3025517; Sun, 18 Dec 2016 22:06:02 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBJ362mD025514; Sun, 18 Dec 2016 22:06:02 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 18 Dec 2016 22:06:01 -0500 Message-ID: <877f6w39eu.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCYG1TugUWdcjhbtMjEq2q16/tXOKgzWhflCuudevlZkUGDwoS+ow1/t2zKyXzr4j4Bz1CErmlTng2v560UL5OuTXd/RsGsap0ncXHMG1V1BYoapbXl2 yqYZgNHxXuiMJ690E7DvD1wymPpvF10rAUhzsM1dkAS5hwVQCnT40mpLnpiP5rdFJqMSdpFuEnVLLKco10GRFN2XWkj9nD0Z5drzU5M354QpphzM9NysbJbL Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 03:07:12 -0000 "Asveren, Tolga" writes: > i- A single implementation does it certain way does not mean it is per > specification/done the same way by all other > entities/implementations. I am aware of many deployments using OPTIONS > for ping/keepalive/probe with success and without any issues. IMHO, > OPTIONS definitely should be mentioned as one of the alternatives. The use of OPTIONS is listed in section 5 of draft-worley-sip-he-connection-01. Dale From nobody Sun Dec 18 19:14:50 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23399129466 for ; Sun, 18 Dec 2016 19:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 cYScf9aGC-dg for ; Sun, 18 Dec 2016 19:14:48 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E105129407 for ; Sun, 18 Dec 2016 19:14:48 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-08v.sys.comcast.net with SMTP id IoPYcrArVwySVIoPYcskBI; Mon, 19 Dec 2016 03:14:48 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-08v.sys.comcast.net with SMTP id IoPUcqiTTsBlpIoPVcxHgn; Mon, 19 Dec 2016 03:14:47 +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 uBJ3DifE026234; Sun, 18 Dec 2016 22:13:44 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBJ3DipX026231; Sun, 18 Dec 2016 22:13:44 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 18 Dec 2016 22:13:44 -0500 Message-ID: <8737hk391z.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJoL8HOJObq7rshsahOh7mh5dXP3wrpQYlt6cnToMMlt9793OwElY2gDoPQ/YLZNLeM8+3xLFcrCLzLkXUViQYpa9yUdl8td42ADvrbxB+i8xTzM3G63 jskRUyvHeGcDUJnZ9s52kBV3kk473mW1qmPWC93xiEtcBgF563RvFuqLRG/FEufIlzfXP0JhFBX76rcycBhVDqumwEW8epgfy43TcC44sMgvuT4a1IrYNwML Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 03:14:49 -0000 "Asveren, Tolga" writes: > On another note, static configurations (e.g. both IPv4/IPv6 Addresses > are provisioned for a target, by whatever means) and DHCP based > learning of addresses for SIP Servers (RFC3361, RFC3319) should be > considered. So, I think SIP/UDP/DTLS is "allowed" afterall. And it is > connection-oriented, therefore should be covered by happy-earballs > IMHO. At least in regard to RFC 3361/3319, the data carried by DHCP are the addresses or domain names of SIP servers. As such, each is used as an *input* to the RFC 3263 process. The two RFCs contain this identical paragraph, giving an ordering in how they are to be processed: The option MAY contain multiple domain names, but these SHOULD refer to different NAPTR records, rather than different A records. The client MUST try the records in the order listed, applying the mechanism described in Section 4.1 of RFC 3263 [3] for each. The client only resolves the subsequent domain names if attempts to contact the first one failed or yielded no common transport protocols between client and server or denote a domain administratively prohibited by client policy. So it looks like these provide an even higher-level ordering of all the possible targets. And I suppose that the entire set should be subject to Happy Eyeballs processing, rather than each result of 3263 being processed seperately. Dale From nobody Sun Dec 18 19:25:37 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360EE129485 for ; Sun, 18 Dec 2016 19:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 VqXmYkXChiFf for ; Sun, 18 Dec 2016 19:25:35 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0A9129460 for ; Sun, 18 Dec 2016 19:25:35 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with SMTP id IoZyc7x1KGIgtIoZycXynk; Mon, 19 Dec 2016 03:25:34 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-02v.sys.comcast.net with SMTP id IoZicF8yBi6pxIoZkctLJU; Mon, 19 Dec 2016 03:25:34 +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 uBJ3OHDb027223; Sun, 18 Dec 2016 22:24:18 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBJ3OHaG027218; Sun, 18 Dec 2016 22:24:17 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 18 Dec 2016 22:24:17 -0500 Message-ID: <87zijs1tzy.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfFEu86JOarSKohNR1nzYR58AGzlzNvOO7NRUXFZpbb3KwORWtIcMDztt2t+hcd+PnvB0isoXsi31+ivD+j/dviAI1JVFW4Tzc+iOOR6ByvBHeajdFlDO cuXuSvc8NT4F4YEZRaxFLuUC9MHCL/cKNvY+baKN/8i9hctWk7aH0hlUbq8smBhIOnJhpppByO/6idemKDV+6AreRDVWtTgFZzY3iZHDGKtFzenKPN6L8PIH Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 03:25:36 -0000 "Asveren, Tolga" writes: > One correction for my previous message: > "SIP+D2U" => "SIPS+D2U" > > And yes, there is yet another IANA Registry to be updated as you > mentioned and some other work, mea culpa. > > There obviously will be a need to extend syntax for relevant SIP > headers/parameters and semantics to use it as one of the valid > protocols. OTOH, I don't think there would be thorny issues and it > would be mostly replicating what has been done/said about other > transport protocols. The question of SIP over DTLS has been discussed before and the idea has been controversial. See, at least, draft-jennings-sip-dtls, with a discussion starting at http://www.ietf.org/mail-archive/web/sip/current/msg11114.html. The major argument put in favor of SIP/DTLS is that a server can easily handle a million clients or more. But Roman Shpount has mentioned a number of shortcomings of DTLS in that environment. My personal feeling is that we'll need to devise a "DTLS Lite" that alleviates the shortcomings of DTLS for that particular environment. After that, the purists may still not like it, but there will be enough practical deployment of SIP-over-DTLS-Lite to overcome their objections. Dale From nobody Sun Dec 18 22:42:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E2B1294A4 for ; Sun, 18 Dec 2016 22:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 127LITiqK6Wy for ; Sun, 18 Dec 2016 22:42:12 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0045.outbound.protection.outlook.com [104.47.42.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD361294EC for ; Sun, 18 Dec 2016 22:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HU7hp+RGhILr4YoVNtznkWr9qmT8cXlo4GlW/j8Y+TM=; b=lMurn+LmEUU5SInaPNb3n+SYvzzSlS6HRNISKnnv0XXcU2PCoIpHTj5uSgChLc88V5oBlkRvmQf8CebcGfNbbnvqH+27JBQnQtzZu5ikwiyMweYRD0yDiKED569a7DD/mdXgg28WVI8MsX6BTDBWb+moNQDDcANXl23b++bsX+k= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 06:42:10 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 06:42:10 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem Thread-Index: AdJZFHrOvyU+dWmrSZmJnOs13D51DgAN34QAAB2sMOA= Date: Mon, 19 Dec 2016 06:42:10 +0000 Message-ID: References: <6C636F5F-F96E-4553-8EAD-31D36CE375BA@edvina.net> In-Reply-To: <6C636F5F-F96E-4553-8EAD-31D36CE375BA@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 02e8eb82-b4af-4802-650f-08d427da289f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:55PTnv5PEFACJ+Z8461r9qyzoQ8j9p67MsevGdsG0IeGYu3MYY/7jIGxGkN5MT7qY06IOpU+poHfU/KQlesE/d0OFSkl33M7Y+lbmgEwkRQNhdmHwndk4WSByZvo0LNxoZyDd4M4Fv29i2VVWvnvEeiARxw1pIr5NhHdkgfs/U+3wQjpF1vXMy6kcXrcWH8Tp3zA4skE5WXyf94E8OKq/w0Yl2rpMaN6l5mY08U4jrZ3jHSamqUhAjqLWuwAYOiXOG0XGuQIk6VNu4J7IFObA+tCnXGI4kRK5+Cqsc0Q85QkJFYK6zHFC1NZaMx6V0g3rb9SH+QMRyTUYEvt0E35GYHhP/p25KPx4eHW9/gcV9x6Ojxds1C7RNL4PD0SA26ZsSeY76F0pUQmKNRU8X8PWfHHccbJ/pQgkXWtElsFxzahOAg3/tk5DNOBi4U6ZsAtmdCErm9WHhDRzQlnfrk+8Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(13464003)(377454003)(24454002)(2900100001)(305945005)(74316002)(66066001)(33656002)(189998001)(7736002)(2906002)(92566002)(99286002)(4326007)(97736004)(106356001)(105586002)(86362001)(76576001)(3280700002)(3660700001)(68736007)(54356999)(6436002)(122556002)(8936002)(6506006)(25786008)(38730400001)(77096006)(2950100002)(6916009)(101416001)(110136003)(6116002)(102836003)(3846002)(9686002)(229853002)(8676002)(81166006)(81156014)(50986999)(76176999)(5660300001)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 06:42:10.1338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 06:42:14 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGxlIEUuIEpvaGFuc3NvbiBb bWFpbHRvOm9lakBlZHZpbmEubmV0XQ0KPiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDE4LCAyMDE2 IDExOjMwIEFNDQo+IFRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0K PiBDYzogT2xsZSBFIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+OyBEYWxlIFIuIFdvcmxleQ0K PiA8d29ybGV5QGFyaWFkbmUuY29tPjsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W3NpcGNvcmVdIEhhcHB5IEV5ZWJhbGxzIGZvciBTSVAgLyBTdW1tYSBCZWF0aXR1ZGluZW0NCj4g DQo+IA0KPiA+IE9uIDE4IERlYyAyMDE2LCBhdCAxNDo0OSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3Zl cmVuQHNvbnVzbmV0LmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPiBpdi0gZHJhZnQtd29ybGV5LXNp cC1oZS1jb25uZWN0aW9uLTAwDQo+ID4gRGVmaW5lcyBTSVAgcmVsYXRlZCBwcm9jZWR1cmVzIHRv IHVzZSBSRkM2NTU1IGZvciBTSVAuDQo+IE9OTFkgZm9yIGNvbm5lY3Rpb24tb3JpZW50ZWQgcHJv dG9jb2xzLg0KPiA+IFRoaXMgaW5jbHVkZXMgcHJvYmluZy9rZWVwLWFsaXZlIGZvciBleGlzdGlu ZyBjb25uZWN0aW9ucywgdXNpbmcgYW4gZXhpc3RpbmcNCj4gY29ubmVjdGlvbiBmb3IgYWxsIHJl cXVlc3RzLg0KPiA+IFdvdWxkIGFueSAiZmFzdC1mYWlsb3ZlciBhZnRlciBjb25uZWN0aW9uIGZh aWx1cmUiLCBlLmcuIHRvd2FyZCB0aGUgc3RhbmRieQ0KPiBzZXJ2ZXIgYWZ0ZXIgZmFpbHVyZSBv ZiB0aGUgcHJpbWFyeSBzZXJ2ZXIsIHJlbGF0ZWQgcHJvY2VkdXJlcyBiZSBpbiBzY29wZT8NCj4g Rm9yIGNvbm5lY3Rpb24gb3JpZW50ZWQgcHJvdG9jb2xzLCBhbnkgcG9zc2libGUNCj4gcmVjb21t ZW5kYXRpb25zL2ltcHJvdmVtZW50cyBpbiB0aGlzIGFyZWEgd291bGQgcHJvYmFibHkgYmUgbGlt aXRlZCB0bw0KPiByZXVzaW5nIHRoZSBUTFMgY29ubmVjdGlvbi4gSXMgdGhlcmUgYW55dGhpbmcg U0lQIHNwZWNpZmljLCB3aGljaCBjb3VsZCBoZWxwDQo+IGhlcmU/DQo+IElzbuKAmXQgdGhhdCB3 aHkgd2UgaGF2ZSBTSVAgT3V0Ym91bmQ/DQpbVE9MR0FdIEhvc3RpbmcgbXVsdGlwbGUgcmVnaXN0 cmF0aW9uIGluc3RhbmNlcyBpcyBjb3N0bHkgYW5kIG5vdCBkZXNpcmVkL3ByZWZlcnJlZCBmb3Ig bWFueSBjYXNlcy4gSSB3YXMgdGhpbmtpbmcgbW9yZSBhbG9uZyB0aGUgbGluZXMgb2YgIkhvdyB0 byBmYWlsb3ZlciB0aGUgVExTIGNvbm5lY3Rpb24gd2l0aCBtaW5pbWFsIHN0YXRlIHN5bmNocm9u aXphdGlvbiIsIHdoaWNoIG1heS9tYXkgbm90IGVuZCB1cCByZXF1aXJpbmcgbmV3IHByb2NlZHVy ZXMuDQo= From nobody Sun Dec 18 22:49:14 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAF012985F for ; Sun, 18 Dec 2016 22:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 KH1w7PLEysV2 for ; Sun, 18 Dec 2016 22:49:12 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0053.outbound.protection.outlook.com [104.47.42.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD187129858 for ; Sun, 18 Dec 2016 22:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4ju+DcKQQ5miOMpECVHQuyqAaOBpfJJqtKm33yyfSIs=; b=LJGFrrjOUC5vDra4LOoJDGd34NBp20lx1SYdtjPKQjZpcIdbKwSzzmQLx+Jyfu0X1GgZGkreYSFHUYRVhG0sjH7ptHRzZab0b2uREPms371/E/KIV5MBkSN8wP4EMQcxojXBWTY4G74S8WGH4MP6+7CVmh7iLalXjW+tq9Gnzo8= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 06:49:10 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 06:49:10 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport Thread-Index: AQHSWSl+tEa6q1kNm0GLCEVThq2kbKENuKdwgAAkAgCAAA1uAIAA6lZQ Date: Mon, 19 Dec 2016 06:49:10 +0000 Message-ID: References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> <6BBEB7E7-D02B-44A4-960C-077AC51F3BD0@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: ca5b678d-9b89-4b44-f5df-08d427db233b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:icr3OQvR7AoShwAioqfjPVwxgaB8FeJbyHufHKysFxooVXvvr5tOJtZXwWYBmQGoPLxlElW/G8icnsE7QGPK5iCDbkVV81fEKBUXSw6z5ieU6lDSUXyrZYfjUJ6QF6PhxkhrD2oWMrGibsaUxZrJdEJFdSS/uvu81IWXwLJBJVCN6oo27s/HMQORIKYialn0JfXOJdd1BXOrCdsAssmCWe/Nz1KognTmRe2yh+HTRZBbj82qo8xA97APE+RlWlfJZZgIKYdIqt+GN7EGnA5ZmXkFk0N3AKslACK3TS8bWBnqoJIk4UUYfiUoulugmScPx1Vg8kU+/cp94K38z6ib1gwBRvtVzJKNiBvEDIS8/MjImVez3nhcj9n0+oi6LBH0nH6pxtHIjQUhHIwylpIfk+CHcjc9fD0ztHkLJ+ZWB1p3iAycur6dx83P9fM0qs7vJMEGRLEct4qzvsC5faYJVg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(13464003)(377454003)(24454002)(1720100001)(8666005)(2900100001)(305945005)(107886002)(74316002)(66066001)(33656002)(189998001)(7736002)(2906002)(92566002)(99286002)(93886004)(97736004)(5001770100001)(106116001)(106356001)(105586002)(86362001)(76576001)(3280700002)(3660700001)(2501003)(68736007)(54356999)(6436002)(122556002)(8936002)(6506006)(25786008)(38730400001)(77096006)(2950100002)(101416001)(6116002)(102836003)(3846002)(9686002)(229853002)(8676002)(81166006)(81156014)(50986999)(76176999)(5660300001)(7696004)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 06:49:10.7214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 06:49:13 -0000 SSB3aWxsIHRyeSB0byBwcmVwYXJlIGFuIGluaXRpYWwgZHJhZnQuDQoNCkFuZCBtZWFud2hpbGUs IGl0IHdvdWxkIGJlIGdyZWF0IGlmIHRoZSBjaGFpcnMgY2FuIGRlY2lkZSB3aGV0aGVyIHJlLWNo YXJ0ZXJpbmcgaXMgbmVlZGVkLiBJIHRoaW5rIHRoaXMgd29yayBpcyAiaW4tc2NvcGUiIGFzIGZh ciBhcyBpdHMgY29udGVudCBidXQgb2J2aW91c2x5IGlzIG5vdCBpbiB0aGUgbGlzdCBvZiBjdXJy ZW50IGdvYWxzLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNCj4gU2VudDogU3VuZGF5LCBEZWNlbWJlciAxOCwgMjAx NiAxMTo0NiBBTQ0KPiBUbzogc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNv cmVdIEhhcHB5IEV5ZWJhbGxzIGZvciBTSVAgLSBEVExTIGFzIGEgU0lQIHRyYW5zcG9ydA0KPiAN Cj4gT24gMTIvMTgvMTYgMTA6NTcgQU0sIE9sbGUgRS4gSm9oYW5zc29uIHdyb3RlOg0KPiA+DQo+ ID4+IE9uIDE4IERlYyAyMDE2LCBhdCAxNDo1MiwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNv bnVzbmV0LmNvbT4NCj4gd3JvdGU6DQo+ID4+DQo+ID4+IFllcywgZGVmaW5pdGVseSB1c2VmdWwg aW4gcHJhY3RpY2UuIEkgY2VydGFpbmx5IGFtIGludGVyZXN0ZWQgaW4gd29ya2luZyBvbg0KPiB0 aGUgbmVlZGVkIHNwZWNpZmljYXRpb24uIElzIHRoZXJlIGEgcmVhc29uIHdoeSB0aGUgd29yayBz aG91bGQgbm90IHN0YXJ0IGFzDQo+IGEgcGFyYWxsZWwgYWN0aXZpdHk/DQo+ID4gTm8sIGlmIHRo ZXJlIGFyZSBwZW9wbGUgaW50ZXJlc3RlZCB0aGF04oCZcyBmaW5lLiBJIHN1c3BlY3QgaXQgaGFz IHRvIHN0YXJ0IGluDQo+IGRpc3BhdGNoLCBidXQgdGhlIGNoYWlycyBjYW4gZXhwbGFpbiBtb3Jl Lg0KPiANCj4gSSBkb24ndCBiZWxpZXZlIGl0IG11c3Qgc3RhcnQgaW4gRGlzcGF0Y2guIEl0IGNs ZWFybHkgZmFsbHMgaW4gc2NvcGUgb2Ygc2lwY29yZSwNCj4gZXZlbiB3aXRob3V0IHRoZSByZWNl bnQgcmVjaGFydGVyLiBCdXQgSSB0aGluayBpdCB3aWxsIG5lZWQgYSBuZXcgbWlsZXN0b25lLg0K PiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+ID4gL08NCj4gPj4NCj4gPj4gVGhhbmtzLA0K PiA+PiBUb2xnYQ0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ IEZyb206IE9sbGUgRS4gSm9oYW5zc29uIFttYWlsdG86b2VqQGVkdmluYS5uZXRdDQo+ID4+PiBT ZW50OiBTdW5kYXksIERlY2VtYmVyIDE4LCAyMDE2IDc6MjMgQU0NCj4gPj4+IFRvOiBBc3ZlcmVu LCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KPiA+Pj4gQ2M6IE9sbGUgRSBKb2hhbnNz b24gPG9lakBlZHZpbmEubmV0PjsgRGFsZSBSLiBXb3JsZXkNCj4gPj4+IDx3b3JsZXlAYXJpYWRu ZS5jb20+OyBzaXBjb3JlQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEhh cHB5IEV5ZWJhbGxzIGZvciBTSVAgLSBEVExTIGFzIGEgU0lQDQo+ID4+PiB0cmFuc3BvcnQNCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4+IE9uIDE4IERlYyAyMDE2LCBhdCAxMjoyMCwgQXN2ZXJlbiwgVG9s Z2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4NCj4gPj4+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4g T25lIGNvcnJlY3Rpb24gZm9yIG15IHByZXZpb3VzIG1lc3NhZ2U6DQo+ID4+Pj4gIlNJUCtEMlUi ID0+ICJTSVBTK0QyVSINCj4gPj4+Pg0KPiA+Pj4+IEFuZCB5ZXMsIHRoZXJlIGlzIHlldCBhbm90 aGVyIElBTkEgUmVnaXN0cnkgdG8gYmUgdXBkYXRlZCBhcyB5b3UNCj4gPj4+IG1lbnRpb25lZCBh bmQgc29tZSBvdGhlciB3b3JrLCBtZWEgY3VscGEuDQo+ID4+Pj4gVGhlcmUgb2J2aW91c2x5IHdp bGwgYmUgYSBuZWVkIHRvIGV4dGVuZCBzeW50YXggZm9yIHJlbGV2YW50IFNJUA0KPiA+Pj4gaGVh ZGVycy9wYXJhbWV0ZXJzIGFuZCBzZW1hbnRpY3MgdG8gdXNlIGl0IGFzIG9uZSBvZiB0aGUgdmFs aWQNCj4gcHJvdG9jb2xzLg0KPiA+Pj4gT1RPSCwgSSBkb24ndCB0aGluayB0aGVyZSB3b3VsZCBi ZSB0aG9ybnkgaXNzdWVzIGFuZCBpdCB3b3VsZCBiZQ0KPiA+Pj4gbW9zdGx5IHJlcGxpY2F0aW5n IHdoYXQgaGFzIGJlZW4gZG9uZS9zYWlkIGFib3V0IG90aGVyIHRyYW5zcG9ydA0KPiBwcm90b2Nv bHMuDQo+ID4+Pg0KPiA+Pj4gRGFsZSBhbmQgSSBoYWQgYSBkaXNjdXNzaW9uIGFib3V0IGl0IGF0 IFNJUGl0IGFuZCBpdOKAmXMgYW4NCj4gPj4+IGludGVyZXN0aW5nIG1peCBvZiBjb25uZWN0aW9u LWxlc3MgYW5kIGNvbm5lY3Rpb24tb3JpZW50ZWQgdGhhdCBuZWVkcw0KPiBzb21lIGRvY3VtZW50 YXRpb24uDQo+ID4+PiBCdXQgSSBkbyB0aGluayBpdCB3aWxsIGhlbHAgYSBsb3Qgb2YgbGFyZ2Ut c2NhbGUgcGxhdGZvcm1zLg0KPiA+Pj4NCj4gPj4+IC9PDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3Ms DQo+ID4+Pj4gVG9sZ2ENCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+Pj4+PiBGcm9tOiBPbGxlIEUuIEpvaGFuc3NvbiBbbWFpbHRvOm9lakBlZHZpbmEubmV0 XQ0KPiA+Pj4+PiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDE4LCAyMDE2IDU6NTggQU0NCj4gPj4+ Pj4gVG86IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+DQo+ID4+Pj4+IENj OiBPbGxlIEUgSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD47IERhbGUgUi4gV29ybGV5DQo+ID4+ Pj4+IDx3b3JsZXlAYXJpYWRuZS5jb20+OyBzaXBjb3JlQGlldGYub3JnDQo+ID4+Pj4+IFN1Ympl Y3Q6IFJlOiBbc2lwY29yZV0gSGFwcHkgRXllYmFsbHMgZm9yIFNJUA0KPiA+Pj4+Pg0KPiA+Pj4+ Pg0KPiA+Pj4+Pj4gT24gMTggRGVjIDIwMTYsIGF0IDEwOjUwLCBBc3ZlcmVuLCBUb2xnYSA8dGFz dmVyZW5Ac29udXNuZXQuY29tPg0KPiA+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4g RFRMUyBmb3IgU0lQL1VEUCBpcyBub3Qgc3BlY2lmaWVkIHlldCwgc28gYXMgb2Ygbm93IHRoYXQg aXMgb3V0IG9mDQo+IHNjb3BlLg0KPiA+Pj4+Pj4+IEJ1dCBJIGRvIGFncmVlIHRoYXQgaXQgd2ls bCBiZSBpbnRlcmVzdGluZy4NCj4gPj4+Pj4+IFtUT0xHQV0gUHJvYmFibHkgeW91IGFyZSByZWZl cnJpbmcgdG8gIlNJUCtEMlUiIGN1cnJlbnRseSBub3QNCj4gPj4+Pj4+IGJlaW5nIGluIHRoZQ0K PiA+Pj4+PiBJQU5BIFJlZ2lzdHJ5LiBJIHRoaW5rIGl0IHNob3VsZC4gSSB3aWxsIGNyYWZ0IGEg ZHJhZnQgZm9yIHRoYXQuDQo+ID4+Pj4+PiBPbiBhbm90aGVyIG5vdGUsIHN0YXRpYyBjb25maWd1 cmF0aW9ucyAoZS5nLiBib3RoIElQdjQvSVB2Ng0KPiA+Pj4+Pj4gQWRkcmVzc2VzIGFyZQ0KPiA+ Pj4+PiBwcm92aXNpb25lZCBmb3IgYSB0YXJnZXQsIGJ5IHdoYXRldmVyIG1lYW5zKSBhbmQgREhD UCBiYXNlZA0KPiA+Pj4+PiBsZWFybmluZyBvZiBhZGRyZXNzZXMgZm9yIFNJUCBTZXJ2ZXJzIChS RkMzMzYxLCBSRkMzMzE5KSBzaG91bGQgYmUNCj4gY29uc2lkZXJlZC4NCj4gPj4+Pj4gU28sICBJ IHRoaW5rIFNJUC9VRFAvRFRMUyBpcyAiYWxsb3dlZCIgYWZ0ZXJhbGwuIEFuZCBpdCBpcw0KPiA+ Pj4+PiBjb25uZWN0aW9uLW9yaWVudGVkLCB0aGVyZWZvcmUgc2hvdWxkIGJlIGNvdmVyZWQgYnkg aGFwcHktZWFyYmFsbHMNCj4gPj4+IElNSE8uDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZXJlIGlzIHNp bXBseSBubyBzdGFuZGFyZCBmb3IgRFRMUyBhcyBhIHRyYW5zcG9ydCBmb3IgU0lQLg0KPiA+Pj4+ PiBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NpcC1wYXJhbWV0ZXJzL3NpcC0NCj4g Pj4+Pj4gcGFyYW1ldGVycy54aHRtbCNzaXAtdHJhbnNwb3J0DQo+ID4+Pj4+DQo+ID4+Pj4+IEkg YWdyZWUgaXQgd291bGQgYmUgYSBnb29kIHRoaW5nLCBidXQgaXQgcmVxdWlyZXMgbW9yZSB3b3Jr IHRoYW4NCj4gPj4+Pj4gYWRkaW5nIGl0IHRvIHRoZSBOQVBUUiByZWdpc3RyeS4NCj4gPj4+Pj4g L08NCj4gPj4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPiBzaXBjb3JlQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID4N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From nobody Sun Dec 18 22:51:11 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8AE12985F for ; Sun, 18 Dec 2016 22:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 j__8PSAAFvuB for ; Sun, 18 Dec 2016 22:51:08 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0081.outbound.protection.outlook.com [104.47.42.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82B91294EC for ; Sun, 18 Dec 2016 22:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g1aXGeduoVS7c1shAPRhjmVvV3/Q5CLmVL/tEJkvE00=; b=GxjY1yQmr3Z5muheEIablcWUPJ38V0+JXQEBqjJolFDZgmo7lSwEbZZiL22jf6OPyLIgYN2cu2J8YX+OQT6sUKcQnhpDmYriDdN2pxbYaKZMCjNapwIieIlTeKjOAgfPYm0fpzX9p5/tlM9c95lIX+gQSw2sqaXyp03QBTfo8+4= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 06:45:23 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 06:45:23 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem Thread-Index: AdJZFHrOvyU+dWmrSZmJnOs13D51DgAN8f4AAB2svdA= Date: Mon, 19 Dec 2016 06:45:23 +0000 Message-ID: References: <86BDF0AB-DA41-4C83-8D1D-56EC8FE46C02@edvina.net> In-Reply-To: <86BDF0AB-DA41-4C83-8D1D-56EC8FE46C02@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: b6f0bd59-c3e8-4456-0331-08d427da9be9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:I1jD1qTJ8qmd3LEm1j8HSI37PUdOC+H+7CZxFka1xG95knjRD05l/RP+4bPKrs/Z22epMX/LrqNTm/UpONPKsq7stxUrSRuCsp2KYGrtUbx1wJiNqp7tLLMmT2odp+/GvvzpWplv0yT1cvc+5q39pvMOtAWhzGvX3xJ3V/UrbP+l9vdHbgEmfnJIDpSwKDIbjADDplFhtBLaRMpq6MQi2fQ+/st80/74iXhR7k+zP+GIj64Zzw3W+/tpu+8DCb72udeeyQvfK4UoB/FAFJEJcHW41Os7B5XB86xz9yM/GdgKkvZa606GNiEe1s71H7dKSr5AhbqJYQoXE/+hU1vdoDMJqssFCI2EXYcYCNW79QTBVj3q0uh7s/lpDHGaolpwlrx8Wg3HCAl5v6eEHKOLK0WdDrHnjAUE2l7RqPWQYqI55OI37lCvwNrDIhvZfHVTOeGpXI8ql79P3y3OI3t4xA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(13464003)(377454003)(24454002)(57704003)(2900100001)(305945005)(74316002)(66066001)(33656002)(189998001)(7736002)(2906002)(92566002)(99286002)(4326007)(97736004)(106356001)(105586002)(86362001)(76576001)(3280700002)(3660700001)(68736007)(54356999)(6436002)(122556002)(8936002)(6506006)(25786008)(38730400001)(77096006)(2950100002)(6916009)(101416001)(110136003)(6116002)(102836003)(3846002)(9686002)(229853002)(8676002)(81166006)(81156014)(50986999)(76176999)(5660300001)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 06:45:23.6444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 06:51:09 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGxlIEUuIEpvaGFuc3NvbiBb bWFpbHRvOm9lakBlZHZpbmEubmV0XQ0KPiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDE4LCAyMDE2 IDExOjMyIEFNDQo+IFRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0K PiBDYzogT2xsZSBFIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+OyBEYWxlIFIuIFdvcmxleQ0K PiA8d29ybGV5QGFyaWFkbmUuY29tPjsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W3NpcGNvcmVdIEhhcHB5IEV5ZWJhbGxzIGZvciBTSVAgLyBTdW1tYSBCZWF0aXR1ZGluZW0NCj4g DQo+IA0KPiA+IE9uIDE4IERlYyAyMDE2LCBhdCAxNDo0OSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3Zl cmVuQHNvbnVzbmV0LmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPiBCKSBVc2Ugb2YgTXVsdGlwbGUg SW50ZXJmYWNlcw0KPiA+IHYtIEkgdGhpbmsgdGhlIGlkZWFsIHBsYWNlIHRvIGNvdmVyIHRoaXMg d291bGQgYmUgUkZDNjU1NS1iaXMgKGFsc28gYnkNCj4gY29uc2lkZXJpbmcgb3RoZXIgcmVzdHJp Y3Rpb25zIGFzIG1lbnRpb25lZCBpbiBpaS0gYWJvdmUpLiBJIHdvdWxkbid0IHRoaW5rIHRoYXQN Cj4gdGhlcmUgd291bGQgYmUgYSBuZWVkIGZvciBkZWZpbmluZyBhbnl0aGluZyBuZXcgaW4gZHJh ZnQtd29ybGV5LXNpcC1oZS0NCj4gY29ubmVjdGlvbi0wMCAoPykuDQo+IA0KPiBBIHF1ZXN0aW9u IGhlcmUgaXMgaG93IHRoaXMgd29ya3Mgd2l0aCBTSVAgb3V0Ym91bmQgLSBkbyB3ZSBuZWVkIHR3 bw0KPiBvdXRib3VuZCBjb25uZWN0aW9ucyBwZXIgaW50ZXJmYWNlPyBIb3cgZG8gd2UgaGFuZGxl IHJlZy1pZCBhbmQgZmFpbG92ZXINCj4gaW4gdGhhdCBjYXNlPw0KPiANCj4gSXTigJlzIGxpa2Ug aW52ZW50aW5nIElDRSBmb3IgU0lQ4oCmIDotKQ0KW1RPTEdBXSBZZXMsIGtpbmQgb2YuIE9UT0gg LWxpa2UgSSBzdGF0ZWQgaW4gYW5vdGhlciBtZXNzYWdlLSwgSSBhbSBub3Qga2VlbiBhYm91dCBz b2x1dGlvbnMvZW5oYW5jZW1lbnRzIHJlcXVpcmluZyBob3N0aW5nIG9mIG11bHRpcGxlIHJlZ2lz dHJhdGlvbiBpbnN0YW5jZXMuIEluIGdlbmVyYWwsIEkgdGhpbmsgZWFjaCBhZGRyZXNzIGZhbWls eS9pbnRlcmZhY2UgdHVwbGUgc2hvdWxkIGJlIGhhbmRsZWQgYXMgYSBwb3NzaWJsZSBjb21iaW5h dGlvbi4gVGhlcmUgKmNvdWxkKiBiZSBjYXNlcyB3aGVyZSB0aGVyZSBpcyBhIG5lZWQgdG8gZXh0 ZW5kIHRoZSB0dXBsZSB3aXRoIHRoZSBkZXN0aW5hdGlvbiByZWxhdGVkIGluZm9ybWF0aW9uIGFz IHdlbGwgKGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhhdCB3b3VsZCBoYXBwZW4gb2Z0ZW4g ZW5vdWdoIGluIHByYWN0aWNlKS4NCg== From nobody Mon Dec 19 00:26:59 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E1C1294C8 for ; Mon, 19 Dec 2016 00:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 nru1U9iwaKRs for ; Mon, 19 Dec 2016 00:26:52 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0047.outbound.protection.outlook.com [104.47.34.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F78C126B6D for ; Mon, 19 Dec 2016 00:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1QQ+DkWVuws/jrjrGhuqrrA520QBL0cvQo0DTXJImQo=; b=EpiWDy5nHGcItXgvQKTaH2ZWe3hnc/MEwqemhEojmQwLDyuotukgcJ2oYxjQTPTBRFoRXoaOTCDUe2knvKXckPl/VXT0/wF5JcJz1adFAdPo3w13VO+SK119QRn43TwPnQp7F2pyfWxBo1r+Cs308TphkoDCuTdZ5iyU56lIjcU= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 08:26:50 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 08:26:50 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" , "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport Thread-Index: AQHSWZjbtEa6q1kNm0GLCEVThq2kbKEO1LCA Date: Mon, 19 Dec 2016 08:26:50 +0000 Message-ID: References: (oej@edvina.net) <87mvfs3ddn.fsf@hobgoblin.ariadne.com> In-Reply-To: <87mvfs3ddn.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 12281329-c6dd-477c-4e15-08d427e8c81e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:aqktVfKG6vo7GE35cJBXyB4CzLcrgfcN6dKTz30ViOxtCAXVZ5RS6vn7iVp+aw7ha6vdjQG36hHdCEhhEyTd6MK7aP6si67zYq8kK3bv6AXQ9VkYxaQsNhtvUFcNcCcVCQBq9bjIjdcRJqrEfg/UnovGJSOY8mE32qeIw4lRlvKiscBW+TLHpabvHoQhnF7WQ1kLQ7c0TXGNL6+9xjG1G7OT/56tgZBEJZNhKdEei56rAaeBYgNcP5+gARYLCl06tTOUALAZ0NJ29Rh7/y/ojkfuptyX7eZUhpnYY5ulKUvcunNUm1xVEKKLO2q7jZLAm3aZqk6ZrQ5iNav/VM4kN4fJHVG52O6XBK0X5sazdfAFzFPfWytttjgPdpdOciPC2yNYL4jTWm+fyC+c7UVxeDf5XbLSC7i49YzlFxQd3ef2QadCjIHXpkO9+NKlhwbzRPyiG7tCSx/TkRdLAu1Dyg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377454003)(13464003)(199003)(66066001)(33656002)(2950100002)(25786008)(77096006)(3280700002)(3660700001)(7696004)(92566002)(229853002)(2900100001)(76176999)(122556002)(38730400001)(76576001)(4326007)(5660300001)(101416001)(54356999)(50986999)(5001770100001)(2906002)(106356001)(97736004)(74316002)(7736002)(305945005)(551934003)(106116001)(189998001)(9686002)(81156014)(81166006)(68736007)(105586002)(6436002)(102836003)(6116002)(6506006)(3846002)(86362001)(8936002)(8676002)(99286002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 08:26:50.8146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 08:26:56 -0000 > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Sunday, December 18, 2016 8:40 PM > To: Olle E. Johansson > Cc: Asveren, Tolga ; sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport >=20 > "Olle E. Johansson" writes: > >> One correction for my previous message: > >> "SIP+D2U" =3D> "SIPS+D2U" > >> > >> There obviously will be a need to extend syntax for relevant SIP > >> headers/parameters and semantics to use it as one of the valid > >> protocols. OTOH, I don't think there would be thorny issues and it > >> would be mostly replicating what has been done/said about other > >> transport protocols. > > > > Dale and I had a discussion about it at SIPit and it's an interesting > > mix of connection-less and connection-oriented that needs some > > documentation. But I do think it will help a lot of large-scale platfor= ms. >=20 > Though I remember discussions with Roman Shpount that DTLS has some > serious deficiencies for really large-scale systems. It seems like a des= ign > adjustment might be needed for DTLS to be really usable for SIP signaling= . > There was a discussion on Sipcore back in March. [TOLGA] IITC, discussions were around how to provide fast failover when DTL= S is used without requiring per-transaction state synchronization. Actually= , we (you, Roman and I had some off-line discussions regarding this. A sing= le-RTT failover indeed may require some changes but that is for an improvem= ent on failover timing rather than to address a generic deficiency in DTLS = (and changes do not necessarily need to be in DTLS itself IMHO). From nobody Mon Dec 19 03:54:03 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675301297AA for ; Mon, 19 Dec 2016 03:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 jWDhN8BfGqkH for ; Mon, 19 Dec 2016 03:53:53 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0061.outbound.protection.outlook.com [104.47.41.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F10129795 for ; Mon, 19 Dec 2016 03:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0+x6DIYXk95kaHso98AvkkCcDiF30xP9RzGMHfrtwTs=; b=u7N3oIOyRgZdfWJZUZlzy4+ifUC2J5JJSlbFHnM8ECPTfevyU7ccEfwCY9Yc/C722Hy/NxeFiAPCUkk1/zQkyyNIyP595VXKMHYyOedAvLSKiFj94cqoo9aFG37gThbqnTVUxpj77W8YfhVQeKRDaipPK9pXBfeb7+fctJFaMAc= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 11:53:51 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 11:53:51 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem Thread-Index: AdJZFHrOvyU+dWmrSZmJnOs13D51DgAN8f4AAB2svdAACtNrIA== Date: Mon, 19 Dec 2016 11:53:50 +0000 Message-ID: References: <86BDF0AB-DA41-4C83-8D1D-56EC8FE46C02@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 42088eb3-819b-43a8-4d4b-08d42805b31f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:d92vG4Ggpcef0u6KqLjjW74Gmb3lgeKgn6ey4hv8R2nSHqD5EOr5IkIwg4PNs9ZgZLn0sdX+X8Qdn4+mu/t0C4YadM6miUe0jWQEoP5VcwQbzCo3skuFa0hxKnh+GtLYf4YXPOkMQZWYWE7mgp+TUInY/BrHjNFkkcu3tA6rvVRw09sp5t6PRcTbW8qfCu2/Y8Svy1lKzISk902SueROZI0YDPiat9HIirYFUSsKbbVU38hKQ82V88WISu0F50ILJUyImTkxEycqOnfOdPcBHaQ36mozQD2NcbJnhE694T1qfeutrKjW8A9fVEbWC6kpeubI8ufMUVU2bTVikUVV3V4OeNZIZm2sgo39F6BhMMct4i2aZiDQnr9r1od7xdD0iVom5yXE3hdkPWCqBQGNRjauYwXXyCohsBnNsUyZ0QPhYUU+tbtYmwZOUi/eyvVJ46/jtPgmeFr5iYQNkyJWCA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(57704003)(110136003)(2906002)(9686002)(122556002)(25786008)(66066001)(7696004)(305945005)(8676002)(68736007)(5660300001)(81166006)(81156014)(101416001)(50986999)(54356999)(76176999)(4326007)(74316002)(33656002)(6916009)(8936002)(7736002)(3280700002)(76576001)(2900100001)(3660700001)(6116002)(102836003)(189998001)(92566002)(3846002)(99286002)(106356001)(105586002)(97736004)(77096006)(6506006)(6436002)(38730400001)(229853002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 11:53:50.9021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 11:54:01 -0000 PiA+ID4gQikgVXNlIG9mIE11bHRpcGxlIEludGVyZmFjZXMNCj4gPiA+IHYtIEkgdGhpbmsgdGhl IGlkZWFsIHBsYWNlIHRvIGNvdmVyIHRoaXMgd291bGQgYmUgUkZDNjU1NS1iaXMgKGFsc28NCj4g PiA+IGJ5DQo+ID4gY29uc2lkZXJpbmcgb3RoZXIgcmVzdHJpY3Rpb25zIGFzIG1lbnRpb25lZCBp biBpaS0gYWJvdmUpLiBJIHdvdWxkbid0DQo+ID4gdGhpbmsgdGhhdCB0aGVyZSB3b3VsZCBiZSBh IG5lZWQgZm9yIGRlZmluaW5nIGFueXRoaW5nIG5ldyBpbg0KPiA+IGRyYWZ0LXdvcmxleS1zaXAt aGUtDQo+ID4gY29ubmVjdGlvbi0wMCAoPykuDQo+ID4NCj4gPiBBIHF1ZXN0aW9uIGhlcmUgaXMg aG93IHRoaXMgd29ya3Mgd2l0aCBTSVAgb3V0Ym91bmQgLSBkbyB3ZSBuZWVkIHR3bw0KPiA+IG91 dGJvdW5kIGNvbm5lY3Rpb25zIHBlciBpbnRlcmZhY2U/IEhvdyBkbyB3ZSBoYW5kbGUgcmVnLWlk IGFuZA0KPiA+IGZhaWxvdmVyIGluIHRoYXQgY2FzZT8NCj4gPg0KPiA+IEl04oCZcyBsaWtlIGlu dmVudGluZyBJQ0UgZm9yIFNJUOKApiA6LSkNCj4gW1RPTEdBXSBZZXMsIGtpbmQgb2YuIE9UT0gg LWxpa2UgSSBzdGF0ZWQgaW4gYW5vdGhlciBtZXNzYWdlLSwgSSBhbSBub3Qga2Vlbg0KPiBhYm91 dCBzb2x1dGlvbnMvZW5oYW5jZW1lbnRzIHJlcXVpcmluZyBob3N0aW5nIG9mIG11bHRpcGxlIHJl Z2lzdHJhdGlvbg0KPiBpbnN0YW5jZXMuIEluIGdlbmVyYWwsIEkgdGhpbmsgZWFjaCBhZGRyZXNz IGZhbWlseS9pbnRlcmZhY2UgdHVwbGUgc2hvdWxkIGJlDQo+IGhhbmRsZWQgYXMgYSBwb3NzaWJs ZSBjb21iaW5hdGlvbi4gVGhlcmUgKmNvdWxkKiBiZSBjYXNlcyB3aGVyZSB0aGVyZSBpcyBhDQo+ IG5lZWQgdG8gZXh0ZW5kIHRoZSB0dXBsZSB3aXRoIHRoZSBkZXN0aW5hdGlvbiByZWxhdGVkIGlu Zm9ybWF0aW9uIGFzIHdlbGwNCj4gKGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhhdCB3b3Vs ZCBoYXBwZW4gb2Z0ZW4gZW5vdWdoIGluIHByYWN0aWNlKS4NCkJUVywgSSBkb27igJl0IHRoaW5r IHRoaXMgaXMgIlNJUCBzcGVjaWZpYyIuIEl0IG5lZWRzIHRvIGJlIGRlZmluZWQgaW4gYSBnZW5l cmljIHdheSBoZW5jZSB3aHkgSSB3b3VsZCB0aGluayBzb21ldGhpbmcgZm9yIFJGQzY1NTViaXMu DQo= From nobody Mon Dec 19 10:11:07 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DBF129598 for ; Mon, 19 Dec 2016 10:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 1yz-NcDuXVmS for ; Mon, 19 Dec 2016 10:11:04 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525F712957B for ; Mon, 19 Dec 2016 10:11:04 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id q68so23745300qki.1 for ; Mon, 19 Dec 2016 10:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zyJ+JzM/jUkEu090k37j3j26Q881ESn6nFy2AM6icj4=; b=WghqC2liT8E1GdduzPqE+n/U8e/CnxyI5BZ0Qa0OYjjhyUKNrn2T1/LlcIY3JZmU2v +C5d2AAchIlHahhfZlikUraaORFGiRwCXzyLLZqAASuEgePitLi0BEkzQ90VNeDILcGb qNUxv1Qh3GLltFSwsLYrm30X+WMUxBVVRqjhYNdSCkWj6lS0QsUAZH57Fha82NM9WAJI Ig37w9KnMVO73edE34pk6/ewcX9E9pI6s1xi5dAb1+GVrjuSdtpB4f5185lvCGBZ43oe CahMpv0ENw1ymgUU85ZFnyj2UNPxKlJ+dDIeWIP5rlkoJizVG9OetZ0YLqD8ws63kgdy /lbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zyJ+JzM/jUkEu090k37j3j26Q881ESn6nFy2AM6icj4=; b=koJqDXLmJyXiIwnUw2RXjjmDPDbJgDmO6oCXMPiQUKJpiMmivW+Gf0KjrnIoUEguTE MpnsVjVWX6fdtanLaolf8qZsoRfhPrk+yLyMNyqd4yxiSRWrDienA50CXSHNvnEqczb8 IifPiKDCeXayq/GkywyenciQ1extZbFIQtZc6LyLPjX6k8vsFgRjvMPUH1ThhE0t71Tx sojaV2nlXq9OMQa1A2RlsskQitqBWKaEgIf3lAjmq0dHum7USyPWDuE/cgmwNRXNfPYl V22A9+JakkacIYWH2SDGiCt77jPSXOPDyIcPNH7rrpO/x1UI9vEz5HlS05jqi/bwBsTB 0K+w== X-Gm-Message-State: AIkVDXLsNsOmuI/RmDvSCsHCSVqiJ3txN+X38v1UKk5S8R0XEsuwf3o15zya1LeqqMuoqg== X-Received: by 10.233.239.194 with SMTP id d185mr1897074qkg.122.1482171063260; Mon, 19 Dec 2016 10:11:03 -0800 (PST) Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com. [209.85.216.175]) by smtp.gmail.com with ESMTPSA id w34sm11059738qtw.10.2016.12.19.10.11.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 10:11:02 -0800 (PST) Received: by mail-qt0-f175.google.com with SMTP id p16so152386288qta.0 for ; Mon, 19 Dec 2016 10:11:02 -0800 (PST) X-Received: by 10.200.54.4 with SMTP id m4mr15953840qtb.141.1482171062138; Mon, 19 Dec 2016 10:11:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.136.230 with HTTP; Mon, 19 Dec 2016 10:11:01 -0800 (PST) In-Reply-To: References: <87mvfs3ddn.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Mon, 19 Dec 2016 13:11:01 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a11357756a7c571054406d73e Archived-At: Cc: "Dale R. Worley" , "Olle E. Johansson" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:11:06 -0000 --001a11357756a7c571054406d73e Content-Type: text/plain; charset=UTF-8 On Mon, Dec 19, 2016 at 3:26 AM, Asveren, Tolga wrote: > > -----Original Message----- > > From: Dale R. Worley [mailto:worley@ariadne.com] > > Sent: Sunday, December 18, 2016 8:40 PM > > To: Olle E. Johansson > > Cc: Asveren, Tolga ; sipcore@ietf.org > > Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport > > > > "Olle E. Johansson" writes: > > >> One correction for my previous message: > > >> "SIP+D2U" => "SIPS+D2U" > > >> > > >> There obviously will be a need to extend syntax for relevant SIP > > >> headers/parameters and semantics to use it as one of the valid > > >> protocols. OTOH, I don't think there would be thorny issues and it > > >> would be mostly replicating what has been done/said about other > > >> transport protocols. > > > > > > Dale and I had a discussion about it at SIPit and it's an interesting > > > mix of connection-less and connection-oriented that needs some > > > documentation. But I do think it will help a lot of large-scale > platforms. > > > > Though I remember discussions with Roman Shpount that DTLS has some > > serious deficiencies for really large-scale systems. It seems like a > design > > adjustment might be needed for DTLS to be really usable for SIP > signaling. > > There was a discussion on Sipcore back in March. > [TOLGA] IITC, discussions were around how to provide fast failover when > DTLS is used without requiring per-transaction state synchronization. > Actually, we (you, Roman and I had some off-line discussions regarding > this. A single-RTT failover indeed may require some changes but that is for > an improvement on failover timing rather than to address a generic > deficiency in DTLS (and changes do not necessarily need to be in DTLS > itself IMHO). > > The question we need to answer is what makes SIP-over-DTLS better then SIP-over-TLS. For all practical purposes SIP-over-DTLS combines downsides of SIP-over-TLS (connection oriented, cannot fail-over without extensive state sharing) with downsides of SIP-over-UDP (unreliable, cannot be used to transport large messages). Unless you can come up with a compelling reason why SIP-over-DTLS will perform better then SIP-over-TLS, there is no reason to define it. This being said, defining a new UDP based secure transport for SIP is something that would be a good idea, but this protocol needs to be designed to preserve the useful qualities of SIP-over-UDP while adding security. _____________ Roman Shpount --001a11357756a7c571054406d73e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 19, 2016 at 3:26 AM, Asveren, Tolga <= tasveren@sonusne= t.com> wrote:
> --= ---Original Message-----
> From: Dale R. Worley [mailto:wor= ley@ariadne.com]
> Sent: Sunday, December 18, 2016 8:40 PM
> To: Olle E. Johansson <oej@edvina= .net>
> Cc: Asveren, Tolga <tasver= en@sonusnet.com>; sipcore@ietf.o= rg
> Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transpor= t
>
> "Olle E. Johansson" <oej@edvina.net> writes:
> >> One correction for my previous message:
> >> "SIP+D2U" =3D> "SIPS+D2U"
> >>
> >> There obviously will be a need to extend syntax for relevant = SIP
> >> headers/parameters and semantics to use it as one of the vali= d
> >> protocols. OTOH, I don't think there would be thorny issu= es and it
> >> would be mostly replicating what has been done/said about oth= er
> >> transport protocols.
> >
> > Dale and I had a discussion about it at SIPit and it's an int= eresting
> > mix of connection-less and connection-oriented that needs some > > documentation. But I do think it will help a lot of large-scale p= latforms.
>
> Though I remember discussions with Roman Shpount that DTLS has some > serious deficiencies for really large-scale systems.=C2=A0 It seems li= ke a design
> adjustment might be needed for DTLS to be really usable for SIP signal= ing.
> There was a discussion on Sipcore back in March.
[TOLGA] IITC, discussions were around how to provide fast failover w= hen DTLS is used without requiring per-transaction state synchronization. A= ctually, we (you, Roman and I had some off-line discussions regarding this.= A single-RTT failover indeed may require some changes but that is for an i= mprovement on failover timing rather than to address a generic deficiency i= n DTLS (and changes do not necessarily need to be in DTLS itself IMHO).


The question we need to answer is what makes SIP-= over-DTLS better then SIP-over-TLS. For all practical purposes SIP-over-DTL= S combines downsides of SIP-over-TLS (connection oriented, cannot fail-over= without extensive state sharing) with downsides of SIP-over-UDP (unreliabl= e, cannot be used to transport large messages). Unless you can come up with= a compelling reason why SIP-over-DTLS will perform better then SIP-over-TL= S, there is no reason to define it.

This being sai= d, defining a new UDP based secure transport for SIP is something that woul= d be a good idea, but this protocol needs to be designed to preserve the us= eful qualities of SIP-over-UDP while adding security.
_____________
Roman Shpount
=C2=A0<= /div>
--001a11357756a7c571054406d73e-- From nobody Mon Dec 19 10:18:47 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86212129531 for ; Mon, 19 Dec 2016 10:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 teNrmvJ9Jn3v for ; Mon, 19 Dec 2016 10:18:43 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0074.outbound.protection.outlook.com [104.47.42.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBB6129513 for ; Mon, 19 Dec 2016 10:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5dKkM1szJgofm8xFkQEYRktqqJX+A0ILukSi6kH7fkU=; b=jNhtTuhbHFxHk8l2V8cKNqUThR8zTZ0pUe0NTS5kjkrxT0UvccEhow2XGVLsGWvNZKlGzsc8AP6S1Vy5UyIpMWpi+8LZkvFAbVwBz6hwDsizpCdIOy8jHrnC33lupcF/GJ2/mmeZcAkgN/JtFBMpPiFh6taIb6JxxH95f5FP5KM= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 18:18:41 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 18:18:41 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport Thread-Index: AQHSWZjbtEa6q1kNm0GLCEVThq2kbKEO1LCAgAC+oICAAAEC4A== Date: Mon, 19 Dec 2016 18:18:41 +0000 Message-ID: References: <87mvfs3ddn.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 0015d7c9-843d-4241-6197-08d4283b7600 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:xx0B/djFcaoPyw0y8b6zWEPzADuhCwvlnH005DWgC2+LjyuELeYPJCRopwh1VwvjP778chTFVhMdbAB+jwwx8gMPzzLfF1P+WyWf6UuwLLT02jQl/RdgZ7Qq7bf18IEzC48+CBB6EgNBHzKLW3n6O1PNJ4ZSBZQeZb6A3tgHwMFEeL+A9dVNGZBirXlm3v/gr/nyLDr/FEkR74o1U2sUtCdFJyrZ0kqr6zf7HOuG7f4wd1MH36DqoyzmkhLS0XaYEORLb4O+VNjYvJtOzvwefXRPZmoYSttZMwon4c4iOEaXsOMXucXht9cl+Loho/0EMqSUxT8/V1JkZmFPjGRjMOBCa/Fef6CMIaVA4oZzrCkSsKpA1RjvqF9ptLMpsGl2sk9m8qtLO1IbzrQE/oeVOQnfhqL5HtBbozwNR0HTF1QiM5USqmUwDJ+slC/Eh868q2EblTFxwpERb2RmAm5qcw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(33656002)(189998001)(66066001)(74316002)(7736002)(99286002)(551934003)(2906002)(92566002)(4326007)(93886004)(106356001)(76576001)(106116001)(97736004)(105586002)(86362001)(3280700002)(3660700001)(122556002)(54356999)(2900100001)(6436002)(6506006)(8936002)(25786008)(38730400001)(77096006)(68736007)(19609705001)(2950100002)(101416001)(110136003)(6916009)(229853002)(50986999)(790700001)(6116002)(102836003)(3846002)(81156014)(8676002)(81166006)(76176999)(5660300001)(7696004)(9686002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350564F6C075203D468AEC5B2910SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 18:18:41.2299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 Archived-At: Cc: "Dale R. Worley" , "Olle E. Johansson" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:18:45 -0000 --_000_SN2PR03MB2350564F6C075203D468AEC5B2910SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBTSVAvVURQL0RUTFMgbWF5IGJlIGVuaGFuY2VkIHRvIGhhdmUg4oCcZWFzeSBzd2l0 Y2hvdmVyIHdpdGhvdXQgc2hhcmluZyBwZXItdHJhbnNhY3Rpb24gc3RhdGUgaW5mb3JtYXRpb27i gJ0sIGFuZCBqdXN0IHdpdGggc29tZSAtcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQtIFNJUCBz aWRlIGVuaGFuY2VtZW50cyByYXRoZXIgdGhhbiBzcGVjaWZ5aW5nIGEgbmV3IHRyYW5zcG9ydC9t b2RpZnlpbmcgRFRMUyAoYW5kIEkgZG9u4oCZdCB0aGluayB0aGUgc2FtZSB3b3VsZCBiZSBwb3Nz aWJsZSBmb3IgU0lQL1RMUy9UQ1ApLiBJdCB3b3VsZCB0YWtlIHF1aXRlIHNvbWUgd29yayB0byBw ZXJmZWN0IHRoZSBtZWNoYW5pc20gYnV0IHRvIG1lIGl0IGxvb2tzIGxpa2Ugd29ydGggdG8gc3Bl bmQgdGhlIGVmZm9ydC4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KPiBUaG91Z2ggSSByZW1lbWJlciBk aXNjdXNzaW9ucyB3aXRoIFJvbWFuIFNocG91bnQgdGhhdCBEVExTIGhhcyBzb21lDQo+IHNlcmlv dXMgZGVmaWNpZW5jaWVzIGZvciByZWFsbHkgbGFyZ2Utc2NhbGUgc3lzdGVtcy4gIEl0IHNlZW1z IGxpa2UgYSBkZXNpZ24NCj4gYWRqdXN0bWVudCBtaWdodCBiZSBuZWVkZWQgZm9yIERUTFMgdG8g YmUgcmVhbGx5IHVzYWJsZSBmb3IgU0lQIHNpZ25hbGluZy4NCj4gVGhlcmUgd2FzIGEgZGlzY3Vz c2lvbiBvbiBTaXBjb3JlIGJhY2sgaW4gTWFyY2guDQpbVE9MR0FdIElJVEMsIGRpc2N1c3Npb25z IHdlcmUgYXJvdW5kIGhvdyB0byBwcm92aWRlIGZhc3QgZmFpbG92ZXIgd2hlbiBEVExTIGlzIHVz ZWQgd2l0aG91dCByZXF1aXJpbmcgcGVyLXRyYW5zYWN0aW9uIHN0YXRlIHN5bmNocm9uaXphdGlv bi4gQWN0dWFsbHksIHdlICh5b3UsIFJvbWFuIGFuZCBJIGhhZCBzb21lIG9mZi1saW5lIGRpc2N1 c3Npb25zIHJlZ2FyZGluZyB0aGlzLiBBIHNpbmdsZS1SVFQgZmFpbG92ZXIgaW5kZWVkIG1heSBy ZXF1aXJlIHNvbWUgY2hhbmdlcyBidXQgdGhhdCBpcyBmb3IgYW4gaW1wcm92ZW1lbnQgb24gZmFp bG92ZXIgdGltaW5nIHJhdGhlciB0aGFuIHRvIGFkZHJlc3MgYSBnZW5lcmljIGRlZmljaWVuY3kg aW4gRFRMUyAoYW5kIGNoYW5nZXMgZG8gbm90IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYmUgaW4gRFRM UyBpdHNlbGYgSU1ITykuDQoNCg0KVGhlIHF1ZXN0aW9uIHdlIG5lZWQgdG8gYW5zd2VyIGlzIHdo YXQgbWFrZXMgU0lQLW92ZXItRFRMUyBiZXR0ZXIgdGhlbiBTSVAtb3Zlci1UTFMuIEZvciBhbGwg cHJhY3RpY2FsIHB1cnBvc2VzIFNJUC1vdmVyLURUTFMgY29tYmluZXMgZG93bnNpZGVzIG9mIFNJ UC1vdmVyLVRMUyAoY29ubmVjdGlvbiBvcmllbnRlZCwgY2Fubm90IGZhaWwtb3ZlciB3aXRob3V0 IGV4dGVuc2l2ZSBzdGF0ZSBzaGFyaW5nKSB3aXRoIGRvd25zaWRlcyBvZiBTSVAtb3Zlci1VRFAg KHVucmVsaWFibGUsIGNhbm5vdCBiZSB1c2VkIHRvIHRyYW5zcG9ydCBsYXJnZSBtZXNzYWdlcyku IFVubGVzcyB5b3UgY2FuIGNvbWUgdXAgd2l0aCBhIGNvbXBlbGxpbmcgcmVhc29uIHdoeSBTSVAt b3Zlci1EVExTIHdpbGwgcGVyZm9ybSBiZXR0ZXIgdGhlbiBTSVAtb3Zlci1UTFMsIHRoZXJlIGlz IG5vIHJlYXNvbiB0byBkZWZpbmUgaXQuDQoNClRoaXMgYmVpbmcgc2FpZCwgZGVmaW5pbmcgYSBu ZXcgVURQIGJhc2VkIHNlY3VyZSB0cmFuc3BvcnQgZm9yIFNJUCBpcyBzb21ldGhpbmcgdGhhdCB3 b3VsZCBiZSBhIGdvb2QgaWRlYSwgYnV0IHRoaXMgcHJvdG9jb2wgbmVlZHMgdG8gYmUgZGVzaWdu ZWQgdG8gcHJlc2VydmUgdGhlIHVzZWZ1bCBxdWFsaXRpZXMgb2YgU0lQLW92ZXItVURQIHdoaWxl IGFkZGluZyBzZWN1cml0eS4NCg0K --_000_SN2PR03MB2350564F6C075203D468AEC5B2910SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21z by1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JIHRoaW5rIFNJUC9VRFAvRFRMUyBtYXkgYmUgZW5oYW5jZWQgdG8gaGF2ZSDigJxlYXN5 IHN3aXRjaG92ZXIgd2l0aG91dCBzaGFyaW5nIHBlci10cmFuc2FjdGlvbiBzdGF0ZSBpbmZvcm1h dGlvbuKAnSwgYW5kIGp1c3Qgd2l0aCBzb21lIC1yZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZC0g U0lQIHNpZGUgZW5oYW5jZW1lbnRzDQogcmF0aGVyIHRoYW4gc3BlY2lmeWluZyBhIG5ldyB0cmFu c3BvcnQvbW9kaWZ5aW5nIERUTFMgKGFuZCBJIGRvbuKAmXQgdGhpbmsgdGhlIHNhbWUgd291bGQg YmUgcG9zc2libGUgZm9yIFNJUC9UTFMvVENQKS4gSXQgd291bGQgdGFrZSBxdWl0ZSBzb21lIHdv cmsgdG8gcGVyZmVjdCB0aGUgbWVjaGFuaXNtIGJ1dCB0byBtZSBpdCBsb29rcyBsaWtlIHdvcnRo IHRvIHNwZW5kIHRoZSBlZmZvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgVGhvdWdoIEkgcmVtZW1iZXIgZGlzY3Vzc2lvbnMgd2l0 aCBSb21hbiBTaHBvdW50IHRoYXQgRFRMUyBoYXMgc29tZTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFz cz0iZ21haWwtIj4mZ3Q7IHNlcmlvdXMgZGVmaWNpZW5jaWVzIGZvciByZWFsbHkgbGFyZ2Utc2Nh bGUgc3lzdGVtcy4mbmJzcDsgSXQgc2VlbXMgbGlrZSBhIGRlc2lnbjwvc3Bhbj48YnI+DQo8c3Bh biBjbGFzcz0iZ21haWwtIj4mZ3Q7IGFkanVzdG1lbnQgbWlnaHQgYmUgbmVlZGVkIGZvciBEVExT IHRvIGJlIHJlYWxseSB1c2FibGUgZm9yIFNJUCBzaWduYWxpbmcuPC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJnbWFpbC0iPiZndDsgVGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiBvbiBTaXBjb3JlIGJh Y2sgaW4gTWFyY2guPC9zcGFuPjxicj4NCltUT0xHQV0gSUlUQywgZGlzY3Vzc2lvbnMgd2VyZSBh cm91bmQgaG93IHRvIHByb3ZpZGUgZmFzdCBmYWlsb3ZlciB3aGVuIERUTFMgaXMgdXNlZCB3aXRo b3V0IHJlcXVpcmluZyBwZXItdHJhbnNhY3Rpb24gc3RhdGUgc3luY2hyb25pemF0aW9uLiBBY3R1 YWxseSwgd2UgKHlvdSwgUm9tYW4gYW5kIEkgaGFkIHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbnMg cmVnYXJkaW5nIHRoaXMuIEEgc2luZ2xlLVJUVCBmYWlsb3ZlciBpbmRlZWQgbWF5IHJlcXVpcmUN CiBzb21lIGNoYW5nZXMgYnV0IHRoYXQgaXMgZm9yIGFuIGltcHJvdmVtZW50IG9uIGZhaWxvdmVy IHRpbWluZyByYXRoZXIgdGhhbiB0byBhZGRyZXNzIGEgZ2VuZXJpYyBkZWZpY2llbmN5IGluIERU TFMgKGFuZCBjaGFuZ2VzIGRvIG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIGJlIGluIERUTFMgaXRz ZWxmIElNSE8pLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcXVlc3Rpb24gd2UgbmVlZCB0byBh bnN3ZXIgaXMgd2hhdCBtYWtlcyBTSVAtb3Zlci1EVExTIGJldHRlciB0aGVuIFNJUC1vdmVyLVRM Uy4gRm9yIGFsbCBwcmFjdGljYWwgcHVycG9zZXMgU0lQLW92ZXItRFRMUyBjb21iaW5lcyBkb3du c2lkZXMgb2YgU0lQLW92ZXItVExTIChjb25uZWN0aW9uIG9yaWVudGVkLCBjYW5ub3QgZmFpbC1v dmVyIHdpdGhvdXQgZXh0ZW5zaXZlIHN0YXRlIHNoYXJpbmcpIHdpdGgNCiBkb3duc2lkZXMgb2Yg U0lQLW92ZXItVURQICh1bnJlbGlhYmxlLCBjYW5ub3QgYmUgdXNlZCB0byB0cmFuc3BvcnQgbGFy Z2UgbWVzc2FnZXMpLiBVbmxlc3MgeW91IGNhbiBjb21lIHVwIHdpdGggYSBjb21wZWxsaW5nIHJl YXNvbiB3aHkgU0lQLW92ZXItRFRMUyB3aWxsIHBlcmZvcm0gYmV0dGVyIHRoZW4gU0lQLW92ZXIt VExTLCB0aGVyZSBpcyBubyByZWFzb24gdG8gZGVmaW5lIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGJlaW5nIHNhaWQsIGRlZmlu aW5nIGEgbmV3IFVEUCBiYXNlZCBzZWN1cmUgdHJhbnNwb3J0IGZvciBTSVAgaXMgc29tZXRoaW5n IHRoYXQgd291bGQgYmUgYSBnb29kIGlkZWEsIGJ1dCB0aGlzIHByb3RvY29sIG5lZWRzIHRvIGJl IGRlc2lnbmVkIHRvIHByZXNlcnZlIHRoZSB1c2VmdWwgcXVhbGl0aWVzIG9mIFNJUC1vdmVyLVVE UCB3aGlsZSBhZGRpbmcgc2VjdXJpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN2PR03MB2350564F6C075203D468AEC5B2910SN2PR03MB2350namp_-- From nobody Mon Dec 19 10:29:29 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200961295A7 for ; Mon, 19 Dec 2016 10:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 iBrsgUUZj6Q8 for ; Mon, 19 Dec 2016 10:29:26 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9511295A6 for ; Mon, 19 Dec 2016 10:29:26 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id n6so155399062qtd.1 for ; Mon, 19 Dec 2016 10:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RJk2OujCPQYnpwH4vMZAfeUCbxaM20NvWCqhY4eF8HU=; b=boorFgjRWIRYJMlOkJJSNMEFB3HDJLBDgSWcUoWlyU2ZcZIQxq81AFxTGBvly6jKCk cbUH6SdCXRersty2VKoyAU64AJb4dF37JMk1v5aE/HnvWjngwFt4ceTa4btGy34Hpfjz Hvgz5P8DiG9tv9sSC47O+abSVO2C8V4MMXkVDYnE0eQBbya6xM3aJ5vPHm+cx72tf+D1 xShOnbh4fp8V8mRk/WQmnNRiX1Eecj9go+iXOTSxbDbwH3boZXH9se19qL/LCkPpSBJT FAGwQ16gOk9Y0CLBN8GnFoaU61Gv7gD2QGYdERXnXkrwt6lAT3ag1ibdYiWwqesm+How cH2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RJk2OujCPQYnpwH4vMZAfeUCbxaM20NvWCqhY4eF8HU=; b=HjojaWROD7peZXC2f62bIgfwv88mc8/us5CQIX3XhqiHqaTY1BEyiwCtL+W0idacNq B3IesnrFxxQ/80NDFMb1LYofkg/3Z2GN6ledXXM9S8ZoozT9lCc4xbdLinoAkIa28iCz A3VJRp+GHsEU4VN+yIjjOCtn1+P46UgDQf5mxBvOs0coRlcpUMvz5SSFDPXIAQTjuCdz Eh8kru9llccIKzERh92bO3eE9QGXayMAQgVIPx82F+O0LiCg9HenddUlG2iYMtNGYA7X Ud9QljMz8Jm7iJyp+a1lUmxVmBkHa/wx9ZoE0mTxAi7pr4RaxZdhX6Kj5fMhXd7vRjG/ huRA== X-Gm-Message-State: AIkVDXI9VTa8I+h67PTsenxUml/UWmr/+f1GkG8z4HS//9TvsA+HAou8L+TwjLGm6rerpA== X-Received: by 10.237.45.38 with SMTP id h35mr18822884qtd.9.1482172165698; Mon, 19 Dec 2016 10:29:25 -0800 (PST) Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com. [209.85.216.169]) by smtp.gmail.com with ESMTPSA id p28sm11067752qtb.31.2016.12.19.10.29.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 10:29:25 -0800 (PST) Received: by mail-qt0-f169.google.com with SMTP id p16so152875125qta.0 for ; Mon, 19 Dec 2016 10:29:25 -0800 (PST) X-Received: by 10.237.37.149 with SMTP id x21mr16438136qtc.148.1482172164937; Mon, 19 Dec 2016 10:29:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.136.230 with HTTP; Mon, 19 Dec 2016 10:29:24 -0800 (PST) In-Reply-To: References: <87mvfs3ddn.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Mon, 19 Dec 2016 13:29:24 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a114108fa632e77054407197e Archived-At: Cc: "Dale R. Worley" , "Olle E. Johansson" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:29:28 -0000 --001a114108fa632e77054407197e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do you think it would be possible to implement "easy switch-over" with SIP/DTLS without significant changes to DTLS only by changing things on SIP side? Can you share what you have in mind, even if it is still at the idea stage? I thought it was possible to implement a secure UDP based protocol by changing DTLS and using SIP sequence numbers or other SIP headers, such as Call ID and via branch value, transformed through a hash function, to replace DTLS sequence number for message key generation. I am not sure how to do the same thing by changing SIP and keeping DTLS the same. Regards, _____________ Roman Shpount On Mon, Dec 19, 2016 at 1:18 PM, Asveren, Tolga wrote: > I think SIP/UDP/DTLS may be enhanced to have =E2=80=9Ceasy switchover wit= hout > sharing per-transaction state information=E2=80=9D, and just with some -r= elatively > straightforward- SIP side enhancements rather than specifying a new > transport/modifying DTLS (and I don=E2=80=99t think the same would be pos= sible for > SIP/TLS/TCP). It would take quite some work to perfect the mechanism but = to > me it looks like worth to spend the effort. > > > > Thanks, > > Tolga > > > > > Though I remember discussions with Roman Shpount that DTLS has some > > serious deficiencies for really large-scale systems. It seems like a > design > > adjustment might be needed for DTLS to be really usable for SIP > signaling. > > There was a discussion on Sipcore back in March. > [TOLGA] IITC, discussions were around how to provide fast failover when > DTLS is used without requiring per-transaction state synchronization. > Actually, we (you, Roman and I had some off-line discussions regarding > this. A single-RTT failover indeed may require some changes but that is f= or > an improvement on failover timing rather than to address a generic > deficiency in DTLS (and changes do not necessarily need to be in DTLS > itself IMHO). > > > > > > The question we need to answer is what makes SIP-over-DTLS better then > SIP-over-TLS. For all practical purposes SIP-over-DTLS combines downsides > of SIP-over-TLS (connection oriented, cannot fail-over without extensive > state sharing) with downsides of SIP-over-UDP (unreliable, cannot be used > to transport large messages). Unless you can come up with a compelling > reason why SIP-over-DTLS will perform better then SIP-over-TLS, there is = no > reason to define it. > > > > This being said, defining a new UDP based secure transport for SIP is > something that would be a good idea, but this protocol needs to be design= ed > to preserve the useful qualities of SIP-over-UDP while adding security. > > > --001a114108fa632e77054407197e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do you think it would be possible to implement "easy = switch-over" with SIP/DTLS without significant changes to DTLS only by= changing things on SIP side? Can you share what you have in mind, even if = it is still at the idea stage?

I thought it was possible= to implement a secure UDP based protocol by changing DTLS and using SIP se= quence numbers or other SIP headers, such as Call ID and via branch value, = transformed through a hash function, to replace DTLS sequence number for me= ssage key generation. I am not sure how to do the same thing by changing SI= P and keeping DTLS the same.

Regards,
_____________
Roman Shpount

On Mon, Dec 19, 2016 at 1:18 PM, Asveren, To= lga <tasveren@sonusnet.com> wrote:

I think SIP/UDP/DTLS may be enhanced to have =E2=80= =9Ceasy switchover without sharing per-transaction state information=E2=80= =9D, and just with some -relatively straightforward- SIP side enhancements rather than specifying a new transport/modifying DTLS (and I don=E2=80=99t= think the same would be possible for SIP/TLS/TCP). It would take quite som= e work to perfect the mechanism but to me it looks like worth to spend the = effort.

=C2=A0

Thanks,

Tolga

=C2=A0

> Th= ough I remember discussions with Roman Shpount that DTLS has some > serious deficiencies for = really large-scale systems.=C2=A0 It seems like a design
> adjustment might be neede= d for DTLS to be really usable for SIP signaling.
> There was a discussion on= Sipcore back in March.
[TOLGA] IITC, discussions were around how to provide fast failover when DTL= S is used without requiring per-transaction state synchronization. Actually= , we (you, Roman and I had some off-line discussions regarding this. A sing= le-RTT failover indeed may require some changes but that is for an improvement on failover timing rather than= to address a generic deficiency in DTLS (and changes do not necessarily ne= ed to be in DTLS itself IMHO).

=C2=A0

=C2=A0

The question we need to answer is what makes SIP-ove= r-DTLS better then SIP-over-TLS. For all practical purposes SIP-over-DTLS c= ombines downsides of SIP-over-TLS (connection oriented, cannot fail-over wi= thout extensive state sharing) with downsides of SIP-over-UDP (unreliable, cannot be used to transport large m= essages). Unless you can come up with a compelling reason why SIP-over-DTLS= will perform better then SIP-over-TLS, there is no reason to define it.=

=C2=A0

This being said, defining a new UDP based secure tra= nsport for SIP is something that would be a good idea, but this protocol ne= eds to be designed to preserve the useful qualities of SIP-over-UDP while a= dding security.

=C2=A0


--001a114108fa632e77054407197e-- From nobody Mon Dec 19 11:07:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D5F1295D5 for ; Mon, 19 Dec 2016 11:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 uiwyYODQ8wPg for ; Mon, 19 Dec 2016 11:07:15 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0040.outbound.protection.outlook.com [104.47.38.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A211295E0 for ; Mon, 19 Dec 2016 11:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4TwFEOAoBrwdXemNAVTmFFcoUpIx28ajJG3qZplhcCQ=; b=m2VgWAaGg+lRFhXTxCC0fJu5GVpssWHOt5Ro0raccvje/3cHpL/3siIPZTSIXvaa1ntEzZ1Fup8Abc5Uid6gsYvcFuIUcf9uvSocnAKuRLkgGnKL6SLemo81q2f1vs6nGVdjBBM8/BJmPH27ojqF+PIKgPkRAEZq2K8aAdpYXzI= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 19:07:11 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 19:07:11 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" Thread-Topic: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem Thread-Index: AQHSWaMhvyU+dWmrSZmJnOs13D51DqEPoB4g Date: Mon, 19 Dec 2016 19:07:11 +0000 Message-ID: References: (tasveren@sonusnet.com) <87eg1439z2.fsf@hobgoblin.ariadne.com> In-Reply-To: <87eg1439z2.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 3e4763ac-8d61-4e93-20eb-08d428423c97 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:TSZk0C2z7BViR+VwVcO2Gb3clTlZW2MtbZokKC45/YqscHXeuft62h/j+83PGlrw5Eo7oteCnpxhCjgk3v6b9mgThYhqcZ+fqGhgW+pissm6i2J5LOC0EUdk3vAhX+EZ16HOQABK8efm3oQxg4XpFEdjJ6N41yyMs031eaSa2t5YmgtRtVZ/tf9IKeGpOzc7iic0A6vpm54w/uDK2XFMzUj06/gL2Xe/Of/HMFO9BXJFBc/VdbwRg/rNNYieTZvIsAspJ70jrLJji3F9YwvJTZCHbZMjQ0BVSL8Oh5VIJD8tq6NB2KSyE5OPG5pCUXf8R00bsLJvMBBARutKTVgooQww+sJgGmYal/9XJhcnON//WgCtUbjzyT22bFt1j6j6AVQ2sKjjnEPqAs2NMaHxBI2fOni8BKZ9BtvXxh2d/lrO05R54VME0kEHSw572lWOYr4fl58q1zwzSPhijDy+Ww== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(150554046322364)(100405760836317)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377454003)(13464003)(199003)(106116001)(74316002)(2906002)(6916009)(33656002)(2950100002)(25786008)(66066001)(77096006)(3660700001)(3280700002)(76176999)(7696004)(229853002)(2900100001)(92566002)(122556002)(38730400001)(110136003)(76576001)(5660300001)(4326007)(101416001)(54356999)(50986999)(106356001)(97736004)(7736002)(305945005)(189998001)(9686002)(81156014)(81166006)(68736007)(105586002)(6436002)(6116002)(6506006)(86362001)(102836003)(8936002)(3846002)(99286002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 19:07:11.4141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 19:07:21 -0000 Inline... Thanks, Tolga > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Sunday, December 18, 2016 9:54 PM > To: Asveren, Tolga > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem >=20 > "Asveren, Tolga" writes: > > I think it would be useful to get on a common understanding/consensus > > on "what needs to be covered and in which document" as far as use of > > multiple IP Address Families/Multiple Interfaces are concerned. Here > > is a first attempt for "Summary of Happiness": >=20 > The current plan has been to discuss topics incrementally in order to kee= p > the scope of each incremental technical discussion small enough that it w= ill > come to an end. If we throw everything into the discussion at once, it w= ill be > difficult to both discuss things thoroughly and come to a consensus. >=20 > > ii- RFC6555 > > Defines parallel connection attempt for different IP address families. > > Restricts itself -I don't know exactly why- to a single hostname for > > IPv4/IPv6 and does not cover other ways of learning IP Addresses, e.g. > > provisioning, DHCP based. AFAICS, procedure described in this > > specification can be applied for those cases as well. >=20 > That's because RFC 6555 discusses the case of HTTP, where there is a sing= le > host name, the domain name from the HTTP URL. There *are* no other > ways of learning an IP address in HTTP. [TOLGA] I couldn't see anything in RFC6555 restricting itself to HTTP. To t= he contrary, it mentions applicability even to non-connection oriented tran= sport protocols as long as application protocol satisfies request/response = semantics. >=20 > > iv- draft-worley-sip-he-connection-00 >=20 > > Would any "fast-failover after connection failure", e.g. toward the > > standby server after failure of the primary server, related procedures > > be in scope? For connection oriented protocols, any possible > > recommendations/improvements in this area would probably be limited to > > reusing the TLS connection. Is there anything SIP specific, which > > could help here? >=20 > Fast failover is, in effect, in scope because in a failure situation, wha= t Happy > Eyeballs attempts to do with the next SIP message is deliver it quickly. [TOLGA] Yes, agreed. I am not sure whether there is a practical way of expe= diting things for TCP/TLS-TCP though. >=20 > > B) Use of Multiple Interfaces > > v- I think the ideal place to cover this would be RFC6555-bis (also by > > considering other restrictions as mentioned in ii- above). I wouldn't > > think that there would be a need for defining anything new in > > draft-worley-sip-he-connection-00 (?). >=20 > The subtle problem with multiple interfaces is that there can be multiple > interfaces that might be able to connect to a particular target address. > Currently in IPv6, the source address selection algorithm of RFC 6724 cho= oses > which interface is to be used to contact a particular target address. Bu= t IIRC > Roman Shpount noted that there are times when RFC 6724 gives a non- > working result. It looks like in the long run we want H.E. to be able to= use > alternative source addresses if necessary. [TOLGA] This is something to be addressed by RFC6555-bis IMHO: try to estab= lish a connection for each { IP Address Family, Interface } tuple rather th= an just for each { IP Address Family }.=20 >=20 > Dale From nobody Mon Dec 19 11:07:49 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349501295CE for ; Mon, 19 Dec 2016 11:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 mZ1x7uh58nDH for ; Mon, 19 Dec 2016 11:07:47 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0081.outbound.protection.outlook.com [104.47.40.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08F4120727 for ; Mon, 19 Dec 2016 11:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+tKzugVZ9Bpmtf8gj11OHAFwBhPkiV/wTS2bqa/d7Mw=; b=BceOy7zxn9k+JQcWjoaT1Ojlp1zaeL1QitdNZqWEc7YfIv1RA8sKZmso4hCOpsx+RB9SSMAot65xubVpBkJn0c6i+E4SnfzAHOLRnUQjqhyynGx63o+CtkxL8VqU9HslPYJSn6miiSdK1qmH4K+/IH7aufEdgpJwHxBmptSVZeU= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 19:07:45 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 19:07:45 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHSWaTTRj/FKGerzk2IPpPFNc5xDqEPoudQ Date: Mon, 19 Dec 2016 19:07:45 +0000 Message-ID: References: (tasveren@sonusnet.com) <877f6w39eu.fsf@hobgoblin.ariadne.com> In-Reply-To: <877f6w39eu.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 06a6a473-c905-4918-de6a-08d4284250b1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:3uWccF+mmoF1V0Gz+Od0ixOz3V5jSC50kvl/QecHGktcu3JASBIN651sQl3p2l3rrH8Jw/Nh1IgLqxGQ62KKXOFDs7N9P3eOE4R/KSDDpYttQ0yVPeU/oZvKfCSpAXb6imYpPtUR88vGguvFsKTB8d1XgFfjDjuwPm4w43hgAawl/iaPqoMfNo+EjOn3BDTh6pzn47MRNeZks3ESlDGxjMtU/pQHw/7acWf07h+r6Qvadeba4g+7ds/FjdD8ywT/ZzLGE+TgMVP1Qwe7nRhm/K6HCe8RfLdp0RciKCq7zSwx0n7fdhbG1fK7fnNyJc6WbTdED/DkT5AZYnJKzY3xn46tCwwUYXDU5XESh2wNJ3jX7aoAs0Drn5wO/P9UDkIXyJ071zwidviwi6R6Gt9vz9NGwp9flueIMkLmmrgOA5M2nHED+ziEL/IPBF+1W4pQz0qVdwJlHh1ThGeBPWf6Lg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377454003)(13464003)(199003)(106116001)(74316002)(2906002)(6916009)(33656002)(2950100002)(25786008)(66066001)(77096006)(3660700001)(3280700002)(76176999)(7696004)(229853002)(2900100001)(92566002)(122556002)(38730400001)(110136003)(76576001)(5660300001)(4326007)(101416001)(54356999)(50986999)(106356001)(97736004)(7736002)(305945005)(189998001)(9686002)(81156014)(81166006)(68736007)(105586002)(6436002)(6116002)(6506006)(86362001)(102836003)(8936002)(3846002)(99286002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 19:07:45.0947 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Cc: "sipcore@ietf.org" , "oej@edvina.net" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 19:07:48 -0000 Yes, and I think it should stay. Thanks, Tolga > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Sunday, December 18, 2016 10:06 PM > To: Asveren, Tolga > Cc: oej@edvina.net; sipcore@ietf.org > Subject: Re: [sipcore] Happy Eyeballs for SIP >=20 > "Asveren, Tolga" writes: > > i- A single implementation does it certain way does not mean it is per > > specification/done the same way by all other entities/implementations. > > I am aware of many deployments using OPTIONS for ping/keepalive/probe > > with success and without any issues. IMHO, OPTIONS definitely should > > be mentioned as one of the alternatives. >=20 > The use of OPTIONS is listed in section 5 of draft-worley-sip-he-connecti= on- > 01. >=20 > Dale From nobody Mon Dec 19 11:14:41 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CD81295CE for ; Mon, 19 Dec 2016 11:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 pPvmx4KU0wlG for ; Mon, 19 Dec 2016 11:14:37 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0074.outbound.protection.outlook.com [104.47.42.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D1C1295DC for ; Mon, 19 Dec 2016 11:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mxom3wgJ5tepd8eFMzJfoeYULEvkMU1voDjxgUvcXIw=; b=r7+QYvHUNowHxy+elJDwW+SqJqGFHzPwupnyXmvnBoc7+K4joqaopiu9HKALtSOQYwsYoRIN+aJU/E+xdqSOVKeAqOQqyd+Dqktq+E3rsa1P4ZxUa/zQxRoDKslS7iUxOR92qRN44DBjK4uPl45jkwDEOfsWKACVv65WwJNeIcs= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 19:14:35 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 19:14:35 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport Thread-Index: AQHSWZjbtEa6q1kNm0GLCEVThq2kbKEO1LCAgAC+oICAAAEC4IAABCEAgAAAPoA= Date: Mon, 19 Dec 2016 19:14:35 +0000 Message-ID: References: <87mvfs3ddn.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 5409dc40-2221-4c27-8573-08d428434533 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:SbxNxYuSjxE2j6hOy3iW6TckAlgepOsBBaceBnBuw+PwOFs97dHbe2svJrX2PWCVEjqGNFUu5iI70oJbfhLaJSGlW81sZst3FzpsN1i+W56b80PY29Scgd5Gx+v+pvs+/WzOlsBFLiXu4WvtiwmuXi3xiRT9KbybE4AwE9A3cxRXhF1qz2T1d3p4h0fXWcToYr5w7iO6xderKYUKSQ5o2CfhVULh0eaAC5//8LR092Qeyu3QuCh1v7v3o2t+TweYi8qhgXlLO7nSs/+EyFwikpHve49q/7w8h/onLhTYQTEyrHdzMRXL3G8jo8CA+Q3BontMPClbDmJVvSmjNIwjujbkgcVZaYkoa9zE1JfkKw2yjYeHbqECKDEjqJrpF8gR9qgZgoPAMLRbovAq2Sv8cystKJ1q7EfTsxZFgZWMdsTp9SO8vaX7Lh92Q3cigCmPc6S1D9g0GK6hlqrekR8omw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558021)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6047074)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(24454002)(377454003)(199003)(4326007)(19609705001)(102836003)(74316002)(8676002)(790700001)(81156014)(6116002)(81166006)(6506006)(6436002)(3846002)(92566002)(106356001)(99286002)(106116001)(66066001)(229853002)(105586002)(8936002)(76176999)(551934003)(97736004)(68736007)(101416001)(110136003)(5660300001)(93886004)(3280700002)(9686002)(50986999)(54356999)(33656002)(2906002)(7736002)(77096006)(122556002)(38730400001)(2900100001)(189998001)(7696004)(25786008)(2950100002)(3660700001)(86362001)(76576001)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23505E3DDD74E808455A10E2B2910SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 19:14:35.3345 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: "Dale R. Worley" , "Olle E. Johansson" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 19:14:40 -0000 --_000_SN2PR03MB23505E3DDD74E808455A10E2B2910SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgKmNvdWxkKiBiZSBwb3NzaWJsZSAtYnV0IHRoZSBpZGVhcyBuZWVkIHRvIGJlIHZldHRlZCBi eSBhIHNlY3VyaXR5IGd1cnUtIGFuZCBJIHdvdWxkbuKAmXQgYmV0IG15IGxpZmUgb24gdGhlIHN1 Y2Nlc3Mgb2YgaXQgYXQgdGhpcyBzdGFnZS4NCg0KVGhlcmUgYXJlIHZhcmlvdXMgc2NlbmFyaW9z IHRvIGNvdmVyLCBiZWxvdyBpcyB0aGUgaGlnaC1sZXZlbCBjb25jZXB0IGZvciBzZXJ2ZXIgc2lk ZSBmYWlsb3ZlcjoNCmktIEFjdGl2ZSBTZXJ2ZXIgc2VuZHMgYSBzaGFyZWQta2V5L25vbmNlIHRv IFVFIGFmdGVyIGl0IGNvbXBsZXRlcyByZWdpc3RyYXRpb24sIGUuZy4gYXMgcGFydCBvZiAyMDAo UkVHSVNURVIpLg0KaWktIEFjdGl2ZSBTZXJ2ZXIgc3luY2hyb25pemVzIHNoYXJlZC1rZXkvbm9u Y2Ugd2l0aCB0aGUgU3RhbmRieSBTZXJ2ZXINCmlpaS0gVUUgZGV0ZWN0cyB0aGF0IEFjdGl2ZSBT ZXJ2ZXIgaXMgZG93biBhbmQgc2VuZHMgYSBtZXNzYWdlIChtYXliZSBhIG5ldyBTVFVOIHVzYWdl KSB3aXRoIChEVExTIGVwb2NoLCBEVExTIHNlcXVlbmNlX25vLCBNQUNbc2hhcmVkIHNlY3JldCwg c29tZSBtZXNzYWdlIGNvbnRlbnQsIG5vbmNlXSkgdG8gU3RhbmRieSBTZXJ2ZXINCml2LSBTdGFu ZGJ5IFNlcnZlciB1c2VzIHRoZSByZWNlaXZlZCBlcG9jaC9zZXF1ZW5jZV9ubyB0byBpbml0aWFs aXplIERUTFMgc3RhdGUgZm9yIGEgbmV3IGluc3RhbmNlLiBUaGlzIHdvdWxkIHJlcXVpcmUgYSBj aGFuZ2UgaW4gdGhlIERUTFMgQVBJL2xvY2FsIHN0YWNrIGlmIGl0IGlzIG5vdCBhbHJlYWR5IHN1 cHBvcnRlZCBidXQgbm8gY2hhbmdlcyBmcm9tIG9uLXRoZS13aXJlIHByb3RvY29sIHBlcnNwZWN0 aXZlLg0Kdi0gU3RhbmRieSBTZXJ2ZXIgc2VuZHMgYSBtZXNzYWdlIGZvciBhY2sgKG1heXViZSBh IG5ldyBTVFVOIHVzYWdlKS4NCg0KKklmKiBzb21ldGhpbmcgYWxvbmcgdGhlc2UgbGluZXMgd29y a3MsIHRoZXJlIHdvdWxkbuKAmXQgYmUgYSBuZWVkIHRvIGVzdGFibGlzaCBhIOKAnG5ld+KAnSBE VExTIHNlc3Npb24gYmV0d2VlbiBVRS9TdGFuZGJ5IFNlcnZlci4gVGhlcmUgd291bGRu4oCZdCBi ZSBhIG5lZWQgdG8gY2hhbmdlIHRoZSBvbi10aGUtd2lyZSBEVExTIHByb3RvY29sL2RlZmluZSBh IG5ldyBwcm90b2NvbCAoYm90aCB0YWxsIG9yZGVycyBpbiB0ZXJtcyBvZiBtYWtpbmcgdGhlaXIg d2F5IHRvIHByYWN0aWNhbCB1c2UvZGVwbG95bWVudCB3aWRlbHkgSU1ITykgLg0KDQpUaGFua3Ms DQpUb2xnYQ0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21d DQpTZW50OiBNb25kYXksIERlY2VtYmVyIDE5LCAyMDE2IDE6MjkgUE0NClRvOiBBc3ZlcmVuLCBU b2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KQ2M6IERhbGUgUi4gV29ybGV5IDx3b3JsZXlA YXJpYWRuZS5jb20+OyBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+OyBzaXBjb3Jl QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEhhcHB5IEV5ZWJhbGxzIGZvciBTSVAg LSBEVExTIGFzIGEgU0lQIHRyYW5zcG9ydA0KDQpEbyB5b3UgdGhpbmsgaXQgd291bGQgYmUgcG9z c2libGUgdG8gaW1wbGVtZW50ICJlYXN5IHN3aXRjaC1vdmVyIiB3aXRoIFNJUC9EVExTIHdpdGhv dXQgc2lnbmlmaWNhbnQgY2hhbmdlcyB0byBEVExTIG9ubHkgYnkgY2hhbmdpbmcgdGhpbmdzIG9u IFNJUCBzaWRlPyBDYW4geW91IHNoYXJlIHdoYXQgeW91IGhhdmUgaW4gbWluZCwgZXZlbiBpZiBp dCBpcyBzdGlsbCBhdCB0aGUgaWRlYSBzdGFnZT8NCg0KSSB0aG91Z2h0IGl0IHdhcyBwb3NzaWJs ZSB0byBpbXBsZW1lbnQgYSBzZWN1cmUgVURQIGJhc2VkIHByb3RvY29sIGJ5IGNoYW5naW5nIERU TFMgYW5kIHVzaW5nIFNJUCBzZXF1ZW5jZSBudW1iZXJzIG9yIG90aGVyIFNJUCBoZWFkZXJzLCBz dWNoIGFzIENhbGwgSUQgYW5kIHZpYSBicmFuY2ggdmFsdWUsIHRyYW5zZm9ybWVkIHRocm91Z2gg YSBoYXNoIGZ1bmN0aW9uLCB0byByZXBsYWNlIERUTFMgc2VxdWVuY2UgbnVtYmVyIGZvciBtZXNz YWdlIGtleSBnZW5lcmF0aW9uLiBJIGFtIG5vdCBzdXJlIGhvdyB0byBkbyB0aGUgc2FtZSB0aGlu ZyBieSBjaGFuZ2luZyBTSVAgYW5kIGtlZXBpbmcgRFRMUyB0aGUgc2FtZS4NCg0KUmVnYXJkcywN Cl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gTW9uLCBEZWMgMTksIDIwMTYgYXQg MToxOCBQTSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFz dmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQpJIHRoaW5rIFNJUC9VRFAvRFRMUyBtYXkgYmUg ZW5oYW5jZWQgdG8gaGF2ZSDigJxlYXN5IHN3aXRjaG92ZXIgd2l0aG91dCBzaGFyaW5nIHBlci10 cmFuc2FjdGlvbiBzdGF0ZSBpbmZvcm1hdGlvbuKAnSwgYW5kIGp1c3Qgd2l0aCBzb21lIC1yZWxh dGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZC0gU0lQIHNpZGUgZW5oYW5jZW1lbnRzIHJhdGhlciB0aGFu IHNwZWNpZnlpbmcgYSBuZXcgdHJhbnNwb3J0L21vZGlmeWluZyBEVExTIChhbmQgSSBkb27igJl0 IHRoaW5rIHRoZSBzYW1lIHdvdWxkIGJlIHBvc3NpYmxlIGZvciBTSVAvVExTL1RDUCkuIEl0IHdv dWxkIHRha2UgcXVpdGUgc29tZSB3b3JrIHRvIHBlcmZlY3QgdGhlIG1lY2hhbmlzbSBidXQgdG8g bWUgaXQgbG9va3MgbGlrZSB3b3J0aCB0byBzcGVuZCB0aGUgZWZmb3J0Lg0KDQpUaGFua3MsDQpU b2xnYQ0KDQo+IFRob3VnaCBJIHJlbWVtYmVyIGRpc2N1c3Npb25zIHdpdGggUm9tYW4gU2hwb3Vu dCB0aGF0IERUTFMgaGFzIHNvbWUNCj4gc2VyaW91cyBkZWZpY2llbmNpZXMgZm9yIHJlYWxseSBs YXJnZS1zY2FsZSBzeXN0ZW1zLiAgSXQgc2VlbXMgbGlrZSBhIGRlc2lnbg0KPiBhZGp1c3RtZW50 IG1pZ2h0IGJlIG5lZWRlZCBmb3IgRFRMUyB0byBiZSByZWFsbHkgdXNhYmxlIGZvciBTSVAgc2ln bmFsaW5nLg0KPiBUaGVyZSB3YXMgYSBkaXNjdXNzaW9uIG9uIFNpcGNvcmUgYmFjayBpbiBNYXJj aC4NCltUT0xHQV0gSUlUQywgZGlzY3Vzc2lvbnMgd2VyZSBhcm91bmQgaG93IHRvIHByb3ZpZGUg ZmFzdCBmYWlsb3ZlciB3aGVuIERUTFMgaXMgdXNlZCB3aXRob3V0IHJlcXVpcmluZyBwZXItdHJh bnNhY3Rpb24gc3RhdGUgc3luY2hyb25pemF0aW9uLiBBY3R1YWxseSwgd2UgKHlvdSwgUm9tYW4g YW5kIEkgaGFkIHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbnMgcmVnYXJkaW5nIHRoaXMuIEEgc2lu Z2xlLVJUVCBmYWlsb3ZlciBpbmRlZWQgbWF5IHJlcXVpcmUgc29tZSBjaGFuZ2VzIGJ1dCB0aGF0 IGlzIGZvciBhbiBpbXByb3ZlbWVudCBvbiBmYWlsb3ZlciB0aW1pbmcgcmF0aGVyIHRoYW4gdG8g YWRkcmVzcyBhIGdlbmVyaWMgZGVmaWNpZW5jeSBpbiBEVExTIChhbmQgY2hhbmdlcyBkbyBub3Qg bmVjZXNzYXJpbHkgbmVlZCB0byBiZSBpbiBEVExTIGl0c2VsZiBJTUhPKS4NCg0KDQpUaGUgcXVl c3Rpb24gd2UgbmVlZCB0byBhbnN3ZXIgaXMgd2hhdCBtYWtlcyBTSVAtb3Zlci1EVExTIGJldHRl ciB0aGVuIFNJUC1vdmVyLVRMUy4gRm9yIGFsbCBwcmFjdGljYWwgcHVycG9zZXMgU0lQLW92ZXIt RFRMUyBjb21iaW5lcyBkb3duc2lkZXMgb2YgU0lQLW92ZXItVExTIChjb25uZWN0aW9uIG9yaWVu dGVkLCBjYW5ub3QgZmFpbC1vdmVyIHdpdGhvdXQgZXh0ZW5zaXZlIHN0YXRlIHNoYXJpbmcpIHdp dGggZG93bnNpZGVzIG9mIFNJUC1vdmVyLVVEUCAodW5yZWxpYWJsZSwgY2Fubm90IGJlIHVzZWQg dG8gdHJhbnNwb3J0IGxhcmdlIG1lc3NhZ2VzKS4gVW5sZXNzIHlvdSBjYW4gY29tZSB1cCB3aXRo IGEgY29tcGVsbGluZyByZWFzb24gd2h5IFNJUC1vdmVyLURUTFMgd2lsbCBwZXJmb3JtIGJldHRl ciB0aGVuIFNJUC1vdmVyLVRMUywgdGhlcmUgaXMgbm8gcmVhc29uIHRvIGRlZmluZSBpdC4NCg0K VGhpcyBiZWluZyBzYWlkLCBkZWZpbmluZyBhIG5ldyBVRFAgYmFzZWQgc2VjdXJlIHRyYW5zcG9y dCBmb3IgU0lQIGlzIHNvbWV0aGluZyB0aGF0IHdvdWxkIGJlIGEgZ29vZCBpZGVhLCBidXQgdGhp cyBwcm90b2NvbCBuZWVkcyB0byBiZSBkZXNpZ25lZCB0byBwcmVzZXJ2ZSB0aGUgdXNlZnVsIHF1 YWxpdGllcyBvZiBTSVAtb3Zlci1VRFAgd2hpbGUgYWRkaW5nIHNlY3VyaXR5Lg0KDQoNCg== --_000_SN2PR03MB23505E3DDD74E808455A10E2B2910SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5tLTQyOTU0NTA0NjE2OTkxOTM3ODNnbWFpbC0NCgl7 bXNvLXN0eWxlLW5hbWU6bV8tNDI5NTQ1MDQ2MTY5OTE5Mzc4M2dtYWlsLTt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JdCAqPGI+Y291bGQ8L2I+KiBiZSBwb3NzaWJsZSAtYnV0IHRoZSBpZGVhcyBuZWVk IHRvIGJlIHZldHRlZCBieSBhIHNlY3VyaXR5IGd1cnUtIGFuZCBJIHdvdWxkbuKAmXQgYmV0IG15 IGxpZmUgb24gdGhlIHN1Y2Nlc3Mgb2YgaXQgYXQgdGhpcyBzdGFnZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VGhlcmUgYXJlIHZhcmlvdXMgc2NlbmFyaW9zIHRvIGNvdmVyLCBiZWxvdyBpcyB0aGUgaGlnaC1s ZXZlbCBjb25jZXB0IGZvciBzZXJ2ZXIgc2lkZSBmYWlsb3Zlcjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmktIEFjdGl2ZSBTZXJ2 ZXIgc2VuZHMgYSBzaGFyZWQta2V5L25vbmNlIHRvIFVFIGFmdGVyIGl0IGNvbXBsZXRlcyByZWdp c3RyYXRpb24sIGUuZy4gYXMgcGFydCBvZiAyMDAoUkVHSVNURVIpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aWktIEFjdGl2ZSBT ZXJ2ZXIgc3luY2hyb25pemVzIHNoYXJlZC1rZXkvbm9uY2Ugd2l0aCB0aGUgU3RhbmRieSBTZXJ2 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPmlpaS0gVUUgZGV0ZWN0cyB0aGF0IEFjdGl2ZSBTZXJ2ZXIgaXMgZG93biBhbmQgc2Vu ZHMgYSBtZXNzYWdlIChtYXliZSBhIG5ldyBTVFVOIHVzYWdlKSB3aXRoIChEVExTIGVwb2NoLCBE VExTIHNlcXVlbmNlX25vLCBNQUNbc2hhcmVkIHNlY3JldCwgc29tZSBtZXNzYWdlIGNvbnRlbnQs IG5vbmNlXSkNCiB0byBTdGFuZGJ5IFNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aXYtIFN0YW5kYnkgU2VydmVyIHVzZXMg dGhlIHJlY2VpdmVkIGVwb2NoL3NlcXVlbmNlX25vIHRvIGluaXRpYWxpemUgRFRMUyBzdGF0ZSBm b3IgYSBuZXcgaW5zdGFuY2UuIFRoaXMgd291bGQgcmVxdWlyZSBhIGNoYW5nZSBpbiB0aGUgRFRM UyBBUEkvbG9jYWwgc3RhY2sgaWYgaXQgaXMgbm90IGFscmVhZHkNCiBzdXBwb3J0ZWQgYnV0IG5v IGNoYW5nZXMgZnJvbSBvbi10aGUtd2lyZSBwcm90b2NvbCBwZXJzcGVjdGl2ZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnYtIFN0 YW5kYnkgU2VydmVyIHNlbmRzIGEgbWVzc2FnZSBmb3IgYWNrIChtYXl1YmUgYSBuZXcgU1RVTiB1 c2FnZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPio8Yj5JZjwvYj4qIHNvbWV0aGluZyBhbG9uZyB0aGVzZSBs aW5lcyB3b3JrcywgdGhlcmUgd291bGRu4oCZdCBiZSBhIG5lZWQgdG8gZXN0YWJsaXNoIGEg4oCc bmV34oCdIERUTFMgc2Vzc2lvbiBiZXR3ZWVuIFVFL1N0YW5kYnkgU2VydmVyLiBUaGVyZSB3b3Vs ZG7igJl0IGJlIGEgbmVlZCB0byBjaGFuZ2UgdGhlDQogb24tdGhlLXdpcmUgRFRMUyBwcm90b2Nv bC9kZWZpbmUgYSBuZXcgcHJvdG9jb2wgKGJvdGggdGFsbCBvcmRlcnMgaW4gdGVybXMgb2YgbWFr aW5nIHRoZWlyIHdheSB0byBwcmFjdGljYWwgdXNlL2RlcGxveW1lbnQgd2lkZWx5IElNSE8pIC4g Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbWFuIFNocG91bnQgW21haWx0 bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIERlY2VtYmVy IDE5LCAyMDE2IDE6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhICZsdDt0YXN2 ZXJlbkBzb251c25ldC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBEYWxlIFIuIFdvcmxleSAmbHQ7 d29ybGV5QGFyaWFkbmUuY29tJmd0OzsgT2xsZSBFLiBKb2hhbnNzb24gJmx0O29lakBlZHZpbmEu bmV0Jmd0Ozsgc2lwY29yZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNv cmVdIEhhcHB5IEV5ZWJhbGxzIGZvciBTSVAgLSBEVExTIGFzIGEgU0lQIHRyYW5zcG9ydDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3Ug dGhpbmsgaXQgd291bGQgYmUgcG9zc2libGUgdG8gaW1wbGVtZW50ICZxdW90O2Vhc3kgc3dpdGNo LW92ZXImcXVvdDsgd2l0aCBTSVAvRFRMUyB3aXRob3V0IHNpZ25pZmljYW50IGNoYW5nZXMgdG8g RFRMUyBvbmx5IGJ5IGNoYW5naW5nIHRoaW5ncyBvbiBTSVAgc2lkZT8gQ2FuIHlvdSBzaGFyZSB3 aGF0IHlvdSBoYXZlIGluIG1pbmQsIGV2ZW4gaWYgaXQgaXMgc3RpbGwgYXQgdGhlIGlkZWEgc3Rh Z2U/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRob3Vn aHQgaXQgd2FzIHBvc3NpYmxlIHRvIGltcGxlbWVudCBhIHNlY3VyZSBVRFAgYmFzZWQgcHJvdG9j b2wgYnkgY2hhbmdpbmcgRFRMUyBhbmQgdXNpbmcgU0lQIHNlcXVlbmNlIG51bWJlcnMgb3Igb3Ro ZXIgU0lQIGhlYWRlcnMsIHN1Y2ggYXMgQ2FsbCBJRCBhbmQgdmlhIGJyYW5jaCB2YWx1ZSwgdHJh bnNmb3JtZWQgdGhyb3VnaCBhIGhhc2ggZnVuY3Rpb24sIHRvIHJlcGxhY2UgRFRMUyBzZXF1ZW5j ZQ0KIG51bWJlciBmb3IgbWVzc2FnZSBrZXkgZ2VuZXJhdGlvbi4gSSBhbSBub3Qgc3VyZSBob3cg dG8gZG8gdGhlIHNhbWUgdGhpbmcgYnkgY2hhbmdpbmcgU0lQIGFuZCBrZWVwaW5nIERUTFMgdGhl IHNhbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRGVjIDE5LCAyMDE2 IGF0IDE6MTggUE0sIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5A c29udXNuZXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayBTSVAvVURQL0RUTFMg bWF5IGJlIGVuaGFuY2VkIHRvIGhhdmUg4oCcZWFzeSBzd2l0Y2hvdmVyIHdpdGhvdXQgc2hhcmlu ZyBwZXItdHJhbnNhY3Rpb24gc3RhdGUgaW5mb3JtYXRpb27igJ0sDQogYW5kIGp1c3Qgd2l0aCBz b21lIC1yZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZC0gU0lQIHNpZGUgZW5oYW5jZW1lbnRzIHJh dGhlciB0aGFuIHNwZWNpZnlpbmcgYSBuZXcgdHJhbnNwb3J0L21vZGlmeWluZyBEVExTIChhbmQg SSBkb27igJl0IHRoaW5rIHRoZSBzYW1lIHdvdWxkIGJlIHBvc3NpYmxlIGZvciBTSVAvVExTL1RD UCkuIEl0IHdvdWxkIHRha2UgcXVpdGUgc29tZSB3b3JrIHRvIHBlcmZlY3QgdGhlIG1lY2hhbmlz bSBidXQgdG8gbWUgaXQNCiBsb29rcyBsaWtlIHdvcnRoIHRvIHNwZW5kIHRoZSBlZmZvcnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gY2xhc3M9Im0tNDI5NTQ1MDQ2MTY5OTE5Mzc4M2dt YWlsLSI+Jmd0OyBUaG91Z2ggSSByZW1lbWJlciBkaXNjdXNzaW9ucyB3aXRoIFJvbWFuIFNocG91 bnQgdGhhdCBEVExTIGhhcyBzb21lPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTQyOTU0NTA0 NjE2OTkxOTM3ODNnbWFpbC0iPiZndDsgc2VyaW91cyBkZWZpY2llbmNpZXMgZm9yIHJlYWxseSBs YXJnZS1zY2FsZSBzeXN0ZW1zLiZuYnNwOyBJdCBzZWVtcyBsaWtlIGEgZGVzaWduPC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJtLTQyOTU0NTA0NjE2OTkxOTM3ODNnbWFpbC0iPiZndDsgYWRqdXN0 bWVudCBtaWdodCBiZSBuZWVkZWQgZm9yIERUTFMgdG8gYmUgcmVhbGx5IHVzYWJsZSBmb3IgU0lQ IHNpZ25hbGluZy48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNDI5NTQ1MDQ2MTY5OTE5Mzc4 M2dtYWlsLSI+Jmd0OyBUaGVyZSB3YXMgYSBkaXNjdXNzaW9uIG9uIFNpcGNvcmUgYmFjayBpbiBN YXJjaC48L3NwYW4+PGJyPg0KW1RPTEdBXSBJSVRDLCBkaXNjdXNzaW9ucyB3ZXJlIGFyb3VuZCBo b3cgdG8gcHJvdmlkZSBmYXN0IGZhaWxvdmVyIHdoZW4gRFRMUyBpcyB1c2VkIHdpdGhvdXQgcmVx dWlyaW5nIHBlci10cmFuc2FjdGlvbiBzdGF0ZSBzeW5jaHJvbml6YXRpb24uIEFjdHVhbGx5LCB3 ZSAoeW91LCBSb21hbiBhbmQgSSBoYWQgc29tZSBvZmYtbGluZSBkaXNjdXNzaW9ucyByZWdhcmRp bmcgdGhpcy4gQSBzaW5nbGUtUlRUIGZhaWxvdmVyIGluZGVlZCBtYXkgcmVxdWlyZQ0KIHNvbWUg Y2hhbmdlcyBidXQgdGhhdCBpcyBmb3IgYW4gaW1wcm92ZW1lbnQgb24gZmFpbG92ZXIgdGltaW5n IHJhdGhlciB0aGFuIHRvIGFkZHJlc3MgYSBnZW5lcmljIGRlZmljaWVuY3kgaW4gRFRMUyAoYW5k IGNoYW5nZXMgZG8gbm90IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYmUgaW4gRFRMUyBpdHNlbGYgSU1I TykuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBxdWVzdGlvbiB3ZSBuZWVkIHRvIGFu c3dlciBpcyB3aGF0IG1ha2VzIFNJUC1vdmVyLURUTFMgYmV0dGVyIHRoZW4gU0lQLW92ZXItVExT LiBGb3IgYWxsIHByYWN0aWNhbCBwdXJwb3NlcyBTSVAtb3Zlci1EVExTIGNvbWJpbmVzIGRvd25z aWRlcyBvZiBTSVAtb3Zlci1UTFMgKGNvbm5lY3Rpb24gb3JpZW50ZWQsDQogY2Fubm90IGZhaWwt b3ZlciB3aXRob3V0IGV4dGVuc2l2ZSBzdGF0ZSBzaGFyaW5nKSB3aXRoIGRvd25zaWRlcyBvZiBT SVAtb3Zlci1VRFAgKHVucmVsaWFibGUsIGNhbm5vdCBiZSB1c2VkIHRvIHRyYW5zcG9ydCBsYXJn ZSBtZXNzYWdlcykuIFVubGVzcyB5b3UgY2FuIGNvbWUgdXAgd2l0aCBhIGNvbXBlbGxpbmcgcmVh c29uIHdoeSBTSVAtb3Zlci1EVExTIHdpbGwgcGVyZm9ybSBiZXR0ZXIgdGhlbiBTSVAtb3Zlci1U TFMsIHRoZXJlIGlzIG5vDQogcmVhc29uIHRvIGRlZmluZSBpdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgYmVpbmcgc2FpZCwg ZGVmaW5pbmcgYSBuZXcgVURQIGJhc2VkIHNlY3VyZSB0cmFuc3BvcnQgZm9yIFNJUCBpcyBzb21l dGhpbmcgdGhhdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSwgYnV0IHRoaXMgcHJvdG9jb2wgbmVlZHMg dG8gYmUgZGVzaWduZWQgdG8gcHJlc2VydmUgdGhlIHVzZWZ1bCBxdWFsaXRpZXMNCiBvZiBTSVAt b3Zlci1VRFAgd2hpbGUgYWRkaW5nIHNlY3VyaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_SN2PR03MB23505E3DDD74E808455A10E2B2910SN2PR03MB2350namp_-- From nobody Mon Dec 19 13:29:02 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295EE129687 for ; Mon, 19 Dec 2016 13:29:01 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 xELw03XRmeKt for ; Mon, 19 Dec 2016 13:28:58 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BE1129461 for ; Mon, 19 Dec 2016 13:28:58 -0800 (PST) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBJK18XK001037; Mon, 19 Dec 2016 21:28:55 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0024.outbound.protection.outlook.com [23.103.198.24]) by mx0a-0024ed01.pphosted.com with ESMTP id 27d05h1b7u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2016 21:28:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dVjsei93nMWL6meip2p/bQG3KiP6YbBG5+LsuCQh0yA=; b=Bp+Bxtht6mEhwKWhmk/RDfinyKmmwRjuZzrva7X08nnro8i/jNAUtPaaF39XN1Hw1EMQ5K7iu1/23F/VCKnLBOBtXdLvai6fvhxXMY7vmEjYqxTIWftM3SdUkCeArZvUn3GyJVMQxGdXi2Zv9367vCPN0TORzWbVWWXjJMjxudY= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Mon, 19 Dec 2016 21:28:53 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0771.020; Mon, 19 Dec 2016 21:28:53 +0000 From: Henning Schulzrinne To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt Thread-Index: AQHSVX1sWRRKPiOkHUi6mpUAv+5fGqEP0kPD Date: Mon, 19 Dec 2016 21:28:53 +0000 Message-ID: References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com>, <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu> In-Reply-To: <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.168.151.106] x-ms-office365-filtering-correlation-id: 49ea6399-a067-4019-cfc1-08d428560868 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:23YRX+zEqpMdDojZ0NQUoxYQ8KqmvDZ0Xz5nP/qG9p4ddCcCxLTqB5w03efhuUxR80KGOqeUQ1ivKoi0B61fsu+1qM8FyWlxbSk6l9hIUxwh5fgEuz8guj7SVTsBtT4XnvsrzczTBe1uKYJchtLAu/Q7f4hocAZTJX6SZd3KxqOo/TuuhmCt7594cOdlt9YYW3GzJMkhqUQRLTdmX2++vvWhhimFH5fXKrO5hvcfLn48vKpyS+gJgNK8AgPGu8yGDCdOvGqt3Kq4CjYCjxOHjr9WvSp1AWHIO394A/KqxYFHTOnrfIFiSKlm00tnZ6a7e4tU1+3vDmQoLtySKansoNaRLWd+rmtcyG121S0SouRHYXpJMz6h3aUiEua+9G99uFO6jIIAr9cxOGKVTdxWNN9LRGMl6sWo9nBTbxiv6DkIGPT9Hm2v50/QDbz1tlA0Ft8UAdXcSBlxqm/VQ3YRkg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558021)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(377454003)(189002)(199003)(377424004)(24454002)(5001770100001)(229853002)(76176999)(122556002)(9686002)(81166006)(230783001)(8676002)(66066001)(81156014)(7736002)(97736004)(7906003)(5660300001)(189998001)(6506006)(50986999)(77096006)(6116002)(102836003)(8936002)(101416001)(3846002)(74316002)(38730400001)(2950100002)(68736007)(3280700002)(33656002)(76576001)(3660700001)(2501003)(606005)(54356999)(107886002)(2906002)(2171001)(106356001)(99286002)(92566002)(105586002)(106116001)(2900100001)(6436002)(345774005)(25786008)(7696004)(86362001)(575784001)(4001150100001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634D6E3F2AC3C5604BF7F34EA910CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2016 21:28:53.7125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-19_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 21:29:01 -0000 --_000_CY1PR09MB0634D6E3F2AC3C5604BF7F34EA910CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for the comments. -01 will include the text suggestions you made. I would like to "ship" -01 before the holidays, so please wrap up your holi= day comment gifts and express-mail them so that only robocallers will find = coal in their stockings. Henning ________________________________ From: sipcore on behalf of Paul Kyzivat Sent: Tuesday, December 13, 2016 3:13:43 PM To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.tx= t I reviewed this new version. I have a couple of suggestions for small wording changes: * Section 1: The wording of the following: ... The called party or a automata acting on her behalf uses this to indicate that future calls from the same caller are also unwanted. is odd. AFAIK, the "called party" here is a person who interacts with the called UA to indicate that the call is unwanted. The called party doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA, acting as an automata, may generate the response without a stimulus from the called party. I suggest the following to replace the above: ... The called user agent (UAS), based on input from the called party or internal logic, uses this code to indicate that this call and future calls from the same caller are unwanted. * Section 2: This section has some text having a similar issue: None of the existing 4xx, 5xx or 6xx response codes allow the called party to convey that they not only reject this call, e.g., using 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere), 603 (Decline) or 606 (Not Acceptable), but that the caller is unwanted. I suggest: None of the existing 4xx, 5xx or 6xx response codes signify that calls from this caller are unwanted by the called party. Otherwise I like it. Thanks, Paul On 12/12/16 4:50 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core of the = IETF. > > Title : A SIP Response Code for Unwanted Calls > Author : Henning Schulzrinne > Filename : draft-ietf-sipcore-status-unwanted-00.txt > Pages : 6 > Date : 2016-12-12 > > Abstract: > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call was unwanted. The > terminating SIP entity may use this information to adjust future call > handling behavior for this called party or more broadly. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDgICAg&c=3Dy0h0omCe0= jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_= CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0RGC_RjQLE0D4e1MF8JTEvWKRNFsrY_6wj__= iKqw8lQ&e=3D > > There's also a htmlized version available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=3DDgICAg&c=3Dy0h0omCe0j= AUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_C= JxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3Dv2Iwj1kwSfluBGM44GaF1yEWLsRiOymrdGvqm= N07_P8&e=3D > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_interne= t-2Ddrafts_&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8l= DU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D= qnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiV= cV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd= 0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=3D > _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0t= M&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=3D --_000_CY1PR09MB0634D6E3F2AC3C5604BF7F34EA910CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for the comments. -01 will include the text suggestions you ma= de.


I would like to "ship" -01 before the holidays, so please=  wrap up your holiday comment gifts and express-mail them so that only= robocallers will find coal in their stockings.


Henning

From: sipcore <sipcore= -bounces@ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu&g= t;
Sent: Tuesday, December 13, 2016 3:13:43 PM
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-00.txt
 
I reviewed this new version. I have a couple of su= ggestions for small
wording changes:

* Section 1:

The wording of the following:

    ... The called party or a automata acting on her behalf = uses this
    to indicate that future calls from the same caller are a= lso unwanted.

is odd. AFAIK, the "called party" here is a person who interacts = with
the called UA to indicate that the call is unwanted. The called party
doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA,
acting as an automata, may generate the response without a stimulus from the called party.

I suggest the following to replace the above:

    ... The called user agent (UAS), based on input from the= called
    party or internal logic, uses this code to indicate that= this call
    and future calls from the same caller are unwanted.

* Section 2:

This section has some text having a similar issue:

    None of the existing 4xx, 5xx or 6xx response codes allo= w the called
    party to convey that they not only reject this call, e.g= ., using 480
    (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Ev= erywhere),
    603 (Decline) or 606 (Not Acceptable), but that the call= er is
    unwanted.

I suggest:

    None of the existing 4xx, 5xx or 6xx response codes sign= ify that
    calls from this caller are unwanted by the called party.=

Otherwise I like it.

        Thanks,
        Paul

On 12/12/16 4:50 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Session Initiation Protocol Core of t= he IETF.
>
>         Title   = ;        : A SIP Response Code for Unwan= ted Calls
>         Author  &nbs= p;       : Henning Schulzrinne
>        Filename   &n= bsp;    : draft-ietf-sipcore-status-unwanted-00.txt
>        Pages    = ;       : 6
>        Date    =         : 2016-12-12
>
> Abstract:
>    This document defines the 666 (Unwanted) SIP respons= e code, allowing
>    called parties to indicate that the call was unwante= d.  The
>    terminating SIP entity may use this information to a= djust future call
>    handling behavior for this called party or more broa= dly.
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDgICAg&c=3Dy0h= 0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&= ;m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0RGC_RjQLE0D4e1MF8= JTEvWKRNFsrY_6wj__iKqw8lQ&e=3D
>
> There's also a htmlized version available at:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=3DDgICAg&c=3Dy0h0= omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&= m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3Dv2Iwj1kwSfluBGM44Ga= F1yEWLsRiOymrdGvqmN07_P8&e=3D
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5E= iVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1= RlHtBd0tM&s=3DqnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=3D
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-= Z8WkEZo1RlHtBd0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e= =3D
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_C= JxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25E= OFNeSGgejY&e=3D
--_000_CY1PR09MB0634D6E3F2AC3C5604BF7F34EA910CY1PR09MB0634namp_-- From nobody Mon Dec 19 13:44:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101DE129695 for ; Mon, 19 Dec 2016 13:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NXClUnIx7o5M for ; Mon, 19 Dec 2016 13:44:36 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46751129418 for ; Mon, 19 Dec 2016 13:44:36 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uBJLaxY5039432; Mon, 19 Dec 2016 16:44:31 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 27ep3s3qq9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2016 16:44:31 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uBJLiUg1028247; Mon, 19 Dec 2016 16:44:30 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uBJLiIfA027984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Dec 2016 16:44:25 -0500 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 19 Dec 2016 21:44:00 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0319.002; Mon, 19 Dec 2016 16:43:59 -0500 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt Thread-Index: AQHSVX1sWRRKPiOkHUi6mpUAv+5fGqEP0kPDgAAExDE= Date: Mon, 19 Dec 2016 21:43:59 +0000 Message-ID: References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com>, <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A92CCFFC7CA242D1B474ACAD7EAB2C78attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-19_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1612190230 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 21:44:38 -0000 --_000_A92CCFFC7CA242D1B474ACAD7EAB2C78attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings Small issue with Paul's comments. The user needs to make a "clear" decision on 666 being sent. So the user pr= essing a button is clear, whether pre/post answer, but an application scena= rio is not Need to fully understand the consequences of initiating trace back and a fr= aud report Regards Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Dec 19, 2016, at 4:29 PM, Henning Schulzrinne > wrote: Thank you for the comments. -01 will include the text suggestions you made. I would like to "ship" -01 before the holidays, so please wrap up your holi= day comment gifts and express-mail them so that only robocallers will find = coal in their stockings. Henning ________________________________ From: sipcore > o= n behalf of Paul Kyzivat > Sent: Tuesday, December 13, 2016 3:13:43 PM To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.tx= t I reviewed this new version. I have a couple of suggestions for small wording changes: * Section 1: The wording of the following: ... The called party or a automata acting on her behalf uses this to indicate that future calls from the same caller are also unwanted. is odd. AFAIK, the "called party" here is a person who interacts with the called UA to indicate that the call is unwanted. The called party doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA, acting as an automata, may generate the response without a stimulus from the called party. I suggest the following to replace the above: ... The called user agent (UAS), based on input from the called party or internal logic, uses this code to indicate that this call and future calls from the same caller are unwanted. * Section 2: This section has some text having a similar issue: None of the existing 4xx, 5xx or 6xx response codes allow the called party to convey that they not only reject this call, e.g., using 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere), 603 (Decline) or 606 (Not Acceptable), but that the caller is unwanted. I suggest: None of the existing 4xx, 5xx or 6xx response codes signify that calls from this caller are unwanted by the called party. Otherwise I like it. Thanks, Paul On 12/12/16 4:50 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core of the = IETF. > > Title : A SIP Response Code for Unwanted Calls > Author : Henning Schulzrinne > Filename : draft-ietf-sipcore-status-unwanted-00.txt > Pages : 6 > Date : 2016-12-12 > > Abstract: > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call was unwanted. The > terminating SIP entity may use this information to adjust future call > handling behavior for this called party or more broadly. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDgICAg&c=3Dy0h0omCe0= jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_= CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0RGC_RjQLE0D4e1MF8JTEvWKRNFsrY_6wj__= iKqw8lQ&e=3D > > There's also a htmlized version available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=3DDgICAg&c=3Dy0h0omCe0j= AUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_C= JxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3Dv2Iwj1kwSfluBGM44GaF1yEWLsRiOymrdGvqm= N07_P8&e=3D > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_interne= t-2Ddrafts_&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8l= DU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D= qnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiV= cV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd= 0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=3D > _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0t= M&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_A92CCFFC7CA242D1B474ACAD7EAB2C78attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greetings 

Small issue with Paul's comments. 

The user needs to make a "clear" d= ecision on 666 being sent. So the user pressing a button is clear, whether = pre/post answer, but an application scenario is not

Need to fully understand the consequences of= initiating trace back and a fraud report

Regards

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Dec 19, 2016, at 4:29 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Thank you for the comments. -01 will include the text suggestions you ma= de.


I would like to "ship" -01 before the holidays, so please=  wrap up your holiday comment gifts and express-mail them so that only= robocallers will find coal in their stockings.


Henning

From: sipcore <sipcore-bounces@ietf.org> on be= half of Paul Kyzivat <pkyzivat@= alum.mit.edu>
Sent: Tuesday, December 13, 2016 3:13:43 PM
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-00.txt
 
I reviewed this new version. I have a couple of su= ggestions for small
wording changes:

* Section 1:

The wording of the following:

    ... The called party or a automata acting on her behalf = uses this
    to indicate that future calls from the same caller are a= lso unwanted.

is odd. AFAIK, the "called party" here is a person who interacts = with
the called UA to indicate that the call is unwanted. The called party
doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA,
acting as an automata, may generate the response without a stimulus from the called party.

I suggest the following to replace the above:

    ... The called user agent (UAS), based on input from the= called
    party or internal logic, uses this code to indicate that= this call
    and future calls from the same caller are unwanted.

* Section 2:

This section has some text having a similar issue:

    None of the existing 4xx, 5xx or 6xx response codes allo= w the called
    party to convey that they not only reject this call, e.g= ., using 480
    (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Ev= erywhere),
    603 (Decline) or 606 (Not Acceptable), but that the call= er is
    unwanted.

I suggest:

    None of the existing 4xx, 5xx or 6xx response codes sign= ify that
    calls from this caller are unwanted by the called party.=

Otherwise I like it.

        Thanks,
        Paul

On 12/12/16 4:50 PM, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Session Initiation Protocol Core of t= he IETF.
>
>         Title   = ;        : A SIP Response Code for Unwan= ted Calls
>         Author  &nbs= p;       : Henning Schulzrinne
>        Filename   &n= bsp;    : draft-ietf-sipcore-status-unwanted-00.txt
>        Pages    = ;       : 6
>        Date    =         : 2016-12-12
>
> Abstract:
>    This document defines the 666 (Unwanted) SIP respons= e code, allowing
>    called parties to indicate that the call was unwante= d.  The
>    terminating SIP entity may use this information to a= djust future call
>    handling behavior for this called party or more broa= dly.
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDgICAg&c=3Dy0h= 0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&= ;m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0RGC_RjQLE0D4e1MF8= JTEvWKRNFsrY_6wj__iKqw8lQ&e=3D
>
> There's also a htmlized version available at:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=3DDgICAg&c=3Dy0h0= omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&= m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3Dv2Iwj1kwSfluBGM44Ga= F1yEWLsRiOymrdGvqmN07_P8&e=3D
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5E= iVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1= RlHtBd0tM&s=3DqnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=3D
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-= Z8WkEZo1RlHtBd0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e= =3D
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_C= JxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25E= OFNeSGgejY&e=3D
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_A92CCFFC7CA242D1B474ACAD7EAB2C78attcom_-- From nobody Tue Dec 20 10:38:13 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D842129665 for ; Tue, 20 Dec 2016 10:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 ySpMlgD7UlTX for ; Tue, 20 Dec 2016 10:38:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6391612947D for ; Tue, 20 Dec 2016 10:38:10 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBKIbZrl080452 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Dec 2016 12:37:36 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Asveren, Tolga" , Paul Kyzivat , "sipcore@ietf.org" References: <87k2b1ovef.fsf@hobgoblin.ariadne.com> <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> <2D5B09A4-4FB1-4238-964D-EB76BEB94378@edvina.net> <2EE33F1D-C4DF-4C52-8639-A426B5C48940@edvina.net> <6BBEB7E7-D02B-44A4-960C-077AC51F3BD0@edvina.net> From: Adam Roach Message-ID: <3e3eafd5-4abc-f4ea-431d-c8a27a2ba755@nostrum.com> Date: Tue, 20 Dec 2016 12:37:35 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 18:38:12 -0000 [as chair] Paul is right -- this is a core protocol change that would have been in scope even prior to the rechartering. I'm going to send out an email shortly that talks about some potential milestones for our new charter; and, given that there seems to be some interest in this area, it should be part of that discussion. /a On 12/19/16 00:49, Asveren, Tolga wrote: > I will try to prepare an initial draft. > > And meanwhile, it would be great if the chairs can decide whether re-chartering is needed. I think this work is "in-scope" as far as its content but obviously is not in the list of current goals. > > Thanks, > Tolga > >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Sunday, December 18, 2016 11:46 AM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport >> >> On 12/18/16 10:57 AM, Olle E. Johansson wrote: >>>> On 18 Dec 2016, at 14:52, Asveren, Tolga >> wrote: >>>> Yes, definitely useful in practice. I certainly am interested in working on >> the needed specification. Is there a reason why the work should not start as >> a parallel activity? >>> No, if there are people interested that’s fine. I suspect it has to start in >> dispatch, but the chairs can explain more. >> >> I don't believe it must start in Dispatch. It clearly falls in scope of sipcore, >> even without the recent recharter. But I think it will need a new milestone. >> >> Thanks, >> Paul >> >>> /O >>>> Thanks, >>>> Tolga >>>> >>>>> -----Original Message----- >>>>> From: Olle E. Johansson [mailto:oej@edvina.net] >>>>> Sent: Sunday, December 18, 2016 7:23 AM >>>>> To: Asveren, Tolga >>>>> Cc: Olle E Johansson ; Dale R. Worley >>>>> ; sipcore@ietf.org >>>>> Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP >>>>> transport >>>>> >>>>> >>>>>> On 18 Dec 2016, at 12:20, Asveren, Tolga >>>>> wrote: >>>>>> One correction for my previous message: >>>>>> "SIP+D2U" => "SIPS+D2U" >>>>>> >>>>>> And yes, there is yet another IANA Registry to be updated as you >>>>> mentioned and some other work, mea culpa. >>>>>> There obviously will be a need to extend syntax for relevant SIP >>>>> headers/parameters and semantics to use it as one of the valid >> protocols. >>>>> OTOH, I don't think there would be thorny issues and it would be >>>>> mostly replicating what has been done/said about other transport >> protocols. >>>>> Dale and I had a discussion about it at SIPit and it’s an >>>>> interesting mix of connection-less and connection-oriented that needs >> some documentation. >>>>> But I do think it will help a lot of large-scale platforms. >>>>> >>>>> /O >>>>>> Thanks, >>>>>> Tolga >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Olle E. Johansson [mailto:oej@edvina.net] >>>>>>> Sent: Sunday, December 18, 2016 5:58 AM >>>>>>> To: Asveren, Tolga >>>>>>> Cc: Olle E Johansson ; Dale R. Worley >>>>>>> ; sipcore@ietf.org >>>>>>> Subject: Re: [sipcore] Happy Eyeballs for SIP >>>>>>> >>>>>>> >>>>>>>> On 18 Dec 2016, at 10:50, Asveren, Tolga >>>>>>> wrote: >>>>>>>>> DTLS for SIP/UDP is not specified yet, so as of now that is out of >> scope. >>>>>>>>> But I do agree that it will be interesting. >>>>>>>> [TOLGA] Probably you are referring to "SIP+D2U" currently not >>>>>>>> being in the >>>>>>> IANA Registry. I think it should. I will craft a draft for that. >>>>>>>> On another note, static configurations (e.g. both IPv4/IPv6 >>>>>>>> Addresses are >>>>>>> provisioned for a target, by whatever means) and DHCP based >>>>>>> learning of addresses for SIP Servers (RFC3361, RFC3319) should be >> considered. >>>>>>> So, I think SIP/UDP/DTLS is "allowed" afterall. And it is >>>>>>> connection-oriented, therefore should be covered by happy-earballs >>>>> IMHO. >>>>>>> There is simply no standard for DTLS as a transport for SIP. >>>>>>> http://www.iana.org/assignments/sip-parameters/sip- >>>>>>> parameters.xhtml#sip-transport >>>>>>> >>>>>>> I agree it would be a good thing, but it requires more work than >>>>>>> adding it to the NAPTR registry. >>>>>>> /O >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 20 12:27:19 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3161295F4 for ; Tue, 20 Dec 2016 12:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 aPKS_Tln4koU for ; Tue, 20 Dec 2016 12:27:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC831295F0 for ; Tue, 20 Dec 2016 12:27:17 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBKKRF8j091023 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Dec 2016 14:27:16 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" From: Adam Roach Message-ID: Date: Tue, 20 Dec 2016 14:27:15 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E296881C99DCCA5BB7B28506" Archived-At: Cc: Ben Campbell Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:27:18 -0000 This is a multi-part message in MIME format. --------------E296881C99DCCA5BB7B28506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as chair] Now that we have our new charter approved, I'd like the working group to have a discussion about the specific work items that we should take on in the short- to medium-term so that we can revise our milestones appropriately. Based on recent discussions on the mailing list, the following topics have some mind-share behind them. What I'd like from everyone with an interest in any of these topics is to indicate (a) whether you are willing to actively review and comment on documents on the topic; and (b) what priority each task has relative to each other: there are five topics; please indicate a unique priority from one (most important) to five (least important) for each topic. 1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently under discussion on the list. 2. "DTLS Transport for SIP", as proposed by Tolga Asveren's recent messages. 3. A mechanism for labeling the nature of SIP calls, with as a likely candidate draft. 4. Fixing Content-ID in SIP, as discussed in , with as a likely candidate draft. 5. Clarifications around SIP name-addr, with as a likely candidate draft I will also note that we have already declared consensus on adopting as a WG document, and will be adding an associated milestone. I want to take this opportunity to remind people that the document is in WGLC, and your comments are strongly encouraged, the earlier the better. Please respond before the end of 2016. Thanks! Thanks! /a --------------E296881C99DCCA5BB7B28506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit [as chair]

Now that we have our new charter approved, I'd like the working group to have a discussion about the specific work items that we should take on in the short- to medium-term so that we can revise our milestones appropriately. Based on recent discussions on the mailing list, the following topics have some mind-share behind them. What I'd like from everyone with an interest in any of these topics is to indicate (a) whether you are willing to actively review and comment on documents on the topic; and (b) what priority each task has relative to each other: there are five topics; please indicate a unique priority from one (most important) to five (least important) for each topic.

  1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently under discussion on the list.
  2. "DTLS Transport for SIP", as proposed by Tolga Asveren's recent messages.
  3. A mechanism for labeling the nature of SIP calls, with <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidate draft.
  4. Fixing Content-ID in SIP, as discussed in <https://www.ietf.org/mail-archive/web/sipcore/current/msg07245.html>, with <draft-holmberg-sipcore-content-id> as a likely candidate draft.
  5. Clarifications around SIP name-addr, with <draft-sparks-sipcore-name-addr-guidance> as a likely candidate draft

I will also note that we have already declared consensus on adopting <draft-ietf-sipcore-status-unwanted> as a WG document, and will be adding an associated milestone. I want to take this opportunity to remind people that the document is in WGLC, and your comments are strongly encouraged, the earlier the better.

Please respond before the end of 2016. Thanks!

Thanks!

/a
--------------E296881C99DCCA5BB7B28506-- From nobody Tue Dec 20 13:17:30 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8912B129635 for ; Tue, 20 Dec 2016 13:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 8aq3fxhtDN0p for ; Tue, 20 Dec 2016 13:17:28 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF2C12962E for ; Tue, 20 Dec 2016 13:17:28 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with SMTP id JRmTcWnxTuazMJRmpcBiku; Tue, 20 Dec 2016 21:17:27 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-09v.sys.comcast.net with SMTP id JRmncgosonS0qJRmocepTu; Tue, 20 Dec 2016 21:17:27 +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 uBKLGP02025934; Tue, 20 Dec 2016 16:16:25 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBKLGNvl025926; Tue, 20 Dec 2016 16:16:23 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: <2E1B0F72-7438-4EA3-B39A-24969494B981@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 20 Dec 2016 16:16:23 -0500 Message-ID: <878traxpw8.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfPFynNGNJNYPXFDnm3p3tduPx3v/DbvhKyjBJi1A8YcMqBLptUMX5MogitGDsUYsxB+WM+fj6CagXlKMEJrd4O+DnW41yerO4h4Z01IdLGBVSYgWdcR3 M77kAL0WEtOsM/fRqBbXzSFiB1WAZ42Ul0EE/x1/wO0ij+ff+wERDFMP6IXeB6aOz9uSuyBe2n//Gw== Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] Happy Eyeballs for SIP - Technical recommendations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 21:17:29 -0000 "Olle E. Johansson" writes: > In regards to the current draft for connection-oriented SIP flows, I > am not happy about copying a lot of text from the Happy Eyeballs RFC > into this doc. > > Happy Eyeballs is a large solution space and the important part of the > RFC is the requirements - the solutions vary. Copying text from that > RFC could mean we copy stuff that is out of scope and already old > compared with today's implementations and that we by accident limit > the solution space for SIP, which would be unfortunate. The SIP > solution for setting up a connection is in no way different from other > protocols and thus I think we will be better off and have a smoother > path to publication by just pointing to the Happy Eyeballs RFC than > starting to copy parts without us authors having current > implementation experience. Ultimately, what goes into this draft/RFC is the working group's decision. But in the mean time, we can check that we've got a correct understanding of this tranche of the problem, so that decision becomes essentially editorial rather than technical: - Have we got the separation of requirements and solutions right? The requirements (on SIP devices) should be stated with MUST. Solution advice should be stated with SHOULD or even non-normative language. - Have we got up-to-date recommendations for the solutions? Most of the current language is copied from RFC 6555. Are there known improvements on that of wide applicability? - Are the recommendations that are relevant for SIP but not for HTTP, and thus are new relative to RFC 6555, properly done? (This is section 5 in draft-worley-sip-he-connection-01.) So far, we haven't had much discussion of the technical content. Dale From nobody Tue Dec 20 20:53:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9A4129460 for ; Tue, 20 Dec 2016 20:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 t4-yzYWVvu5w for ; Tue, 20 Dec 2016 20:53:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D2112945B for ; Tue, 20 Dec 2016 20:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3166; q=dns/txt; s=iport; t=1482295985; x=1483505585; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QiIEVcggf8VRrZQYbZvyYiCvDjT8iVaeTtK6cITllFM=; b=jW5yqZbqeHBJ2SBQBiUaycOcP6up+sh46bl+bjS/qm3Z0zaQ9hY1Xh/h phCtoT26W3wS7JEYwVipTK80OP7kqFvrzBsFuin8X5M1Ec7/sMWeL23fm QxWeEHpZDCBt/NumuH/HCezdLC/Ks0/iY2tCmHelSL9lwtQm/IdrFsnmK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCCClpY/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzYBAQEBAR9agQYHjUmWWZUOggofC4UuSgIagVA/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEDAQEBEBEROgIJBQsCAQgYAgImAgICJQsVEAIEDgUiiEEIDplnA?= =?us-ascii?q?Y12giiLFAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFK4F9glyEIwEBG4MELYI?= =?us-ascii?q?wBY8Bi28BkTOBdIUDiVaOGoQOAR83gSYsDwGFSnIBhliBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,381,1477958400"; d="scan'208";a="187952988" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2016 04:52:43 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uBL4qhBD008775 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Dec 2016 04:52:43 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Dec 2016 22:52:42 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Tue, 20 Dec 2016 22:52:42 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Adam Roach Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv95G6VmhE95f0GNmphVO/F+2aESOrYA Date: Wed, 21 Dec 2016 04:52:42 +0000 Message-ID: <0C597C24-AE5C-4E3F-BD19-569B20B0AC62@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.226.176] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , SIPCORE Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 04:53:08 -0000 DQpDb25zaWRlcmluZyB0aGF0IHdlIGFscmVhZHkgYWdyZWVkIGluIEJlcmxpbiB0byB0YWtlIG9u ICJIYXBweSBFeWViYWxscyBmb3IgU0lQ4oCdIGFzIGEgbWlsZXN0b25lLCBJIHRoaW5rIHRoYXQg c2hvdWxkIGJlIHByaW9yaXRpemVkLiAgV2UgYXJlIG9idmlvdXNseSB3aWxsaW5nIHRvIHdvcmsg b24gdGhpcyBhbmQgaGF2ZSBhbHJlYWR5IHB1dCBmb3J0aCBhIGNhbmRpZGF0ZSBkcmFmdCB0byBz YXRpc2Z5IHRoaXMgbWlsZXN0b25lIChkcmFmdC13b3JsZXktc2lwLWhlLWNvbm5lY3Rpb24pIHRo YXQgd2XigJlyZSBob3BpbmcgdGhlIFdHIHdpbGwgY29uc2lkZXIgZm9yIGFkb3B0aW9uLg0KDQpD aGVlcnMsDQoNCkdvbnphbG8NCg0KPiBPbiBEZWMgMjAsIDIwMTYsIGF0IDM6MjcgUE0sIEFkYW0g Um9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPiANCj4gW2FzIGNoYWlyXQ0KPiANCj4g Tm93IHRoYXQgd2UgaGF2ZSBvdXIgbmV3IGNoYXJ0ZXIgYXBwcm92ZWQsIEknZCBsaWtlIHRoZSB3 b3JraW5nIGdyb3VwIHRvIGhhdmUgYSBkaXNjdXNzaW9uIGFib3V0IHRoZSBzcGVjaWZpYyB3b3Jr IGl0ZW1zIHRoYXQgd2Ugc2hvdWxkIHRha2Ugb24gaW4gdGhlIHNob3J0LSB0byBtZWRpdW0tdGVy bSBzbyB0aGF0IHdlIGNhbiByZXZpc2Ugb3VyIG1pbGVzdG9uZXMgYXBwcm9wcmlhdGVseS4gQmFz ZWQgb24gcmVjZW50IGRpc2N1c3Npb25zIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHRoZSBmb2xsb3dp bmcgdG9waWNzIGhhdmUgc29tZSBtaW5kLXNoYXJlIGJlaGluZCB0aGVtLiBXaGF0IEknZCBsaWtl IGZyb20gZXZlcnlvbmUgd2l0aCBhbiBpbnRlcmVzdCBpbiBhbnkgb2YgdGhlc2UgdG9waWNzIGlz IHRvIGluZGljYXRlIChhKSB3aGV0aGVyIHlvdSBhcmUgd2lsbGluZyB0byBhY3RpdmVseSByZXZp ZXcgYW5kIGNvbW1lbnQgb24gZG9jdW1lbnRzIG9uIHRoZSB0b3BpYzsgYW5kIChiKSB3aGF0IHBy aW9yaXR5IGVhY2ggdGFzayBoYXMgcmVsYXRpdmUgdG8gZWFjaCBvdGhlcjogdGhlcmUgYXJlIGZp dmUgdG9waWNzOyBwbGVhc2UgaW5kaWNhdGUgYSB1bmlxdWUgcHJpb3JpdHkgZnJvbSBvbmUgKG1v c3QgaW1wb3J0YW50KSB0byBmaXZlIChsZWFzdCBpbXBvcnRhbnQpIGZvciBlYWNoIHRvcGljLg0K PiANCj4gCeKAoiAiSGFwcHkgRXllYmFsbHMgZm9yIFNJUCIgKGFrYSBIYXBweSBFYXJiYWxscyks IGN1cnJlbnRseSB1bmRlciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Lg0KPiAJ4oCiICJEVExTIFRy YW5zcG9ydCBmb3IgU0lQIiwgYXMgcHJvcG9zZWQgYnkgVG9sZ2EgQXN2ZXJlbidzIHJlY2VudCBt ZXNzYWdlcy4NCj4gCeKAoiBBIG1lY2hhbmlzbSBmb3IgbGFiZWxpbmcgdGhlIG5hdHVyZSBvZiBT SVAgY2FsbHMsIHdpdGggPGRyYWZ0LXNjaHVsenJpbm5lLXNpcGNvcmUtY2FsbGluZm8tc3BhbT4g YXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0Lg0KPiAJ4oCiIEZpeGluZyBDb250ZW50LUlEIGlu IFNJUCwgYXMgZGlzY3Vzc2VkIGluIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNzI0NS5odG1sPiwgd2l0aCA8ZHJhZnQtaG9sbWJlcmct c2lwY29yZS1jb250ZW50LWlkPiBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQuDQo+IAnigKIg Q2xhcmlmaWNhdGlvbnMgYXJvdW5kIFNJUCBuYW1lLWFkZHIsIHdpdGggPGRyYWZ0LXNwYXJrcy1z aXBjb3JlLW5hbWUtYWRkci1ndWlkYW5jZT4gYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0DQo+ IA0KPiBJIHdpbGwgYWxzbyBub3RlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGRlY2xhcmVkIGNvbnNl bnN1cyBvbiBhZG9wdGluZyA8ZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZD4gYXMg YSBXRyBkb2N1bWVudCwgYW5kIHdpbGwgYmUgYWRkaW5nIGFuIGFzc29jaWF0ZWQgbWlsZXN0b25l LiBJIHdhbnQgdG8gdGFrZSB0aGlzIG9wcG9ydHVuaXR5IHRvIHJlbWluZCBwZW9wbGUgdGhhdCB0 aGUgZG9jdW1lbnQgaXMgaW4gV0dMQywgYW5kIHlvdXIgY29tbWVudHMgYXJlIHN0cm9uZ2x5IGVu Y291cmFnZWQsIHRoZSBlYXJsaWVyIHRoZSBiZXR0ZXIuDQo+IA0KPiBQbGVhc2UgcmVzcG9uZCBi ZWZvcmUgdGhlIGVuZCBvZiAyMDE2LiBUaGFua3MhDQo+IA0KPiBUaGFua3MhDQo+IA0KPiAvYQ0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBj b3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQo= From nobody Wed Dec 21 00:53:33 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C827A129C4F for ; Wed, 21 Dec 2016 00:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 4OwIfP1IiEPT for ; Wed, 21 Dec 2016 00:53:29 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0047.outbound.protection.outlook.com [104.47.37.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDCA129C51 for ; Wed, 21 Dec 2016 00:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BQEufyhkJeHoyo4jBdoWZA2OYtNFi9wHzl36aHbvs5k=; b=qtQWFNI+PEi1+/PeSHSgivTTBNDB7LHTBV8eYXgJWLorHdHgZRGgIS9232MQadHKHQT98zeDp8YH5uG1XEh+zcEmKQgIZo6ZOM+BtVKW+4OQd1rBXiPzs7Og7rHqp7uBQSi4e79DwrGC/E+Faev9kAH2IF/5D1kj/WPS4FbJfIA= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 08:49:09 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 08:49:09 +0000 From: "Asveren, Tolga" To: Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv96++N6DRIq/E2cKGNWf6YDKaESFXXw Date: Wed, 21 Dec 2016 08:49:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 4852b1d6-e50d-43ac-04a2-08d4297e3b06 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:pzYNko8w4ijP7WwSveT02iqhnAjYbXTIKJ4kzX192eBMUh7LEQXmjJeYFim5RmraWMnFf5FDv6x3wMme+8WhhnfRyyce9ZWnQM0UgifY8ZvdWuObBDNKOQ8EJT8zzbo5L7HwPgO6eMeao03EboXRwSJqIj2caYkjn1DX35K6mT81SpsVjB8cmHxBV6Y6QWPfEQI7ivQkyOYVrc4DS8mWVrXudl0WumubVaO3g5FEOgK3NV7fJzmHQxAdQ/4XWbe24xHJkkJTjrtJL91turWBbgVrLtgeIU9oYRXBDN6PtCR+B6Rvn83rxb8u98AFlh6C+bk1IMPeERGMD35k+W9jKB4F1JtFMFCWtxDAuSc+cNU8L5CrDjk8XH/20awjDxilD17gRSxkx0TTMubPmn/DbdCvXOuWDVFCyuHrUu4nG6DnD0HOXDklX9USwcg0rsAyYFeR5bJZMaVpy9VljnvjTQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(377454003)(199003)(68736007)(2900100001)(54356999)(5660300001)(6436002)(3846002)(102836003)(6116002)(790700001)(2950100002)(25786008)(189998001)(33656002)(7696004)(101416001)(606005)(6506006)(50986999)(77096006)(8676002)(122556002)(76176999)(74316002)(7906003)(92566002)(97736004)(7736002)(81166006)(229853002)(81156014)(99286002)(38730400001)(105586002)(106116001)(86362001)(2906002)(9686002)(3660700001)(76576001)(66066001)(8936002)(4326007)(5001770100001)(3280700002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23505D69C200C8D7B533CBF2B2930SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2016 08:49:09.6768 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 Archived-At: Cc: Ben Campbell Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 08:53:32 -0000 --_000_SN2PR03MB23505D69C200C8D7B533CBF2B2930SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ydGVkIGFjY29yZGluZyB0byBteSBvcmRlciBvZiBwcmVmZXJlbmNlOg0KDQppLSBBIG1lY2hh bmlzbSBmb3IgbGFiZWxpbmcgdGhlIG5hdHVyZSBvZiBTSVAgY2FsbHMsIHdpdGggPGRyYWZ0LXNj aHVsenJpbm5lLXNpcGNvcmUtY2FsbGluZm8tc3BhbT4gYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRy YWZ0Lg0KSSBjYW4gYWN0aXZlbHkgcmV2aWV3LiBUaGlzIGRyYWZ0IGFkZHJlc3NlcyBhIHJlYWwv cHJhY3RpY2FsL3VyZ2VudCBpbmR1c3RyeSBuZWVkLg0KDQppaS0gIkhhcHB5IEV5ZWJhbGxzIGZv ciBTSVAiIChha2EgSGFwcHkgRWFyYmFsbHMpLCBjdXJyZW50bHkgdW5kZXIgZGlzY3Vzc2lvbiBv biB0aGUgbGlzdC4NCkkgY2FuIGFjdGl2ZWx5IHJldmlldy9jby1hdXRob3IuIFRoaXMgc2hvdWxk buKAmXQ7IHRha2UgdG9vIGxvbmcgYW5kIHByb2JhYmx5IHdvdWxkIGVuZCB1cCBzdGFuZGFyZGl6 aW5nIGEgZmV3IGNvbW1vbi1zZW5zZS9hbG1vc3Qgb2J2aW91cyBzZW1hbnRpY3MvY2hhbmdlcyBp biBjdXJyZW50bHkgZGVmaW5lZCBwcm9jZWR1cmVzIC13aGljaCBtYWtlcyBpdCBpbXBvcnRhbnQt DQoNCmlpaS0gIkRUTFMgVHJhbnNwb3J0IGZvciBTSVAiLCBhcyBwcm9wb3NlZCBieSBUb2xnYSBB c3ZlcmVuJ3MgcmVjZW50IG1lc3NhZ2VzLg0KSSBjYW4gKGNvKS1hdXRob3IuIFVzZSBvZiBVRFAg aW4gYSBzZWN1cmUgd2F5IGlzIGltcG9ydGFudCBmb3IgbGFyZ2Utc2NhbGUgc2VydmVycy4NCg0K VGhlIG90aGVyIHR3byBhcmUgb2YgZXF1YWwgaW1wb3J0YW5jZSBmcm9tIG15IHBlcnNwZWN0aXZl IGFuZCBhcmUgYXQgdGhlIGJvdHRvbSBvZiBteSBsaXN0Lg0KDQpJIGFzc3VtZSBhbnkgUkZDNjU1 NSBIYXBweSBFeWViYWxscyByZWxhdGVkIGRpc2N1c3Npb25zL2JpcyBhY3Rpdml0eSBzaG91bGQg dGFrZSBwbGFjZSBtYWlubHkgaW4gdGhlIFY2b3BzIFdHKD8pDQoNClRoYW5rcywNClRvbGdhDQoN CkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBZGFtIFJvYWNoDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyMCwgMjAxNiAzOjI3IFBN DQpUbzogJ1NJUENPUkUnIDxzaXBjb3JlQGlldGYub3JnPg0KQ2M6IEJlbiBDYW1wYmVsbCA8YmVu QG5vc3RydW0uY29tPg0KU3ViamVjdDogW3NpcGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RFRDogU0lQ Q09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzDQoNClthcyBjaGFpcl0NCg0KTm93IHRoYXQgd2UgaGF2 ZSBvdXIgbmV3IGNoYXJ0ZXIgYXBwcm92ZWQsIEknZCBsaWtlIHRoZSB3b3JraW5nIGdyb3VwIHRv IGhhdmUgYSBkaXNjdXNzaW9uIGFib3V0IHRoZSBzcGVjaWZpYyB3b3JrIGl0ZW1zIHRoYXQgd2Ug c2hvdWxkIHRha2Ugb24gaW4gdGhlIHNob3J0LSB0byBtZWRpdW0tdGVybSBzbyB0aGF0IHdlIGNh biByZXZpc2Ugb3VyIG1pbGVzdG9uZXMgYXBwcm9wcmlhdGVseS4gQmFzZWQgb24gcmVjZW50IGRp c2N1c3Npb25zIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHRoZSBmb2xsb3dpbmcgdG9waWNzIGhhdmUg c29tZSBtaW5kLXNoYXJlIGJlaGluZCB0aGVtLiBXaGF0IEknZCBsaWtlIGZyb20gZXZlcnlvbmUg d2l0aCBhbiBpbnRlcmVzdCBpbiBhbnkgb2YgdGhlc2UgdG9waWNzIGlzIHRvIGluZGljYXRlIChh KSB3aGV0aGVyIHlvdSBhcmUgd2lsbGluZyB0byBhY3RpdmVseSByZXZpZXcgYW5kIGNvbW1lbnQg b24gZG9jdW1lbnRzIG9uIHRoZSB0b3BpYzsgYW5kIChiKSB3aGF0IHByaW9yaXR5IGVhY2ggdGFz ayBoYXMgcmVsYXRpdmUgdG8gZWFjaCBvdGhlcjogdGhlcmUgYXJlIGZpdmUgdG9waWNzOyBwbGVh c2UgaW5kaWNhdGUgYSB1bmlxdWUgcHJpb3JpdHkgZnJvbSBvbmUgKG1vc3QgaW1wb3J0YW50KSB0 byBmaXZlIChsZWFzdCBpbXBvcnRhbnQpIGZvciBlYWNoIHRvcGljLg0KDQogIDEuICAiSGFwcHkg RXllYmFsbHMgZm9yIFNJUCIgKGFrYSBIYXBweSBFYXJiYWxscyksIGN1cnJlbnRseSB1bmRlciBk aXNjdXNzaW9uIG9uIHRoZSBsaXN0Lg0KICAyLiAgIkRUTFMgVHJhbnNwb3J0IGZvciBTSVAiLCBh cyBwcm9wb3NlZCBieSBUb2xnYSBBc3ZlcmVuJ3MgcmVjZW50IG1lc3NhZ2VzLg0KICAzLiAgQSBt ZWNoYW5pc20gZm9yIGxhYmVsaW5nIHRoZSBuYXR1cmUgb2YgU0lQIGNhbGxzLCB3aXRoIDxkcmFm dC1zY2h1bHpyaW5uZS1zaXBjb3JlLWNhbGxpbmZvLXNwYW0+IGFzIGEgbGlrZWx5IGNhbmRpZGF0 ZSBkcmFmdC4NCiAgNC4gIEZpeGluZyBDb250ZW50LUlEIGluIFNJUCwgYXMgZGlzY3Vzc2VkIGlu IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9t c2cwNzI0NS5odG1sPjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNv cmUvY3VycmVudC9tc2cwNzI0NS5odG1sPiwgd2l0aCA8ZHJhZnQtaG9sbWJlcmctc2lwY29yZS1j b250ZW50LWlkPiBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQuDQogIDUuICBDbGFyaWZpY2F0 aW9ucyBhcm91bmQgU0lQIG5hbWUtYWRkciwgd2l0aCA8ZHJhZnQtc3BhcmtzLXNpcGNvcmUtbmFt ZS1hZGRyLWd1aWRhbmNlPiBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQNCg0KSSB3aWxsIGFs c28gbm90ZSB0aGF0IHdlIGhhdmUgYWxyZWFkeSBkZWNsYXJlZCBjb25zZW5zdXMgb24gYWRvcHRp bmcgPGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQ+IGFzIGEgV0cgZG9jdW1lbnQs IGFuZCB3aWxsIGJlIGFkZGluZyBhbiBhc3NvY2lhdGVkIG1pbGVzdG9uZS4gSSB3YW50IHRvIHRh a2UgdGhpcyBvcHBvcnR1bml0eSB0byByZW1pbmQgcGVvcGxlIHRoYXQgdGhlIGRvY3VtZW50IGlz IGluIFdHTEMsIGFuZCB5b3VyIGNvbW1lbnRzIGFyZSBzdHJvbmdseSBlbmNvdXJhZ2VkLCB0aGUg ZWFybGllciB0aGUgYmV0dGVyLg0KDQpQbGVhc2UgcmVzcG9uZCBiZWZvcmUgdGhlIGVuZCBvZiAy MDE2LiBUaGFua3MhDQoNClRoYW5rcyENCg0KL2ENCg== --_000_SN2PR03MB23505D69C200C8D7B533CBF2B2930SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IjsNCglwYW5vc2UtMToyIDE1IDMgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTg2Mjc0NTc4MTsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTUxNDY3OTAyNDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSBMaWdodCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPlNvcnRlZCBhY2NvcmRpbmcgdG8gbXkg b3JkZXIgb2YgcHJlZmVyZW5jZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpIExpZ2h0JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aS0gQSBtZWNoYW5pc20g Zm9yIGxhYmVsaW5nIHRoZSBuYXR1cmUgb2YgU0lQIGNhbGxzLCB3aXRoICZsdDtkcmFmdC1zY2h1 bHpyaW5uZS1zaXBjb3JlLWNhbGxpbmZvLXNwYW0mZ3Q7IGFzIGEgbGlrZWx5IGNhbmRpZGF0ZSBk cmFmdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIGFjdGl2ZWx5 IHJldmlldy4gVGhpcyBkcmFmdCBhZGRyZXNzZXMgYSByZWFsL3ByYWN0aWNhbC91cmdlbnQgaW5k dXN0cnkgbmVlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aWktICZxdW90O0hhcHB5IEV5ZWJh bGxzIGZvciBTSVAmcXVvdDsgKGFrYSBIYXBweSBFYXJiYWxscyksIGN1cnJlbnRseSB1bmRlciBk aXNjdXNzaW9uIG9uIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBjYW4gYWN0aXZlbHkgcmV2aWV3L2NvLWF1dGhvci4gVGhpcyBzaG91bGRu4oCZdDsgdGFr ZSB0b28gbG9uZyBhbmQgcHJvYmFibHkgd291bGQgZW5kIHVwIHN0YW5kYXJkaXppbmcgYSBmZXcg Y29tbW9uLXNlbnNlL2FsbW9zdCBvYnZpb3VzIHNlbWFudGljcy9jaGFuZ2VzIGluIGN1cnJlbnRs eSBkZWZpbmVkIHByb2NlZHVyZXMgLXdoaWNoIG1ha2VzIGl0IGltcG9ydGFudC08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+aWlpLSAmcXVvdDtEVExTIFRyYW5zcG9ydCBmb3IgU0lQJnF1b3Q7LCBh cyBwcm9wb3NlZCBieSBUb2xnYSBBc3ZlcmVuJ3MgcmVjZW50IG1lc3NhZ2VzLjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOndpbmRvd3RleHQiPkkgY2FuIChjbyktYXV0aG9yLiBVc2Ugb2YgVURQIGluIGEgc2VjdXJl IHdheSBpcyBpbXBvcnRhbnQgZm9yIGxhcmdlLXNjYWxlIHNlcnZlcnMuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5k b3d0ZXh0Ij5UaGUgb3RoZXIgdHdvIGFyZSBvZiBlcXVhbCBpbXBvcnRhbmNlIGZyb20gbXkgcGVy c3BlY3RpdmUgYW5kIGFyZSBhdCB0aGUgYm90dG9tIG9mIG15IGxpc3QuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93 dGV4dCI+SSBhc3N1bWUgYW55IFJGQzY1NTUgSGFwcHkgRXllYmFsbHMgcmVsYXRlZCBkaXNjdXNz aW9ucy9iaXMgYWN0aXZpdHkgc2hvdWxkIHRha2UgcGxhY2UgbWFpbmx5IGluIHRoZSBWNm9wcyBX Ryg/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3 aW5kb3d0ZXh0Ij5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IHNpcGNvcmUgW21haWx0bzpz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFkYW0gUm9hY2g8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMjAsIDIwMTYgMzoyNyBQTTxicj4N CjxiPlRvOjwvYj4gJ1NJUENPUkUnICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPkNj OjwvYj4gQmVuIENhbXBiZWxsICZsdDtiZW5Abm9zdHJ1bS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUgd29yayBhbmQgbWls ZXN0b25lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+W2FzIGNoYWlyXTxicj4NCjxicj4NCk5vdyB0aGF0 IHdlIGhhdmUgb3VyIG5ldyBjaGFydGVyIGFwcHJvdmVkLCBJJ2QgbGlrZSB0aGUgd29ya2luZyBn cm91cCB0byBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgc3BlY2lmaWMgd29yayBpdGVtcyB0 aGF0IHdlIHNob3VsZCB0YWtlIG9uIGluIHRoZSBzaG9ydC0gdG8gbWVkaXVtLXRlcm0gc28gdGhh dCB3ZSBjYW4gcmV2aXNlIG91ciBtaWxlc3RvbmVzIGFwcHJvcHJpYXRlbHkuIEJhc2VkIG9uIHJl Y2VudCBkaXNjdXNzaW9ucyBvbiB0aGUNCiBtYWlsaW5nIGxpc3QsIHRoZSBmb2xsb3dpbmcgdG9w aWNzIGhhdmUgc29tZSBtaW5kLXNoYXJlIGJlaGluZCB0aGVtLiBXaGF0IEknZCBsaWtlIGZyb20g ZXZlcnlvbmUgd2l0aCBhbiBpbnRlcmVzdCBpbiBhbnkgb2YgdGhlc2UgdG9waWNzIGlzIHRvIGlu ZGljYXRlIChhKSB3aGV0aGVyIHlvdSBhcmUgd2lsbGluZyB0byBhY3RpdmVseSByZXZpZXcgYW5k IGNvbW1lbnQgb24gZG9jdW1lbnRzIG9uIHRoZSB0b3BpYzsgYW5kIChiKSB3aGF0IHByaW9yaXR5 DQogZWFjaCB0YXNrIGhhcyByZWxhdGl2ZSB0byBlYWNoIG90aGVyOiB0aGVyZSBhcmUgZml2ZSB0 b3BpY3M7IHBsZWFzZSBpbmRpY2F0ZSBhIHVuaXF1ZSBwcmlvcml0eSBmcm9tIG9uZSAobW9zdCBp bXBvcnRhbnQpIHRvIGZpdmUgKGxlYXN0IGltcG9ydGFudCkgZm9yIGVhY2ggdG9waWMuPG86cD48 L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQomcXVvdDtIYXBweSBFeWViYWxscyBmb3IgU0lQ JnF1b3Q7IChha2EgSGFwcHkgRWFyYmFsbHMpLCBjdXJyZW50bHkgdW5kZXIgZGlzY3Vzc2lvbiBv biB0aGUgbGlzdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQomcXVvdDtEVExTIFRyYW5zcG9ydCBmb3IgU0lQJnF1b3Q7LCBh cyBwcm9wb3NlZCBieSBUb2xnYSBBc3ZlcmVuJ3MgcmVjZW50IG1lc3NhZ2VzLjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkEg bWVjaGFuaXNtIGZvciBsYWJlbGluZyB0aGUgbmF0dXJlIG9mIFNJUCBjYWxscywgd2l0aCAmbHQ7 ZHJhZnQtc2NodWx6cmlubmUtc2lwY29yZS1jYWxsaW5mby1zcGFtJmd0OyBhcyBhIGxpa2VseSBj YW5kaWRhdGUgZHJhZnQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KRml4aW5nIENvbnRlbnQtSUQgaW4gU0lQLCBhcyBkaXNj dXNzZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9z aXBjb3JlL2N1cnJlbnQvbXNnMDcyNDUuaHRtbCI+DQombHQ7aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDcyNDUuaHRtbCZndDs8L2E+LCB3 aXRoICZsdDtkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLWNvbnRlbnQtaWQmZ3Q7IGFzIGEgbGlrZWx5 IGNhbmRpZGF0ZSBkcmFmdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpDbGFyaWZpY2F0aW9ucyBhcm91bmQgU0lQIG5hbWUt YWRkciwgd2l0aCAmbHQ7ZHJhZnQtc3BhcmtzLXNpcGNvcmUtbmFtZS1hZGRyLWd1aWRhbmNlJmd0 OyBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQ8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCkkgd2lsbCBhbHNvIG5vdGUgdGhhdCB3ZSBoYXZlIGFscmVh ZHkgZGVjbGFyZWQgY29uc2Vuc3VzIG9uIGFkb3B0aW5nICZsdDtkcmFmdC1pZXRmLXNpcGNvcmUt c3RhdHVzLXVud2FudGVkJmd0OyBhcyBhIFdHIGRvY3VtZW50LCBhbmQgd2lsbCBiZSBhZGRpbmcg YW4gYXNzb2NpYXRlZCBtaWxlc3RvbmUuIEkgd2FudCB0byB0YWtlIHRoaXMgb3Bwb3J0dW5pdHkg dG8gcmVtaW5kIHBlb3BsZSB0aGF0IHRoZSBkb2N1bWVudCBpcyBpbiBXR0xDLCBhbmQgeW91ciBj b21tZW50cw0KIGFyZSBzdHJvbmdseSBlbmNvdXJhZ2VkLCB0aGUgZWFybGllciB0aGUgYmV0dGVy Ljxicj4NCjxicj4NClBsZWFzZSByZXNwb25kIGJlZm9yZSB0aGUgZW5kIG9mIDIwMTYuIFRoYW5r cyE8YnI+DQo8YnI+DQpUaGFua3MhPGJyPg0KPGJyPg0KL2E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN2PR03MB23505D69C200C8D7B533CBF2B2930SN2PR03MB2350namp_-- From nobody Wed Dec 21 06:29:19 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D083129696 for ; Wed, 21 Dec 2016 06:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 tGVRb45bEvXG for ; Wed, 21 Dec 2016 06:29:15 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34001129684 for ; Wed, 21 Dec 2016 06:29:14 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id BE36958458AD4; Wed, 21 Dec 2016 14:29:09 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBLETBcL004505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2016 14:29:12 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uBLESNeY032236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Dec 2016 14:29:10 GMT Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.138]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 21 Dec 2016 15:29:03 +0100 From: "Drage, Keith (Nokia - GB)" To: Adam Roach , "'SIPCORE'" Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv98CYTifSRHzUuxd/Cssc4ijKERrGEg Date: Wed, 21 Dec 2016 14:29:02 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFCE0CC@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADFCE0CCFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: Ben Campbell Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 14:29:17 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADFCE0CCFR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 NCBhbmQgNSBhcmUgZXJyb3IgZml4aW5nLCBzbyB3ZSBzaG91bGQgcHJvYmFibHkgZG8gdGhlbSBh bnl3YXksIG5vIG1hdHRlciB3aGF0IHRoZSBwcmlvcml0eS4NCg0KT2YgbmV3IHdvcmsgMyBoYXMg aGlnaGVzdCBwcmlvcml0eSBpbiBteSBtaW5kLg0KDQpZb3VyIG1lc3NhZ2UgcmF0aGVyIHNlZW1z IHRvIGltcGx5IHdlIGRvIHRoZW0gYWxsIGFuZCB3ZSBhcmUganVzdCBzb3J0aW5nIG91dCB0aGUg c2VxdWVuY2UsIGFzIHRoZXJlIGlzIG5vIGluZGljYXRpb24gcmVxdWlyZWQgdGhhdCBwZW9wbGUg Y29uc2lkZXIgd2UgYWN0dWFsbHkgbmVlZCB0aGUgd29yayAodGhhdCBpcyBhIGRpZmZlcmVudCBx dWVzdGlvbiBmcm9tIGFjdGl2ZWx5IHJldmlldyBhbmQgY29tbWVudCkuDQoNCg0KS2VpdGgNCg0K RnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEFkYW0gUm9hY2gNClNlbnQ6IDIwIERlY2VtYmVyIDIwMTYgMjA6MjcNClRvOiAnU0lQQ09S RScgPHNpcGNvcmVAaWV0Zi5vcmc+DQpDYzogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+ DQpTdWJqZWN0OiBbc2lwY29yZV0gUkVTUE9OU0UgUkVRVUVTVEVEOiBTSVBDT1JFIHdvcmsgYW5k IG1pbGVzdG9uZXMNCg0KW2FzIGNoYWlyXQ0KDQpOb3cgdGhhdCB3ZSBoYXZlIG91ciBuZXcgY2hh cnRlciBhcHByb3ZlZCwgSSdkIGxpa2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gaGF2ZSBhIGRpc2N1 c3Npb24gYWJvdXQgdGhlIHNwZWNpZmljIHdvcmsgaXRlbXMgdGhhdCB3ZSBzaG91bGQgdGFrZSBv biBpbiB0aGUgc2hvcnQtIHRvIG1lZGl1bS10ZXJtIHNvIHRoYXQgd2UgY2FuIHJldmlzZSBvdXIg bWlsZXN0b25lcyBhcHByb3ByaWF0ZWx5LiBCYXNlZCBvbiByZWNlbnQgZGlzY3Vzc2lvbnMgb24g dGhlIG1haWxpbmcgbGlzdCwgdGhlIGZvbGxvd2luZyB0b3BpY3MgaGF2ZSBzb21lIG1pbmQtc2hh cmUgYmVoaW5kIHRoZW0uIFdoYXQgSSdkIGxpa2UgZnJvbSBldmVyeW9uZSB3aXRoIGFuIGludGVy ZXN0IGluIGFueSBvZiB0aGVzZSB0b3BpY3MgaXMgdG8gaW5kaWNhdGUgKGEpIHdoZXRoZXIgeW91 IGFyZSB3aWxsaW5nIHRvIGFjdGl2ZWx5IHJldmlldyBhbmQgY29tbWVudCBvbiBkb2N1bWVudHMg b24gdGhlIHRvcGljOyBhbmQgKGIpIHdoYXQgcHJpb3JpdHkgZWFjaCB0YXNrIGhhcyByZWxhdGl2 ZSB0byBlYWNoIG90aGVyOiB0aGVyZSBhcmUgZml2ZSB0b3BpY3M7IHBsZWFzZSBpbmRpY2F0ZSBh IHVuaXF1ZSBwcmlvcml0eSBmcm9tIG9uZSAobW9zdCBpbXBvcnRhbnQpIHRvIGZpdmUgKGxlYXN0 IGltcG9ydGFudCkgZm9yIGVhY2ggdG9waWMuDQoNCiAgMS4gICJIYXBweSBFeWViYWxscyBmb3Ig U0lQIiAoYWthIEhhcHB5IEVhcmJhbGxzKSwgY3VycmVudGx5IHVuZGVyIGRpc2N1c3Npb24gb24g dGhlIGxpc3QuDQogIDIuICAiRFRMUyBUcmFuc3BvcnQgZm9yIFNJUCIsIGFzIHByb3Bvc2VkIGJ5 IFRvbGdhIEFzdmVyZW4ncyByZWNlbnQgbWVzc2FnZXMuDQogIDMuICBBIG1lY2hhbmlzbSBmb3Ig bGFiZWxpbmcgdGhlIG5hdHVyZSBvZiBTSVAgY2FsbHMsIHdpdGggPGRyYWZ0LXNjaHVsenJpbm5l LXNpcGNvcmUtY2FsbGluZm8tc3BhbT4gYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0Lg0KICA0 LiAgRml4aW5nIENvbnRlbnQtSUQgaW4gU0lQLCBhcyBkaXNjdXNzZWQgaW4gPGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzA3MjQ1Lmh0bWw+ PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21z ZzA3MjQ1Lmh0bWw+LCB3aXRoIDxkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLWNvbnRlbnQtaWQ+IGFz IGEgbGlrZWx5IGNhbmRpZGF0ZSBkcmFmdC4NCiAgNS4gIENsYXJpZmljYXRpb25zIGFyb3VuZCBT SVAgbmFtZS1hZGRyLCB3aXRoIDxkcmFmdC1zcGFya3Mtc2lwY29yZS1uYW1lLWFkZHItZ3VpZGFu Y2U+IGFzIGEgbGlrZWx5IGNhbmRpZGF0ZSBkcmFmdA0KDQpJIHdpbGwgYWxzbyBub3RlIHRoYXQg d2UgaGF2ZSBhbHJlYWR5IGRlY2xhcmVkIGNvbnNlbnN1cyBvbiBhZG9wdGluZyA8ZHJhZnQtaWV0 Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZD4gYXMgYSBXRyBkb2N1bWVudCwgYW5kIHdpbGwgYmUg YWRkaW5nIGFuIGFzc29jaWF0ZWQgbWlsZXN0b25lLiBJIHdhbnQgdG8gdGFrZSB0aGlzIG9wcG9y dHVuaXR5IHRvIHJlbWluZCBwZW9wbGUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgaW4gV0dMQywgYW5k IHlvdXIgY29tbWVudHMgYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQsIHRoZSBlYXJsaWVyIHRoZSBi ZXR0ZXIuDQoNClBsZWFzZSByZXNwb25kIGJlZm9yZSB0aGUgZW5kIG9mIDIwMTYuIFRoYW5rcyEN Cg0KVGhhbmtzIQ0KDQovYQ0K --_000_949EF20990823C4C85C18D59AA11AD8BADFCE0CCFR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjE2MDM5NDkxNTQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xODM1MzU5NzMwO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1H QiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj40IGFuZCA1IGFyZSBlcnJv ciBmaXhpbmcsIHNvIHdlIHNob3VsZCBwcm9iYWJseSBkbyB0aGVtIGFueXdheSwgbm8gbWF0dGVy IHdoYXQgdGhlIHByaW9yaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5PZiBuZXcgd29yayAzIGhhcyBoaWdo ZXN0IHByaW9yaXR5IGluIG15IG1pbmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPllvdXIgbWVzc2FnZSByYXRo ZXIgc2VlbXMgdG8gaW1wbHkgd2UgZG8gdGhlbSBhbGwgYW5kIHdlIGFyZSBqdXN0IHNvcnRpbmcg b3V0IHRoZSBzZXF1ZW5jZSwgYXMgdGhlcmUgaXMgbm8gaW5kaWNhdGlvbg0KIHJlcXVpcmVkIHRo YXQgcGVvcGxlIGNvbnNpZGVyIHdlIGFjdHVhbGx5IG5lZWQgdGhlIHdvcmsgKHRoYXQgaXMgYSBk aWZmZXJlbnQgcXVlc3Rpb24gZnJvbSBhY3RpdmVseSByZXZpZXcgYW5kIGNvbW1lbnQpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPktlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij4gc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+QWRhbSBSb2FjaDxicj4NCjxiPlNlbnQ6PC9iPiAyMCBEZWNlbWJlciAyMDE2IDIw OjI3PGJyPg0KPGI+VG86PC9iPiAnU0lQQ09SRScgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBCZW4gQ2FtcGJlbGwgJmx0O2JlbkBub3N0cnVtLmNvbSZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW3NpcGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3b3Jr IGFuZCBtaWxlc3RvbmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5bYXMgY2hhaXJdPGJyPg0KPGJyPg0K Tm93IHRoYXQgd2UgaGF2ZSBvdXIgbmV3IGNoYXJ0ZXIgYXBwcm92ZWQsIEknZCBsaWtlIHRoZSB3 b3JraW5nIGdyb3VwIHRvIGhhdmUgYSBkaXNjdXNzaW9uIGFib3V0IHRoZSBzcGVjaWZpYyB3b3Jr IGl0ZW1zIHRoYXQgd2Ugc2hvdWxkIHRha2Ugb24gaW4gdGhlIHNob3J0LSB0byBtZWRpdW0tdGVy bSBzbyB0aGF0IHdlIGNhbiByZXZpc2Ugb3VyIG1pbGVzdG9uZXMgYXBwcm9wcmlhdGVseS4gQmFz ZWQgb24gcmVjZW50IGRpc2N1c3Npb25zIG9uIHRoZQ0KIG1haWxpbmcgbGlzdCwgdGhlIGZvbGxv d2luZyB0b3BpY3MgaGF2ZSBzb21lIG1pbmQtc2hhcmUgYmVoaW5kIHRoZW0uIFdoYXQgSSdkIGxp a2UgZnJvbSBldmVyeW9uZSB3aXRoIGFuIGludGVyZXN0IGluIGFueSBvZiB0aGVzZSB0b3BpY3Mg aXMgdG8gaW5kaWNhdGUgKGEpIHdoZXRoZXIgeW91IGFyZSB3aWxsaW5nIHRvIGFjdGl2ZWx5IHJl dmlldyBhbmQgY29tbWVudCBvbiBkb2N1bWVudHMgb24gdGhlIHRvcGljOyBhbmQgKGIpIHdoYXQg cHJpb3JpdHkNCiBlYWNoIHRhc2sgaGFzIHJlbGF0aXZlIHRvIGVhY2ggb3RoZXI6IHRoZXJlIGFy ZSBmaXZlIHRvcGljczsgcGxlYXNlIGluZGljYXRlIGEgdW5pcXVlIHByaW9yaXR5IGZyb20gb25l IChtb3N0IGltcG9ydGFudCkgdG8gZml2ZSAobGVhc3QgaW1wb3J0YW50KSBmb3IgZWFjaCB0b3Bp Yy48bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCiZxdW90O0hhcHB5IEV5ZWJhbGxz IGZvciBTSVAmcXVvdDsgKGFrYSBIYXBweSBFYXJiYWxscyksIGN1cnJlbnRseSB1bmRlciBkaXNj dXNzaW9uIG9uIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCiZxdW90O0RUTFMgVHJhbnNwb3J0IGZvciBTSVAm cXVvdDssIGFzIHByb3Bvc2VkIGJ5IFRvbGdhIEFzdmVyZW4ncyByZWNlbnQgbWVzc2FnZXMuPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KQSBtZWNoYW5pc20gZm9yIGxhYmVsaW5nIHRoZSBuYXR1cmUgb2YgU0lQIGNhbGxzLCB3 aXRoICZsdDtkcmFmdC1zY2h1bHpyaW5uZS1zaXBjb3JlLWNhbGxpbmZvLXNwYW0mZ3Q7IGFzIGEg bGlrZWx5IGNhbmRpZGF0ZSBkcmFmdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpGaXhpbmcgQ29udGVudC1JRCBpbiBTSVAs IGFzIGRpc2N1c3NlZCBpbiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNzI0NS5odG1sIj4NCiZsdDtodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNzI0NS5odG1sJmd0 OzwvYT4sIHdpdGggJmx0O2RyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtY29udGVudC1pZCZndDsgYXMg YSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkNsYXJpZmljYXRpb25zIGFyb3VuZCBT SVAgbmFtZS1hZGRyLCB3aXRoICZsdDtkcmFmdC1zcGFya3Mtc2lwY29yZS1uYW1lLWFkZHItZ3Vp ZGFuY2UmZ3Q7IGFzIGEgbGlrZWx5IGNhbmRpZGF0ZSBkcmFmdDxvOnA+PC9vOnA+PC9saT48L29s Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSB3aWxsIGFsc28gbm90ZSB0aGF0IHdlIGhh dmUgYWxyZWFkeSBkZWNsYXJlZCBjb25zZW5zdXMgb24gYWRvcHRpbmcgJmx0O2RyYWZ0LWlldGYt c2lwY29yZS1zdGF0dXMtdW53YW50ZWQmZ3Q7IGFzIGEgV0cgZG9jdW1lbnQsIGFuZCB3aWxsIGJl IGFkZGluZyBhbiBhc3NvY2lhdGVkIG1pbGVzdG9uZS4gSSB3YW50IHRvIHRha2UgdGhpcyBvcHBv cnR1bml0eSB0byByZW1pbmQgcGVvcGxlIHRoYXQgdGhlIGRvY3VtZW50IGlzIGluIFdHTEMsIGFu ZCB5b3VyIGNvbW1lbnRzDQogYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQsIHRoZSBlYXJsaWVyIHRo ZSBiZXR0ZXIuPGJyPg0KPGJyPg0KUGxlYXNlIHJlc3BvbmQgYmVmb3JlIHRoZSBlbmQgb2YgMjAx Ni4gVGhhbmtzITxicj4NCjxicj4NClRoYW5rcyE8YnI+DQo8YnI+DQovYTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_949EF20990823C4C85C18D59AA11AD8BADFCE0CCFR712WXCHMBA11z_-- From nobody Wed Dec 21 07:23:46 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AD01296E9 for ; Wed, 21 Dec 2016 07:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gN2jr40F7K02 for ; Wed, 21 Dec 2016 07:23:43 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF151296E3 for ; Wed, 21 Dec 2016 07:23:43 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id 15so25271033iom.2 for ; Wed, 21 Dec 2016 07:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XEBJh2vN7nSz0D3XjxbCuiFW2/nsKF5VFEwakw7tHck=; b=tFR9FBzC5CiNCZVREKJVMrh/I8Z8XHJbsm2XicYdbDHRuEf0uV06Wv+56QQrdykMJl A03FSeJNzQ4YliDIxijUnF0AWf3QhtreI12ZIxhHCS3NxNmtelvt1UXKlrDWiJ6PTp26 RkiwdaU9/Ad1965JBiJvvTDFwYUKnKZBgE2F5RtF2mFGtW1UnnQ9bxK3fFcX60y0SWl3 6Y/4Iz/Li1dUGQko0au4FZqfEySano1OK+8wAmreb2Ee94vsp+WmjA9XmiQUZS4WZHYs bb4SIWXiTeq+UvyOiiwfzWIAq6c7UEVJPyFODgpxHj+e88jf2q0ngNtWAPAmJtWIPk0+ X57g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XEBJh2vN7nSz0D3XjxbCuiFW2/nsKF5VFEwakw7tHck=; b=s8XnrKRMwKHQbGqwAMPtVUpSztS6cHn8yZs8hXG8eMaUT60Zs4pUo1GUxO4CggYZdN nDqtm1F0wcAt3cdG8+FrmiyOkL/reKMsmRQZONeDp90EhwCxrqfds4lBryjDMduCGUK5 Ljil5fF01g2lxfphQSdIYAHveG8bAO6IlIYjMfCXaw6lVqnFgCwzxP5D5Q7ysfYQJTNN rHBvW72JO5lWDfmJRkRBYT7cmswCE5e6fo4aHQIU+tRwdQ2d+QvM9jzJP/UNU4HFXsOu 1SgwrUivVMgxSxzyUOg6VrpAnkjte7HOc+JVX0rX4PXJ1Nv6FCBOEWtSp58qfoi1X5Zn YAEQ== X-Gm-Message-State: AIkVDXLMc/TMBOrjbpyKjz0p7z8loDMxLDmw7HQIeas/d82PMbIiNXahn7HffYYbbC6u+hiRul2LeJIYsDqzFA== X-Received: by 10.107.34.207 with SMTP id i198mr5541572ioi.16.1482333822403; Wed, 21 Dec 2016 07:23:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.1.199 with HTTP; Wed, 21 Dec 2016 07:23:41 -0800 (PST) In-Reply-To: References: From: Andy Hutton Date: Wed, 21 Dec 2016 15:23:41 +0000 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a11403e24ec55e805442cbcba Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 15:23:44 -0000 --001a11403e24ec55e805442cbcba Content-Type: text/plain; charset=UTF-8 Minor WGLC comment. The abstract states "The terminating SIP entity may use this information....". But this is not I believe referring to the actual terminating SIP entity which is the called users device but is referring to some preceding SIP entity probably the service provider. Regards Andy On Mon, Dec 12, 2016 at 9:05 PM, Adam Roach wrote: > [as chair] > > I've seen significant support for adoption of > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and no > objections. Our revised charter that includes scope for this kind of item > has been approved. The document is now adopted by SIPCORE. I have asked the > author to submit subsequent versions of the document as > draft-ietf-sipcore-status-unwanted. > > Given the relatively uncomplicated mechanism being described and the > requests for expedited processing, we will be starting our working group > last call on the document today. In recognition that the upcoming winter > holidays will take some portion of many participants' attention, and that > many people will observe a New Year's Holiday on January 2nd, we will run > this last call for three weeks, ending on January 3rd. Please review the > document and provide comments on before that date. > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11403e24ec55e805442cbcba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Minor WGLC comment.

The abstract states= "The=C2=A0terminating SIP entit= y may use this information....".

But this is not I believe referring= to the actual terminating SIP entity which is the called users device but = is referring to some preceding SIP entity probably the service provider.

Regards
Andy=C2=A0




<= div class=3D"gmail_extra">
On Mon, Dec 12, 20= 16 at 9:05 PM, Adam Roach <adam@nostrum.com> wrote:
[as chair]

I've seen significant support for adoption of draft-schulzrinne-dispatc= h-status-unwanted as a SIPCORE item and no objections. Our revised cha= rter that includes scope for this kind of item has been approved. The docum= ent is now adopted by SIPCORE. I have asked the author to submit subsequent= versions of the document as draft-ietf-sipcore-status-unwanted.

Given the relatively uncomplicated mechanism being described and the reques= ts for expedited processing, we will be starting our working group last cal= l on the document today. In recognition that the upcoming winter holidays w= ill take some portion of many participants' attention, and that many pe= ople will observe a New Year's Holiday on January 2nd, we will run this= last call for three weeks, ending on January 3rd. Please review the docume= nt and provide comments on before that date.

/a

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

--001a11403e24ec55e805442cbcba-- From nobody Wed Dec 21 12:36:36 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114651295FB for ; Wed, 21 Dec 2016 12:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 2hM_cYL_jpqi for ; Wed, 21 Dec 2016 12:36:34 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D211295C5 for ; Wed, 21 Dec 2016 12:36:33 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-10v.sys.comcast.net with SMTP id Jnc9cUaZGrC25Jncnck1Zy; Wed, 21 Dec 2016 20:36:33 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-05v.sys.comcast.net with SMTP id JnclcsaOxHWnFJncmc2uR7; Wed, 21 Dec 2016 20:36:33 +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 uBLKZVGR012063; Wed, 21 Dec 2016 15:35:31 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBLKZUtC012060; Wed, 21 Dec 2016 15:35:30 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-Reply-To: (adam@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Dec 2016 15:35:30 -0500 Message-ID: <87wpetvx4d.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBCP4bTAbGiVApthq4pgyTuG7ocF//IntiUMlSUIQr2n+d/ZrJnIYAFh0qFuCb1ZGAMxZAx2vy2Cp0BCng2JvSwGE1exrfYoM0zzO0V3wFi2Xpxe9Rky QKqelQ5Qq1RyczgfEJuMrdIblfsPjZ2uklB25NIY0aADiSPwcGqpPDdhuX+ZCsAxJ1UCNOJOTNOLlxbNsAViHCLnqNNPyyXpOYaH6rVDnOLdk/q6+2cGN63F Archived-At: Cc: ben@nostrum.com, sipcore@ietf.org Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 20:36:35 -0000 Adam Roach writes: > 4. Fixing Content-ID in SIP, as discussed in > , > with as a likely candidate draft. > 5. Clarifications around SIP name-addr, with > as a likely candidate draft These two are essentially bug fixes, and it seems that we are already in need of their results. Also, the amount of additional work to complete them is small. So they appear to be the highest-priority items. > 1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently under > discussion on the list. I'm involved in working on this, so I think it's useful. Generally, its usefulness hinges on how many SIP systems are both (1) dual-stack and (2) use general RFC 3263 mechanisms to find servers (i.e., aren't in heavily configured environments). But if we want to support SIP over the general Internet in the future, we'll need this. > 2. "DTLS Transport for SIP", as proposed by Tolga Asveren's recent > messages. I think this is a good idea, as it solves a problem that Roman Shpount and Tolga Asveren have both mentioned as important. Do other people who work with large-scale servers feel a need for DTLS or DTLS-like signaling transport? > 3. A mechanism for labeling the nature of SIP calls, with > as a likely candidate draft. Certainly spam calls are a problem in reality. Do people consider this a way to help suppress them in practice? Dale From nobody Wed Dec 21 13:02:40 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E181295C9 for ; Wed, 21 Dec 2016 13:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 9Fc19KcuxQjP for ; Wed, 21 Dec 2016 13:02:37 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4CF1295EE for ; Wed, 21 Dec 2016 13:02:36 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBLKxjRg030114; Wed, 21 Dec 2016 21:02:32 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0054.outbound.protection.outlook.com [23.103.198.54]) by mx0b-0024ed01.pphosted.com with ESMTP id 27eqm11a2u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 21 Dec 2016 21:02:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wlw2+9OZjmmlbnI+P4mlUu85qXI5Y2ZENGmouUeTaIo=; b=DO3GeMsyVuQltEUZ3X2IWD1HQAAxjh6XuO+nR41b0uIrkJj/OzaVTX/k+DWv/qW8IjwJwfpiRqMQKJ5+sRmmSYet/GaXcNv/i+FIUJuAh99kOgP+qcdWthK00tp2J8P6KtJKp6wwDzgvX989xOAfFJrFhoOcqtnipnvpgTgB+rg= Received: from BY1PR09MB0631.namprd09.prod.outlook.com (10.160.110.19) by BY1PR09MB0629.namprd09.prod.outlook.com (10.160.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Wed, 21 Dec 2016 21:02:31 +0000 Received: from BY1PR09MB0631.namprd09.prod.outlook.com ([10.160.110.19]) by BY1PR09MB0631.namprd09.prod.outlook.com ([10.160.110.19]) with mapi id 15.01.0771.020; Wed, 21 Dec 2016 21:02:31 +0000 From: Henning Schulzrinne To: "Dale R. Worley" Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSW8nFlk3q3jJYdky4HQOpr+Xx5KES3t0g Date: Wed, 21 Dec 2016 21:02:30 +0000 Message-ID: References: (adam@nostrum.com) <87wpetvx4d.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wpetvx4d.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 4b6c410d-020d-429a-2bee-08d429e4add7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY1PR09MB0629; x-microsoft-exchange-diagnostics: 1; BY1PR09MB0629; 7:Uw9UDCSo6r4JF0KrvVfJHCQ7hOgU1L7EnIQbYWj4G+Qiu8wygW0L4uFeZa2dN6K5eEIBN8MHDC0doFpJgyp9au5vjSCjQEci91knKdP2m7r4ACfSCWXDy8ELk363lFjNL35aJJoV+Uajo8X3bX12GznR/VC2yzzzS60IueF9IgSVav4Z36TgyjiSiSxKUiaNTD1KYI0YYiWzP0TwMz9C9uAJdLI9qn+hg/Jfcav/T8in+eds2uQ1oUuDH2xCm7/bnurNX+NxoAN2DOupwM0PzZEv2xElPLJ8qEZ3vL6b2iA/XhKLZt9wVYbU/wV+8yNf78OuPkVD2bEOqc1yzTskIQJ5dzKQwOwVlbdPdqVU3/35XtP4VO+WJyMF1yrF8/LrTOWgjE4o7S3M7Fo66Iv8abyE3uhp4+YxeQY6c6XknU3W2eY5wAoswmUzRfx38fefGRo175QKEPcoR/KXS2oqrw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:BY1PR09MB0629; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0629; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(189002)(13464003)(6916009)(66066001)(229853002)(92566002)(106116001)(3280700002)(76576001)(8676002)(8936002)(3660700001)(2950100002)(77096006)(6506006)(2900100001)(110136003)(33656002)(5660300001)(6436002)(74316002)(50986999)(81166006)(54356999)(76176999)(81156014)(101416001)(97736004)(7696004)(105586002)(305945005)(31430400001)(189998001)(106356001)(9686002)(99286002)(68736007)(102836003)(3846002)(6116002)(2906002)(122556002)(4326007)(86362001)(7736002)(25786008)(38730400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0629; H:BY1PR09MB0631.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2016 21:02:30.9172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0629 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-21_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 21:02:39 -0000 A bit of background below. The two drafts are part of a broader suite of tools, and probably among the= lower-importance ones compared to, in particular, the STIR caller ID authe= ntication work. I think there is some consensus that a complete robocall pr= evention eco system consists of a number of components: (1) A way to validate caller ID, to prevent spoofing and to facilitate trac= king and suitable law enforcement. (Spoofing makes the other parts hard or = fail.) Law enforcement, besides putting a few spammers behind bars, changes= the risk/reward calculus and thus discourages copy cats. (2) With authenticated caller ID, various block/black lists can work, decre= asing the reach of spammers and thus again weakening their business model. (3) Given the challenges of not being able to do content analysis easily (o= r look at the history of domain names or senders), human feedback is import= ant to populate the blacklists. Also, as for email, there's a significant g= ray zone of calls in between the clearly-wanted (calls from your spouse, on= e would hope) and the outright-criminal fraud. The "unwanted" draft allows = for standards-based feedback by humans to make both automated blocking, for= groups of customers and the individual, and enforcement work better. (4) Given the gray area and the general desire not to interfere with commun= ications, for both customer-focused and, in some countries, legal reasons, = some calls are best flagged and labeled rather than rejected, so that end s= ystems or humans can make more nuanced decisions. Examples often cited incl= ude calls from charities, politicians and survey organizations, but also au= tomated calls for prescription pickup, school snow days or outstanding debt= s. The 'callinfo' draft addresses this particular need. Both drafts are outgrowths of the Robocall Strike Force (https://www.fcc.go= v/news-events/events/2016/10/second-meeting-industry-led-robocall-strike-fo= rce) and were identified as standards gaps by the participants. Thus, the drafts are unlikely, by themselves, to solve the robocall problem= , but hopefully they'll help in a small way. Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > 3. A mechanism for labeling the nature of SIP calls, with > as a likely candidate draft= . Certainly spam calls are a problem in reality. Do people consider this a w= ay to help suppress them in practice? Dale =20 From nobody Wed Dec 21 13:37:36 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4311295EA for ; Wed, 21 Dec 2016 13:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 8xnq470ydD1j for ; Wed, 21 Dec 2016 13:37:33 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B1B1294B6 for ; Wed, 21 Dec 2016 13:37:33 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-09v.sys.comcast.net with SMTP id JoZXcXT1H5lLvJoZocbut8; Wed, 21 Dec 2016 21:37:32 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-04v.sys.comcast.net with SMTP id JoZncqYJxjWbHJoZocpZDN; Wed, 21 Dec 2016 21:37:32 +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 uBLLaUDd018578 for ; Wed, 21 Dec 2016 16:36:30 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBLLaUWV018571; Wed, 21 Dec 2016 16:36:30 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Dec 2016 16:36:30 -0500 Message-ID: <87tw9xvuap.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMwvmC8FeKiyf8CQ8oAxIk8pyeWt27GLQaNSO3QyUhvqSnUxsd2QW5YbWwAH6mm9xo0vhoZsWpjtXv7TU1XvTfDWfcpsSWNb8cd9YSEoN7k0/CWbKSo8 sHg2ZTJd2+lHVZT6efodwj1WipxkKsy85l03cl2qGDFA0SSzKJvxP0Zz Archived-At: Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 21:37:34 -0000 All of these comments are editorial. 1. Introduction The called party or a automata acting on her behalf uses this to indicate that future calls from the same caller are also unwanted. s/a automata/an automaton/ 4. Behavior of SIP Entities The response code MAY also be used in Reason header fields [RFC3326], typically when the UAS issues a BYE request terminating an incoming call. This doesn't fully explain the intended behaviors. Better would be a description like: The response code 666 MAY be used in a failure response for an INVITE, MESSAGE, or other request to indicate that the offered communication is unwanted. The response code MAY also be used as the value of the "cause" parameter of a "SIP" reason-value in a "Reason" header field [RFC3326] in a BYE request terminating an incoming call that is unwanted. -- The service provider delivering calls to the user issuing the response may, for example, add the calling party to a personal blacklist specific to the called party, or may use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), might initiate a traceback request, or could report the calling number to government authorities. This list has 4 items: may, for example, add the calling party to a personal blacklist specific to the called party, or may use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), might initiate a traceback request, or could report the calling number to government authorities. There is a lack of parallelism in that clauses use "may", "might", and "could" to indicate possbility. There are two uses of "or". The first item contains commas, but the items are not separated by semicolons. Reformulating this by (1) consistently using MAY, (2) using one "or" before the last item, and (3) moving the "for example" to before the list (thus escaping the rule regarding semicolons): The service provider delivering calls to the user issuing the response, for example, MAY add the calling party to a personal blacklist specific to the called party, MAY use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), MAY initiate a traceback request, or MAY report the calling number to government authorities. -- The same user interface action might also trigger addition of the number to a local, on-device blacklist or graylist, e.g., causing such calls to be flagged or alert with a different ring tone. This construction parallels "to be flagged" with "alert with a different ring tone". Probably s/alert/alerted/ so that the parallelism is "to be (flagged | alerted with a different ring tone)". -- We define a SIP feature-capability [RFC6809], sip.666, that allows the registrar to indicate that it supports this particular response code. Except that the registrar doesn't support the response code, really. It's the proxy that does lookups in the location service that the registrar maintains. So perhaps: We define a SIP feature-capability [RFC6809], sip.666, that allows the registrar to indicate that the corresponding proxy supports this particular response code. 6. Security Considerations Thus, any additions to a personal list of blocked numbers should be observable by the subscriber, e.g., on a web page or by regular email notification, and reservible. s/reservible/reversible/ The meaning of "the subscriber" is unclear. Is it "the recipient" or "the caller"? Dale From nobody Wed Dec 21 14:59:06 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCB6129627 for ; Wed, 21 Dec 2016 14:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 AyjpUHm2iv35 for ; Wed, 21 Dec 2016 14:59:01 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 3EAF012957F for ; Wed, 21 Dec 2016 14:59:01 -0800 (PST) Received: (qmail 26505 invoked by uid 0); 21 Dec 2016 22:58:58 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 21 Dec 2016 22:58:58 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id Nmtt1u00d1MNPNq01mtwkE; Wed, 21 Dec 2016 15:53:57 -0700 X-Authority-Analysis: v=2.1 cv=KYpB72oD c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=n5n_aSjo0skA:10 a=ZZnuYtJkoWoA:10 a=HeG67adPAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=doUQZJtgAAAA:8 a=5lGD27SC0sDLZxo0-tUA:9 a=wA55TZdhR5IdxoL8:21 a=jA4sHR-V-Voau2OR:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=jlXKPczUY4Vio7-9iMRd:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=d0-0EwFVFT64L02gzcZV:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=v/K7TDxQXA0UpviUwiWczDfXnb/T6nXqiUXFb6XUuBU=; b=oaBAN/DBR5iJ4l+SaRwrCB9iEc cOafKcf4Pnaz261DwdN+Z8Bs4eaAnDkQog2rl3wQczOMO/HB2iYURda17FSEd/tAM+GN/VN7ktKsf 0l/UVhVR4sAE48yVIIYthoDRt; Received: from pool-100-36-44-71.washdc.fios.verizon.net ([100.36.44.71]:59351 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1cJplj-0007Wa-6P; Wed, 21 Dec 2016 15:53:55 -0700 User-Agent: Microsoft-MacOutlook/f.1d.0.161209 Date: Wed, 21 Dec 2016 17:53:53 -0500 From: Richard Shockey To: Henning Schulzrinne , "Dale R. Worley" Message-ID: <02CEEA1E-B5CB-4F16-A098-C524A1071AF0@shockey.us> Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones References: <87wpetvx4d.fsf@hobgoblin.ariadne.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.71 X-Exim-ID: 1cJplj-0007Wa-6P X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-71.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.71]:59351 X-Source-Auth: richard+shockey.us X-Email-Count: 3 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 22:59:04 -0000 +1 =20 =E2=80=9CThere is no Silver Bullet=E2=80=9D Henning is right. These drafts are part of a whole suite of initiatives go= ing on at multiple levels among multiple SDO=E2=80=99s. It should also be pointed out that these initiatives are being supported by= multiple National Regulatory Authorities. =20 I might point out my presentation to NICC in the UK recently and the presen= tation by Huw Saunders the Director of Network Infrastructure for OFCOM the = UK telecom regulator. =20 http://www.niccstandards.org.uk/meetings/forum-2016.cfm This is going to get deployed. The SIP Forum along with ATIS are working o= n the STIR/ SHAKEN implementation profiles as we speak.=20 I will say something else. The pending change in US Administration IMHO wil= l not affect these initiatives in any way shape or form. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 On 12/21/16, 4:02 PM, "sipcore on behalf of Henning Schulzrinne" wrote: A bit of background below. =20 The two drafts are part of a broader suite of tools, and probably among= the lower-importance ones compared to, in particular, the STIR caller ID au= thentication work. I think there is some consensus that a complete robocall = prevention eco system consists of a number of components: =20 (1) A way to validate caller ID, to prevent spoofing and to facilitate = tracking and suitable law enforcement. (Spoofing makes the other parts hard = or fail.) Law enforcement, besides putting a few spammers behind bars, chang= es the risk/reward calculus and thus discourages copy cats. =20 (2) With authenticated caller ID, various block/black lists can work, d= ecreasing the reach of spammers and thus again weakening their business mode= l. =20 (3) Given the challenges of not being able to do content analysis easil= y (or look at the history of domain names or senders), human feedback is imp= ortant to populate the blacklists. Also, as for email, there's a significant= gray zone of calls in between the clearly-wanted (calls from your spouse, o= ne would hope) and the outright-criminal fraud. The "unwanted" draft allows = for standards-based feedback by humans to make both automated blocking, for = groups of customers and the individual, and enforcement work better. =20 (4) Given the gray area and the general desire not to interfere with co= mmunications, for both customer-focused and, in some countries, legal reason= s, some calls are best flagged and labeled rather than rejected, so that end= systems or humans can make more nuanced decisions. Examples often cited inc= lude calls from charities, politicians and survey organizations, but also au= tomated calls for prescription pickup, school snow days or outstanding debts= . The 'callinfo' draft addresses this particular need. =20 Both drafts are outgrowths of the Robocall Strike Force (https://www.fc= c.gov/news-events/events/2016/10/second-meeting-industry-led-robocall-strike= -force) and were identified as standards gaps by the participants. =20 Thus, the drafts are unlikely, by themselves, to solve the robocall pro= blem, but hopefully they'll help in a small way. =20 Henning =20 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Wo= rley Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones =20 > 3. A mechanism for labeling the nature of SIP calls, with > as a likely candidate d= raft. =20 Certainly spam calls are a problem in reality. Do people consider this= a way to help suppress them in practice? =20 Dale =20 =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =20 From nobody Thu Dec 22 04:39:08 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C7C1295CE for ; Thu, 22 Dec 2016 04:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NoTJo0n84VMb for ; Thu, 22 Dec 2016 04:39:06 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E19129487 for ; Thu, 22 Dec 2016 04:39:06 -0800 (PST) X-AuditID: c1b4fb3a-854f998000005d1c-03-585bc968d85a Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id AD.98.23836.869CB585; Thu, 22 Dec 2016 13:39:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Thu, 22 Dec 2016 13:39:27 +0100 From: Christer Holmberg To: Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv94qVaIPJWYtkKphBDYR9rbSaET+4mA Date: Thu, 22 Dec 2016 12:39:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D48194CE14EEAchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2J7uG7GyegIg+cP9S32/F3EbjG/8zS7 xdcfm9gcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxnbacZC/bZVDTPyGtgnGrcxcjJ ISFgIjGlaw9rFyMXh5DAOkaJ5ombWUESQgJLGCUW7tTsYuTgYBOwkOj+pw0SFhGwl3j7dS1Y CbOAksS+7UfAbGEBN4lrk5rYQcpFBNwlpq7QgCg3klhx8Q1LFyM7B4uAqsQlf5Aor4C1xO+P R1gg9thJ7L09nRnE5gQavmjqZDCbUUBM4vupNUwQi8Qlbj2ZzwRxsIDEkj3nmSFsUYmXj/+x giwVFdCTWHM/DCKsKPHx1T5GiNYEidm/lzBDrBWUODnzCcsERtFZSKbOQlI2C0kZRNxA4v25 +cwQtrbEsoWvoWx9iY1fzjJC2NYS35a8ZUFWs4CRYxWjaHFqcXFuupGRXmpRZnJxcX6eXl5q ySZGYBQe3PLbagfjweeOhxgFOBiVeHg/zIiKEGJNLCuuzD3EKMHBrCTC2308OkKINyWxsiq1 KD++qDQntfgQozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGxhDHL+qeRZ/E18XckL/C FrDFRP3CI4nzlySvrllT/OvCxeOyEZxH+jMFE+fOWd42eXde3a3dH4zPvZ8p/Ht36I/uiboJ aqldt7wu3rnrb3d1XU5NmKDOsr/h5wNLLLvvP1k6/17GZLljXXfe38ye9vL3tMWMrQwGF0yC j5+emOj5v8ndb9rZK3uVWIozEg21mIuKEwFcPTSbvgIAAA== Archived-At: Cc: Ben Campbell Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 12:39:08 -0000 --_000_D48194CE14EEAchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I will obviously be actively involved in 4), and I also agree that 5) shoul= d be done as it is a correction. As far as the other potential work is concerned, 3) has the highest priorit= y for me, and I would actively participate in that work. I would review 1) and 2), but I would really like to see an individual draf= t on 2) before we agree whether to create a milestone for it. For example, = I would like to see some input on WHY to do it, and HOW it is intended to b= e deployed etc. How does DTLS fit SIP? What are the advantages? OR, do we w= ant to specify DTLS-for-SIP simply because DTLS is =93hot=94? Regards, Christer From: sipcore > o= n behalf of "adam@nostrum.com" > Date: Tuesday 20 December 2016 at 22:27 To: "sipcore@ietf.org" > Cc: Ben Campbell > Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones [as chair] Now that we have our new charter approved, I'd like the working group to ha= ve a discussion about the specific work items that we should take on in the= short- to medium-term so that we can revise our milestones appropriately. = Based on recent discussions on the mailing list, the following topics have = some mind-share behind them. What I'd like from everyone with an interest i= n any of these topics is to indicate (a) whether you are willing to activel= y review and comment on documents on the topic; and (b) what priority each = task has relative to each other: there are five topics; please indicate a u= nique priority from one (most important) to five (least important) for each= topic. 1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently under discus= sion on the list. 2. "DTLS Transport for SIP", as proposed by Tolga Asveren's recent messa= ges. 3. A mechanism for labeling the nature of SIP calls, with as a likely candidate draft. 4. Fixing Content-ID in SIP, as discussed in , with as a likely candidate draft. 5. Clarifications around SIP name-addr, with as a likely candidate draft I will also note that we have already declared consensus on adopting as a WG document, and will be adding an asso= ciated milestone. I want to take this opportunity to remind people that the= document is in WGLC, and your comments are strongly encouraged, the earlie= r the better. Please respond before the end of 2016. Thanks! Thanks! /a --_000_D48194CE14EEAchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <82DF2A12C67F66448B1C0F39C7CB1F16@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I will obviously be actively involved in 4), and I also agree that 5) = should be done as it is a correction.

As far as the other potential work is concerned, 3) has the highest pr= iority for me, and I would actively participate in that work.

I would review 1) and 2), but I would really like to see an individual= draft on 2) before we agree whether to create a milestone for it. For exam= ple, I would like to see some input on WHY to do it, and HOW it is intended= to be deployed etc. How does DTLS fit SIP? What are the advantages? OR, do we want to specify DTLS-for-SIP s= imply because DTLS is =93hot=94?

Regards,

Christer

From: sipcore <sipcore-bounces@ietf.org> on behalf of &q= uot;adam@nostrum.com" <adam@nostrum.com>
Date: Tuesday 20 December 2016 at 2= 2:27
To: "sipcore@ietf.org" <sipcore@ietf.org>
Cc: Ben Campbell <ben@nostrum.com>
Subject: [sipcore] RESPONSE REQUEST= ED: SIPCORE work and milestones

[as chair]

Now that we have our new charter approved, I'd like the working group to ha= ve a discussion about the specific work items that we should take on in the= short- to medium-term so that we can revise our milestones appropriately. = Based on recent discussions on the mailing list, the following topics have some mind-share behind them. What = I'd like from everyone with an interest in any of these topics is to indica= te (a) whether you are willing to actively review and comment on documents = on the topic; and (b) what priority each task has relative to each other: there are five topics; please indica= te a unique priority from one (most important) to five (least important) fo= r each topic.

  1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently unde= r discussion on the list.
  2. "DTLS Transport for SIP", as proposed by Tolga Asveren's= recent messages.
  3. A mechanism for labeling the nature of SIP calls= , with <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidat= e draft.
  4. Fixing Content-ID in SIP, as discussed in <https://www.ietf.org/mail-archive/web/sipcore/current/msg07245.html>= , with <draft-holmberg-sipcore-content-id> as a likely candidate = draft.
  5. Clarifications around SIP name-addr, with <draft-sparks-sipcore= -name-addr-guidance> as a likely candidate draft

I will also note that we have already declared consensus on adopting <dr= aft-ietf-sipcore-status-unwanted> as a WG document, and will be adding a= n associated milestone. I want to take this opportunity to remind people th= at the document is in WGLC, and your comments are strongly encouraged, the earlier the better.

Please respond before the end of 2016. Thanks!

Thanks!

/a
 --_000_D48194CE14EEAchristerholmbergericssoncom_-- From nobody Thu Dec 22 05:50:46 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE223129A14 for ; Thu, 22 Dec 2016 05:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 jRLs_RCstq-C for ; Thu, 22 Dec 2016 05:50:41 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0067.outbound.protection.outlook.com [104.47.33.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6A6129A18 for ; Thu, 22 Dec 2016 05:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=71EyB7af6eAc6FJ2ZDaP63aJStUEZ0eLq7DGRoNYceY=; b=eLdF0lMCuHjKXpSshbe7GIc5gLzJsoNz6wKGzVsq3dB+0WzlxqPxvxdW5tteNlcOaHPSVaU2uf55G2oGMV3Heb0ad1frIW6XkwQnnTtIYYAR5/2dP+Gxq98OgZufbsXall0jvGcHX7u0/+OKTV3tfXOzeobcDHwu2njPoVCaeE0= Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Thu, 22 Dec 2016 13:50:37 +0000 Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.0789.018; Thu, 22 Dec 2016 13:50:37 +0000 From: "Asveren, Tolga" To: Christer Holmberg , Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv96++N6DRIq/E2cKGNWf6YDKaET6r4AgAAS3iA= Date: Thu, 22 Dec 2016 13:50:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 9138a712-9ebd-41de-3e84-08d42a718267 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2342; x-microsoft-exchange-diagnostics: 1; CO2PR03MB2342; 7:xHTr+JBHkKUA9XdODVcQGaXDA9FNIpcZmqTIKzzrmuH9ZssneWFL576nA6ugAG0wU9pI78UEpRWhsSJHZVCRE/oJaW1H4AenFbm4+hr1dXn+3G37Bgq5zKYxtjcVJCJwSj02uLL0zUwNSQbco7ksl3Mi93p5sitZAl+/wDtlIuFPtTkNnmx/eEx3lvSASvsfKndLNEEKt0mIAZUk1gucwJJSuuZmylhUisLO+aC7/uMVIbpLPhWVXOreJn5k1e9bIjUcddNRgWu0a2SzwLj5tfUqyFbcJXn+f6/DLdbA7RKI9jYxZumLydyVllnNZgACn/PAkdLX6bKSWyrEbq1vmC0IARoMQSqGCXCdwXpmb0h1G+/CsQhsEnUOtgnZlHcEHZpX3PY2eLYmB9qpn99bgE8jqMUxT22IfSkfK+qEXSTbmv4DknTI5+qmLHUGeTa27Ag5GPgmbC8MxeakpPnSoA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(6047074); SRVR:CO2PR03MB2342; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2342; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(377454003)(189002)(99286002)(6506006)(25786008)(19609705001)(6436002)(102836003)(606005)(7696004)(229853002)(2906002)(4326007)(6116002)(5660300001)(790700001)(3660700001)(3280700002)(3846002)(8936002)(2900100001)(81156014)(81166006)(8676002)(7736002)(38730400001)(7906003)(77096006)(92566002)(97736004)(5001770100001)(2950100002)(9686002)(54356999)(106356001)(74316002)(189998001)(86362001)(105586002)(122556002)(68736007)(76176999)(101416001)(66066001)(33656002)(50986999)(76576001)(106116001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2342; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB2342255BB9ECDF579283A930B2920CO2PR03MB2342namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 13:50:36.8934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2342 Archived-At: Cc: Ben Campbell Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 13:50:44 -0000 --_000_CO2PR03MB2342255BB9ECDF579283A930B2920CO2PR03MB2342namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the interest in SIP/UDP/DTLS: This is mainly based on prospect of larger scalability on server side. Ther= e may/may not be an immediate need to tweak/change things to make DTLS rela= ted processing (hopefully just on the local stack level rather than on on-t= he-wire protocol- with some supporting SIP enhancements) more "failover fri= endly". This issue requires more analysis/discussion but does not sound uns= olvable IMHO. Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Thursday, December 22, 2016 7:39 AM To: Adam Roach ; 'SIPCORE' Cc: Ben Campbell Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Hi, I will obviously be actively involved in 4), and I also agree that 5) shoul= d be done as it is a correction. As far as the other potential work is concerned, 3) has the highest priorit= y for me, and I would actively participate in that work. I would review 1) and 2), but I would really like to see an individual draf= t on 2) before we agree whether to create a milestone for it. For example, = I would like to see some input on WHY to do it, and HOW it is intended to b= e deployed etc. How does DTLS fit SIP? What are the advantages? OR, do we w= ant to specify DTLS-for-SIP simply because DTLS is "hot"? Regards, Christer From: sipcore > o= n behalf of "adam@nostrum.com" > Date: Tuesday 20 December 2016 at 22:27 To: "sipcore@ietf.org" > Cc: Ben Campbell > Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones [as chair] Now that we have our new charter approved, I'd like the working group to ha= ve a discussion about the specific work items that we should take on in the= short- to medium-term so that we can revise our milestones appropriately. = Based on recent discussions on the mailing list, the following topics have = some mind-share behind them. What I'd like from everyone with an interest i= n any of these topics is to indicate (a) whether you are willing to activel= y review and comment on documents on the topic; and (b) what priority each = task has relative to each other: there are five topics; please indicate a u= nique priority from one (most important) to five (least important) for each= topic. 1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently under discus= sion on the list. 2. "DTLS Transport for SIP", as proposed by Tolga Asveren's recent messa= ges. 3. A mechanism for labeling the nature of SIP calls, with as a likely candidate draft. 4. Fixing Content-ID in SIP, as discussed in , with as a likely candidate draft. 5. Clarifications around SIP name-addr, with as a likely candidate draft I will also note that we have already declared consensus on adopting as a WG document, and will be adding an asso= ciated milestone. I want to take this opportunity to remind people that the= document is in WGLC, and your comments are strongly encouraged, the earlie= r the better. Please respond before the end of 2016. Thanks! Thanks! /a --_000_CO2PR03MB2342255BB9ECDF579283A930B2920CO2PR03MB2342namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding the interest in SIP/UDP/DTLS:<= /span>

This is mainly based on prospect of larger scalabil= ity on server side. There may/may not be an immediate need to tweak/change = things to make DTLS related processing (hopefully just on the local stack level rather than on on-the-wire protocol- with so= me supporting SIP enhancements) more “failover friendly”. This = issue requires more analysis/discussion but does not sound unsolvable IMHO.=

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, December 22, 2016 7:39 AM
To: Adam Roach <adam@nostrum.com>; 'SIPCORE' <sipcore@ietf.= org>
Cc: Ben Campbell <ben@nostrum.com>
Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and mileston= es

 

Hi,

 

I will obviously be actively involved i= n 4), and I also agree that 5) should be done as it is a correction.

 

As far as the other potential work is c= oncerned, 3) has the highest priority for me, and I would actively particip= ate in that work.

 

I would review 1) and 2), but I would r= eally like to see an individual draft on 2) before we agree whether to crea= te a milestone for it. For example, I would like to see some input on WHY to do it, and HOW it is intended to be deployed e= tc. How does DTLS fit SIP? What are the advantages? OR, do we want to speci= fy DTLS-for-SIP simply because DTLS is “hot”?=

 

Regards,

 

Christer

 

From: sipcore <sipcore-bounces@ietf.org> on behalf of "adam@nostrum.com" <adam@nostrum.com>
Date: Tuesday 20 December 2016 at 22:27
To: "sipcore@ietf.org&q= uot; <sipcore@ietf.org>
Cc: Ben Campbell <ben@nostrum.= com>
Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

 

[as chai= r]

Now that we have our new charter approved, I'd like the working group to ha= ve a discussion about the specific work items that we should take on in the= short- to medium-term so that we can revise our milestones appropriately. = Based on recent discussions on the mailing list, the following topics have some mind-share behind them. What = I'd like from everyone with an interest in any of these topics is to indica= te (a) whether you are willing to actively review and comment on documents = on the topic; and (b) what priority each task has relative to each other: there are five topics; please indica= te a unique priority from one (most important) to five (least important) fo= r each topic.

  1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently under d= iscussion on the list.
  2. "DTLS Transport for SIP", as proposed by Tolga Asveren's recent = messages.
  3. A mechanism for labeling the nature of SIP calls, with <draft-schulzrin= ne-sipcore-callinfo-spam> as a likely candidate draft.
  4. Fixing Content-ID in SIP, as discussed in <https://www.ietf.org/mail-archive/web/sipcore/current/msg07245.htm= l>, with <draft-holmberg-sipcore-content-id> as a likely candi= date draft.
  5. Clarifications around SIP name-addr, with <draft-sparks-sipcore-name-ad= dr-guidance> as a likely candidate draft


I will also note that we have already declared consensus on adopting <dr= aft-ietf-sipcore-status-unwanted> as a WG document, and will be adding a= n associated milestone. I want to take this opportunity to remind people th= at the document is in WGLC, and your comments are strongly encouraged, the earlier the better.

Please respond before the end of 2016. Thanks!

Thanks!

/a

--_000_CO2PR03MB2342255BB9ECDF579283A930B2920CO2PR03MB2342namp_-- From nobody Thu Dec 22 06:08:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81B71295C6 for ; Thu, 22 Dec 2016 06:08:20 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WmyKE84BwCWz for ; Thu, 22 Dec 2016 06:08:18 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A4812947F for ; Thu, 22 Dec 2016 06:08:17 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id D3AC97032; Thu, 22 Dec 2016 15:08:03 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_0BF51037-CAD4-4A29-BFD0-3368D6BFE1BA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 22 Dec 2016 15:08:02 +0100 Message-Id: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> References: To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ben Campbell , SIPCORE , Olle E Johansson Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:08:20 -0000 --Apple-Mail=_0BF51037-CAD4-4A29-BFD0-3368D6BFE1BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Dec 2016, at 14:50, Asveren, Tolga = wrote: >=20 > Regarding the interest in SIP/UDP/DTLS: > This is mainly based on prospect of larger scalability on server side. = There may/may not be an immediate need to tweak/change things to make = DTLS related processing (hopefully just on the local stack level rather = than on on-the-wire protocol- with some supporting SIP enhancements) = more =E2=80=9Cfailover friendly=E2=80=9D. This issue requires more = analysis/discussion but does not sound unsolvable IMHO. We will have to solve client connection reuse for both TLS and DTLS = sessions though. Unless you want to have client certificates on all devices. Adam as chair: SIP Client Connection Reuse is something we=E2=80=99ve = disussed under multiple names - =E2=80=9Chalf outbound=E2=80=9D or = =E2=80=9Cwhy is ;transport=3Dtls=E2=80=9D deprecated=E2=80=9D or =E2=80=9CWhy doesn=E2=80=99t SIP Outbound = happen?=E2=80=9D. Maybe that deserves a milestone. /O > =20 > Thanks, > Tolga > =20 > From: sipcore [mailto:sipcore-bounces@ietf.org = ] On Behalf Of Christer Holmberg > Sent: Thursday, December 22, 2016 7:39 AM > To: Adam Roach >; 'SIPCORE' = > > Cc: Ben Campbell > > Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > Hi, > =20 > I will obviously be actively involved in 4), and I also agree that 5) = should be done as it is a correction. > =20 > As far as the other potential work is concerned, 3) has the highest = priority for me, and I would actively participate in that work. > =20 > I would review 1) and 2), but I would really like to see an individual = draft on 2) before we agree whether to create a milestone for it. For = example, I would like to see some input on WHY to do it, and HOW it is = intended to be deployed etc. How does DTLS fit SIP? What are the = advantages? OR, do we want to specify DTLS-for-SIP simply because DTLS = is =E2=80=9Chot=E2=80=9D? > =20 > Regards, > =20 > Christer > =20 > From: sipcore > on behalf of "adam@nostrum.com = " > > Date: Tuesday 20 December 2016 at 22:27 > To: "sipcore@ietf.org " > > Cc: Ben Campbell > > Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > [as chair] >=20 > Now that we have our new charter approved, I'd like the working group = to have a discussion about the specific work items that we should take = on in the short- to medium-term so that we can revise our milestones = appropriately. Based on recent discussions on the mailing list, the = following topics have some mind-share behind them. What I'd like from = everyone with an interest in any of these topics is to indicate (a) = whether you are willing to actively review and comment on documents on = the topic; and (b) what priority each task has relative to each other: = there are five topics; please indicate a unique priority from one (most = important) to five (least important) for each topic. >=20 > "Happy Eyeballs for SIP" (aka Happy Earballs), currently under = discussion on the list. > "DTLS Transport for SIP", as proposed by Tolga Asveren's recent = messages. > A mechanism for labeling the nature of SIP calls, with = as a likely candidate draft. > Fixing Content-ID in SIP, as discussed in = = , = with as a likely candidate draft. > Clarifications around SIP name-addr, with = as a likely candidate draft >=20 > I will also note that we have already declared consensus on adopting = as a WG document, and will be = adding an associated milestone. I want to take this opportunity to = remind people that the document is in WGLC, and your comments are = strongly encouraged, the earlier the better. >=20 > Please respond before the end of 2016. Thanks! >=20 > Thanks! >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_0BF51037-CAD4-4A29-BFD0-3368D6BFE1BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22 Dec 2016, at 14:50, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Regarding the interest in SIP/UDP/DTLS:
This is mainly based on prospect of larger scalability on = server side. There may/may not be an immediate need to tweak/change = things to make DTLS related processing (hopefully just on the local = stack level rather than on on-the-wire protocol- with some supporting = SIP enhancements) more =E2=80=9Cfailover friendly=E2=80=9D. This issue = requires more analysis/discussion but does not sound unsolvable = IMHO.
We will have to solve client = connection reuse for both TLS and DTLS sessions though. Unless you want = to have
client certificates on all devices.

Adam as chair: SIP Client Connection Reuse is = something we=E2=80=99ve disussed under multiple names - =E2=80=9Chalf = outbound=E2=80=9D or =E2=80=9Cwhy is = ;transport=3Dtls=E2=80=9D
deprecated=E2=80=9D or =E2=80=9CWhy = doesn=E2=80=99t SIP Outbound happen?=E2=80=9D. Maybe that deserves a = milestone.

/O
 
Thanks,
Tolga
 
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: Thursday, December 22, 2016 = 7:39 AM
To: Adam Roach <adam@nostrum.com>; = 'SIPCORE' <sipcore@ietf.org>
Cc: Ben = Campbell <ben@nostrum.com>
Subject: Re: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 
Hi,
 
I will obviously be = actively involved in 4), and I also agree that 5) should be done as it = is a correction.
 
As far as the other potential work is concerned, 3) has the = highest priority for me, and I would actively participate in that = work.
 
I would review 1) and 2), = but I would really like to see an individual draft on 2) before we agree = whether to create a milestone for it. For example, I would like to see = some input on WHY to do it, and HOW it is intended to be deployed etc. = How does DTLS fit SIP? What are the advantages? OR, do we want to = specify DTLS-for-SIP simply because DTLS is =E2=80=9Chot=E2=80=9D?
 
Regards,
 
Christer
 
From: sipcore <sipcore-bounces@ietf.org> on behalf of "adam@nostrum.com" <adam@nostrum.com>
Date: Tuesday 20 December = 2016 at 22:27
To: "sipcore@ietf.org" <sipcore@ietf.org>
Cc: Ben Campbell <ben@nostrum.com>
Subject: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 

[as chair]

Now that we have our = new charter approved, I'd like the working group to have a discussion = about the specific work items that we should take on in the short- to = medium-term so that we can revise our milestones appropriately. Based on = recent discussions on the mailing list, the following topics have some = mind-share behind them. What I'd like from everyone with an interest in = any of these topics is to indicate (a) whether you are willing to = actively review and comment on documents on the topic; and (b) what = priority each task has relative to each other: there are five topics; = please indicate a unique priority from one (most important) to five = (least important) for each topic.

  1. "Happy Eyeballs = for SIP" (aka Happy Earballs), currently under discussion on the = list.
  2. "DTLS Transport for SIP", as proposed = by Tolga Asveren's recent messages.
  3. A mechanism for = labeling the nature of SIP calls, with = <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidate = draft.
  4. Fixing Content-ID in SIP, as discussed = in <https://www.ietf.org/mail-archive/web/sipcore/current/msg07= 245.html>, with <draft-holmberg-sipcore-content-id> as a = likely candidate draft.
  5. Clarifications = around SIP name-addr, with = <draft-sparks-sipcore-name-addr-guidance> as a likely candidate = draft

I will also note that we have = already declared consensus on adopting = <draft-ietf-sipcore-status-unwanted> as a WG document, and will be = adding an associated milestone. I want to take this opportunity to = remind people that the document is in WGLC, and your comments are = strongly encouraged, the earlier the better.

Please respond before the end of 2016. Thanks!

Thanks!

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

= --Apple-Mail=_0BF51037-CAD4-4A29-BFD0-3368D6BFE1BA-- From nobody Thu Dec 22 07:34:14 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6931296B2 for ; Thu, 22 Dec 2016 07:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 rvsuWWp6dPEj for ; Thu, 22 Dec 2016 07:34:08 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0069.outbound.protection.outlook.com [104.47.42.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E60012955C for ; Thu, 22 Dec 2016 07:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jPKOzLChZwiST89BJ3Fz26xNy0tlK+DcVSzBTcq83VY=; b=glhPiWoJOL8gW233BtW6HCJ4F2+dz5eoE+uLKZWN9XSDsIGxINGsXWr/m1nnLn76kRhDfxmv7wxOroFRTKdaMX0gzuiyT6xcsHaNJRcVH4m0sJsQmWdZzmpDsty5Sn6kTtL42i6WWGPXnEJScj9pgjOGk4RtGpOE7N5XOijr+2k= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Thu, 22 Dec 2016 15:34:07 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.015; Thu, 22 Dec 2016 15:34:07 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv96++N6DRIq/E2cKGNWf6YDKaET6r4AgAAS3iCAAAYCAIAAF0yA Date: Thu, 22 Dec 2016 15:34:06 +0000 Message-ID: References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> In-Reply-To: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 311efd45-b83e-46bf-d802-08d42a7ff7be x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:QUfNQ5GQZT4rZRMDoGNCDP48GnRuaZDWIpkGcbmRgwkF5Qa1ublt7bMi1mGlD1NZ+Aycbv4JYVR7/qXe12Rb+DHlvJXrrdthebuSDD9q6RhNYAgDjBc2JySejBIdYeyPE2Z+kpFcosIso0c/s3Wp+EdYpqF6OxDw40xAYO0Cji/dD3tVeALiFvCgN4XCErnMJGlBzAAmR0vyJ+Gu1gFAEIOC2ZNWqjFmvwVWAE/Yqea5FSEXNL6tA3fgtmK2BKzYFllurQR6jQSA7e4SfHAqPPNj4tKAa+qQEvBFtv4pKOL+JJSh11G15J66NG8EGRsmStJyXEO5ZAIRKLchKN0hozNyPKhGEU21AF2kzclDxCV+9P+/04uQ/bwOXfwAwjBTqc5uKwPQ2XlYr43XpLSCx/vnmX5HsBdeqFn0ls5UgcSH0pZ3MxNgniZ0QvB7ksYREd5u4h3ndBxPQVGpYcIzlw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(24454002)(377454003)(189002)(199003)(2906002)(33656002)(6116002)(2900100001)(5660300001)(7906003)(97736004)(3846002)(74316002)(3280700002)(3660700001)(76576001)(92566002)(7736002)(189998001)(102836003)(790700001)(86362001)(229853002)(66066001)(77096006)(122556002)(38730400001)(2950100002)(106116001)(8676002)(81156014)(6506006)(99286002)(606005)(6916009)(19609705001)(106356001)(93886004)(68736007)(105586002)(6436002)(81166006)(25786008)(8936002)(110136003)(54356999)(9686002)(4326007)(76176999)(7696004)(50986999)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235007F2298CD2EEDC718363B2920SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 15:34:06.8872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 Archived-At: Cc: Ben Campbell , SIPCORE Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 15:34:11 -0000 --_000_SN2PR03MB235007F2298CD2EEDC718363B2920SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2xsZSwNCg0KSSBtaXNzZWQgdGhlIHBvaW50IGFib3V0IHdoeSDigJxwcmFjdGljYWxseSBwb3Nz aWJsZSBmYWlsb3ZlcuKAnSBuZWVkcyB0byBiZSBzb2x2ZWQgYm90aCBmb3IgVExTL0RUTFMgKEkg YW0gbm90IGFyZ3VpbmcgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgc29sdXRpb24gZm9yIGJv dGgpIGFuZCBhbHNvIHdoYXQgdGhpcyBpc3N1ZSBpbiBnZW5lcmFsIGhhcyBzb21ldGhpbmcgdG8g ZG8gd2l0aCBjbGllbnQgY2VydGlmaWNhdGVzLg0KQ291bGQgeW91IHByb3ZpZGUgYSBiaXQgbW9y ZSBpbmZvcm1hdGlvbi9jbGFyaWZpY2F0aW9ucz8NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTog T2xsZSBFLiBKb2hhbnNzb24gW21haWx0bzpvZWpAZWR2aW5hLm5ldF0NClNlbnQ6IFRodXJzZGF5 LCBEZWNlbWJlciAyMiwgMjAxNiA5OjA4IEFNDQpUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVu QHNvbnVzbmV0LmNvbT4NCkNjOiBPbGxlIEUgSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD47IENo cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBBZGFtIFJv YWNoIDxhZGFtQG5vc3RydW0uY29tPjsgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz47IEJlbiBD YW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBSRVNQT05T RSBSRVFVRVNURUQ6IFNJUENPUkUgd29yayBhbmQgbWlsZXN0b25lcw0KDQoNCk9uIDIyIERlYyAy MDE2LCBhdCAxNDo1MCwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWls dG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQoNClJlZ2FyZGluZyB0aGUgaW50ZXJl c3QgaW4gU0lQL1VEUC9EVExTOg0KVGhpcyBpcyBtYWlubHkgYmFzZWQgb24gcHJvc3BlY3Qgb2Yg bGFyZ2VyIHNjYWxhYmlsaXR5IG9uIHNlcnZlciBzaWRlLiBUaGVyZSBtYXkvbWF5IG5vdCBiZSBh biBpbW1lZGlhdGUgbmVlZCB0byB0d2Vhay9jaGFuZ2UgdGhpbmdzIHRvIG1ha2UgRFRMUyByZWxh dGVkIHByb2Nlc3NpbmcgKGhvcGVmdWxseSBqdXN0IG9uIHRoZSBsb2NhbCBzdGFjayBsZXZlbCBy YXRoZXIgdGhhbiBvbiBvbi10aGUtd2lyZSBwcm90b2NvbC0gd2l0aCBzb21lIHN1cHBvcnRpbmcg U0lQIGVuaGFuY2VtZW50cykgbW9yZSDigJxmYWlsb3ZlciBmcmllbmRseeKAnS4gVGhpcyBpc3N1 ZSByZXF1aXJlcyBtb3JlIGFuYWx5c2lzL2Rpc2N1c3Npb24gYnV0IGRvZXMgbm90IHNvdW5kIHVu c29sdmFibGUgSU1ITy4NCldlIHdpbGwgaGF2ZSB0byBzb2x2ZSBjbGllbnQgY29ubmVjdGlvbiBy ZXVzZSBmb3IgYm90aCBUTFMgYW5kIERUTFMgc2Vzc2lvbnMgdGhvdWdoLiBVbmxlc3MgeW91IHdh bnQgdG8gaGF2ZQ0KY2xpZW50IGNlcnRpZmljYXRlcyBvbiBhbGwgZGV2aWNlcy4NCg0KQWRhbSBh cyBjaGFpcjogU0lQIENsaWVudCBDb25uZWN0aW9uIFJldXNlIGlzIHNvbWV0aGluZyB3ZeKAmXZl IGRpc3Vzc2VkIHVuZGVyIG11bHRpcGxlIG5hbWVzIC0g4oCcaGFsZiBvdXRib3VuZOKAnSBvciDi gJx3aHkgaXMgO3RyYW5zcG9ydD10bHPigJ0NCmRlcHJlY2F0ZWTigJ0gb3Ig4oCcV2h5IGRvZXNu 4oCZdCBTSVAgT3V0Ym91bmQgaGFwcGVuP+KAnS4gTWF5YmUgdGhhdCBkZXNlcnZlcyBhIG1pbGVz dG9uZS4NCg0KL08NCg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcN ClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMiwgMjAxNiA3OjM5IEFNDQpUbzogQWRhbSBSb2Fj aCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+OyAnU0lQQ09SRScg PHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+Pg0KQ2M6IEJlbiBDYW1w YmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+Pg0KU3ViamVjdDog UmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUgd29yayBhbmQgbWlsZXN0 b25lcw0KDQpIaSwNCg0KSSB3aWxsIG9idmlvdXNseSBiZSBhY3RpdmVseSBpbnZvbHZlZCBpbiA0 KSwgYW5kIEkgYWxzbyBhZ3JlZSB0aGF0IDUpIHNob3VsZCBiZSBkb25lIGFzIGl0IGlzIGEgY29y cmVjdGlvbi4NCg0KQXMgZmFyIGFzIHRoZSBvdGhlciBwb3RlbnRpYWwgd29yayBpcyBjb25jZXJu ZWQsIDMpIGhhcyB0aGUgaGlnaGVzdCBwcmlvcml0eSBmb3IgbWUsIGFuZCBJIHdvdWxkIGFjdGl2 ZWx5IHBhcnRpY2lwYXRlIGluIHRoYXQgd29yay4NCg0KSSB3b3VsZCByZXZpZXcgMSkgYW5kIDIp LCBidXQgSSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUgYW4gaW5kaXZpZHVhbCBkcmFmdCBvbiAy KSBiZWZvcmUgd2UgYWdyZWUgd2hldGhlciB0byBjcmVhdGUgYSBtaWxlc3RvbmUgZm9yIGl0LiBG b3IgZXhhbXBsZSwgSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIGlucHV0IG9uIFdIWSB0byBkbyBp dCwgYW5kIEhPVyBpdCBpcyBpbnRlbmRlZCB0byBiZSBkZXBsb3llZCBldGMuIEhvdyBkb2VzIERU TFMgZml0IFNJUD8gV2hhdCBhcmUgdGhlIGFkdmFudGFnZXM/IE9SLCBkbyB3ZSB3YW50IHRvIHNw ZWNpZnkgRFRMUy1mb3ItU0lQIHNpbXBseSBiZWNhdXNlIERUTFMgaXMg4oCcaG904oCdPw0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBzaXBjb3JlIDxzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAiYWRh bUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4iIDxhZGFtQG5vc3RydW0uY29t PG1haWx0bzphZGFtQG5vc3RydW0uY29tPj4NCkRhdGU6IFR1ZXNkYXkgMjAgRGVjZW1iZXIgMjAx NiBhdCAyMjoyNw0KVG86ICJzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3Jn PiIgPHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+Pg0KQ2M6IEJlbiBD YW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+Pg0KU3ViamVj dDogW3NpcGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3Rv bmVzDQoNClthcyBjaGFpcl0NCg0KTm93IHRoYXQgd2UgaGF2ZSBvdXIgbmV3IGNoYXJ0ZXIgYXBw cm92ZWQsIEknZCBsaWtlIHRoZSB3b3JraW5nIGdyb3VwIHRvIGhhdmUgYSBkaXNjdXNzaW9uIGFi b3V0IHRoZSBzcGVjaWZpYyB3b3JrIGl0ZW1zIHRoYXQgd2Ugc2hvdWxkIHRha2Ugb24gaW4gdGhl IHNob3J0LSB0byBtZWRpdW0tdGVybSBzbyB0aGF0IHdlIGNhbiByZXZpc2Ugb3VyIG1pbGVzdG9u ZXMgYXBwcm9wcmlhdGVseS4gQmFzZWQgb24gcmVjZW50IGRpc2N1c3Npb25zIG9uIHRoZSBtYWls aW5nIGxpc3QsIHRoZSBmb2xsb3dpbmcgdG9waWNzIGhhdmUgc29tZSBtaW5kLXNoYXJlIGJlaGlu ZCB0aGVtLiBXaGF0IEknZCBsaWtlIGZyb20gZXZlcnlvbmUgd2l0aCBhbiBpbnRlcmVzdCBpbiBh bnkgb2YgdGhlc2UgdG9waWNzIGlzIHRvIGluZGljYXRlIChhKSB3aGV0aGVyIHlvdSBhcmUgd2ls bGluZyB0byBhY3RpdmVseSByZXZpZXcgYW5kIGNvbW1lbnQgb24gZG9jdW1lbnRzIG9uIHRoZSB0 b3BpYzsgYW5kIChiKSB3aGF0IHByaW9yaXR5IGVhY2ggdGFzayBoYXMgcmVsYXRpdmUgdG8gZWFj aCBvdGhlcjogdGhlcmUgYXJlIGZpdmUgdG9waWNzOyBwbGVhc2UgaW5kaWNhdGUgYSB1bmlxdWUg cHJpb3JpdHkgZnJvbSBvbmUgKG1vc3QgaW1wb3J0YW50KSB0byBmaXZlIChsZWFzdCBpbXBvcnRh bnQpIGZvciBlYWNoIHRvcGljLg0KDQogIDEuICAiSGFwcHkgRXllYmFsbHMgZm9yIFNJUCIgKGFr YSBIYXBweSBFYXJiYWxscyksIGN1cnJlbnRseSB1bmRlciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0 Lg0KICAyLiAgIkRUTFMgVHJhbnNwb3J0IGZvciBTSVAiLCBhcyBwcm9wb3NlZCBieSBUb2xnYSBB c3ZlcmVuJ3MgcmVjZW50IG1lc3NhZ2VzLg0KICAzLiAgQSBtZWNoYW5pc20gZm9yIGxhYmVsaW5n IHRoZSBuYXR1cmUgb2YgU0lQIGNhbGxzLCB3aXRoIDxkcmFmdC1zY2h1bHpyaW5uZS1zaXBjb3Jl LWNhbGxpbmZvLXNwYW0+IGFzIGEgbGlrZWx5IGNhbmRpZGF0ZSBkcmFmdC4NCiAgNC4gIEZpeGlu ZyBDb250ZW50LUlEIGluIFNJUCwgYXMgZGlzY3Vzc2VkIGluIDxodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNzI0NS5odG1sPjxodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNzI0NS5o dG1sPiwgd2l0aCA8ZHJhZnQtaG9sbWJlcmctc2lwY29yZS1jb250ZW50LWlkPiBhcyBhIGxpa2Vs eSBjYW5kaWRhdGUgZHJhZnQuDQogIDUuICBDbGFyaWZpY2F0aW9ucyBhcm91bmQgU0lQIG5hbWUt YWRkciwgd2l0aCA8ZHJhZnQtc3BhcmtzLXNpcGNvcmUtbmFtZS1hZGRyLWd1aWRhbmNlPiBhcyBh IGxpa2VseSBjYW5kaWRhdGUgZHJhZnQNCg0KSSB3aWxsIGFsc28gbm90ZSB0aGF0IHdlIGhhdmUg YWxyZWFkeSBkZWNsYXJlZCBjb25zZW5zdXMgb24gYWRvcHRpbmcgPGRyYWZ0LWlldGYtc2lwY29y ZS1zdGF0dXMtdW53YW50ZWQ+IGFzIGEgV0cgZG9jdW1lbnQsIGFuZCB3aWxsIGJlIGFkZGluZyBh biBhc3NvY2lhdGVkIG1pbGVzdG9uZS4gSSB3YW50IHRvIHRha2UgdGhpcyBvcHBvcnR1bml0eSB0 byByZW1pbmQgcGVvcGxlIHRoYXQgdGhlIGRvY3VtZW50IGlzIGluIFdHTEMsIGFuZCB5b3VyIGNv bW1lbnRzIGFyZSBzdHJvbmdseSBlbmNvdXJhZ2VkLCB0aGUgZWFybGllciB0aGUgYmV0dGVyLg0K DQpQbGVhc2UgcmVzcG9uZCBiZWZvcmUgdGhlIGVuZCBvZiAyMDE2LiBUaGFua3MhDQoNClRoYW5r cyENCg0KL2ENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K DQo= --_000_SN2PR03MB235007F2298CD2EEDC718363B2920SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRl ZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjExMTU3MDc4NTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1ODUyMTQz Njt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5PbGxlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIG1pc3NlZCB0aGUgcG9pbnQgYWJv dXQgd2h5IOKAnHByYWN0aWNhbGx5IHBvc3NpYmxlIGZhaWxvdmVy4oCdIG5lZWRzIHRvIGJlIHNv bHZlZCBib3RoIGZvciBUTFMvRFRMUyAoSSBhbSBub3QgYXJndWluZyBpdCB3b3VsZCBiZSBnb29k IHRvIGhhdmUgYSBzb2x1dGlvbiBmb3IgYm90aCkgYW5kIGFsc28gd2hhdA0KIHRoaXMgaXNzdWUg aW4gZ2VuZXJhbCBoYXMgc29tZXRoaW5nIHRvIGRvIHdpdGggY2xpZW50IGNlcnRpZmljYXRlcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkNvdWxkIHlvdSBwcm92aWRlIGEgYml0IG1vcmUgaW5mb3JtYXRpb24vY2xhcmlmaWNhdGlv bnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9sbGUgRS4gSm9oYW5zc29uIFttYWls dG86b2VqQGVkdmluYS5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVy IDIyLCAyMDE2IDk6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhICZsdDt0YXN2 ZXJlbkBzb251c25ldC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBPbGxlIEUgSm9oYW5zc29uICZs dDtvZWpAZWR2aW5hLm5ldCZndDs7IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20mZ3Q7OyBBZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0 OzsgU0lQQ09SRSAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs7IEJlbiBDYW1wYmVsbCAmbHQ7YmVu QG5vc3RydW0uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIFJFU1BP TlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgRGVjIDIwMTYsIGF0IDE0 OjUwLCBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0 LmNvbSI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZGlu ZyB0aGUgaW50ZXJlc3QgaW4gU0lQL1VEUC9EVExTOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBp cyBtYWlubHkgYmFzZWQgb24gcHJvc3BlY3Qgb2YgbGFyZ2VyIHNjYWxhYmlsaXR5IG9uIHNlcnZl ciBzaWRlLiBUaGVyZSBtYXkvbWF5IG5vdCBiZSBhbiBpbW1lZGlhdGUgbmVlZCB0byB0d2Vhay9j aGFuZ2UgdGhpbmdzIHRvIG1ha2UgRFRMUyByZWxhdGVkIHByb2Nlc3NpbmcgKGhvcGVmdWxseQ0K IGp1c3Qgb24gdGhlIGxvY2FsIHN0YWNrIGxldmVsIHJhdGhlciB0aGFuIG9uIG9uLXRoZS13aXJl IHByb3RvY29sLSB3aXRoIHNvbWUgc3VwcG9ydGluZyBTSVAgZW5oYW5jZW1lbnRzKSBtb3JlIOKA nGZhaWxvdmVyIGZyaWVuZGx54oCdLiBUaGlzIGlzc3VlIHJlcXVpcmVzIG1vcmUgYW5hbHlzaXMv ZGlzY3Vzc2lvbiBidXQgZG9lcyBub3Qgc291bmQgdW5zb2x2YWJsZSBJTUhPLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XZSB3aWxsIGhhdmUgdG8gc29sdmUgY2xpZW50IGNvbm5lY3Rpb24gcmV1c2UgZm9y IGJvdGggVExTIGFuZCBEVExTIHNlc3Npb25zIHRob3VnaC4gVW5sZXNzIHlvdSB3YW50IHRvIGhh dmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNs aWVudCBjZXJ0aWZpY2F0ZXMgb24gYWxsIGRldmljZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkYW0gYXMgY2hhaXI6IFNJUCBDbGllbnQg Q29ubmVjdGlvbiBSZXVzZSBpcyBzb21ldGhpbmcgd2XigJl2ZSBkaXN1c3NlZCB1bmRlciBtdWx0 aXBsZSBuYW1lcyAtIOKAnGhhbGYgb3V0Ym91bmTigJ0gb3Ig4oCcd2h5IGlzIDt0cmFuc3BvcnQ9 dGxz4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5kZXByZWNhdGVk4oCdIG9yIOKAnFdoeSBkb2VzbuKAmXQgU0lQIE91dGJvdW5kIGhhcHBlbj/i gJ0uIE1heWJlIHRoYXQgZGVzZXJ2ZXMgYSBtaWxlc3RvbmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9PPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnNpcGNvcmUN CiBbPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+ XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBC ZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPkNocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBEZWNlbWJlciAyMiwgMjAx NiA3OjM5IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5BZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0 cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhbUBub3N0cnVtLmNvbTwvc3Bh bj48L2E+Jmd0OzsgJ1NJUENPUkUnICZsdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2lwY29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+ Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+QmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0u Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5iZW5Abm9zdHJ1bS5jb208L3NwYW4+PC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENP UkUgd29yayBhbmQgbWlsZXN0b25lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHdpbGwgb2J2aW91c2x5IGJlIGFjdGl2 ZWx5IGludm9sdmVkIGluIDQpLCBhbmQgSSBhbHNvIGFncmVlIHRoYXQgNSkgc2hvdWxkIGJlIGRv bmUgYXMgaXQgaXMgYSBjb3JyZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BcyBmYXIgYXMgdGhl IG90aGVyIHBvdGVudGlhbCB3b3JrIGlzIGNvbmNlcm5lZCwgMykgaGFzIHRoZSBoaWdoZXN0IHBy aW9yaXR5IGZvciBtZSwgYW5kIEkgd291bGQgYWN0aXZlbHkgcGFydGljaXBhdGUgaW4gdGhhdCB3 b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHdvdWxkIHJldmlldyAxKSBhbmQgMiksIGJ1dCBJIHdv dWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IG9uIDIpIGJlZm9yZSB3 ZSBhZ3JlZSB3aGV0aGVyIHRvIGNyZWF0ZSBhIG1pbGVzdG9uZSBmb3IgaXQuIEZvciBleGFtcGxl LCBJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUNCiBpbnB1dCBvbiBXSFkgdG8gZG8gaXQsIGFuZCBI T1cgaXQgaXMgaW50ZW5kZWQgdG8gYmUgZGVwbG95ZWQgZXRjLiBIb3cgZG9lcyBEVExTIGZpdCBT SVA/IFdoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzPyBPUiwgZG8gd2Ugd2FudCB0byBzcGVjaWZ5IERU TFMtZm9yLVNJUCBzaW1wbHkgYmVjYXVzZSBEVExTIGlzIOKAnGhvdOKAnT88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+c2lwY29y ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7 DQogb24gYmVoYWxmIG9mICZxdW90OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGFtQG5vc3RydW0uY29tPC9zcGFuPjwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5hZGFtQG5vc3RydW0uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlR1ZXNk YXkgMjAgRGVjZW1iZXIgMjAxNiBhdCAyMjoyNzxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRv OnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNpcGNvcmVAaWV0 Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9h PiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPkJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBub3N0cnVt LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVuQG5vc3RydW0uY29tPC9zcGFuPjwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPltzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUg d29yayBhbmQgbWlsZXN0b25lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlthcyBjaGFpcl08YnI+DQo8YnI+DQpOb3cgdGhhdCB3ZSBoYXZlIG91ciBuZXcg Y2hhcnRlciBhcHByb3ZlZCwgSSdkIGxpa2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gaGF2ZSBhIGRp c2N1c3Npb24gYWJvdXQgdGhlIHNwZWNpZmljIHdvcmsgaXRlbXMgdGhhdCB3ZSBzaG91bGQgdGFr ZSBvbiBpbiB0aGUgc2hvcnQtIHRvIG1lZGl1bS10ZXJtIHNvIHRoYXQgd2UgY2FuIHJldmlzZSBv dXIgbWlsZXN0b25lcyBhcHByb3ByaWF0ZWx5LiBCYXNlZCBvbiByZWNlbnQgZGlzY3Vzc2lvbnMg b24gdGhlDQogbWFpbGluZyBsaXN0LCB0aGUgZm9sbG93aW5nIHRvcGljcyBoYXZlIHNvbWUgbWlu ZC1zaGFyZSBiZWhpbmQgdGhlbS4gV2hhdCBJJ2QgbGlrZSBmcm9tIGV2ZXJ5b25lIHdpdGggYW4g aW50ZXJlc3QgaW4gYW55IG9mIHRoZXNlIHRvcGljcyBpcyB0byBpbmRpY2F0ZSAoYSkgd2hldGhl ciB5b3UgYXJlIHdpbGxpbmcgdG8gYWN0aXZlbHkgcmV2aWV3IGFuZCBjb21tZW50IG9uIGRvY3Vt ZW50cyBvbiB0aGUgdG9waWM7IGFuZCAoYikgd2hhdCBwcmlvcml0eQ0KIGVhY2ggdGFzayBoYXMg cmVsYXRpdmUgdG8gZWFjaCBvdGhlcjogdGhlcmUgYXJlIGZpdmUgdG9waWNzOyBwbGVhc2UgaW5k aWNhdGUgYSB1bmlxdWUgcHJpb3JpdHkgZnJvbSBvbmUgKG1vc3QgaW1wb3J0YW50KSB0byBmaXZl IChsZWFzdCBpbXBvcnRhbnQpIGZvciBlYWNoIHRvcGljLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+JnF1b3Q7SGFwcHkgRXllYmFsbHMgZm9yIFNJUCZxdW90OyAoYWthIEhhcHB5IEVhcmJh bGxzKSwgY3VycmVudGx5IHVuZGVyIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuPC9zcGFuPjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVs MSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90O0RUTFMgVHJhbnNwb3J0IGZvciBTSVAmcXVv dDssIGFzIHByb3Bvc2VkIGJ5IFRvbGdhIEFzdmVyZW4ncyByZWNlbnQgbWVzc2FnZXMuPC9zcGFu PjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omww IGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkEgbWVjaGFuaXNtIGZvciBsYWJlbGluZyB0 aGUgbmF0dXJlIG9mIFNJUCBjYWxscywgd2l0aCAmbHQ7ZHJhZnQtc2NodWx6cmlubmUtc2lwY29y ZS1jYWxsaW5mby1zcGFtJmd0OyBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQuPC9zcGFuPjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZpeGluZyBDb250ZW50LUlEIGluIFNJUCwgYXMg ZGlzY3Vzc2VkIGluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29y ZS9jdXJyZW50L21zZzA3MjQ1Lmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDto dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cw NzI0NS5odG1sJmd0Ozwvc3Bhbj48L2E+LA0KIHdpdGggJmx0O2RyYWZ0LWhvbG1iZXJnLXNpcGNv cmUtY29udGVudC1pZCZndDsgYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0Ljwvc3Bhbj48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DbGFyaWZpY2F0aW9ucyBhcm91bmQgU0lQIG5hbWUt YWRkciwgd2l0aCAmbHQ7ZHJhZnQtc3BhcmtzLXNpcGNvcmUtbmFtZS1hZGRyLWd1aWRhbmNlJmd0 OyBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQ8L3NwYW4+PG86cD48L286cD48L2xpPjwvb2w+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpJIHdp bGwgYWxzbyBub3RlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGRlY2xhcmVkIGNvbnNlbnN1cyBvbiBh ZG9wdGluZyAmbHQ7ZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZCZndDsgYXMgYSBX RyBkb2N1bWVudCwgYW5kIHdpbGwgYmUgYWRkaW5nIGFuIGFzc29jaWF0ZWQgbWlsZXN0b25lLiBJ IHdhbnQgdG8gdGFrZSB0aGlzIG9wcG9ydHVuaXR5IHRvIHJlbWluZCBwZW9wbGUgdGhhdCB0aGUg ZG9jdW1lbnQgaXMgaW4gV0dMQywgYW5kIHlvdXIgY29tbWVudHMNCiBhcmUgc3Ryb25nbHkgZW5j b3VyYWdlZCwgdGhlIGVhcmxpZXIgdGhlIGJldHRlci48YnI+DQo8YnI+DQpQbGVhc2UgcmVzcG9u ZCBiZWZvcmUgdGhlIGVuZCBvZiAyMDE2LiBUaGFua3MhPGJyPg0KPGJyPg0KVGhhbmtzITxicj4N Cjxicj4NCi9hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxp bmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5zaXBjb3JlQGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVy cGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_SN2PR03MB235007F2298CD2EEDC718363B2920SN2PR03MB2350namp_-- From nobody Thu Dec 22 07:55:41 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C7C1294DF for ; Thu, 22 Dec 2016 07:55:39 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 S2LyCeJlIiMy for ; Thu, 22 Dec 2016 07:55:36 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C906D12949D for ; Thu, 22 Dec 2016 07:55:35 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 6DF347032; Thu, 22 Dec 2016 16:55:21 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_0DAC25C0-9A7B-4ADC-A04D-A7A2FFF49A1A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 22 Dec 2016 16:55:04 +0100 Message-Id: References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ben Campbell , SIPCORE , Olle E Johansson Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 15:55:40 -0000 --Apple-Mail=_0DAC25C0-9A7B-4ADC-A04D-A7A2FFF49A1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Dec 2016, at 16:34, Asveren, Tolga = wrote: >=20 > Olle, > =20 > I missed the point about why =E2=80=9Cpractically possible failover=E2=80= =9D needs to be solved both for TLS/DTLS (I am not arguing it would be = good to have a solution for both) and also what this issue in general = has something to do with client certificates. > Could you provide a bit more information/clarifications? > =20 We=E2=80=99ve discussed it a number of times both here and on the SIP = Forum techwg mailing list. You can find summaries here: http://www.slideshare.net/oej/sip-half-outbound-random-notes http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world In short, without SIP Outbound the client connection can=E2=80=99t be = re-used for outbound requests. Seems like there is a huge resistance to implement SIP Outbound. We need a way for the client to = allow the server to reuse the inbound connection for outbound requests even though there=E2=80=99s no TLS certificate = matching the URI on the client side. We=E2=80=99ve had a lot of clients register with =E2=80=9C;transport=3Dtls= =E2=80=9D at SIPit without a client cert - which means we can=E2=80=99t = communicate based on that registration. Cheers, /O > Thanks, > Tolga > =20 > From: Olle E. Johansson [mailto:oej@edvina.net = ]=20 > Sent: Thursday, December 22, 2016 9:08 AM > To: Asveren, Tolga > > Cc: Olle E Johansson >; = Christer Holmberg >; Adam Roach >; SIPCORE >; Ben Campbell > > Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > =20 > On 22 Dec 2016, at 14:50, Asveren, Tolga > wrote: > =20 > Regarding the interest in SIP/UDP/DTLS: > This is mainly based on prospect of larger scalability on server side. = There may/may not be an immediate need to tweak/change things to make = DTLS related processing (hopefully just on the local stack level rather = than on on-the-wire protocol- with some supporting SIP enhancements) = more =E2=80=9Cfailover friendly=E2=80=9D. This issue requires more = analysis/discussion but does not sound unsolvable IMHO. > We will have to solve client connection reuse for both TLS and DTLS = sessions though. Unless you want to have > client certificates on all devices. > =20 > Adam as chair: SIP Client Connection Reuse is something we=E2=80=99ve = disussed under multiple names - =E2=80=9Chalf outbound=E2=80=9D or = =E2=80=9Cwhy is ;transport=3Dtls=E2=80=9D > deprecated=E2=80=9D or =E2=80=9CWhy doesn=E2=80=99t SIP Outbound = happen?=E2=80=9D. Maybe that deserves a milestone. > =20 > /O >=20 > =20 > Thanks, > Tolga > =20 > From: sipcore [mailto:sipcore-bounces@ietf.org = ] On Behalf Of Christer Holmberg > Sent: Thursday, December 22, 2016 7:39 AM > To: Adam Roach >; 'SIPCORE' = > > Cc: Ben Campbell > > Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > Hi, > =20 > I will obviously be actively involved in 4), and I also agree that 5) = should be done as it is a correction. > =20 > As far as the other potential work is concerned, 3) has the highest = priority for me, and I would actively participate in that work. > =20 > I would review 1) and 2), but I would really like to see an individual = draft on 2) before we agree whether to create a milestone for it. For = example, I would like to see some input on WHY to do it, and HOW it is = intended to be deployed etc. How does DTLS fit SIP? What are the = advantages? OR, do we want to specify DTLS-for-SIP simply because DTLS = is =E2=80=9Chot=E2=80=9D? > =20 > Regards, > =20 > Christer > =20 > From: sipcore > on behalf of "adam@nostrum.com = " > > Date: Tuesday 20 December 2016 at 22:27 > To: "sipcore@ietf.org " > > Cc: Ben Campbell > > Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > [as chair] >=20 > Now that we have our new charter approved, I'd like the working group = to have a discussion about the specific work items that we should take = on in the short- to medium-term so that we can revise our milestones = appropriately. Based on recent discussions on the mailing list, the = following topics have some mind-share behind them. What I'd like from = everyone with an interest in any of these topics is to indicate (a) = whether you are willing to actively review and comment on documents on = the topic; and (b) what priority each task has relative to each other: = there are five topics; please indicate a unique priority from one (most = important) to five (least important) for each topic. >=20 > "Happy Eyeballs for SIP" (aka Happy Earballs), currently under = discussion on the list. > "DTLS Transport for SIP", as proposed by Tolga Asveren's recent = messages. > A mechanism for labeling the nature of SIP calls, with = as a likely candidate draft. > Fixing Content-ID in SIP, as discussed in = = , = with as a likely candidate draft. > Clarifications around SIP name-addr, with = as a likely candidate draft >=20 > I will also note that we have already declared consensus on adopting = as a WG document, and will be = adding an associated milestone. I want to take this opportunity to = remind people that the document is in WGLC, and your comments are = strongly encouraged, the earlier the better. >=20 > Please respond before the end of 2016. Thanks! >=20 > Thanks! >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_0DAC25C0-9A7B-4ADC-A04D-A7A2FFF49A1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22 Dec 2016, at 16:34, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Olle,
 
I missed the point about = why =E2=80=9Cpractically possible failover=E2=80=9D needs to be solved = both for TLS/DTLS (I am not arguing it would be good to have a solution = for both) and also what this issue in general has something to do with = client certificates.
Could you provide a bit = more information/clarifications?
 
We=E2=80=99ve= discussed it a number of times both here and on the SIP Forum techwg = mailing list. You can find summaries here:


In short, without SIP = Outbound the client connection can=E2=80=99t be re-used for outbound = requests. Seems like there is a huge
resistance to implement = SIP Outbound. We need a way for the client to allow the server to reuse = the inbound connection
for outbound requests even though = there=E2=80=99s no TLS certificate matching the URI on the client = side.

We=E2=80=99ve had a lot of = clients register with =E2=80=9C;transport=3Dtls=E2=80=9D at SIPit = without a client cert - which means we can=E2=80=99t = communicate
based on that registration.

Cheers,
/O

Thanks,
Tolga
 
From: Olle E. = Johansson [mailto:oej@edvina.net] 
Sent: Thursday, December 22, 2016 = 9:08 AM
To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: Olle E Johansson <oej@edvina.net>; Christer Holmberg <christer.holmberg@ericsson.com>; Adam Roach <adam@nostrum.com>; = SIPCORE <sipcore@ietf.org>; Ben = Campbell <ben@nostrum.com>
Subject: Re: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 
 
On 22 Dec 2016, at = 14:50, Asveren, Tolga <tasveren@sonusnet.com> wrote:
 
Regarding the interest in = SIP/UDP/DTLS:
This is mainly based on = prospect of larger scalability on server side. There may/may not be an = immediate need to tweak/change things to make DTLS related processing = (hopefully just on the local stack level rather than on on-the-wire = protocol- with some supporting SIP enhancements) more =E2=80=9Cfailover = friendly=E2=80=9D. This issue requires more analysis/discussion but does = not sound unsolvable IMHO.
We will have to solve client connection reuse for = both TLS and DTLS sessions though. Unless you want to have
client certificates on all devices.
 
Adam as chair: SIP Client Connection = Reuse is something we=E2=80=99ve disussed under multiple names - =E2=80=9C= half outbound=E2=80=9D or =E2=80=9Cwhy is ;transport=3Dtls=E2=80=9D
deprecated=E2=80=9D or =E2=80=9CWhy doesn=E2=80=99t SIP = Outbound happen?=E2=80=9D. Maybe that deserves a milestone.
 
/O

 
Thanks,
Tolga
 
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: Thursday, December 22, 2016 = 7:39 AM
To: Adam Roach <adam@nostrum.com>; 'SIPCORE' <sipcore@ietf.org>
Cc: Ben = Campbell <ben@nostrum.com>
Subject: Re: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 
Hi,
 
I will obviously be = actively involved in 4), and I also agree that 5) should be done as it = is a correction.
 
As far as the other potential work is concerned, 3) has the = highest priority for me, and I would actively participate in that = work.
 
I would review 1) and 2), but I would really like to see an = individual draft on 2) before we agree whether to create a milestone for = it. For example, I would like to see some input on WHY to do it, and HOW = it is intended to be deployed etc. How does DTLS fit SIP? What are the = advantages? OR, do we want to specify DTLS-for-SIP simply because DTLS = is =E2=80=9Chot=E2=80=9D?
 
Regards,
 
Christer
 
From: sipcore <sipcore-bounces@ietf.org> on behalf of "adam@nostrum.com" <adam@nostrum.com>
Date: Tuesday 20 December = 2016 at 22:27
To: "sipcore@ietf.org" <sipcore@ietf.org>
Cc: Ben = Campbell <ben@nostrum.com>
Subject: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 

[as chair]

Now that we have our new charter approved, I'd = like the working group to have a discussion about the specific work = items that we should take on in the short- to medium-term so that we can = revise our milestones appropriately. Based on recent discussions on the = mailing list, the following topics have some mind-share behind them. = What I'd like from everyone with an interest in any of these topics is = to indicate (a) whether you are willing to actively review and comment = on documents on the topic; and (b) what priority each task has relative = to each other: there are five topics; please indicate a unique priority = from one (most important) to five (least important) for each = topic.

  1. "Happy Eyeballs = for SIP" (aka Happy Earballs), currently under discussion on the = list.
  2. "DTLS Transport for SIP", as proposed = by Tolga Asveren's recent messages.
  3. A mechanism for = labeling the nature of SIP calls, with = <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidate = draft.
  4. Fixing Content-ID in SIP, as discussed = in <https://www.ietf.org/mail-archive/web/sipcore/current/msg07= 245.html>, with <draft-holmberg-sipcore-content-id> = as a likely candidate draft.
  5. Clarifications = around SIP name-addr, with = <draft-sparks-sipcore-name-addr-guidance> as a likely candidate = draft

I will also = note that we have already declared consensus on adopting = <draft-ietf-sipcore-status-unwanted> as a WG document, and will be = adding an associated milestone. I want to take this opportunity to = remind people that the document is in WGLC, and your comments are = strongly encouraged, the earlier the better.

Please respond before the end of 2016. Thanks!

Thanks!

/a
_______________________________________________sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
<= /div>

= --Apple-Mail=_0DAC25C0-9A7B-4ADC-A04D-A7A2FFF49A1A-- From nobody Thu Dec 22 09:08:46 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C33212947B for ; Thu, 22 Dec 2016 09:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 8hww3ZjurMQy for ; Thu, 22 Dec 2016 09:08:41 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0070.outbound.protection.outlook.com [104.47.36.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BD512940C for ; Thu, 22 Dec 2016 09:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qKARJ0KWqhbeZPpXB2A5E8urw953nowAg57MHWFx8sY=; b=Oyq5oFleHGo/j3SeU73E818kTTw8z5E7miGdp9T1CuUlj7lxfKFnHDbs8av5hbRsSoV8k8jm2Erb01W2T8oia4zlSRMwwu+Gh7DQ+j4YhhMQT5M3REAn1GqxNLktfogqiULPJIWNAD+y3g777v8n512YXh6ljY8DcnwkfxRt9hg= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 22 Dec 2016 17:08:38 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.015; Thu, 22 Dec 2016 17:08:38 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv96++N6DRIq/E2cKGNWf6YDKaET6r4AgAAS3iCAAAYCAIAAF0yAgAAGmwCAABLYMA== Date: Thu, 22 Dec 2016 17:08:38 +0000 Message-ID: References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 37e26476-5178-4b60-4db2-08d42a8d2c21 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:i2qw3l4uCffm2Uop19XrHt+ygn0HDOsPNnNPR/IwpfoIusQsQN8mWy9+Z/i5tw6m+/UWtvJEGaetIBiRDqFCLQxY19LfL9KQwgpZ1i2vpE3fBPth/R3XjI+A4v1PhpiB3gpMaYqPIoEysh6HGs6uTd+0WduEK+HvFBgysg1VC8RoTW46CoX1URsKASOQAqJQAxSbKZDqUR7kp11r5a+DJs4ZyJw9eMuCT4kfjirFw9qu5Gf7fOGLtHwxpyHpFyIsCLU56q5ZNfYIyevIvCQvrIyXgza33BFcaqyiaw3FRbT0NUuGtXznPDga011eU9jXiGo7hsHqE4xLbznRbmI/XQrQDxuRurDg56vqFeGn5IUwdIO4OvmjrLhzs/Hy8Vq5+3A9zGeUxJ//+Oaz6lL0MvZB45oms3F/VtFd3o/h5cBn92XKN1vFS7yNPL7UAPfwMoQKG7JFsPTJHYAsMR3eyw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(100405760836317)(178636050973902)(21748063052155)(132712982866762); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(199003)(51914003)(377454003)(24454002)(8676002)(101416001)(189998001)(86362001)(2950100002)(7696004)(6916009)(110136003)(551934003)(6116002)(790700001)(33656002)(3846002)(102836003)(5660300001)(2906002)(74316002)(7736002)(9686002)(7906003)(97736004)(93886004)(68736007)(19609705001)(38730400001)(8936002)(6436002)(81166006)(81156014)(606005)(77096006)(106116001)(4326007)(66066001)(105586002)(99286002)(6506006)(76576001)(92566002)(106356001)(229853002)(3660700001)(122556002)(3280700002)(54356999)(76176999)(50986999)(25786008)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350D22AA44D07FE21369CB0B2920SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 17:08:38.3566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 Archived-At: Cc: Ben Campbell , SIPCORE Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 17:08:45 -0000 --_000_SN2PR03MB2350D22AA44D07FE21369CB0B2920SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCg0KaS0gSSBhZ3JlZSB0aGF0IGNvbm5lY3Rp b24gcmUtdXNlIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBhcyBpdCB3b3VsZCBiZSBhIG5vcm1hdGl2 ZSBjaGFuZ2UuDQppaS0gSXMgaXQgYSBtYW5kYXRlIHRoYXQgbXV0dWFsIGF1dGhlbnRpY2F0aW9u IG5lZWRzIHRvIGJlIHVzZWQgaWYgdHJhbnNwb3J0PXRscz8gSWYgc28sIHRoYXQgd291bGQgcmVx dWlyZSBhbm90aGVyIG5vcm1hdGl2ZSBjaGFuZ2UgdG8gYWxpZ24gd2l0aCBwcmFjdGljYWwgbmVl ZHMuDQppaWktIEkgdGhpbmsgYm90aCBpLS9paS0gYXJlIHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3 YXJkIHRvIGFkZHJlc3MuIFRoZSBtb3JlIGludGVyZXN0aW5nL2NoYWxsZW5naW5nIGFzcGVjdCBp cyBob3cgdG8gZmFpbG92ZXIgRFRMUyBjb25uZWN0aW9ucyB3aXRob3V0IGEgbmVlZCBmb3IgcGVy LXRyYW5zYWN0aW9uIHN0YXRlIHN5bmNocm9uaXphdGlvbiBhbmQgd2l0aCB0aGUgZmV3ZXN0IHJv dW5kLXRyaXBzIHBvc3NpYmxlLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBPbGxlIEUuIEpv aGFuc3NvbiBbbWFpbHRvOm9lakBlZHZpbmEubmV0XQ0KU2VudDogVGh1cnNkYXksIERlY2VtYmVy IDIyLCAyMDE2IDEwOjU1IEFNDQpUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0 LmNvbT4NCkNjOiBPbGxlIEUgSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD47IENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBBZGFtIFJvYWNoIDxhZGFt QG5vc3RydW0uY29tPjsgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz47IEJlbiBDYW1wYmVsbCA8 YmVuQG5vc3RydW0uY29tPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNU RUQ6IFNJUENPUkUgd29yayBhbmQgbWlsZXN0b25lcw0KDQoNCk9uIDIyIERlYyAyMDE2LCBhdCAx NjozNCwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQoNCk9sbGUsDQoNCkkgbWlzc2VkIHRoZSBwb2ludCBh Ym91dCB3aHkg4oCccHJhY3RpY2FsbHkgcG9zc2libGUgZmFpbG92ZXLigJ0gbmVlZHMgdG8gYmUg c29sdmVkIGJvdGggZm9yIFRMUy9EVExTIChJIGFtIG5vdCBhcmd1aW5nIGl0IHdvdWxkIGJlIGdv b2QgdG8gaGF2ZSBhIHNvbHV0aW9uIGZvciBib3RoKSBhbmQgYWxzbyB3aGF0IHRoaXMgaXNzdWUg aW4gZ2VuZXJhbCBoYXMgc29tZXRoaW5nIHRvIGRvIHdpdGggY2xpZW50IGNlcnRpZmljYXRlcy4N CkNvdWxkIHlvdSBwcm92aWRlIGEgYml0IG1vcmUgaW5mb3JtYXRpb24vY2xhcmlmaWNhdGlvbnM/ DQoNCldl4oCZdmUgZGlzY3Vzc2VkIGl0IGEgbnVtYmVyIG9mIHRpbWVzIGJvdGggaGVyZSBhbmQg b24gdGhlIFNJUCBGb3J1bSB0ZWNod2cgbWFpbGluZyBsaXN0LiBZb3UgY2FuIGZpbmQgc3VtbWFy aWVzIGhlcmU6DQoNCmh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQvb2VqL3NpcC1oYWxmLW91dGJv dW5kLXJhbmRvbS1ub3Rlcw0KaHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9vZWovc2lwLXRscy1z ZWN1cml0eS1pbi1hLXBlZXItdG8tcGVlci13b3JsZA0KDQpJbiBzaG9ydCwgd2l0aG91dCBTSVAg T3V0Ym91bmQgdGhlIGNsaWVudCBjb25uZWN0aW9uIGNhbuKAmXQgYmUgcmUtdXNlZCBmb3Igb3V0 Ym91bmQgcmVxdWVzdHMuIFNlZW1zIGxpa2UgdGhlcmUgaXMgYSBodWdlDQpyZXNpc3RhbmNlIHRv IGltcGxlbWVudCBTSVAgT3V0Ym91bmQuIFdlIG5lZWQgYSB3YXkgZm9yIHRoZSBjbGllbnQgdG8g YWxsb3cgdGhlIHNlcnZlciB0byByZXVzZSB0aGUgaW5ib3VuZCBjb25uZWN0aW9uDQpmb3Igb3V0 Ym91bmQgcmVxdWVzdHMgZXZlbiB0aG91Z2ggdGhlcmXigJlzIG5vIFRMUyBjZXJ0aWZpY2F0ZSBt YXRjaGluZyB0aGUgVVJJIG9uIHRoZSBjbGllbnQgc2lkZS4NCg0KV2XigJl2ZSBoYWQgYSBsb3Qg b2YgY2xpZW50cyByZWdpc3RlciB3aXRoIOKAnDt0cmFuc3BvcnQ9dGxz4oCdIGF0IFNJUGl0IHdp dGhvdXQgYSBjbGllbnQgY2VydCAtIHdoaWNoIG1lYW5zIHdlIGNhbuKAmXQgY29tbXVuaWNhdGUN CmJhc2VkIG9uIHRoYXQgcmVnaXN0cmF0aW9uLg0KDQpDaGVlcnMsDQovTw0KDQoNClRoYW5rcywN ClRvbGdhDQoNCkZyb206IE9sbGUgRS4gSm9oYW5zc29uIFttYWlsdG86b2VqQGVkdmluYS5uZXRd DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjIsIDIwMTYgOTowOCBBTQ0KVG86IEFzdmVyZW4s IFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNv bT4+DQpDYzogT2xsZSBFIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ8bWFpbHRvOm9lakBlZHZp bmEubmV0Pj47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBBZGFtIFJvYWNoIDxh ZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj47IFNJUENPUkUgPHNpcGNv cmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+PjsgQmVuIENhbXBiZWxsIDxiZW5A bm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+DQpTdWJqZWN0OiBSZTogW3NpcGNv cmVdIFJFU1BPTlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzDQoNCg0K T24gMjIgRGVjIDIwMTYsIGF0IDE0OjUwLCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNu ZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+PiB3cm90ZToNCg0KUmVnYXJkaW5n IHRoZSBpbnRlcmVzdCBpbiBTSVAvVURQL0RUTFM6DQpUaGlzIGlzIG1haW5seSBiYXNlZCBvbiBw cm9zcGVjdCBvZiBsYXJnZXIgc2NhbGFiaWxpdHkgb24gc2VydmVyIHNpZGUuIFRoZXJlIG1heS9t YXkgbm90IGJlIGFuIGltbWVkaWF0ZSBuZWVkIHRvIHR3ZWFrL2NoYW5nZSB0aGluZ3MgdG8gbWFr ZSBEVExTIHJlbGF0ZWQgcHJvY2Vzc2luZyAoaG9wZWZ1bGx5IGp1c3Qgb24gdGhlIGxvY2FsIHN0 YWNrIGxldmVsIHJhdGhlciB0aGFuIG9uIG9uLXRoZS13aXJlIHByb3RvY29sLSB3aXRoIHNvbWUg c3VwcG9ydGluZyBTSVAgZW5oYW5jZW1lbnRzKSBtb3JlIOKAnGZhaWxvdmVyIGZyaWVuZGx54oCd LiBUaGlzIGlzc3VlIHJlcXVpcmVzIG1vcmUgYW5hbHlzaXMvZGlzY3Vzc2lvbiBidXQgZG9lcyBu b3Qgc291bmQgdW5zb2x2YWJsZSBJTUhPLg0KV2Ugd2lsbCBoYXZlIHRvIHNvbHZlIGNsaWVudCBj b25uZWN0aW9uIHJldXNlIGZvciBib3RoIFRMUyBhbmQgRFRMUyBzZXNzaW9ucyB0aG91Z2guIFVu bGVzcyB5b3Ugd2FudCB0byBoYXZlDQpjbGllbnQgY2VydGlmaWNhdGVzIG9uIGFsbCBkZXZpY2Vz Lg0KDQpBZGFtIGFzIGNoYWlyOiBTSVAgQ2xpZW50IENvbm5lY3Rpb24gUmV1c2UgaXMgc29tZXRo aW5nIHdl4oCZdmUgZGlzdXNzZWQgdW5kZXIgbXVsdGlwbGUgbmFtZXMgLSDigJxoYWxmIG91dGJv dW5k4oCdIG9yIOKAnHdoeSBpcyA7dHJhbnNwb3J0PXRsc+KAnQ0KZGVwcmVjYXRlZOKAnSBvciDi gJxXaHkgZG9lc27igJl0IFNJUCBPdXRib3VuZCBoYXBwZW4/4oCdLiBNYXliZSB0aGF0IGRlc2Vy dmVzIGEgbWlsZXN0b25lLg0KDQovTw0KDQoNCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogc2lw Y29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlz dGVyIEhvbG1iZXJnDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjIsIDIwMTYgNzozOSBBTQ0K VG86IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+ PjsgJ1NJUENPUkUnIDxzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPj4N CkNjOiBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3RydW0uY29t Pj4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gUkVTUE9OU0UgUkVRVUVTVEVEOiBTSVBDT1JFIHdv cmsgYW5kIG1pbGVzdG9uZXMNCg0KSGksDQoNCkkgd2lsbCBvYnZpb3VzbHkgYmUgYWN0aXZlbHkg aW52b2x2ZWQgaW4gNCksIGFuZCBJIGFsc28gYWdyZWUgdGhhdCA1KSBzaG91bGQgYmUgZG9uZSBh cyBpdCBpcyBhIGNvcnJlY3Rpb24uDQoNCkFzIGZhciBhcyB0aGUgb3RoZXIgcG90ZW50aWFsIHdv cmsgaXMgY29uY2VybmVkLCAzKSBoYXMgdGhlIGhpZ2hlc3QgcHJpb3JpdHkgZm9yIG1lLCBhbmQg SSB3b3VsZCBhY3RpdmVseSBwYXJ0aWNpcGF0ZSBpbiB0aGF0IHdvcmsuDQoNCkkgd291bGQgcmV2 aWV3IDEpIGFuZCAyKSwgYnV0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8gc2VlIGFuIGluZGl2aWR1 YWwgZHJhZnQgb24gMikgYmVmb3JlIHdlIGFncmVlIHdoZXRoZXIgdG8gY3JlYXRlIGEgbWlsZXN0 b25lIGZvciBpdC4gRm9yIGV4YW1wbGUsIEkgd291bGQgbGlrZSB0byBzZWUgc29tZSBpbnB1dCBv biBXSFkgdG8gZG8gaXQsIGFuZCBIT1cgaXQgaXMgaW50ZW5kZWQgdG8gYmUgZGVwbG95ZWQgZXRj LiBIb3cgZG9lcyBEVExTIGZpdCBTSVA/IFdoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzPyBPUiwgZG8g d2Ugd2FudCB0byBzcGVjaWZ5IERUTFMtZm9yLVNJUCBzaW1wbHkgYmVjYXVzZSBEVExTIGlzIOKA nGhvdOKAnT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogc2lwY29yZSA8c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgImFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+IiA8YWRh bUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+DQpEYXRlOiBUdWVzZGF5IDIw IERlY2VtYmVyIDIwMTYgYXQgMjI6MjcNClRvOiAic2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lw Y29yZUBpZXRmLm9yZz4iIDxzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3Jn Pj4NCkNjOiBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3RydW0u Y29tPj4NClN1YmplY3Q6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUgd29y ayBhbmQgbWlsZXN0b25lcw0KDQpbYXMgY2hhaXJdDQoNCk5vdyB0aGF0IHdlIGhhdmUgb3VyIG5l dyBjaGFydGVyIGFwcHJvdmVkLCBJJ2QgbGlrZSB0aGUgd29ya2luZyBncm91cCB0byBoYXZlIGEg ZGlzY3Vzc2lvbiBhYm91dCB0aGUgc3BlY2lmaWMgd29yayBpdGVtcyB0aGF0IHdlIHNob3VsZCB0 YWtlIG9uIGluIHRoZSBzaG9ydC0gdG8gbWVkaXVtLXRlcm0gc28gdGhhdCB3ZSBjYW4gcmV2aXNl IG91ciBtaWxlc3RvbmVzIGFwcHJvcHJpYXRlbHkuIEJhc2VkIG9uIHJlY2VudCBkaXNjdXNzaW9u cyBvbiB0aGUgbWFpbGluZyBsaXN0LCB0aGUgZm9sbG93aW5nIHRvcGljcyBoYXZlIHNvbWUgbWlu ZC1zaGFyZSBiZWhpbmQgdGhlbS4gV2hhdCBJJ2QgbGlrZSBmcm9tIGV2ZXJ5b25lIHdpdGggYW4g aW50ZXJlc3QgaW4gYW55IG9mIHRoZXNlIHRvcGljcyBpcyB0byBpbmRpY2F0ZSAoYSkgd2hldGhl ciB5b3UgYXJlIHdpbGxpbmcgdG8gYWN0aXZlbHkgcmV2aWV3IGFuZCBjb21tZW50IG9uIGRvY3Vt ZW50cyBvbiB0aGUgdG9waWM7IGFuZCAoYikgd2hhdCBwcmlvcml0eSBlYWNoIHRhc2sgaGFzIHJl bGF0aXZlIHRvIGVhY2ggb3RoZXI6IHRoZXJlIGFyZSBmaXZlIHRvcGljczsgcGxlYXNlIGluZGlj YXRlIGEgdW5pcXVlIHByaW9yaXR5IGZyb20gb25lIChtb3N0IGltcG9ydGFudCkgdG8gZml2ZSAo bGVhc3QgaW1wb3J0YW50KSBmb3IgZWFjaCB0b3BpYy4NCg0KICAxLiAgIkhhcHB5IEV5ZWJhbGxz IGZvciBTSVAiIChha2EgSGFwcHkgRWFyYmFsbHMpLCBjdXJyZW50bHkgdW5kZXIgZGlzY3Vzc2lv biBvbiB0aGUgbGlzdC4NCiAgMi4gICJEVExTIFRyYW5zcG9ydCBmb3IgU0lQIiwgYXMgcHJvcG9z ZWQgYnkgVG9sZ2EgQXN2ZXJlbidzIHJlY2VudCBtZXNzYWdlcy4NCiAgMy4gIEEgbWVjaGFuaXNt IGZvciBsYWJlbGluZyB0aGUgbmF0dXJlIG9mIFNJUCBjYWxscywgd2l0aCA8ZHJhZnQtc2NodWx6 cmlubmUtc2lwY29yZS1jYWxsaW5mby1zcGFtPiBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQu DQogIDQuICBGaXhpbmcgQ29udGVudC1JRCBpbiBTSVAsIGFzIGRpc2N1c3NlZCBpbiA8aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDcyNDUu aHRtbD48aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJl bnQvbXNnMDcyNDUuaHRtbD4sIHdpdGggPGRyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtY29udGVudC1p ZD4gYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0Lg0KICA1LiAgQ2xhcmlmaWNhdGlvbnMgYXJv dW5kIFNJUCBuYW1lLWFkZHIsIHdpdGggPGRyYWZ0LXNwYXJrcy1zaXBjb3JlLW5hbWUtYWRkci1n dWlkYW5jZT4gYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0DQoNCkkgd2lsbCBhbHNvIG5vdGUg dGhhdCB3ZSBoYXZlIGFscmVhZHkgZGVjbGFyZWQgY29uc2Vuc3VzIG9uIGFkb3B0aW5nIDxkcmFm dC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkPiBhcyBhIFdHIGRvY3VtZW50LCBhbmQgd2ls bCBiZSBhZGRpbmcgYW4gYXNzb2NpYXRlZCBtaWxlc3RvbmUuIEkgd2FudCB0byB0YWtlIHRoaXMg b3Bwb3J0dW5pdHkgdG8gcmVtaW5kIHBlb3BsZSB0aGF0IHRoZSBkb2N1bWVudCBpcyBpbiBXR0xD LCBhbmQgeW91ciBjb21tZW50cyBhcmUgc3Ryb25nbHkgZW5jb3VyYWdlZCwgdGhlIGVhcmxpZXIg dGhlIGJldHRlci4NCg0KUGxlYXNlIHJlc3BvbmQgYmVmb3JlIHRoZSBlbmQgb2YgMjAxNi4gVGhh bmtzIQ0KDQpUaGFua3MhDQoNCi9hDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmc8bWFp bHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCg0K --_000_SN2PR03MB2350D22AA44D07FE21369CB0B2920SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRl ZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjE3MDY3MTYxMTI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NjU1MzAx NzY7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+aS0gSSBhZ3JlZSB0aGF0IGNvbm5lY3Rpb24gcmUtdXNlIG5lZWRzIHRvIGJlIGFkZHJlc3Nl ZCBhcyBpdCB3b3VsZCBiZSBhIG5vcm1hdGl2ZSBjaGFuZ2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlpLSBJcyBpdCBhIG1h bmRhdGUgdGhhdCBtdXR1YWwgYXV0aGVudGljYXRpb24gbmVlZHMgdG8gYmUgdXNlZCBpZiB0cmFu c3BvcnQ9dGxzPyBJZiBzbywgdGhhdCB3b3VsZCByZXF1aXJlIGFub3RoZXIgbm9ybWF0aXZlIGNo YW5nZSB0byBhbGlnbiB3aXRoIHByYWN0aWNhbCBuZWVkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlpaS0gSSB0aGluayBib3Ro IGktL2lpLSBhcmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQgdG8gYWRkcmVzcy4gVGhlIG1v cmUgaW50ZXJlc3RpbmcvY2hhbGxlbmdpbmcgYXNwZWN0IGlzIGhvdyB0byBmYWlsb3ZlciBEVExT IGNvbm5lY3Rpb25zIHdpdGhvdXQgYSBuZWVkIGZvciBwZXItdHJhbnNhY3Rpb24NCiBzdGF0ZSBz eW5jaHJvbml6YXRpb24gYW5kIHdpdGggdGhlIGZld2VzdCByb3VuZC10cmlwcyBwb3NzaWJsZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT2xsZSBFLiBKb2hhbnNzb24gW21haWx0bzpv ZWpAZWR2aW5hLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgMjIs IDIwMTYgMTA6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhICZsdDt0YXN2ZXJl bkBzb251c25ldC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBPbGxlIEUgSm9oYW5zc29uICZsdDtv ZWpAZWR2aW5hLm5ldCZndDs7IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20mZ3Q7OyBBZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0Ozsg U0lQQ09SRSAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs7IEJlbiBDYW1wYmVsbCAmbHQ7YmVuQG5v c3RydW0uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIFJFU1BPTlNF IFJFUVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgRGVjIDIwMTYsIGF0IDE2OjM0 LCBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNv bSI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9sbGUsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgbWlzc2VkIHRoZSBwb2lu dCBhYm91dCB3aHkg4oCccHJhY3RpY2FsbHkgcG9zc2libGUgZmFpbG92ZXLigJ0gbmVlZHMgdG8g YmUgc29sdmVkIGJvdGggZm9yIFRMUy9EVExTIChJIGFtIG5vdCBhcmd1aW5nIGl0IHdvdWxkIGJl IGdvb2QgdG8gaGF2ZSBhIHNvbHV0aW9uIGZvciBib3RoKSBhbmQgYWxzbyB3aGF0DQogdGhpcyBp c3N1ZSBpbiBnZW5lcmFsIGhhcyBzb21ldGhpbmcgdG8gZG8gd2l0aCBjbGllbnQgY2VydGlmaWNh dGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q291bGQgeW91IHByb3ZpZGUgYSBiaXQgbW9yZSBpbmZv cm1hdGlvbi9jbGFyaWZpY2F0aW9ucz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZeKAmXZlIGRpc2N1c3NlZCBpdCBhIG51bWJlciBvZiB0aW1lcyBib3RoIGhl cmUgYW5kIG9uIHRoZSBTSVAgRm9ydW0gdGVjaHdnIG1haWxpbmcgbGlzdC4gWW91IGNhbiBmaW5k IHN1bW1hcmllcyBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L29lai9zaXAt aGFsZi1vdXRib3VuZC1yYW5kb20tbm90ZXMiPmh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQvb2Vq L3NpcC1oYWxmLW91dGJvdW5kLXJhbmRvbS1ub3RlczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuc2xpZGVz aGFyZS5uZXQvb2VqL3NpcC10bHMtc2VjdXJpdHktaW4tYS1wZWVyLXRvLXBlZXItd29ybGQiPmh0 dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQvb2VqL3NpcC10bHMtc2VjdXJpdHktaW4tYS1wZWVyLXRv LXBlZXItd29ybGQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkluIHNob3J0LCB3aXRob3V0IFNJUCBPdXRib3VuZCB0aGUgY2xpZW50IGNv bm5lY3Rpb24gY2Fu4oCZdCBiZSByZS11c2VkIGZvciBvdXRib3VuZCByZXF1ZXN0cy4gU2VlbXMg bGlrZSB0aGVyZSBpcyBhIGh1Z2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnJlc2lzdGFuY2UgdG8gaW1wbGVtZW50IFNJUCBPdXRib3VuZC4gV2Ug bmVlZCBhIHdheSBmb3IgdGhlIGNsaWVudCB0byBhbGxvdyB0aGUgc2VydmVyIHRvIHJldXNlIHRo ZSBpbmJvdW5kIGNvbm5lY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmZvciBvdXRib3VuZCByZXF1ZXN0cyBldmVuIHRob3VnaCB0aGVyZeKA mXMgbm8gVExTIGNlcnRpZmljYXRlIG1hdGNoaW5nIHRoZSBVUkkgb24gdGhlIGNsaWVudCBzaWRl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZeKAmXZlIGhhZCBhIGxvdCBvZiBjbGllbnRzIHJlZ2lzdGVyIHdpdGgg4oCcO3RyYW5zcG9ydD10 bHPigJ0gYXQgU0lQaXQgd2l0aG91dCBhIGNsaWVudCBjZXJ0IC0gd2hpY2ggbWVhbnMgd2UgY2Fu 4oCZdCBjb21tdW5pY2F0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YmFzZWQgb24gdGhhdCByZWdpc3RyYXRpb24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9PPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9sbGUNCiBFLiBKb2hhbnNzb24gWzxhIGhyZWY9Im1h aWx0bzpvZWpAZWR2aW5hLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOm9l akBlZHZpbmEubmV0PC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgRGVjZW1iZXIgMjIsIDIwMTYgOTow OCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+QXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBz b251c25ldC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRhc3ZlcmVuQHNvbnVzbmV0 LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+T2xsZSBFIEpvaGFuc3NvbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9lakBlZHZpbmEubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5vZWpAZWR2 aW5hLm5ldDwvc3Bhbj48L2E+Jmd0OzsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+Jmd0OzsNCiBB ZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+YWRhbUBub3N0cnVtLmNvbTwvc3Bhbj48L2E+Jmd0OzsgU0lQQ09S RSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs7IEJlbiBDYW1wYmVsbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBub3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+YmVuQG5vc3RydW0uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbc2lw Y29yZV0gUkVTUE9OU0UgUkVRVUVTVEVEOiBTSVBDT1JFIHdvcmsgYW5kIG1pbGVzdG9uZXM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMiBEZWMgMjAxNiwgYXQgMTQ6 NTAsIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50YXN2ZXJlbkBzb251c25ldC5jb208L3Nw YW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJl Z2FyZGluZyB0aGUgaW50ZXJlc3QgaW4gU0lQL1VEUC9EVExTOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VGhpcyBpcyBtYWlubHkgYmFzZWQgb24gcHJvc3BlY3Qgb2YgbGFyZ2Vy IHNjYWxhYmlsaXR5IG9uIHNlcnZlciBzaWRlLiBUaGVyZSBtYXkvbWF5IG5vdCBiZSBhbiBpbW1l ZGlhdGUgbmVlZCB0byB0d2Vhay9jaGFuZ2UgdGhpbmdzIHRvIG1ha2UgRFRMUyByZWxhdGVkIHBy b2Nlc3NpbmcgKGhvcGVmdWxseQ0KIGp1c3Qgb24gdGhlIGxvY2FsIHN0YWNrIGxldmVsIHJhdGhl ciB0aGFuIG9uIG9uLXRoZS13aXJlIHByb3RvY29sLSB3aXRoIHNvbWUgc3VwcG9ydGluZyBTSVAg ZW5oYW5jZW1lbnRzKSBtb3JlIOKAnGZhaWxvdmVyIGZyaWVuZGx54oCdLiBUaGlzIGlzc3VlIHJl cXVpcmVzIG1vcmUgYW5hbHlzaXMvZGlzY3Vzc2lvbiBidXQgZG9lcyBub3Qgc291bmQgdW5zb2x2 YWJsZSBJTUhPLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB3aWxsIGhhdmUg dG8gc29sdmUgY2xpZW50IGNvbm5lY3Rpb24gcmV1c2UgZm9yIGJvdGggVExTIGFuZCBEVExTIHNl c3Npb25zIHRob3VnaC4gVW5sZXNzIHlvdSB3YW50IHRvIGhhdmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNsaWVudCBj ZXJ0aWZpY2F0ZXMgb24gYWxsIGRldmljZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFk YW0gYXMgY2hhaXI6IFNJUCBDbGllbnQgQ29ubmVjdGlvbiBSZXVzZSBpcyBzb21ldGhpbmcgd2Xi gJl2ZSBkaXN1c3NlZCB1bmRlciBtdWx0aXBsZSBuYW1lcyAtIOKAnGhhbGYgb3V0Ym91bmTigJ0g b3Ig4oCcd2h5IGlzIDt0cmFuc3BvcnQ9dGxz4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kZXByZWNhdGVk4oCdIG9y IOKAnFdoeSBkb2VzbuKAmXQgU0lQIE91dGJvdW5kIGhhcHBlbj/igJ0uIE1heWJlIHRoYXQgZGVz ZXJ2ZXMgYSBtaWxlc3RvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9PPGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnNpcGNvcmUNCiBbPGEgaHJlZj0ibWFpbHRvOnNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRv OnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkNocmlzdGVyIEhvbG1iZXJn PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlRodXJzZGF5LCBEZWNlbWJlciAyMiwgMjAxNiA3OjM5IEFNPGJyPg0KPGI+VG86 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5BZGFt IFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+YWRhbUBub3N0cnVtLmNvbTwvc3Bhbj48L2E+Jmd0OzsgJ1NJUENPUkUn ICZsdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+c2lwY29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QmVuIENhbXBi ZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5iZW5Abm9zdHJ1bS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6 IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUgd29yayBhbmQgbWlsZXN0b25l czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5JIHdpbGwgb2J2aW91c2x5IGJlIGFjdGl2ZWx5IGludm9sdmVkIGluIDQp LCBhbmQgSSBhbHNvIGFncmVlIHRoYXQgNSkgc2hvdWxkIGJlIGRvbmUgYXMgaXQgaXMgYSBjb3Jy ZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5B cyBmYXIgYXMgdGhlIG90aGVyIHBvdGVudGlhbCB3b3JrIGlzIGNvbmNlcm5lZCwgMykgaGFzIHRo ZSBoaWdoZXN0IHByaW9yaXR5IGZvciBtZSwgYW5kIEkgd291bGQgYWN0aXZlbHkgcGFydGljaXBh dGUgaW4gdGhhdCB3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JIHdvdWxkIHJldmlldyAxKSBhbmQgMiksIGJ1dCBJIHdvdWxkIHJlYWxseSBsaWtl IHRvIHNlZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IG9uIDIpIGJlZm9yZSB3ZSBhZ3JlZSB3aGV0aGVy IHRvIGNyZWF0ZSBhIG1pbGVzdG9uZSBmb3IgaXQuIEZvciBleGFtcGxlLCBJIHdvdWxkIGxpa2Ug dG8gc2VlIHNvbWUNCiBpbnB1dCBvbiBXSFkgdG8gZG8gaXQsIGFuZCBIT1cgaXQgaXMgaW50ZW5k ZWQgdG8gYmUgZGVwbG95ZWQgZXRjLiBIb3cgZG9lcyBEVExTIGZpdCBTSVA/IFdoYXQgYXJlIHRo ZSBhZHZhbnRhZ2VzPyBPUiwgZG8gd2Ugd2FudCB0byBzcGVjaWZ5IERUTFMtZm9yLVNJUCBzaW1w bHkgYmVjYXVzZSBEVExTIGlzIOKAnGhvdOKAnT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+c2lwY29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2lwY29yZS1ib3VuY2VzQGlldGYu b3JnPC9zcGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mICZxdW90OzxhIGhyZWY9Im1haWx0bzph ZGFtQG5vc3RydW0uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGFtQG5vc3RydW0u Y29tPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29t Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGFtQG5vc3RydW0uY29tPC9zcGFuPjwvYT4m Z3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPlR1ZXNkYXkgMjAgRGVjZW1iZXIgMjAxNiBhdCAyMjoyNzxicj4NCjxiPlRv OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNpcGNvcmVA aWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJlbkBub3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVuQG5v c3RydW0uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPltzaXBjb3JlXSBSRVNQT05TRSBS RVFVRVNURUQ6IFNJUENPUkUgd29yayBhbmQgbWlsZXN0b25lczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W2FzIGNo YWlyXTxicj4NCjxicj4NCk5vdyB0aGF0IHdlIGhhdmUgb3VyIG5ldyBjaGFydGVyIGFwcHJvdmVk LCBJJ2QgbGlrZSB0aGUgd29ya2luZyBncm91cCB0byBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91dCB0 aGUgc3BlY2lmaWMgd29yayBpdGVtcyB0aGF0IHdlIHNob3VsZCB0YWtlIG9uIGluIHRoZSBzaG9y dC0gdG8gbWVkaXVtLXRlcm0gc28gdGhhdCB3ZSBjYW4gcmV2aXNlIG91ciBtaWxlc3RvbmVzIGFw cHJvcHJpYXRlbHkuIEJhc2VkIG9uIHJlY2VudCBkaXNjdXNzaW9ucyBvbiB0aGUNCiBtYWlsaW5n IGxpc3QsIHRoZSBmb2xsb3dpbmcgdG9waWNzIGhhdmUgc29tZSBtaW5kLXNoYXJlIGJlaGluZCB0 aGVtLiBXaGF0IEknZCBsaWtlIGZyb20gZXZlcnlvbmUgd2l0aCBhbiBpbnRlcmVzdCBpbiBhbnkg b2YgdGhlc2UgdG9waWNzIGlzIHRvIGluZGljYXRlIChhKSB3aGV0aGVyIHlvdSBhcmUgd2lsbGlu ZyB0byBhY3RpdmVseSByZXZpZXcgYW5kIGNvbW1lbnQgb24gZG9jdW1lbnRzIG9uIHRoZSB0b3Bp YzsgYW5kIChiKSB3aGF0IHByaW9yaXR5DQogZWFjaCB0YXNrIGhhcyByZWxhdGl2ZSB0byBlYWNo IG90aGVyOiB0aGVyZSBhcmUgZml2ZSB0b3BpY3M7IHBsZWFzZSBpbmRpY2F0ZSBhIHVuaXF1ZSBw cmlvcml0eSBmcm9tIG9uZSAobW9zdCBpbXBvcnRhbnQpIHRvIGZpdmUgKGxlYXN0IGltcG9ydGFu dCkgZm9yIGVhY2ggdG9waWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtIYXBw eSBFeWViYWxscyBmb3IgU0lQJnF1b3Q7IChha2EgSGFwcHkgRWFyYmFsbHMpLCBjdXJyZW50bHkg dW5kZXIgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC48L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+JnF1b3Q7RFRMUyBUcmFuc3BvcnQgZm9yIFNJUCZxdW90OywgYXMgcHJvcG9zZWQg YnkgVG9sZ2EgQXN2ZXJlbidzIHJlY2VudCBtZXNzYWdlcy48L3NwYW4+PG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+QSBtZWNoYW5pc20gZm9yIGxhYmVsaW5nIHRoZSBuYXR1cmUgb2YgU0lQ IGNhbGxzLCB3aXRoICZsdDtkcmFmdC1zY2h1bHpyaW5uZS1zaXBjb3JlLWNhbGxpbmZvLXNwYW0m Z3Q7IGFzIGEgbGlrZWx5IGNhbmRpZGF0ZSBkcmFmdC48L3NwYW4+PG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Rml4aW5nIENvbnRlbnQtSUQgaW4gU0lQLCBhcyBkaXNjdXNzZWQgaW48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDcy NDUuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O2h0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzA3MjQ1Lmh0bWwmZ3Q7PC9z cGFuPjwvYT4sDQogd2l0aCAmbHQ7ZHJhZnQtaG9sbWJlcmctc2lwY29yZS1jb250ZW50LWlkJmd0 OyBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkNsYXJpZmljYXRpb25zIGFyb3VuZCBTSVAgbmFtZS1hZGRyLCB3aXRoICZsdDtk cmFmdC1zcGFya3Mtc2lwY29yZS1uYW1lLWFkZHItZ3VpZGFuY2UmZ3Q7IGFzIGEgbGlrZWx5IGNh bmRpZGF0ZSBkcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpJIHdpbGwgYWxzbyBu b3RlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGRlY2xhcmVkIGNvbnNlbnN1cyBvbiBhZG9wdGluZyAm bHQ7ZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZCZndDsgYXMgYSBXRyBkb2N1bWVu dCwgYW5kIHdpbGwgYmUgYWRkaW5nIGFuIGFzc29jaWF0ZWQgbWlsZXN0b25lLiBJIHdhbnQgdG8g dGFrZSB0aGlzIG9wcG9ydHVuaXR5IHRvIHJlbWluZCBwZW9wbGUgdGhhdCB0aGUgZG9jdW1lbnQg aXMgaW4gV0dMQywgYW5kIHlvdXIgY29tbWVudHMNCiBhcmUgc3Ryb25nbHkgZW5jb3VyYWdlZCwg dGhlIGVhcmxpZXIgdGhlIGJldHRlci48YnI+DQo8YnI+DQpQbGVhc2UgcmVzcG9uZCBiZWZvcmUg dGhlIGVuZCBvZiAyMDE2LiBUaGFua3MhPGJyPg0KPGJyPg0KVGhhbmtzITxicj4NCjxicj4NCi9h PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3Jl IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5zaXBjb3JlQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_SN2PR03MB2350D22AA44D07FE21369CB0B2920SN2PR03MB2350namp_-- From nobody Thu Dec 22 09:17:14 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B913A12965F for ; Thu, 22 Dec 2016 09:17:11 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5mlV7_PYAx4i for ; Thu, 22 Dec 2016 09:17:08 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EE3129530 for ; Thu, 22 Dec 2016 09:17:07 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 693F8702E; Thu, 22 Dec 2016 18:16:48 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_06D6E694-1B7E-49D4-BD0A-BD8B6E53056C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 22 Dec 2016 18:16:32 +0100 Message-Id: References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ben Campbell , SIPCORE , Olle E Johansson Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 17:17:12 -0000 --Apple-Mail=_06D6E694-1B7E-49D4-BD0A-BD8B6E53056C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Dec 2016, at 18:08, Asveren, Tolga = wrote: >=20 > Thanks for the clarification. > =20 > i- I agree that connection re-use needs to be addressed as it would be = a normative change. > ii- Is it a mandate that mutual authentication needs to be used if = transport=3Dtls? If so, that would require another normative change to = align with practical needs. The URI for the target and the cert for the UA server needs to match. = It=E2=80=99s not mutual - two certs in the same TLS session, but that = would also be one solution (there is a RFC for that). SIP Outbound permits reuse of = the incoming connection and thus avoids this particular problem. > iii- I think both i-/ii- are relatively straightforward to address. = The more interesting/challenging aspect is how to failover DTLS = connections without a need for per-transaction state synchronization and = with the fewest round-trips possible. Connection reuse needs to be handled separately and needs to be = something that is way more easy to implement than SIP outbound. We need something we can easily test and get it done soon, as I want = more TLS on the SIP networks out there :-) The current way to handle this is connection reuse that breaks the RFCs, = we have that implementation in Kamailio. If there is an open socket, TLS or TCP, we prefer to use it to make = things work. I would love for this to be RFC compliant :-) /O > =20 > Thanks, > Tolga > =20 > From: Olle E. Johansson [mailto:oej@edvina.net = ]=20 > Sent: Thursday, December 22, 2016 10:55 AM > To: Asveren, Tolga > > Cc: Olle E Johansson >; = Christer Holmberg >; Adam Roach >; SIPCORE >; Ben Campbell > > Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > =20 > On 22 Dec 2016, at 16:34, Asveren, Tolga > wrote: > =20 > Olle, > =20 > I missed the point about why =E2=80=9Cpractically possible failover=E2=80= =9D needs to be solved both for TLS/DTLS (I am not arguing it would be = good to have a solution for both) and also what this issue in general = has something to do with client certificates. > Could you provide a bit more information/clarifications? > =20 > We=E2=80=99ve discussed it a number of times both here and on the SIP = Forum techwg mailing list. You can find summaries here: > =20 > http://www.slideshare.net/oej/sip-half-outbound-random-notes = > http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world = > =20 > In short, without SIP Outbound the client connection can=E2=80=99t be = re-used for outbound requests. Seems like there is a huge > resistance to implement SIP Outbound. We need a way for the client to = allow the server to reuse the inbound connection > for outbound requests even though there=E2=80=99s no TLS certificate = matching the URI on the client side. > =20 > We=E2=80=99ve had a lot of clients register with =E2=80=9C;transport=3Dt= ls=E2=80=9D at SIPit without a client cert - which means we can=E2=80=99t = communicate > based on that registration. > =20 > Cheers, > /O >=20 >=20 > Thanks, > Tolga > =20 > From: Olle E. Johansson [mailto:oej@edvina.net = ]=20 > Sent: Thursday, December 22, 2016 9:08 AM > To: Asveren, Tolga > > Cc: Olle E Johansson >; = Christer Holmberg >; Adam Roach >; SIPCORE >; Ben Campbell > > Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > =20 > On 22 Dec 2016, at 14:50, Asveren, Tolga > wrote: > =20 > Regarding the interest in SIP/UDP/DTLS: > This is mainly based on prospect of larger scalability on server side. = There may/may not be an immediate need to tweak/change things to make = DTLS related processing (hopefully just on the local stack level rather = than on on-the-wire protocol- with some supporting SIP enhancements) = more =E2=80=9Cfailover friendly=E2=80=9D. This issue requires more = analysis/discussion but does not sound unsolvable IMHO. > We will have to solve client connection reuse for both TLS and DTLS = sessions though. Unless you want to have > client certificates on all devices. > =20 > Adam as chair: SIP Client Connection Reuse is something we=E2=80=99ve = disussed under multiple names - =E2=80=9Chalf outbound=E2=80=9D or = =E2=80=9Cwhy is ;transport=3Dtls=E2=80=9D > deprecated=E2=80=9D or =E2=80=9CWhy doesn=E2=80=99t SIP Outbound = happen?=E2=80=9D. Maybe that deserves a milestone. > =20 > /O >=20 >=20 > =20 > Thanks, > Tolga > =20 > From: sipcore [mailto:sipcore-bounces@ietf.org = ] On Behalf Of Christer Holmberg > Sent: Thursday, December 22, 2016 7:39 AM > To: Adam Roach >; 'SIPCORE' = > > Cc: Ben Campbell > > Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > Hi, > =20 > I will obviously be actively involved in 4), and I also agree that 5) = should be done as it is a correction. > =20 > As far as the other potential work is concerned, 3) has the highest = priority for me, and I would actively participate in that work. > =20 > I would review 1) and 2), but I would really like to see an individual = draft on 2) before we agree whether to create a milestone for it. For = example, I would like to see some input on WHY to do it, and HOW it is = intended to be deployed etc. How does DTLS fit SIP? What are the = advantages? OR, do we want to specify DTLS-for-SIP simply because DTLS = is =E2=80=9Chot=E2=80=9D? > =20 > Regards, > =20 > Christer > =20 > From: sipcore > on behalf of "adam@nostrum.com = " > > Date: Tuesday 20 December 2016 at 22:27 > To: "sipcore@ietf.org " > > Cc: Ben Campbell > > Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > =20 > [as chair] >=20 > Now that we have our new charter approved, I'd like the working group = to have a discussion about the specific work items that we should take = on in the short- to medium-term so that we can revise our milestones = appropriately. Based on recent discussions on the mailing list, the = following topics have some mind-share behind them. What I'd like from = everyone with an interest in any of these topics is to indicate (a) = whether you are willing to actively review and comment on documents on = the topic; and (b) what priority each task has relative to each other: = there are five topics; please indicate a unique priority from one (most = important) to five (least important) for each topic. >=20 > "Happy Eyeballs for SIP" (aka Happy Earballs), currently under = discussion on the list. > "DTLS Transport for SIP", as proposed by Tolga Asveren's recent = messages. > A mechanism for labeling the nature of SIP calls, with = as a likely candidate draft. > Fixing Content-ID in SIP, as discussed in = = , = with as a likely candidate draft. > Clarifications around SIP name-addr, with = as a likely candidate draft >=20 > I will also note that we have already declared consensus on adopting = as a WG document, and will be = adding an associated milestone. I want to take this opportunity to = remind people that the document is in WGLC, and your comments are = strongly encouraged, the earlier the better. >=20 > Please respond before the end of 2016. Thanks! >=20 > Thanks! >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_06D6E694-1B7E-49D4-BD0A-BD8B6E53056C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22 Dec 2016, at 18:08, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Thanks for the clarification.
 
i- I agree that connection re-use needs to be = addressed as it would be a normative change.
ii- Is it a mandate that mutual authentication needs to be = used if transport=3Dtls? If so, that would require another normative = change to align with practical = needs.
The URI for the target and = the cert for the UA server needs to match. It=E2=80=99s not mutual - two = certs in the same TLS session, but that would also
be one = solution (there is a RFC for that). SIP Outbound permits reuse of the = incoming connection and thus
avoids this particular = problem.

iii- I think both i-/ii- = are relatively straightforward to address. The more = interesting/challenging aspect is how to failover DTLS connections = without a need for per-transaction state synchronization and with the = fewest round-trips = possible.
Connection reuse needs to = be handled separately and needs to be something that is way more easy to = implement than SIP outbound.
We need something we can easily = test and get it done soon, as I want more TLS on the SIP networks out = there :-)

The current way to handle = this is connection reuse that breaks the RFCs, we have that = implementation in Kamailio.
If there is an open socket, TLS or = TCP, we prefer to use it to make things work. I would love for this to = be RFC compliant :-)

/O
 
Thanks,
Tolga
 
From: Olle E. Johansson [mailto:oej@edvina.net] 
Sent: Thursday, December 22, 2016 = 10:55 AM
To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: Olle E Johansson <oej@edvina.net>; Christer Holmberg <christer.holmberg@ericsson.com>; Adam Roach <adam@nostrum.com>; = SIPCORE <sipcore@ietf.org>; Ben = Campbell <ben@nostrum.com>
Subject: Re: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 
 
On 22 Dec 2016, at = 16:34, Asveren, Tolga <tasveren@sonusnet.com> wrote:
 
Olle,
 
I missed the point about why =E2=80=9Cpractically = possible failover=E2=80=9D needs to be solved both for TLS/DTLS (I am = not arguing it would be good to have a solution for both) and also what = this issue in general has something to do with client = certificates.
Could you provide a bit = more information/clarifications?
 
We=E2=80=99ve discussed it a number of times both = here and on the SIP Forum techwg mailing list. You can find summaries = here:
 
http://www.slideshare.net/oej/sip-half-outbound-random-notes
http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-pee= r-world
 
In short, without SIP Outbound the client connection = can=E2=80=99t be re-used for outbound requests. Seems like there is a = huge
resistance to implement SIP Outbound. We = need a way for the client to allow the server to reuse the inbound = connection
for outbound requests even though = there=E2=80=99s no TLS certificate matching the URI on the client = side.
 
We=E2=80=99ve had a lot of clients register with = =E2=80=9C;transport=3Dtls=E2=80=9D at SIPit without a client cert - = which means we can=E2=80=99t communicate
based on that registration.
 
Cheers,
/O


Thanks,
Tolga
 
From: Olle E. Johansson [mailto:oej@edvina.net] 
Sent: Thursday, December 22, 2016 = 9:08 AM
To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: Olle = E Johansson <oej@edvina.net>; Christer Holmberg = <christer.holmberg@ericsson.com>; Adam = Roach <adam@nostrum.com>; SIPCORE <sipcore@ietf.org>; Ben Campbell <ben@nostrum.com>
Subject: Re: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 
 
On 22 Dec 2016, at 14:50, Asveren, Tolga <tasveren@sonusnet.com> wrote:
 
Regarding the interest in = SIP/UDP/DTLS:
This is mainly based on prospect of larger scalability on = server side. There may/may not be an immediate need to tweak/change = things to make DTLS related processing (hopefully just on the local = stack level rather than on on-the-wire protocol- with some supporting = SIP enhancements) more =E2=80=9Cfailover friendly=E2=80=9D. This issue = requires more analysis/discussion but does not sound unsolvable = IMHO.
We will have to solve client connection = reuse for both TLS and DTLS sessions though. Unless you want to have
client certificates on all devices.
 
Adam as chair: SIP Client Connection = Reuse is something we=E2=80=99ve disussed under multiple names - =E2=80=9C= half outbound=E2=80=9D or =E2=80=9Cwhy is ;transport=3Dtls=E2=80=9D
deprecated=E2=80=9D or =E2=80=9CWhy = doesn=E2=80=99t SIP Outbound happen?=E2=80=9D. Maybe that deserves a = milestone.
 
/O


 
Thanks,
Tolga
 
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: Thursday, December 22, 2016 = 7:39 AM
To: Adam Roach <adam@nostrum.com>; 'SIPCORE' <sipcore@ietf.org>
Cc: Ben = Campbell <ben@nostrum.com>
Subject: Re: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 
Hi,
 
I will obviously be actively involved in 4), and I also agree = that 5) should be done as it is a correction.
 
As far as the other potential work is concerned, = 3) has the highest priority for me, and I would actively participate in = that work.
 
I would review 1) and 2), but I would really like to see an = individual draft on 2) before we agree whether to create a milestone for = it. For example, I would like to see some input on WHY to do it, and HOW = it is intended to be deployed etc. How does DTLS fit SIP? What are the = advantages? OR, do we want to specify DTLS-for-SIP simply because DTLS = is =E2=80=9Chot=E2=80=9D?
 
Regards,
 
Christer
 
From: sipcore <sipcore-bounces@ietf.org> on behalf of "adam@nostrum.com" <adam@nostrum.com>
Date: Tuesday 20 December = 2016 at 22:27
To: "sipcore@ietf.org" <sipcore@ietf.org>
Cc: Ben = Campbell <ben@nostrum.com>
Subject: [sipcore] RESPONSE = REQUESTED: SIPCORE work and milestones
 

[as chair]

Now that we have our = new charter approved, I'd like the working group to have a discussion = about the specific work items that we should take on in the short- to = medium-term so that we can revise our milestones appropriately. Based on = recent discussions on the mailing list, the following topics have some = mind-share behind them. What I'd like from everyone with an interest in = any of these topics is to indicate (a) whether you are willing to = actively review and comment on documents on the topic; and (b) what = priority each task has relative to each other: there are five topics; = please indicate a unique priority from one (most important) to five = (least important) for each topic.

  1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently = under discussion on the list.
  2. "DTLS Transport = for SIP", as proposed by Tolga Asveren's recent messages.
  3. A mechanism for labeling the nature of SIP calls, with = <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidate = draft.
  4. Fixing Content-ID in SIP, as discussed = in <https://www.ietf.org/mail-archive/web/sipcore/current/msg07= 245.html>, with <draft-holmberg-sipcore-content-id> = as a likely candidate draft.
  5. Clarifications = around SIP name-addr, with = <draft-sparks-sipcore-name-addr-guidance> as a likely candidate = draft

I will also note that we have already declared = consensus on adopting <draft-ietf-sipcore-status-unwanted> as a WG = document, and will be adding an associated milestone. I want to take = this opportunity to remind people that the document is in WGLC, and your = comments are strongly encouraged, the earlier the better.

Please respond before the end of 2016. = Thanks!

Thanks!

/a
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
<= /div>
<= /div>
= --Apple-Mail=_06D6E694-1B7E-49D4-BD0A-BD8B6E53056C-- From nobody Thu Dec 22 10:24:20 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1141294F1 for ; Thu, 22 Dec 2016 10:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 1vi7duRW3pMI for ; Thu, 22 Dec 2016 10:24:17 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CAA129671 for ; Thu, 22 Dec 2016 10:24:17 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with SMTP id K82Gc4pZA1yUhK82Kc4EhC; Thu, 22 Dec 2016 18:24:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1482431056; bh=Amce5yAKpL70KGCqOU93V3kdCgwxxPAIhi6dYIAA5PQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ksapcs+r9ZBkzRqpRifdSVzuRcsV0QyTRkezhBc89tv54v9eFkHbHDFPREInkGJ+G IUNfTFn4JheG47rs6mcvaK7vciv8/y/EBLHJfBMNWfnVemAP9J1ctTJ0CeYtbnFBsA ZUYf3CQwXWon6ngGpNO9aJT1Wt7W+Urv+JA5KMaN38esxom5NCH83k17xyNW9dMYm4 lAyBZUJanwF8BEiMqH70+FUqyhDLhlxvfvOYo/IJfoCzyQy6wC/lbajvDSfidd9gjV yOXXoLQZISVMvfsVCaoFS0u/UxAvRvnn1Ot3fovYs6MtyFwHVm7jS4lomLEtp9ihr/ n+6sHgK63k1zw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-09v.sys.comcast.net with SMTP id K82JcgsoGXhnsK82JcaXfo; Thu, 22 Dec 2016 18:24:16 +0000 To: sipcore@ietf.org References: <87tw9xvuap.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <16e6ecb4-64cd-b814-d3c9-8c1c5e7cbe94@comcast.net> Date: Thu, 22 Dec 2016 13:24:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <87tw9xvuap.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBuS6Lt16Jz2CjNw88lLyLWPSqLPcu3WkkIHRni/c2ClsLxRY9bAcA2dbySw3K4zxJ5vVB8JDgmKbDhZ9stMLf5RPu2fptuvd87H9LfKK3ZnxVmTtXAn ciMwI9kUOzKMMgu64C/+8iOfYMlN04przmHWrEFZGfgWJSGyA1GEAimxNx/jV4PeVvK75cqbWXWisg== Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 18:24:18 -0000 On 12/21/16 4:36 PM, Dale R. Worley wrote: > The service provider delivering calls to > the user issuing the response may, for example, add the calling party > to a personal blacklist specific to the called party, or may use the > information as input when computing the likelihood that the calling > party is placing unwanted calls ("crowd sourcing"), might initiate a > traceback request, or could report the calling number to government > authorities. > > This list has 4 items: > > may, for example, add the calling party to a personal blacklist > specific to the called party, > > or may use the information as input when computing the likelihood > that the calling party is placing unwanted calls ("crowd > sourcing"), > > might initiate a traceback request, > > or could report the calling number to government authorities. > > There is a lack of parallelism in that clauses use "may", "might", and > "could" to indicate possbility. There are two uses of "or". The > first item contains commas, but the items are not separated by > semicolons. Reformulating this by (1) consistently using MAY, (2) > using one "or" before the last item, and (3) moving the "for example" > to before the list (thus escaping the rule regarding semicolons): > > The service provider delivering calls to the user issuing the > response, for example, MAY add the calling party to a personal > blacklist specific to the called party, MAY use the information as > input when computing the likelihood that the calling party is > placing unwanted calls ("crowd sourcing"), MAY initiate a traceback > request, or MAY report the calling number to government > authorities. IIUC these actions are not mutually exclusive. So I would: s/or MAY report/and MAY report/ Thanks, Paul From nobody Thu Dec 22 20:21:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5C31294F8 for ; Thu, 22 Dec 2016 20:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 h1C24vkhOuNK for ; Thu, 22 Dec 2016 20:21:41 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2441294B0 for ; Thu, 22 Dec 2016 20:21:41 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-03v.sys.comcast.net with SMTP id KHM3cYD9icKypKHMScp4vK; Fri, 23 Dec 2016 04:21:40 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-11v.sys.comcast.net with SMTP id KHMRcKsPxy32lKHMSc2v0T; Fri, 23 Dec 2016 04:21:40 +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 uBN4KbFP007739; Thu, 22 Dec 2016 23:20:39 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uBMLY6Gd014019; Thu, 22 Dec 2016 16:34:06 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <16e6ecb4-64cd-b814-d3c9-8c1c5e7cbe94@comcast.net> (paul.kyzivat@comcast.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 22 Dec 2016 16:34:06 -0500 Message-ID: <87shpfveb5.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfInaFY9EwhU4eKXUvtuvfF+ktXTdry2eO8M5hGf99HBD5efcILo2C2eG16/VMgEmMPVF/VzM2G21XkLs8S+/BPZlb4M5q1cXzRFjkATB1vy1/Ba6fiLI hL0QPGTEGnmaclvqvxfSzjZJt+nm49SCHqAjxRVQTNJv9KkgB+454/S2mRSekoe69nVLqAgyPj7Ce85FJLsOzWsojjLt9fNaM5o= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 04:21:42 -0000 Paul Kyzivat writes: >> The service provider delivering calls to the user issuing the >> response, for example, MAY add the calling party to a personal >> blacklist specific to the called party, MAY use the information as >> input when computing the likelihood that the calling party is >> placing unwanted calls ("crowd sourcing"), MAY initiate a traceback >> request, or MAY report the calling number to government >> authorities. > > IIUC these actions are not mutually exclusive. So I would: > > s/or MAY report/and MAY report/ I agree. And yet at the same time, I think the "and" form seems awkward. I wonder if the best solution is to rephrase it to pull the MAY out front. Something like: The service provider delivering calls to the user issuing the response, for example, MAY do one or more of the following: add the calling party to a personal blacklist specific to the called party, use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), initiate a traceback request, or report the calling number to government authorities. Or even pull out the items into a .... Dale From nobody Fri Dec 23 00:30:53 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF1B1294AE for ; Fri, 23 Dec 2016 00:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 0oUA0TN7zyv5 for ; Fri, 23 Dec 2016 00:30:48 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0050.outbound.protection.outlook.com [104.47.42.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D1B1299A2 for ; Fri, 23 Dec 2016 00:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+feoqBbbRb3chWeDmLBoIaIFLQSlqZ4IE1wPNh8tjJE=; b=H+siJoqA4Qp/HOPgpYxNatgW1EbiJBFVuL5X85kSH+mzetYYjOLrSZk/vnLxsqxFpNnfkZ1XoTf5YtARB2YwiLtIuPIdBeRFFJsqpcpxsAH0x2ivydWZEnsPGzApHQXpWxE1icxe8xVNnhL1DhqN6T97uKRT55mOJ8c57cAnV8k= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Fri, 23 Dec 2016 08:30:45 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.015; Fri, 23 Dec 2016 08:30:45 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv96++N6DRIq/E2cKGNWf6YDKaET6r4AgAAS3iCAAAYCAIAAF0yAgAAGmwCAABLYMIAAA+sAgADDHnA= Date: Fri, 23 Dec 2016 08:30:44 +0000 Message-ID: References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 51ab8c61-f27d-4119-063f-08d42b0dfd63 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:tllInRP02PCZs007FHjB/4FPKp8mzwK57SaIj2/C3H0b+6yfG7FnF9aQ1gVX2GptVUfwbHsIGAup74VlhxvJzV5saq+ZmDs7hA6iUvKGyxoUM60tMxEtr3tg7yXnIABtJ8P9up2S4evMHii9TKWs2t96pS1MKxisuxoe9lU8ywOGApUfYZocUBGqvqumllSlPZQDpjFh481THXsnjTLKSebasQ4ThxZtpOlQWeGAxJL1yqljB/BBMoAB7j/byoefYBBv7i1vX+SrrSTGoah5TmX6W0PT84auR9ig9L6uRoyetR9kvvfLwbZQ0JBjYH3QSTwrDeA1/5msBN8A7kjbB3bqrSFJyQmQDEv8cFbapXQhrbXB365HNGdKg1ZeU4nLvTkEBqzWYTvWztM/9189wvtLlQtBMSMVS8YOtHRS6UKqpG10vGLGApNi7SVvx6zOV7/siLhCTb5NRn+xck+kQQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(192374486261705)(100405760836317)(178636050973902)(21748063052155)(132712982866762); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 016572D96D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39410400002)(39830400002)(39450400003)(51914003)(24454002)(377454003)(189002)(199003)(7736002)(551934003)(101416001)(6506006)(2950100002)(38730400001)(6916009)(2900100001)(6116002)(790700001)(93886004)(3846002)(102836003)(105586002)(4326007)(106116001)(229853002)(6436002)(50986999)(77096006)(25786008)(33656002)(106356001)(92566002)(7696004)(54356999)(606005)(99286002)(5660300001)(110136003)(86362001)(9686002)(76176999)(97736004)(122556002)(66066001)(3280700002)(8936002)(3660700001)(81156014)(81166006)(8676002)(76576001)(2906002)(19609705001)(189998001)(68736007)(7906003)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350C16785A81C21DEC8A9E2B2950SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2016 08:30:45.0135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Cc: Ben Campbell , SIPCORE Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 08:30:51 -0000 --_000_SN2PR03MB2350C16785A81C21DEC8A9E2B2950SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aS0gSSBhZ3JlZSB3aXRoIHRoZSBuZWVkIHRvIOKAnHN0YW5kYXJkaXpl4oCdIHRoZSDigJxjb25u ZWN0aW9uIHJldXNlIHBlciBleGlzdGluZyBkZXBsb3ltZW50IHNlbWFudGljc+KAnS4gIEkgdGhp bmsgd2hhdCB3ZSBhcmUgbG9va2luZyBmb3IgaXM6DQoNCi0gICAgICAgICAgQmlkaXJlY3Rpb25h bCBjb25uZWN0aW9uIHJldXNlIHdpdGggVExTL3NlcnZlci1zaWRlIG9ubHkgY2VydGlmaWNhdGUv VUUgYXV0aGVudGljYXRpb24gcGVyIFNJUCByZWdpc3RyYXRpb24gd2l0aG91dCBSRkM1NjI2DQoN Ci0gICAgICAgICAgQmlkaXJlY3Rpb25hbCBjb25uZWN0aW9uIHJldXNlIHdpdGggVENQIG92ZXIg VlBOLCBlLmcuIElQU2VjDQoNCi0gICAgICAgICAgQmlkaXJlY3Rpb25hbCBjb25uZWN0aW9uIHJl dXNlIHdpdGggVENQIHdoZW4gYXV0aGVudGljYXRpb24vc2VjdXJpdHkgaXMgcHJvdmlkZWQgYnkg TDINCg0KSSBhbSBub3Qgc3VyZSB3aGF0IHdvdWxkIGJlIHRoZSBiZXN0IHBsYWNlIHRvIGFkZHJl c3MgdGhlc2UuIEl0IGNvdWxkIGJlIGVpdGhlciBoYXBweS1lYXJiYWxscyBvciBhIG5ldyBkb2N1 bWVudC4gSSB3b3VsZCBwcmVmZXIgdGhlIGZvcm1lciBhbmQgY2FuIHByb3ZpZGUgdGV4dCBpbiBl aXRoZXIgY2FzZS4NCg0KaWktIFRoZSBpc3N1ZSB3aXRoIFNJUC9VRFAvRFRMUyBpcyBzb21ldGhp bmcgcXVpdGUgZGlmZmVyZW50LiBJdCByZWFsbHkgaXMgbW9yZSBhYm91dCBwcm92aWRpbmcgZmFz dC9wcmFjdGljYWxseSBmZWFzaWJsZSBmYWlsb3ZlciBmb3IgRFRMUyBjb25uZWN0aW9ucyAoaW4g YWRkaXRpb24gdG8gZGVmaW5pbmcgdXNlIG9mIFVEUC9EVExTIGFzIGEgbmV3IHRyYW5zcG9ydCBm b3IgU0lQIGJ1dCB0aGlzIHBhcnQgaXMgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQgSU1ITyku IEluIGFueSBjYXNlLCBsZXQgbWUgdXNlIHRoaXMgb3Bwb3J0dW5pdHkgdG8gZXhwcmVzcyBteSBz dHJvbmcgaW50ZXJlc3QgaW4gdGhpcyB3b3JrIG9uZSBtb3JlIHRpbWUuDQoNClRoYW5rcywNClRv bGdhDQoNCkZyb206IE9sbGUgRS4gSm9oYW5zc29uIFttYWlsdG86b2VqQGVkdmluYS5uZXRdDQpT ZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjIsIDIwMTYgMTI6MTcgUE0NClRvOiBBc3ZlcmVuLCBU b2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KQ2M6IE9sbGUgRSBKb2hhbnNzb24gPG9lakBl ZHZpbmEubmV0PjsgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT47IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+OyBTSVBDT1JFIDxzaXBjb3JlQGll dGYub3JnPjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQpTdWJqZWN0OiBSZTogW3Np cGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzDQoN Cg0KT24gMjIgRGVjIDIwMTYsIGF0IDE4OjA4LCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29u dXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+PiB3cm90ZToNCg0KVGhhbmtz IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCg0KaS0gSSBhZ3JlZSB0aGF0IGNvbm5lY3Rpb24gcmUt dXNlIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBhcyBpdCB3b3VsZCBiZSBhIG5vcm1hdGl2ZSBjaGFu Z2UuDQppaS0gSXMgaXQgYSBtYW5kYXRlIHRoYXQgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIG5lZWRz IHRvIGJlIHVzZWQgaWYgdHJhbnNwb3J0PXRscz8gSWYgc28sIHRoYXQgd291bGQgcmVxdWlyZSBh bm90aGVyIG5vcm1hdGl2ZSBjaGFuZ2UgdG8gYWxpZ24gd2l0aCBwcmFjdGljYWwgbmVlZHMuDQpU aGUgVVJJIGZvciB0aGUgdGFyZ2V0IGFuZCB0aGUgY2VydCBmb3IgdGhlIFVBIHNlcnZlciBuZWVk cyB0byBtYXRjaC4gSXTigJlzIG5vdCBtdXR1YWwgLSB0d28gY2VydHMgaW4gdGhlIHNhbWUgVExT IHNlc3Npb24sIGJ1dCB0aGF0IHdvdWxkIGFsc28NCmJlIG9uZSBzb2x1dGlvbiAodGhlcmUgaXMg YSBSRkMgZm9yIHRoYXQpLiBTSVAgT3V0Ym91bmQgcGVybWl0cyByZXVzZSBvZiB0aGUgaW5jb21p bmcgY29ubmVjdGlvbiBhbmQgdGh1cw0KYXZvaWRzIHRoaXMgcGFydGljdWxhciBwcm9ibGVtLg0K DQoNCmlpaS0gSSB0aGluayBib3RoIGktL2lpLSBhcmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndh cmQgdG8gYWRkcmVzcy4gVGhlIG1vcmUgaW50ZXJlc3RpbmcvY2hhbGxlbmdpbmcgYXNwZWN0IGlz IGhvdyB0byBmYWlsb3ZlciBEVExTIGNvbm5lY3Rpb25zIHdpdGhvdXQgYSBuZWVkIGZvciBwZXIt dHJhbnNhY3Rpb24gc3RhdGUgc3luY2hyb25pemF0aW9uIGFuZCB3aXRoIHRoZSBmZXdlc3Qgcm91 bmQtdHJpcHMgcG9zc2libGUuDQpDb25uZWN0aW9uIHJldXNlIG5lZWRzIHRvIGJlIGhhbmRsZWQg c2VwYXJhdGVseSBhbmQgbmVlZHMgdG8gYmUgc29tZXRoaW5nIHRoYXQgaXMgd2F5IG1vcmUgZWFz eSB0byBpbXBsZW1lbnQgdGhhbiBTSVAgb3V0Ym91bmQuDQpXZSBuZWVkIHNvbWV0aGluZyB3ZSBj YW4gZWFzaWx5IHRlc3QgYW5kIGdldCBpdCBkb25lIHNvb24sIGFzIEkgd2FudCBtb3JlIFRMUyBv biB0aGUgU0lQIG5ldHdvcmtzIG91dCB0aGVyZSA6LSkNCg0KVGhlIGN1cnJlbnQgd2F5IHRvIGhh bmRsZSB0aGlzIGlzIGNvbm5lY3Rpb24gcmV1c2UgdGhhdCBicmVha3MgdGhlIFJGQ3MsIHdlIGhh dmUgdGhhdCBpbXBsZW1lbnRhdGlvbiBpbiBLYW1haWxpby4NCklmIHRoZXJlIGlzIGFuIG9wZW4g c29ja2V0LCBUTFMgb3IgVENQLCB3ZSBwcmVmZXIgdG8gdXNlIGl0IHRvIG1ha2UgdGhpbmdzIHdv cmsuIEkgd291bGQgbG92ZSBmb3IgdGhpcyB0byBiZSBSRkMgY29tcGxpYW50IDotKQ0KDQovTw0K DQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IE9sbGUgRS4gSm9oYW5zc29uIFttYWlsdG86b2Vq QGVkdmluYS5uZXRdDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjIsIDIwMTYgMTA6NTUgQU0N ClRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJl bkBzb251c25ldC5jb20+Pg0KQ2M6IE9sbGUgRSBKb2hhbnNzb24gPG9lakBlZHZpbmEubmV0PG1h aWx0bzpvZWpAZWR2aW5hLm5ldD4+OyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pjsg QWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+OyBT SVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPj47IEJlbiBD YW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+Pg0KU3ViamVj dDogUmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUgd29yayBhbmQgbWls ZXN0b25lcw0KDQoNCk9uIDIyIERlYyAyMDE2LCBhdCAxNjozNCwgQXN2ZXJlbiwgVG9sZ2EgPHRh c3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6 DQoNCk9sbGUsDQoNCkkgbWlzc2VkIHRoZSBwb2ludCBhYm91dCB3aHkg4oCccHJhY3RpY2FsbHkg cG9zc2libGUgZmFpbG92ZXLigJ0gbmVlZHMgdG8gYmUgc29sdmVkIGJvdGggZm9yIFRMUy9EVExT IChJIGFtIG5vdCBhcmd1aW5nIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIHNvbHV0aW9uIGZv ciBib3RoKSBhbmQgYWxzbyB3aGF0IHRoaXMgaXNzdWUgaW4gZ2VuZXJhbCBoYXMgc29tZXRoaW5n IHRvIGRvIHdpdGggY2xpZW50IGNlcnRpZmljYXRlcy4NCkNvdWxkIHlvdSBwcm92aWRlIGEgYml0 IG1vcmUgaW5mb3JtYXRpb24vY2xhcmlmaWNhdGlvbnM/DQoNCldl4oCZdmUgZGlzY3Vzc2VkIGl0 IGEgbnVtYmVyIG9mIHRpbWVzIGJvdGggaGVyZSBhbmQgb24gdGhlIFNJUCBGb3J1bSB0ZWNod2cg bWFpbGluZyBsaXN0LiBZb3UgY2FuIGZpbmQgc3VtbWFyaWVzIGhlcmU6DQoNCmh0dHA6Ly93d3cu c2xpZGVzaGFyZS5uZXQvb2VqL3NpcC1oYWxmLW91dGJvdW5kLXJhbmRvbS1ub3Rlcw0KaHR0cDov L3d3dy5zbGlkZXNoYXJlLm5ldC9vZWovc2lwLXRscy1zZWN1cml0eS1pbi1hLXBlZXItdG8tcGVl ci13b3JsZA0KDQpJbiBzaG9ydCwgd2l0aG91dCBTSVAgT3V0Ym91bmQgdGhlIGNsaWVudCBjb25u ZWN0aW9uIGNhbuKAmXQgYmUgcmUtdXNlZCBmb3Igb3V0Ym91bmQgcmVxdWVzdHMuIFNlZW1zIGxp a2UgdGhlcmUgaXMgYSBodWdlDQpyZXNpc3RhbmNlIHRvIGltcGxlbWVudCBTSVAgT3V0Ym91bmQu IFdlIG5lZWQgYSB3YXkgZm9yIHRoZSBjbGllbnQgdG8gYWxsb3cgdGhlIHNlcnZlciB0byByZXVz ZSB0aGUgaW5ib3VuZCBjb25uZWN0aW9uDQpmb3Igb3V0Ym91bmQgcmVxdWVzdHMgZXZlbiB0aG91 Z2ggdGhlcmXigJlzIG5vIFRMUyBjZXJ0aWZpY2F0ZSBtYXRjaGluZyB0aGUgVVJJIG9uIHRoZSBj bGllbnQgc2lkZS4NCg0KV2XigJl2ZSBoYWQgYSBsb3Qgb2YgY2xpZW50cyByZWdpc3RlciB3aXRo IOKAnDt0cmFuc3BvcnQ9dGxz4oCdIGF0IFNJUGl0IHdpdGhvdXQgYSBjbGllbnQgY2VydCAtIHdo aWNoIG1lYW5zIHdlIGNhbuKAmXQgY29tbXVuaWNhdGUNCmJhc2VkIG9uIHRoYXQgcmVnaXN0cmF0 aW9uLg0KDQpDaGVlcnMsDQovTw0KDQoNCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogT2xsZSBF LiBKb2hhbnNzb24gW21haWx0bzpvZWpAZWR2aW5hLm5ldF0NClNlbnQ6IFRodXJzZGF5LCBEZWNl bWJlciAyMiwgMjAxNiA5OjA4IEFNDQpUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVz bmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4NCkNjOiBPbGxlIEUgSm9oYW5z c29uIDxvZWpAZWR2aW5hLm5ldDxtYWlsdG86b2VqQGVkdmluYS5uZXQ+PjsgQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPj47IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRv OmFkYW1Abm9zdHJ1bS5jb20+PjsgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lw Y29yZUBpZXRmLm9yZz4+OyBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVu QG5vc3RydW0uY29tPj4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gUkVTUE9OU0UgUkVRVUVTVEVE OiBTSVBDT1JFIHdvcmsgYW5kIG1pbGVzdG9uZXMNCg0KDQpPbiAyMiBEZWMgMjAxNiwgYXQgMTQ6 NTAsIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVu QHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KDQpSZWdhcmRpbmcgdGhlIGludGVyZXN0IGluIFNJUC9V RFAvRFRMUzoNClRoaXMgaXMgbWFpbmx5IGJhc2VkIG9uIHByb3NwZWN0IG9mIGxhcmdlciBzY2Fs YWJpbGl0eSBvbiBzZXJ2ZXIgc2lkZS4gVGhlcmUgbWF5L21heSBub3QgYmUgYW4gaW1tZWRpYXRl IG5lZWQgdG8gdHdlYWsvY2hhbmdlIHRoaW5ncyB0byBtYWtlIERUTFMgcmVsYXRlZCBwcm9jZXNz aW5nIChob3BlZnVsbHkganVzdCBvbiB0aGUgbG9jYWwgc3RhY2sgbGV2ZWwgcmF0aGVyIHRoYW4g b24gb24tdGhlLXdpcmUgcHJvdG9jb2wtIHdpdGggc29tZSBzdXBwb3J0aW5nIFNJUCBlbmhhbmNl bWVudHMpIG1vcmUg4oCcZmFpbG92ZXIgZnJpZW5kbHnigJ0uIFRoaXMgaXNzdWUgcmVxdWlyZXMg bW9yZSBhbmFseXNpcy9kaXNjdXNzaW9uIGJ1dCBkb2VzIG5vdCBzb3VuZCB1bnNvbHZhYmxlIElN SE8uDQpXZSB3aWxsIGhhdmUgdG8gc29sdmUgY2xpZW50IGNvbm5lY3Rpb24gcmV1c2UgZm9yIGJv dGggVExTIGFuZCBEVExTIHNlc3Npb25zIHRob3VnaC4gVW5sZXNzIHlvdSB3YW50IHRvIGhhdmUN CmNsaWVudCBjZXJ0aWZpY2F0ZXMgb24gYWxsIGRldmljZXMuDQoNCkFkYW0gYXMgY2hhaXI6IFNJ UCBDbGllbnQgQ29ubmVjdGlvbiBSZXVzZSBpcyBzb21ldGhpbmcgd2XigJl2ZSBkaXN1c3NlZCB1 bmRlciBtdWx0aXBsZSBuYW1lcyAtIOKAnGhhbGYgb3V0Ym91bmTigJ0gb3Ig4oCcd2h5IGlzIDt0 cmFuc3BvcnQ9dGxz4oCdDQpkZXByZWNhdGVk4oCdIG9yIOKAnFdoeSBkb2VzbuKAmXQgU0lQIE91 dGJvdW5kIGhhcHBlbj/igJ0uIE1heWJlIHRoYXQgZGVzZXJ2ZXMgYSBtaWxlc3RvbmUuDQoNCi9P DQoNCg0KDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDog VGh1cnNkYXksIERlY2VtYmVyIDIyLCAyMDE2IDc6MzkgQU0NClRvOiBBZGFtIFJvYWNoIDxhZGFt QG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj47ICdTSVBDT1JFJyA8c2lwY29y ZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4+DQpDYzogQmVuIENhbXBiZWxsIDxi ZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+DQpTdWJqZWN0OiBSZTogW3Np cGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzDQoN CkhpLA0KDQpJIHdpbGwgb2J2aW91c2x5IGJlIGFjdGl2ZWx5IGludm9sdmVkIGluIDQpLCBhbmQg SSBhbHNvIGFncmVlIHRoYXQgNSkgc2hvdWxkIGJlIGRvbmUgYXMgaXQgaXMgYSBjb3JyZWN0aW9u Lg0KDQpBcyBmYXIgYXMgdGhlIG90aGVyIHBvdGVudGlhbCB3b3JrIGlzIGNvbmNlcm5lZCwgMykg aGFzIHRoZSBoaWdoZXN0IHByaW9yaXR5IGZvciBtZSwgYW5kIEkgd291bGQgYWN0aXZlbHkgcGFy dGljaXBhdGUgaW4gdGhhdCB3b3JrLg0KDQpJIHdvdWxkIHJldmlldyAxKSBhbmQgMiksIGJ1dCBJ IHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IG9uIDIpIGJlZm9y ZSB3ZSBhZ3JlZSB3aGV0aGVyIHRvIGNyZWF0ZSBhIG1pbGVzdG9uZSBmb3IgaXQuIEZvciBleGFt cGxlLCBJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUgaW5wdXQgb24gV0hZIHRvIGRvIGl0LCBhbmQg SE9XIGl0IGlzIGludGVuZGVkIHRvIGJlIGRlcGxveWVkIGV0Yy4gSG93IGRvZXMgRFRMUyBmaXQg U0lQPyBXaGF0IGFyZSB0aGUgYWR2YW50YWdlcz8gT1IsIGRvIHdlIHdhbnQgdG8gc3BlY2lmeSBE VExTLWZvci1TSVAgc2ltcGx5IGJlY2F1c2UgRFRMUyBpcyDigJxob3TigJ0/DQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCkZyb206IHNpcGNvcmUgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mICJhZGFtQG5vc3Ry dW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPiIgPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRv OmFkYW1Abm9zdHJ1bS5jb20+Pg0KRGF0ZTogVHVlc2RheSAyMCBEZWNlbWJlciAyMDE2IGF0IDIy OjI3DQpUbzogInNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+IiA8c2lw Y29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4+DQpDYzogQmVuIENhbXBiZWxs IDxiZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+DQpTdWJqZWN0OiBbc2lw Y29yZV0gUkVTUE9OU0UgUkVRVUVTVEVEOiBTSVBDT1JFIHdvcmsgYW5kIG1pbGVzdG9uZXMNCg0K W2FzIGNoYWlyXQ0KDQpOb3cgdGhhdCB3ZSBoYXZlIG91ciBuZXcgY2hhcnRlciBhcHByb3ZlZCwg SSdkIGxpa2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gaGF2ZSBhIGRpc2N1c3Npb24gYWJvdXQgdGhl IHNwZWNpZmljIHdvcmsgaXRlbXMgdGhhdCB3ZSBzaG91bGQgdGFrZSBvbiBpbiB0aGUgc2hvcnQt IHRvIG1lZGl1bS10ZXJtIHNvIHRoYXQgd2UgY2FuIHJldmlzZSBvdXIgbWlsZXN0b25lcyBhcHBy b3ByaWF0ZWx5LiBCYXNlZCBvbiByZWNlbnQgZGlzY3Vzc2lvbnMgb24gdGhlIG1haWxpbmcgbGlz dCwgdGhlIGZvbGxvd2luZyB0b3BpY3MgaGF2ZSBzb21lIG1pbmQtc2hhcmUgYmVoaW5kIHRoZW0u IFdoYXQgSSdkIGxpa2UgZnJvbSBldmVyeW9uZSB3aXRoIGFuIGludGVyZXN0IGluIGFueSBvZiB0 aGVzZSB0b3BpY3MgaXMgdG8gaW5kaWNhdGUgKGEpIHdoZXRoZXIgeW91IGFyZSB3aWxsaW5nIHRv IGFjdGl2ZWx5IHJldmlldyBhbmQgY29tbWVudCBvbiBkb2N1bWVudHMgb24gdGhlIHRvcGljOyBh bmQgKGIpIHdoYXQgcHJpb3JpdHkgZWFjaCB0YXNrIGhhcyByZWxhdGl2ZSB0byBlYWNoIG90aGVy OiB0aGVyZSBhcmUgZml2ZSB0b3BpY3M7IHBsZWFzZSBpbmRpY2F0ZSBhIHVuaXF1ZSBwcmlvcml0 eSBmcm9tIG9uZSAobW9zdCBpbXBvcnRhbnQpIHRvIGZpdmUgKGxlYXN0IGltcG9ydGFudCkgZm9y IGVhY2ggdG9waWMuDQoNCiAgMS4gICJIYXBweSBFeWViYWxscyBmb3IgU0lQIiAoYWthIEhhcHB5 IEVhcmJhbGxzKSwgY3VycmVudGx5IHVuZGVyIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuDQogIDIu ICAiRFRMUyBUcmFuc3BvcnQgZm9yIFNJUCIsIGFzIHByb3Bvc2VkIGJ5IFRvbGdhIEFzdmVyZW4n cyByZWNlbnQgbWVzc2FnZXMuDQogIDMuICBBIG1lY2hhbmlzbSBmb3IgbGFiZWxpbmcgdGhlIG5h dHVyZSBvZiBTSVAgY2FsbHMsIHdpdGggPGRyYWZ0LXNjaHVsenJpbm5lLXNpcGNvcmUtY2FsbGlu Zm8tc3BhbT4gYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0Lg0KICA0LiAgRml4aW5nIENvbnRl bnQtSUQgaW4gU0lQLCBhcyBkaXNjdXNzZWQgaW4gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzA3MjQ1Lmh0bWw+PGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzA3MjQ1Lmh0bWw+LCB3 aXRoIDxkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLWNvbnRlbnQtaWQ+IGFzIGEgbGlrZWx5IGNhbmRp ZGF0ZSBkcmFmdC4NCiAgNS4gIENsYXJpZmljYXRpb25zIGFyb3VuZCBTSVAgbmFtZS1hZGRyLCB3 aXRoIDxkcmFmdC1zcGFya3Mtc2lwY29yZS1uYW1lLWFkZHItZ3VpZGFuY2U+IGFzIGEgbGlrZWx5 IGNhbmRpZGF0ZSBkcmFmdA0KDQpJIHdpbGwgYWxzbyBub3RlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5 IGRlY2xhcmVkIGNvbnNlbnN1cyBvbiBhZG9wdGluZyA8ZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1 cy11bndhbnRlZD4gYXMgYSBXRyBkb2N1bWVudCwgYW5kIHdpbGwgYmUgYWRkaW5nIGFuIGFzc29j aWF0ZWQgbWlsZXN0b25lLiBJIHdhbnQgdG8gdGFrZSB0aGlzIG9wcG9ydHVuaXR5IHRvIHJlbWlu ZCBwZW9wbGUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgaW4gV0dMQywgYW5kIHlvdXIgY29tbWVudHMg YXJlIHN0cm9uZ2x5IGVuY291cmFnZWQsIHRoZSBlYXJsaWVyIHRoZSBiZXR0ZXIuDQoNClBsZWFz ZSByZXNwb25kIGJlZm9yZSB0aGUgZW5kIG9mIDIwMTYuIFRoYW5rcyENCg0KVGhhbmtzIQ0KDQov YQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNv cmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg== --_000_SN2PR03MB2350C16785A81C21DEC8A9E2B2950SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU4ODM5 NDQwOTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5 MTQ1NDU2OCAtMTczOTUzOTE1NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MS4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDox Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi4yNWluOw0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDoyLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMuMjVpbjsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDozLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQuMjVpbjsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NC43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTE2 OTk3OTA1NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTM3NDI5MjY0O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmkt IEkgYWdyZWUgd2l0aCB0aGUgbmVlZCB0byDigJxzdGFuZGFyZGl6ZeKAnSB0aGUg4oCcY29ubmVj dGlvbiByZXVzZSBwZXIgZXhpc3RpbmcgZGVwbG95bWVudCBzZW1hbnRpY3PigJ0uICZuYnNwO0kg dGhpbmsgd2hhdCB3ZSBhcmUgbG9va2luZyBmb3IgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJpZGlyZWN0aW9uYWwgY29u bmVjdGlvbiByZXVzZSB3aXRoIFRMUy9zZXJ2ZXItc2lkZSBvbmx5IGNlcnRpZmljYXRlL1VFIGF1 dGhlbnRpY2F0aW9uIHBlciBTSVAgcmVnaXN0cmF0aW9uIHdpdGhvdXQgUkZDNTYyNjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5C aWRpcmVjdGlvbmFsIGNvbm5lY3Rpb24gcmV1c2Ugd2l0aCBUQ1Agb3ZlciBWUE4sIGUuZy4gSVBT ZWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi43NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+QmlkaXJlY3Rpb25hbCBjb25uZWN0aW9uIHJldXNlIHdpdGggVENQIHdoZW4gYXV0 aGVudGljYXRpb24vc2VjdXJpdHkgaXMgcHJvdmlkZWQgYnkgTDI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBh bSBub3Qgc3VyZSB3aGF0IHdvdWxkIGJlIHRoZSBiZXN0IHBsYWNlIHRvIGFkZHJlc3MgdGhlc2Uu IEl0IGNvdWxkIGJlIGVpdGhlciBoYXBweS1lYXJiYWxscyBvciBhIG5ldyBkb2N1bWVudC4gSSB3 b3VsZCBwcmVmZXIgdGhlIGZvcm1lciBhbmQgY2FuIHByb3ZpZGUgdGV4dCBpbiBlaXRoZXIgY2Fz ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+aWktIFRoZSBpc3N1ZSB3aXRoIFNJUC9VRFAvRFRMUyBpcyBzb21l dGhpbmcgcXVpdGUgZGlmZmVyZW50LiBJdCByZWFsbHkgaXMgbW9yZSBhYm91dCBwcm92aWRpbmcg ZmFzdC9wcmFjdGljYWxseSBmZWFzaWJsZSBmYWlsb3ZlciBmb3IgRFRMUyBjb25uZWN0aW9ucyAo aW4gYWRkaXRpb24gdG8gZGVmaW5pbmcNCiB1c2Ugb2YgVURQL0RUTFMgYXMgYSBuZXcgdHJhbnNw b3J0IGZvciBTSVAgYnV0IHRoaXMgcGFydCBpcyByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZCBJ TUhPKS4gSW4gYW55IGNhc2UsIGxldCBtZSB1c2UgdGhpcyBvcHBvcnR1bml0eSB0byBleHByZXNz IG15IHN0cm9uZyBpbnRlcmVzdCBpbiB0aGlzIHdvcmsgb25lIG1vcmUgdGltZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gT2xsZSBFLiBKb2hhbnNzb24gW21haWx0bzpvZWpAZWR2aW5h Lm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgMjIsIDIwMTYgMTI6 MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhICZsdDt0YXN2ZXJlbkBzb251c25l dC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBPbGxlIEUgSm9oYW5zc29uICZsdDtvZWpAZWR2aW5h Lm5ldCZndDs7IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20mZ3Q7OyBBZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0OzsgU0lQQ09SRSAm bHQ7c2lwY29yZUBpZXRmLm9yZyZndDs7IEJlbiBDYW1wYmVsbCAmbHQ7YmVuQG5vc3RydW0uY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RF RDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgRGVjIDIwMTYsIGF0IDE4OjA4LCBBc3ZlcmVu LCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSI+dGFzdmVy ZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgdGhlIGNsYXJp ZmljYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmkt IEkgYWdyZWUgdGhhdCBjb25uZWN0aW9uIHJlLXVzZSBuZWVkcyB0byBiZSBhZGRyZXNzZWQgYXMg aXQgd291bGQgYmUgYSBub3JtYXRpdmUgY2hhbmdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aWktIElz IGl0IGEgbWFuZGF0ZSB0aGF0IG11dHVhbCBhdXRoZW50aWNhdGlvbiBuZWVkcyB0byBiZSB1c2Vk IGlmIHRyYW5zcG9ydD10bHM/IElmIHNvLCB0aGF0IHdvdWxkIHJlcXVpcmUgYW5vdGhlciBub3Jt YXRpdmUgY2hhbmdlIHRvIGFsaWduIHdpdGggcHJhY3RpY2FsIG5lZWRzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgVVJJIGZvciB0aGUgdGFyZ2V0IGFuZCB0aGUgY2VydCBmb3IgdGhlIFVBIHNlcnZl ciBuZWVkcyB0byBtYXRjaC4gSXTigJlzIG5vdCBtdXR1YWwgLSB0d28gY2VydHMgaW4gdGhlIHNh bWUgVExTIHNlc3Npb24sIGJ1dCB0aGF0IHdvdWxkIGFsc288bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlIG9uZSBzb2x1dGlvbiAodGhlcmUgaXMg YSBSRkMgZm9yIHRoYXQpLiBTSVAgT3V0Ym91bmQgcGVybWl0cyByZXVzZSBvZiB0aGUgaW5jb21p bmcgY29ubmVjdGlvbiBhbmQgdGh1czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+YXZvaWRzIHRoaXMgcGFydGljdWxhciBwcm9ibGVtLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5paWktIEkgdGhpbmsgYm90aCBpLS9paS0gYXJlIHJlbGF0aXZlbHkgc3Ry YWlnaHRmb3J3YXJkIHRvIGFkZHJlc3MuIFRoZSBtb3JlIGludGVyZXN0aW5nL2NoYWxsZW5naW5n IGFzcGVjdCBpcyBob3cgdG8gZmFpbG92ZXIgRFRMUyBjb25uZWN0aW9ucyB3aXRob3V0IGEgbmVl ZCBmb3IgcGVyLXRyYW5zYWN0aW9uDQogc3RhdGUgc3luY2hyb25pemF0aW9uIGFuZCB3aXRoIHRo ZSBmZXdlc3Qgcm91bmQtdHJpcHMgcG9zc2libGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbm5lY3Rp b24gcmV1c2UgbmVlZHMgdG8gYmUgaGFuZGxlZCBzZXBhcmF0ZWx5IGFuZCBuZWVkcyB0byBiZSBz b21ldGhpbmcgdGhhdCBpcyB3YXkgbW9yZSBlYXN5IHRvIGltcGxlbWVudCB0aGFuIFNJUCBvdXRi b3VuZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldlIG5lZWQgc29tZXRoaW5nIHdlIGNhbiBlYXNpbHkgdGVzdCBhbmQgZ2V0IGl0IGRvbmUgc29v biwgYXMgSSB3YW50IG1vcmUgVExTIG9uIHRoZSBTSVAgbmV0d29ya3Mgb3V0IHRoZXJlIDotKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg Y3VycmVudCB3YXkgdG8gaGFuZGxlIHRoaXMgaXMgY29ubmVjdGlvbiByZXVzZSB0aGF0IGJyZWFr cyB0aGUgUkZDcywgd2UgaGF2ZSB0aGF0IGltcGxlbWVudGF0aW9uIGluIEthbWFpbGlvLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlcmUg aXMgYW4gb3BlbiBzb2NrZXQsIFRMUyBvciBUQ1AsIHdlIHByZWZlciB0byB1c2UgaXQgdG8gbWFr ZSB0aGluZ3Mgd29yay4gSSB3b3VsZCBsb3ZlIGZvciB0aGlzIHRvIGJlIFJGQyBjb21wbGlhbnQg Oi0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi9PPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRo YW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPk9sbGUNCiBFLiBKb2hhbnNzb24gWzxhIGhyZWY9Im1haWx0bzpvZWpA ZWR2aW5hLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOm9lakBlZHZpbmEu bmV0PC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgRGVjZW1iZXIgMjIsIDIwMTYgMTA6NTUgQU08YnI+ DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPkFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50YXN2ZXJlbkBzb251c25ldC5jb208L3Nw YW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPk9sbGUgRSBKb2hhbnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpv ZWpAZWR2aW5hLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+b2VqQGVkdmluYS5uZXQ8 L3NwYW4+PC9hPiZndDs7IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDs7DQogQWRhbSBSb2Fj aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmFkYW1Abm9zdHJ1bS5jb208L3NwYW4+PC9hPiZndDs7IFNJUENPUkUgJmx0Ozxh IGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5zaXBjb3JlQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7OyBCZW4gQ2FtcGJlbGwgJmx0OzxhIGhy ZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmJl bkBub3N0cnVtLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3NpcGNvcmVdIFJF U1BPTlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgRGVjIDIwMTYsIGF0IDE2OjM0LCBBc3Zl cmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbGxlLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5JIG1pc3NlZCB0aGUgcG9pbnQgYWJvdXQgd2h5IOKAnHByYWN0aWNhbGx5 IHBvc3NpYmxlIGZhaWxvdmVy4oCdIG5lZWRzIHRvIGJlIHNvbHZlZCBib3RoIGZvciBUTFMvRFRM UyAoSSBhbSBub3QgYXJndWluZyBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSBzb2x1dGlvbiBm b3IgYm90aCkgYW5kIGFsc28gd2hhdA0KIHRoaXMgaXNzdWUgaW4gZ2VuZXJhbCBoYXMgc29tZXRo aW5nIHRvIGRvIHdpdGggY2xpZW50IGNlcnRpZmljYXRlcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkNvdWxkIHlvdSBwcm92aWRlIGEgYml0IG1vcmUgaW5mb3JtYXRpb24vY2xh cmlmaWNhdGlvbnM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2XigJl2ZSBkaXNjdXNzZWQgaXQgYSBudW1i ZXIgb2YgdGltZXMgYm90aCBoZXJlIGFuZCBvbiB0aGUgU0lQIEZvcnVtIHRlY2h3ZyBtYWlsaW5n IGxpc3QuIFlvdSBjYW4gZmluZCBzdW1tYXJpZXMgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9vZWovc2lwLWhhbGYtb3V0 Ym91bmQtcmFuZG9tLW5vdGVzIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vd3d3 LnNsaWRlc2hhcmUubmV0L29lai9zaXAtaGFsZi1vdXRib3VuZC1yYW5kb20tbm90ZXM8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9vZWovc2lw LXRscy1zZWN1cml0eS1pbi1hLXBlZXItdG8tcGVlci13b3JsZCI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9vZWovc2lwLXRscy1zZWN1cml0eS1p bi1hLXBlZXItdG8tcGVlci13b3JsZDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHNob3J0LCB3aXRob3V0IFNJUCBPdXRib3VuZCB0aGUgY2xpZW50IGNvbm5lY3Rpb24g Y2Fu4oCZdCBiZSByZS11c2VkIGZvciBvdXRib3VuZCByZXF1ZXN0cy4gU2VlbXMgbGlrZSB0aGVy ZSBpcyBhIGh1Z2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlc2lzdGFuY2UgdG8gaW1wbGVtZW50IFNJUCBPdXRib3Vu ZC4gV2UgbmVlZCBhIHdheSBmb3IgdGhlIGNsaWVudCB0byBhbGxvdyB0aGUgc2VydmVyIHRvIHJl dXNlIHRoZSBpbmJvdW5kIGNvbm5lY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvciBvdXRib3VuZCByZXF1ZXN0 cyBldmVuIHRob3VnaCB0aGVyZeKAmXMgbm8gVExTIGNlcnRpZmljYXRlIG1hdGNoaW5nIHRoZSBV Ukkgb24gdGhlIGNsaWVudCBzaWRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZeKAmXZl IGhhZCBhIGxvdCBvZiBjbGllbnRzIHJlZ2lzdGVyIHdpdGgg4oCcO3RyYW5zcG9ydD10bHPigJ0g YXQgU0lQaXQgd2l0aG91dCBhIGNsaWVudCBjZXJ0IC0gd2hpY2ggbWVhbnMgd2UgY2Fu4oCZdCBj b21tdW5pY2F0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YmFzZWQgb24gdGhhdCByZWdpc3RyYXRpb24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9PPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9sbGUNCiBFLiBK b2hhbnNzb24gWzxhIGhyZWY9Im1haWx0bzpvZWpAZWR2aW5hLm5ldCI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+bWFpbHRvOm9lakBlZHZpbmEubmV0PC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwg RGVjZW1iZXIgMjIsIDIwMTYgOTowOCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhy ZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+T2xsZSBFIEpv aGFuc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9lakBlZHZpbmEubmV0Ij48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5vZWpAZWR2aW5hLm5ldDwvc3Bhbj48L2E+Jmd0OzsgQ2hyaXN0ZXIgSG9s bWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTwvc3Bhbj48L2E+Jmd0OzsNCiBBZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBu b3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhbUBub3N0cnVtLmNvbTwv c3Bhbj48L2E+Jmd0OzsgU0lQQ09SRSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9h PiZndDs7IEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBub3N0cnVtLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVuQG5vc3RydW0uY29tPC9zcGFuPjwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlJlOiBbc2lwY29yZV0gUkVTUE9OU0UgUkVRVUVTVEVEOiBTSVBDT1JFIHdv cmsgYW5kIG1pbGVzdG9uZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMiBEZWMgMjAx NiwgYXQgMTQ6NTAsIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5A c29udXNuZXQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50YXN2ZXJlbkBzb251c25l dC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZGluZyB0aGUgaW50ZXJl c3QgaW4gU0lQL1VEUC9EVExTOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VGhpcyBpcyBtYWlubHkgYmFzZWQgb24gcHJvc3BlY3Qgb2YgbGFyZ2VyIHNj YWxhYmlsaXR5IG9uIHNlcnZlciBzaWRlLiBUaGVyZSBtYXkvbWF5IG5vdCBiZSBhbiBpbW1lZGlh dGUgbmVlZCB0byB0d2Vhay9jaGFuZ2UgdGhpbmdzIHRvIG1ha2UgRFRMUyByZWxhdGVkIHByb2Nl c3NpbmcgKGhvcGVmdWxseQ0KIGp1c3Qgb24gdGhlIGxvY2FsIHN0YWNrIGxldmVsIHJhdGhlciB0 aGFuIG9uIG9uLXRoZS13aXJlIHByb3RvY29sLSB3aXRoIHNvbWUgc3VwcG9ydGluZyBTSVAgZW5o YW5jZW1lbnRzKSBtb3JlIOKAnGZhaWxvdmVyIGZyaWVuZGx54oCdLiBUaGlzIGlzc3VlIHJlcXVp cmVzIG1vcmUgYW5hbHlzaXMvZGlzY3Vzc2lvbiBidXQgZG9lcyBub3Qgc291bmQgdW5zb2x2YWJs ZSBJTUhPLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZSB3aWxsIGhhdmUgdG8gc29sdmUgY2xpZW50IGNvbm5lY3Rpb24gcmV1c2UgZm9yIGJvdGggVExT IGFuZCBEVExTIHNlc3Npb25zIHRob3VnaC4gVW5sZXNzIHlvdSB3YW50IHRvIGhhdmU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmNsaWVudCBjZXJ0aWZpY2F0ZXMgb24gYWxsIGRldmljZXMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFk YW0gYXMgY2hhaXI6IFNJUCBDbGllbnQgQ29ubmVjdGlvbiBSZXVzZSBpcyBzb21ldGhpbmcgd2Xi gJl2ZSBkaXN1c3NlZCB1bmRlciBtdWx0aXBsZSBuYW1lcyAtIOKAnGhhbGYgb3V0Ym91bmTigJ0g b3Ig4oCcd2h5IGlzIDt0cmFuc3BvcnQ9dGxz4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5k ZXByZWNhdGVk4oCdIG9yIOKAnFdoeSBkb2VzbuKAmXQgU0lQIE91dGJvdW5kIGhhcHBlbj/igJ0u IE1heWJlIHRoYXQgZGVzZXJ2ZXMgYSBtaWxlc3RvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9PPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnNpcGNvcmUNCiBbPGEgaHJl Zj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkNocmlz dGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBEZWNlbWJlciAyMiwgMjAxNiA3OjM5IEFN PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5BZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhbUBub3N0cnVtLmNvbTwvc3Bhbj48L2E+Jmd0 OzsgJ1NJUENPUkUnICZsdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+c2lwY29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4N CjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+QmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5iZW5Abm9zdHJ1bS5jb208L3NwYW4+PC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+UmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUgd29yayBh bmQgbWlsZXN0b25lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHdpbGwgb2J2aW91c2x5IGJlIGFjdGl2ZWx5 IGludm9sdmVkIGluIDQpLCBhbmQgSSBhbHNvIGFncmVlIHRoYXQgNSkgc2hvdWxkIGJlIGRvbmUg YXMgaXQgaXMgYSBjb3JyZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BcyBmYXIgYXMgdGhl IG90aGVyIHBvdGVudGlhbCB3b3JrIGlzIGNvbmNlcm5lZCwgMykgaGFzIHRoZSBoaWdoZXN0IHBy aW9yaXR5IGZvciBtZSwgYW5kIEkgd291bGQgYWN0aXZlbHkgcGFydGljaXBhdGUgaW4gdGhhdCB3 b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHdvdWxkIHJldmlldyAxKSBhbmQgMiksIGJ1dCBJ IHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IG9uIDIpIGJlZm9y ZSB3ZSBhZ3JlZSB3aGV0aGVyIHRvIGNyZWF0ZSBhIG1pbGVzdG9uZSBmb3IgaXQuIEZvciBleGFt cGxlLCBJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUNCiBpbnB1dCBvbiBXSFkgdG8gZG8gaXQsIGFu ZCBIT1cgaXQgaXMgaW50ZW5kZWQgdG8gYmUgZGVwbG95ZWQgZXRjLiBIb3cgZG9lcyBEVExTIGZp dCBTSVA/IFdoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzPyBPUiwgZG8gd2Ugd2FudCB0byBzcGVjaWZ5 IERUTFMtZm9yLVNJUCBzaW1wbHkgYmVjYXVzZSBEVExTIGlzIOKAnGhvdOKAnT88L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+c2lwY29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9z cGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mICZxdW90OzxhIGhyZWY9Im1haWx0bzphZGFtQG5v c3RydW0uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGFtQG5vc3RydW0uY29tPC9z cGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGFtQG5vc3RydW0uY29tPC9zcGFuPjwvYT4mZ3Q7PGJy Pg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9iPlR1ZXNkYXkgMjAgRGVjZW1iZXIgMjAxNiBhdCAyMjoyNzxicj4NCjxiPlRvOjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEg aHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNp cGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNpcGNvcmVAaWV0Zi5v cmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJlbkBub3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVuQG5vc3RydW0u Y29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPltzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNU RUQ6IFNJUENPUkUgd29yayBhbmQgbWlsZXN0b25lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5bYXMgY2hhaXJdPGJyPg0KPGJyPg0KTm93IHRoYXQgd2UgaGF2ZSBvdXIgbmV3 IGNoYXJ0ZXIgYXBwcm92ZWQsIEknZCBsaWtlIHRoZSB3b3JraW5nIGdyb3VwIHRvIGhhdmUgYSBk aXNjdXNzaW9uIGFib3V0IHRoZSBzcGVjaWZpYyB3b3JrIGl0ZW1zIHRoYXQgd2Ugc2hvdWxkIHRh a2Ugb24gaW4gdGhlIHNob3J0LSB0byBtZWRpdW0tdGVybSBzbyB0aGF0IHdlIGNhbiByZXZpc2Ug b3VyIG1pbGVzdG9uZXMgYXBwcm9wcmlhdGVseS4gQmFzZWQgb24gcmVjZW50IGRpc2N1c3Npb25z IG9uIHRoZQ0KIG1haWxpbmcgbGlzdCwgdGhlIGZvbGxvd2luZyB0b3BpY3MgaGF2ZSBzb21lIG1p bmQtc2hhcmUgYmVoaW5kIHRoZW0uIFdoYXQgSSdkIGxpa2UgZnJvbSBldmVyeW9uZSB3aXRoIGFu IGludGVyZXN0IGluIGFueSBvZiB0aGVzZSB0b3BpY3MgaXMgdG8gaW5kaWNhdGUgKGEpIHdoZXRo ZXIgeW91IGFyZSB3aWxsaW5nIHRvIGFjdGl2ZWx5IHJldmlldyBhbmQgY29tbWVudCBvbiBkb2N1 bWVudHMgb24gdGhlIHRvcGljOyBhbmQgKGIpIHdoYXQgcHJpb3JpdHkNCiBlYWNoIHRhc2sgaGFz IHJlbGF0aXZlIHRvIGVhY2ggb3RoZXI6IHRoZXJlIGFyZSBmaXZlIHRvcGljczsgcGxlYXNlIGlu ZGljYXRlIGEgdW5pcXVlIHByaW9yaXR5IGZyb20gb25lIChtb3N0IGltcG9ydGFudCkgdG8gZml2 ZSAobGVhc3QgaW1wb3J0YW50KSBmb3IgZWFjaCB0b3BpYy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8xIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZxdW90O0hhcHB5IEV5ZWJhbGxzIGZvciBTSVAmcXVvdDsgKGFrYSBIYXBweSBFYXJi YWxscyksIGN1cnJlbnRseSB1bmRlciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Ljwvc3Bhbj48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZl bDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtEVExTIFRyYW5zcG9ydCBmb3IgU0lQJnF1 b3Q7LCBhcyBwcm9wb3NlZCBieSBUb2xnYSBBc3ZlcmVuJ3MgcmVjZW50IG1lc3NhZ2VzLjwvc3Bh bj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDps MSBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BIG1lY2hhbmlzbSBmb3IgbGFiZWxpbmcg dGhlIG5hdHVyZSBvZiBTSVAgY2FsbHMsIHdpdGggJmx0O2RyYWZ0LXNjaHVsenJpbm5lLXNpcGNv cmUtY2FsbGluZm8tc3BhbSZndDsgYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBs ZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GaXhpbmcgQ29udGVudC1JRCBpbiBTSVAsIGFz IGRpc2N1c3NlZCBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNv cmUvY3VycmVudC9tc2cwNzI0NS5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNn MDcyNDUuaHRtbCZndDs8L3NwYW4+PC9hPiwNCiB3aXRoICZsdDtkcmFmdC1ob2xtYmVyZy1zaXBj b3JlLWNvbnRlbnQtaWQmZ3Q7IGFzIGEgbGlrZWx5IGNhbmRpZGF0ZSBkcmFmdC48L3NwYW4+PG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2xhcmlmaWNhdGlvbnMgYXJvdW5kIFNJUCBuYW1l LWFkZHIsIHdpdGggJmx0O2RyYWZ0LXNwYXJrcy1zaXBjb3JlLW5hbWUtYWRkci1ndWlkYW5jZSZn dDsgYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L29s Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48YnI+DQpJIHdpbGwgYWxzbyBub3RlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGRlY2xhcmVk IGNvbnNlbnN1cyBvbiBhZG9wdGluZyAmbHQ7ZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndh bnRlZCZndDsgYXMgYSBXRyBkb2N1bWVudCwgYW5kIHdpbGwgYmUgYWRkaW5nIGFuIGFzc29jaWF0 ZWQgbWlsZXN0b25lLiBJIHdhbnQgdG8gdGFrZSB0aGlzIG9wcG9ydHVuaXR5IHRvIHJlbWluZCBw ZW9wbGUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgaW4gV0dMQywgYW5kIHlvdXIgY29tbWVudHMNCiBh cmUgc3Ryb25nbHkgZW5jb3VyYWdlZCwgdGhlIGVhcmxpZXIgdGhlIGJldHRlci48YnI+DQo8YnI+ DQpQbGVhc2UgcmVzcG9uZCBiZWZvcmUgdGhlIGVuZCBvZiAyMDE2LiBUaGFua3MhPGJyPg0KPGJy Pg0KVGhhbmtzITxicj4NCjxicj4NCi9hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4N Cjwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6cHVycGxlIj5zaXBjb3JlQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN2PR03MB2350C16785A81C21DEC8A9E2B2950SN2PR03MB2350namp_-- From nobody Fri Dec 23 08:30:59 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B44312988C for ; Fri, 23 Dec 2016 08:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 d5z8FMfslPi1 for ; Fri, 23 Dec 2016 08:30:55 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0056.outbound.protection.outlook.com [104.47.40.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EAB129880 for ; Fri, 23 Dec 2016 08:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ualk7zZaJwVdV1dweR/R8nl4XoTwBHJblpE2FCQ8L/I=; b=MSDB+NzuGfAdbIGZSVxlGrkqVI6PAzYPcAnmQd+sgI6qqPQ4JLJAtuBPhVJPGa1dm++K4f4PWnhgmpkD8UmM04ntK1SXyng6tks+DHCcTWXCIKv/SjU18pmnMM4v6S7G70cCa6vXXW58WaejzEbHxOLMusIWlyX1KODuY601OZg= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Fri, 23 Dec 2016 16:30:52 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.015; Fri, 23 Dec 2016 16:30:52 +0000 From: "Asveren, Tolga" To: "Asveren, Tolga" , "Olle E. Johansson" Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv96++N6DRIq/E2cKGNWf6YDKaET6r4AgAAS3iCAAAYCAIAAF0yAgAAGmwCAABLYMIAAA+sAgADDHnCAAFn5gA== Date: Fri, 23 Dec 2016 16:30:52 +0000 Message-ID: References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:di6z2DTqQmD+aJhySDCwLosiY0OMDPSn66Yl66x9t77wObHjnwc6ExVsa/KTb0siQt2JCYaClQO3NO8M3sc48q1/n34yYRCfLqJddTuHVV9E/uqBJ2ArMqDa50hsODRqqdEMm5l2PizGSTSmmFeyYQPi7mx1vANNQZX34cab3hp1MLufwOZ3pz1jJigob8+pq/xjq9RDFsXpja2lxnCjpKbQ8+Iq4WxkZ93pSbnAJL7NkLFsTK6OLphQEBIt8sdyIdBgA+Znl77Qlc6MMaxzVV3IaPnkkiZNAEHggCgVf1GHSwi3mkk7x10WkBgbEup86EyhajJ6U3IHE5Xekx3S4QpRtnCkgjBtOQdUZ9DjuFmq+B8DghB/X6lF2URpfM1dFOfQkscQLX3wb2U8eWQj4zpvMjuHbVuKgnSd0CSmQS8uQX0JcSZhbkX9SfVQRtbr6Fwy2Ds87gG7Ao/iS4H63Q== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(39410400002)(39830400002)(39450400003)(24454002)(377454003)(51914003)(189002)(199003)(101416001)(6506006)(38730400001)(551934003)(7736002)(2950100002)(2900100001)(6116002)(3846002)(790700001)(93886004)(102836003)(5001770100001)(105586002)(4326007)(106116001)(77096006)(25786008)(50986999)(229853002)(6436002)(33656002)(106356001)(92566002)(54356999)(7696004)(99286002)(5660300001)(606005)(86362001)(97736004)(76176999)(9686002)(122556002)(66066001)(3280700002)(8936002)(3660700001)(81156014)(81166006)(8676002)(76576001)(19609705001)(2906002)(189998001)(68736007)(74316002)(7906003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 89046ed5-cb12-4e62-4ac4-08d42b510fd2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(192374486261705)(100405760836317)(178636050973902)(21748063052155)(132712982866762); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 016572D96D received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235040DBC76ABA8BC4EED379B2950SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2016 16:30:52.2266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Cc: Ben Campbell , SIPCORE Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 16:30:58 -0000 --_000_SN2PR03MB235040DBC76ABA8BC4EED379B2950SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QlRXLCBTSVAvVURQL0RUTFMgaGFzIGFuIGFkdmFudGFnZSBvdmVyIFNJUC9UQ1AvVExTIGV2ZW4g d2l0aG91dCB0aGUgcG9zc2libGUgaW1wcm92ZW1lbnRzIEkgbWVudGlvbmVkIGJlbG93OiBJdCBk b2VzIG5vdCByZXF1aXJlIGVzdGFibGlzaG1lbnQgb2YgYSBuZXcgVENQIGNvbm5lY3Rpb24uIFRo aXMgcGFydGljdWxhcmx5IGlzIGltcG9ydGFudCBmb3Igc2VydmVyIGZhaWxvdmVyIHNjZW5hcmlv cyBhcyBpdCB3b3VsZCBkZWNyZWFzZSB0aGUgYW1vdW50IG9mIHdvcmsgdG8gYmUgZG9uZSBieSB0 aGUgc3RhbmRieSBzZXJ2ZXIgYWZ0ZXIgaXQgYmVjYW1lIGFjdGl2ZSBhbmQgYWxzbyB3b3VsZCBj dXQgdGhlIG92ZXJhbGwgbnVtYmVyIG9mIHJvdW5kLXRyaXBzIG5lZWRlZCB0byByZXN1bWUgY29t bXVuaWNhdGlvbiB0b3dhcmQvZnJvbSBhIFVFLg0KDQpBbmQgYW5vdGhlciBzaWRlIGJlbmVmaXQg aXMgdGhhdCBTSVAvVURQIGlzIGxlc3Mg4oCcdmljdGltaXplZOKAnSB0aGFuIFNJUC9UQ1Agb24g Y29uZ2VzdGVkIGxpbmtzLCBlLmcuIHBvb3IvY29uZ2VzdGVkIG1vYmlsZSBjb3ZlcmFnZSBhcmVh cy4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFzdmVyZW4sIFRvbGdhDQpTZW50OiBGcmlkYXks IERlY2VtYmVyIDIzLCAyMDE2IDM6MzEgQU0NClRvOiBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVk dmluYS5uZXQ+DQpDYzogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+OyBTSVBDT1JFIDxz aXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNU RUQ6IFNJUENPUkUgd29yayBhbmQgbWlsZXN0b25lcw0KDQppLSBJIGFncmVlIHdpdGggdGhlIG5l ZWQgdG8g4oCcc3RhbmRhcmRpemXigJ0gdGhlIOKAnGNvbm5lY3Rpb24gcmV1c2UgcGVyIGV4aXN0 aW5nIGRlcGxveW1lbnQgc2VtYW50aWNz4oCdLiAgSSB0aGluayB3aGF0IHdlIGFyZSBsb29raW5n IGZvciBpczoNCg0KLSAgICAgICAgICBCaWRpcmVjdGlvbmFsIGNvbm5lY3Rpb24gcmV1c2Ugd2l0 aCBUTFMvc2VydmVyLXNpZGUgb25seSBjZXJ0aWZpY2F0ZS9VRSBhdXRoZW50aWNhdGlvbiBwZXIg U0lQIHJlZ2lzdHJhdGlvbiB3aXRob3V0IFJGQzU2MjYNCg0KLSAgICAgICAgICBCaWRpcmVjdGlv bmFsIGNvbm5lY3Rpb24gcmV1c2Ugd2l0aCBUQ1Agb3ZlciBWUE4sIGUuZy4gSVBTZWMNCg0KLSAg ICAgICAgICBCaWRpcmVjdGlvbmFsIGNvbm5lY3Rpb24gcmV1c2Ugd2l0aCBUQ1Agd2hlbiBhdXRo ZW50aWNhdGlvbi9zZWN1cml0eSBpcyBwcm92aWRlZCBieSBMMg0KDQpJIGFtIG5vdCBzdXJlIHdo YXQgd291bGQgYmUgdGhlIGJlc3QgcGxhY2UgdG8gYWRkcmVzcyB0aGVzZS4gSXQgY291bGQgYmUg ZWl0aGVyIGhhcHB5LWVhcmJhbGxzIG9yIGEgbmV3IGRvY3VtZW50LiBJIHdvdWxkIHByZWZlciB0 aGUgZm9ybWVyIGFuZCBjYW4gcHJvdmlkZSB0ZXh0IGluIGVpdGhlciBjYXNlLg0KDQppaS0gVGhl IGlzc3VlIHdpdGggU0lQL1VEUC9EVExTIGlzIHNvbWV0aGluZyBxdWl0ZSBkaWZmZXJlbnQuIEl0 IHJlYWxseSBpcyBtb3JlIGFib3V0IHByb3ZpZGluZyBmYXN0L3ByYWN0aWNhbGx5IGZlYXNpYmxl IGZhaWxvdmVyIGZvciBEVExTIGNvbm5lY3Rpb25zIChpbiBhZGRpdGlvbiB0byBkZWZpbmluZyB1 c2Ugb2YgVURQL0RUTFMgYXMgYSBuZXcgdHJhbnNwb3J0IGZvciBTSVAgYnV0IHRoaXMgcGFydCBp cyByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZCBJTUhPKS4gSW4gYW55IGNhc2UsIGxldCBtZSB1 c2UgdGhpcyBvcHBvcnR1bml0eSB0byBleHByZXNzIG15IHN0cm9uZyBpbnRlcmVzdCBpbiB0aGlz IHdvcmsgb25lIG1vcmUgdGltZS4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogT2xsZSBFLiBK b2hhbnNzb24gW21haWx0bzpvZWpAZWR2aW5hLm5ldF0NClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJl ciAyMiwgMjAxNiAxMjoxNyBQTQ0KVG86IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25l dC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+DQpDYzogT2xsZSBFIEpvaGFuc3Nv biA8b2VqQGVkdmluYS5uZXQ8bWFpbHRvOm9lakBlZHZpbmEubmV0Pj47IENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT4+OyBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzph ZGFtQG5vc3RydW0uY29tPj47IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNv cmVAaWV0Zi5vcmc+PjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBu b3N0cnVtLmNvbT4+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RFRDog U0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzDQoNCg0KT24gMjIgRGVjIDIwMTYsIGF0IDE4OjA4 LCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBz b251c25ldC5jb20+PiB3cm90ZToNCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCg0K aS0gSSBhZ3JlZSB0aGF0IGNvbm5lY3Rpb24gcmUtdXNlIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBh cyBpdCB3b3VsZCBiZSBhIG5vcm1hdGl2ZSBjaGFuZ2UuDQppaS0gSXMgaXQgYSBtYW5kYXRlIHRo YXQgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIG5lZWRzIHRvIGJlIHVzZWQgaWYgdHJhbnNwb3J0PXRs cz8gSWYgc28sIHRoYXQgd291bGQgcmVxdWlyZSBhbm90aGVyIG5vcm1hdGl2ZSBjaGFuZ2UgdG8g YWxpZ24gd2l0aCBwcmFjdGljYWwgbmVlZHMuDQpUaGUgVVJJIGZvciB0aGUgdGFyZ2V0IGFuZCB0 aGUgY2VydCBmb3IgdGhlIFVBIHNlcnZlciBuZWVkcyB0byBtYXRjaC4gSXTigJlzIG5vdCBtdXR1 YWwgLSB0d28gY2VydHMgaW4gdGhlIHNhbWUgVExTIHNlc3Npb24sIGJ1dCB0aGF0IHdvdWxkIGFs c28NCmJlIG9uZSBzb2x1dGlvbiAodGhlcmUgaXMgYSBSRkMgZm9yIHRoYXQpLiBTSVAgT3V0Ym91 bmQgcGVybWl0cyByZXVzZSBvZiB0aGUgaW5jb21pbmcgY29ubmVjdGlvbiBhbmQgdGh1cw0KYXZv aWRzIHRoaXMgcGFydGljdWxhciBwcm9ibGVtLg0KDQppaWktIEkgdGhpbmsgYm90aCBpLS9paS0g YXJlIHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3YXJkIHRvIGFkZHJlc3MuIFRoZSBtb3JlIGludGVy ZXN0aW5nL2NoYWxsZW5naW5nIGFzcGVjdCBpcyBob3cgdG8gZmFpbG92ZXIgRFRMUyBjb25uZWN0 aW9ucyB3aXRob3V0IGEgbmVlZCBmb3IgcGVyLXRyYW5zYWN0aW9uIHN0YXRlIHN5bmNocm9uaXph dGlvbiBhbmQgd2l0aCB0aGUgZmV3ZXN0IHJvdW5kLXRyaXBzIHBvc3NpYmxlLg0KQ29ubmVjdGlv biByZXVzZSBuZWVkcyB0byBiZSBoYW5kbGVkIHNlcGFyYXRlbHkgYW5kIG5lZWRzIHRvIGJlIHNv bWV0aGluZyB0aGF0IGlzIHdheSBtb3JlIGVhc3kgdG8gaW1wbGVtZW50IHRoYW4gU0lQIG91dGJv dW5kLg0KV2UgbmVlZCBzb21ldGhpbmcgd2UgY2FuIGVhc2lseSB0ZXN0IGFuZCBnZXQgaXQgZG9u ZSBzb29uLCBhcyBJIHdhbnQgbW9yZSBUTFMgb24gdGhlIFNJUCBuZXR3b3JrcyBvdXQgdGhlcmUg Oi0pDQoNClRoZSBjdXJyZW50IHdheSB0byBoYW5kbGUgdGhpcyBpcyBjb25uZWN0aW9uIHJldXNl IHRoYXQgYnJlYWtzIHRoZSBSRkNzLCB3ZSBoYXZlIHRoYXQgaW1wbGVtZW50YXRpb24gaW4gS2Ft YWlsaW8uDQpJZiB0aGVyZSBpcyBhbiBvcGVuIHNvY2tldCwgVExTIG9yIFRDUCwgd2UgcHJlZmVy IHRvIHVzZSBpdCB0byBtYWtlIHRoaW5ncyB3b3JrLiBJIHdvdWxkIGxvdmUgZm9yIHRoaXMgdG8g YmUgUkZDIGNvbXBsaWFudCA6LSkNCg0KL08NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogT2xs ZSBFLiBKb2hhbnNzb24gW21haWx0bzpvZWpAZWR2aW5hLm5ldF0NClNlbnQ6IFRodXJzZGF5LCBE ZWNlbWJlciAyMiwgMjAxNiAxMDo1NSBBTQ0KVG86IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBz b251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+DQpDYzogT2xsZSBFIEpv aGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ8bWFpbHRvOm9lakBlZHZpbmEubmV0Pj47IENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPG1h aWx0bzphZGFtQG5vc3RydW0uY29tPj47IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRv OnNpcGNvcmVAaWV0Zi5vcmc+PjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb208bWFpbHRv OmJlbkBub3N0cnVtLmNvbT4+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFJFU1BPTlNFIFJFUVVF U1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzDQoNCg0KT24gMjIgRGVjIDIwMTYsIGF0 IDE2OjM0LCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2 ZXJlbkBzb251c25ldC5jb20+PiB3cm90ZToNCg0KT2xsZSwNCg0KSSBtaXNzZWQgdGhlIHBvaW50 IGFib3V0IHdoeSDigJxwcmFjdGljYWxseSBwb3NzaWJsZSBmYWlsb3ZlcuKAnSBuZWVkcyB0byBi ZSBzb2x2ZWQgYm90aCBmb3IgVExTL0RUTFMgKEkgYW0gbm90IGFyZ3VpbmcgaXQgd291bGQgYmUg Z29vZCB0byBoYXZlIGEgc29sdXRpb24gZm9yIGJvdGgpIGFuZCBhbHNvIHdoYXQgdGhpcyBpc3N1 ZSBpbiBnZW5lcmFsIGhhcyBzb21ldGhpbmcgdG8gZG8gd2l0aCBjbGllbnQgY2VydGlmaWNhdGVz Lg0KQ291bGQgeW91IHByb3ZpZGUgYSBiaXQgbW9yZSBpbmZvcm1hdGlvbi9jbGFyaWZpY2F0aW9u cz8NCg0KV2XigJl2ZSBkaXNjdXNzZWQgaXQgYSBudW1iZXIgb2YgdGltZXMgYm90aCBoZXJlIGFu ZCBvbiB0aGUgU0lQIEZvcnVtIHRlY2h3ZyBtYWlsaW5nIGxpc3QuIFlvdSBjYW4gZmluZCBzdW1t YXJpZXMgaGVyZToNCg0KaHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC9vZWovc2lwLWhhbGYtb3V0 Ym91bmQtcmFuZG9tLW5vdGVzDQpodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L29lai9zaXAtdGxz LXNlY3VyaXR5LWluLWEtcGVlci10by1wZWVyLXdvcmxkDQoNCkluIHNob3J0LCB3aXRob3V0IFNJ UCBPdXRib3VuZCB0aGUgY2xpZW50IGNvbm5lY3Rpb24gY2Fu4oCZdCBiZSByZS11c2VkIGZvciBv dXRib3VuZCByZXF1ZXN0cy4gU2VlbXMgbGlrZSB0aGVyZSBpcyBhIGh1Z2UNCnJlc2lzdGFuY2Ug dG8gaW1wbGVtZW50IFNJUCBPdXRib3VuZC4gV2UgbmVlZCBhIHdheSBmb3IgdGhlIGNsaWVudCB0 byBhbGxvdyB0aGUgc2VydmVyIHRvIHJldXNlIHRoZSBpbmJvdW5kIGNvbm5lY3Rpb24NCmZvciBv dXRib3VuZCByZXF1ZXN0cyBldmVuIHRob3VnaCB0aGVyZeKAmXMgbm8gVExTIGNlcnRpZmljYXRl IG1hdGNoaW5nIHRoZSBVUkkgb24gdGhlIGNsaWVudCBzaWRlLg0KDQpXZeKAmXZlIGhhZCBhIGxv dCBvZiBjbGllbnRzIHJlZ2lzdGVyIHdpdGgg4oCcO3RyYW5zcG9ydD10bHPigJ0gYXQgU0lQaXQg d2l0aG91dCBhIGNsaWVudCBjZXJ0IC0gd2hpY2ggbWVhbnMgd2UgY2Fu4oCZdCBjb21tdW5pY2F0 ZQ0KYmFzZWQgb24gdGhhdCByZWdpc3RyYXRpb24uDQoNCkNoZWVycywNCi9PDQoNCg0KVGhhbmtz LA0KVG9sZ2ENCg0KRnJvbTogT2xsZSBFLiBKb2hhbnNzb24gW21haWx0bzpvZWpAZWR2aW5hLm5l dF0NClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMiwgMjAxNiA5OjA4IEFNDQpUbzogQXN2ZXJl biwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tPj4NCkNjOiBPbGxlIEUgSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldDxtYWlsdG86b2VqQGVk dmluYS5uZXQ+PjsgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47IEFkYW0gUm9hY2gg PGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+PjsgU0lQQ09SRSA8c2lw Y29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4+OyBCZW4gQ2FtcGJlbGwgPGJl bkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3RydW0uY29tPj4NClN1YmplY3Q6IFJlOiBbc2lw Y29yZV0gUkVTUE9OU0UgUkVRVUVTVEVEOiBTSVBDT1JFIHdvcmsgYW5kIG1pbGVzdG9uZXMNCg0K DQpPbiAyMiBEZWMgMjAxNiwgYXQgMTQ6NTAsIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251 c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KDQpSZWdhcmRp bmcgdGhlIGludGVyZXN0IGluIFNJUC9VRFAvRFRMUzoNClRoaXMgaXMgbWFpbmx5IGJhc2VkIG9u IHByb3NwZWN0IG9mIGxhcmdlciBzY2FsYWJpbGl0eSBvbiBzZXJ2ZXIgc2lkZS4gVGhlcmUgbWF5 L21heSBub3QgYmUgYW4gaW1tZWRpYXRlIG5lZWQgdG8gdHdlYWsvY2hhbmdlIHRoaW5ncyB0byBt YWtlIERUTFMgcmVsYXRlZCBwcm9jZXNzaW5nIChob3BlZnVsbHkganVzdCBvbiB0aGUgbG9jYWwg c3RhY2sgbGV2ZWwgcmF0aGVyIHRoYW4gb24gb24tdGhlLXdpcmUgcHJvdG9jb2wtIHdpdGggc29t ZSBzdXBwb3J0aW5nIFNJUCBlbmhhbmNlbWVudHMpIG1vcmUg4oCcZmFpbG92ZXIgZnJpZW5kbHni gJ0uIFRoaXMgaXNzdWUgcmVxdWlyZXMgbW9yZSBhbmFseXNpcy9kaXNjdXNzaW9uIGJ1dCBkb2Vz IG5vdCBzb3VuZCB1bnNvbHZhYmxlIElNSE8uDQpXZSB3aWxsIGhhdmUgdG8gc29sdmUgY2xpZW50 IGNvbm5lY3Rpb24gcmV1c2UgZm9yIGJvdGggVExTIGFuZCBEVExTIHNlc3Npb25zIHRob3VnaC4g VW5sZXNzIHlvdSB3YW50IHRvIGhhdmUNCmNsaWVudCBjZXJ0aWZpY2F0ZXMgb24gYWxsIGRldmlj ZXMuDQoNCkFkYW0gYXMgY2hhaXI6IFNJUCBDbGllbnQgQ29ubmVjdGlvbiBSZXVzZSBpcyBzb21l dGhpbmcgd2XigJl2ZSBkaXN1c3NlZCB1bmRlciBtdWx0aXBsZSBuYW1lcyAtIOKAnGhhbGYgb3V0 Ym91bmTigJ0gb3Ig4oCcd2h5IGlzIDt0cmFuc3BvcnQ9dGxz4oCdDQpkZXByZWNhdGVk4oCdIG9y IOKAnFdoeSBkb2VzbuKAmXQgU0lQIE91dGJvdW5kIGhhcHBlbj/igJ0uIE1heWJlIHRoYXQgZGVz ZXJ2ZXMgYSBtaWxlc3RvbmUuDQoNCi9PDQoNCg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBz aXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hy aXN0ZXIgSG9sbWJlcmcNClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMiwgMjAxNiA3OjM5IEFN DQpUbzogQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNv bT4+OyAnU0lQQ09SRScgPHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+ Pg0KQ2M6IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5j b20+Pg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUg d29yayBhbmQgbWlsZXN0b25lcw0KDQpIaSwNCg0KSSB3aWxsIG9idmlvdXNseSBiZSBhY3RpdmVs eSBpbnZvbHZlZCBpbiA0KSwgYW5kIEkgYWxzbyBhZ3JlZSB0aGF0IDUpIHNob3VsZCBiZSBkb25l IGFzIGl0IGlzIGEgY29ycmVjdGlvbi4NCg0KQXMgZmFyIGFzIHRoZSBvdGhlciBwb3RlbnRpYWwg d29yayBpcyBjb25jZXJuZWQsIDMpIGhhcyB0aGUgaGlnaGVzdCBwcmlvcml0eSBmb3IgbWUsIGFu ZCBJIHdvdWxkIGFjdGl2ZWx5IHBhcnRpY2lwYXRlIGluIHRoYXQgd29yay4NCg0KSSB3b3VsZCBy ZXZpZXcgMSkgYW5kIDIpLCBidXQgSSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUgYW4gaW5kaXZp ZHVhbCBkcmFmdCBvbiAyKSBiZWZvcmUgd2UgYWdyZWUgd2hldGhlciB0byBjcmVhdGUgYSBtaWxl c3RvbmUgZm9yIGl0LiBGb3IgZXhhbXBsZSwgSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIGlucHV0 IG9uIFdIWSB0byBkbyBpdCwgYW5kIEhPVyBpdCBpcyBpbnRlbmRlZCB0byBiZSBkZXBsb3llZCBl dGMuIEhvdyBkb2VzIERUTFMgZml0IFNJUD8gV2hhdCBhcmUgdGhlIGFkdmFudGFnZXM/IE9SLCBk byB3ZSB3YW50IHRvIHNwZWNpZnkgRFRMUy1mb3ItU0lQIHNpbXBseSBiZWNhdXNlIERUTFMgaXMg 4oCcaG904oCdPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBzaXBjb3JlIDxzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiAiYWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4iIDxh ZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj4NCkRhdGU6IFR1ZXNkYXkg MjAgRGVjZW1iZXIgMjAxNiBhdCAyMjoyNw0KVG86ICJzaXBjb3JlQGlldGYub3JnPG1haWx0bzpz aXBjb3JlQGlldGYub3JnPiIgPHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5v cmc+Pg0KQ2M6IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1 bS5jb20+Pg0KU3ViamVjdDogW3NpcGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3 b3JrIGFuZCBtaWxlc3RvbmVzDQoNClthcyBjaGFpcl0NCg0KTm93IHRoYXQgd2UgaGF2ZSBvdXIg bmV3IGNoYXJ0ZXIgYXBwcm92ZWQsIEknZCBsaWtlIHRoZSB3b3JraW5nIGdyb3VwIHRvIGhhdmUg YSBkaXNjdXNzaW9uIGFib3V0IHRoZSBzcGVjaWZpYyB3b3JrIGl0ZW1zIHRoYXQgd2Ugc2hvdWxk IHRha2Ugb24gaW4gdGhlIHNob3J0LSB0byBtZWRpdW0tdGVybSBzbyB0aGF0IHdlIGNhbiByZXZp c2Ugb3VyIG1pbGVzdG9uZXMgYXBwcm9wcmlhdGVseS4gQmFzZWQgb24gcmVjZW50IGRpc2N1c3Np b25zIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHRoZSBmb2xsb3dpbmcgdG9waWNzIGhhdmUgc29tZSBt aW5kLXNoYXJlIGJlaGluZCB0aGVtLiBXaGF0IEknZCBsaWtlIGZyb20gZXZlcnlvbmUgd2l0aCBh biBpbnRlcmVzdCBpbiBhbnkgb2YgdGhlc2UgdG9waWNzIGlzIHRvIGluZGljYXRlIChhKSB3aGV0 aGVyIHlvdSBhcmUgd2lsbGluZyB0byBhY3RpdmVseSByZXZpZXcgYW5kIGNvbW1lbnQgb24gZG9j dW1lbnRzIG9uIHRoZSB0b3BpYzsgYW5kIChiKSB3aGF0IHByaW9yaXR5IGVhY2ggdGFzayBoYXMg cmVsYXRpdmUgdG8gZWFjaCBvdGhlcjogdGhlcmUgYXJlIGZpdmUgdG9waWNzOyBwbGVhc2UgaW5k aWNhdGUgYSB1bmlxdWUgcHJpb3JpdHkgZnJvbSBvbmUgKG1vc3QgaW1wb3J0YW50KSB0byBmaXZl IChsZWFzdCBpbXBvcnRhbnQpIGZvciBlYWNoIHRvcGljLg0KDQogIDEuICAiSGFwcHkgRXllYmFs bHMgZm9yIFNJUCIgKGFrYSBIYXBweSBFYXJiYWxscyksIGN1cnJlbnRseSB1bmRlciBkaXNjdXNz aW9uIG9uIHRoZSBsaXN0Lg0KICAyLiAgIkRUTFMgVHJhbnNwb3J0IGZvciBTSVAiLCBhcyBwcm9w b3NlZCBieSBUb2xnYSBBc3ZlcmVuJ3MgcmVjZW50IG1lc3NhZ2VzLg0KICAzLiAgQSBtZWNoYW5p c20gZm9yIGxhYmVsaW5nIHRoZSBuYXR1cmUgb2YgU0lQIGNhbGxzLCB3aXRoIDxkcmFmdC1zY2h1 bHpyaW5uZS1zaXBjb3JlLWNhbGxpbmZvLXNwYW0+IGFzIGEgbGlrZWx5IGNhbmRpZGF0ZSBkcmFm dC4NCiAgNC4gIEZpeGluZyBDb250ZW50LUlEIGluIFNJUCwgYXMgZGlzY3Vzc2VkIGluIDxodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNzI0 NS5odG1sPjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3Vy cmVudC9tc2cwNzI0NS5odG1sPiwgd2l0aCA8ZHJhZnQtaG9sbWJlcmctc2lwY29yZS1jb250ZW50 LWlkPiBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQuDQogIDUuICBDbGFyaWZpY2F0aW9ucyBh cm91bmQgU0lQIG5hbWUtYWRkciwgd2l0aCA8ZHJhZnQtc3BhcmtzLXNpcGNvcmUtbmFtZS1hZGRy LWd1aWRhbmNlPiBhcyBhIGxpa2VseSBjYW5kaWRhdGUgZHJhZnQNCg0KSSB3aWxsIGFsc28gbm90 ZSB0aGF0IHdlIGhhdmUgYWxyZWFkeSBkZWNsYXJlZCBjb25zZW5zdXMgb24gYWRvcHRpbmcgPGRy YWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQ+IGFzIGEgV0cgZG9jdW1lbnQsIGFuZCB3 aWxsIGJlIGFkZGluZyBhbiBhc3NvY2lhdGVkIG1pbGVzdG9uZS4gSSB3YW50IHRvIHRha2UgdGhp cyBvcHBvcnR1bml0eSB0byByZW1pbmQgcGVvcGxlIHRoYXQgdGhlIGRvY3VtZW50IGlzIGluIFdH TEMsIGFuZCB5b3VyIGNvbW1lbnRzIGFyZSBzdHJvbmdseSBlbmNvdXJhZ2VkLCB0aGUgZWFybGll ciB0aGUgYmV0dGVyLg0KDQpQbGVhc2UgcmVzcG9uZCBiZWZvcmUgdGhlIGVuZCBvZiAyMDE2LiBU aGFua3MhDQoNClRoYW5rcyENCg0KL2ENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxt YWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZQ0KDQo= --_000_SN2PR03MB235040DBC76ABA8BC4EED379B2950SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28t c3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwNjk3MjMzNDM7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xMzIyMzY4NzQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QlRXLCBTSVAvVURQL0RUTFMgaGFzIGFuIGFk dmFudGFnZSBvdmVyIFNJUC9UQ1AvVExTIGV2ZW4gd2l0aG91dCB0aGUgcG9zc2libGUgaW1wcm92 ZW1lbnRzIEkgbWVudGlvbmVkIGJlbG93OiBJdCBkb2VzIG5vdCByZXF1aXJlIGVzdGFibGlzaG1l bnQgb2YgYSBuZXcgVENQIGNvbm5lY3Rpb24uIFRoaXMNCiBwYXJ0aWN1bGFybHkgaXMgaW1wb3J0 YW50IGZvciBzZXJ2ZXIgZmFpbG92ZXIgc2NlbmFyaW9zIGFzIGl0IHdvdWxkIGRlY3JlYXNlIHRo ZSBhbW91bnQgb2Ygd29yayB0byBiZSBkb25lIGJ5IHRoZSBzdGFuZGJ5IHNlcnZlciBhZnRlciBp dCBiZWNhbWUgYWN0aXZlIGFuZCBhbHNvIHdvdWxkIGN1dCB0aGUgb3ZlcmFsbCBudW1iZXIgb2Yg cm91bmQtdHJpcHMgbmVlZGVkIHRvIHJlc3VtZSBjb21tdW5pY2F0aW9uIHRvd2FyZC9mcm9tIGEg VUUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkFuZCBhbm90aGVyIHNpZGUgYmVuZWZpdCBpcyB0aGF0IFNJUC9V RFAgaXMgbGVzcyDigJx2aWN0aW1pemVk4oCdIHRoYW4gU0lQL1RDUCBvbiBjb25nZXN0ZWQgbGlu a3MsIGUuZy4gcG9vci9jb25nZXN0ZWQgbW9iaWxlIGNvdmVyYWdlIGFyZWFzLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFzdmVyZW4sIFRvbGdhPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgRGVjZW1iZXIgMjMsIDIwMTYgMzozMSBBTTxicj4NCjxiPlRvOjwvYj4gT2xs ZSBFLiBKb2hhbnNzb24gJmx0O29lakBlZHZpbmEubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQmVu IENhbXBiZWxsICZsdDtiZW5Abm9zdHJ1bS5jb20mZ3Q7OyBTSVBDT1JFICZsdDtzaXBjb3JlQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIFJFU1BPTlNFIFJF UVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5pLSBJIGFncmVlIHdp dGggdGhlIG5lZWQgdG8g4oCcc3RhbmRhcmRpemXigJ0gdGhlIOKAnGNvbm5lY3Rpb24gcmV1c2Ug cGVyIGV4aXN0aW5nIGRlcGxveW1lbnQgc2VtYW50aWNz4oCdLiAmbmJzcDtJIHRoaW5rIHdoYXQg d2UgYXJlIGxvb2tpbmcgZm9yIGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4y NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CaWRpcmVjdGlvbmFsIGNvbm5lY3Rpb24gcmV1c2Ug d2l0aCBUTFMvc2VydmVyLXNpZGUgb25seSBjZXJ0aWZpY2F0ZS9VRSBhdXRoZW50aWNhdGlvbiBw ZXIgU0lQIHJlZ2lzdHJhdGlvbiB3aXRob3V0IFJGQzU2MjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43NWluO3Rl eHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QmlkaXJlY3Rpb25hbCBjb25u ZWN0aW9uIHJldXNlIHdpdGggVENQIG92ZXIgVlBOLCBlLmcuIElQU2VjPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDou NzVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJpZGlyZWN0aW9u YWwgY29ubmVjdGlvbiByZXVzZSB3aXRoIFRDUCB3aGVuIGF1dGhlbnRpY2F0aW9uL3NlY3VyaXR5 IGlzIHByb3ZpZGVkIGJ5IEwyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYW0gbm90IHN1cmUgd2hhdCB3b3Vs ZCBiZSB0aGUgYmVzdCBwbGFjZSB0byBhZGRyZXNzIHRoZXNlLiBJdCBjb3VsZCBiZSBlaXRoZXIg aGFwcHktZWFyYmFsbHMgb3IgYSBuZXcgZG9jdW1lbnQuIEkgd291bGQgcHJlZmVyIHRoZSBmb3Jt ZXIgYW5kIGNhbiBwcm92aWRlIHRleHQgaW4gZWl0aGVyIGNhc2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlp LSBUaGUgaXNzdWUgd2l0aCBTSVAvVURQL0RUTFMgaXMgc29tZXRoaW5nIHF1aXRlIGRpZmZlcmVu dC4gSXQgcmVhbGx5IGlzIG1vcmUgYWJvdXQgcHJvdmlkaW5nIGZhc3QvcHJhY3RpY2FsbHkgZmVh c2libGUgZmFpbG92ZXIgZm9yIERUTFMgY29ubmVjdGlvbnMgKGluIGFkZGl0aW9uIHRvIGRlZmlu aW5nDQogdXNlIG9mIFVEUC9EVExTIGFzIGEgbmV3IHRyYW5zcG9ydCBmb3IgU0lQIGJ1dCB0aGlz IHBhcnQgaXMgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQgSU1ITykuIEluIGFueSBjYXNlLCBs ZXQgbWUgdXNlIHRoaXMgb3Bwb3J0dW5pdHkgdG8gZXhwcmVzcyBteSBzdHJvbmcgaW50ZXJlc3Qg aW4gdGhpcyB3b3JrIG9uZSBtb3JlIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRv bGdhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IE9sbGUgRS4gSm9oYW5zc29uIFs8YSBocmVmPSJtYWlsdG86b2VqQGVkdmluYS5uZXQiPm1haWx0 bzpvZWpAZWR2aW5hLm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2Vt YmVyIDIyLCAyMDE2IDEyOjE3IFBNPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSI+dGFzdmVyZW5Ac29udXNuZXQu Y29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE9sbGUgRSBKb2hhbnNzb24gJmx0OzxhIGhyZWY9 Im1haWx0bzpvZWpAZWR2aW5hLm5ldCI+b2VqQGVkdmluYS5uZXQ8L2E+Jmd0OzsgQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7OyBBZGFtIFJvYWNoICZs dDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+YWRhbUBub3N0cnVtLmNvbTwvYT4m Z3Q7OyBTSVBDT1JFDQogJmx0OzxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBj b3JlQGlldGYub3JnPC9hPiZndDs7IEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJl bkBub3N0cnVtLmNvbSI+YmVuQG5vc3RydW0uY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUgd29yayBhbmQgbWls ZXN0b25lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDIyIERlYyAyMDE2LCBhdCAxODowOCwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1h aWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5pLSBJIGFncmVlIHRoYXQgY29ubmVjdGlv biByZS11c2UgbmVlZHMgdG8gYmUgYWRkcmVzc2VkIGFzIGl0IHdvdWxkIGJlIGEgbm9ybWF0aXZl IGNoYW5nZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlpLSBJcyBpdCBhIG1hbmRhdGUgdGhhdCBtdXR1 YWwgYXV0aGVudGljYXRpb24gbmVlZHMgdG8gYmUgdXNlZCBpZiB0cmFuc3BvcnQ9dGxzPyBJZiBz bywgdGhhdCB3b3VsZCByZXF1aXJlIGFub3RoZXIgbm9ybWF0aXZlIGNoYW5nZSB0byBhbGlnbiB3 aXRoIHByYWN0aWNhbCBuZWVkcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFVSSSBmb3IgdGhlIHRh cmdldCBhbmQgdGhlIGNlcnQgZm9yIHRoZSBVQSBzZXJ2ZXIgbmVlZHMgdG8gbWF0Y2guIEl04oCZ cyBub3QgbXV0dWFsIC0gdHdvIGNlcnRzIGluIHRoZSBzYW1lIFRMUyBzZXNzaW9uLCBidXQgdGhh dCB3b3VsZCBhbHNvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5iZSBvbmUgc29sdXRpb24gKHRoZXJlIGlzIGEgUkZDIGZvciB0aGF0KS4gU0lQIE91 dGJvdW5kIHBlcm1pdHMgcmV1c2Ugb2YgdGhlIGluY29taW5nIGNvbm5lY3Rpb24gYW5kIHRodXM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmF2b2lk cyB0aGlzIHBhcnRpY3VsYXIgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5paWktIEkgdGhpbmsgYm90aCBpLS9paS0gYXJlIHJlbGF0aXZlbHkgc3Ry YWlnaHRmb3J3YXJkIHRvIGFkZHJlc3MuIFRoZSBtb3JlIGludGVyZXN0aW5nL2NoYWxsZW5naW5n IGFzcGVjdCBpcyBob3cgdG8gZmFpbG92ZXIgRFRMUyBjb25uZWN0aW9ucyB3aXRob3V0IGEgbmVl ZCBmb3IgcGVyLXRyYW5zYWN0aW9uDQogc3RhdGUgc3luY2hyb25pemF0aW9uIGFuZCB3aXRoIHRo ZSBmZXdlc3Qgcm91bmQtdHJpcHMgcG9zc2libGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbm5lY3Rp b24gcmV1c2UgbmVlZHMgdG8gYmUgaGFuZGxlZCBzZXBhcmF0ZWx5IGFuZCBuZWVkcyB0byBiZSBz b21ldGhpbmcgdGhhdCBpcyB3YXkgbW9yZSBlYXN5IHRvIGltcGxlbWVudCB0aGFuIFNJUCBvdXRi b3VuZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldlIG5lZWQgc29tZXRoaW5nIHdlIGNhbiBlYXNpbHkgdGVzdCBhbmQgZ2V0IGl0IGRvbmUgc29v biwgYXMgSSB3YW50IG1vcmUgVExTIG9uIHRoZSBTSVAgbmV0d29ya3Mgb3V0IHRoZXJlIDotKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg Y3VycmVudCB3YXkgdG8gaGFuZGxlIHRoaXMgaXMgY29ubmVjdGlvbiByZXVzZSB0aGF0IGJyZWFr cyB0aGUgUkZDcywgd2UgaGF2ZSB0aGF0IGltcGxlbWVudGF0aW9uIGluIEthbWFpbGlvLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlcmUg aXMgYW4gb3BlbiBzb2NrZXQsIFRMUyBvciBUQ1AsIHdlIHByZWZlciB0byB1c2UgaXQgdG8gbWFr ZSB0aGluZ3Mgd29yay4gSSB3b3VsZCBsb3ZlIGZvciB0aGlzIHRvIGJlIFJGQyBjb21wbGlhbnQg Oi0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+L088bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9sZ2E8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T2xsZQ0KIEUuIEpvaGFuc3NvbiBbPGEg aHJlZj0ibWFpbHRvOm9lakBlZHZpbmEubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5t YWlsdG86b2VqQGVkdmluYS5uZXQ8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBEZWNlbWJlciAyMiwg MjAxNiAxMDo1NSBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+QXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0 YXN2ZXJlbkBzb251c25ldC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRhc3ZlcmVu QHNvbnVzbmV0LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+T2xsZSBFIEpvaGFuc3NvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm9lakBlZHZpbmEubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5vZWpAZWR2aW5hLm5ldDwvc3Bhbj48L2E+Jmd0OzsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+ Jmd0OzsNCiBBZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhbUBub3N0cnVtLmNvbTwvc3Bhbj48L2E+Jmd0 OzsgU0lQQ09SRSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs7IEJlbiBD YW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBub3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+YmVuQG5vc3RydW0uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJlOiBbc2lwY29yZV0gUkVTUE9OU0UgUkVRVUVTVEVEOiBTSVBDT1JFIHdvcmsgYW5kIG1pbGVz dG9uZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMiBEZWMgMjAx NiwgYXQgMTY6MzQsIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5A c29udXNuZXQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50YXN2ZXJlbkBzb251c25l dC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPk9sbGUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgbWlzc2VkIHRoZSBwb2ludCBhYm91dCB3 aHkg4oCccHJhY3RpY2FsbHkgcG9zc2libGUgZmFpbG92ZXLigJ0gbmVlZHMgdG8gYmUgc29sdmVk IGJvdGggZm9yIFRMUy9EVExTIChJIGFtIG5vdCBhcmd1aW5nIGl0IHdvdWxkIGJlIGdvb2QgdG8g aGF2ZSBhIHNvbHV0aW9uIGZvciBib3RoKSBhbmQgYWxzbyB3aGF0DQogdGhpcyBpc3N1ZSBpbiBn ZW5lcmFsIGhhcyBzb21ldGhpbmcgdG8gZG8gd2l0aCBjbGllbnQgY2VydGlmaWNhdGVzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q291bGQgeW91IHByb3ZpZGUgYSBiaXQgbW9y ZSBpbmZvcm1hdGlvbi9jbGFyaWZpY2F0aW9ucz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZeKAmXZlIGRp c2N1c3NlZCBpdCBhIG51bWJlciBvZiB0aW1lcyBib3RoIGhlcmUgYW5kIG9uIHRoZSBTSVAgRm9y dW0gdGVjaHdnIG1haWxpbmcgbGlzdC4gWW91IGNhbiBmaW5kIHN1bW1hcmllcyBoZXJlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0 L29lai9zaXAtaGFsZi1vdXRib3VuZC1yYW5kb20tbm90ZXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQvb2VqL3NpcC1oYWxmLW91dGJvdW5kLXJh bmRvbS1ub3Rlczwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LnNsaWRl c2hhcmUubmV0L29lai9zaXAtdGxzLXNlY3VyaXR5LWluLWEtcGVlci10by1wZWVyLXdvcmxkIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vd3d3LnNsaWRlc2hhcmUubmV0L29lai9z aXAtdGxzLXNlY3VyaXR5LWluLWEtcGVlci10by1wZWVyLXdvcmxkPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc2hvcnQsIHdpdGhvdXQgU0lQIE91dGJvdW5kIHRoZSBj bGllbnQgY29ubmVjdGlvbiBjYW7igJl0IGJlIHJlLXVzZWQgZm9yIG91dGJvdW5kIHJlcXVlc3Rz LiBTZWVtcyBsaWtlIHRoZXJlIGlzIGEgaHVnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVzaXN0YW5jZSB0byBpbXBs ZW1lbnQgU0lQIE91dGJvdW5kLiBXZSBuZWVkIGEgd2F5IGZvciB0aGUgY2xpZW50IHRvIGFsbG93 IHRoZSBzZXJ2ZXIgdG8gcmV1c2UgdGhlIGluYm91bmQgY29ubmVjdGlvbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9y IG91dGJvdW5kIHJlcXVlc3RzIGV2ZW4gdGhvdWdoIHRoZXJl4oCZcyBubyBUTFMgY2VydGlmaWNh dGUgbWF0Y2hpbmcgdGhlIFVSSSBvbiB0aGUgY2xpZW50IHNpZGUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldl4oCZdmUgaGFkIGEgbG90IG9mIGNsaWVudHMgcmVnaXN0ZXIgd2l0aCDigJw7 dHJhbnNwb3J0PXRsc+KAnSBhdCBTSVBpdCB3aXRob3V0IGEgY2xpZW50IGNlcnQgLSB3aGljaCBt ZWFucyB3ZSBjYW7igJl0IGNvbW11bmljYXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iYXNlZCBvbiB0aGF0IHJlZ2lz dHJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L088 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Ub2xnYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbGxlDQogRS4gSm9oYW5zc29uIFs8YSBocmVm PSJtYWlsdG86b2VqQGVkdmluYS5uZXQiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0 bzpvZWpAZWR2aW5hLm5ldDwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIERlY2VtYmVyIDIyLCAyMDE2 IDk6MDggQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPkFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50YXN2ZXJlbkBzb251 c25ldC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk9sbGUgRSBKb2hhbnNzb24gJmx0OzxhIGhy ZWY9Im1haWx0bzpvZWpAZWR2aW5hLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+b2Vq QGVkdmluYS5uZXQ8L3NwYW4+PC9hPiZndDs7IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVm PSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDs7 DQogQWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmFkYW1Abm9zdHJ1bS5jb208L3NwYW4+PC9hPiZndDs7IFNJ UENPUkUgJmx0OzxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5zaXBjb3JlQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7OyBCZW4gQ2FtcGJl bGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmJlbkBub3N0cnVtLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTog W3NpcGNvcmVdIFJFU1BPTlNFIFJFUVVFU1RFRDogU0lQQ09SRSB3b3JrIGFuZCBtaWxlc3RvbmVz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgRGVjIDIwMTYsIGF0IDE0OjUwLCBBc3Zl cmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRpbmcgdGhlIGludGVyZXN0IGluIFNJUC9VRFAvRFRM Uzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMg aXMgbWFpbmx5IGJhc2VkIG9uIHByb3NwZWN0IG9mIGxhcmdlciBzY2FsYWJpbGl0eSBvbiBzZXJ2 ZXIgc2lkZS4gVGhlcmUgbWF5L21heSBub3QgYmUgYW4gaW1tZWRpYXRlIG5lZWQgdG8gdHdlYWsv Y2hhbmdlIHRoaW5ncyB0byBtYWtlIERUTFMgcmVsYXRlZCBwcm9jZXNzaW5nIChob3BlZnVsbHkN CiBqdXN0IG9uIHRoZSBsb2NhbCBzdGFjayBsZXZlbCByYXRoZXIgdGhhbiBvbiBvbi10aGUtd2ly ZSBwcm90b2NvbC0gd2l0aCBzb21lIHN1cHBvcnRpbmcgU0lQIGVuaGFuY2VtZW50cykgbW9yZSDi gJxmYWlsb3ZlciBmcmllbmRseeKAnS4gVGhpcyBpc3N1ZSByZXF1aXJlcyBtb3JlIGFuYWx5c2lz L2Rpc2N1c3Npb24gYnV0IGRvZXMgbm90IHNvdW5kIHVuc29sdmFibGUgSU1ITy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2lsbCBoYXZlIHRvIHNv bHZlIGNsaWVudCBjb25uZWN0aW9uIHJldXNlIGZvciBib3RoIFRMUyBhbmQgRFRMUyBzZXNzaW9u cyB0aG91Z2guIFVubGVzcyB5b3Ugd2FudCB0byBoYXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5jbGllbnQgY2VydGlmaWNhdGVzIG9uIGFsbCBkZXZpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGFtIGFzIGNoYWlyOiBTSVAg Q2xpZW50IENvbm5lY3Rpb24gUmV1c2UgaXMgc29tZXRoaW5nIHdl4oCZdmUgZGlzdXNzZWQgdW5k ZXIgbXVsdGlwbGUgbmFtZXMgLSDigJxoYWxmIG91dGJvdW5k4oCdIG9yIOKAnHdoeSBpcyA7dHJh bnNwb3J0PXRsc+KAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVwcmVjYXRlZOKAnSBvciDi gJxXaHkgZG9lc27igJl0IFNJUCBPdXRib3VuZCBoYXBwZW4/4oCdLiBNYXliZSB0aGF0IGRlc2Vy dmVzIGEgbWlsZXN0b25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPi9PPGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5r cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdh PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnNpcGNvcmUNCiBb PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhh bGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9i PkNocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBEZWNlbWJlciAyMiwgMjAxNiA3 OjM5IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5BZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVt LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhbUBub3N0cnVtLmNvbTwvc3Bhbj48 L2E+Jmd0OzsgJ1NJUENPUkUnICZsdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2lwY29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+QmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29t Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5iZW5Abm9zdHJ1bS5jb208L3NwYW4+PC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UmU6IFtzaXBjb3JlXSBSRVNQT05TRSBSRVFVRVNURUQ6IFNJUENPUkUg d29yayBhbmQgbWlsZXN0b25lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHdpbGwgb2J2aW91c2x5IGJlIGFj dGl2ZWx5IGludm9sdmVkIGluIDQpLCBhbmQgSSBhbHNvIGFncmVlIHRoYXQgNSkgc2hvdWxkIGJl IGRvbmUgYXMgaXQgaXMgYSBjb3JyZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BcyBmYXIg YXMgdGhlIG90aGVyIHBvdGVudGlhbCB3b3JrIGlzIGNvbmNlcm5lZCwgMykgaGFzIHRoZSBoaWdo ZXN0IHByaW9yaXR5IGZvciBtZSwgYW5kIEkgd291bGQgYWN0aXZlbHkgcGFydGljaXBhdGUgaW4g dGhhdCB3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHdvdWxkIHJldmlldyAxKSBhbmQgMiks IGJ1dCBJIHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IG9uIDIp IGJlZm9yZSB3ZSBhZ3JlZSB3aGV0aGVyIHRvIGNyZWF0ZSBhIG1pbGVzdG9uZSBmb3IgaXQuIEZv ciBleGFtcGxlLCBJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUNCiBpbnB1dCBvbiBXSFkgdG8gZG8g aXQsIGFuZCBIT1cgaXQgaXMgaW50ZW5kZWQgdG8gYmUgZGVwbG95ZWQgZXRjLiBIb3cgZG9lcyBE VExTIGZpdCBTSVA/IFdoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzPyBPUiwgZG8gd2Ugd2FudCB0byBz cGVjaWZ5IERUTFMtZm9yLVNJUCBzaW1wbHkgYmVjYXVzZSBEVExTIGlzIOKAnGhvdOKAnT88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+c2lwY29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2lwY29yZS1ib3VuY2VzQGlldGYu b3JnPC9zcGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mICZxdW90OzxhIGhyZWY9Im1haWx0bzph ZGFtQG5vc3RydW0uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGFtQG5vc3RydW0u Y29tPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29t Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGFtQG5vc3RydW0uY29tPC9zcGFuPjwvYT4m Z3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPlR1ZXNkYXkgMjAgRGVjZW1iZXIgMjAxNiBhdCAyMjoyNzxicj4NCjxiPlRv OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNpcGNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNpcGNvcmVA aWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJlbkBub3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVuQG5v c3RydW0uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPltzaXBjb3JlXSBSRVNQT05TRSBS RVFVRVNURUQ6IFNJUENPUkUgd29yayBhbmQgbWlsZXN0b25lczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5bYXMgY2hhaXJdPGJyPg0KPGJyPg0KTm93IHRoYXQgd2UgaGF2ZSBv dXIgbmV3IGNoYXJ0ZXIgYXBwcm92ZWQsIEknZCBsaWtlIHRoZSB3b3JraW5nIGdyb3VwIHRvIGhh dmUgYSBkaXNjdXNzaW9uIGFib3V0IHRoZSBzcGVjaWZpYyB3b3JrIGl0ZW1zIHRoYXQgd2Ugc2hv dWxkIHRha2Ugb24gaW4gdGhlIHNob3J0LSB0byBtZWRpdW0tdGVybSBzbyB0aGF0IHdlIGNhbiBy ZXZpc2Ugb3VyIG1pbGVzdG9uZXMgYXBwcm9wcmlhdGVseS4gQmFzZWQgb24gcmVjZW50IGRpc2N1 c3Npb25zIG9uIHRoZQ0KIG1haWxpbmcgbGlzdCwgdGhlIGZvbGxvd2luZyB0b3BpY3MgaGF2ZSBz b21lIG1pbmQtc2hhcmUgYmVoaW5kIHRoZW0uIFdoYXQgSSdkIGxpa2UgZnJvbSBldmVyeW9uZSB3 aXRoIGFuIGludGVyZXN0IGluIGFueSBvZiB0aGVzZSB0b3BpY3MgaXMgdG8gaW5kaWNhdGUgKGEp IHdoZXRoZXIgeW91IGFyZSB3aWxsaW5nIHRvIGFjdGl2ZWx5IHJldmlldyBhbmQgY29tbWVudCBv biBkb2N1bWVudHMgb24gdGhlIHRvcGljOyBhbmQgKGIpIHdoYXQgcHJpb3JpdHkNCiBlYWNoIHRh c2sgaGFzIHJlbGF0aXZlIHRvIGVhY2ggb3RoZXI6IHRoZXJlIGFyZSBmaXZlIHRvcGljczsgcGxl YXNlIGluZGljYXRlIGEgdW5pcXVlIHByaW9yaXR5IGZyb20gb25lIChtb3N0IGltcG9ydGFudCkg dG8gZml2ZSAobGVhc3QgaW1wb3J0YW50KSBmb3IgZWFjaCB0b3BpYy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZxdW90O0hhcHB5IEV5ZWJhbGxzIGZvciBTSVAmcXVvdDsgKGFrYSBIYXBw eSBFYXJiYWxscyksIGN1cnJlbnRseSB1bmRlciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Ljwvc3Bh bj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtEVExTIFRyYW5zcG9ydCBmb3Ig U0lQJnF1b3Q7LCBhcyBwcm9wb3NlZCBieSBUb2xnYSBBc3ZlcmVuJ3MgcmVjZW50IG1lc3NhZ2Vz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BIG1lY2hhbmlzbSBmb3IgbGFi ZWxpbmcgdGhlIG5hdHVyZSBvZiBTSVAgY2FsbHMsIHdpdGggJmx0O2RyYWZ0LXNjaHVsenJpbm5l LXNpcGNvcmUtY2FsbGluZm8tc3BhbSZndDsgYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0Ljwv c3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GaXhpbmcgQ29udGVudC1JRCBpbiBT SVAsIGFzIGRpc2N1c3NlZCBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3NpcGNvcmUvY3VycmVudC9tc2cwNzI0NS5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij4mbHQ7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJl bnQvbXNnMDcyNDUuaHRtbCZndDs8L3NwYW4+PC9hPiwNCiB3aXRoICZsdDtkcmFmdC1ob2xtYmVy Zy1zaXBjb3JlLWNvbnRlbnQtaWQmZ3Q7IGFzIGEgbGlrZWx5IGNhbmRpZGF0ZSBkcmFmdC48L3Nw YW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2xhcmlmaWNhdGlvbnMgYXJvdW5kIFNJ UCBuYW1lLWFkZHIsIHdpdGggJmx0O2RyYWZ0LXNwYXJrcy1zaXBjb3JlLW5hbWUtYWRkci1ndWlk YW5jZSZndDsgYXMgYSBsaWtlbHkgY2FuZGlkYXRlIGRyYWZ0PC9zcGFuPjxvOnA+PC9vOnA+PC9s aT48L29sPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48YnI+DQpJIHdpbGwgYWxzbyBub3RlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGRl Y2xhcmVkIGNvbnNlbnN1cyBvbiBhZG9wdGluZyAmbHQ7ZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1 cy11bndhbnRlZCZndDsgYXMgYSBXRyBkb2N1bWVudCwgYW5kIHdpbGwgYmUgYWRkaW5nIGFuIGFz c29jaWF0ZWQgbWlsZXN0b25lLiBJIHdhbnQgdG8gdGFrZSB0aGlzIG9wcG9ydHVuaXR5IHRvIHJl bWluZCBwZW9wbGUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgaW4gV0dMQywgYW5kIHlvdXIgY29tbWVu dHMNCiBhcmUgc3Ryb25nbHkgZW5jb3VyYWdlZCwgdGhlIGVhcmxpZXIgdGhlIGJldHRlci48YnI+ DQo8YnI+DQpQbGVhc2UgcmVzcG9uZCBiZWZvcmUgdGhlIGVuZCBvZiAyMDE2LiBUaGFua3MhPGJy Pg0KPGJyPg0KVGhhbmtzITxicj4NCjxicj4NCi9hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlz dDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6cHVycGxlIj5zaXBjb3JlQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN2PR03MB235040DBC76ABA8BC4EED379B2950SN2PR03MB2350namp_-- From nobody Fri Dec 23 14:11:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E65129485 for ; Fri, 23 Dec 2016 14:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 20Dh6dQZap8b for ; Fri, 23 Dec 2016 14:11:31 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5BB129439 for ; Fri, 23 Dec 2016 14:11:31 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-09v.sys.comcast.net with SMTP id KY3UcbEGiuazMKY3mcK94P; Fri, 23 Dec 2016 22:11:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1482531090; bh=ocmYhRsptES4gMHAq1SmUUpabCINZ7f3BsMpEzcR5SI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WAeh8bB1A6ifomz5YrncmymqZjav0l15Xp9IyPUioKk2LmRPfBeUwha/nTKe5eYln Yd0Nwbmo1CYeY8acOrXxvqFlYdqdlnCheeV0J1Juf4MHKkDlsem3XFoi65RMG3jpuw qHwuZSaXYthGxJIjF/vw5A+TeTpj9W0Caei67ia6db4gJFZr41y7jeQQqHgQoNV2Wk aLoS7z9fTvuGibR4EI+yIPoKqh8Pm5VTFCyHCyfnEofoHM7zKkEGRJHHFm8G49DaJ+ wLo4FZSof/JwmbVX4Jr7H7gd3RYDBlIlxi4SOUeKVI45XiIOxxSSxoQJU/jxZzdty4 MuhAtvBMxjL9Q== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-14v.sys.comcast.net with SMTP id KY3lcVhPv2qkOKY3mcMw6i; Fri, 23 Dec 2016 22:11:30 +0000 To: sipcore@ietf.org References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> From: Paul Kyzivat Message-ID: <955f2fa5-887a-fb54-d694-134e4cdab5f6@comcast.net> Date: Fri, 23 Dec 2016 17:11:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfIK/VWzE3mJ9vtuU7eNJza1SfsOSTln46OTI4E2Biv6OMmhRqxR/XgeO61epgFNafL/8VbtTXCUV+utDWdVZTwTrF8UsIFcALX/+wkgCsOXh/UC5m0ey yA4ngdGJLznjdrttfRcqFpUljGVt2dyfmGANILv5UmW86JOuLLFrndDEdla6P+R79yjDGdlMgXviGw== Archived-At: Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 22:11:33 -0000 On 12/23/16 3:30 AM, Asveren, Tolga wrote: > i- I agree with the need to “standardize” the “connection reuse per > existing deployment semantics”. I think what we are looking for is: > > - Bidirectional connection reuse with TLS/server-side only > certificate/UE authentication per SIP registration without RFC5626 > > - Bidirectional connection reuse with TCP over VPN, e.g. IPSec > > - Bidirectional connection reuse with TCP when > authentication/security is provided by L2 The problem in all of these cases is for the entity sending a request to be able to ascertain that the connection terminates on a device known to correspond to the URI used to address it. Outbound was created to solve that problem. I have yet to see another "simpler" solution that provides that assurance. As currently defined outbound can be used without redundancy if that is what you want to do. There is a requirement for the software to *support* use of redundancy, but deployments are free to configure without it. So I see no compelling reason to revise outbound for this purpose. Maybe there is something simpler than outbound that will work. But it remains to be proposed. Thanks, Paul > I am not sure what would be the best place to address these. It could be > either happy-earballs or a new document. I would prefer the former and > can provide text in either case. > > > > ii- The issue with SIP/UDP/DTLS is something quite different. It really > is more about providing fast/practically feasible failover for DTLS > connections (in addition to defining use of UDP/DTLS as a new transport > for SIP but this part is relatively straightforward IMHO). In any case, > let me use this opportunity to express my strong interest in this work > one more time. > > > > Thanks, > > Tolga > > > > *From:*Olle E. Johansson [mailto:oej@edvina.net] > *Sent:* Thursday, December 22, 2016 12:17 PM > *To:* Asveren, Tolga > *Cc:* Olle E Johansson ; Christer Holmberg > ; Adam Roach ; SIPCORE > ; Ben Campbell > *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > > > > > > On 22 Dec 2016, at 18:08, Asveren, Tolga > wrote: > > > > Thanks for the clarification. > > > > i- I agree that connection re-use needs to be addressed as it would > be a normative change. > > ii- Is it a mandate that mutual authentication needs to be used if > transport=tls? If so, that would require another normative change to > align with practical needs. > > The URI for the target and the cert for the UA server needs to match. > It’s not mutual - two certs in the same TLS session, but that would also > > be one solution (there is a RFC for that). SIP Outbound permits reuse of > the incoming connection and thus > > avoids this particular problem. > > > > iii- I think both i-/ii- are relatively straightforward to address. > The more interesting/challenging aspect is how to failover DTLS > connections without a need for per-transaction state synchronization > and with the fewest round-trips possible. > > Connection reuse needs to be handled separately and needs to be > something that is way more easy to implement than SIP outbound. > > We need something we can easily test and get it done soon, as I want > more TLS on the SIP networks out there :-) > > > > The current way to handle this is connection reuse that breaks the RFCs, > we have that implementation in Kamailio. > > If there is an open socket, TLS or TCP, we prefer to use it to make > things work. I would love for this to be RFC compliant :-) > > > > /O > > > > Thanks, > > Tolga > > > > *From:* Olle E. Johansson [mailto:oej@edvina.net] > *Sent:* Thursday, December 22, 2016 10:55 AM > *To:* Asveren, Tolga > > *Cc:* Olle E Johansson >; > Christer Holmberg >; Adam Roach > >; SIPCORE > >; Ben Campbell > > > *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones > > > > > > On 22 Dec 2016, at 16:34, Asveren, Tolga > wrote: > > > > Olle, > > > > I missed the point about why “practically possible failover” > needs to be solved both for TLS/DTLS (I am not arguing it would > be good to have a solution for both) and also what this issue in > general has something to do with client certificates. > > Could you provide a bit more information/clarifications? > > > > We’ve discussed it a number of times both here and on the SIP Forum > techwg mailing list. You can find summaries here: > > > > http://www.slideshare.net/oej/sip-half-outbound-random-notes > > http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world > > > > In short, without SIP Outbound the client connection can’t be > re-used for outbound requests. Seems like there is a huge > > resistance to implement SIP Outbound. We need a way for the client > to allow the server to reuse the inbound connection > > for outbound requests even though there’s no TLS certificate > matching the URI on the client side. > > > > We’ve had a lot of clients register with “;transport=tls” at SIPit > without a client cert - which means we can’t communicate > > based on that registration. > > > > Cheers, > > /O > > > > > Thanks, > > Tolga > > > > *From:* Olle E. Johansson [mailto:oej@edvina.net] > *Sent:* Thursday, December 22, 2016 9:08 AM > *To:* Asveren, Tolga > > *Cc:* Olle E Johansson >; > Christer Holmberg >; Adam Roach > >; SIPCORE > >; Ben Campbell > > > *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and > milestones > > > > > > On 22 Dec 2016, at 14:50, Asveren, Tolga > > wrote: > > > > Regarding the interest in SIP/UDP/DTLS: > > This is mainly based on prospect of larger scalability on > server side. There may/may not be an immediate need to > tweak/change things to make DTLS related processing > (hopefully just on the local stack level rather than on > on-the-wire protocol- with some supporting SIP enhancements) > more “failover friendly”. This issue requires more > analysis/discussion but does not sound unsolvable IMHO. > > We will have to solve client connection reuse for both TLS and > DTLS sessions though. Unless you want to have > > client certificates on all devices. > > > > Adam as chair: SIP Client Connection Reuse is something we’ve > disussed under multiple names - “half outbound” or “why is > ;transport=tls” > > deprecated” or “Why doesn’t SIP Outbound happen?”. Maybe that > deserves a milestone. > > > > /O > > > > > > Thanks, > > Tolga > > > > *From:* sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Thursday, December 22, 2016 7:39 AM > *To:* Adam Roach >; 'SIPCORE' > > *Cc:* Ben Campbell > > *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work > and milestones > > > > Hi, > > > > I will obviously be actively involved in 4), and I also > agree that 5) should be done as it is a correction. > > > > As far as the other potential work is concerned, 3) has the > highest priority for me, and I would actively participate in > that work. > > > > I would review 1) and 2), but I would really like to see an > individual draft on 2) before we agree whether to create a > milestone for it. For example, I would like to see some > input on WHY to do it, and HOW it is intended to be deployed > etc. How does DTLS fit SIP? What are the advantages? OR, do > we want to specify DTLS-for-SIP simply because DTLS is “hot”? > > > > Regards, > > > > Christer > > > > *From: *sipcore > on behalf of > "adam@nostrum.com " > > > *Date: *Tuesday 20 December 2016 at 22:27 > *To: *"sipcore@ietf.org " > > > *Cc: *Ben Campbell > > *Subject: *[sipcore] RESPONSE REQUESTED: SIPCORE work and > milestones > > > > [as chair] > > Now that we have our new charter approved, I'd like the > working group to have a discussion about the specific work > items that we should take on in the short- to medium-term so > that we can revise our milestones appropriately. Based on > recent discussions on the mailing list, the following topics > have some mind-share behind them. What I'd like from > everyone with an interest in any of these topics is to > indicate (a) whether you are willing to actively review and > comment on documents on the topic; and (b) what priority > each task has relative to each other: there are five topics; > please indicate a unique priority from one (most important) > to five (least important) for each topic. > > 1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently > under discussion on the list. > 2. "DTLS Transport for SIP", as proposed by Tolga Asveren's > recent messages. > 3. A mechanism for labeling the nature of SIP calls, with > as a likely > candidate draft. > 4. Fixing Content-ID in SIP, as discussed > in > , > with as a likely > candidate draft. > 5. Clarifications around SIP name-addr, with > as a likely > candidate draft > > > I will also note that we have already declared consensus on > adopting as a WG > document, and will be adding an associated milestone. I want > to take this opportunity to remind people that the document > is in WGLC, and your comments are strongly encouraged, the > earlier the better. > > Please respond before the end of 2016. Thanks! > > Thanks! > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat Dec 24 04:08:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30A512963E for ; Sat, 24 Dec 2016 04:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 Z9qu8BntR9UW for ; Sat, 24 Dec 2016 04:08:19 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0086.outbound.protection.outlook.com [104.47.36.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DE51293E3 for ; Sat, 24 Dec 2016 04:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HvlY9geOuFQtlauMF2JRhdFtkaUX+So/azVvUNtQCMY=; b=lHnZtVP/0yMV5Txiwb4hOpXOan13W/JPmoSYLuwuKLkE3LnoMOpQ5QI5VLM7zY6dM1UiJ6HuujclmcxyprZTd5V79az3qkV2H33AQjHHx8ca6x7+F4VjlbGAIheg28X9CKdofDMYVomcECFkgOBQ1XlB9swm8iwiuzu2i9JKDLM= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Sat, 24 Dec 2016 12:08:16 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.015; Sat, 24 Dec 2016 12:08:16 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv96++N6DRIq/E2cKGNWf6YDKaET6r4AgAAS3iCAAAYCAIAAF0yAgAAGmwCAABLYMIAAA+sAgADDHnCAASGggIAA44Ig Date: Sat, 24 Dec 2016 12:08:16 +0000 Message-ID: References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> <955f2fa5-887a-fb54-d694-134e4cdab5f6@comcast.net> In-Reply-To: <955f2fa5-887a-fb54-d694-134e4cdab5f6@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: ed0b6cfd-2f64-4476-fe35-08d42bf58b1c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:vw6i9+YeRPR8yYC+dgKuOcGGB/3j12i7lFmEFSzZgZfVETdACaNaaHCpfCZd02U2Bv1b9hRQpgGRJ8tVX7fLyUiiI9C5btAY9kHCC4WamrKPfbNTA/Pi/ADaRuGpP20+lIO+nXFmsYRcS7/FcMFEDDaDrRpmzImbbQgiSe/x5tGe7hapzo1jQQUGbIIUaCTpK3Huk7mbc+Gec/zZSBfb9znZzTx1rmvtatdeNjjQQfb53dVln2/MqnmrzC74HlvuVBGkYpEK+nrXGrUsLl4uJQzbPavIvc1LvOedyuLg5WlZ64RVAgTE0JTrVwSSgkUpg6EoLwTGhCKsqvPMQJjZxvJO6k2EJonZun+8TESROvVAcULCMJYxxI4K4R7YpluxZN1hPLzDYLkWpveX5qumLoqSeXAm4zL7tw3mUXuE8kKGrrMZLjN2aq7I/LWdRBQXtpOgrpYGvVQoqiTRRTt+hQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(192374486261705)(100405760836317)(178636050973902)(132712982866762); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 0166B75B74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(13464003)(51914003)(55885003)(24454002)(377454003)(189002)(199003)(105586002)(8666007)(189998001)(81166006)(81156014)(106356001)(93886004)(106116001)(551934003)(99286002)(54356999)(50986999)(3660700001)(66066001)(305945005)(74316002)(76176999)(3280700002)(8936002)(33656002)(107886002)(101416001)(2501003)(2950100002)(6506006)(2900100001)(6436002)(86362001)(92566002)(6116002)(122556002)(3846002)(102836003)(38730400001)(229853002)(68736007)(7736002)(76576001)(25786008)(1720100001)(77096006)(5001770100001)(8676002)(9686002)(2906002)(97736004)(5660300001)(7696004)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2016 12:08:16.5786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 Archived-At: Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 12:08:23 -0000 RFC5626 seems to be leaving some room to use a single registration: "For each outbound proxy URI in the set, the User Agent Client (UAC) SHOULD send a REGISTER request using this URI as the default outbound proxy. (Alternatively, the UA could limit the number of flows formed to conserve battery power, for example). If the set has more than one URI, the UAC MUST send a REGISTER request to at least two of the default outbound proxies from the set. " OTOH it mandates use of reg-id/+sip.instance parameters: "A UAC conforming to this specification MUST include in the Contact header field, a "reg-id" parameter that is distinct from other "reg-id" parameters used in other registrations that use the same "+sip.instance" Contact header field parameter and AOR." I am not arguing that these parameters are not adding value/addressing cert= ain requirements. I just think that not everything they are helping with is= absolutely needed by many existing deployments. IMHO the main requirement for "simple outbound" is: (Re)use a single TCP co= nnection between UA/Edge Proxy. This is anyhow how many deployments out in = the wild operate. It would be great if that could be allowed (maybe with a = SHOULD in happy-earballs). Iy may be even possible to define semantics with= out use of an option-tag - I am not sure though whether we can end up with= something kosher from IETF perspective-. As far as authentication is concerned: i- For TLS(only server certificate) Server authenticated based on X.509 certificate=20 UE authenticated during registration (digest) ii- For TLS(certificate for both ends) Already covered by RFC5923 iii- For VPN Both ends are authenticated during VPN setup, e.g. IMS AKA.=20 Overall, I don't see any problem with your "knowing who is on the other end= " question. Maybe I am missing your point(?) Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, December 23, 2016 5:11 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones >=20 > On 12/23/16 3:30 AM, Asveren, Tolga wrote: > > i- I agree with the need to "standardize" the "connection reuse per > > existing deployment semantics". I think what we are looking for is: > > > > - Bidirectional connection reuse with TLS/server-side only > > certificate/UE authentication per SIP registration without RFC5626 > > > > - Bidirectional connection reuse with TCP over VPN, e.g. IPSec > > > > - Bidirectional connection reuse with TCP when > > authentication/security is provided by L2 >=20 > The problem in all of these cases is for the entity sending a request to = be able > to ascertain that the connection terminates on a device known to correspo= nd > to the URI used to address it. >=20 > Outbound was created to solve that problem. I have yet to see another > "simpler" solution that provides that assurance. >=20 > As currently defined outbound can be used without redundancy if that is > what you want to do. There is a requirement for the software to > *support* use of redundancy, but deployments are free to configure > without it. So I see no compelling reason to revise outbound for this pur= pose. >=20 > Maybe there is something simpler than outbound that will work. But it > remains to be proposed. >=20 > Thanks, > Paul >=20 > > I am not sure what would be the best place to address these. It could > > be either happy-earballs or a new document. I would prefer the former > > and can provide text in either case. > > > > > > > > ii- The issue with SIP/UDP/DTLS is something quite different. It > > really is more about providing fast/practically feasible failover for > > DTLS connections (in addition to defining use of UDP/DTLS as a new > > transport for SIP but this part is relatively straightforward IMHO). > > In any case, let me use this opportunity to express my strong interest > > in this work one more time. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > *From:*Olle E. Johansson [mailto:oej@edvina.net] > > *Sent:* Thursday, December 22, 2016 12:17 PM > > *To:* Asveren, Tolga > > *Cc:* Olle E Johansson ; Christer Holmberg > > ; Adam Roach ; > > SIPCORE ; Ben Campbell > > *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and > > milestones > > > > > > > > > > > > On 22 Dec 2016, at 18:08, Asveren, Tolga > > wrote: > > > > > > > > Thanks for the clarification. > > > > > > > > i- I agree that connection re-use needs to be addressed as it would > > be a normative change. > > > > ii- Is it a mandate that mutual authentication needs to be used if > > transport=3Dtls? If so, that would require another normative change= to > > align with practical needs. > > > > The URI for the target and the cert for the UA server needs to match. > > It's not mutual - two certs in the same TLS session, but that would > > also > > > > be one solution (there is a RFC for that). SIP Outbound permits reuse > > of the incoming connection and thus > > > > avoids this particular problem. > > > > > > > > iii- I think both i-/ii- are relatively straightforward to address. > > The more interesting/challenging aspect is how to failover DTLS > > connections without a need for per-transaction state synchronizatio= n > > and with the fewest round-trips possible. > > > > Connection reuse needs to be handled separately and needs to be > > something that is way more easy to implement than SIP outbound. > > > > We need something we can easily test and get it done soon, as I want > > more TLS on the SIP networks out there :-) > > > > > > > > The current way to handle this is connection reuse that breaks the > > RFCs, we have that implementation in Kamailio. > > > > If there is an open socket, TLS or TCP, we prefer to use it to make > > things work. I would love for this to be RFC compliant :-) > > > > > > > > /O > > > > > > > > Thanks, > > > > Tolga > > > > > > > > *From:* Olle E. Johansson [mailto:oej@edvina.net] > > *Sent:* Thursday, December 22, 2016 10:55 AM > > *To:* Asveren, Tolga > > > > *Cc:* Olle E Johansson >; > > Christer Holmberg > >; Adam Roach > > >; SIPCORE > > >; Ben Campbell > > > > > *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and > > milestones > > > > > > > > > > > > On 22 Dec 2016, at 16:34, Asveren, Tolga > > wrote: > > > > > > > > Olle, > > > > > > > > I missed the point about why "practically possible failover" > > needs to be solved both for TLS/DTLS (I am not arguing it would > > be good to have a solution for both) and also what this issue i= n > > general has something to do with client certificates. > > > > Could you provide a bit more information/clarifications? > > > > > > > > We've discussed it a number of times both here and on the SIP Forum > > techwg mailing list. You can find summaries here: > > > > > > > > http://www.slideshare.net/oej/sip-half-outbound-random-notes > > > > > > http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world > > > > > > > > In short, without SIP Outbound the client connection can't be > > re-used for outbound requests. Seems like there is a huge > > > > resistance to implement SIP Outbound. We need a way for the client > > to allow the server to reuse the inbound connection > > > > for outbound requests even though there's no TLS certificate > > matching the URI on the client side. > > > > > > > > We've had a lot of clients register with ";transport=3Dtls" at SIPi= t > > without a client cert - which means we can't communicate > > > > based on that registration. > > > > > > > > Cheers, > > > > /O > > > > > > > > > > Thanks, > > > > Tolga > > > > > > > > *From:* Olle E. Johansson [mailto:oej@edvina.net] > > *Sent:* Thursday, December 22, 2016 9:08 AM > > *To:* Asveren, Tolga > > > > *Cc:* Olle E Johansson >= ; > > Christer Holmberg > >; Adam Roach > > >; SIPCORE > > >; Ben Campbell > > > > > *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and > > milestones > > > > > > > > > > > > On 22 Dec 2016, at 14:50, Asveren, Tolga > > > > wrote: > > > > > > > > Regarding the interest in SIP/UDP/DTLS: > > > > This is mainly based on prospect of larger scalability on > > server side. There may/may not be an immediate need to > > tweak/change things to make DTLS related processing > > (hopefully just on the local stack level rather than on > > on-the-wire protocol- with some supporting SIP enhancements= ) > > more "failover friendly". This issue requires more > > analysis/discussion but does not sound unsolvable IMHO. > > > > We will have to solve client connection reuse for both TLS and > > DTLS sessions though. Unless you want to have > > > > client certificates on all devices. > > > > > > > > Adam as chair: SIP Client Connection Reuse is something we've > > disussed under multiple names - "half outbound" or "why is > > ;transport=3Dtls" > > > > deprecated" or "Why doesn't SIP Outbound happen?". Maybe that > > deserves a milestone. > > > > > > > > /O > > > > > > > > > > > > Thanks, > > > > Tolga > > > > > > > > *From:* sipcore [mailto:sipcore-bounces@ietf.org] *On Behal= f > > Of *Christer Holmberg > > *Sent:* Thursday, December 22, 2016 7:39 AM > > *To:* Adam Roach > >; 'SIPCORE' > > > > *Cc:* Ben Campbell > > > *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work > > and milestones > > > > > > > > Hi, > > > > > > > > I will obviously be actively involved in 4), and I also > > agree that 5) should be done as it is a correction. > > > > > > > > As far as the other potential work is concerned, 3) has the > > highest priority for me, and I would actively participate i= n > > that work. > > > > > > > > I would review 1) and 2), but I would really like to see an > > individual draft on 2) before we agree whether to create a > > milestone for it. For example, I would like to see some > > input on WHY to do it, and HOW it is intended to be deploye= d > > etc. How does DTLS fit SIP? What are the advantages? OR, do > > we want to specify DTLS-for-SIP simply because DTLS is "hot= "? > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > *From: *sipcore > > on behalf of > > "adam@nostrum.com " > > > > > *Date: *Tuesday 20 December 2016 at 22:27 > > *To: *"sipcore@ietf.org " > > > > > *Cc: *Ben Campbell > > > *Subject: *[sipcore] RESPONSE REQUESTED: SIPCORE work and > > milestones > > > > > > > > [as chair] > > > > Now that we have our new charter approved, I'd like the > > working group to have a discussion about the specific work > > items that we should take on in the short- to medium-term s= o > > that we can revise our milestones appropriately. Based on > > recent discussions on the mailing list, the following topic= s > > have some mind-share behind them. What I'd like from > > everyone with an interest in any of these topics is to > > indicate (a) whether you are willing to actively review and > > comment on documents on the topic; and (b) what priority > > each task has relative to each other: there are five topics= ; > > please indicate a unique priority from one (most important) > > to five (least important) for each topic. > > > > 1. "Happy Eyeballs for SIP" (aka Happy Earballs), currentl= y > > under discussion on the list. > > 2. "DTLS Transport for SIP", as proposed by Tolga Asveren'= s > > recent messages. > > 3. A mechanism for labeling the nature of SIP calls, with > > as a likely > > candidate draft. > > 4. Fixing Content-ID in SIP, as discussed > > in archive/web/sipcore/current/msg07245.html> > > archive/web/sipcore/current/msg07245.html>, > > with as a likely > > candidate draft. > > 5. Clarifications around SIP name-addr, with > > as a likely > > candidate draft > > > > > > I will also note that we have already declared consensus on > > adopting as a WG > > document, and will be adding an associated milestone. I wan= t > > to take this opportunity to remind people that the document > > is in WGLC, and your comments are strongly encouraged, the > > earlier the better. > > > > Please respond before the end of 2016. Thanks! > > > > Thanks! > > > > /a > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Dec 24 07:15:35 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C6E12940B for ; Sat, 24 Dec 2016 07:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 q69xAArD1wg8 for ; Sat, 24 Dec 2016 07:15:30 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52451293E1 for ; Sat, 24 Dec 2016 07:15:30 -0800 (PST) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-10v.sys.comcast.net with SMTP id Ko2acmW4HkJTyKo2jcuKSB; Sat, 24 Dec 2016 15:15:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1482592529; bh=DgzaqHvAL6yzRZinDfu3JxjG/CGGLQZ/RKSxSdEtHUk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hZNTFeePJ72mk7O39qFII1q+OEdMtDI7Pf+nyBMlKC+lOpdlG0rIDVeH2Ki2d0YCX Lqxx/U0miuUeX9t4ZLqhtf3eAspEh5grb+8fDvJClPPgXXbHtKq1/mYDrvxKh2wjMb +XxvqHw9yQScwA0jV4j8KGsE74Sbt4pcoDPvApJJmdJzvF25M+z3VHk7tXFMquGjwf sTtzdkARNqpuLhkckjuw3adbuhVGtsBO6lcnYsGQJlfFtp16Ve7KqQwGneH7ZI6pYe ywh4CSyYnN6rgGLG4pTbT+1Kzkdta3o49ChdXwG5HTK8XeIaMpjNvWxTwA+zDel5U9 B0dSSPhkpuXLg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-07v.sys.comcast.net with SMTP id Ko2icLsawB2QXKo2icIUuq; Sat, 24 Dec 2016 15:15:29 +0000 To: "Asveren, Tolga" , "sipcore@ietf.org" References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> <955f2fa5-887a-fb54-d694-134e4cdab5f6@comcast.net> From: Paul Kyzivat Message-ID: Date: Sat, 24 Dec 2016 10:15:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMHC4Yyx0PjbNipisYSJd661JXdURkkve7pGiGHoXMF+zGrBzD6jZ/Ke5Z8xGdvxp3ZyCBl9OKKPXKW4Ih/xlQZ7jzxczSbd7e/pTUqHN99FiMgKgsbA 6xmyy2NW+o2OsFeckRrS6cl668CBJVazwhX7lRi0NtS5iH6nZh8v2eNBneqqj90NyYNQUBYDcy3CWHh+UiDT0UhpXzapdx1Bquo= Archived-At: Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 15:15:33 -0000 On 12/24/16 7:08 AM, Asveren, Tolga wrote: > RFC5626 seems to be leaving some room to use a single registration: > "For each outbound proxy URI in the set, the User Agent Client (UAC) > SHOULD send a REGISTER request using this URI as the default outbound > proxy. (Alternatively, the UA could limit the number of flows formed > to conserve battery power, for example). If the set has more than > one URI, the UAC MUST send a REGISTER request to at least two of the > default outbound proxies from the set. " > > OTOH it mandates use of reg-id/+sip.instance parameters: > "A UAC conforming to this specification MUST include in the Contact > header field, a "reg-id" parameter that is distinct from other > "reg-id" parameters used in other registrations that use the same > "+sip.instance" Contact header field parameter and AOR." > > I am not arguing that these parameters are not adding value/addressing certain requirements. > I just think that not everything they are helping with is absolutely needed by many existing deployments. Maybe not. But it is what we have. Is it such a burden that we need to define something else? > IMHO the main requirement for "simple outbound" is: > (Re)use a single TCP connection between UA/Edge Proxy. Do you really mean TCP? Or do you really mean TLS? > This is anyhow how many deployments out in the wild operate. Yes, but this has not been vetted for security. > It would be great if that could be allowed (maybe with a SHOULD in happy-earballs). > Iy may be even possible to define semantics without use of an option-tag - > I am not sure though whether we can end up with something kosher from IETF perspective-. > > As far as authentication is concerned: > i- For TLS(only server certificate) > Server authenticated based on X.509 certificate > UE authenticated during registration (digest) This only works in the case that the registrar is the first hop from the UA, and is also the home proxy for all subsequent sip messaging. Is that a workable limitation? > ii- For TLS(certificate for both ends) > Already covered by RFC5923 > > iii- For VPN > Both ends are authenticated during VPN setup, e.g. IMS AKA. ISTM the problem in this case is tying the endpoints and credentials used for VPN setup with the URL used to identify the two endpoints for sip messaging. > Overall, I don't see any problem with your "knowing who is on the other end" question. Maybe I am missing your point(?) See above. Note, I don't claim to be a security expert. We really need some in this discussion. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, December 23, 2016 5:11 PM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones >> >> On 12/23/16 3:30 AM, Asveren, Tolga wrote: >>> i- I agree with the need to "standardize" the "connection reuse per >>> existing deployment semantics". I think what we are looking for is: >>> >>> - Bidirectional connection reuse with TLS/server-side only >>> certificate/UE authentication per SIP registration without RFC5626 >>> >>> - Bidirectional connection reuse with TCP over VPN, e.g. IPSec >>> >>> - Bidirectional connection reuse with TCP when >>> authentication/security is provided by L2 >> >> The problem in all of these cases is for the entity sending a request to be able >> to ascertain that the connection terminates on a device known to correspond >> to the URI used to address it. >> >> Outbound was created to solve that problem. I have yet to see another >> "simpler" solution that provides that assurance. >> >> As currently defined outbound can be used without redundancy if that is >> what you want to do. There is a requirement for the software to >> *support* use of redundancy, but deployments are free to configure >> without it. So I see no compelling reason to revise outbound for this purpose. >> >> Maybe there is something simpler than outbound that will work. But it >> remains to be proposed. >> >> Thanks, >> Paul >> >>> I am not sure what would be the best place to address these. It could >>> be either happy-earballs or a new document. I would prefer the former >>> and can provide text in either case. >>> >>> >>> >>> ii- The issue with SIP/UDP/DTLS is something quite different. It >>> really is more about providing fast/practically feasible failover for >>> DTLS connections (in addition to defining use of UDP/DTLS as a new >>> transport for SIP but this part is relatively straightforward IMHO). >>> In any case, let me use this opportunity to express my strong interest >>> in this work one more time. >>> >>> >>> >>> Thanks, >>> >>> Tolga >>> >>> >>> >>> *From:*Olle E. Johansson [mailto:oej@edvina.net] >>> *Sent:* Thursday, December 22, 2016 12:17 PM >>> *To:* Asveren, Tolga >>> *Cc:* Olle E Johansson ; Christer Holmberg >>> ; Adam Roach ; >>> SIPCORE ; Ben Campbell >>> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and >>> milestones >>> >>> >>> >>> >>> >>> On 22 Dec 2016, at 18:08, Asveren, Tolga >> > wrote: >>> >>> >>> >>> Thanks for the clarification. >>> >>> >>> >>> i- I agree that connection re-use needs to be addressed as it would >>> be a normative change. >>> >>> ii- Is it a mandate that mutual authentication needs to be used if >>> transport=tls? If so, that would require another normative change to >>> align with practical needs. >>> >>> The URI for the target and the cert for the UA server needs to match. >>> It's not mutual - two certs in the same TLS session, but that would >>> also >>> >>> be one solution (there is a RFC for that). SIP Outbound permits reuse >>> of the incoming connection and thus >>> >>> avoids this particular problem. >>> >>> >>> >>> iii- I think both i-/ii- are relatively straightforward to address. >>> The more interesting/challenging aspect is how to failover DTLS >>> connections without a need for per-transaction state synchronization >>> and with the fewest round-trips possible. >>> >>> Connection reuse needs to be handled separately and needs to be >>> something that is way more easy to implement than SIP outbound. >>> >>> We need something we can easily test and get it done soon, as I want >>> more TLS on the SIP networks out there :-) >>> >>> >>> >>> The current way to handle this is connection reuse that breaks the >>> RFCs, we have that implementation in Kamailio. >>> >>> If there is an open socket, TLS or TCP, we prefer to use it to make >>> things work. I would love for this to be RFC compliant :-) >>> >>> >>> >>> /O >>> >>> >>> >>> Thanks, >>> >>> Tolga >>> >>> >>> >>> *From:* Olle E. Johansson [mailto:oej@edvina.net] >>> *Sent:* Thursday, December 22, 2016 10:55 AM >>> *To:* Asveren, Tolga >> > >>> *Cc:* Olle E Johansson >; >>> Christer Holmberg >> >; Adam Roach >>> >; SIPCORE >>> >; Ben Campbell >>> > >>> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and >>> milestones >>> >>> >>> >>> >>> >>> On 22 Dec 2016, at 16:34, Asveren, Tolga >> > wrote: >>> >>> >>> >>> Olle, >>> >>> >>> >>> I missed the point about why "practically possible failover" >>> needs to be solved both for TLS/DTLS (I am not arguing it would >>> be good to have a solution for both) and also what this issue in >>> general has something to do with client certificates. >>> >>> Could you provide a bit more information/clarifications? >>> >>> >>> >>> We've discussed it a number of times both here and on the SIP Forum >>> techwg mailing list. You can find summaries here: >>> >>> >>> >>> http://www.slideshare.net/oej/sip-half-outbound-random-notes >>> >>> >>> http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world >>> >>> >>> >>> In short, without SIP Outbound the client connection can't be >>> re-used for outbound requests. Seems like there is a huge >>> >>> resistance to implement SIP Outbound. We need a way for the client >>> to allow the server to reuse the inbound connection >>> >>> for outbound requests even though there's no TLS certificate >>> matching the URI on the client side. >>> >>> >>> >>> We've had a lot of clients register with ";transport=tls" at SIPit >>> without a client cert - which means we can't communicate >>> >>> based on that registration. >>> >>> >>> >>> Cheers, >>> >>> /O >>> >>> >>> >>> >>> Thanks, >>> >>> Tolga >>> >>> >>> >>> *From:* Olle E. Johansson [mailto:oej@edvina.net] >>> *Sent:* Thursday, December 22, 2016 9:08 AM >>> *To:* Asveren, Tolga >> > >>> *Cc:* Olle E Johansson >; >>> Christer Holmberg >> >; Adam Roach >>> >; SIPCORE >>> >; Ben Campbell >>> > >>> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and >>> milestones >>> >>> >>> >>> >>> >>> On 22 Dec 2016, at 14:50, Asveren, Tolga >>> > >> wrote: >>> >>> >>> >>> Regarding the interest in SIP/UDP/DTLS: >>> >>> This is mainly based on prospect of larger scalability on >>> server side. There may/may not be an immediate need to >>> tweak/change things to make DTLS related processing >>> (hopefully just on the local stack level rather than on >>> on-the-wire protocol- with some supporting SIP enhancements) >>> more "failover friendly". This issue requires more >>> analysis/discussion but does not sound unsolvable IMHO. >>> >>> We will have to solve client connection reuse for both TLS and >>> DTLS sessions though. Unless you want to have >>> >>> client certificates on all devices. >>> >>> >>> >>> Adam as chair: SIP Client Connection Reuse is something we've >>> disussed under multiple names - "half outbound" or "why is >>> ;transport=tls" >>> >>> deprecated" or "Why doesn't SIP Outbound happen?". Maybe that >>> deserves a milestone. >>> >>> >>> >>> /O >>> >>> >>> >>> >>> >>> Thanks, >>> >>> Tolga >>> >>> >>> >>> *From:* sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf >>> Of *Christer Holmberg >>> *Sent:* Thursday, December 22, 2016 7:39 AM >>> *To:* Adam Roach >> >; 'SIPCORE' >> > >>> *Cc:* Ben Campbell > > >>> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work >>> and milestones >>> >>> >>> >>> Hi, >>> >>> >>> >>> I will obviously be actively involved in 4), and I also >>> agree that 5) should be done as it is a correction. >>> >>> >>> >>> As far as the other potential work is concerned, 3) has the >>> highest priority for me, and I would actively participate in >>> that work. >>> >>> >>> >>> I would review 1) and 2), but I would really like to see an >>> individual draft on 2) before we agree whether to create a >>> milestone for it. For example, I would like to see some >>> input on WHY to do it, and HOW it is intended to be deployed >>> etc. How does DTLS fit SIP? What are the advantages? OR, do >>> we want to specify DTLS-for-SIP simply because DTLS is "hot"? >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> *From: *sipcore >> > on behalf of >>> "adam@nostrum.com " >>> > >>> *Date: *Tuesday 20 December 2016 at 22:27 >>> *To: *"sipcore@ietf.org " >>> > >>> *Cc: *Ben Campbell > > >>> *Subject: *[sipcore] RESPONSE REQUESTED: SIPCORE work and >>> milestones >>> >>> >>> >>> [as chair] >>> >>> Now that we have our new charter approved, I'd like the >>> working group to have a discussion about the specific work >>> items that we should take on in the short- to medium-term so >>> that we can revise our milestones appropriately. Based on >>> recent discussions on the mailing list, the following topics >>> have some mind-share behind them. What I'd like from >>> everyone with an interest in any of these topics is to >>> indicate (a) whether you are willing to actively review and >>> comment on documents on the topic; and (b) what priority >>> each task has relative to each other: there are five topics; >>> please indicate a unique priority from one (most important) >>> to five (least important) for each topic. >>> >>> 1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently >>> under discussion on the list. >>> 2. "DTLS Transport for SIP", as proposed by Tolga Asveren's >>> recent messages. >>> 3. A mechanism for labeling the nature of SIP calls, with >>> as a likely >>> candidate draft. >>> 4. Fixing Content-ID in SIP, as discussed >>> in > archive/web/sipcore/current/msg07245.html> >>> > archive/web/sipcore/current/msg07245.html>, >>> with as a likely >>> candidate draft. >>> 5. Clarifications around SIP name-addr, with >>> as a likely >>> candidate draft >>> >>> >>> I will also note that we have already declared consensus on >>> adopting as a WG >>> document, and will be adding an associated milestone. I want >>> to take this opportunity to remind people that the document >>> is in WGLC, and your comments are strongly encouraged, the >>> earlier the better. >>> >>> Please respond before the end of 2016. Thanks! >>> >>> Thanks! >>> >>> /a >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat Dec 24 22:52:27 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BB6129539 for ; Sat, 24 Dec 2016 22:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 hQ0i9Qq-KhOp for ; Sat, 24 Dec 2016 22:52:23 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0060.outbound.protection.outlook.com [104.47.40.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455ED1294C1 for ; Sat, 24 Dec 2016 22:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TIeckjiEfYj/WHHtcZbCdR6QwvsjDEy/o0fT9T30kBA=; b=fq9okgExJ+9x0bslwAif3ZWvDYpGekZlL0z4nNL1hVwfBBXFKgujjlX2ttKIPIxNjMp0OPdaGip6ratO9ykNFWCdSFzNggZEr/TGZ3+kQjmy1/qHmZ9/3gcsDnEMpHHM1vak6Yr0v2WE6pNT7z6Y8jZeeNCfQ5H7VMEruQEgSG0= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Sun, 25 Dec 2016 06:52:20 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.018; Sun, 25 Dec 2016 06:52:20 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones Thread-Index: AQHSWv96++N6DRIq/E2cKGNWf6YDKaET6r4AgAAS3iCAAAYCAIAAF0yAgAAGmwCAABLYMIAAA+sAgADDHnCAASGggIAA44IggAA6lwCAAOGykA== Date: Sun, 25 Dec 2016 06:52:19 +0000 Message-ID: References: <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> <955f2fa5-887a-fb54-d694-134e4cdab5f6@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 9605afc4-efe4-4f3e-69d8-08d42c9292b9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:ZBudpzYOGZKyjJ6MpxAzyHmefxJ5NVSV3Bj9yZGBHSyZZM4gZoXaqXMf3nYkmSe5OuY7D09AHVlXNQxbqh2JB5tZ/Th0h38rAYAFL53GSvvAJoZ8b5njwmolJ53BnlC9ovbfPy+a4JlXdWldvPkmqxIUeuA1ZEX4PO754SHL+Esv85DYJpFmaOySHiPhOGa3QLO7ho1Qhn6JDcs7zGF9tWTaOvv1cPVWtagOLRSlDG3t7Ebze0vlxqQs8SZVazOLzR7qEM4pdSz0OjivfpihoRToco1Tuzk/bM7U1oJleaxwmEH8Gts/dWBDMlkXjFYerMTxEqNdUI7OGizLaXPeVAy69jYMPkTbDro6HfZWqvkR9l5EbNK0gyTZZTs9nRIeCSaa7l6y+sGby9JaDHd+jGDBSGVUXGu9jVC0a3A5YCvUiahPf8MNCsTP8Hbr6PTmCln8PrWSaLUFuSZDYLBxEQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(68173958961439)(192374486261705)(100405760836317)(178636050973902)(132712982866762); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 0167DB5752 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(51914003)(13464003)(199003)(377454003)(189002)(55885003)(105586002)(3660700001)(99286002)(106356001)(5001770100001)(97736004)(106116001)(3280700002)(33656002)(551934003)(76176999)(54356999)(50986999)(3846002)(107886002)(66066001)(101416001)(93886004)(189998001)(92566002)(6116002)(102836003)(7696004)(2950100002)(5660300001)(2501003)(68736007)(9686002)(76576001)(8666007)(81156014)(8676002)(81166006)(2900100001)(122556002)(2906002)(1720100001)(8936002)(6506006)(305945005)(74316002)(86362001)(229853002)(25786008)(7736002)(6436002)(77096006)(38730400001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Dec 2016 06:52:19.9140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2016 06:52:26 -0000 Inline... Thanks, Tolga > -----Original Message----- > From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net] > Sent: Saturday, December 24, 2016 10:15 AM > To: Asveren, Tolga ; sipcore@ietf.org > Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones >=20 > On 12/24/16 7:08 AM, Asveren, Tolga wrote: > > RFC5626 seems to be leaving some room to use a single registration: > > "For each outbound proxy URI in the set, the User Agent Client (UAC) > > SHOULD send a REGISTER request using this URI as the default outboun= d > > proxy. (Alternatively, the UA could limit the number of flows forme= d > > to conserve battery power, for example). If the set has more than > > one URI, the UAC MUST send a REGISTER request to at least two of the > > default outbound proxies from the set. " > > > > OTOH it mandates use of reg-id/+sip.instance parameters: > > "A UAC conforming to this specification MUST include in the Contact > > header field, a "reg-id" parameter that is distinct from other > > "reg-id" parameters used in other registrations that use the same > > "+sip.instance" Contact header field parameter and AOR." > > > > I am not arguing that these parameters are not adding value/addressing > certain requirements. > > I just think that not everything they are helping with is absolutely n= eeded > by many existing deployments. >=20 > Maybe not. But it is what we have. Is it such a burden that we need to de= fine > something else? [TOLGA] In terms of "burden in practice", yes IMHO. There is a large set of= existing deployments behaving in certain way and I don't see people giving= up that model/it causing any issues. It would be good to standardize it -a= nd to add some clarifications/warnings/guidelines as needed- so that people= have a more informed understanding. >=20 > > IMHO the main requirement for "simple outbound" is: > > (Re)use a single TCP connection between UA/Edge Proxy. >=20 > Do you really mean TCP? Or do you really mean TLS? [TOLGA] Politically correct answer: TLS. OTOH, the behavior I described is= widely used with TCP as well. With VPN/L2 security, this probably should b= e acceptable even within IETF. There are also several cases, where there is= no VPN/L2 security and folks are still fine with using TCP this way(althou= gh not addressing a MitM attack, TCP sequence numbers, SIP Call-Id/to-tag/f= rom-tag provide some resiliency for many more common/practical attack scena= rios)). I would prefer allowing TCP as well -in the specification, if there= is agreement to have one- with information about security aspects.=20 >=20 > > This is anyhow how many deployments out in the wild operate. >=20 > Yes, but this has not been vetted for security. >=20 > > It would be great if that could be allowed (maybe with a SHOULD in happ= y- > earballs). > > Iy may be even possible to define semantics without use of an > > option-tag - I am not sure though whether we can end up with something > kosher from IETF perspective-. > > > > As far as authentication is concerned: > > i- For TLS(only server certificate) > > Server authenticated based on X.509 certificate UE authenticated > > during registration (digest) >=20 > This only works in the case that the registrar is the first hop from the = UA, and > is also the home proxy for all subsequent sip messaging. >=20 > Is that a workable limitation? [TOLGA] This is how things operate mostly in practice. It can be mentioned = as when the mechanism is applicable. >=20 > > ii- For TLS(certificate for both ends) Already covered by RFC5923 > > > > iii- For VPN > > Both ends are authenticated during VPN setup, e.g. IMS AKA. >=20 > ISTM the problem in this case is tying the endpoints and credentials used= for > VPN setup with the URL used to identify the two endpoints for sip > messaging. [TOLGA] Again, based on practice/existing deployments: IMS AKA: The identity provided by SIM/USIM is what is used for SIP as well. VPN among servers: Servers know each other based on preconfigured data, e.g= . IP Address, and that is used during VPN setup and by SIP (possibly after = DNS resolution) TLS(only server side certificate): X.509 identity is what is used by SIP. R= egistered AoR (for UE authentication) is anyhow what SIP uses. I don't see any problem/issues on this front. Again, all this is based on h= ow things operate in practice for many years. >=20 > > Overall, I don't see any problem with your "knowing who is on the > > other end" question. Maybe I am missing your point(?) >=20 > See above. Note, I don't claim to be a security expert. We really need so= me > in this discussion. >=20 > Thanks, > Paul >=20 > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul > >> Kyzivat > >> Sent: Friday, December 23, 2016 5:11 PM > >> To: sipcore@ietf.org > >> Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and > >> milestones > >> > >> On 12/23/16 3:30 AM, Asveren, Tolga wrote: > >>> i- I agree with the need to "standardize" the "connection reuse per > >>> existing deployment semantics". I think what we are looking for is: > >>> > >>> - Bidirectional connection reuse with TLS/server-side only > >>> certificate/UE authentication per SIP registration without RFC5626 > >>> > >>> - Bidirectional connection reuse with TCP over VPN, e.g. IPS= ec > >>> > >>> - Bidirectional connection reuse with TCP when > >>> authentication/security is provided by L2 > >> > >> The problem in all of these cases is for the entity sending a request > >> to be able to ascertain that the connection terminates on a device > >> known to correspond to the URI used to address it. > >> > >> Outbound was created to solve that problem. I have yet to see another > >> "simpler" solution that provides that assurance. > >> > >> As currently defined outbound can be used without redundancy if that > >> is what you want to do. There is a requirement for the software to > >> *support* use of redundancy, but deployments are free to configure > >> without it. So I see no compelling reason to revise outbound for this > purpose. > >> > >> Maybe there is something simpler than outbound that will work. But it > >> remains to be proposed. > >> > >> Thanks, > >> Paul > >> > >>> I am not sure what would be the best place to address these. It > >>> could be either happy-earballs or a new document. I would prefer the > >>> former and can provide text in either case. > >>> > >>> > >>> > >>> ii- The issue with SIP/UDP/DTLS is something quite different. It > >>> really is more about providing fast/practically feasible failover > >>> for DTLS connections (in addition to defining use of UDP/DTLS as a > >>> new transport for SIP but this part is relatively straightforward IMH= O). > >>> In any case, let me use this opportunity to express my strong > >>> interest in this work one more time. > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Tolga > >>> > >>> > >>> > >>> *From:*Olle E. Johansson [mailto:oej@edvina.net] > >>> *Sent:* Thursday, December 22, 2016 12:17 PM > >>> *To:* Asveren, Tolga > >>> *Cc:* Olle E Johansson ; Christer Holmberg > >>> ; Adam Roach > ; > >>> SIPCORE ; Ben Campbell > >>> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and > >>> milestones > >>> > >>> > >>> > >>> > >>> > >>> On 22 Dec 2016, at 18:08, Asveren, Tolga >>> > wrote: > >>> > >>> > >>> > >>> Thanks for the clarification. > >>> > >>> > >>> > >>> i- I agree that connection re-use needs to be addressed as it wou= ld > >>> be a normative change. > >>> > >>> ii- Is it a mandate that mutual authentication needs to be used i= f > >>> transport=3Dtls? If so, that would require another normative chan= ge to > >>> align with practical needs. > >>> > >>> The URI for the target and the cert for the UA server needs to match. > >>> It's not mutual - two certs in the same TLS session, but that would > >>> also > >>> > >>> be one solution (there is a RFC for that). SIP Outbound permits > >>> reuse of the incoming connection and thus > >>> > >>> avoids this particular problem. > >>> > >>> > >>> > >>> iii- I think both i-/ii- are relatively straightforward to addres= s. > >>> The more interesting/challenging aspect is how to failover DTLS > >>> connections without a need for per-transaction state synchronizat= ion > >>> and with the fewest round-trips possible. > >>> > >>> Connection reuse needs to be handled separately and needs to be > >>> something that is way more easy to implement than SIP outbound. > >>> > >>> We need something we can easily test and get it done soon, as I want > >>> more TLS on the SIP networks out there :-) > >>> > >>> > >>> > >>> The current way to handle this is connection reuse that breaks the > >>> RFCs, we have that implementation in Kamailio. > >>> > >>> If there is an open socket, TLS or TCP, we prefer to use it to make > >>> things work. I would love for this to be RFC compliant :-) > >>> > >>> > >>> > >>> /O > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Tolga > >>> > >>> > >>> > >>> *From:* Olle E. Johansson [mailto:oej@edvina.net] > >>> *Sent:* Thursday, December 22, 2016 10:55 AM > >>> *To:* Asveren, Tolga >>> > > >>> *Cc:* Olle E Johansson >; > >>> Christer Holmberg >>> >; Adam Roach > >>> >; SIPCORE > >>> >; Ben Campbell > >>> > > >>> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and > >>> milestones > >>> > >>> > >>> > >>> > >>> > >>> On 22 Dec 2016, at 16:34, Asveren, Tolga >>> > wrote: > >>> > >>> > >>> > >>> Olle, > >>> > >>> > >>> > >>> I missed the point about why "practically possible failover" > >>> needs to be solved both for TLS/DTLS (I am not arguing it wou= ld > >>> be good to have a solution for both) and also what this issue= in > >>> general has something to do with client certificates. > >>> > >>> Could you provide a bit more information/clarifications? > >>> > >>> > >>> > >>> We've discussed it a number of times both here and on the SIP For= um > >>> techwg mailing list. You can find summaries here: > >>> > >>> > >>> > >>> http://www.slideshare.net/oej/sip-half-outbound-random-notes > >>> > >>> > >>> http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-wor > >>> ld > >>> > >>> > >>> > >>> In short, without SIP Outbound the client connection can't be > >>> re-used for outbound requests. Seems like there is a huge > >>> > >>> resistance to implement SIP Outbound. We need a way for the clien= t > >>> to allow the server to reuse the inbound connection > >>> > >>> for outbound requests even though there's no TLS certificate > >>> matching the URI on the client side. > >>> > >>> > >>> > >>> We've had a lot of clients register with ";transport=3Dtls" at SI= Pit > >>> without a client cert - which means we can't communicate > >>> > >>> based on that registration. > >>> > >>> > >>> > >>> Cheers, > >>> > >>> /O > >>> > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Tolga > >>> > >>> > >>> > >>> *From:* Olle E. Johansson [mailto:oej@edvina.net] > >>> *Sent:* Thursday, December 22, 2016 9:08 AM > >>> *To:* Asveren, Tolga >>> > > >>> *Cc:* Olle E Johansson >; > >>> Christer Holmberg >>> >; Adam Roach > >>> >; SIPCORE > >>> >; Ben Campbell > >>> > > >>> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and > >>> milestones > >>> > >>> > >>> > >>> > >>> > >>> On 22 Dec 2016, at 14:50, Asveren, Tolga > >>> > > >> wrote: > >>> > >>> > >>> > >>> Regarding the interest in SIP/UDP/DTLS: > >>> > >>> This is mainly based on prospect of larger scalability on > >>> server side. There may/may not be an immediate need to > >>> tweak/change things to make DTLS related processing > >>> (hopefully just on the local stack level rather than on > >>> on-the-wire protocol- with some supporting SIP enhancemen= ts) > >>> more "failover friendly". This issue requires more > >>> analysis/discussion but does not sound unsolvable IMHO. > >>> > >>> We will have to solve client connection reuse for both TLS an= d > >>> DTLS sessions though. Unless you want to have > >>> > >>> client certificates on all devices. > >>> > >>> > >>> > >>> Adam as chair: SIP Client Connection Reuse is something we've > >>> disussed under multiple names - "half outbound" or "why is > >>> ;transport=3Dtls" > >>> > >>> deprecated" or "Why doesn't SIP Outbound happen?". Maybe that > >>> deserves a milestone. > >>> > >>> > >>> > >>> /O > >>> > >>> > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Tolga > >>> > >>> > >>> > >>> *From:* sipcore [mailto:sipcore-bounces@ietf.org] *On Beh= alf > >>> Of *Christer Holmberg > >>> *Sent:* Thursday, December 22, 2016 7:39 AM > >>> *To:* Adam Roach >>> >; 'SIPCORE' >>> > > >>> *Cc:* Ben Campbell >> > > >>> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work > >>> and milestones > >>> > >>> > >>> > >>> Hi, > >>> > >>> > >>> > >>> I will obviously be actively involved in 4), and I also > >>> agree that 5) should be done as it is a correction. > >>> > >>> > >>> > >>> As far as the other potential work is concerned, 3) has t= he > >>> highest priority for me, and I would actively participate= in > >>> that work. > >>> > >>> > >>> > >>> I would review 1) and 2), but I would really like to see = an > >>> individual draft on 2) before we agree whether to create = a > >>> milestone for it. For example, I would like to see some > >>> input on WHY to do it, and HOW it is intended to be deplo= yed > >>> etc. How does DTLS fit SIP? What are the advantages? OR, = do > >>> we want to specify DTLS-for-SIP simply because DTLS is "h= ot"? > >>> > >>> > >>> > >>> Regards, > >>> > >>> > >>> > >>> Christer > >>> > >>> > >>> > >>> *From: *sipcore >>> > on behalf of > >>> "adam@nostrum.com " > >>> > > >>> *Date: *Tuesday 20 December 2016 at 22:27 > >>> *To: *"sipcore@ietf.org " > >>> > > >>> *Cc: *Ben Campbell >> > > >>> *Subject: *[sipcore] RESPONSE REQUESTED: SIPCORE work and > >>> milestones > >>> > >>> > >>> > >>> [as chair] > >>> > >>> Now that we have our new charter approved, I'd like the > >>> working group to have a discussion about the specific wor= k > >>> items that we should take on in the short- to medium-term= so > >>> that we can revise our milestones appropriately. Based on > >>> recent discussions on the mailing list, the following top= ics > >>> have some mind-share behind them. What I'd like from > >>> everyone with an interest in any of these topics is to > >>> indicate (a) whether you are willing to actively review a= nd > >>> comment on documents on the topic; and (b) what priority > >>> each task has relative to each other: there are five topi= cs; > >>> please indicate a unique priority from one (most importan= t) > >>> to five (least important) for each topic. > >>> > >>> 1. "Happy Eyeballs for SIP" (aka Happy Earballs), curren= tly > >>> under discussion on the list. > >>> 2. "DTLS Transport for SIP", as proposed by Tolga Asvere= n's > >>> recent messages. > >>> 3. A mechanism for labeling the nature of SIP calls, wit= h > >>> as a likely > >>> candidate draft. > >>> 4. Fixing Content-ID in SIP, as discussed > >>> in >> archive/web/sipcore/current/msg07245.html> > >>> >> archive/web/sipcore/current/msg07245.html>, > >>> with as a likely > >>> candidate draft. > >>> 5. Clarifications around SIP name-addr, with > >>> as a likely > >>> candidate draft > >>> > >>> > >>> I will also note that we have already declared consensus = on > >>> adopting as a WG > >>> document, and will be adding an associated milestone. I w= ant > >>> to take this opportunity to remind people that the docume= nt > >>> is in WGLC, and your comments are strongly encouraged, th= e > >>> earlier the better. > >>> > >>> Please respond before the end of 2016. Thanks! > >>> > >>> Thanks! > >>> > >>> /a > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >