From nobody Fri Jul 11 06:59:28 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AA91B2B00 for ; Fri, 11 Jul 2014 06:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqSiIsqReUx7 for ; Fri, 11 Jul 2014 06:59:19 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.115]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCDA1B2AFD for ; Fri, 11 Jul 2014 06:59:16 -0700 (PDT) Received: from [193.109.254.3:38246] by server-11.bemta-14.messagelabs.com id DD/D2-12767-2BDEFB35; Fri, 11 Jul 2014 13:59:14 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-3.tower-184.messagelabs.com!1405087153!10819043!1 X-Originating-IP: [195.232.224.78] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16704 invoked from network); 11 Jul 2014 13:59:14 -0000 Received: from mailout09.vodafone.com (HELO mailout09.vodafone.com) (195.232.224.78) by server-3.tower-184.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Jul 2014 13:59:14 -0000 Received: from mailint09.vodafone.com (localhost [127.0.0.1]) by mailout09.vodafone.com (Postfix) with ESMTP id 2BF8EE0122 for ; Fri, 11 Jul 2014 15:59:11 +0200 (CEST) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint09.vodafone.com (Postfix) with ESMTPS id 198F3E00E1; Fri, 11 Jul 2014 15:59:11 +0200 (CEST) Received: from VOEXC10W.internal.vodafone.com (145.230.101.30) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 11 Jul 2014 15:59:10 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.58]) by VOEXC10W.internal.vodafone.com ([145.230.101.30]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 15:59:09 +0200 From: "Dawes, Peter, Vodafone Group" To: "insipid@ietf.org" Thread-Topic: draft-dawes-insipid-logme-marking-00 Thread-Index: Ac+dDTxIN5Z96SedQKqtU/qDZaqMIA== Date: Fri, 11 Jul 2014 13:59:08 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99870F1A91@VOEXM31W.internal.vodafone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/doH8LzIUpM0nDvtLcm0h409J9PU Cc: "DRAGE, Keith \(Keith\) \(keith.drage@alcatel-lucent.com\)" , "Gonzalo Salgueiro \(gsalguei@cisco.com\)" Subject: [Insipid] draft-dawes-insipid-logme-marking-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 13:59:25 -0000 Hello All, I have updated the draft that describes a protocol solution to the 'log me'= requirements in http://datatracker.ietf.org/doc/draft-ietf-insipid-logme-r= eqs/ based on comments on the list and at IETF#89 in London. Draft submissi= on seems to be closed until July 21st so I have copied the text below I wil= l upload when submission re-opens. The main changes are: - only one solution is described, based on the Session-ID header field - renamed the draft from "draft-dawes-inspid-logme-solutions" to "draft-da= wes-insipid-logme-marking-00" - removed all text related to sending logs to a server - redundant references have been removed and some references have been mov= ed from "informative" to "normative" - added clauses for ABNF and IANA considerations - key words capitalized I would be happy to hear any comments or questions. Regards, Peter Internet Engineering Task Force P. Dawes Internet-Draft Vodafone Group Intended status: Standards Track July 11, 2014 Expires: January 12, 2015 Marking SIP Messages to be Logged draft-dawes-insipid-logme-marking-00 Abstract SIP networks use signalling monitoring tools to diagnose user reported problems and for regression testing if network or user agent software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between user agents, and therefore impractical to monitor SIP signalling end-to-end. This document describes an indicator for the SIP protocol which can be used to mark signalling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular user agent signalling. However, such marking can be carried end-to-end including the SIP user agents, even if a session originates and terminates in different networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Dawes Expires January 12, 2015 [Page 1] Internet-Draft log me marking July 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Motivating Scenario . . . . . . . . . . . . . . . . . . . . . 3 4. Skeleton Diagnostic Procedure . . . . . . . . . . . . . . . . 4 5. Protocol for Log-Me Marking . . . . . . . . . . . . . . . . . 5 5.1. Configuration for Log-Me Marking . . . . . . . . . . . . 5 5.2. Starting and Stopping Log-Me Marking . . . . . . . . . . 5 5.3. End Points of Log-Me Marking . . . . . . . . . . . . . . 6 5.3.1. Originating and Terminating User Agent . . . . . . . 6 5.3.2. Originating Edge Proxy and Terminating Edge Proxy . . 7 5.4. Maintaining State . . . . . . . . . . . . . . . . . . . . 7 5.5. Missing Log-me Marker in Dialog Being Logged . . . . . . 9 5.6. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 10 5.7. Forked Requests and Back to Back User Agents . . . . . . 10 5.7.1. Propagating the Log-me Marker in Forked Requests . . 10 5.7.2. B2BUA Processing of Log-Me Marker . . . . . . . . . . 10 5.8. 'Log-Me' Marker . . . . . . . . . . . . . . . . . . . . . 10 5.8.1. Header Field Parameter for Session-ID . . . . . . . . 10 5.8.2. Identifying Test Cases . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. Trust Domain . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Security Threats . . . . . . . . . . . . . . . . . . . . 11 6.2.1. The Log-Me Marker . . . . . . . . . . . . . . . . . . 11 6.2.2. Activating Debug . . . . . . . . . . . . . . . . . . 11 6.3. Protecting Logs . . . . . . . . . . . . . . . . . . . . . 12 7. Augmented BNF for the "debug" Parameter . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8.1. Registration of the "debug" Parameter . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Dawes Expires January 12, 2015 [Page 2] Internet-Draft log me marking July 2014 1. Introduction If users experience problems with setting up sessions using SIP, their service provider needs to find out why by examining the SIP signalling. Also, if network or user agent software or hardware is upgraded regression testing is needed. Such diagnostics apply to a small proportion of network traffic and can apply end-to-end, even if signalling crosses several networks possibly belonging to several different network operators. It may not be possible to predict the path through those networks in advance, therefore a mechanism is needed to mark a session as being of interest so that SIP entities along the signalling path can provide diagnostic logging. This document describes a solution that meets the requirements for such a 'log me' marker for SIP signalling as defined in draft-insipid-logme- reqs [I-D.dawes-insipid-logme-reqs]. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Motivating Scenario Signalling for SIP session setup can cross several networks, and these networks may not have common ownership and also may be in differrent countries. If a single operator wishes to perform regression testing or fault diagnosis end-to-end, the separate ownership of networks that carry the signalling and the explosion in the number of possible signalling paths through SIP entities from the originating to the terminating user make it impractical to pre- configure logging of an end-to-end SIP signalling of a session of interest. The figure below shows an example of a signalling path through multiple networks. Dawes Expires January 12, 2015 [Page 3] Internet-Draft log me marking July 2014 +------------------+ +------------------+ | COUNTRY A | | COUNTRY B | | Operator A | | Operator A | | | | | | SIP Phones | | SIP Phones | | | //| | +------------------+ // +------------------+ | // | // ,'```', // +------------------+ .`',.' `..'``',<=3D=3D// | COUNTRY B | ,' Operator A `', | Operator A | ; Backbone Network ..'-------| | ', ,., .'` | PSTN phones | '.,.`'.,,,.` `''` | | || +------------------+ || \/ +------------------+ | | | Transit Network | | | | |\\ +------------------+ \\ | \\ | \\ +------------------+ \\ +------------------+ | COUNTRY D | \\ | COUNTRY C | | Operator C | \\=3D>| Operator B | | | | | | SIP Phones | | SIP Phones | | | | | +------------------+ +------------------+ Figure 1: Example signalling path through multiple networks 4. Skeleton Diagnostic Procedure The skeleton diagnostic procedure is as follows: o The user's user agent is placed in debug mode. The user agent logs its own signalling and inserts a log me marker into SIP requests for session setup o All SIP entities that the signalling traverses, from the first proxy the user agent connects to at the edge of the network to the destination user agent, can detect that the log me marker is Dawes Expires January 12, 2015 [Page 4] Internet-Draft log me marking July 2014 present and can log SIP requests and responses that contain the marker if configured to do so. o Subsequent responses and requests in the same dialog are logged. o Logging stops, either because the dialog has ended or because a 'stop event', typically expiry of a certain amount of time, occurred o The user's user agent and any other SIP entity that has logged signalling sends logs to a server that is co-ordinating diagnostics. 5. Protocol for Log-Me Marking This clause describes the protocol solution to the log-me requirements described in draft-dawes-insipid-logme-reqs [I-D.dawes-insipid-logme-reqs]. 5.1. Configuration for Log-Me Marking Configuration of a user agent or proxy to perform log-me marking can be done in any way that is convenient to the configured entity. For example, an XML file might be used to list conditions for starting and stopping based on time. 09:00:00 09:10:00 Figure 2: Simple example log-me configuration Logging is on a per-dialog basis and individual logs are differentiated by their test identifier, which is defined in Section 5.8.2 of this document. Therefore, an individual log for an individual dialog is closed when that dialog ends. Logging is typically done separately from regualar operation, which means that tests can be designed to be short enough to troubleshoot quickly and to limit the size of individual logs. If logging is configured so that everything is logged for a specified number of minutes then several separate dialogs might start and finish meaning that several logs may be generated, each one distinguished by its test identifier. 5.2. Starting and Stopping Log-Me Marking A proxy or user agent needs to determine when it needs to log-me mark a SIP request or response. A user agent or proxy log-me marks a request or response for two reasons: either it is configured to do so or it has detected that a dialog is being log-me marked and maintains Dawes Expires January 12, 2015 [Page 5] Internet-Draft log me marking July 2014 state to ensure that all requests and responses in the dialog are log-me marked. A regression test might be configured to log-me mark all SIP dialogs created during a given time period whereas a troubleshooting test might be configured to mark a dialog based on criteria specific to a reported fault. When configuration has caused a user agent or proxy to start log-me marking requests and responses, marking continues until the dialog ends. 5.3. End Points of Log-Me Marking Log-me marking is initiated on a dialog creating side controlled by configuration. The dialog terminating side detects an incoming log- me marker and reacts accordingly. 5.3.1. Originating and Terminating User Agent In the simplest case, an originating user agent will insert a log-me marker in the dialog-creating SIP request and all subsequent SIP requests within that dialog. The log-me marker is carried to the terminating user agent and the terminating user agent echoes the log- me marker in responses. If the terminating user agent sends an in- dialog request on a dialog that is being log-me marked, it inserts a log-me marker and the originating user agent echoes the log-me marker in responses. This basic case suggests the following principles: o The originating user agent is configured for debug o The terminating user agent is not configured for debug and cannot initiate log-me marking. o The originating user agent logs its own signalling and inserts a log me marker into the dialog-creating SIP request and subsequent in-dialog SIP requests. o The terminating user agent can detect that a dialog is of interest to logging by the existence of a log-me marker in an incoming dialog-creating SIP request. o The terminating user agent MUST echo a log-me marker in responses to a SIP request that included a log-me marker. o If the terminating user agent has detected that a dialog is being log-me marked, it inserts a log-me marker in any in-dialog SIP requests that it sends. Dawes Expires January 12, 2015 [Page 6] Internet-Draft log me marking July 2014 5.3.2. Originating Edge Proxy and Terminating Edge Proxy Some user agents might not support log-me marking. In order to test sessions involving such user agents, the log-me marker is inserted by edge proxies on the originating and terminating sides. The log-me marker is carried to the terminating user agent but the terminating user agent is not able to echo the log-me marker in responses to that request. Therefore the terminating edge proxy inserts a log-me marker in reponses to the request. Likewise, if the terminating user agent sends an in-dialog request, the terminating edge proxy inserts a log-me marker and the originating edge proxy echoes the log-me marker in responses to that request. This case suggests the following principles: o The originating edge proxy is configured for debug. o The terminating edge proxy is not configured for debug and cannot initiate log-me marking. o The originating edge proxy logs its own signalling and inserts a log me marker into SIP requests for session setup. o The terminating edge proxy can detect that a dialog is of interest to logging by the existence of a log-me marker in an incoming SIP request. o The terminating edge proxy MUST echo a log-me marker in responses to a SIP request that included a log-me marker. o If the terminating edge proxy has detected that a dialog is being log-me marked, it inserts a log-me marker in in-dialog SIP requests from the terminating user agent. o The originating edge proxy echoes the log-me marker in responses to in-dialog requests received from the terminating side. 5.4. Maintaining State If a proxy inserts a log-me marker in a SIP request (because a user agent did not) then it must ensure that a log-me marker is also inserted in responses to that request. A proxy on the terminating side that receives a SIP reqeust with a log-me marker may also ensure that responses to that requset contain a log-me marker by inserting one if the terminating user agent did not. Entities that perform this log-me marking or checking must maintain a record of which dialogs are being log-me marked. Dawes Expires January 12, 2015 [Page 7] Internet-Draft log me marking July 2014 In the figure below, the edge proxy in the originating network maintains state to ensure log-me marking of SIP requests and in the terminating network the registrar maintains state to ensure log-me marking of SIP responses. Such behaviour is useful for logging if end devices do not insert or echo a log-me marker. Alice Proxy Registrar u1.foocorp.com p1.foocorp.com r1.foocorp.com | | | |(1) INVITE | | | (u1 does not insert log-me marker in SIP request) |----------------->| | | |(2) INVITE | | | 'log-me' marker | | (p1 inserts log-me marker. p1 maintains | | state and inserts log-me marker in all | | requests on this dialog) | |----------------->| | | |(3) INVITE | | | 'log-me' marker | | |--------> (to barcorp) | | | | | | | | | | | |(8) 200 OK | | | 'log-me' marker | |(9) 200 OK |<-------- (from barcorp) | | 'log-me' marker | |<-----------------| |(10) 200 OK | | | 'log-me' marker | |<-----------------| | | | | |(11) ACK | | |---------------------------------------------------------> | | | Proxy Registrar Bob p1.barcorp.com r1.barcorp.com u1.barcorp.com | | | (3) INVITE | | 'log-me' marker | | ----->|(from foocorp) | | | | | |(4) INVITE | | | 'log-me' marker | Dawes Expires January 12, 2015 [Page 8] Internet-Draft log me marking July 2014 |----------------->| | | |(r1 detects that this dialog is | | being log-me marked) | | | | | | | |(5) INVITE | | 'log-me' marker | |----------------->| | | | | |(6) 200 OK | | | (u1 does not echo LogMe: | | to SIP response)| | |<-----------------| |(7) 200 OK | | |'log-me' marker | | | (r1 inserts log-me marker. r1 maintains | state and inserts log-me marker in all | responses on this dialog) |<-----------------| | | | | (8) 200 OK | | 'log-me' marker | | <----| | | | | | (11) ACK | | from foocorp) -------------------------->| | | | | | | | |(12) re-INVITE | | |<-----------------| | |(in-dialog request) | | | |(13) re-INVITE | | |'log-me' marker | | |<-----------------| | |(r1 inserts log-me marker into in-dialog | requests sent from the terminating user agent) | | | Figure 3: Maintaining state for log-me marking 5.5. Missing Log-me Marker in Dialog Being Logged A terminating user agent or terminating edge proxy that has been echoing markers in responses for a given dialog might receive a SIP request that has not been log-me marked. Since log-me marking is done per dialog, this is an error. In such cases, the proxy SHOULD Dawes Expires January 12, 2015 [Page 9] Internet-Draft log me marking July 2014 consider log-me marking to have ended and MUST NOT mark a response to the unmarked request, responses to subsequent requests in the dialog, or in-dialog requests sent from the terminating side. Similarly, log-me marking that begins mid-dialog is an error case and the terminating user agent or edge proxy MUST NOT log-me mark responses to the marked request, responses to subsequent requests in the dialog, or in-dialog requests from the terminating side. 5.6. Logging Multiple Simultaneous Dialogs An originating or terminating user agent and SIP entities on the signaling path can log multiple SIP dialogs simultaneously, these dialogs are differentiated by their test identifier. 5.7. Forked Requests and Back to Back User Agents 5.7.1. Propagating the Log-me Marker in Forked Requests Log-me marking is copied into forked requests. 5.7.2. B2BUA Processing of Log-Me Marker A B2BUA SHOULD act on the terminating side as described for a terminating user agent and therefore log marked incoming requests, echo log-me marking in responses to log-me marked requests, and log- me mark in-dialog SIP requests that it sends if the dialog is being log-me marked. A B2BUA SHOULD act on the originating side as described for an originating user agent and therefore mark SIP requests if and only if configured to do so, and echo log-me marking in responses to in- dialog requests received from the terminating side. 5.8. 'Log-Me' Marker 5.8.1. Header Field Parameter for Session-ID A new header field parameter called debug is defined to be used with the Session-ID header field (described in draft-ietf-insipid-session- id [I-D.ietf-insipid-session-id]). Dawes Expires January 12, 2015 [Page 10] Internet-Draft log me marking July 2014 Alice Proxy Registrar Debug Server u1.foocorp.com p1.foocorp.com r1.foocorp.com d1.foocorp.c= om | | | | |(1) INVITE | | | | Session-ID: ab30317f1a784dc48ff824d0d3715d86; remote=3D47755a= 9de7794ba387653f2099600ef2; debug |----------------->| | | | | | | Figure 4: Log-me marking using the "debug" Session-ID: header field parameter 5.8.2. Identifying Test Cases The test case identifier is the Session-ID in the Session-ID header field (described in draft-ietf-insipid-session-id [I-D.ietf-insipid-session-id]). A log relates to exactly one dialog and logs are distinguished by their test case identifier. 6. Security Considerations 6.1. Trust Domain Since a log me marker may cause a SIP entity to log the SIP header and body of a request or response, the log me marker SHOULD be removed at a trust domain boundary. If a prior agreement to log sessions exists with the net hop network then the log me marker might not be removed. 6.2. Security Threats 6.2.1. The Log-Me Marker The log me marker is not sensitive information, although it will sometimes be inserted because a particular device is experiencing problems. The presence of a log me marker will cause some SIP entities to log signalling. Therefore, this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted. 6.2.2. Activating Debug Activating a debug mode affects the operation of a user agent, therefore it MUST be supplied by an authorized server to an authorized user agent, it MUST NOT be altered in transit, and it MUST NOT be readable by an unauthorized third party. Dawes Expires January 12, 2015 [Page 11] Internet-Draft log me marking July 2014 6.3. Protecting Logs A SIP entity that has logged information SHOULD encrypt it, such that it can be decrypted only by a person authorized to examine the logged information. 7. Augmented BNF for the "debug" Parameter ABNF is described in RFC 5234 [RFC5234] debug-param =3D "debug" 8. IANA Considerations 8.1. Registration of the "debug" Parameter The following parameter is to be added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry: +--------------+----------------+-------------------+-----------+ | Header Field | Parameter Name | Predefined Values | Reference | +--------------+----------------+-------------------+-----------+ | Session-ID | debug | No | [RFCXXXX] | +--------------+----------------+-------------------+-----------+ Table 1 9. References 9.1. Normative References [I-D.dawes-insipid-logme-reqs] Dawes, P., "Requirements for Marking SIP Messages to be Logged", draft-dawes-insipid-logme-reqs-00 (work in progress), January 2014. [I-D.ietf-insipid-session-id] Jones, P., Pearce, C., Polk, J., and G. Salgueiro, "End- to-End Session Identification in IP-Based Multimedia Communication Networks", draft-ietf-insipid-session-id-06 (work in progress), April 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Dawes Expires January 12, 2015 [Page 12] Internet-Draft log me marking July 2014 9.2. Informative References [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Appendix A. Additional Stuff This becomes an Appendix. Author's Address Peter Dawes Vodafone Group The Connection Newbury, Berkshire RG14 2FN UK Email: peter.dawes@vodafone.com Dawes Expires January 12, 2015 [Page 13] From nobody Fri Jul 11 14:04:51 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A321B29B1 for ; Fri, 11 Jul 2014 14:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 409fwRo69CU1 for ; Fri, 11 Jul 2014 14:04:25 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 96A491B29AD for ; Fri, 11 Jul 2014 14:04:23 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta08.westchester.pa.mail.comcast.net with comcast id R64a1o0031ap0As5894Pwg; Fri, 11 Jul 2014 21:04:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id R94N1o01q3ZTu2S3i94N3x; Fri, 11 Jul 2014 21:04:23 +0000 Message-ID: <53C05156.7030602@alum.mit.edu> Date: Fri, 11 Jul 2014 17:04:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: insipid@ietf.org References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99870F1A91@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99870F1A91@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405112663; bh=KSAjN1jirCqh1DKJxUD90kQ9eNvgMzEAOisVejSh/+U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XsJqYD7r9h1nqaEvYP+tEOvmhSiXtb5iYYPbGO8Q0VLy9lWx97Hv1ZQqR+iYGUe4E GkaxSNKRtUNy9vkNi/4AIvZ3xNT5iqEWbLVT7BZdq92ygr9IsrkwmhO6sSRw5DrALK OpXt1nUCCc08FRqZH3h8DQC2v/TY4HHLBbhG/iMWVzbEzcgsKwYR8Z9ize8mAth72k AaC84zMIQDimKaOiExaNkf+CpwGt3Bo04OZbt+9j0CU9hiofNysY8XSRZLhNO92HAv zsDaFSwrENoTi+pWSfIqkIkX+tTeH5ZPEeA9eLVNWV8uao5W65ScJwyHXZWyl5fjVT 8zMOkrkIERrIg== Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/f8csaxJZdK240qfwfVTmwFFKVfI Subject: Re: [Insipid] draft-dawes-insipid-logme-marking-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 21:04:26 -0000 Just a couple of comments: General comment: Run IdNits on this. You at least have lines that are too long. Section 5.7.2. (B2BUA Processing of Log-Me Marker): ISTM that not all B2BUAs should act the same way: - SBC-like B2BUAs will most likely want to forward the logme marker from the incoming dialog to the corresponding outgoing dialog. - more specialized B2BUAs may not want to do that. E.g., a conference focus may not want to forward incoming logme markers to all the other participant dialogs. STRAW has a B2BUA taxonomy that might be useful to you for sorting this out. Thanks, Paul On 7/11/14 9:59 AM, Dawes, Peter, Vodafone Group wrote: > Hello All, > I have updated the draft that describes a protocol solution to the 'log me' requirements in http://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ based on comments on the list and at IETF#89 in London. Draft submission seems to be closed until July 21st so I have copied the text below I will upload when submission re-opens. The main changes are: > > - only one solution is described, based on the Session-ID header field > - renamed the draft from "draft-dawes-inspid-logme-solutions" to "draft-dawes-insipid-logme-marking-00" > - removed all text related to sending logs to a server > - redundant references have been removed and some references have been moved from "informative" to "normative" > - added clauses for ABNF and IANA considerations > - key words capitalized > > I would be happy to hear any comments or questions. > > Regards, > Peter From nobody Mon Jul 21 02:23:57 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0391B2C9D; Mon, 21 Jul 2014 02:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh5xlfoEC5fg; Mon, 21 Jul 2014 02:23:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F3E1B2CAB; Mon, 21 Jul 2014 02:23:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721092352.10119.89448.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 02:23:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/iz4-A5Z_R8aHc2ri89omZ3E1ouI Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-logme-reqs-01.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 09:23:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the INtermediary-safe SIP session ID Working Group of the IETF. Title : Requirements for Marking SIP Messages to be Logged Author : Peter Dawes Filename : draft-ietf-insipid-logme-reqs-01.txt Pages : 8 Date : 2014-07-21 Abstract: SIP networks use signalling monitoring tools to diagnose user reported problem and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between clients, and therefore impractical to monitor SIP signalling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol which can be used to mark signalling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-logme-reqs-01 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 Thu Jul 24 08:43:22 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEB11A0240 for ; Thu, 24 Jul 2014 08:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-uwFzFJtOXn for ; Thu, 24 Jul 2014 08:43:16 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86ED41A0266 for ; Thu, 24 Jul 2014 08:43:15 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s6OFhCqV022993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jul 2014 10:43:14 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6OFh5d9001756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 17:43:12 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 24 Jul 2014 17:42:58 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: Log me requirements Thread-Index: Ac+nVfCw8MYIhTSWRjmcIJtMTie8BA== Date: Thu, 24 Jul 2014 15:42:58 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B210123@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/qi37CDF3rh1PK4eb1vRZdZPp9KQ Subject: [Insipid] Log me requirements X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:43:21 -0000 (As WG cochair) We are seeing whether the logme requirements document is ready for WGLC http://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ And specifically the -01 version. Could the members of the WG take a look through, in particular with regard = to does it address all the issues that need to be addressed, and is therefo= re complete. Please respond by Friday August 15th with any comments. Regards Keith= From nobody Thu Jul 24 08:46:44 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523F51A0240 for ; Thu, 24 Jul 2014 08:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udMaM4DVJb_0 for ; Thu, 24 Jul 2014 08:46:41 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3131A0199 for ; Thu, 24 Jul 2014 08:46:40 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6OFkXJj004719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jul 2014 10:46:35 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6OFkXKH009670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 17:46:33 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 24 Jul 2014 17:46:33 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: Adoption as WG item of draft-dawes-insipid-logme-marking Thread-Index: Ac+nVnBjTBR2aHKsScKwzHUxcfqivg== Date: Thu, 24 Jul 2014 15:46:32 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/7tzEP5mgGsN2wjHkLtZ3lXUELcc Subject: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:46:43 -0000 (as WG cochair) We have a draft solutions document for the logme marking in: http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt No other documents have been identified to fulfil this work. This is a call to adopt this text (or parts of it if necessary) as text for= the WG item. Please respond by August 15th as to whether the text is acceptable to adopt= and work on as WG text, or not.=20 If you consider only part of the text should be adopted, then please say so= , and be specific as to what text is acceptable and what is not. Regards Keith= From nobody Thu Jul 24 08:50:49 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4341A03D0 for ; Thu, 24 Jul 2014 08:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtqkSzA8uOXT for ; Thu, 24 Jul 2014 08:50:47 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB4F1A0393 for ; Thu, 24 Jul 2014 08:50:44 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta15.westchester.pa.mail.comcast.net with comcast id WF2z1o0051ZXKqc5FFqkNB; Thu, 24 Jul 2014 15:50:44 +0000 Received: from dhcp-90b7.meeting.ietf.org ([31.133.144.183]) by omta21.westchester.pa.mail.comcast.net with comcast id WFob1o00P3xdsjB3hFodPY; Thu, 24 Jul 2014 15:48:42 +0000 Message-ID: <53D12AD3.7040505@alum.mit.edu> Date: Thu, 24 Jul 2014 11:48:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: insipid@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B210123@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B210123@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406217044; bh=OyN2659hYuhGv97iwud+QUu86pEW1vq9yD784S2luT4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JQufGG6a7RFHEOF9/4QQ/TcscBWEeYXLZKbcqJiLFVMZVSfPVrpLhbsle455EeSCI VVFQ09bmnQbwoyUGSYjNi78sBvlBPq4zzOEcPe0UBUHTJJhICcCUO+WX+ZYOJ3Zdpi fPjer5Ml9+pvYepxoAl0NMyyzf8FI7QR1KKbQCnxSIF84K09/V4w8oak0/C05rHOLA 8QpV7+NU+kr5Rqcw7+102eBHZFGcSXi0MFQBFvqQpdpySusZp+YUab6XkNO0DYtLcd XQGs4cdDhP573QwNfPWFQgXlukEpTTOWMB5sO5Uej1XSg5XRtd8gh6SM9REkrtLKWD P5uMgfECz4APw== Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/zlBwcz3umq10J2ZAGmin_HGiI9o Subject: Re: [Insipid] Log me requirements X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:50:48 -0000 My concerns have been resolved. Thanks, Paul On 7/24/14 11:42 AM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > We are seeing whether the logme requirements document is ready for WGLC > > http://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ > > And specifically the -01 version. > > Could the members of the WG take a look through, in particular with regard to does it address all the issues that need to be addressed, and is therefore complete. > > Please respond by Friday August 15th with any comments. > > Regards > > Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From nobody Thu Jul 24 09:47:27 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BF41A0495 for ; Thu, 24 Jul 2014 09:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIjMIcxSFSrG for ; Thu, 24 Jul 2014 09:47:25 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8220B1A04B1 for ; Thu, 24 Jul 2014 09:47:17 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 59831d35.2b68bb431940.5681452.00-2486.15867237.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 24 Jul 2014 16:47:17 +0000 (UTC) X-MXL-Hash: 53d138953815b21f-e1ca56bc6926df14856a04fa35a185552b4ce23c Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e8831d35.0.5681397.00-1966.15867065.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 24 Jul 2014 16:47:11 +0000 (UTC) X-MXL-Hash: 53d1388f57a3ed5d-13ed8d9301ebe9f31d72f4a8142deb0f81b6e588 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 s6OGlAxN024470; Thu, 24 Jul 2014 12:47:10 -0400 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 s6OGl1Jr024337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 12:47:03 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 24 Jul 2014 16:46:45 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.32]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 12:46:44 -0400 From: "DOLLY, MARTIN C" To: "DRAGE, Keith (Keith)" Thread-Topic: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking Thread-Index: AQHPp17Z3ANDtrtslk+c0hJv3QXAYA== Date: Thu, 24 Jul 2014 16:46:44 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=YYkKEXtf c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=NX4N2fcf7xoA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=gxZvrgisAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=rI6WAxTM_Ldn2VBlF0oA:9 a=CjuIK1q_8ugA:10 a=qM39cor] X-AnalysisOut: [4HRgA:10 a=Hz7IrDYlS0cA:10 a=3FZX-ydVlcEA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/7R0AibJQRif3gNqU2yMlr_DmNDA Cc: "insipid@ietf.org" Subject: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:47:26 -0000 I support this as a WG item Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards =20 AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com > On Jul 24, 2014, at 11:46 AM, "DRAGE, Keith (Keith)" wrote: >=20 > (as WG cochair) >=20 > We have a draft solutions document for the logme marking in: >=20 > http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt >=20 > No other documents have been identified to fulfil this work. >=20 > This is a call to adopt this text (or parts of it if necessary) as text f= or the WG item. >=20 > Please respond by August 15th as to whether the text is acceptable to ado= pt and work on as WG text, or not.=20 >=20 > If you consider only part of the text should be adopted, then please say = so, and be specific as to what text is acceptable and what is not. >=20 > Regards >=20 > Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Thu Jul 24 09:49:54 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326261A0460 for ; Thu, 24 Jul 2014 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsopQjfaFHsg for ; Thu, 24 Jul 2014 09:49:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586621A0564 for ; Thu, 24 Jul 2014 09:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=560; q=dns/txt; s=iport; t=1406220582; x=1407430182; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=USj+e5QuqVSbs1JwtsR404tFyHQbKC/ok4lKYf5sQJ0=; b=PmzW2Tw/9DdiNM2JOo229h/dAEyoVxmIF/EJenhA/d56OUSLGzBl/wCx /lfeIgW302eSTFL7ErAyoaAk6RF2qtCEEY24HOljey7v8DpNQPMSBOaIs GqDA7gyxkkrdFoxgucEwTp2jY10GjyG6fy30JVoOAZRmVJM401TVd1nJH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4HAJM40VOtJV2Y/2dsb2JhbABYAYMNUlgDyTaHRYEOFneECjo/EgE+QicEDiCIJw2/fhePS4M1gRgFmzaBUpJzg0iCMQ X-IronPort-AV: E=Sophos;i="5.01,725,1400025600"; d="scan'208";a="63731563" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 24 Jul 2014 16:49:41 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6OGnfUP024988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 16:49:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 11:49:41 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "insipid@ietf.org" Thread-Topic: Reviews for INSIPID Session-ID solution draft Thread-Index: AQHPp19C6/xeqyJWK0SvlVEb6jwnAQ== Date: Thu, 24 Jul 2014 16:49:40 +0000 Message-ID: <5AF0100A-3D47-468D-BD89-0C905E7AE118@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.126] Content-Type: text/plain; charset="us-ascii" Content-ID: <08BE7389E13FB5428853A16BE18B7031@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/tlDwWgR4bTp8vOTGh6w0KJQSG0U Cc: "insipid-chairs@tools.ietf.org" Subject: [Insipid] Reviews for INSIPID Session-ID solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:49:50 -0000 Hi -=20 The chairs met and had a WG sync while here in Toronto. Conversations with = the draft authors clearly indicate that we are getting very close to WGLC = for the Session-ID draft (http://tools.ietf.org/html/draft-ietf-insipid-ses= sion-id). The chairs feel it would be helpful if we were to get additional= reviews prior to WGLC. We have proactively reached out specifically to som= e obvious review candidates but we would welcome and appreciate partial or = complete reviews from anyone in the WG. Cheers, Gonzalo (as co-chair)= From nobody Thu Jul 24 09:50:41 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C461A063E for ; Thu, 24 Jul 2014 09:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqDx5SROg9SK for ; Thu, 24 Jul 2014 09:50:39 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2DB1A04B0 for ; Thu, 24 Jul 2014 09:50:21 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so2504831lbd.36 for ; Thu, 24 Jul 2014 09:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lmEXtmg/Kxoc1bPNXUYr2jyJbVLmhfsAk+zEe5ElLM8=; b=esi0m/BfcjsZZ/2k5adO42Ul3CLGsQehu6UQVmGJa48mQbj0duD0AbE0hiduBBnFbh jDICN9+GKhZdtUKv7cqaKT10kyc0H5vM5wlBqS3ElZSafxJpIa54TuH3lsuNSQAYBneZ bQC76sUZmbTg7UN/nO61ZtDiiFQAI/1GVCHnxOEOBMbxEMV3Gz/p+JfxancZY6QRoqAa Pp8rhJoHqZeQBjkM3VyB+oZilhPteKGvnaoca3BYiBvpkYdU2l7BvPXMwh56YR6k9rS/ VmREonzwDVRycZ40Ieb6vbYTNdhK/C8tFxcLy0ZxrGiWUGsEk9lpr9oP0tmmjUBmCD8s Xsiw== MIME-Version: 1.0 X-Received: by 10.112.128.232 with SMTP id nr8mr10298586lbb.58.1406220620345; Thu, 24 Jul 2014 09:50:20 -0700 (PDT) Received: by 10.114.75.194 with HTTP; Thu, 24 Jul 2014 09:50:20 -0700 (PDT) In-Reply-To: References: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 24 Jul 2014 18:50:20 +0200 Message-ID: From: Laura Liess To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=047d7b343d2c8d36a504fef3404d Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/oK_AKqQ2VysQMwMAXpjRHvj-5RI Cc: "DRAGE, Keith \(Keith\)" , "insipid@ietf.org" Subject: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:50:40 -0000 --047d7b343d2c8d36a504fef3404d Content-Type: text/plain; charset=ISO-8859-1 +1 Laura 2014-07-24 18:46 GMT+02:00 DOLLY, MARTIN C : > I support this as a WG item > > Martin Dolly > Lead Member of Technical Staff > Core Network & Gov't/Regulatory Standards > AT&T Standards and Industry Alliances > +1-609-903-3360 > md3135@att.com > > > On Jul 24, 2014, at 11:46 AM, "DRAGE, Keith (Keith)" < > keith.drage@alcatel-lucent.com> wrote: > > > > (as WG cochair) > > > > We have a draft solutions document for the logme marking in: > > > > http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt > > > > No other documents have been identified to fulfil this work. > > > > This is a call to adopt this text (or parts of it if necessary) as text > for the WG item. > > > > Please respond by August 15th as to whether the text is acceptable to > adopt and work on as WG text, or not. > > > > If you consider only part of the text should be adopted, then please say > so, and be specific as to what text is acceptable and what is not. > > > > Regards > > > > Keith > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > --047d7b343d2c8d36a504fef3404d Content-Type: text/html; charset=ISO-8859-1
+1

Laura


2014-07-24 18:46 GMT+02:00 DOLLY, MARTIN C <md3135@att.com>:
I support this as a WG item

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards
AT&T Standards and Industry Alliances
+1-609-903-3360
md3135@att.com

> On Jul 24, 2014, at 11:46 AM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> wrote:
>
> (as WG cochair)
>
> We have a draft solutions document for the logme marking in:
>
> http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt
>
> No other documents have been identified to fulfil this work.
>
> This is a call to adopt this text (or parts of it if necessary) as text for the WG item.
>
> Please respond by August 15th as to whether the text is acceptable to adopt and work on as WG text, or not.
>
> If you consider only part of the text should be adopted, then please say so, and be specific as to what text is acceptable and what is not.
>
> Regards
>
> Keith
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid

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

--047d7b343d2c8d36a504fef3404d-- From nobody Thu Jul 24 10:26:40 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A341A0146 for ; Thu, 24 Jul 2014 10:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpImWV_Yu1bJ for ; Thu, 24 Jul 2014 10:26:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C77E1A0B10 for ; Thu, 24 Jul 2014 10:25:46 -0700 (PDT) X-AuditID: c1b4fb30-f79da6d000006b80-e6-53d14198ef16 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 82.BF.27520.89141D35; Thu, 24 Jul 2014 19:25:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 19:25:44 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: Adoption as WG item of draft-dawes-insipid-logme-marking Thread-Index: Ac+nVnBjTBR2aHKsScKwzHUxcfqivgADdZCw Date: Thu, 24 Jul 2014 17:25:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3D2863@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje5Mx4vBBttWsVjMv/+MyeJp41lG ByaP1md7WT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxaf5b5oJGjorHf+4yNTAeZOti5OSQEDCR uHS/kxnCFpO4cG89UJyLQ0jgKKPEkaNX2CGcRYwSe68tA8pwcLAJWEh0/9MGaRARSJFYNGMO I0hYWMBV4soaVhBTRMBN4kq3LkSFkcTiWedYQWwWAVWJbVNXgNm8Ar4Sy5ZPZwSxhQSiJF4t vgF2DqdAtMSkgzfBahiBzvl+ag0TiM0sIC5x68l8JogzBSSW7DkPdbKoxMvH/1ghbCWJRbc/ Q9XrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpxUm66 kZFealFmcnFxfp5eXmrJJkZgjBzc8ttgB+PL546HGAU4GJV4eB/uPx8sxJpYVlyZe4hRmoNF SZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYDbb0pMXemr4h02RC2OOar995Cnzc ejx8HsSZ3WU04QrVXeN3WHlWuYBpos37SBm/7wZpqqV/p/4OOBH1aNeEenkTz4Snapq7yn53 vNuYZWmy9PvJvjWi+euWxVzgu+IW8WX5eTmBt2bP/r6uZajbI+d0X6N1XWP9iX1xRg0da45b rpmWeEdaiaU4I9FQi7moOBEAFoj17XICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/YKe9qN03Wu-kfSU1x_D3D6YDHks Subject: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:26:39 -0000 Hi, I support the adoption. Regards, Christer -----Original Message----- From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of DRAGE, Keith (= Keith) Sent: 24 July 2014 18:47 To: insipid@ietf.org Subject: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking (as WG cochair) We have a draft solutions document for the logme marking in: http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt No other documents have been identified to fulfil this work. This is a call to adopt this text (or parts of it if necessary) as text for= the WG item. Please respond by August 15th as to whether the text is acceptable to adopt= and work on as WG text, or not.=20 If you consider only part of the text should be adopted, then please say so= , and be specific as to what text is acceptable and what is not. Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From nobody Thu Jul 24 10:53:18 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B249F1A019C for ; Thu, 24 Jul 2014 10:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbLAEMBQ-Bwy for ; Thu, 24 Jul 2014 10:53:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5431ABB23 for ; Thu, 24 Jul 2014 10:52:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-0a-53d147e8254f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.FC.04090.8E741D35; Thu, 24 Jul 2014 19:52:40 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.189]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 19:52:40 +0200 From: Atle Monrad To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: Adoption as WG item of draft-dawes-insipid-logme-marking Thread-Index: Ac+nVnBjTBR2aHKsScKwzHUxcfqivgAEWyhw Date: Thu, 24 Jul 2014 17:52:39 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C1686FCA5@ESESSMB203.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje4L94vBBp0nTS3m33/GZPG08Syj A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYPPsOe8FKzoqT92eyNTCeZu9i5OSQEDCR +Pr7CyuELSZx4d56ti5GLg4hgaOMElMOvWeHcJYwSqxbuQ6sik1AR+LczztgtohAisSiGXMY uxg5OIQFXCWurGEFMUUE3CSudOtCVBhJ9J1/DLaLRUBVovv/f0YQm1fAV2L7z/8sILaQQJTE q8U32EBsToFoiUkHb4KNYRSQlZjbxAsSZhYQl7j1ZD4TxJkCEkv2nGeGsEUlXj7+B3W+kkTj kiesEPU6Egt2f2KDsLUlli18zQyxVlDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFpc nJtuZKSXWpSZXFycn6eXl1qyiREYIwe3/LbawXjwueMhRgEORiUe3gf7zwcLsSaWFVfmHmKU 5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGjf1Jam1HBLY3pnCbZ1dO1Cs9 8TbPJ+KL2WERjrAPNk02HEVFaedZU1ZOb1Lpu/rEZX1FjtC2C7pvHzy792fhDzHuvmkt4rGf 902+f92B89GuO72KAVJtt4Pk9jteucjP0mBrkBf5ScSMXUzC4NaHmF/S7e9/7jdOrT1Xyf7O oeWcrpzXp0glluKMREMt5qLiRADbCvvAcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/twZ3q3wLu_tP_9fboG9KvAp2IEE Subject: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:53:12 -0000 I support adopting the draft as a WG-item Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of DRAGE, Keith (= Keith) Sent: 24. juli 2014 17:47 To: insipid@ietf.org Subject: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking (as WG cochair) We have a draft solutions document for the logme marking in: http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt No other documents have been identified to fulfil this work. This is a call to adopt this text (or parts of it if necessary) as text for= the WG item. Please respond by August 15th as to whether the text is acceptable to adopt= and work on as WG text, or not.=20 If you consider only part of the text should be adopted, then please say so= , and be specific as to what text is acceptable and what is not. Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From nobody Thu Jul 24 11:11:22 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1D1A01F9 for ; Thu, 24 Jul 2014 11:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvhavGxHUKXI for ; Thu, 24 Jul 2014 11:11:15 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD091A01F2 for ; Thu, 24 Jul 2014 11:11:10 -0700 (PDT) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 24 Jul 2014 14:11:08 -0400 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 24 Jul 2014 14:11:07 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 14:11:07 -0400 From: Andrew Allen To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: Adoption as WG item of draft-dawes-insipid-logme-marking Thread-Index: Ac+nVnBjTBR2aHKsScKwzHUxcfqivgAFB5PQ Date: Thu, 24 Jul 2014 18:11:06 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/is7c40SRMrZBduLA49URfeKM1BA Subject: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:11:17 -0000 I support adoption of this draft as a WG item -----Original Message----- From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of DRAGE, Keith (= Keith) Sent: Thursday, July 24, 2014 11:47 AM To: insipid@ietf.org Subject: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking (as WG cochair) We have a draft solutions document for the logme marking in: http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt No other documents have been identified to fulfil this work. This is a call to adopt this text (or parts of it if necessary) as text for= the WG item. Please respond by August 15th as to whether the text is acceptable to adopt= and work on as WG text, or not.=20 If you consider only part of the text should be adopted, then please say so= , and be specific as to what text is acceptable and what is not. Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From nobody Thu Jul 24 13:00:45 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EA91A037D for ; Thu, 24 Jul 2014 13:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSMNq9tMiAr5 for ; Thu, 24 Jul 2014 13:00:43 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id D80841A0643 for ; Thu, 24 Jul 2014 13:00:42 -0700 (PDT) Received: from userPC (unknown [122.167.76.199]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id ECA69639580; Thu, 24 Jul 2014 20:00:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1406232044; bh=cN2SjDDnYlWSs4HNaW87gwZgGOXsxUt1L9mKxL/gXpk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=QZdbJ9zZkp8mKB+yIAh7QKmH4JlhsSfe0VA7F+P0ITKmW5Uezs5qdvMFFpPb1X4/l G5gthhJ4RPxxtPcg8eGhiBe+cn+vENjsC8YKbsvpo1CJWvWS8oQOCUtHFQgfjHcD+T rvewA7GIKNfuvk+GW8edT9O8BANvT+SZGzDnIzwA= From: "Parthasarathi R" To: "'Laura Liess'" , "'DOLLY, MARTIN C'" References: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Date: Fri, 25 Jul 2014 01:30:28 +0530 Message-ID: <00bd01cfa779$ef3cbbd0$cdb63370$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01CFA7A8.08F4F7D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+nX2l0X2PQg6DKTBehorg3+zMjmAAGmpog Content-Language: en-us X-CTCH-RefID: str=0001.0A020206.53D165E9.02AA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.134 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/QkukvWKOvwifMeoKwinF9UhfpWI Cc: "'DRAGE, Keith \(Keith\)'" , insipid@ietf.org Subject: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:00:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BE_01CFA7A8.08F4F7D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 Partha From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Laura Liess Sent: Thursday, July 24, 2014 10:20 PM To: DOLLY, MARTIN C Cc: DRAGE, Keith (Keith); insipid@ietf.org Subject: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking +1 Laura 2014-07-24 18:46 GMT+02:00 DOLLY, MARTIN C : I support this as a WG item Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com > On Jul 24, 2014, at 11:46 AM, "DRAGE, Keith (Keith)" wrote: > > (as WG cochair) > > We have a draft solutions document for the logme marking in: > > http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt > > No other documents have been identified to fulfil this work. > > This is a call to adopt this text (or parts of it if necessary) as text for the WG item. > > Please respond by August 15th as to whether the text is acceptable to adopt and work on as WG text, or not. > > If you consider only part of the text should be adopted, then please say so, and be specific as to what text is acceptable and what is not. > > Regards > > Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid ------=_NextPart_000_00BE_01CFA7A8.08F4F7D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Partha

 

From:= insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Laura Liess
Sent: Thursday, July 24, 2014 10:20 PM
To: DOLLY, MARTIN C
Cc: DRAGE, Keith (Keith); insipid@ietf.org
Subject: Re: [Insipid] Adoption as WG item of = draft-dawes-insipid-logme-marking

 

+1

Laura

 

2014-07-24 18:46 GMT+02:00 DOLLY, MARTIN C <md3135@att.com>:

I support this as a WG item

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards
AT&T Standards and Industry Alliances
+1-609-903-3360
md3135@att.com


> On Jul 24, 2014, at 11:46 AM, "DRAGE, Keith (Keith)" = <keith.drage@alcatel-lucent= .com> wrote:
>
> (as WG cochair)
>
> We have a draft solutions document for the logme marking in:
>
> http://www.ietf.org/id/draft-dawes-insipid-logme-markin= g-00.txt
>
> No other documents have been identified to fulfil this work.
>
> This is a call to adopt this text (or parts of it if necessary) as = text for the WG item.
>
> Please respond by August 15th as to whether the text is acceptable = to adopt and work on as WG text, or not.
>
> If you consider only part of the text should be adopted, then = please say so, and be specific as to what text is acceptable and what is not.
>
> Regards
>
> Keith
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid

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

 

------=_NextPart_000_00BE_01CFA7A8.08F4F7D0-- From nobody Thu Jul 24 13:11:30 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20D1A0AD3 for ; Thu, 24 Jul 2014 13:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N6dQMiWlkOk for ; Thu, 24 Jul 2014 13:11:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF7F1A0880 for ; Thu, 24 Jul 2014 13:11:26 -0700 (PDT) X-AuditID: c1b4fb25-f79da6d000004ad3-07-53d1686c843e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 08.FF.19155.C6861D35; Thu, 24 Jul 2014 22:11:25 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.189]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 22:11:24 +0200 From: Atle Monrad To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: Log me requirements Thread-Index: Ac+nVfCw8MYIhTSWRjmcIJtMTie8BAAJT0qg Date: Thu, 24 Jul 2014 20:11:23 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C1686FEC2@ESESSMB203.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B210123@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B210123@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvjW5uxsVgg8sb2C3m33/GZPG08Syj A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpoPDmJpeAdR8XZR6INjPPYuxg5OCQETCSO fnfrYuQEMsUkLtxbz9bFyMUhJHCUUWLO26fsIAkhgSWMEh9b8kFsNgEdiXM/77CC2CICKRKL ZsxhBLGFBRQk7pzYDBVXlOg70sYEYRtJbFp+mQXEZhFQlbj1cidYPa+Ar8TquW+g5kdJ9F2d ClbDKRAtMf/5KbDbGAVkJeY28YKEmQXEJW49mc8EcaeAxJI955khbFGJl4//sULYShKNS56w QtTrSCzY/YkNwtaWWLbwNTPEWkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpxUm66 kbFealFmcnFxfp5eXmrJJkZghBzc8lt1B+PlN46HGAU4GJV4eB/sPx8sxJpYVlyZe4hRmoNF SZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYg97dLhVUvq3978iPRl8TTV6er41b dy688/+FY0mgkmS/gWLRC49ls65y/5vBGGznwr/aInnn6qs+yjrNDqWR6x4IPnsv2pcu7sCo KrI26vMnb56I1Oft/W9W3tfvvcTy90CRabqxX8zXSTMebJuULLvoQnhR2/NNd1Y/17HzdTjc /J1Zcb+/EktxRqKhFnNRcSIA3KtMMXECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/HGQ5p1ficpdEuk5PONfBZNBhCis Subject: Re: [Insipid] Log me requirements X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:11:29 -0000 Keith / all As part of progressing this topic that is of interest to 3GPP: No objections - hopefully the draft can be brought forward to WGLC as soon = as possible. /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of DRAGE, Keith (= Keith) Sent: 24. juli 2014 17:43 To: insipid@ietf.org Subject: [Insipid] Log me requirements (As WG cochair) We are seeing whether the logme requirements document is ready for WGLC http://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ And specifically the -01 version. Could the members of the WG take a look through, in particular with regard = to does it address all the issues that need to be addressed, and is therefo= re complete. Please respond by Friday August 15th with any comments. Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From nobody Fri Jul 25 02:16:07 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AAA1A00D8 for ; Fri, 25 Jul 2014 02:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnMOq9hcKLyQ for ; Fri, 25 Jul 2014 02:16:02 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A04C1A004B for ; Fri, 25 Jul 2014 02:16:02 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 25 Jul 2014 11:16:00 +0200 X-IronPort-AV: E=Sophos;i="5.01,729,1400018400"; d="scan'208";a="503508111" Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 25 Jul 2014 11:16:00 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by he110890 ([10.134.92.131]) with mapi; Fri, 25 Jul 2014 11:16:00 +0200 From: To: , , Date: Fri, 25 Jul 2014 11:15:59 +0200 Thread-Topic: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking Thread-Index: Ac+nVnBjTBR2aHKsScKwzHUxcfqivgAEWyhwACBI2wA= Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E281876FF5@HE113667.emea1.cds.t-internal.com> References: <949EF20990823C4C85C18D59AA11AD8B210141@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7D2F7D7ADBA812449F25F4A69922881C1686FCA5@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C1686FCA5@ESESSMB203.ericsson.se> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/9qq4ww7EWlXE7I8ZkUtny0vDmwY Subject: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:16:05 -0000 +1 Roland -----Urspr=FCngliche Nachricht----- Von: insipid [mailto:insipid-bounces@ietf.org] Im Auftrag von Atle Monrad Gesendet: Donnerstag, 24. Juli 2014 19:53 An: DRAGE, Keith (Keith); insipid@ietf.org Betreff: Re: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-mar= king I support adopting the draft as a WG-item Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation Ericss= on -----Original Message----- From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of DRAGE, Keith (= Keith) Sent: 24. juli 2014 17:47 To: insipid@ietf.org Subject: [Insipid] Adoption as WG item of draft-dawes-insipid-logme-marking (as WG cochair) We have a draft solutions document for the logme marking in: http://www.ietf.org/id/draft-dawes-insipid-logme-marking-00.txt No other documents have been identified to fulfil this work. This is a call to adopt this text (or parts of it if necessary) as text for= the WG item. Please respond by August 15th as to whether the text is acceptable to adopt= and work on as WG text, or not.=20 If you consider only part of the text should be adopted, then please say so= , and be specific as to what text is acceptable and what is not. Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From nobody Mon Jul 28 07:01:25 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9619A1A0452 for ; Mon, 28 Jul 2014 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z2SahOZbNLF for ; Mon, 28 Jul 2014 07:01:10 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F5F1B284C for ; Mon, 28 Jul 2014 07:00:32 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail41.telekom.de with ESMTP; 28 Jul 2014 16:00:26 +0200 X-IronPort-AV: E=Sophos;i="5.01,749,1400018400"; d="scan'208";a="505332071" Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 28 Jul 2014 16:00:18 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 28 Jul 2014 16:00:18 +0200 From: To: , Date: Mon, 28 Jul 2014 16:00:14 +0200 Thread-Topic: Reviews for INSIPID Session-ID solution draft Thread-Index: AQHPp19C6/xeqyJWK0SvlVEb6jwnAZu0+hwQ Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E2818E1C6B@HE113667.emea1.cds.t-internal.com> References: <5AF0100A-3D47-468D-BD89-0C905E7AE118@cisco.com> In-Reply-To: <5AF0100A-3D47-468D-BD89-0C905E7AE118@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/Cim5Y282vmcX-ecHSdaz6gqt0bY Cc: insipid-chairs@tools.ietf.org Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:01:23 -0000 Hi Gonzalo, I did a review of the draft till section 9.1 Here are my comments: Section 2 Text: The terms "Session Identifier" and "Session ID" refer to the value of the identifier, whereas "Session-ID" refers to the header used to convey the identifier. For me it is not really clear what th3e difference between "Session Identif= ier", "Session ID" and "Session-ID" is. It is really hard to read the whole text in mind of this description. Someb= ody who is not aware of the difference will struggle a little bit. I would propose to replace all "Session ID" with "Session Identifier".=20 Section 4.1 I'm missing some more description in the start of section 4 that a local an= d remote UUID exists. Old: 4.1. Constructing the Session Identifier The Session Identifier comprises two UUIDs [RFC4122], with each UUID representing one of the endpoints participating in the session. Proposal: 4.1. Constructing the Session Identifier RFC4412 describes the construction of the Universally Unique Identifier (= UUID). The Session Identifier comprises two UUIDs [RFC4122], with each UUID representing one of the endpoints (local UUID and remote UUID) participa= ting in the session. Section 4.1 uuid_t This text: ... When generating a version 5 UUID, endpoints or intermediaries MUST utilize the following "name space ID" (see Section 4.3 of [RFC4122]): uuid_t NameSpace_SessionID =3D { /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ 0xa58587da, 0xc93d, 0x11e2, 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 } ... Is/was hard to understand what is here meant by. So if I understand correct= ly this is the specific name space definition for our "Session ID". Thus th= is is used to calculate our Session-ID/UUID local/remote. So I would propose to change the following text: New proposal: When generating a version 5 UUID, endpoints or intermediaries MUST Follow the procedures described in Section 4.3 of [RFC4122]. The followi= ng "name space ID" MUST be taken for the calculation of the UUID. /* Name string is a Session ID */ uuid_t NameSpace_SessionID =3D { /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ 0xa58587da, 0xc93d, 0x11e2, 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 } Section 4.2 first Paragraph: ... ABNF: Section 5 (1st comment) This draft defines the header "session-id" (ABNF: session-id =3D "Sessio= n-ID" HCOLON local-uuid) while I-D.kaplan-insipid-session-id defines the he= ader "Session-ID" (ABNF Session-ID =3D "Session-ID" HCOLON sess-id*( SEMI= generic-param )). Seen from syntax there is no difference with regard to the value both are = 32 bytes (32(DIGIT / %x61-66) ;32 chars of [0-9a-f]) Was this done by purpose or does this not care? ABNF: Section 5 (2nd comment) The definition sess-uuid =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f= ] is shown, but there is no real hint that this value is at least the built= UUID regarding RFC4412. I think we should spent some words of clarificatio= n. Section 6: Reading this text is a little bit hard to distinguish the UAC/UAS behavior.= I think it would be worth to spend a little bit more words to describe the= UAC/UAS behavior in addition. Like what happens in the Initial request see= n from UAC and first response from UAS. Section 7 3rd paragraph: Text: If an intermediary receives a SIP message without a Session-ID header value, the intermediary MAY assign a "local-uuid" value to represent the sending endpoint and insert that value into all signaling messages on behalf of the sending endpoint. If the intermediary is aware of a "remote" value that identifies the receiving UA, it MUST insert that value if also inserting the "local-uuid" value. Perhaps a note would be valuable what such intermediary (e.g. Network borde= r) could be. e.g. Note: Such an intermediary could be an entry point interconnecting to a net= work belonging to another domain or service provider which is not supportin= g the Session ID. Would it be also worth to mention the Interworking behavior between PSTN/IS= DN and SIP? =20 Section 9. /9.1 Would it be worth to show one example Request INVITE and on response. I know it is redundant text but people like to see an example to show how i= t looks like. e.G. INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=3Dz9hG4bKnashds10 From: Alice ;tag=3D1234567 To: Bob Call-Id: 123456mcmxcix@1.2.3.4 Session-ID: ab30317f1a784dc48ff824d0d3715d86; remote=3D00000000000000000000000000000000 CSeq: 1 INVITE Contact: SIP/2.0 200 OK Via: SIP/2.0/UDP b2bua.atlanta.com ;branch=3Dz9hG4bK77ef4c2312983.1;received=3D192.0.2.2 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=3Dz9hG4bKnashds10 To: Bob tag=3Da6c85cf From: Alice ;tag=3D1234567 Call-Id: 123456mcmxcix@1.2.3.4 Session-ID: ab30317f1a784dc48ff824d0d3715d86; remote=3D47755a9de7794ba387653f2099600ef2 CSeq: 1 INVITE Contact: So that are my comments till 9.1.=20 Editorial Page 8 last paragraph responseand --> response and=20 Page 15 1st Paragraph and following is "passcode" correct or should it be "= pass code" ? Page 25 last Paragraph "The authors would like to than" --> "The authors wo= uld like to thank" Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: insipid [mailto:insipid-bounces@ietf.org] Im Auftrag von Gonzalo Salgu= eiro (gsalguei) Gesendet: Donnerstag, 24. Juli 2014 18:50 An: insipid@ietf.org Cc: insipid-chairs@tools.ietf.org Betreff: [Insipid] Reviews for INSIPID Session-ID solution draft Hi -=20 The chairs met and had a WG sync while here in Toronto. Conversations with = the draft authors clearly indicate that we are getting very close to WGLC = for the Session-ID draft (http://tools.ietf.org/html/draft-ietf-insipid-ses= sion-id). The chairs feel it would be helpful if we were to get additional= reviews prior to WGLC. We have proactively reached out specifically to som= e obvious review candidates but we would welcome and appreciate partial or = complete reviews from anyone in the WG. Cheers, Gonzalo (as co-chair) _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From nobody Mon Jul 28 11:02:29 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BC91A0A91 for ; Mon, 28 Jul 2014 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VsE1XyFhx2w for ; Mon, 28 Jul 2014 11:02:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3B81A02DD for ; Mon, 28 Jul 2014 11:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7439; q=dns/txt; s=iport; t=1406570498; x=1407780098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eiVtdEAFhwGMfdnTxUoDsbkiBGOiRL3iuYEurdJOA4Y=; b=F64VLktJvdPeA4HWUa+F/nAGftQwZSjSdqEGct0BHY0rAbwZ7mwm7uwA 4nOjEa1+YhndJTillTKNtpyEP4Yu+Ge5fA5b0KkdCAjZznFpfHOuDbphO MVXVBLoWMyi9W7qiuIvuumPkgXFUNqdGPDIDDuvGLgrF0fGbnhVORzeJy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIoAIOP1lOtJV2c/2dsb2JhbABZAYMNUlcEsHabCgqGclMBgREWd4QDAQEBAwEBAQEkRwsFCwIBCBUqBycLFBECBA4FG4gfAgYNvhsXjxkNJgeDL4EbBYo3kRWBUpJ6g0lsAYFE X-IronPort-AV: E=Sophos;i="5.01,750,1400025600"; d="scan'208";a="343400872" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2014 18:01:36 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6SI1a2J009669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 18:01:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 13:01:35 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "R.Jesske@telekom.de" Thread-Topic: Reviews for INSIPID Session-ID solution draft Thread-Index: AQHPp19C6/xeqyJWK0SvlVEb6jwnAZu0+hwQgAEm1QA= Date: Mon, 28 Jul 2014 18:01:35 +0000 Message-ID: References: <5AF0100A-3D47-468D-BD89-0C905E7AE118@cisco.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E2818E1C6B@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E2818E1C6B@HE113667.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.53] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <25B589A956ACDC46A3C47F27A2BE363C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/yUYW7UzK5fIGKtO2N_l-rmimrjE Cc: "insipid@ietf.org" , "insipid-chairs@tools.ietf.org" Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 18:02:26 -0000 Truly appreciate the feedback, Roland. =20 I don't want to push my luck, but if you get a chance to finish reviewing t= he remainder of the document that would be very helpful. ;-) Cheers, Gonzalo On Jul 28, 2014, at 10:00 AM, R.Jesske@telekom.de wrote: > Hi Gonzalo, > I did a review of the draft till section 9.1 > Here are my comments: >=20 > Section 2 >=20 > Text: > The terms "Session Identifier" and "Session ID" refer to the value of > the identifier, whereas "Session-ID" refers to the header used to > convey the identifier. >=20 > For me it is not really clear what th3e difference between "Session Ident= ifier", "Session ID" and "Session-ID" is. > It is really hard to read the whole text in mind of this description. Som= ebody who is not aware of the difference will struggle a little bit. > I would propose to replace all "Session ID" with "Session Identifier".=20 >=20 >=20 > Section 4.1 >=20 > I'm missing some more description in the start of section 4 that a local = and remote UUID exists. >=20 > Old: >=20 > 4.1. Constructing the Session Identifier >=20 > The Session Identifier comprises two UUIDs [RFC4122], with each UUID > representing one of the endpoints participating in the session. >=20 > Proposal: >=20 > 4.1. Constructing the Session Identifier >=20 > RFC4412 describes the construction of the Universally Unique Identifier = (UUID). > The Session Identifier comprises two UUIDs [RFC4122], with each UUID > representing one of the endpoints (local UUID and remote UUID) particip= ating in the session. >=20 > Section 4.1 uuid_t >=20 > This text: > ... >=20 > When generating a version 5 UUID, endpoints or intermediaries MUST > utilize the following "name space ID" (see Section 4.3 of [RFC4122]): >=20 > uuid_t NameSpace_SessionID =3D { > /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ > 0xa58587da, > 0xc93d, > 0x11e2, > 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 > } >=20 > ... >=20 > Is/was hard to understand what is here meant by. So if I understand corre= ctly this is the specific name space definition for our "Session ID". Thus = this is used to calculate our Session-ID/UUID local/remote. >=20 > So I would propose to change the following text: >=20 > New proposal: > When generating a version 5 UUID, endpoints or intermediaries MUST > Follow the procedures described in Section 4.3 of [RFC4122]. The follow= ing "name space ID" MUST be taken for the calculation of the UUID. >=20 > /* Name string is a Session ID */ > uuid_t NameSpace_SessionID =3D { > /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ > 0xa58587da, > 0xc93d, > 0x11e2, > 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 > } >=20 >=20 >=20 > Section 4.2 first Paragraph: > ... >=20 >=20 > ABNF: Section 5 (1st comment) > This draft defines the header "session-id" (ABNF: session-id =3D "Sess= ion-ID" HCOLON local-uuid) while I-D.kaplan-insipid-session-id defines the = header "Session-ID" (ABNF Session-ID =3D "Session-ID" HCOLON sess-id*( SE= MI generic-param )). > Seen from syntax there is no difference with regard to the value both ar= e 32 bytes (32(DIGIT / %x61-66) ;32 chars of [0-9a-f]) > Was this done by purpose or does this not care? >=20 >=20 > ABNF: Section 5 (2nd comment) > The definition sess-uuid =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a= -f] is shown, but there is no real hint that this value is at least the bui= lt UUID regarding RFC4412. I think we should spent some words of clarificat= ion. >=20 >=20 > Section 6: >=20 > Reading this text is a little bit hard to distinguish the UAC/UAS behavio= r. I think it would be worth to spend a little bit more words to describe t= he UAC/UAS behavior in addition. Like what happens in the Initial request s= een from UAC and first response from UAS. >=20 > Section 7 3rd paragraph: >=20 > Text: > If an intermediary receives a SIP message without a Session-ID header > value, the intermediary MAY assign a "local-uuid" value to represent > the sending endpoint and insert that value into all signaling > messages on behalf of the sending endpoint. If the intermediary is > aware of a "remote" value that identifies the receiving UA, it MUST > insert that value if also inserting the "local-uuid" value. >=20 > Perhaps a note would be valuable what such intermediary (e.g. Network bor= der) could be. > e.g. > Note: Such an intermediary could be an entry point interconnecting to a n= etwork belonging to another domain or service provider which is not support= ing the Session ID. >=20 > Would it be also worth to mention the Interworking behavior between PSTN/= ISDN and SIP? =20 >=20 > Section 9. /9.1 >=20 > Would it be worth to show one example Request INVITE and on response. > I know it is redundant text but people like to see an example to show how= it looks like. >=20 > e.G. >=20 > INVITE sip:bob@example.com SIP/2.0 > Via: SIP/2.0/UDP 192.0.2.1:5060;branch=3Dz9hG4bKnashds10 > From: Alice ;tag=3D1234567 > To: Bob > Call-Id: 123456mcmxcix@1.2.3.4 > Session-ID: ab30317f1a784dc48ff824d0d3715d86; > remote=3D00000000000000000000000000000000 > CSeq: 1 INVITE > Contact: >=20 > SIP/2.0 200 OK > Via: SIP/2.0/UDP b2bua.atlanta.com > ;branch=3Dz9hG4bK77ef4c2312983.1;received=3D192.0.2.2 > Via: SIP/2.0/UDP 192.0.2.1:5060;branch=3Dz9hG4bKnashds10 > To: Bob tag=3Da6c85cf > From: Alice ;tag=3D1234567 > Call-Id: 123456mcmxcix@1.2.3.4 > Session-ID: ab30317f1a784dc48ff824d0d3715d86; > remote=3D47755a9de7794ba387653f2099600ef2 > CSeq: 1 INVITE > Contact: >=20 > So that are my comments till 9.1.=20 >=20 > Editorial > Page 8 last paragraph responseand --> response and=20 > Page 15 1st Paragraph and following is "passcode" correct or should it be= "pass code" ? > Page 25 last Paragraph "The authors would like to than" --> "The authors = would like to thank" >=20 >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: insipid [mailto:insipid-bounces@ietf.org] Im Auftrag von Gonzalo Sal= gueiro (gsalguei) > Gesendet: Donnerstag, 24. Juli 2014 18:50 > An: insipid@ietf.org > Cc: insipid-chairs@tools.ietf.org > Betreff: [Insipid] Reviews for INSIPID Session-ID solution draft >=20 > Hi -=20 >=20 > The chairs met and had a WG sync while here in Toronto. Conversations wit= h the draft authors clearly indicate that we are getting very close to WGLC= for the Session-ID draft (http://tools.ietf.org/html/draft-ietf-insipid-s= ession-id). The chairs feel it would be helpful if we were to get addition= al reviews prior to WGLC. We have proactively reached out specifically to s= ome obvious review candidates but we would welcome and appreciate partial o= r complete reviews from anyone in the WG. >=20 >=20 > Cheers, >=20 > Gonzalo > (as co-chair) > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Wed Jul 30 08:31:18 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA011A0180 for ; Wed, 30 Jul 2014 08:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNIgnQ7x-t19 for ; Wed, 30 Jul 2014 08:31:07 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF651A00CF for ; Wed, 30 Jul 2014 08:29:23 -0700 (PDT) Received: from [85.158.139.163:25233] by server-6.bemta-5.messagelabs.com id 8F/6D-06284-25F09D35; Wed, 30 Jul 2014 15:29:22 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-2.tower-188.messagelabs.com!1406734161!7948309!1 X-Originating-IP: [195.232.224.76] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21988 invoked from network); 30 Jul 2014 15:29:22 -0000 Received: from mailout07.vodafone.com (HELO mailout07.vodafone.com) (195.232.224.76) by server-2.tower-188.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2014 15:29:22 -0000 Received: from mailint07.vodafone.com (localhost [127.0.0.1]) by mailout07.vodafone.com (Postfix) with ESMTP id BE15B2204C7 for ; Wed, 30 Jul 2014 17:29:21 +0200 (CEST) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint07.vodafone.com (Postfix) with ESMTPS id B01C6220171; Wed, 30 Jul 2014 17:29:21 +0200 (CEST) Received: from AVOEXC03W.internal.vodafone.com (145.230.15.132) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 30 Jul 2014 17:29:21 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.97]) by AVOEXC03W.internal.vodafone.com ([145.230.15.132]) with mapi id 14.03.0181.006; Wed, 30 Jul 2014 17:29:20 +0200 From: "Dawes, Peter, Vodafone Group" To: James Polk , "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] Posted draft-ietf-insipid-session-id-06 Thread-Index: AQHPVHBkVDpTJjne3kOMcj8OZdFvc5t4kbWwgADI+s+ALRqIoA== Date: Wed, 30 Jul 2014 15:29:20 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D998720672E@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99870C73C3@VOEXM31W.internal.vodafone.com> <201406192102.s5JL2Oi7010523@alln-core-3.cisco.com> In-Reply-To: <201406192102.s5JL2Oi7010523@alln-core-3.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/nCZH9O_xnhjKy_Y6dubfcPiUwC8 Cc: "insipid-chairs@tools.ietf.org" Subject: Re: [Insipid] Posted draft-ietf-insipid-session-id-06 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:31:13 -0000 SGVsbG8gSmFtZXMsDQpUaGFua3MgZm9yIGxvb2tpbmcgaW50byBteSBjb21tZW50cyBhbmQgcXVl c3Rpb25zLCBtYW55IG9mIHdoaWNoIGFyZSBhbnN3ZXJlZC4gQmVsb3cgSSBoYXZlIHRyaWVkIHRv IGV4cGxhaW4gbW9yZSBjbGVhcmx5IGEgZmV3IHRoYXQgSSB0aGluayBzdGlsbCBuZWVkIHRvIGJl IGludmVzdGlnYXRlZC4gSSB3aWxsIGFsc28gcmV2aWV3IHRoZSBzaWduYWxsaW5nIGZsb3dzIGFu ZCBzZW5kIGNvbW1lbnRzIGlmIGFueS4uLg0KDQpCZXN0IHJlZ2FyZHMsDQpQZXRlcg0KDQpbY29t bWVudCMwMSBsaW5lcyAxNjcgLSAxNjldDQpUaGUgZHJhZnQgdXNlcyB0d28gdGVybXMgdG8gcmVm ZXIgdG8gdGhlIHZhbHVlIG9mIHRoZSBTZXNzaW9uLUlEIGhlYWRlciBmaWVsZCwgbmFtZWx5ICJT ZXNzaW9uIElkZW50aWZpZXIiIGFuZCAiU2Vzc2lvbi1JRCIsIGUuZy4gZnJvbSB0aGUgVGFibGUg b2YgQ29udGVudHM6DQoNCiAgIDMuIFNlc3Npb24gSWRlbnRpZmllciBSZXF1aXJlbWVudHMgYW5k IFVzZSBDYXNlcy4uLi4uLi4uLi4uLi4uLi4uLjQNCiAgIDQuIENvbnN0cnVjdGluZyBhbmQgQ29u dmV5aW5nIHRoZSBTZXNzaW9uIElkZW50aWZpZXIuLi4uLi4uLi4uLi4uLjQNCiAgICAgIDQuMS4g Q29uc3RydWN0aW5nIHRoZSBTZXNzaW9uIElkZW50aWZpZXIuLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjQNCiAgICAgIDQuMi4gQ29udmV5aW5nIHRoZSBTZXNzaW9uIElkZW50aWZpZXIuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjQNCiAgIDUuIFRyYW5zbWl0dGluZyB0aGUgU2Vzc2lvbiBJZGVudGlm aWVyIGluIFNJUC4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCi4NCiAgIDkuIFZhcmlvdXMgQ2FsbCBG bG93IE9wZXJhdGlvbnMgVXRpbGl6aW5nIHRoZSBTZXNzaW9uIElELi4uLi4uLi4uMTANCiAgICAg IDkuMS4gQmFzaWMgU2Vzc2lvbiBJRCBDb25zdHJ1Y3Rpb24gd2l0aCAyIFVVSURzLi4uLi4uLi4u Li4uLi4uMTANCi4NCiAgICAgIDkuNi4gQ2FzY2FkaW5nIENvbmZlcmVuY2UgQnJpZGdlIFN1cHBv cnQgZm9yIHRoZSBTZXNzaW9uIElELi4uMTcNCiAgICAgICAgIDkuNi4xLiBDYWxsaW5nIGludG8g Q2FzY2FkZWQgQ29uZmVyZW5jZSBCcmlkZ2UgZm9yIHRoZSBTZXNzaW9uDQogICAgICAgICBJRC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4 DQouDQogICAgICA5LjguIFNlc3Npb24gSUQgSGFuZGxpbmcgaW4gMTAwIFRyeWluZyBTSVAgUmVz cG9uc2UgYW5kIENBTkNFTA0KICAgICAgUmVxdWVzdC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMA0KICAgICAgICAgOS44LjEuIFNlc3Npb24g SUQgSGFuZGxpbmcgaW4gYSAxMDAgVHJ5aW5nIFNJUCBSZXNwb25zZS4uLi4yMA0KICAgICAgICAg OS44LjIuIFNlc3Npb24gSUQgaW4gYSBDQU5DRUwgU0lQIFJlcXVlc3QuLi4uLi4uLi4uLi4uLi4u Li4yMQ0KICAgICAgOS45LiBTZXNzaW9uIElEIGluIGFuIG91dC1vZi1kaWFsb2cgUkVGRVIgVHJh bnNhY3Rpb24uLi4uLi4uLi4yMg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIGNsZWFyZXIgdG8gcmVw bGFjZSBhbGwgIlNlc3Npb24gSUQiIHdpdGggIlNlc3Npb24gSWRlbnRpZmllciINCg0KW2NvbW1l bnQjMDIgbGluZXMgNDQ0XQ0KWW91IGNsYXJpZmllZCB0aGF0IHRoZSB0ZXh0DQo+SWYgYW4gaW50 ZXJtZWRpYXJ5IHJlY2VpdmVzIGEgU0lQIG1lc3NhZ2Ugd2l0aG91dCBhIFNlc3Npb24tSUQgaGVh ZGVyDQo+ICAgIHZhbHVlICwgDQptZWFucyB0aGF0IHRoZSBTZXNzaW9uLUlEIGhlYWRlciBmaWVs ZCBpcyAibm9uLWV4aXN0ZW50Ig0KDQpJIHRoaW5rIGJldHRlciB3b3JkaW5nIHdvdWxkIGJlICIg SWYgYW4gaW50ZXJtZWRpYXJ5IHJlY2VpdmVzIGEgU0lQIG1lc3NhZ2Ugd2l0aG91dCBhIFNlc3Np b24tSUQgaGVhZGVyIGZpZWxkLCAiDQoNCltjb21tZW50IzAzIGxpbmVzIDQ0NC00NDldDQpGb3Ig dGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggaW4gY2xhdXNlIDcgUHJvY2Vzc2luZyBieSBJbnRlcm1l ZGlhcmllcw0KDQpJZiBhbiBpbnRlcm1lZGlhcnkgcmVjZWl2ZXMgYSBTSVAgbWVzc2FnZSB3aXRo b3V0IGEgU2Vzc2lvbi1JRCBoZWFkZXINCiAgIHZhbHVlLCB0aGUgaW50ZXJtZWRpYXJ5IE1BWSBh c3NpZ24gYSAibG9jYWwtdXVpZCIgdmFsdWUgdG8gcmVwcmVzZW50DQogICB0aGUgc2VuZGluZyBl bmRwb2ludCBhbmQgaW5zZXJ0IHRoYXQgdmFsdWUgaW50byBhbGwgc2lnbmFsaW5nDQogICBtZXNz YWdlcyBvbiBiZWhhbGYgb2YgdGhlIHNlbmRpbmcgZW5kcG9pbnQuICBJZiB0aGUgaW50ZXJtZWRp YXJ5IGlzDQogICBhd2FyZSBvZiBhICJyZW1vdGUiIHZhbHVlIHRoYXQgaWRlbnRpZmllcyB0aGUg cmVjZWl2aW5nIFVBLCBpdCBNVVNUDQogICBpbnNlcnQgdGhhdCB2YWx1ZSBpZiBhbHNvIGluc2Vy dGluZyB0aGUgImxvY2FsLXV1aWQiIHZhbHVlLg0KDQpJZiBBbGljZSBzZW5kcyBhIGRpYWxvZy1j cmVhdGluZyBTSVAgbWVzc2FnZSB0aGF0IGRvZXMgbm90IGhhdmUgYSBTZXNzaW9uLUlEIGhlYWRl ciBmaWVsZCwgdGhlbiBhbiBpbnRlcm1lZGlhcnkgTUFZIGFzc2lnbiBhbmQgaW5zZXJ0IGEgImxv Y2FsLXV1aWQiIHZhbHVlLiBXaGF0IGlmIEFsaWNlIHNlbmRzIGFub3RoZXIgZGlhbG9nLWNyZWF0 aW5nIFNJUCBtZXNzYWdlIChpLmUuIHNpbXVsdGFuZW91cyBkaWFsb2dzKT8gVGhlIHRleHQgc2F5 cyB0aGF0IHRoZSBpbnRlcm1lZGlhcnkgaW5zZXJ0cyB0aGUgImxvY2FsLXV1aWQiIHZhbHVlIGlu IGFsbCBzaWduYWxsaW5nIG1lc3NhZ2VzIHdpdGggbm8gbGltaXRzIG9uIHRpbWUgb3IgZGlhbG9n LiBJIGd1ZXNzIGl0IHNob3VsZCBzYXkgImFsbCBzaWduYWxpbmcgbWVzc2FnZXMgaW4gdGhhdCBk aWFsb2ciLg0KDQpbY29tbWVudCMwNCBnZW5lcmFsXQ0KSW4gbWFueSBwbGFjZXMgdGhlIGRyYWZ0 IGRvZXMgbm90IGNsZWFybHkgYW5kIGNvbnNpc3RlbnRseSBpZGVudGlmeSB0aGUgaGVhZGVyIGZp ZWxkIHZhbHVlICh3aGljaCBpcyBhbHNvIHRoZSBsb2NhbC11dWlkKSwgdGhlICJyZW1vdGUiIHBh cmFtZXRlciBuYW1lLCBhbmQgdGhlIHZhbHVlIHRoYXQgdGhlICJyZW1vdGUiIHBhcmFtZXRlciBj b250YWlucy4gTG9va2luZyBhdCB0aGUgZXhhbXBsZToNCg0KU2Vzc2lvbi1JRDogYWIzMDMxN2Yx YTc4NGRjNDhmZjgyNGQwZDM3MTVkODY7DQogICAgICAgICAgICAgICAgIHJlbW90ZT00Nzc1NWE5 ZGU3Nzk0YmEzODc2NTNmMjA5OTYwMGVmMg0KDQpJIHRoaW5rIHRoZSB0ZXJtaW5vbG9neSBzaG91 bGQgYmUgYXMgZm9sbG93czoNCmhlYWRlciBmaWVsZCBpcyBTZXNzaW9uLUlEOiBhYjMwMzE3ZjFh Nzg0ZGM0OGZmODI0ZDBkMzcxNWQ4NjsgcmVtb3RlPTQ3NzU1YTlkZTc3OTRiYTM4NzY1M2YyMDk5 NjAwZWYyDQpmaWVsZCBuYW1lIGlzIFNlc3Npb24tSUQNCmZpZWxkIHZhbHVlIGlzIGFiMzAzMTdm MWE3ODRkYzQ4ZmY4MjRkMGQzNzE1ZDg2DQpsb2NhbC11dWlkIGlzIGFiMzAzMTdmMWE3ODRkYzQ4 ZmY4MjRkMGQzNzE1ZDg2DQoicmVtb3RlIiBwYXJhbWV0ZXIgY29udGFpbnMgNDc3NTVhOWRlNzc5 NGJhMzg3NjUzZjIwOTk2MDBlZjINCg0Kd2hpY2ggd291bGQgbWF0Y2ggdGhlIGRlc2NyaXB0aW9u IGluIFJGQzMyNjEgIk1hbnkgZXhpc3RpbmcgaGVhZGVyIGZpZWxkcyB3aWxsIGFkaGVyZSB0byB0 aGUgZ2VuZXJhbCBmb3JtIG9mIGEgdmFsdWUgZm9sbG93ZWQgYnkgYSBzZW1pLWNvbG9uIHNlcGFy YXRlZCBzZXF1ZW5jZSBvZiBwYXJhbWV0ZXItbmFtZSwgcGFyYW1ldGVyLXZhbHVlIHBhaXJzDQoJ CQkJCQkJZmllbGQtbmFtZTogZmllbGQtdmFsdWUgICooO3BhcmFtZXRlci1uYW1lPXBhcmFtZXRl ci12YWx1ZSkiDQoNCmNoYW5nZXMgYXJlIGFzIGZvbGxvd3MNCg0KW2NvbW1lbnQjMDUgbGluZXMg MzY5IC0gMzc1XQ0KY2hhbmdlOg0KVG8gY29tcGx5IHdpdGggdGhpcyBzcGVjaWZpY2F0aW9uLCBu b24taW50ZXJtZWRpYXJ5IFNJUCBVQXMgTVVTVA0KICAgaW5jbHVkZSBhIFNlc3Npb24tSUQgaGVh ZGVyIGluIGFsbCBTSVAgbWVzc2FnZXMgdHJhbnNtaXR0ZWQgYXMNCiAgIGEgcGFydCBvZiBhIGNv bW11bmljYXRpb24gc2Vzc2lvbi4gIFRoZSBVVUlEIG9mIHRoZSB0cmFuc21pdHRlciBvZg0KICAg dGhlIG1lc3NhZ2UgTVVTVCBhcHBlYXIgaW4gdGhlICJsb2NhbC11dWlkIiBwb3J0aW9uIG9mIHRo ZSBTZXNzaW9uLUlEDQogICBoZWFkZXItdmFsdWUuICBUaGUgVVVJRCBvZiB0aGUgcGVlciBkZXZp Y2UsIGlmIGtub3duLCBNVVNUIGFwcGVhciBhcw0KICAgdGhlICJyZW1vdGUiIHBhcmFtZXRlciBm b2xsb3dpbmcgdGhlIHRyYW5zbWl0dGVyJ3MgVVVJRC4gIA0KDQp0bzoNClRvIGNvbXBseSB3aXRo IHRoaXMgc3BlY2lmaWNhdGlvbiwgbm9uLWludGVybWVkaWFyeSBTSVAgVUFzIE1VU1QNCiAgIGlu Y2x1ZGUgYSBTZXNzaW9uLUlEIGhlYWRlciBmaWVsZCBpbiBhbGwgU0lQIG1lc3NhZ2VzIHRyYW5z bWl0dGVkIGFzDQogICBhIHBhcnQgb2YgYSBjb21tdW5pY2F0aW9uIHNlc3Npb24uICBUaGUgVVVJ RCBvZiB0aGUgdHJhbnNtaXR0ZXIgb2YNCiAgIHRoZSBtZXNzYWdlIE1VU1QgYXBwZWFyIGFzIHRo ZSB2YWx1ZSAobG9jYWwtdXVpZCkgb2YgdGhlIFNlc3Npb24tSUQNCiAgIGhlYWRlciBmaWVsZC4g IFRoZSBVVUlEIG9mIHRoZSBwZWVyIGRldmljZSwgaWYga25vd24sIE1VU1QgYXBwZWFyIGluDQog ICB0aGUgInJlbW90ZSIgcGFyYW1ldGVyIGZvbGxvd2luZyB0aGUgdHJhbnNtaXR0ZXIncyBVVUlE LiAgDQoNCltjb21tZW50IzA2IGxpbmVzIDM5MC00MDNdDQpjaGFuZ2U6DQpBIG5vbi1pbnRlcm1l ZGlhcnkgVUEgdGhhdCByZWNlaXZlcyBhIFNlc3Npb24tSUQgaGVhZGVyIE1VU1QgdGFrZQ0KICAg bm90ZSBvZiB0aGUgZmlyc3QgVVVJRCB2YWx1ZSAoaS5lLiwgdGhlICJsb2NhbC11dWlkIikgdGhh dCBpdA0KICAgcmVjZWl2ZXMgaW4gdGhlIFNlc3Npb24tSUQgaGVhZGVyIGFuZCBhc3N1bWUgdGhh dCB0aGF0IGlzIHRoZSBVVUlEIG9mDQogICB0aGUgcGVlciBlbmRwb2ludCB3aXRoaW4gdGhhdCBj b21tdW5pY2F0aW9ucyBzZXNzaW9uLiAgVUFzIE1VU1QNCiAgIGluY2x1ZGUgdGhpcyByZWNlaXZl ZCBVVUlEIHZhbHVlIGFzIHRoZSAicmVtb3RlIiBwYXJhbWV0ZXIgd2hlbg0KICAgdHJhbnNtaXR0 aW5nIHN1YnNlcXVlbnQgbWVzc2FnZXMsIG1ha2luZyBzdXJlIG5vdCB0byBjaGFuZ2UgdGhpcyBV VUlEDQogICB2YWx1ZSBpbiB0aGUgcHJvY2VzcyBvZiBtb3ZpbmcgdGhlIHZhbHVlIGludGVybmFs bHkgZnJvbSB0aGUgImxvY2FsLQ0KICAgdXVpZCIgZmllbGQgdG8gdGhlICJyZW1vdGUtdXVpZCIg ZmllbGQuDQoNCiAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IG1lc3NhZ2VzIHJlY2VpdmVkIGJ5 IGEgVUEgbWlnaHQgY29udGFpbiBhDQogICAibG9jYWwtdXVpZCIgdmFsdWUgdGhhdCBkb2VzIG5v dCBtYXRjaCB3aGF0IHRoZSBVQSBleHBlY3RlZCB0aGUgZmFyDQogICBlbmQgVUEncyBVVUlEIHRv IGJlLiAgSXQgaXMgYWxzbyBwb3NzaWJsZSB0byBmb3IgdGhlIFVBIHRvIHJlY2VpdmUgYQ0KICAg InJlbW90ZS11dWlkIiB2YWx1ZSB0aGF0IGRvZXMgbm90IG1hdGNoIHRoZSBVQSdzIGFzc2lnbmVk IFVVSUQgZm9yDQogICB0aGUgc2Vzc2lvbi4NCg0KdG86DQpBIG5vbi1pbnRlcm1lZGlhcnkgVUEg dGhhdCByZWNlaXZlcyBhIFNlc3Npb24tSUQgaGVhZGVyIE1VU1QgdGFrZQ0KICAgbm90ZSBvZiB0 aGUgU2Vzc2lvbi1JRCBoZWFkZXIgZmllbGQgdmFsdWUgKGkuZS4sIHRoZSBsb2NhbC11dWlkKSAN CmFuZCBhc3N1bWUgdGhhdCB0aGF0IGlzIHRoZSBVVUlEIG9mDQogICB0aGUgcGVlciBlbmRwb2lu dCB3aXRoaW4gdGhhdCBjb21tdW5pY2F0aW9ucyBzZXNzaW9uLiAgVUFzIE1VU1QNCiAgIGluY2x1 ZGUgdGhpcyByZWNlaXZlZCBVVUlEIHZhbHVlIGluIHRoZSAicmVtb3RlIiBwYXJhbWV0ZXIgd2hl bg0KICAgdHJhbnNtaXR0aW5nIHN1YnNlcXVlbnQgbWVzc2FnZXMsIG1ha2luZyBzdXJlIG5vdCB0 byBjaGFuZ2UgdGhpcyBVVUlEDQogICB2YWx1ZSBpbiB0aGUgcHJvY2VzcyBvZiBtb3ZpbmcgdGhl IHZhbHVlIGludGVybmFsbHkgZnJvbSB0aGUgZmllbGQgdmFsdWUgdG8gdGhlICJyZW1vdGUgIiBw YXJhbWV0ZXIuDQoNCiAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IG1lc3NhZ2VzIHJlY2VpdmVk IGJ5IGEgVUEgbWlnaHQgY29udGFpbiBhDQp2YWx1ZSAobG9jYWwtdXVpZCkgIHRoYXQgZG9lcyBu b3QgbWF0Y2ggd2hhdCB0aGUgVUEgZXhwZWN0ZWQgdGhlIGZhcg0KICAgZW5kIFVBJ3MgVVVJRCB0 byBiZS4gIEl0IGlzIGFsc28gcG9zc2libGUgdG8gZm9yIHRoZSBVQSB0byByZWNlaXZlIGENCiAg ICJyZW1vdGUiIHBhcmFtZXRlciBjb250YWluaW5nIGEgdmFsdWUgdGhhdCBkb2VzIG5vdCBtYXRj aCB0aGUgVUEncyBhc3NpZ25lZCBVVUlEIGZvcg0KICAgdGhlIHNlc3Npb24uDQoNCltjb21tZW50 IzA3IGxpbmVzIDQyMi00MjcgXQ0KY2hhbmdlOg0KSXQgaXMgYWxzbyBpbXBvcnRhbnQgdG8gbm90 ZSB0aGF0IGlmIGFuIGludGVybWVkaWFyeSBpbiB0aGUgbmV0d29yaw0KICAgZm9ya3MgYSBzZXNz aW9uLCB0aGUgaW5pdGlhdGluZyBVQSBtYXkgcmVjZWl2ZSBtdWx0aXBsZSByZXNwb25zZXMNCiAg IGJhY2sgZnJvbSBkaWZmZXJlbnQgZW5kcG9pbnRzLCBlYWNoIG9mIHdoaWNoIGNvbnRhaW5zIGEg ZGlmZmVyZW50DQogICBVVUlEICgibG9jYWwtdXVpZCIpIHZhbHVlLiAgVUFzIE1VU1QgdGFrZSBj YXJlIHRvIGVuc3VyZSB0aGF0IHRoZQ0KICAgY29ycmVjdCBVVUlEIHZhbHVlIGlzIHJldHVybmVk IGluIHRoZSAicmVtb3RlIiBwYXJhbWV0ZXIgd2hlbg0KICAgaW50ZXJhY3Rpbmcgd2l0aCBlYWNo IGVuZHBvaW50Lg0KDQp0bzoNCkl0IGlzIGFsc28gaW1wb3J0YW50IHRvIG5vdGUgdGhhdCBpZiBh biBpbnRlcm1lZGlhcnkgaW4gdGhlIG5ldHdvcmsNCiAgIGZvcmtzIGEgc2Vzc2lvbiwgdGhlIGlu aXRpYXRpbmcgVUEgbWF5IHJlY2VpdmUgbXVsdGlwbGUgcmVzcG9uc2VzDQogICBiYWNrIGZyb20g ZGlmZmVyZW50IGVuZHBvaW50cywgZWFjaCBvZiB3aGljaCBjb250YWlucyBhIGRpZmZlcmVudA0K ICAgdmFsdWUgKGxvY2FsLXV1aWQpLiAgVUFzIE1VU1QgdGFrZSBjYXJlIHRvIGVuc3VyZSB0aGF0 IHRoZQ0KICAgY29ycmVjdCBVVUlEIHZhbHVlIGlzIHJldHVybmVkIGluIHRoZSAicmVtb3RlIiBw YXJhbWV0ZXIgd2hlbg0KICAgaW50ZXJhY3Rpbmcgd2l0aCBlYWNoIGVuZHBvaW50Lg0KDQpbY29t bWVudCMwOCBsaW5lcyA0NDQtNDQ5XQ0KY2hhbmdlOg0KSWYgYW4gaW50ZXJtZWRpYXJ5IHJlY2Vp dmVzIGEgU0lQIG1lc3NhZ2Ugd2l0aG91dCBhIFNlc3Npb24tSUQgaGVhZGVyLCB0aGUgaW50ZXJt ZWRpYXJ5IE1BWSBhc3NpZ24gYSAibG9jYWwtdXVpZCIgdmFsdWUgdG8gcmVwcmVzZW50DQogICB0 aGUgc2VuZGluZyBlbmRwb2ludCBhbmQgaW5zZXJ0IHRoYXQgdmFsdWUgaW50byBhbGwgc2lnbmFs aW5nDQogICBtZXNzYWdlcyBvbiBiZWhhbGYgb2YgdGhlIHNlbmRpbmcgZW5kcG9pbnQuICBJZiB0 aGUgaW50ZXJtZWRpYXJ5IGlzDQogICBhd2FyZSBvZiBhICJyZW1vdGUiIHZhbHVlIHRoYXQgaWRl bnRpZmllcyB0aGUgcmVjZWl2aW5nIFVBLCBpdCBNVVNUDQogICBpbnNlcnQgdGhhdCB2YWx1ZSBp ZiBhbHNvIGluc2VydGluZyB0aGUgImxvY2FsLXV1aWQiIHZhbHVlLg0KDQp0bzoNCklmIGFuIGlu dGVybWVkaWFyeSByZWNlaXZlcyBhIFNJUCBtZXNzYWdlIHdpdGhvdXQgYSBTZXNzaW9uLUlEIGhl YWRlcg0KICAgLCB0aGUgaW50ZXJtZWRpYXJ5IE1BWSBhc3NpZ24gYSBsb2NhbC11dWlkIHRvIHJl cHJlc2VudA0KICAgdGhlIHNlbmRpbmcgZW5kcG9pbnQgYW5kIGluc2VydCBhIFNlc3Npb24tSUQg aGVhZGVyIHdpdGggdGhlIGxvY2FsLXV1aWQgdmFsdWUgaW50byBhbGwgc2lnbmFsaW5nDQogICBt ZXNzYWdlcyBvbiBiZWhhbGYgb2YgdGhlIHNlbmRpbmcgZW5kcG9pbnQuICBJZiB0aGUgaW50ZXJt ZWRpYXJ5IGlzDQogICBhd2FyZSBvZiBhIHJlbW90ZS11dWlkIHRoYXQgaWRlbnRpZmllcyB0aGUg cmVjZWl2aW5nIFVBLCBpdCBNVVNUDQogICBpbnNlcnQgYSAicmVtb3RlIiBwYXJhbWV0ZXIgY29u dGFpbmluZyB0aGUgcmVtb3RlLXV1aWQgdmFsdWUgaWYgYWxzbyBpbnNlcnRpbmcgdGhlIGxvY2Fs LXV1aWQgdmFsdWUuDQoNCltjb21tZW50IzA5LCBsaW5lcyA0NjMtNDkzXQ0KY2hhbmdlOg0KV2hl biBpbnRlcm1lZGlhcmllcyB0cmFuc21pdHMgYSAxMDAgKFRyeWluZykgcHJvdmlzaW9uYWwgcmVz cG9uc2VhbmQNCiAgIHdoZW4gdGhlIFVVSUQgb2YgdGhlIGRlc3RpbmF0aW9uIFVBIGlzIHVua25v d24sIHRoZSBpbnRlcm1lZGlhcnkgTVVTVA0KICAgcGxhY2UgdGhlIG9uZSBrbm93biBVVUlEIGlu IHRoZSAicmVtb3RlLXV1aWQiIGZpZWxkIGFuZCBzZXQgdGhlDQogICAibG9jYWwtdXVpZCIgZmll bGQgdG8gdGhlIG51bGwgVVVJRCB2YWx1ZS4gIFdoZW4gYW4gaW50ZXJtZWRpYXJ5DQogICB0cmFu c21pdHMgYW55IG90aGVyIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGFuZCB3aGVuIHRoZSBVVUlEIG9m IHRoZQ0KICAgZGVzdGluYXRpb24gVUEgaXMgdW5rbm93biwgdGhlIGludGVybWVkaWFyeSBNVVNU IHBsYWNlIHRoZSBvbmUga25vd24NCiAgIFVVSUQgaW4gdGhlICJyZW1vdGUtdXVpZCIgZmllbGQg YW5kIE1BWSBzZXQgdGhlICJsb2NhbC11dWlkIiBmaWVsZCB0bw0KICAgYSBsb2NhbGx5IGNyZWF0 ZWQgVVVJRCB2YWx1ZSBvciB0aGUgbnVsbCBVVUlEIHZhbHVlLiAgSW4gYWxsIGNhc2VzDQogICB3 aGVuIHRoZSBpbnRlcm1lZGlhcnkga25vd3MgdGhlIFVVSUQgb2YgdGhlIGRlc3RpbmF0aW9uIFVB LCB0aGUNCiAgIGludGVybWVkaWFyeSBNVVNUIGluc2VydCB0aGUgVVVJRCBvZiB0aGUgZGVzdGlu YXRpb24gVUEgaW4gdGhlDQogICAibG9jYWwtdXVpZCIgZmllbGQgYW5kIGluc2VydCB0aGUgb3Jp Z2luYXRpbmcgVUEncyBVVUlEIGludG8gdGhlDQogICAicmVtb3RlLXV1aWQiIGZpZWxkIHdoZW4g c2VuZGluZyBhIHByb3Zpc2lvbmFsIHJlc3BvbnNlLg0KDQogICBBIENBTkNFTCByZXF1ZXN0IHNl bnQgYnkgYW4gaW50ZXJtZWRpYXJ5IHRoYXQgaGFzIG5vdCByZWNlaXZlZCBhIFVVSUQNCiAgIGZy b20gdGhlIGRlc3RpbmF0aW9uIFVBIE1VU1QgY29uc3RydWN0IGEgU2Vzc2lvbi1JRCBoZWFkZXIg dmFsdWUNCiAgIGV4YWN0bHkgbGlrZSB0aGUgSU5WSVRFIHRvIHRoYXQgVUEsIHdpdGggdGhlIGtu b3duICJsb2NhbC11dWlkIiB2YWx1ZQ0KICAgZm9yIHRoZSBpbml0aWF0aW5nIFVBIGFuZCB0aGUg bnVsbCBVVUlEIGFzIHRoZSAicmVtb3RlLXV1aWQiIHZhbHVlDQogICBmb3IgdGhlIGRlc3RpbmF0 aW9uIFVBLg0KDQogICBJZiBhIFNJUCBpbnRlcm1lZGlhcnkgaW5pdGlhdGVzIGEgZGlhbG9nIGJl dHdlZW4gdHdvIFVBcyBpbiBhIDNQQ0MNCiAgIHNjZW5hcmlvLCB0aGUgU0lQIHJlcXVlc3QgaW4g dGhlIGluaXRpYWwgSU5WSVRFIHdpbGwgaGF2ZSBhIG5vbi1udWxsDQogICAibG9jYWwtdXVpZCIg dmFsdWU7IGNhbGwgdGhpcyB0ZW1wb3JhcnkgVVVJRCBYLiAgVGhlIHJlcXVlc3Qgd2lsbA0KICAg c3RpbGwgaGF2ZSBhIG51bGwgInJlbW90ZS11dWlkIiB2YWx1ZTsgY2FsbCB0aGlzIHZhbHVlIE4u DQoNCnRvOg0KV2hlbiBpbnRlcm1lZGlhcmllcyB0cmFuc21pdHMgYSAxMDAgKFRyeWluZykgcHJv dmlzaW9uYWwgcmVzcG9uc2VhbmQNCiAgIHdoZW4gdGhlIFVVSUQgb2YgdGhlIGRlc3RpbmF0aW9u IFVBIGlzIHVua25vd24sIHRoZSBpbnRlcm1lZGlhcnkgTVVTVA0KICAgcGxhY2UgdGhlIG9uZSBr bm93biBVVUlEIGluIHRoZSAicmVtb3RlIiBwYXJhbWV0ZXIgYW5kIHNldCB0aGUNCiAgIFNlc3Np b24tSUQgZmllbGQgdmFsdWUgKGxvY2FsLXV1aWQpIHRvIHRoZSBudWxsIFVVSUQuICBXaGVuIGFu IGludGVybWVkaWFyeQ0KICAgdHJhbnNtaXRzIGFueSBvdGhlciBwcm92aXNpb25hbCByZXNwb25z ZSBhbmQgd2hlbiB0aGUgVVVJRCBvZiB0aGUNCiAgIGRlc3RpbmF0aW9uIFVBIGlzIHVua25vd24s IHRoZSBpbnRlcm1lZGlhcnkgTVVTVCBwbGFjZSB0aGUgb25lIGtub3duDQogICBVVUlEIGluIHRo ZSAicmVtb3RlIiBwYXJhbWV0ZXIgYW5kIE1BWSBzZXQgdGhlIFNlc3Npb24tSUQgaGVhZGVyIGZp ZWxkIHZhbHVlIChsb2NhbC11dWlkKSB0bw0KICAgYSBsb2NhbGx5IGNyZWF0ZWQgVVVJRCBvciB0 aGUgbnVsbCBVVUlELiAgSW4gYWxsIGNhc2VzDQogICB3aGVuIHRoZSBpbnRlcm1lZGlhcnkga25v d3MgdGhlIFVVSUQgb2YgdGhlIGRlc3RpbmF0aW9uIFVBLCB0aGUNCiAgIGludGVybWVkaWFyeSBN VVNUIHNldCB0aGUgVVVJRCBvZiB0aGUgZGVzdGluYXRpb24gVUEgYXMgdGhlDQogIFNlc3Npb24t SUQgaGVhZGVyIGZpZWxkIHZhbHVlIChsb2NhbC11dWlkKSBhbmQgaW5zZXJ0IHRoZSBvcmlnaW5h dGluZyBVQSdzIFVVSUQgaW50byB0aGUNCiAgICJyZW1vdGUgIiBwYXJhbWV0ZXIgd2hlbiBzZW5k aW5nIGEgcHJvdmlzaW9uYWwgcmVzcG9uc2UuDQoNCiAgIEEgQ0FOQ0VMIHJlcXVlc3Qgc2VudCBi eSBhbiBpbnRlcm1lZGlhcnkgdGhhdCBoYXMgbm90IHJlY2VpdmVkIGEgVVVJRA0KICAgZnJvbSB0 aGUgZGVzdGluYXRpb24gVUEgTVVTVCBjb25zdHJ1Y3QgYSBTZXNzaW9uLUlEIGhlYWRlciANCiAg IGV4YWN0bHkgbGlrZSB0aGUgSU5WSVRFIHRvIHRoYXQgVUEsIHdpdGggdGhlIGtub3duIGxvY2Fs LXV1aWQgDQogICBmb3IgdGhlIGluaXRpYXRpbmcgVUEgYXMgdGhlIFNlc3Npb24tSUQgaGVhZGVy IGZpZWxkIHZhbHVlIGFuZCB0aGUgbnVsbCBVVUlEIGluIHRoZSAicmVtb3RlIiBwYXJhbWV0ZXIN CiAgIGZvciB0aGUgZGVzdGluYXRpb24gVUEuDQoNCiAgIElmIGEgU0lQIGludGVybWVkaWFyeSBp bml0aWF0ZXMgYSBkaWFsb2cgYmV0d2VlbiB0d28gVUFzIGluIGEgM1BDQw0KICAgc2NlbmFyaW8s IHRoZSBTSVAgcmVxdWVzdCBpbiB0aGUgaW5pdGlhbCBJTlZJVEUgd2lsbCBoYXZlIGEgbm9uLW51 bGwNCiAgIHZhbHVlIChsb2NhbC11dWlkKTsgY2FsbCB0aGlzIHRlbXBvcmFyeSBVVUlEIFguICBU aGUgcmVxdWVzdCB3aWxsDQogICBzdGlsbCBoYXZlIGEgInJlbW90ZSAiIHBhcmFtZXRlciBjb250 YWluaW5nIHRoZSBudWxsbCBVVUlEOyBjYWxsIHRoaXMgdmFsdWUgTi4NCg0KW2NvbW1lbnQjMTBd DQpzaW1pbGFyIGNoYW5nZXMgZm9yIGxvY2FsLXV1aWQgYW5kICJyZW1vdGUiIHBhcmFtZXRlciBm cm9tIGNsYXVzZSA4IG9ud2FyZHMuDQoNCg0KW2NvbW1lbnQjMTFdDQpjaGFuZ2U6DQo5LjEuIEJh c2ljIFNlc3Npb24gSUQgQ29uc3RydWN0aW9uIHdpdGggMiBVVUlEcw0KDQogICAgICBTZXNzaW9u IElEDQogICAgICAgICAtLS0gICAgIEFsaWNlICAgICAgICAgICAgQjJCVUEgICAgICAgICAgICAg Qm9iICAgICAgICAgICAgQ2Fyb2wNCiAgICAgICAge0EsTn0gICAgICB8LS0tLUlOVklURS0tLS0t PnwgICAgICAgICAgICAgICAgfA0KICAgICAgICB7QSxOfSAgICAgIHwgICAgICAgICAgICAgICAg fC0tLS1JTlZJVEUtLS0tLT58DQogICAgICAgIHtCLEF9ICAgICAgfCAgICAgICAgICAgICAgICB8 PC0tLTIwMCBPSy0tLS0tLXwNCiAgICAgICAge0IsQX0gICAgICB8PC0tLTIwMCBPSy0tLS0tLXwg ICAgICAgICAgICAgICAgfA0KICAgICAgICB7QSxCfSAgICAgIHwtLS0tLS1BQ0stLS0tLS0+fCAg ICAgICAgICAgICAgICB8DQogICAgICAgIHtBLEJ9ICAgICAgfCAgICAgICAgICAgICAgICB8LS0t LS0tQUNLLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICB8PD09PT09PT09PT09PT09UlRQPT09 PT09PT09PT09PT0+fA0KDQogICAgICAgICAgICAgRmlndXJlIDEgLSBTZXNzaW9uIElEIENyZWF0 aW9uIHdoZW4gQWxpY2UgY2FsbHMgQm9iDQoNCiAgIEdlbmVyYWwgb3BlcmF0aW9uIG9mIHRoaXMg ZXhhbXBsZToNCg0KICAgICAgbyBVQS1BbGljZSBwb3B1bGF0ZXMgdGhlICJsb2NhbC11dWlkIiBw b3J0aW9uIG9mIHRoZSBTZXNzaW9uLUlEDQogICAgICAgIGhlYWRlci12YWx1ZS4NCg0KICAgICAg byBVQS1BbGljZSBzZW5kcyBpdHMgVVVJRCBpbiB0aGUgU0lQIElOVklURSwgYW5kIHBvcHVsYXRl cyB0aGUNCiAgICAgICAgInJlbW90ZSIgcGFyYW1ldGVyIHdpdGggYSBudWxsIHZhbHVlICgzMiB6 ZXJvcykuDQoNCnRvOg0KOS4xLiBCYXNpYyBTZXNzaW9uIElEIENvbnN0cnVjdGlvbiB3aXRoIDIg VVVJRHMNCg0KICAgICAgU2Vzc2lvbiBJRA0KICAgICAgICAgLS0tICAgICBBbGljZSAgICAgICAg ICAgIEIyQlVBICAgICAgICAgICAgIEJvYiAgICAgICAgICAgIENhcm9sDQogICAgICAgIHtBLE59 ICAgICAgfC0tLS1JTlZJVEUtLS0tLT58ICAgICAgICAgICAgICAgIHwNCiAgICAgICAge0EsTn0g ICAgICB8ICAgICAgICAgICAgICAgIHwtLS0tSU5WSVRFLS0tLS0+fA0KICAgICAgICB7QixBfSAg ICAgIHwgICAgICAgICAgICAgICAgfDwtLS0yMDAgT0stLS0tLS18DQogICAgICAgIHtCLEF9ICAg ICAgfDwtLS0yMDAgT0stLS0tLS18ICAgICAgICAgICAgICAgIHwNCiAgICAgICAge0EsQn0gICAg ICB8LS0tLS0tQUNLLS0tLS0tPnwgICAgICAgICAgICAgICAgfA0KICAgICAgICB7QSxCfSAgICAg IHwgICAgICAgICAgICAgICAgfC0tLS0tLUFDSy0tLS0tLT58DQogICAgICAgICAgICAgICAgICAg fDw9PT09PT09PT09PT09PVJUUD09PT09PT09PT09PT09PnwNCg0KICAgICAgICAgICAgIEZpZ3Vy ZSAxIC0gU2Vzc2lvbiBJRCBDcmVhdGlvbiB3aGVuIEFsaWNlIGNhbGxzIEJvYg0KDQogICBHZW5l cmFsIG9wZXJhdGlvbiBvZiB0aGlzIGV4YW1wbGU6DQoNCiAgICAgIG8gVUEtQWxpY2Ugc2VuZHMg aXRzIFVVSUQgaW4gdGhlIFNJUCBJTlZJVEUsIGFuZCBwb3B1bGF0ZXMgdGhlDQogICAgICAgICJy ZW1vdGUiIHBhcmFtZXRlciB3aXRoIGEgbnVsbCB2YWx1ZSAoMzIgemVyb3MpLg0KDQppLmUuIGNv bWJpbmUgdGhlIGZpcnN0IHR3byBidWxsZXRzIGludG8gb25lLg0KIA0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKYW1lcyBQb2xrIFttYWlsdG86am1wb2xrQGNpc2NvLmNv bV0gDQpTZW50OiAxOSBKdW5lIDIwMTQgMjI6MDINClRvOiBEYXdlcywgUGV0ZXIsIFZvZGFmb25l IEdyb3VwOyBQYXVsIEUuIEpvbmVzOyBpbnNpcGlkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lu c2lwaWRdIFBvc3RlZCBkcmFmdC1pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC0wNg0KDQpBdCAwNDow NSBBTSA2LzE5LzIwMTQsIERhd2VzLCBQZXRlciwgVm9kYWZvbmUgR3JvdXAgd3JvdGU6DQo+Q29u dGVudC1MYW5ndWFnZTogZW4tVVMNCj5Db250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2 ZTsNCj4gDQo+Ym91bmRhcnk9Il8wMDBfNEE0RjEzNkNCRDBFMEQ0NEFFMUVERTM2QzRDRDlEOTk4 NzBDNzNDM1ZPRVhNMzFXaW50ZXJuYV8iDQo+DQo+SGkgUGF1bCwNCj5JIGhhdmUgcmVhZCB0aHJv dWdoIHRoZSBsYXRlc3Qgc2Vzc2lvbi1pZCBzb2x1dGlvbnMgZHJhZnQgDQo+PGh0dHA6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1pbnNpcGlkLXNlc3Npb24taWQtMDYudHh0Pmh0dHA6Ly93 d3cNCj4uaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1pbnNpcGlkLXNlc3Npb24taWQtMDYudHh0DQo+ YW5kIEkgaGF2ZSB0aGUgY29tbWVudHMgYmVsb3csIG9yZ2FuaXplZCBieSB0aGUgbGluZSBudW1i ZXIgaW4gdGhlIA0KPmRyYWZ0LiBJIGhhdmVuw6LigqzihKJ0IHlldCBjaGVja2VkIHRoZSBkZXRh aWxzIG9mIGFsbCBvZiB0aGUgc2lnbmFsbGluZyANCj5zY2VuYXJpb3MgaW4gY2xhdXNlIDkgc28g SSBtaWdodCBoYXZlIHNvbWUgbW9yZSBjb21tZW50cyBsYXRlci4NCg0KUGV0ZXINCg0KVGhhbmtz IGZvciBkb2luZyB0aGlzIHJldmlldy4NCg0KQ29tbWVudHMgYXJlIGluLWxpbmUgd2l0aCB0aGUg cXVlc3Rpb25zL2NvbW1lbnRzIHlvdSBoYXZlLi4uDQoNCj4NCj5SZ2RzLA0KPlBldGVyDQo+DQo+ DQo+TGluZQ0KPkRyYWZ0IFRleHQNCj5Db21tZW50IG9yIFF1ZXN0aW9uDQo+bGluZSA5NQ0KPjku NS4gU2luZ2xlIEZvY3VzIENvbmZlcmVuY2luZyB1c2luZyBXZWJFeCAuLi4uLi4uLi4uLi4uLi4u Li4uLjE2IElzIGFuIA0KPmludGVybmV0IGRyYWZ0IGFsbG93ZWQgdG8gcmVmZXIgdG8gYSBjb21t ZXJjaWFsIHByb2R1Y3QsIGkuZS4gV2ViRXg/DQoNClRoaXMgaXMgb25seSBpbiB0aGUgZXhhbXBs ZXMgc2VjdGlvbiBvZiB0aGUgZG9jdW1lbnQuIEJlY2F1c2UgaXQgaXMgdXNlZCBzbyBwZXJ2YXNp dmVseSB0aHJvdWdob3V0IHRoZSBpbmR1c3RyeSwgYW5kIGhhcyBhIHN1YnN0YW50aWFsbHkgZGlm ZmVyZW50IG1vZGVsIHRvIG90aGVyIGNvbmZlcmVuY2luZyBzeXN0ZW1zIChpdCB1c2VzIGFub3Ro ZXIgcHJvdG9jb2wgLSB0aGUgc2VjdXJlIGZvcm0gb2YgSFRUUCksIHdlIHRob3VnaHQgaXQgd2lz ZSB0byBoYXZlIGluIHRoZSBkb2MgKGJ1dCBvbmx5IGluIHRoZSBleGFtcGxlIHRleHQpLg0KDQo+ bGluZXMgMTQ5IC0gMTUyDQo+VGhpcyBkcmFmdCBwcmVzZW50cyBhIG5ldyBpZGVudGlmaWVyLCBy ZWZlcnJlZCB0byBhcyB0aGUgU2Vzc2lvbiANCj5JZGVudGlmaWVyLCBvciAiU2Vzc2lvbiBJRCIs IGFuZCBhc3NvY2lhdGVkIHN5bnRheCBpbnRlbmRlZCB0byBvdmVyY29tZSANCj50aGUgaXNzdWVz IHRoYXQgZXhpc3Qgd2l0aCB0aGUgY3VycmVudGx5IGRlZmluZWQgY2FsbCBpZGVudGlmaWVycy4N Cj5JdCB3b3VsZCBoZWxwIHRvIGRlc2NyaWJlIHRoZSBzY29wZSBvZiB0aGlzIG5ldyBpZGVudGlm aWVyLCBlLmcuIFNJUCANCj5vbmx5LCBTSVAgYW5kIEguMzIzLCBvciBzb21ldGhpbmcgZWxzZS4N Cg0KcmVhZGluZyB0aGUgb3BlbmluZyBwYXJhZ3JhcGhzIG9mIHRoZSBJbnRybyBzZWN0aW9uIHNo b3VsZCBhbnN3ZXIgdGhpcyBmb3IgYW55b25lDQoNCj5saW5lcyAxNjkgLSAxNzENCj5UaGUgdGVy bXMgIlNlc3Npb24gSWRlbnRpZmllciIgYW5kICJTZXNzaW9uIElEIiANCj5yZWZlciB0byB0aGUg dmFsdWUgb2YgdGhlIGlkZW50aWZpZXIsIHdoZXJlYXMgIlNlc3Npb24tSUQiIHJlZmVycyB0byAN Cj50aGUgaGVhZGVyIHVzZWQgdG8gY29udmV5IHRoZSBpZGVudGlmaWVyLg0KPkl0IHdvdWxkIGJl IGNsZWFyZXIgdG8gcmVmZXIgdG8gdGhlIHZhbHVlIHVzaW5nIG9ubHkgIlNlc3Npb24gDQo+SWRl bnRpZmllciIgdGhyb3VnaG91dC4NCg0KU29tZXRpbWVzIHdlIG5lZWQgdG8gdGFsayBhYm91dCB0 aGUgdmFsdWUgIm9mIiANCnRoZSBoZWFkZXIsIGFuZCBvdGhlcnMgd2UgbmVlZCB0byB0YWxrIGFi b3V0IHRoZSBoZWFkZXIgaXRzZWxmLg0KDQo+bGluZSAxNzANCj4iU2Vzc2lvbi1JRCIgcmVmZXJz IHRvIHRoZSBoZWFkZXINCj5DaGFuZ2UgdG8gIlNlc3Npb24tSUQiIHJlZmVycyB0byB0aGUgU0lQ IGhlYWRlciBmaWVsZA0KDQpJJ20gbm90IHN1cmUgd2hhdCB5b3UgYXJlIGdldHRpbmcgYXQsIHRo aXMgaXMgYSBTSVAgZG9jIChJVFUncyBTRzE2IGp1c3QgaW50cm9kdWNlZCBpdHMgb3duIHZlcnNp b24gb2YgdGhlIFNlc3Npb24tSUQgaGVhZGVyICh1bmRlciBILjQ2MCkgdGhpcyB3ZWVrKS4NCg0K PmxpbmUgMTg3DQo+W0ktRC5pZXRmLWluc2lwaWQtc2Vzc2lvbi1pZC1yZXF0c10gLg0KPk5vdyBS RkM3MjA2DQoNCmluZGVlZA0KDQo+MTk2IC0gMTk3DQo+VGhlIHZlcnNpb24gbnVtYmVyIGluIHRo ZSBVVUlEIGluZGljYXRlcyB0aGUgbWFubmVyIGluIHdoaWNoIHRoZSBVVUlEIA0KPmlzIGdlbmVy YXRlZCwgSSBkaWQgbm90IHNlZSB2ZXJzaW9uIG51bWJlciBkZWZpbmVkIGluIHRoZSBkcmFmdA0K DQppdCdzIG9uZSBudW1iZXIgYWx3YXlzLCB2ZXJzaW9uIDUgLS0gYW5kIHRoZSBwcmVzZW50IGRv YyBkb2VzIHNheSB0aGF0Lg0KDQo+bGluZXMgMjAyIC0gMjExDQo+V2hlbiBnZW5lcmF0aW5nIGEg dmVyc2lvbiA1IFVVSUQsIGVuZHBvaW50cyBvciBpbnRlcm1lZGlhcmllcyBNVVNUDQo+ICAgIHV0 aWxpemUgdGhlIGZvbGxvd2luZyAibmFtZSBzcGFjZSBJRCIgKHNlZSBTZWN0aW9uIDQuMyBvZiBb UkZDNDEyMl0pOg0KPg0KPiAgICAgICAgdXVpZF90IE5hbWVTcGFjZV9TZXNzaW9uSUQgPSB7DQo+ ICAgICAgICAgICAgLyogYTU4NTg3ZGEtYzkzZC0xMWUyLWFlOTAtZjRlYTY3ODAxZTI5ICovDQo+ ICAgICAgICAgICAgMHhhNTg1ODdkYSwNCj4gICAgICAgICAgICAweGM5M2QsDQo+ICAgICAgICAg ICAgMHgxMWUyLA0KPiAgICAgICAgICAgIDB4YWUsIDB4OTAsIDB4ZjQsIDB4ZWEsIDB4NjcsIDB4 ODAsIDB4MWUsIDB4MjkNCj4gICAgICAgIH0NCj5UaGUgcHJvY2VkdXJlIGFuZCBzeW50YXggYmVp bmcgZGVzY3JpYmVkIGJ5IHRoZSBkcmFmdCBhcmUgbm90IGNsZWFyIHRvIG1lLg0KDQpsb29rIHRv ICJTZWN0aW9uIDQuMyBvZiBbUkZDNDEyMl0iIGZvciB0aGlzDQoNCj5saW5lcyAyMjUgLSAyMjgN Cj5Ob3RlIHRoYXQgaWYgYW4gaW50ZXJtZWRpYXJ5IGlzIHN0YXRlbGVzcyBhbmQgdGhlIGVuZHBv aW50IG9uIG9uZSBlbmQNCj4gICAgb2YgdGhlIGNhbGwgaXMgcmVwbGFjZWQgd2l0aCBhbm90aGVy IGVuZHBvaW50IGR1ZSB0byBzb21lIHNlcnZpY2UNCj4gICAgaW50ZXJhY3Rpb24sIHRoZSB2YWx1 ZXMgdXNlZCB0byBjcmVhdGUgdGhlIFVVSUQgbWlnaHQgY2hhbmdlICBhbmQsIGlmDQo+ICAgIHNv LCB0aGUgaW50ZXJtZWRpYXJ5IHdpbGwgY29tcHV0ZSBhIGRpZmZlcmVudCBVVUlELg0KPmEpIElm IGFuIGVuZHBvaW50IGlzIHJlcGxhY2VkIHRoZW4gSSB3b3VsZCBleHBlY3QgdGhlIFVVSUQgdG8g YWx3YXlzIA0KPmNoYW5nZSBidXQgdGhlIHRleHQgc2F5cyAibWlnaHQiDQo+YikgdGV4dCBzYXlz ICJ0aGUgdmFsdWVzIHVzZWQgdG8gY3JlYXRlIHRoZSBVVUlEIiBidXQgdGhlIGRyYWZ0IGRvZXMg DQo+bm90IGRlc2NyaWJlIGEgVVVJRCBjcmVhdGlvbiBhbGdvcml0aG0NCj5jKSB0ZXh0IHNheXMg dGhhdCBpbnRlcm1lZGlhcnkgaXMgc3RhdGVsZXNzIGJ1dCBhbHNvIHNheXMgdGhhdCB0aGUgDQo+ aW50ZXJtZWRpYXJ5IHdpbGwgY29tcHV0ZSAgYSBkaWZmZXJlbnQgVVVJRC4gU3VyZWx5IGEgc3Rh dGVsZXNzIA0KPmludGVybWVkaWFyeSBkb2VzIG5vdCBjb21wdXRlIGEgVVVJRA0KDQpobW0sIEkg aGF2ZSB0aGUgb25seSBtZW50aW9uIG9mIHRoZSB3b3JkICJzdGF0ZWxlc3MiIG9uIGxpbmUgMjE1 Li4uDQoNCmEpIHRoaXMgaXMgb25seSB1bmRlciB0aGUgY29uZGl0aW9uIG9mIHRoZSBpbnRlcm1l ZGlhcnkgYmVpbmcgc3RhdGVsZXNzLg0KYikgPyAsIHdlIHN0YXRlIHRoZSBVVUlEIHJlZmVyZW5j ZSBSRkMgZm9yIGNyZWF0aW5nIGl0IHNldmVyYWwgdGltZXMgaW4gdGhpcyBzZWN0aW9uIChSRkMg NDEyMiwgUzMpDQpjKSBub3QgInRoYXQiIGJ1dCAiaWYiIGFuIGludGVybWVkaWF0ZSBpcyBzdGF0 ZWxlc3MuDQoNCg0KPmxpbmUgMzI3DQo+bnVsbCAgICAgICAgICA9IDMyKCIwIikNCj5zaW5jZSAz MiB6ZXJvcyBpcyBhIHZhbGlkIFVVSUQsIGl0IG1pZ2h0IGJlIA0KPmJldHRlciB0byB1c2UgdGhl IHN0cmluZyAibnVsbCIgZm9yIHRoZSBOVUxMIHZhbHVlLg0KDQpJJ2xsIGNvbnN1bHQgd2l0aCBt eSBjby1lZGl0b3IgYW5kIHRoZSBXRw0KDQo+bGluZXMgNDUxIC0gNDU0DQo+SWYgYW4gaW50ZXJt ZWRpYXJ5IHJlY2VpdmVzIGEgU0lQIG1lc3NhZ2Ugd2l0aG91dCBhIFNlc3Npb24tSUQgaGVhZGVy DQo+ICAgIHZhbHVlICwgdGhlIGludGVybWVkaWFyeSBNQVkgYXNzaWduIGEgImxvY2FsLXV1aWQi IHZhbHVlIHRvIHJlcHJlc2VudA0KPiAgICB0aGUgc2VuZGluZyBlbmRwb2ludCBhbmQgaW5zZXJ0 IHRoYXQgdmFsdWUgaW50byBhbGwgc2lnbmFsaW5nDQo+ICAgIG1lc3NhZ2VzIG9uIGJlaGFsZiBv ZiB0aGUgc2VuZGluZyBlbmRwb2ludC4NCj5hKSBEb2VzIHRoZSBpbnRlcm1lZGlhcnkgcmVjZWl2 ZSBhbiBlbXB0eSANCj5TZXNzaW9uLUlEIGhlYWRlciBmaWVsZCwgb3IgYSBtZXNzYWdlIHdpdGgg bm8gU2Vzc2lvbi1JRCBoZWFkZXIgZmllbGQ/DQo+YikgbWVzc2FnZXMgY2FuIGJlIG9yaWdpbmF0 ZWQgaW4gYm90aCANCj5kaXJlY3Rpb25zLCBzbyBpcyBpdCBhbHdheXMgbG9jYWwtdXVpZCB0aGF0 IGlzIA0KPmFzc2lnbmVkIG9yIGlzIGl0IHNvbWV0aW1lcyByZW1vdGUtdXVpZD8NCj5jKSB0aGUg dGV4dCAiYWxsIHNpZ25hbGxpbmcgbWVzc2FnZXMiIGRvZXMgbm90IA0KPnNlZW0gc3BlY2lmaWMg ZW5vdWdoIGUuZy4gdGhlIHNlbmRpbmcgZW5kcG9pbnQgDQo+bWlnaHQgaW5pdGlhdGUgYSBjb21w bGV0ZWx5IG5ldyBkaWFsb2cNCg0KYSkgbm90IGVtcHR5LCAibm9uLWV4aXN0ZW50Ig0KYikgYWx3 YXlzIGxvY2FsLCBleGNlcHQgdW5kZXIgdGhlIGNvbmRpdGlvbnMgb2Ygc2VjdGlvbiAxMA0KYykg bmV3IGRpYWxvZyBtZWFucyBuZXcgVVVJRHMgaW4gYm90aCBkaXJlY3Rpb25zDQoNCj5saW5lcyA0 NzEgLSA0NzMNCj4sIHRoZSBpbnRlcm1lZGlhcnkgTVVTVA0KPiAgICBwbGFjZSB0aGUgb25lIGtu b3duIFVVSUQgaW4gdGhlICJyZW1vdGUtdXVpZCIgZmllbGQgIGFuZCBzZXQgdGhlDQo+ICAgICJs b2NhbC11dWlkIiBmaWVsZCB0byB0aGUgbnVsbCBVVUlEIHZhbHVlLg0KPk1pZ2h0IGJlIGNsZWFy ZXIgdG8gc2F5ICJ1c2UgdGhlIG9uZSBrbm93biBVVUlEIA0KPmFzIHRoZSAicmVtb3RlLXV1aWQi IHNpbmNlICJyZW1vdGUtdXVpZCIgaXMgbm90IA0KPmEgaGVhZGVyIGZpZWxkIG9yIGEgaGVhZGVy IGZpZWxkIHBhcmFtZXRlci4gTGlrZXdpc2UgZm9yICJsb2NhbC11dWlkIg0KDQoic2luY2UgInJl bW90ZS11dWlkIiBpcyBub3QgYSBoZWFkZXIgZmllbGQgb3IgYSANCmhlYWRlciBmaWVsZCBwYXJh bWV0ZXIiLiBUaGUgbG9jYWwtdXVpZCBpcyBhIA0KaGVhZGVyLXZhbHVlIGFuZCB0aGUgcmVtb3Rl LXV1aWQgaXMgYSBoZWFkZXItcGFyYW1ldGVyLCBhbHdheXMuDQoNCj5saW5lIDQ5Mw0KPk1VU1Qg Y29uc3RydWN0IGEgU2Vzc2lvbi1JRCBoZWFkZXIgdmFsdWUNCj5NVVNUIHVzZSBhIFNlc3Npb24t SUQgaGVhZGVyIHZhbHVlDQoNCndoYXQgaWYgdGhlcmUgaXNuJ3QgYSBTZXNzaW9uLUlEOiB0aGVy ZSBpbiB0aGUgDQpmaXJzdCBwbGFjZT8gVGhlbiAidXNlIiAoc29tZXRoaW5nIHRoYXQncyBub24t ZXhpc3RlbnQpIGlzbid0IHJpZ2h0Lg0KDQo+bGluZSA1MTENCj5NQ1VzLCBpbmNsdWRpbmcgY2Fz Y2FkZWQgTUNVcyAsDQo+SXMgImNhc2NhZGVkIE1DVSIgYSB3ZWxsIHVuZGVyc3Rvb2QgdGVybT8N Cg0KSSBndWVzcyB0aGUgcmVhbCBxdWVzdGlvbiBpcyBpZiB0aGUgaW1wbGVtZW50b3IgDQp1bmRl cnN0YW5kcyB3aGF0IHRoZSB3b3JkIGNhc2NhZGUgaXMuIFM5LjYgZ2l2ZXMgDQpnb29kIGRpYWdy YW1zIG9mIHRoZSBtb3N0IGNvbW1vbiB1c2UtY2FzZXMuDQoNCj5saW5lcyA1NDMgLSA1NDYNCj5J bnRlcm1lZGlhcnkgZGV2aWNlcywgc3VjaCBhcyBwcm94aWVzICBvciBzZXNzaW9uIGJvcmRlciBj b250cm9sbGVycywNCj4gICAgb3IgbmV0d29yayBkaWFnbm9zdGljcyBlcXVpcG1lbnQgbWlnaHQg YXNzdW1lIHRoYXQgd2hlbiB0aGV5IHNlZSB0d28NCj4gICAgb3IgbW9yZSBzZXNzaW9ucyB3aXRo IGRpZmZlcmVudCBTZXNzaW9uIElkZW50aWZpZXJzLCBidXQgd2l0aCBvbmUNCj4gICAgVVVJRCBp biBjb21tb24sIHRoYXQgdGhlIHNlc3Npb25zIGFyZSBwYXJ0IG9mIHRoZSBzYW1lIGNvbmZlcmVu Y2UuDQo+TWF5YmUgcHJveGllcyBzaG91bGQgYmUgbGVmdCBvZmYgdGhlIGxpc3Qgb2YgDQo+ZGV2 aWNlcyB0aGF0IHdpbGwgZXhhbWluZSB0aGUgc2Vzc2lvbiBpZGVudGlmaWVyDQoNCmZvbGtzIGxv b2sgZm9yIHByb3h5IHdoZW4gdGFsa2luZyBhYm91dCBTSVAsIGFuZCANCml0IGl0J3MgbGVmdCBv ZmYgc29tZSBsaXN0IGludm9sdmluZyBzZXJ2ZXJzLCBpdCdsbCBiZSBhIGRpc3RyYWN0IChiZXN0 IGNhc2UpDQoNCj5saW5lIDU2Ng0KPiJOIiByZXByZXNlbnRzIGEgbnVsbCBVVUlEDQo+DQoNCkkn bGwgdGFsayB0byBteSBjby1lZGl0b3IgYWJvdXQgdGhpcw0KDQo+bGluZXMgNTg1IC0gNTg2DQo+ VUEtQWxpY2UgcG9wdWxhdGVzIHRoZSAibG9jYWwtdXVpZCIgcG9ydGlvbiBvZiB0aGUgU2Vzc2lv bi1JRA0KPiAgICAgICAgIGhlYWRlci12YWx1ZS4NCj5UaGlzIGJ1bGxldCBzZWVtcyB0byBiZSBy ZWR1bmRhbnQgYW5kIGNvdWxkIGJlIGRlbGV0ZWQNCg0KSSdtIGxvc3QgaGVyZS4gVGhlcmUgYXJl IHRocmVlIGluc3RhbmNlcyBvZiB0aGUgDQp3b3JkICJwb3B1bGF0ZXMiLCBhbmQgVUEtQWxpY2Ug aXNuJ3Qgb24gcGFnZSAxMSANCihsaW5lIDU4NS04NikuIFRoZXJlIGlzIGEgIkJvYidzIFVVSUQg cG9wdWxhdGVzIA0KdGhlICJyZW1vdGUtdXVpZCIuLi4gIiwgd2hpY2ggSSdkIGxpa2UgdG8ga2Vl cA0KDQo+bGluZSA1NTQNCj45LiBWYXJpb3VzIENhbGwgRmxvdyBPcGVyYXRpb25zIFV0aWxpemlu ZyB0aGUgU2Vzc2lvbiBJRA0KPkkgdGhpbmsgaXQgd291bGQgaGVscCBpZiBhdCBsZWFzdCBvbmUg b2YgdGhlIA0KPnNpZ25hbGxpbmcgZXhhbXBsZXMgc2hvd3MgU0lQIChhbmQgbWF5YmUgU0RQKS4g DQo+Rm9yIGEgd2hpbGUsIEkgd2FzIGNvbmZ1c2VkIGFib3V0IHdoZXRoZXIgDQo+ImxvY2FsLXV1 aWQiIGFuZCAicmVtb3RlLXV1aWQiIHdlcmUgaGVhZGVyIGZpZWxkIA0KPnBhcmFtZXRlcnMgYW5k IHRoZW4gd29uZGVyZWQgd2h5IHRoZSBvbmx5IElBTkEgDQo+cmVnaXN0cmF0aW9uIHdhcyBmb3Ig YSAicmVtb3RlIiBwYXJhbWV0ZXIuDQoNCkluc3RlYWQgb2YgdGhpcywgbG9vayBhdCB0aGUgdG9w IG9mIHBhZ2UgNyBmb3IgdGhlIFNlc3Npb24tSUQ6IGV4YW1wbGUuDQoNCj5saW5lIDE0MjMNCj4x MS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCj5BdCB0aGUgTG9uZG9uIG1lZXRpbmcsIHNlY3Vy aXR5IHdhcyBpZGVudGlmaWVkIA0KPmFzIGFuIG9wZW4gaXNzdWUgdGhhdCBuZWVkcyB0byBiZSBm dWxseSANCj5hbmFseXNlZC4gRG9lcyB0aGlzIGFuYWx5c2lzIHN0aWxsIG5lZWQgdG8gYmUgZG9u ZT8NCg0KV2UncmUgYWx3YXlzIG9wZW4gdG8gbW9yZSBjb21tZW50cy4gVGhlIFNlY0FEIA0KKFNl YW4gVHVybmVyID8pIGhhcyBiZWVuIGNvbnRhY3RlZCwgYnV0IGhhc24ndCANCmdvdHRlbiBiYWNr IHRvIHVzIG9yIHRoZSBjaGFpcnMuLi4NCg0KQWdhaW4sIHRoYW5rcyBmb3IgdGhlIHRob3JvdWdo IHJldmlldw0KDQpKYW1lcw0KDQo+DQo+DQo+DQo+RnJvbTogaW5zaXBpZCBbbWFpbHRvOmluc2lw aWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhdWwgRS4gSm9uZXMNCj5TZW50OiAx MCBBcHJpbCAyMDE0IDA0OjUzDQo+VG86IGluc2lwaWRAaWV0Zi5vcmcNCj5TdWJqZWN0OiBbSW5z aXBpZF0gUG9zdGVkIGRyYWZ0LWlldGYtaW5zaXBpZC1zZXNzaW9uLWlkLTA2DQo+DQo+Rm9sa3Ms DQo+DQo+SSBqdXN0IHVwbG9hZGVkIGEgcmV2aXNlZCB2ZXJzaW9uIG9mIHRoZSBTZXNzaW9uIA0K PklEIHNvbHV0aW9uIGRyYWZ0LiAgSW4gdGhpcyBkcmFmdCwgd2UgZGlkIHRoZSBmb2xsb3dpbmc6 DQo+ICAgICogQWRkZWQgdGV4dCB0byBTZWN0aW9uIDcgKGludGVybWVkaWFyaWVzKSANCj4gdG8g ZGVzY3JpYmUgaGFuZGxpbmcgb2YgcHJvdmlzaW9uYWwgcmVzcG9uc2VzDQo+ICAgICAgICAqIFdJ dGggb25lIHR5cG8gImludGVybWVkaWFyaWVzIA0KPiB0cmFuc21pdHMiICh3aWxsIGZpeCB0aGF0 IGluIHRoZSBuZXh0IHZlcnNpb24pDQo+ICAgICogQ2hhbmdlZCB0aGUgVVVJRCB2YWx1ZXMgdXNl ZCBmb3IgT09EIFJFRkVSIA0KPiAoU2VjdGlvbiA5LjkpIHBlciBsaXN0IGRpc2N1c3Npb24NCj4g ICAgKiBBZGRlZCBvbmUgbmV3IHBhcmFncmFwaCBvbiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0K PlBsZWFzZSBoYXZlIGEgbG9vayBhdCB0aGUgZHJhZnQgYW5kIHN1Z2dlc3QgDQo+b3RoZXIgdGhp bmdzIHdlIG5lZWQgdG8gYWRkcmVzcywgaW5jbHVkaW5nIGFueSANCj5pc3N1ZXMgeW91IGJlbGll dmUgd2UgbmVlZCB0byByYWlzZSBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQo+DQo+ VGhhbmtzLA0KPlBhdWwNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPmluc2lwaWQgbWFpbGluZyBsaXN0DQo+aW5zaXBpZEBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZA0KDQo= From nobody Wed Jul 30 11:09:13 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD151A0195 for ; Wed, 30 Jul 2014 11:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPUkBfvAXnH6 for ; Wed, 30 Jul 2014 11:05:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137661A01C5 for ; Wed, 30 Jul 2014 11:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5307; q=dns/txt; s=iport; t=1406743545; x=1407953145; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jmEX8c8PfUNOPmFLRiwt1vcawfMXRzrOUL8o4nxUqHg=; b=grBcVX2Fr8TckHmlhNR4mss1hwlJ8nJQ+Jfpj8B8711D2JsJ6T6TPRwv 51TxWqTqZQogi54gkbB2JX2+9IcWWrtqJbwdibAtkTLMFtASsK01j0pz6 fnNDNHlO0ukys3drps0okmLhKsN3VjsEcLA8SgWxZeZUxSI1cFCoxqjFi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFAIIy2VOtJA2D/2dsb2JhbABZAYMNUlcEywqIXBZ3hAo6LiMBPkInBBOIQg2ZEKcIF4l/ih4Flz6EJoFSkwGDSWyBAyQe X-IronPort-AV: E=Sophos;i="5.01,765,1400025600"; d="scan'208";a="343945439" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jul 2014 18:05:44 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6UI5iSk013191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Jul 2014 18:05:44 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 13:05:43 -0500 From: "Adam Gensler (agensler)" To: "insipid@ietf.org" Thread-Topic: Pre-WGLC INSIPID Session-ID Review Comments Thread-Index: AQHPrCDhKQ90DAn8HkiQQ2+H7MoUsw== Date: Wed, 30 Jul 2014 18:05:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.150.34.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <6FC00588511A1E45A90BB56A45B7ECBB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/uIeIFyRvJstTtRw0ENEP_DrOPiE X-Mailman-Approved-At: Wed, 30 Jul 2014 11:09:12 -0700 Subject: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 18:05:48 -0000 Hi all, I've reviewed the INSIPID Session-ID draft located here: http://tools.ietf.org/html/draft-ietf-insipid-session-id I have a few comments/questions, listed below in no particular order: --- 4.1. Constructing the Session Identifier "To satisfy the requirement that no user or device information be conveyed, endpoints SHOULD generate version 4 (random) or version 5 (SHA-1) UUIDs." "Intermediaries that insert a Session-ID header into a SIP message on behalf of a sending User Agent MUST utilize version 5 UUIDs to ensure that UUIDs for the communication session are consistently generated." Comment: What's the rational behind allowing two different types of UUID generation in the first paragraph, then mandating a kind in the second paragraph? It seems that mandating version 5 UUIDs would provide two benefits. First, it would ensure the UUIDs are consistently generated in all scenarios, and second, it would be inline with the security guidelines spelled out in section 11. --- --- 7. Processing by Intermediaries "When intermediaries transmits a 100 (Trying) provisional responseand when the UUID of the destination UA is unknown, the intermediary MUST place the one known UUID in the "remote-uuid" field and set the "local-uuid" field to the null UUID value. When an intermediary transmits any other provisional response and when the UUID of the destination UA is unknown, the intermediary MUST place the one known UUID in the "remote-uuid" field and MAY set the "local-uuid" field to a locally created UUID value or the null UUID value. Comment: What's the rational behind the difference in behavior between the 100 and other 1xx responses? --- --- 9.6. Cascading Conference Bridge Support for the Session ID General Comment: I'll admit to not being well versed in cascading MCU setups. Are multiple MCUs linked together always from the top down? Or, is it possible that a downstream MCU may link upstream, thereby potentially causing a race condition of Session-ID indication via simultaneous isfocus-INVITEs between two MCUs? --- --- 9.4 Single Focus Conferencing Comment: This example shows reINVITEs being sent to change the UUID from the temporary, IVR-connected session, to the UUID of the conference. Is a SIP UPDATE/200OK exchange also a possibility for updating the UUID? If so, the validity of using an UPDATE to reflect changes in the UUID should be specifically mentioned. --- --- General Comment: The opening introduction discusses the challenges of end-to-end session IDs in multi-protocol environments. Are any provisions given for inter-working this draft with something like H.323? If not, is there specific guidance worth providing for intermediate devices that interwork between multiple protocols (CUCM/CUBE)? General Comment: How does this draft mesh with SIP OPTIONS ping/keepalive functionality? Should a Session-ID be included there? General Comment: The Webex specific example seems out of place and product specific. What's the generally accepted rule in regard to mentioning specific products in an RFC? --- --- 7. Processing by Intermediaries "Devices that initiate communication sessions following the procedures for third party call control MUST fabricate a UUID value that will be utilized only temporarily. Once the responding endpoint provides a UUID value in a response message, the temporary value MUST be discarded and replaced with the endpoint-provided UUID value. Refer to the third-party call control example for an illustration." **snip** "If a SIP intermediary initiates a dialog between two UAs in a 3PCC scenario, the SIP request in the initial INVITE will have a non-null "local-uuid" value; call this temporary UUID X. The request will still have a null "remote-uuid" value; call this value N. The SIP server MUST be transaction stateful. The UUID pair in the INVITE will be {X,N}. A non-redirected or rejected response will have a UUID pair {A,X}. This transaction stateful, dialog initiating SIP server MUST replace its own UUID, i.e., X, with a null UUID (i.e., {A,N}) as expected by other UAS" Comment: These paragraphs both seem to be describing 3PCC scenarios, but are separated in this section by three paragraphs not talking about 3PCC. Would it be beneficial to move this paragraphs closer together? --- --- 6. Endpoint Behavior "It is also possible to for the UA to receive a "remote-uuid" value that does not match the UA's assigned UUID for the session." Comment: Typo - "...is also possible to for the UA to..." --- --- 7. Processing by Intermediaries "When intermediaries transmits a 100 (Trying) provisional responseand when the UUID of the destination UA is unknown" Comment: Typo - "...provisional responseand when the..." --- --- 9.6. Cascading Conference Bridge Support for the Session ID "The one MCU that generates the UUID informs one or several MCUs of this common UUID, and they inform downstream MCUs of this common UUID each will be using for this one conference, or" Comment: Truncated sentence? "...this one conference, or" --- Any input and/or feedback on the above would be great. Best regards, Adam --- Adam Gensler agensler@cisco.com From nobody Wed Jul 30 11:10:01 2014 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8BC1A0328 for ; Wed, 30 Jul 2014 11:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_yqHTWfTP5j for ; Wed, 30 Jul 2014 11:09:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C424D1A01C5 for ; Wed, 30 Jul 2014 11:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6026; q=dns/txt; s=iport; t=1406743795; x=1407953395; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=W9nojm/c5xIGeja6M9sbiS7LdY2nvNUOUI3Ixx4Nn9Y=; b=Lk43hNlxexWzTCqtLO8y5ek7fANc4ogDcEYxY7A+SEDnVH+Y9ZRAMQEv inwqGD41k8BHuT0KIgqFpSPJn4XhvqQhHYJcIEgXE8aE2v8KBHwaQKNaM mUSDbihUUiZhorUaDs3q57V6ZsN95IUNHmBha9DNUZPZ7gkXxt87RrGbq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAJE02VOtJV2Z/2dsb2JhbABZAYMNUk0KBMp/CoZ4UwGBEBZ3hAQBAQMBAQEBNy4GCwULAgEINhAnCyUCBA4FiDoIDcAXF4l/hRozB4MvgRsFlz6EJoFSkwGDSWyBAyQe X-IronPort-AV: E=Sophos;i="5.01,765,1400025600"; d="scan'208";a="343944668" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 30 Jul 2014 18:09:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6UI9pAe007931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Jul 2014 18:09:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 13:09:51 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Adam Gensler (agensler)" Thread-Topic: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments Thread-Index: AQHPrCDhKQ90DAn8HkiQQ2+H7MoUs5u5Pm+A Date: Wed, 30 Jul 2014 18:09:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D19BB5B739D7848AFE65CCB08977D10@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/joDF_UIEHW-kPdqWmFjvNSZNocQ Cc: "insipid@ietf.org" Subject: Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 18:09:59 -0000 Thanks for the review feedback, Adam. Cheers, Gonzalo On Jul 30, 2014, at 2:05 PM, Adam Gensler (agensler) w= rote: > Hi all, >=20 > I've reviewed the INSIPID Session-ID draft located here: > http://tools.ietf.org/html/draft-ietf-insipid-session-id >=20 >=20 > I have a few comments/questions, listed below in no particular order: >=20 >=20 >=20 > --- > 4.1. Constructing the Session Identifier > "To satisfy the requirement that no user or device information be > conveyed, endpoints SHOULD generate version 4 (random) or version 5 > (SHA-1) UUIDs." >=20 > "Intermediaries that insert a Session-ID header into a SIP message on > behalf of a sending User Agent MUST utilize version 5 UUIDs to ensure tha= t > UUIDs for the communication session are consistently generated." >=20 > Comment: What's the rational behind allowing two different types of UUID > generation in the first paragraph, then mandating a kind in the second > paragraph? It seems that mandating version 5 UUIDs would provide two > benefits. First, it would ensure the UUIDs are consistently generated in > all scenarios, and second, it would be inline with the security guideline= s > spelled out in section 11. > --- >=20 > --- > 7. Processing by Intermediaries >=20 > "When intermediaries transmits a 100 (Trying) provisional responseand whe= n > the UUID of the destination UA is unknown, the intermediary MUST place th= e > one known UUID in the "remote-uuid" field and set the "local-uuid" field > to the null UUID value. When an intermediary transmits any other > provisional response and when the UUID of the destination UA is unknown, > the intermediary MUST place the one known UUID in the "remote-uuid" field > and MAY set the "local-uuid" field to a locally created UUID value or the > null UUID value. >=20 > Comment: What's the rational behind the difference in behavior between th= e > 100 and other 1xx responses? > --- >=20 > --- > 9.6. Cascading Conference Bridge Support for the Session ID >=20 > General Comment: I'll admit to not being well versed in cascading MCU > setups. Are multiple MCUs linked together always from the top down? Or, i= s > it possible that a downstream MCU may link upstream, thereby potentially > causing a race condition of Session-ID indication via simultaneous > isfocus-INVITEs between two MCUs? > --- >=20 > --- > 9.4 Single Focus Conferencing >=20 > Comment: This example shows reINVITEs being sent to change the UUID from > the temporary, IVR-connected session, to the UUID of the conference. Is a > SIP UPDATE/200OK exchange also a possibility for updating the UUID? If so= , > the validity of using an UPDATE to reflect changes in the UUID should be > specifically mentioned. > --- >=20 > --- > General Comment: The opening introduction discusses the challenges of > end-to-end session IDs in multi-protocol environments. Are any provisions > given for inter-working this draft with something like H.323? If not, is > there specific guidance worth providing for intermediate devices that > interwork between multiple protocols (CUCM/CUBE)? >=20 > General Comment: How does this draft mesh with SIP OPTIONS ping/keepalive > functionality? Should a Session-ID be included there? >=20 > General Comment: The Webex specific example seems out of place and produc= t > specific. What's the generally accepted rule in regard to mentioning > specific products in an RFC? > --- >=20 > --- > 7. Processing by Intermediaries >=20 > "Devices that initiate communication sessions following the procedures fo= r > third party call control MUST fabricate a UUID value that will be utilize= d > only temporarily. Once the responding endpoint provides a UUID value in a > response message, the temporary value MUST be discarded and replaced with > the endpoint-provided UUID value. Refer to the third-party call control > example for an illustration." >=20 > **snip** >=20 > "If a SIP intermediary initiates a dialog between two UAs in a 3PCC > scenario, the SIP request in the initial INVITE will have a non-null > "local-uuid" value; call this temporary UUID X. The request will still > have a null "remote-uuid" value; call this value N. The SIP server MUST b= e > transaction stateful. The UUID pair in the INVITE will be {X,N}. A > non-redirected or rejected response will have a UUID pair {A,X}. This > transaction stateful, dialog initiating SIP server MUST replace its own > UUID, i.e., X, with a null UUID (i.e., {A,N}) as expected by other UAS" >=20 > Comment: These paragraphs both seem to be describing 3PCC scenarios, but > are separated in this section by three paragraphs not talking about 3PCC. > Would it be beneficial to move this paragraphs closer together? > --- >=20 > --- > 6. Endpoint Behavior >=20 > "It is also possible to for the UA to receive a "remote-uuid" value that > does not match the UA's assigned UUID for the session." >=20 > Comment: Typo - "...is also possible to for the UA to..." > --- >=20 >=20 > --- > 7. Processing by Intermediaries >=20 > "When intermediaries transmits a 100 (Trying) provisional responseand whe= n > the UUID of the destination UA is unknown" >=20 > Comment: Typo - "...provisional responseand when the..." > --- >=20 >=20 > --- > 9.6. Cascading Conference Bridge Support for the Session ID >=20 > "The one MCU that generates the UUID informs one or several MCUs of this > common UUID, and they inform downstream MCUs of this common UUID each wil= l > be using for this one conference, or" >=20 > Comment: Truncated sentence? "...this one conference, or" > --- >=20 > Any input and/or feedback on the above would be great. >=20 > Best regards, > Adam >=20 > --- > Adam Gensler > agensler@cisco.com >=20 >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid