From nobody Mon Jun 5 07:13:35 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2990F1298BA; Mon, 5 Jun 2017 07:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eVd-6nMhPZ6; Mon, 5 Jun 2017 07:13:22 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A724129A8F; Mon, 5 Jun 2017 07:13:21 -0700 (PDT) Received: from [85.158.139.163] by server-9.bemta-5.messagelabs.com id 1B/F9-01999-FF665395; Mon, 05 Jun 2017 14:13:19 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleJIrShJLcpLzFFi42LR98zp1P2XZhp psOiAvkXjg2nsFo8e/WCymH//GZMDs8eU3xtZPZYs+ckUwBTFmpmXlF+RwJrx8e5vloJHCxkr Fn07x9rAOHkCYxcjF4eQwDZGiXs925ghnEOMEj/uTGWBcDYxSjR1XAByODjYBOwlZuyJ6WLk5 BAR0JT4eOMcWAOzQCOjxIXnXewgCWGBUImtHx4yQxSFSby/Ph3KNpJYuPAWK4jNIqAisW3uYj YQmxeovn/9QbAaRgFZiS+Nq8FsZgFxiVtP5jOB2BICAhJL9pxnhrBFJV4+/scKcg+zQJ7EykZ FiDGCEidnPmEBsYUEVCX+rVzENIFRaBaSSbMQOmYh6YAo0ZFYsPsTG4StLbFs4WtmGPvMgcdM yOILGNlXMaoXpxaVpRbpmuglFWWmZ5TkJmbm6BoamOrlphYXJ6an5iQmFesl5+duYgTGEwMQ7 GC81ed8iFGSg0lJlHe1ommkEF9SfkplRmJxRnxRaU5q8SFGGQ4OJQne3FSgnGBRanpqRVpmDj CyYdISHDxKIrzOIGne4oLE3OLMdIjUKUZFKXHefSAJAZBERmkeXBssmVxilJUS5mUEOkSIpyC 1KDezBFX+FaM4B6OSMO+ZFKApPJl5JXDTXwEtZgJazHfJBGRxSSJCSqqBccLWpYyN/ns7PF3X 3IjVNNlz84djZcCKmhtO3azWaz6UsKV47r7WNcUi4Ea6zGSuyyG5U5cUvUp7xPFcyapF/Y5Ds WPmi+Z9ujwPnohuORosxO+2TtY988JbzYdrXNc9/qiSJSxfXnFk07EJbEqVSiEre7o1JXb1NR vM89r19cvie5XOSxevVmIpzkg01GIuKk4EAOcCynohAwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-15.tower-188.messagelabs.com!1496671996!111626197!3 X-Originating-IP: [47.73.108.137] X-StarScan-Received: X-StarScan-Version: 9.4.19; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26575 invoked from network); 5 Jun 2017 14:13:18 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.137) by server-15.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 5 Jun 2017 14:13:18 -0000 Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Jun 2017 16:13:03 +0200 Received: from VOEXC06W.internal.vodafone.com (145.230.101.26) by VOEXH06W.internal.vodafone.com (47.73.211.204) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Jun 2017 16:13:02 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.246]) by VOEXC06W.internal.vodafone.com ([192.168.89.204]) with mapi id 14.03.0352.000; Mon, 5 Jun 2017 16:13:02 +0200 From: "Dawes, Peter, Vodafone Group" To: "insipid@ietf.org" CC: "insipid-chairs@ietf.org" , "Arun Arunachalam (carunach) (carunach@cisco.com)" Thread-Topic: draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged" Thread-Index: AdLOtx1nlsqbvQXKTMWmLjT3ATquTQPTn0YA Date: Mon, 5 Jun 2017 14:13:02 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E159785F@VOEXM31W.internal.vodafone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E159785FVOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Logged" X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 14:13:25 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E159785FVOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Just a kind reminder that a significantly revised logme-marking solution dr= aft (-07) was uploaded a few weeks ago. The revised text aims to pair with = the now published requirements draft as a complete description of problem a= nd solution, and to answer some comments and concerns raised during the rev= iew of the requirements draft. The authors are hoping we can progress this draft as a follow-up to the req= uirements discussion as the issues are similar and some of the text in this= solution draft was moved from the requirements draft. Comments and reviews are welcome! Best regards, Peter (co-author) From: Dawes, Peter, Vodafone Group Sent: 17 May 2017 05:14 To: insipid@ietf.org Cc: insipid-chairs@ietf.org; Arun Arunachalam (carunach) (carunach@cisco.co= m) Subject: draft-ietf-insipid-logme-marking-07 "Marking SIP Messages to be Lo= gged" Hello All, To follow up on the logme requirements being published as RFC 8123, the cor= responding solution draft https://datatracker.ietf.org/doc/draft-ietf-insip= id-logme-marking/ has been revised and uploaded as -07. Changes in this version are from a few sources. The requirements draft cont= ained some detailed solution-related text that has been moved to the soluti= on draft. The IESG review of the requirements draft highlighted a number of= corrections and concerns including privacy. A review that Paul Giralt sent= to this list a while back identified some changes. Also, the authors restr= uctured and clarified the descriptions throughout. The changes are all sum= marized below. We have tried to be comprehensive in describing procedures and answering re= view concerns in this version and it would be good to hear if issues remain= . Thanks! Peter and Arun (co-authors) **Changes as a result of review of requirements draft by Dan Romascanu and = moving text from the requirements to the solution draft** In "2. Conventions Used in this Document added text to expand the applicab= ility of requirements language. Added a new high-level clause "Marking Related Dialogs" to describe "log me= " marking related dialogs. Defined the SIP CLF format for logs in "Format of Logged Signaling". Restructured "Security Considerations". Trust domain behavior described in end-to-end marking clause. Restructured with high-level "Stateful and Stateless SIP Entities" clause. End-to-end marking section clarifies that "log me" marking does not contain= any user or device specific information. "Authorizing logme Marking" section added to Security Considerations **Changes resulting from review of requirements draft by Stephen Farrell, K= athleen Moriarty Moved "Trust Domain" sub-clause from "Security Considerations" to the body = of the draft and re-named it "End-to-End Marking" Added a "Privacy" sub-clause in "Security Considerations". Did a privacy analysis as described in RFC 6973 and as a result completely = restructured and revised the Privacy section. **Changes as a result of review by Paul Giralt Section 5.1 on configuration removed. Configuration does not need to be des= cribed in any detail as it is out of scope of the document. Example of calling/called party number added to section "Starting and Stopp= ing logme Marking". Text revised to "log me" marking MUST be copied into forked requests. Section 4.2.1.2.1 describes B2BUA terminating behaviour (since according to= RFC 7092, a signaling only B2BUA can manipulate SIP in any way it likes.) References to RFC 7206 changed to references to RFC 7989. In section 6.5, text revised to "A SIP entity that has logged information M= UST protect the logs, such that the logs can only be read by a person autho= rized to do so." Text added to introduction stating that session identity must be implemente= d for this document. RFC7989 added to normative references. logme-reqs moved to informative references. Syntax of all references revised. Revised section "Identifying Test Cases" to align with description in the r= equirements draft. **Authors updates Text in 5.1 moved to clause 4 and revised to clarify that the example of us= ing XML to show configuration is only an example. The draft does not formal= ize how configuration is done. Text revised to say that it is operator knowledge that some user agents do = not support "log me" and that a SIP entity must act on behalf of the user a= gent Revised text for both originating and terminating proxies to say that they = MUST log signaling. Replaced text and figure in 5.4 with a list of 4 cases for maintaining stat= e and 4 figures that illustrate each one. Replaced figure with four figures based on a call flow example from RFC 366= 5. The new figures are simpler and have a single proxy in originating and t= erminating networks. Currently the signaling B2BUA is subject to the same rules as a user's UA, = i.e. it cannot invoke "log me" marking on dialogs that it creates without c= onfiguration to do so. Text is revised to clarify why this restriction exis= ts, and perhaps this rule can be re-visited if cases for breaking the rule = emerge. debug parameter renamed logme. Split the "Maintaining State" clause into sub-clauses that describe statele= ss and stateful behavior. Restructured the entire draft into a more natural order of describing the "= log me" marker, SIP entity behavior, error cases, and security. Consistent use of "log me" term. Referenced RFC8123 instead of I-D.ietf-insipid-logme-reqs Updated ABNF definition (Figure 7) to define header field parameter as "log= me" --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E159785FVOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

Just a kind reminder t= hat a significantly revised logme-marking solution draft (-07) was uploaded= a few weeks ago. The revised text aims to pair with the now published requ= irements draft as a complete description of problem and solution, and to answer some comments and concerns raised d= uring the review of the requirements draft.

 

The authors are hoping= we can progress this draft as a follow-up to the requirements discussion a= s the issues are similar and some of the text in this solution draft was mo= ved from the requirements draft.

 

Comments and reviews a= re welcome!

 

Best regards,

Peter (co-author) 

 

 

 

From:= Dawes, Peter, Vodafone Group
Sent: 17 May 2017 05:14
To: insipid@ietf.org
Cc: insipid-chairs@ietf.org; Arun Arunachalam (carunach) (carunach@c= isco.com)
Subject: draft-ietf-insipid-logme-marking-07 "Marking SIP Messa= ges to be Logged"

 

Hello All,

To follow up on the logme requirements being publish= ed as RFC 8123, the corresponding solution draft https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ = has been revised and uploaded as -07.

 

Changes in this version are from a few sources. The = requirements draft contained some detailed solution-related text that has b= een moved to the solution draft. The IESG review of the requirements draft = highlighted a number of corrections and concerns including privacy. A review that Paul Giralt sent to this lis= t a while back identified some changes. Also, the authors restructured and = clarified the descriptions throughout.  The changes are all summarized= below.

 

We have tried to be comprehensive in describing proc= edures and answering review concerns in this version and it would be good t= o hear if issues remain.

 

Thanks!

Peter and Arun (co-authors)

 

**Changes as a result of review of requirements draf= t by Dan Romascanu and moving text from the requirements to the solution dr= aft**

In "2.  Conventions Used in this Document = added text to expand the applicability of requirements language.=

 

Added a new high-level clause "Marking Related = Dialogs" to describe "log me" marking related dialogs.<= /o:p>

 

Defined the SIP CLF format for logs in "Format = of Logged Signaling".

 

Restructured “Security Considerations”. =

 

Trust domain behavior described in end-to-end markin= g clause.

 

Restructured with high-level "Stateful and Stat= eless SIP Entities" clause.

 

End-to-end marking section clarifies that "log = me" marking does not contain any user or device specific information.<= o:p>

 

"Authorizing logme Marking" section added = to Security Considerations

 

 

 

**Changes resulting from review of requirements draf= t by Stephen Farrell, Kathleen Moriarty

Moved "Trust Domain" sub-clause from "= ;Security Considerations" to the body of the draft and re-named it &qu= ot;End-to-End Marking"

 

Added a "Privacy" sub-clause in "Secu= rity Considerations".

 

Did a privacy analysis as described in RFC 6973 and = as a result completely restructured and revised the Privacy section.

 

 

 

**Changes as a result of review by Paul Giralt<= /o:p>

Section 5.1 on configuration removed. Configuration = does not need to be described in any detail as it is out of scope of the do= cument.

 

Example of calling/called party number added to sect= ion "Starting and Stopping logme Marking".

 

Text revised to "log me" marking MUST be c= opied into forked requests.

 

Section 4.2.1.2.1 describes B2BUA terminating behavi= our (since according to RFC 7092, a signaling only B2BUA can manipulate SIP= in any way it likes.)

References to RFC 7206 changed to references to RFC = 7989.

 

In section 6.5, text revised to "A SIP entity t= hat has logged information MUST protect the logs, such that the logs can on= ly be read by a person authorized to do so."

 

Text added to introduction stating that session iden= tity must be implemented for this document. RFC7989 added to normative refe= rences.

 

logme-reqs moved to informative references.

 

Syntax of all references revised.

 

Revised section "Identifying Test Cases" t= o align with description in the requirements draft.

 

 

 

**Authors updates

Text in 5.1 moved to clause 4 and revised to clarify= that the example of using XML to show configuration is only an example. Th= e draft does not formalize how configuration is done.

 

Text revised to say that it is operator knowledge th= at some user agents do not support "log me" and that a SIP entity= must act on behalf of the user agent

 

Revised text for both originating and terminating pr= oxies to say that they MUST log signaling.

 

Replaced text and figure in 5.4 with a list of 4 cas= es for maintaining state and 4 figures that illustrate each one.

 

Replaced figure with four figures based on a call fl= ow example from RFC 3665. The new figures are simpler and have a single pro= xy in originating and terminating networks.

 

Currently the signaling B2BUA is subject to the same= rules as a user's UA, i.e. it cannot invoke "log me" marking on = dialogs that it creates without configuration to do so. Text is revised to = clarify why this restriction exists, and perhaps this rule can be re-visited if cases for breaking the rule emerge.

 

debug parameter renamed logme.

 

Split the "Maintaining State" clause into = sub-clauses that describe stateless and stateful behavior.

        &nbs= p;            &= nbsp;     

Restructured the entire draft into a more natural or= der of describing the “log me” marker, SIP entity behavior, err= or cases, and security.

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =   

Consistent use of "log me" term.

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =  

Referenced RFC8123 instead of I-D.ietf-insipid-logme= -reqs

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =  

Updated ABNF definition (Figure 7) to define header = field parameter as "logme"

 

 

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E159785FVOEXM31Winterna_-- From nobody Mon Jun 5 14:41:07 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2C12E036 for ; Mon, 5 Jun 2017 14:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo7QLd8X2XKn for ; Mon, 5 Jun 2017 14:41:05 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B03129B2C for ; Mon, 5 Jun 2017 14:41:04 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-05v.sys.comcast.net with SMTP id HzjidIO6Xzz3dHzkGdlIVg; Mon, 05 Jun 2017 21:41:04 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-02v.sys.comcast.net with SMTP id HzkFdENUtgFBHHzkFd26eZ; Mon, 05 Jun 2017 21:41:04 +0000 To: "insipid@ietf.org" References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15977A9@VOEXM31W.internal.vodafone.com> From: Paul Kyzivat Message-ID: <19bd71c8-e74c-4e71-f5ed-a3fd77ffb9b0@alum.mit.edu> Date: Mon, 5 Jun 2017 17:41:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15977A9@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGTBAqGk/KJJZduQQqZRSR6GBa/u6unrvLL90O37iKbKzItuA+cZg9czlyn7U3A4kAdnUWEL0KhLCBKeY/HufgAfa2xUWZK80kwGkMrbx9VWeWKSuNkR HHRsEJWR8HpotpURXui1w4pDyRA51ufPnVacd0o8QNOFLLrehWgsKhqq Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 21:41:06 -0000 I have reviewed the -07 version. This time I couldn't do it just by looking at the diff, so I did read it end to end. I do have a number of comments: * Terminology: Some places use "test case identifier" while others use "test identifier". Please pick one term and stick to it. Or perhaps the special term can be abandoned altogether by simply using Session-ID. * Section 3.1: Example needs to use domain names taken from domains example.com or example.org. * Section 3.7: It would be helpful to include some message detail for F1, F2 and F3. It doesn't have to be complete, but should show the Session-ID header field. * Section 4.1: A couple of important things seem to have been left out of the list principles: - the originating UA should itself log all the requests in the dialog. - the terminating UA should also log in-dialog requests that it marks and sends, and the corresponding responses. (This could be simplified by simply saying that both UAs should log all messages in the dialog.) * Section 4.2: Similar comment to that for 4.1. * Section 4.2.1: IMO what is written in this section and subsections is both incomplete and overly complex. ISTM that this can be greatly simplified: - a dialog on one "side" of the B2BUA may or may not be coupled to a related dialog on the other "side" for logme purposes. - by default related dialogs on the two sides are coupled. In cases where the B2BUA is more complex some related dialogs might not be coupled. (You can say as much or as little as you want about this.) - if a dialog on one side is logme marked then a coupled dialog on the other side must also be so marked. This affects all messages in both dialogs. * Section 4.2.2.2.1: The actions are labeled by message id (Fn), but those for F2 and F3 don't correspond to the corresponding message. Also you missed a message. I think you mean: F1 - Alice's UA does not insert a "log me" marker in the dialog- creating INVITE request F1. Nevertheless, Proxy 1 is configured to detect the start of logging. Proxy 1 logs INVITE request F1 and maintains state that this dialog is being logged. F5 - Proxy 1 inserts a "log me" marker in INVITE request F5 before forwarding it to Proxy 2. F16 - Proxy 1 inserts a "log me" marker in ACK request F16 before forwarding it to Proxy 2). F22 - Proxy 1 inserts a "log me" marker in 200 response F22 before forwarding it to Proxy 2. Also, should Proxy 1 also be inserting a "log me" marker into F6, F11, F14, and F20? In this topology they will probably be ignored by Alice, but maybe there can be cases where they are not. * Section 4.2.2.2.3: You forgot to mention: F8 - Proxy 2 inserts a "log me" marker in the 100 response it sends to Proxy 1. * Section 4.2.2.2.4: This section says: In Figure 6 below Proxy 2 removes "log me" marking from all SIP requests and responses entering network B. Proxy 1 therefore maintains state of which dialogs are being "log me" marked in order to "log me" mark all requests and responses that it receives from Proxy 2. The "therefore" in this doesn't make sense. IMO you can't expect that Proxy 1 knows a priori that Proxy 2 will do that and hence maintain state. Rather, I think you need to assume that Proxy 1 maintains state in any case, and then uses it to mark things if it observes that they haven't been marked already. So I suggest: In Figure 6 below Proxy 2 removes "log me" marking from all SIP requests and responses entering network B. Proxy 1 maintains the marking state of the dialog. When it observes that requests and responses received from Proxy 2 are not marked it adds the marking. However this seems to be in conflict with section 5.1. I don't know how to reconcile those. * Section 5.2: I question this. Consider a 3PCC case - Alice calls Bob via a B2BUA, then the B2BUA reconnects Alice to Charlie. It may turn out that Charlie has logme marking enabled. So this will appear during the dialog establishment with Charlie, but it will appear to be mid-dialog to Alice. I think you do want to log in this case. * Section 7: I suggest simplifying the ABNF as follows: sess-id-param =/ logme-param logme-param = "logme" I expect that issues may still be raised regarding security and privacy, but I'm not an expert on that stuff and will leave it to others. Thanks, Paul From nobody Fri Jun 9 08:07:22 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3887129442 for ; Fri, 9 Jun 2017 08:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPKXyl5sMl4L for ; Fri, 9 Jun 2017 08:07:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5AE127076 for ; Fri, 9 Jun 2017 08:07:17 -0700 (PDT) X-AuditID: c1b4fb30-4a9ff70000003fda-57-593ab9a37a16 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.21.16346.3A9BA395; Fri, 9 Jun 2017 17:07:15 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 9 Jun 2017 17:07:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xynFaAp8JOhjzdZxVI78Vh2ATeZE8O+zT5TYoNsIzRc=; b=A+EasTadCZNDEkSdGBMP9U/5YxTu+whV+GuBJyHaITD3bTkhUhAjf7/jr5icHNdVmIQNTU5FllbAYHLPCGDsuF7nD+yQ80VihAPptorpmuXvVY7PHlOcYiNe0OF/HHmJf4zkJbIfWxy4kLZG46HYlbTWS864rvhlaeYP0BiudG8= Received: from DB5PR07MB0949.eurprd07.prod.outlook.com (10.161.200.144) by DB5PR07MB0808.eurprd07.prod.outlook.com (10.161.196.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Fri, 9 Jun 2017 15:07:13 +0000 Received: from DB5PR07MB0949.eurprd07.prod.outlook.com ([fe80::b5f3:e92f:5f19:54de]) by DB5PR07MB0949.eurprd07.prod.outlook.com ([fe80::b5f3:e92f:5f19:54de%17]) with mapi id 15.01.1157.014; Fri, 9 Jun 2017 15:07:13 +0000 From: =?iso-8859-1?Q?J=F6rgen_Axell?= To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] draft-ietf-insipid-logme-marking-07 Thread-Index: AQHS3kSNOfynA3pNy0mnFAelZjVtTKIcMp/A Date: Fri, 9 Jun 2017 15:07:13 +0000 Message-ID: References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15977A9@VOEXM31W.internal.vodafone.com> <19bd71c8-e74c-4e71-f5ed-a3fd77ffb9b0@alum.mit.edu> In-Reply-To: <19bd71c8-e74c-4e71-f5ed-a3fd77ffb9b0@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB0808; 7:AziFSJXIX+ZG9g+JzCtSGazlcGSeA23fU88YmGGSqNd8TehR3wSLGlt8+vCSjDQICLgnsnMhNFbMw3Fi0y+JdFkBg3lf/3gFxdgS/sijU9sQ4ZWJz8pTQdvE0rb5/Q/xiSHTZe81Ur+jlu/4a6h5VsibILn4Ww6w4gDtSVmNerJEESCQXEUgiaFgNNXTs4kPuY5aD+ZqjJpDdjSffxr8ZMZft7B9n/pacZnbrpSvi7cPWoG3kygKwtk69GFcGD7QXY/d484nm5XQzqFaFZUxdcK+GGTX5f5MQOR7CrmZiu0y3t9haFkG5qUMqlUKBYR/9HYd8etdzhjQvrRpmtrgNQ== x-ms-traffictypediagnostic: DB5PR07MB0808: x-ms-office365-filtering-correlation-id: fffa2adf-242f-48fd-164f-08d4af493606 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB5PR07MB0808; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0808; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0808; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(39400400002)(13464003)(55016002)(99286003)(2906002)(54356999)(2501003)(6436002)(33656002)(478600001)(6506006)(76176999)(3846002)(102836003)(50986999)(53936002)(6306002)(966005)(5250100002)(14454004)(189998001)(7696004)(9686003)(53546009)(25786009)(86362001)(8676002)(7736002)(3660700001)(6246003)(2171002)(2950100002)(38730400002)(81166006)(3280700002)(2900100001)(8936002)(5660300001)(74316002)(229853002)(230783001)(305945005)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB0808; H:DB5PR07MB0949.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 15:07:13.8003 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0808 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee7LvBstHtfE00qQJQQTzaQPNiWUAgXTEio1olp6U1GnbNNS IVQydCbYq07QKYrZFqaptZqlLctS0Sw1rczalrIslSjCTMntLujb7zn/c/7nhYchRSW0hElT aliVUpEh5QkoXcK92IDG+/LEoAX79hD9zCwR0tLWS4cTUauLS0RUU9MycZA4KghLZjPSclnV jj0nBam1Sy1E9pPAs23GXlSIlrdpEcMA3gXNxgAtEjAi3Ifgeaud0CL++qMfQbWtwClQuIKE iu8NJCdUEdBfKucqrAjqdaM8p8DDETC+9sfDyWIcB6+f1rvim7AcBvrGKS4eCgb7JXdOMLyv nHQxhf1gddbhyhHiY6DvMCKuQTkCU5HJZcTH4TAxWk07GWEf+FFkdE1EYm94a9e7xgaMoal7 hOTYCxy2NdpphPAVBKX6MZrb2Rc+dcVyOT7wSl/uagb4IgnT1suIE2Qw1F3swXEMGFpn3Kbn wNQzRXGcDu0312iOQ8ExbKY5IwsNhsZFd/FW6JmqdgstNNRNlrjvIoHpsTJUiWQ1/23BcSBM XrvK49gfmhvmyRrXaTzhhc5O1SPKgLzUrPpUZkpwcCCrSktSq7OUgUpWcwetf47HnStBJuSY i7AgzCDpBqG5RJ4oohW56rxMCwKGlIqFX+6uh4TJirx8VpV1QpWTwaotaAtDSb2FEY9eJohw ikLDprNsNqv6pxIMX1KItA8TzJFiy5EueXztwnyKw9eSP+IxwS9yRB+IFs/pIg/X3Xp2/g35 4dvcyuePmqH9pvqC22HzVttQTfzwmc7jvxr2bTTlKGVdLWZJSFP1BVXH1yRJ3Gl2sOL65t97 q3RlqflSh8EyNeB3w1Y8mz24+93P9hhs9X8gOwSeMjHMSCl1qmKnjFSpFX8B2hfvMRgDAAA= Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 15:07:21 -0000 Hi, This is my review on this draft, trying to not duplicate Paul's comments: 4.1 says "log me" header in one place, change to "log me" marker terminology "header" versus "header field" seems inconsistent 4.2: The third sentence (starting with 'The "log me" marker...') seems a bit sta= ndalone. I think the text could have a condition e.g.: "If a "log me" marke= r is received by a user agent not supporting "log me" marking the user agen= t does not echo the "log me" marker in responses." I think the last bullet should say that the originating SIP intermediary ec= hoes **received** "log me" markers in responses to in-dialog requests. As t= he text is now I get a bit uncertain if the node always puts in a "log me" = marker in the response. If so it would be against the recommendation in 5.1= . 4.2.2.2.1 Editorial: Proxy-1-->Proxy 1 4.2.2.2.2 first line has in In. Below figure 4 F6, remove "the" from "the Alice's".=20 Regards, J=F6rgen -----Original Message----- From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 05 June 2017 23:41 To: insipid@ietf.org Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07 I have reviewed the -07 version. This time I couldn't do it just by looking= at the diff, so I did read it end to end. I do have a number of comments: * Terminology: Some places use "test case identifier" while others use "test identifier". = Please pick one term and stick to it. Or perhaps the special term can be ab= andoned altogether by simply using Session-ID. * Section 3.1: Example needs to use domain names taken from domains example.com or example= .org. * Section 3.7: It would be helpful to include some message detail for F1, F2 and F3. It do= esn't have to be complete, but should show the Session-ID header field. * Section 4.1: A couple of important things seem to have been left out of the list principles: - the originating UA should itself log all the requests in the dialog. - the terminating UA should also log in-dialog requests that it marks and s= ends, and the corresponding responses. (This could be simplified by simply saying that both UAs should log all mes= sages in the dialog.) * Section 4.2: Similar comment to that for 4.1. * Section 4.2.1: IMO what is written in this section and subsections is both incomplete and = overly complex. ISTM that this can be greatly simplified: - a dialog on one "side" of the B2BUA may or may not be coupled to a relate= d dialog on the other "side" for logme purposes. - by default related dialogs on the two sides are coupled. In cases where t= he B2BUA is more complex some related dialogs might not be coupled. (You ca= n say as much or as little as you want about this.) - if a dialog on one side is logme marked then a coupled dialog on the othe= r side must also be so marked. This affects all messages in both dialogs. * Section 4.2.2.2.1: The actions are labeled by message id (Fn), but those for F2 and F3 don't c= orrespond to the corresponding message. Also you missed a message. I think = you mean: F1 - Alice's UA does not insert a "log me" marker in the dialog- creating INVITE request F1. Nevertheless, Proxy 1 is configured to detect the start of logging. Proxy 1 logs INVITE request F1 and maintains state that this dialog is being logged. F5 - Proxy 1 inserts a "log me" marker in INVITE request F5 before forwarding it to Proxy 2. F16 - Proxy 1 inserts a "log me" marker in ACK request F16 before forwarding it to Proxy 2). F22 - Proxy 1 inserts a "log me" marker in 200 response F22 before forwarding it to Proxy 2. Also, should Proxy 1 also be inserting a "log me" marker into F6, F11, F14,= and F20? In this topology they will probably be ignored by Alice, but mayb= e there can be cases where they are not. * Section 4.2.2.2.3: You forgot to mention: F8 - Proxy 2 inserts a "log me" marker in the 100 response it sends to Proxy 1. * Section 4.2.2.2.4: This section says: In Figure 6 below Proxy 2 removes "log me" marking from all SIP requests and responses entering network B. Proxy 1 therefore maintains state of which dialogs are being "log me" marked in order to "log me" mark all requests and responses that it receives from Proxy 2. The "therefore" in this doesn't make sense. IMO you can't expect that Proxy= 1 knows a priori that Proxy 2 will do that and hence maintain state. Rathe= r, I think you need to assume that Proxy 1 maintains state in any case, and= then uses it to mark things if it observes that they haven't been marked a= lready. So I suggest: In Figure 6 below Proxy 2 removes "log me" marking from all SIP requests and responses entering network B. Proxy 1 maintains the marking state of the dialog. When it observes that requests and responses received from Proxy 2 are not marked it adds the marking. However this seems to be in conflict with section 5.1. I don't know how to = reconcile those. * Section 5.2: I question this. Consider a 3PCC case - Alice calls Bob via a B2BUA, then t= he B2BUA reconnects Alice to Charlie. It may turn out that Charlie has logm= e marking enabled. So this will appear during the dialog establishment with= Charlie, but it will appear to be mid-dialog to Alice. I think you do want= to log in this case. * Section 7: I suggest simplifying the ABNF as follows: sess-id-param =3D/ logme-param logme-param =3D "logme" I expect that issues may still be raised regarding security and privacy, bu= t I'm not an expert on that stuff and will leave it to others. Thanks, Paul _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From nobody Tue Jun 13 04:05:21 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49259131101 for ; Tue, 13 Jun 2017 04:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_R50NafxlOP for ; Tue, 13 Jun 2017 04:05:17 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60DB12F4B2 for ; Tue, 13 Jun 2017 04:03:15 -0700 (PDT) Received: from [193.109.255.99] by server-9.bemta-6.messagelabs.com id 5B/96-03557-176CF395; Tue, 13 Jun 2017 11:03:13 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRWlGSWpSXmKPExsWi75nTrVt4zD7 S4O1ZSYvGB9PYLebff8ZksWL5W0aLFRsOsDqwePx9/4HJY8rvjawev75eZfNYsuQnUwBLFGtm XlJ+RQJrxsS/dxkL9iVU3L3dz9TA+M29i5GTQ0hgO6PE3Z92XYxcQPZhRomFF/YxQzhHGCXu7 bkF5WxmlPh55CtrFyMHB5uAvcSMPTEgcRGBXkaJtwePMoOMYhbwlli6bSmYLSxgJXHqyFUWEF tEwFpi1ZOJ7CC9IgJuEgtes4OEWQRUJa5/esUKYvMKhErc3bCVDWLXHUaJa79OMYEkOAViJda 9+Q9WxCggK/GlcTXULnGJW0/mg9VICAhILNlznhnCFpV4+fgfK0SNnsSNqVPYIGxtiWULXzND LBOUODnzCQvE+6oS/1YuYprAKDYLydhZSNpnIWmfhaR9ASPLKkaN4tSistQiXWMjvaSizPSMk tzEzBxdQwMzvdzU4uLE9NScxKRiveT83E2MwDhkAIIdjKfXBR5ilORgUhLl3XLFJlKILyk/pT IjsTgjvqg0J7X4EKMMB4eSBK/YUftIIcGi1PTUirTMHGBCgElLcPAoifAGHAZK8xYXJOYWZ6Z DpE4xKkqJ87qD9AmAJDJK8+DaYEnoEqOslDAvI9AhQjwFqUW5mSWo8q8YxTkYlYR5Tx4BmsKT mVcCN/0V0GImoMXXQW7mLS5JREhJNTDOy12vtUc+RKI2bFJd4fPl8nzSaa33bMoPF9UkaJw0b qza9PZkqVrR2inOkW/2nt3MM2PhivYuu5zmxs6rDZ/FJU8fyYxOSJI4FrePy922Vj845i3nhV D5WIvt5W3+L1yT3h+ffCOj+G5H5nFuvosaXVKRnxaeWxhfUOywv9uk8Fb0fLNJP5RYijMSDbW Yi4oTARXBWBo9AwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-3.tower-48.messagelabs.com!1497351790!121649157!10 X-Originating-IP: [47.73.108.139] X-StarScan-Received: X-StarScan-Version: 9.4.19; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20569 invoked from network); 13 Jun 2017 11:03:13 -0000 Received: from vgdpm13vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.139) by server-3.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 13 Jun 2017 11:03:13 -0000 Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 13:03:10 +0200 Received: from VOEXC06W.internal.vodafone.com (145.230.101.26) by VOEXH08W.internal.vodafone.com (47.73.211.212) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 13:03:09 +0200 Received: from VOEXC19W.internal.vodafone.com (145.230.103.124) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 13 Jun 2017 13:03:09 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.50]) by VOEXC19W.internal.vodafone.com ([145.230.103.124]) with mapi id 14.03.0352.000; Tue, 13 Jun 2017 13:03:07 +0200 From: "Dawes, Peter, Vodafone Group" To: =?iso-8859-1?Q?J=F6rgen_Axell?= , Paul Kyzivat , "insipid@ietf.org" CC: "Arun Arunachalam (carunach) (carunach@cisco.com)" Thread-Topic: [Insipid] draft-ietf-insipid-logme-marking-07 Thread-Index: AdLeAvRBRs63oXisSya0OWmk/rHn6AAAL5VwAAv98YAAu2lFgAC/ZKOQ Date: Tue, 13 Jun 2017 11:03:07 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15B08AC@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15977A9@VOEXM31W.internal.vodafone.com> <19bd71c8-e74c-4e71-f5ed-a3fd77ffb9b0@alum.mit.edu> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:05:20 -0000 Hello Paul, J=F6rgen, Thanks very much for the reviews which uncovered a number of areas that can= be improved! I have given some responses in-line below but I didn't includ= e the complete suggested revised text as some of it is long and might be di= fficult to follow outside the context of draft. If I didn't make an explici= t response (e.g. on editorials) then it means I agree with the comment :-) We would very much welcome further reviews from anyone else who has time to= read through the draft, but I wanted to give some responses now because a = lot of points have been raised already.=20 Thanks and regards, Peter =20 > -----Original Message----- > From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of J=F6rgen Axe= ll > Sent: 09 June 2017 16:07 > To: Paul Kyzivat; insipid@ietf.org > Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07 >=20 > Hi, >=20 > This is my review on this draft, trying to not duplicate Paul's comments: >=20 > 4.1 says "log me" header in one place, change to "log me" marker terminol= ogy > "header" versus "header field" seems inconsistent (Peter) Agreed, we will correct to "log me marker" and "header field" throu= ghout.=20 >=20 > 4.2: > The third sentence (starting with 'The "log me" marker...') seems a bit > standalone. I think the text could have a condition e.g.: "If a "log me" = marker is > received by a user agent not supporting "log me" marking the user agent d= oes > not echo the "log me" marker in responses." (Peter) We will re-word this sentence. > I think the last bullet should say that the originating SIP intermediary = echoes > **received** "log me" markers in responses to in-dialog requests. As the = text is > now I get a bit uncertain if the node always puts in a "log me" marker in= the > response. If so it would be against the recommendation in 5.1. (Peter) We will re-word this sentence. >=20 > 4.2.2.2.1 Editorial: Proxy-1-->Proxy 1 >=20 > 4.2.2.2.2 first line has in In. > Below figure 4 F6, remove "the" from "the Alice's". >=20 > Regards, > J=F6rgen >=20 > -----Original Message----- > From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 05 June 2017 23:41 > To: insipid@ietf.org > Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07 >=20 > I have reviewed the -07 version. This time I couldn't do it just by looki= ng at the > diff, so I did read it end to end. I do have a number of > comments: >=20 > * Terminology: >=20 > Some places use "test case identifier" while others use "test identifier"= . Please > pick one term and stick to it. Or perhaps the special term can be abandon= ed > altogether by simply using Session-ID. (Peter) We will use "test case identifier" throughout.=20 >=20 > * Section 3.1: >=20 > Example needs to use domain names taken from domains example.com or > example.org. >=20 > * Section 3.7: >=20 > It would be helpful to include some message detail for F1, F2 and F3. It = doesn't > have to be complete, but should show the Session-ID header field. (Peter) We will re-write the example in section 3.7 based on call transfer = in RFC 5589. The revised example will include more message details to make = it clearer that "log me" marking always begins with the initial SIP request= from the originating user agent and also to show how the local-uuid compon= ent of the Session-ID header field value is used as the test case identifie= r. =20 The fact "log me" marking always begins with the initial SIP request also r= elates to the comment below on section 5.2.=20 >=20 > * Section 4.1: >=20 > A couple of important things seem to have been left out of the list > principles: >=20 > - the originating UA should itself log all the requests in the dialog. >=20 > - the terminating UA should also log in-dialog requests that it marks and= sends, > and the corresponding responses. >=20 > (This could be simplified by simply saying that both UAs should log all m= essages > in the dialog.) (Peter) We will revise the list of principles so that each bullet states a = single principle and add a bullet stating that the terminating UA itself lo= gs any in-dialog SIP requests that it sends. It will be clearer if we also = make the list of principles for user agents parallel to the corresponding l= is for intermediaries acting on behalf of user agents. >=20 > * Section 4.2: >=20 > Similar comment to that for 4.1. >=20 > * Section 4.2.1: >=20 > IMO what is written in this section and subsections is both incomplete an= d > overly complex. >=20 > ISTM that this can be greatly simplified: >=20 > - a dialog on one "side" of the B2BUA may or may not be coupled to a rela= ted > dialog on the other "side" for logme purposes. >=20 > - by default related dialogs on the two sides are coupled. In cases where= the > B2BUA is more complex some related dialogs might not be coupled. (You can > say as much or as little as you want about this.) >=20 > - if a dialog on one side is logme marked then a coupled dialog on the ot= her > side must also be so marked. This affects all messages in both dialogs. >=20 (Peter) We will simplify section 4.2.1 based on this suggested text (thanks= !) but I think it's useful to still say how they relate to the named B2BUA = types in the taxonomy in RFC 7092. > * Section 4.2.2.2.1: >=20 > The actions are labeled by message id (Fn), but those for F2 and F3 don't > correspond to the corresponding message. Also you missed a message. I thi= nk > you mean: >=20 > F1 - Alice's UA does not insert a "log me" marker in the dialog- > creating INVITE request F1. Nevertheless, Proxy 1 is configured to > detect the start of logging. Proxy 1 logs INVITE request F1 and > maintains state that this dialog is being logged. >=20 > F5 - Proxy 1 inserts a "log me" marker in INVITE request F5 before > forwarding it to Proxy 2. >=20 > F16 - Proxy 1 inserts a "log me" marker in ACK request F16 before > forwarding it to Proxy 2). >=20 > F22 - Proxy 1 inserts a "log me" marker in 200 response F22 before > forwarding it to Proxy 2. >=20 (Peter) Thanks, we will correct the numbering. Also I think it will help to= add a few more requests/responses to the description (e.g. the 100 respons= e and the in-dialog BYE sent by Bob ). > Also, should Proxy 1 also be inserting a "log me" marker into F6, F11, F1= 4, and > F20? In this topology they will probably be ignored by Alice, but maybe t= here > can be cases where they are not. (Peter) I think Proxy 1 should be inserting a "log me" marker into F6. For = F11, F14, and F20, Bob's UA should have echoed (responses F11, F14) or inse= rted (BYE request F20) the "log me" marker so we will make that clear.=20 >=20 > * Section 4.2.2.2.3: >=20 > You forgot to mention: >=20 > F8 - Proxy 2 inserts a "log me" marker in the 100 response it > sends to Proxy 1. (Peter) Agree. >=20 > * Section 4.2.2.2.4: >=20 > This section says: >=20 > In Figure 6 below Proxy 2 removes "log me" marking from all SIP > requests and responses entering network B. Proxy 1 therefore > maintains state of which dialogs are being "log me" marked in order > to "log me" mark all requests and responses that it receives from > Proxy 2. >=20 > The "therefore" in this doesn't make sense. IMO you can't expect that Pro= xy 1 > knows a priori that Proxy 2 will do that and hence maintain state. Rather= , I > think you need to assume that Proxy 1 maintains state in any case, and th= en > uses it to mark things if it observes that they haven't been marked alrea= dy. So I > suggest: >=20 > In Figure 6 below Proxy 2 removes "log me" marking from all SIP > requests and responses entering network B. Proxy 1 maintains > the marking state of the dialog. When it observes that requests and > responses received from Proxy 2 are not marked it adds the > marking. >=20 (Peter) We will correct the wording.=20 > However this seems to be in conflict with section 5.1. I don't know how t= o > reconcile those. (Peter) I don't think that the text is in conflict with section 5.1, but I = could have misunderstood the point. Section 5.1 describes terminating proxi= es, i.e. Proxy 2. Proxy 2 will not see "log me" marking on e.g. 180 F9 but = it will not be expecting it since it removed the marking itself. Proxy 1 is= on the originating side so section 5.1 does not apply.=20 >=20 > * Section 5.2: >=20 > I question this. Consider a 3PCC case - Alice calls Bob via a B2BUA, then= the > B2BUA reconnects Alice to Charlie. It may turn out that Charlie has logme > marking enabled. So this will appear during the dialog establishment with > Charlie, but it will appear to be mid-dialog to Alice. I think you do wan= t to log in > this case. >=20 I think the rule about "log me" marking that begins mid-dialog being an err= or is still OK but I might have mis-understood. Looking at the 3PCC example= in RFC 3665 section 3.6 (below), "log me" marking must begin at INVITE F1.= Bob will see INVITE F5 but this is not mid-dialog since as far as Bob is c= oncerned INVITE F5 is the dialog-creating request.=20 3.6. Session via Redirect and Proxy Servers with SDP in ACK Alice Redirect Server Proxy 3 Bob | | | | | INVITE F1 | | | |--------------->| | | | 302 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE F4 | | |-------------------------------->| INVITE F5 | | 100 F6 |--------------->| |<--------------------------------| 180 F7 | | 180 F8 |<---------------| |<--------------------------------| | | | 200 F9 | | 200 F10 |<---------------| |<--------------------------------| | | ACK F11 | | |-------------------------------->| ACK F12 | | |--------------->| | Both Way RTP Media | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D>| | | BYE F13 | | BYE F14 |<---------------| |<--------------------------------| | | 200 F15 | | |-------------------------------->| 200 F16 | | |--------------->| | | | In this scenario, Alice places a call to Bob using first a Redirect server then a Proxy Server. The INVITE message is first sent to the Redirect Server. The Server returns a 302 Moved Temporarily response (F2) containing a Contact header with Bob's current SIP address. Alice then generates a new INVITE and sends to Bob via the Proxy Server and the call proceeds normally. In this example, no SDP is present in the INVITE, so the SDP is carried in the ACK message. The call is terminated when Bob sends a BYE message. > * Section 7: >=20 > I suggest simplifying the ABNF as follows: >=20 > sess-id-param =3D/ logme-param >=20 > logme-param =3D "logme" >=20 (Peter) The simpler the better. Does this still allow the remote parameter = and the logme parameter to appear together? Does it retain the extensibilit= y of Session-ID indicated by generic-param? > I expect that issues may still be raised regarding security and privacy, = but I'm > not an expert on that stuff and will leave it to others. >=20 > Thanks, > Paul >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Wed Jun 14 12:18:42 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDF912EAEE; Wed, 14 Jun 2017 12:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrIUg4mbx4Ap; Wed, 14 Jun 2017 12:18:38 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0099.outbound.protection.outlook.com [104.47.2.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02AF12943D; Wed, 14 Jun 2017 12:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xc7laf7IMDdc9pXlhkK1BHAUKlzaTN+hKdFR8Lx0oWA=; b=GPXc3hCP7e0x3uIlaBpsnxknjB7PHSgsJVmBUddggeE1x2aUYFEozSNtWsQbHB4u0YmYZX4DTuYHGjniXEpEpkTFluxwUsPUEjfpgI98CxP72/3KTuDufPadPebIpoLk+5rAQbp5BM62CoA44/XsAqRJdO8t3/ZmddU4ojfVweU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia-bell-labs.com; Received: from [135.185.237.246] (135.245.20.22) by DB5PR07MB0853.eurprd07.prod.outlook.com (2a01:111:e400:5106::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.10; Wed, 14 Jun 2017 19:18:31 +0000 To: insipid@ietf.org Cc: draft-ietf-insipid-logme-marking@ietf.org From: "Vijay K. Gurbani" Organization: Bell Laboratories, Nokia Networks Message-ID: <077dae6c-8d9f-fb26-c18f-749e529b395d@nokia-bell-labs.com> Date: Wed, 14 Jun 2017 14:18:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [135.245.20.22] X-ClientProxiedBy: MWHPR17CA0075.namprd17.prod.outlook.com (2603:10b6:300:c2::13) To DB5PR07MB0853.eurprd07.prod.outlook.com (2a01:111:e400:5106::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fa936e49-36a0-46af-8c92-08d4b35a25a0 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:DB5PR07MB0853; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0853; 3:Roh1mNJcAB9ckCEXZ8Andy1vHrELYOhn4js9iN7h0AeMZsZ/nBpjWP6Nop8YrC4vFVZtoC32yP5AjFJ4ClJ10kgsdjCb1v78CcMqr73uvQflwEPPLqlwLQvGLY60Kbi3W3l7hPIPsYLplvCJ1OWxbV/XNJyQg7OjszVjNeT/6j+GzrsdZv9jjZDCdKVDe30xGstrIsgFvvwT4vlRGS1N785dqB76quL0ZuMxHwVZ2/z1FHMnOJQ9L4h4ayKZPql/pbjCi24jTGaMz/Ntngm6unh20vAf+E/mE0TCNZ5mHYjpbDrPGz1ts1S3+jbPiqm7Pq/UbFFxuqAfg9yIcqEZ34laKhGd3ei0ty1Az0YX9n0=; 25:I82N8u6qvM8W/4D2kgWUvrtq8Ad4H1MiVUAg48F3LEdjDJJqKWGoqvzcA6/RoRq7kNFJtwzzN5Mw0/D5QyQNCed/fAlX9tBHBqq1LK/Mczkh1wehkq+jnZxEh2i+nqodV3iMCc7PNFeKYiTLToIP2TeZ6DC3uyoAeinCaOCH8NBNIb3Z70FRvjCw8qDizNyZWrZ8yH5e0omJy8k8vGaemm6P7N308u7AGI0soMMIpg54Lw37ZjwBfHvdtfYa9TdKccOZnN0hPkSyrJOTtNU2LHUpNY495rpL8BUqppZ3JJrUXrZnDIADTWC3cGYZ3S4u/wwGnRm0YXfCjVwuMvzo6CYcV4Ao1bI6vmTE7i+n8bzoEqVFZM1AKy/Fb9m9HHU2zU7MpLQ1adEOhDdSeGVj4SvkWpBc2lXygY3bKWOJZUUlsAIjL54W7MN5hPAA2XyRidfKN6XeqjS6MKX1xW8GS2fWOWzGqvZl8l+mrcVcOWs= X-MS-TrafficTypeDiagnostic: DB5PR07MB0853: X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0853; 31:3fFOrZZRpx2XE45mO2r7tReELyyNtoWYvzaaREBTVzuOtzAMhG3dxCqIxInDPir0oGwRlsChqs1p+Bu1xHVuH/534DdoYYVwdzToW55zh5Gsrodyh6TI0k5809RPlE7O5tyB3cxN6aVlroJap2vHaQoxPqtimOexIlxYvxc0zs1mMn8b1Xgw1XifRdhBot9exdalU9UuD1Ni7DJOIw1n2XiB9zNg5wWGuqC107OsqSonIZrJuF+7NXrQL0bMohxG; 20:7jFc2iAYM3ybyKeRN0c171vUYe22m18XBgxybnPibkW6MEtYaG1WIiTvqPn/xgR7igcEy+KDl0ZIpsWMnwFqwmHf4kP5G2d0bSNkdoLjYFDFO8LHs0du+5XbijQiBdORKmrTEFFYhsPQoTMcesac8/iM9iVcxuk5nV1zUaIydR3XRI2YalRm2OaBAVpZrscDGpWEHE74V/YkgukSFLeeXR2QJObLGvUue7EFYUqPtj/Tkw3X0xTPZ5kFyfu5bKRu2bMgAnKRh5Vbukn9axEomCrp9Glspis1OKD/UeRv8tYYIBB+JSx4kLubQO0a1gg/01yVXQq0HoD68I4/WAUo5O/Q1Ipco8Wk6BhwgHhQFuysm9030CvyhDo9S7skfWHBM7aECiRftQvj1sw/GY0FpQxW0hSc8n5LOG4tviQfm/VdUWX2Cg69NrTyMgRN0MlBxB0JpaBOOyp+ZvVtyh68Miiv6R6KXYa3k0qpZyfRod5+UmVXMIFb2Yu7CSrxGpRH X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0853; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0853; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIwODUzOzQ6M1N5UEwrUjdYUUs3YlJYR05wNGtrT1VNek9V?= =?utf-8?B?b0RQbWkrR1Q0aTJPT3hITmdBeHhnRGF4TGViRkhZckdTR1NkYW52WXZGUThl?= =?utf-8?B?OG8yaXIxQTNvckVraFA1WXRnd0VsQTJLRUo1TGF6WXppN0Q3RFN1dUFFRmJz?= =?utf-8?B?TE11V25EeExKNExra2MxRDVwb3FwQVpORVp1bTRPdzZzVlFuU05vSnhuZ01V?= =?utf-8?B?THQ4OWNqZ1JrRDgrTFcwUXhyTHZzaDNBMzBqSnRkdXRCT0tjVHFNbHh5Slg0?= =?utf-8?B?MUk4eEJMem9RRTBjMzVydFdRdzk4UkN3YmZhdVdvc09uZFRLQ1FRcHlncVZZ?= =?utf-8?B?aUNjczhDZ1RYanZPU3VsbTZvRUx6UThja1hLb3pSWUxQVUhVdnplTVpHRUta?= =?utf-8?B?dlZSRVVxaFRqcTkvd2Flb1Y3SDFaVDZ5VHRnL3VBakJIcjVhRzV3bGtUQ0wz?= =?utf-8?B?Uzd6R3J6U2cyZW5vaHhzeW0vZ2oyTXc3MnlwMVUxVGxPZEFGdzJ5ZVV6V0Ro?= =?utf-8?B?R09EWFlwRUVVc2xPamhLbC9pMGs3UTZYcHhmWWtUV0Z2Yy9MWmZVREJ2eDVQ?= =?utf-8?B?MDJCVm9yUlk5YUlLdVRBL2FZWHhBenZSblc1K0I1TnhWMm92RGRiWGtValhJ?= =?utf-8?B?L056SmxNTDRoQWExSzhPcStqSEs3aEhlV1BSWXY0UUE0QWM4Z05MQ05VTmhZ?= =?utf-8?B?elUvdklvRmdVaEZhWUoxR1FLSzErS0ZIN0NBMzhVWjc3WHNrVk5ucUtRZUo3?= =?utf-8?B?TjV6ZXdNRXhqRXBZQnVtWWppSUw4ZHZ0UkY4UzdEMnZhejBlM1lNMktkMGkz?= =?utf-8?B?VGRtSGdOMFFHSjE1eVBVQmZENE4xOGRjVmxyQ3VFSWNrRG9zRDJ4ODFXQTE3?= =?utf-8?B?a2hLN1N0ek5YR21QVUJBNldNTjdicGkvNVBvZzRaQ0U4U3grL3o2NG5RNHcy?= =?utf-8?B?YlFZNDhvY0ttTzhxOEhFcmc4MUFTU09sVFAyb1BiMlhhV3dLMFRVWHU4d282?= =?utf-8?B?OGpobTZFNjk0aFdVblJNMFE2WVBaVy9hZERuT1VFNE1Rb0h6NTVuZkN1elQ3?= =?utf-8?B?SmRGbTQ2NkRJOHpBeXNqWG1PL0VrczI4WGRlbnNsSnhTQ3M1QktabmM4OENZ?= =?utf-8?B?YUhNbDdRMnIwemdSakxTR21HKzg5RUkvL3BmTHVzWHIxS0lyZmdCbTJUd29K?= =?utf-8?B?NGFxa05GT1htYzRWaTBBd1BtQTMvOTF2VWpVMG1FdDBtNVNNcHVoQWRLT1Rp?= =?utf-8?B?blJhdHI2MjhZNE5EcUJmYzVpeUJTMCtYWGNDbFFOMVNNOFRnd0xwQjV2Tksr?= =?utf-8?B?NWNad1A4UkVIS3VYRmdOVS84VXVCUk03cUJnZlU1aGRNQ0krWjhOR0FpdEV0?= =?utf-8?B?ZS9aaDdURWRZK2dlWHZEOWI3QU1sRTJYeVF3YnZIc1hOa3Fubk53UUcyL05P?= =?utf-8?B?NUJxaXZPSXBqTHdtbDg4MktaTDhpTTVlUDkwcldaVXEvU1RzYzJlN3lxZytP?= =?utf-8?B?V1pBZU5rd255T0E1Y3pmUnpHeFdvbndZeXpTaGNjYXIyTkE3VkVCRkFVam9F?= =?utf-8?B?RlBlMlRSN1k1L2FKY2o4UURwZExXUT09?= X-Forefront-PRVS: 033857D0BD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39450400003)(39410400002)(39850400002)(39860400002)(39840400002)(39400400002)(252514010)(81166006)(47776003)(65806001)(189998001)(305945005)(25786009)(66066001)(65956001)(551934003)(2361001)(7736002)(8676002)(230783001)(2351001)(230700001)(86362001)(64126003)(450100002)(65826007)(5660300001)(11609785009)(54356999)(31686004)(50986999)(31696002)(42186005)(4326008)(6486002)(53366004)(966005)(4001350100001)(2906002)(53376002)(38730400002)(110136004)(83506001)(6916009)(478600001)(36756003)(49976008)(6666003)(50466002)(3846002)(6306002)(6116002)(33646002)(1720100001)(23676002)(53936002)(78286005)(90052001)(4068875011); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB0853; H:[135.185.237.246]; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIwODUzOzIzOjJXNmE0bDZRR0gzUlM4T3J2cURHbzNvMm91?= =?utf-8?B?WHdpMThwaVNrWTUxWGhNb21OTEdVNUZXY2MyaUErUS9DdHZqMTJKdmxZNS9M?= =?utf-8?B?Y3J6NTJOclB5SDlmOUZpUjJ2MjdMemxIM3RmS0lpOWJKWktZeTdSWXlaOFBU?= =?utf-8?B?NkM2Nkt0NXVzOHlTaFNDRWlmcTBaQXBJTHp6bTFkbEV2azJwKzRWQ3JZZjZF?= =?utf-8?B?ZjZWYmhpc2c0anVZYkFLSExOc1JPemN0dldSK1RCcENvR3RqWXh0TzJMVGRD?= =?utf-8?B?c25QNWQzb3VFUitlSVRXK2FLUUdvdFNPd0ZwOWd4NDVUcStTOFFQQ2d4L3pK?= =?utf-8?B?d0I4ZUFPNUZVOFZ1alorVnZDMnZraWxiS0VzTzVTNUhmQnY4Q3IzS1UrNkVq?= =?utf-8?B?NUhSNkMvTWRNcHVnTEx6c0VESXBiSkJ4eks4TG5sQm5EWHhmL2RhUVFXNkJS?= =?utf-8?B?N0ExZ04zMmtmdTZETFdxelVKTHdpNjRyem41OElPN282Y2pDQkdoUTJ3TkN1?= =?utf-8?B?R3NrbXZjbUtYVjlKZnRObmlBb1FqVEtzK3FKSmNKMDd0RnlqS2R4V2d3SHBs?= =?utf-8?B?MXRhTGFzY3lsT3E5WEp1SlkvbWJ6dCtzZGJ6M2J1MUtxMHBtcjFwZXVQVEY3?= =?utf-8?B?RDRzM2VIQzBWYVNUZWhick9wVzhFSlZta3FFVTdraEY3NHdaU2U0R3hFS2ov?= =?utf-8?B?OS9lY0hNR0NtQkY5ZG1uckdUcDhmMjlXblBQeFJyeXZMM21hUWJLekhwWGJ4?= =?utf-8?B?WGtPYUUvUy9mR0FUdEVlZWd5cmFoQ2ZtYmlyd0M3OEU5ME9Vbm5pVXVjcGhC?= =?utf-8?B?M0NsQVRnbTJBdGFiNm83VkEvNTR2S0hjV1R4N0NxS0lRZENqVVV0RFQrK3pp?= =?utf-8?B?NXNwekp4U01LV2J0VDJtYXdMWlNxVWwrMEx3UUxUWUdxUHIyNG1EWUNBci9X?= =?utf-8?B?c2gydjZPbFFSTHZlQVBZYjEybGNtNVVuSVlQem1tSEw1bXpIeXc5RGpDNllX?= =?utf-8?B?Z0l3OXcvOHR2TE5WRzVGT3RTU0VuRnJUeG1iaERrdmI2SDY2R1FnSmNWdzRX?= =?utf-8?B?dnM4MVpmeFhHUWY1anoybmt3YTdTTkdBbmRXcG9tSzRLZjRqTzg5dzBCdXNz?= =?utf-8?B?SXdIc1hkNkxOZW9uUjEyNmM3Sm5mZmRma09TVGoxbGJIU3YxNU9lY3JvVmE1?= =?utf-8?B?TVVVb2Y2T1Y4T0dqY1hkZnRGRTlrd2VERzR2bUJzUGJHdkJ5dTQyOVU4bC9Q?= =?utf-8?B?aThKMjd2VnRGR3plZEhJVk10VTRMQ2N2T0FkTVZDQmlSaXdNU0NWb2xyUUJs?= =?utf-8?B?L3JTVjd4MnpiNkJjSERyS2w2ejZhSWIyNHBUQ1Nwelp0bWRZWkZRZXprenR0?= =?utf-8?B?VW5YVWxWcExhNDZod1lqV09YRFNrNjBOV282blZQclR5TDBXbW02cmRLallv?= =?utf-8?B?RFN3aVR3dHIydVBLZWlETUREMWVqZVgrZ2FNYWh0T3Vid0tScndjMmVvMzVB?= =?utf-8?B?NVdZcWt2dS9xV2Rmbnp1dDBLSGdYa0xWNkZPeHlGcExiQ3l5S1F2V0R0MVRn?= =?utf-8?B?WUlNWjZXdTVwRU1ZVXVXKzI1QnVNc2lnUWpiZVJzVGZXdEc4eWFiOVJZMTFx?= =?utf-8?B?WC8rZ2FHamlScmM5VlZVb2sxQ0d3QUp5MUdzOFQwUFdqYi9PQmVuYW9yZlVV?= =?utf-8?B?Rk1IeWQ3NWFDeEJYVVVvN2hzZWFVZ0VkaGZPWStyRnZkTzhuTEQ0b3BVczB3?= =?utf-8?B?QUc0TmRUaGdHZDc0RFNJaXZhNVk0amMrdms2aGpoS3pMMmR5djZ3VndVOXRN?= =?utf-8?B?VlNVd1R0UUoxSjUvOXl2Z1FRaHhUV216cW01UU01L1VKRTdjc0JWTStheEZI?= =?utf-8?B?dm82cDdEbExRV1BYVXg1ZVF6MUY4cHpsRkd6K2Z0NkVtWFZja296Y2YwTXhX?= =?utf-8?B?ck5tTWUzK2U5S1ZETi9SQ2FrcTg0MXBtVm5SSEhTKzUvNXI3T0oyUStkVXlY?= =?utf-8?B?SUczVzhiUU90MmhRZmN1WUFidUh2SHE4d3A2bk16TzZMMWhPVEpGdmhUTlVE?= =?utf-8?Q?NYSs=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0853; 6:4wq6Y+xVT0Qphgi2V1SjUXi/pwKWAHgJrGHtmLAFbLBjoAP+adkiwcuD+jYWHr1Xo7/fjYl/70PfZYtBOsfk02B2g3aW955Bm2rbnHhZWd3h2KhTi8l74Wx60PurdTEy8YgB4CFPWsO2lWZKhQGGDkZkuOLBiEgzi4xfK6AjukIsWaPnacJXnG5PYV4/4LdHYNYZoY99tDuheySH0nKuAZ74IsbTsQ1raMx5xJUbC06JURnyjbxTrK6R8igeC0rqG/29RaA+wZ0fT3kQ0TLla+ImgGH3f9ldtKEgB5lF2ac4izMl7uSdhHd2TJBoD9i/9HWAyDqjKyUV7fbxHJp5iKmUWgfGWXoxxjre1A/cX/ZZHM1UkuhZ/8afPVWVQA3jcUHxZNxC6lkMkAU2/6fViFp0MuqQkD4WR/kac+tpnRjVr6RxnI+BltkJ1OdqIDPtzotc28aW55/CrZYp5nxZ+d1uhSfvyCLy6+ZjC69gWcDVffwUX3DEDjLwoJipC1W/lZyfoO9lPhJ1W3PbRWLhAu7YzjYcJCEY4Wh1u9TL/No= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0853; 5:UdhxKCQrIKhd9kit5IzObrTGk5ch6im7NZYQAey0W1zeBQqQn7ejRqamamz87XCLybM84nqOXYn73De+ewEbYB/48O/sYKKB4NOr++HHhQ4czPV3SHcUlAaVV1AhbaMnYoYZjtOW4+nZ3r3mN6i9xijRR4UsKtAsAq3gDj0i4tjSuRawl8BiM9Nw4aKgEe2jJU8GS59P+GayLPV9Edbo5lK7MIcdMRP9jJ15lneGJW6TravGN57/WiPgFZxvL9FKL07tJPDS1kN6gdrekbqFZjTvmAwNrqK5R818hr3oHI6240jkIqro8gtFR/tzVV1nrV6afHP1vJg3j0AaSOjOPVnf99H+73qVU5LCVlLVnfHh74tEA6lOtlwCYqXeC0eXNwVDvzaebKsbo+mOLUMhc9IRQON0VaRUPXREzQpLFKurPXr+r1vK1sazXG2Kf705nqValZZKj9uszdp/iG7vN9YhIQI/+tqi4UtmFDlLpQseoiZCJA+p2a6elHPnVErR; 24:S/gW4WsLWoLdaHK619GVDTd35MRKVTjqys3dNEcIwJG72zff5LqNS4bmrs6XBkc3UB6VKq9Vp6qJ5rlqSP7gl94lXdektYpeT3x+IxoCFMs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0853; 7:7klGo+PXW6LZWxdJzgZ9LJZjSP7dFRby7FDJQZapcW4LXQ2f5+6SCThDgqSdPpnyDL+kBGhyj32ASFlOsSwSTI1f2kWTEzp04OliHdvEtRf4OM0tOUjlLEm3jyU5XspMEq9j+i2xTj51kJdTRSPGc+B2C2vDITbv6lCA8w4XNs3BxYbia1+iPBBB0aOniFty3Yan+BPeVUpv8xafke9+n+L1By2anPxFd1HvV+1Ipo9Sn2h0Yp3FEloextiZjiQgTohg26BRCdqMKs9sh0I4+b+4lejwKM40McY4HS+IrVa6MKouj/y7MKAXvqSQOsoUOBij6uZs4XmtTp+5ocnZ+w== X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jun 2017 19:18:31.5945 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0853 Archived-At: Subject: [Insipid] Review of draft-ietf-insipid-logme-marking-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 19:18:41 -0000 Hello, I was asked by the authors to review draft-ietf-insipid-logme-marking-07. My review is below. Summary: good stuff, but some issues need to be addressed as documented next. MAJOR: - S3.2: So, it appears from the last sentence that "log me" is scoped by the dialogue. If through some configuration, a SIP UA is configured to insert the "logme" parameter, then the UA will continue inserting the parameter for all dialogues created by the UA until configured to stop inserting the parameter, right? If so, then the scope of the "logme" parameter is driven by configuration more than a dialogue. This should be made clear in the text, as there are many places that state that "logme" is scoped to a dialogue (S6.4.5, for instance). I believe this is an important aspect to clarify: Is the "logme" scoped by a dialogue or through configuration, as time limited as that configuration may be? My reading of the draft suggests that the scoping is through configuration, and S6.4.5 appears to support this (in my reading, at least). - S3.4.1: I don't see the relationship between the two sentences. Perhaps simpler to say: When a user device inserts the "log me" marker, the marker MUST be be passed unchanged in the To and From headers across an edge proxy or a B2BUA adjacent to the user device. - S3.4.2: Isn't the second paragraph in conflict with the MUST in S3.1? I know what you are getting at in the second paragraph of S3.4.2 --- providing an escape hatch for pragmatic reasons. However, a strict interpretation would require relaxing one of the MUSTs. Perhaps best to say in S3.1 that: In S3.1, OLD: ... does not introduce any device-specific or user-specific information and MUST be passed unchanged through SIP B2BUAs or other intermediaries. NEW: ... does not introduce any device-specific or user-specific information and MUST be passed unchanged through SIP B2BUAs or other intermediaries. (See Section 3.4.2 where this normative behaviour may be relaxed for intermediaries in an external network.) - S4.2.2.2.1: The F1, F2, and F3 messages do not convey much and just cause confusion. My advice would be to remove F1, F2 and F3 and renumber F4 as F1. Your interest is in showing Proxy-1 inserting "logme" on behalf of Alice, as such showing a INV/407/ACK transaction before the actual proxied INVITE does not convey any additional information besides cause confusion. I would also advise to physically show "logme" or its absence in the messages corresponding to F5. I understand that you may not want to show the entire Session-ID header with the "logme" parameter, but a succinct indication like the one below should suffice: OLD: | | | INVITE F1 | |--------------->| NEW: | | | INVITE F1 | | (logme) | |--------------->| Similarly, if a UAS does not support "logme" and cannot echo it, use something like: OLD: | | | 180 F9 | |<---------------| NEW: | | | 180 F9 | | (no logme) | |<---------------| - S4.2.2.2.2: Same comment as above for F1, F2 and F3. - S4.2.2.2.3: Same comment as above for F1, F2 and F3. MINOR: - S3.5: s/test identifier./test identifier (the local UUID of Session-ID header at the originating device)./ Nits: - Abstract: s/as of interest/as being of interest/ - Abstract: s/regular user agent/normal user agent/ - S1, paragraph 1: s/upgraded regression/upgraded, regression/ - S3.1, paragraph 1: s/for a/in a/ - S3.2, paragraph 1: s/are "log me"/are similarly "log me"/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks Email: vijay.gurbani@nokia-bell-labs.com / vkg@bell-labs.com Web: https://www.bell-labs.com/usr/vijay.gurbani Calendar: http://goo.gl/x3Ogq From nobody Wed Jun 14 14:17:16 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F53129549 for ; Wed, 14 Jun 2017 14:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZeK3ZBzadDX for ; Wed, 14 Jun 2017 14:17:13 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D5412940C for ; Wed, 14 Jun 2017 14:17:13 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-05v.sys.comcast.net with SMTP id LFdSdVtiHzz3dLFf6d8okV; Wed, 14 Jun 2017 21:17:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1497475032; bh=j0p4+vTVPntMa1FWrWyxLTH7JNtYO8fkY5Sa2L0p1FE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=TN6PB2CVlMhCtAMV4VI4tiV2DcIrIkSdTXy9wlUtjGyIldIjrCHMBCtOW7PNXUce0 KPdhzNKkPO242+vL8IrqB1NWqFXCA3EQSKOz+frbx8t1KGEqzOYI13QB6Hy8TIhCSO 5OGvnwNtWlglOmJl1xK6uRtGO8GV/5hkNX0F+VjDY2AAKXgsffUR1bXo4z9ND2Xioa joUvz8KkO7jrKRlzqqyl6rAiVP5SDKUnj10M7HC01slev6i6oAPLBlSTDqwf9gHHeP /kjO15ArLTqByWbjKFhyUE+Y8Dt0P1Hf69pwlghV8yLne6lfC1Tx/GG9ZxRXBZ2pfI w2qP8mxCnsluQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-08v.sys.comcast.net with SMTP id LFf5dNN3QtZO6LFf5dfaNw; Wed, 14 Jun 2017 21:17:12 +0000 To: insipid@ietf.org References: <077dae6c-8d9f-fb26-c18f-749e529b395d@nokia-bell-labs.com> From: Paul Kyzivat Message-ID: Date: Wed, 14 Jun 2017 17:17:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <077dae6c-8d9f-fb26-c18f-749e529b395d@nokia-bell-labs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfL/LQWnE05TxmDef9jLD1Opf21u9Gk2SMVkByGtR/NXwniC9FOpDm+s72/w7s3XajWq7Hov3aaxzfIwr8PG8pdl0f9jOCXnlPn869wOGlKMxUjuTb+M9 /ou1d2qgGCNyV2NKw3/bJpWZLK4H3nrdrs9EKEOYMSUPh6CsnSYVVuQkeaq52/ZAYBuKIAz7M2HI4w== Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 21:17:15 -0000 On 6/14/17 3:18 PM, Vijay K. Gurbani wrote: > Hello, > > I was asked by the authors to review > draft-ietf-insipid-logme-marking-07. My review is below. > > Summary: good stuff, but some issues need to be addressed as documented > next. > > MAJOR: > > - S3.2: So, it appears from the last sentence that "log me" is scoped by > the dialogue. If through some configuration, a SIP UA is configured > to insert the "logme" parameter, then the UA will continue inserting > the parameter for all dialogues created by the UA until configured to > stop inserting the parameter, right? > > If so, then the scope of the "logme" parameter is driven by > configuration more than a dialogue. This should be made clear in the > text, as there are many places that state that "logme" is scoped to a > dialogue (S6.4.5, for instance). > > I believe this is an important aspect to clarify: Is the "logme" > scoped by a dialogue or through configuration, as time limited as that > configuration may be? My reading of the draft suggests that the > scoping is through configuration, and S6.4.5 appears to support this > (in my reading, at least). I'm not an author, so this can be a test of how clear they have been. IIUC, a given logme "session" is dialog scoped. (Though not exactly, since in the presence of B2BUAs it becomes a set of related dialogs.) This is identified by the SessionID. Those entities that did not initiate the logging need to keep state for that duration. And of course this then is tied to the resulting logs. Some entities may also have some other state that causes them to initiate logging "sessions". The duration of that state is undefined. Now the authors can say if I got it right. Thanks, Paul From nobody Thu Jun 15 03:30:24 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4FB129AEB for ; Thu, 15 Jun 2017 03:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AsNrt_l21Da for ; Thu, 15 Jun 2017 03:30:20 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A160129ADA for ; Thu, 15 Jun 2017 03:30:19 -0700 (PDT) Received: from [195.245.230.51] by server-9.bemta-3.messagelabs.com id C9/BD-26749-9B162495; Thu, 15 Jun 2017 10:30:17 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRWlGSWpSXmKPExsWi75nTo7sz0Sn S4OJrKYvGB9PYLebff8Zk8eBHL5sDs8eU3xtZPSY/nsPosWTJT6YA5ijWzLyk/IoE1ow/f7az F7RIVlxfPpupgbFfpIuRi0NIYDujxIH+qywQzmFGiWXr+hCczQfmM0M4mxglOp89Z+xi5OBgE 7CXmLEnpouRk0NEIFhiy8Ol7CA2s4C3xNJtS5lBbGEBF4kDlyYxgZSLCLhKvL1RDWFaSbzYrQ pSwSKgKrHo2QkWEJtXIFTi3osusE4hgSqJz8/uMYLYnECLlm49ygRiMwrISnxpXM0MsUlc4ta T+WBxCQEBiSV7zjND2KISLx//Y4Wo0ZFYsPsTG4StLbFs4WtmiF2CEidnPmGB2KUq8W/lIqYJ jGKzkIydhaR9FpL2WUjaFzCyrGLUKE4tKkst0jUy1UsqykzPKMlNzMzRNTQw1stNLS5OTE/NS Uwq1kvOz93ECIy3egYGxh2MrSf8DjFKcjApifLyyzlFCvEl5adUZiQWZ8QXleakFh9ilOHgUJ Lg3ZAAlBMsSk1PrUjLzAFGPkxagoNHSYS3IB4ozVtckJhbnJkOkTrFqCglznsIpE8AJJFRmgf XBks2lxhlpYR5GRkYGIR4ClKLcjNLUOVfMYpzMCoJ8x4BmcKTmVcCN/0V0GImoMVBFxxAFpck IqSkGhjn3Vtd2u0sLtS0Q6vNWqB5wrMmYSnxqfIS3Hu78v9b7fvZti9VIdg8cmbaHa/2fRo9E n6aZSvPfd7zb/JSO5PrJs/ZV3p4OjxOFPAIeLZKILmAZY2Rzqfzy1RPMx/n2i48//N1CzfxPB HjJll15sbeh6n604z31a2+vMlUrbDvIPflR4fWvlViKc5INNRiLipOBADpmXF2MQMAAA== X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-11.tower-33.messagelabs.com!1497522617!99954443!1 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.4.19; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14030 invoked from network); 15 Jun 2017 10:30:17 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe04hw.internal.vodafone.com) (47.73.108.140) by server-11.tower-33.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Jun 2017 10:30:17 -0000 Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Jun 2017 12:30:13 +0200 Received: from VOEXC06W.internal.vodafone.com (145.230.101.26) by VOEXH06W.internal.vodafone.com (47.73.211.204) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Jun 2017 12:30:12 +0200 Received: from VOEXC17W.internal.vodafone.com (145.230.101.19) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 15 Jun 2017 12:30:12 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.50]) by voexc17w.internal.vodafone.com ([145.230.101.19]) with mapi id 14.03.0352.000; Thu, 15 Jun 2017 12:30:11 +0200 From: "Dawes, Peter, Vodafone Group" To: Paul Kyzivat , "insipid@ietf.org" CC: "Arun Arunachalam (carunach) (carunach@cisco.com)" Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-marking-07 Thread-Index: AQHS5UMMAPKNYGXfF0SXCMdcYfdsIKIkux6AgAD5WQA= Date: Thu, 15 Jun 2017 10:30:09 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15B75F3@VOEXM31W.internal.vodafone.com> References: <077dae6c-8d9f-fb26-c18f-749e529b395d@nokia-bell-labs.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 10:30:23 -0000 Hello Vijay, Paul, Paul's summary is correct and the review comment from Vijay indicates that = section 3.2 needs to be clearer on configuration vs. per-dialog scope of "l= og me" marking. An example of configuration is that a service provider might have a test te= rminal programmed to run through a set of SIP sessions (call, call re-direc= ted at set up, call transfer) and this terminal would be configured to "log= me" mark all of them. An example of per-dialog scope is a SIP terminating = user agent, which needs to be aware that a dialog is being "log me" marked = (i.e. it needs to be stateful) in order to mark any in-dialog requests that= it sends (e.g. BYE). Such a terminating UA knows that when the dialog ends= it can close its signalling log for that dialog and stop marking requests = that it sends. Such a user agent does not use configuration to perform "log= me" marking. We will clarify S3.2 in the next revision.=20 Regards, Peter > -----Original Message----- > From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 14 June 2017 22:17 > To: insipid@ietf.org > Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07 >=20 > On 6/14/17 3:18 PM, Vijay K. Gurbani wrote: > > Hello, > > > > I was asked by the authors to review > > draft-ietf-insipid-logme-marking-07. My review is below. > > > > Summary: good stuff, but some issues need to be addressed as > > documented next. > > > > MAJOR: > > > > - S3.2: So, it appears from the last sentence that "log me" is scoped b= y > > the dialogue. If through some configuration, a SIP UA is configured > > to insert the "logme" parameter, then the UA will continue inserting > > the parameter for all dialogues created by the UA until configured t= o > > stop inserting the parameter, right? > > > > If so, then the scope of the "logme" parameter is driven by > > configuration more than a dialogue. This should be made clear in th= e > > text, as there are many places that state that "logme" is scoped to = a > > dialogue (S6.4.5, for instance). > > > > I believe this is an important aspect to clarify: Is the "logme" > > scoped by a dialogue or through configuration, as time limited as th= at > > configuration may be? My reading of the draft suggests that the > > scoping is through configuration, and S6.4.5 appears to support this > > (in my reading, at least). >=20 > I'm not an author, so this can be a test of how clear they have been. >=20 > IIUC, a given logme "session" is dialog scoped. (Though not exactly, sinc= e in > the presence of B2BUAs it becomes a set of related dialogs.) This is iden= tified > by the SessionID. Those entities that did not initiate the logging need t= o keep > state for that duration. And of course this then is tied to the resulting= logs. >=20 > Some entities may also have some other state that causes them to initiate > logging "sessions". The duration of that state is undefined. >=20 > Now the authors can say if I got it right. >=20 > Thanks, > Paul >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Thu Jun 15 05:59:48 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461F0129C6E for ; Thu, 15 Jun 2017 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOq5jr9NL3OQ for ; Thu, 15 Jun 2017 05:59:36 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0138.outbound.protection.outlook.com [104.47.0.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C531294E2 for ; Thu, 15 Jun 2017 05:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nIdTYihdhOcP093m+M1r0a052cx9j0ykJlA2ZPQb38k=; b=PxBY36TcELwnICA1+8i7la7wqKH8AddH+vIAsTgMGSW8lYDk+aE5FSc8/x6OYa4mymgmKGjeNWr8ERokSO8RfE914NidOzCDuxPztw0/Sr/eGMQlf3Bb0ugVjXeFatnU9OR+USs/8jxFRrOIms9D/ioDg1Akn4ClHOho36Gk1/E= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nokia-bell-labs.com; Received: from [135.185.237.246] (135.245.20.22) by VI1PR07MB0864.eurprd07.prod.outlook.com (2a01:111:e400:508f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Thu, 15 Jun 2017 12:59:31 +0000 To: "Dawes, Peter, Vodafone Group" , Paul Kyzivat Cc: "insipid@ietf.org" , "Arun Arunachalam (carunach) (carunach@cisco.com)" References: <077dae6c-8d9f-fb26-c18f-749e529b395d@nokia-bell-labs.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15B75F3@VOEXM31W.internal.vodafone.com> From: "Vijay K. Gurbani" Organization: Bell Laboratories, Nokia Networks Message-ID: Date: Thu, 15 Jun 2017 07:59:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15B75F3@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [135.245.20.22] X-ClientProxiedBy: DM5PR1401CA0019.namprd14.prod.outlook.com (2603:10b6:4:4a::29) To VI1PR07MB0864.eurprd07.prod.outlook.com (2a01:111:e400:508f::18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b42ab4e4-f7cb-47e2-cd17-08d4b3ee5e1a X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:VI1PR07MB0864; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0864; 3:DRDsWT1si7hylYBhXTPRyjvzDSTs0oU6VS7zaOwnM148rLTYS/BtDZJFp/0UVfVaqZhQWKEpIrGWtRY3lcqDh3Ysag/KrgsHreJQOaYLjeKwqMLNppJodJTsceNI48XA+aGuAtJffOnd4rFh7yQVeFwXYdrYZF7wIR/+vJNvS+CGMJAUjxkpAYdD0WS1UdxmD9tyPBuuti66bWUIzgckt7JcN6jyNYYB3x2k4W6UeEgo3nynbS3bKL0jyvnGvW/E0DE7QjsZPQJo4K+t59ha05mPlj9bLptcOcqjm0F4j9Nhw3U8ntk5Yw5rTECh6vJHt5JKH+4CFir7SwAVMAYf9Q9vRr+qRzpSRSgITmkekn0= X-MS-TrafficTypeDiagnostic: VI1PR07MB0864: X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0864; 25:oBi00hfMz6rpsraK8oom9v1eYXr/wOtKST/quahERD9pa+LnT0cMonZC+VeUwbMqbyZrk0L6IFLIeumIXITAmqitt62OhTUBN5DK68Bnf+3xNly2htHZZC0lpiWbQhkiD6+oO5dvxpwsa/7BqbVphchMS3Odv62K7WN9376UJRUuvN7mK9X/8n302no+J72vXmS/2kcRkMDm4wb9eSp4pUt4/Lzw9nih6RMhZJdRtlpK+N67CegWxgeZR2r7Q6dOvJ0JQVMr1IPlVl7syV/eM2aSpDssBCoomUKf3W3gk+JHbHL/1J9tLIwVJYREBhL1if8i5FyOCrk2FvyAarsto8wT+PmX+x8plAVhPt0R9qPVcwnbnCs/4cv+GqjlHSivc6hFLQkjH8X7zK1wRr3EWs3/RVSRB+NtBkdeEM2g74QOD89Ma1+4Ie6LVcDlP0jkgVZZKIzoVrV5UNDvJ1VasQ4xZK3k5NESf86QzgQr+rvdlFX+ZX/DjlztiDye6b1O2jhu//4KAmxMaojhYd3V4aDALOI4jigxMIhhiRPcWzD85TjSbhzVYefbp7sbCk1zYhsRAue6LcF8jpX76yHqXUD2pMn8Aw+FscxWONUdSFIbr9hNtiGsillnCQRDnzV29bLZ0kR7XEt4PEW0qyUranhwPCJzMs5HpS2IjANTCPVSiWW0zl3Krmtjcq3cSns4WHwGHkv+k73xe2rNKKI2KvvqYT6bxrIBXhfpeWtjNIL0cX+PU35NJUNkhRmpbkQEDg5OIsBCYNoY+SUSxYwuCqpa/6vH67W276gbIDmtSCw6N2CAugMY+yT29t5IpMfHrubGDK5o15MkOkPCaL/94xgdoHu6K/45Ctxs/eo4StJpXI+qY7hgcIbUwJTuHUg2OwrRrlegfkMQropVX/w96A8bYauYhmKV7hrQKxW5mVk= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0864; 31:QZeZaONs/4ok3djiMp8sQOdBm0zuTUqkdEPk93N0EOxW9lIfJ5VIe7kTLXMH1Lk6zqcFas+NLkives768d5mvitXhLUOQjCUFV0P1gcSW4SGYDA1TYXb6R7OC2d89wOx6/fGZw42k0x11hIMifqiU7ECemX7DMzRStSES6stD1nJwByhn2uNHoMngLpRd6z1ZJ3TGaSReKjhkEwzqYvlXcrhrhQdq1dqpyk6rZ37GrJ3Ho7D7rTvRd7Xbg9wy2YYmW42pqtH3lK5Nhx+DjrC6+EIvdhTq2/AWB1mim4Jr67njpHo4yjHBdXaWumtdQcfWm6SrXTLpKIQXI1FGrw1J8hIkICVN1DPvAjb1ep3LHlhv4b7MNDYxra7Az+CfkONe6NEKNdWSTC+VonGoyE+6BbSUHAqXXFi1rqeQ6Lfrlna+3ctsq1n4flVYANVht5rB0DAaDKTxAuuahrzVIT7zepq1Cb9gst/1QXVt4d1Io7trD4zQEouTtHEMcL84CAeuFPKdFBJNuroAVUdLMcLFll4BQFK+QPMtRwGz/EtnmYOIijFhTHIvIF91mtCpWNHHN7LZz5h0OcluOpENMxCVRqi6IDHK/4xsyJEa1lKYZOmkaprY1ZJfhPpdNDS8hUSb3UJufVRo1Bm+cTygw4t9QOcPmFM3YOc2jSAzSFx83BILGSs2oyvx2AZcO/gCvhK7wEBuy++n6lnpWaSk1AHVg== X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0864; 20:sfnwPRXWexa6SqUvcFg2XV3X7PUFqqc8QqXiJ8nmlmamSke6mwEjwLkeIT+OHPzXmWuYQZt4I8OMTuFe74OrnfAlTZMY39ebgWELYP3f1BK/EuPMVge439YaNGnvg5F4g0vRfO05/URNZz/2wrYX8qb59bzLsXzCI5Z/RPNZLgQthPev6//j0H0pIgq3zUbH0JqcbgJIpNqZCuUF6nIP6qitNaHekXDfrnpyhhoAFu/I5igCekuQBWiEWxX7fYesWJ02kVeq1hKqA0dn3LW2Fg3KhhpfZunpUuIN3jcpD7WCqqFs6k7SjEjhCbArjyMsNSH0Izh03xWHUNUjZGijtxyMOu3yXHPmTVWWUHCGl+2erTkyiSPeFWxDt2hODXETCT46CGzreLfLyWXWZNu0BJrohLCUe9+4DoleKUJ+KZrej0y+nQcyAfNQsZOcW/QIhFv/9aM1zddKfS9PELipKlrmh8TXuw7SXJA5GLsmAF2ecmvR22PwEu4QTsZJhZ5U X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB0864; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB0864; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIwODY0OzQ6Qmx2UG9GcXRVck96ckVMOWJ3OFQ0b0tsV2FM?= =?utf-8?B?WlFxcHdFSDlTZFNaZnByRnM4Y2l5dnRJYmxYYmtqTjVMUzRWR1c1dmJwOE92?= =?utf-8?B?dUU2RGtJU004c1Z4TXorUHovYTVuUUc0Tk1EYkN0dTc2cy85VzFPdGxLT29J?= =?utf-8?B?cVh5M29QUmlCUlNzUitodGcvZzNSeHFLcEdGMmFEdU93Ni9JZGpYOXFleUJS?= =?utf-8?B?bkRGKy9BTXRQeUg4N3dkNFdxT1FPOEMwVUIrUmxSeXJDMzYraFVFNVllSWxm?= =?utf-8?B?d2w2U2xTOTk4bjliL3NBTWQ0aUhXTVdzTS9NdGpFT1E4YU1samEzdDVXOE51?= =?utf-8?B?cEN6ZnVOWUVBblFwTE5OYS9yRmZPOXhSUUcxUnVzUVRvNW5pT3E1N0NLQXkv?= =?utf-8?B?VHZqVHF1ZlVHUmhkVFY1aXZ6c08wQnVyWmFLeHlFc29KZ2pJUE1sL2o1UVQr?= =?utf-8?B?TmNsU2JCVVdvTWhaYnNPRVRPbmdpdk9YVXdJVnY3M2xDajB4amJuWi96N0Jo?= =?utf-8?B?dzhRRUtJUDNTVVRsRUc3Sk9rRFMxOWwwL1FnWnR0T21pSnRZLzVwbWE1ZldO?= =?utf-8?B?STlzRDMzTmJIYVNDcVUwVzQvN2JFdVlJY0t0dVl6Z3FVcFlpRWRBRzRiajlK?= =?utf-8?B?aGRPRXowZ2JOZThHbmIwMlRZWlNIcUwwS0Z0NXJwQWZsTDR2bDEyWXluWFlQ?= =?utf-8?B?RHVJYzhVckhDdVdLOVZ5b3U0UzFVOG9nZWZLL05DVzR6QU42ZTZPL3Y4SW51?= =?utf-8?B?eUdaVzBSOVU1dzlvNms4ajJOT3hiYUVURjdTd1VudEc2ajV5dkNYdlJJbldH?= =?utf-8?B?YXN2dXN0NGV0TndkMHNacW9iV2FVN0trOTVhTlV4YmdiNWFoTTZwWGdRNS9l?= =?utf-8?B?Q2dES2dOeUF1MEZuNS9NVnlFWUR3N01HMmVEUXcwaTd5T1BtZ2FKTy8vb01v?= =?utf-8?B?enVRY20wYVZuVmRua0xsT0JrWFVkblpoQUVReU5HUW93OEZSNlZuSTE0WTBH?= =?utf-8?B?R0xZL0ZKYU9NdWpJL2pXNk9SdDRVV2Z3SW12RThTN3lIZXlGb1JuYThwQVBo?= =?utf-8?B?V0VmdEJ0KzY5TSs0V0Q1L29uU215Qm9wR3JpTFVJaGVaSjNkV1grbkxCa2Zx?= =?utf-8?B?ZUp2QWVnMzBRSEU2UGhaZThGSzNlWmpLakpDRmgzZDR3OUlFTk8rV2JTV09a?= =?utf-8?B?SVRrN21oZ2VhVWZZOFdXRmw2QkpiOUo3V1oyNU0wajhUOUFMUlRXWWVXMXZx?= =?utf-8?B?Ymc0aHlIRmMrVmVGUmN0bkp5OXJNTk1WODhVUm1acnVHNEJDT2gwNzFLS2dx?= =?utf-8?B?L09jVCtHZHVOSTBFWTY0VnQ4aVl6Y090Tm1DSWFvRXdtRzNXV0ZHQmlYT0Nt?= =?utf-8?B?Nzl0eDQrc25vSEc2cDJJclFLdUh5UnFGbWRUWXFhR0s5QXJKSDZpVXVBUTBN?= =?utf-8?B?RW01QVR5RUFRMDNRS004Vk1CWWZ2UUY0Q2EzK2tyM3VObUlVajZtemF2akwy?= =?utf-8?B?Ym5jMSt0cWpiOCs1TjJKR24xcTNVWVhYQ3VRMGRQcjRTdmdkVkE4U0V4QjAx?= =?utf-8?B?TllmWUxLZTNlL3U0cGJuRFl6WDlTQT09?= X-Forefront-PRVS: 0339F89554 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39860400002)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(377454003)(252514010)(24454002)(13464003)(31686004)(50986999)(966005)(3846002)(54356999)(76176999)(49976008)(6116002)(6486002)(4326008)(478600001)(53546009)(33646002)(2870700001)(31696002)(36756003)(25786009)(42186005)(23676002)(189998001)(65826007)(81166006)(2906002)(66066001)(230783001)(50466002)(64126003)(11609785009)(65806001)(5660300001)(53936002)(47776003)(8676002)(65956001)(2950100002)(6666003)(1720100001)(83506001)(53366004)(305945005)(54906002)(6306002)(6246003)(345774005)(53376002)(38730400002)(229853002)(7736002)(86362001)(8656002)(8666007)(4001350100001)(78286005)(90052001)(4068875011); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB0864; H:[135.185.237.246]; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIwODY0OzIzOk9hRW9YY0IvZDNka2FuV1FaWHl6VjQ4Q0xB?= =?utf-8?B?Y2pZbDBTMkxuTHRtQzBEY1NjVDdXdCt0WmtJanR6K01SYkdpeThPMTdVS1BN?= =?utf-8?B?TExyZE51azR2bjd5bklXdXJnbHJhRjNjRlVXUmtaVjd6TlhNcGV4RWd0TU1L?= =?utf-8?B?NjVqdUdRUnVrbERSbVpNQzkwcC9oWW5XV3BMVXFKWm5HRU92RjVZUlE1OFhm?= =?utf-8?B?ek5tWmZWdWJpcXJuNFQrQTRqK1hPajVvdXRyR0JaamJPNDJEZjF6RjAyQk82?= =?utf-8?B?WHduNW5STG9pMFZmSGw2enU0Um4xUTkvUjQxTXlRU3NVUjhXT0JGalBSUEtT?= =?utf-8?B?SCtkc291WVhFZGJxam1aMTErN1NJdUYwNG9YWHcwcEU3by9sLy9FWkRvem5E?= =?utf-8?B?S2xCeWdFZEVPU3dxN21pTjYrWG15RWlTYkRjTWlnOFFudktZTDg5YU1VUUNG?= =?utf-8?B?dzFweDRuOE9sT3ZvNUVCYXhzNGdVaWlya3VBNlpwa1JMRUFaS0szWkVnMHdo?= =?utf-8?B?S05Qci9NSG5WYUVDQm5uNzdlZ1ErcmZ2endRRFpwSC9hNU05N0tQbVZoMExs?= =?utf-8?B?azlSUUs1K2JGcHNPVElkemhWK3lJVFR0ZDZKUEJHaExnN3JuRTlnN3BLUGhJ?= =?utf-8?B?Sk4xQ2o5ZnNCaEZPQTBSbGRqM0oySXNpdHh2OG5LQksya0dlMm96Nm1KaHpG?= =?utf-8?B?SWlkRlN4TFNqbmU2clhPTndPQnNja1Z4S3VhM0VJSVRlU24xMVR1cmc1eHB4?= =?utf-8?B?Y2VHbkQvS3o4WEtKdTZ3WFVaZ0JWS3pLMkhzTk9IWThjS0kzbERsR2RaN0gr?= =?utf-8?B?amtSNzdRY1lvRzg0djd1NE5IbUtCQmhKMGlNblpJRkxTb015RTFjRk5EeUM5?= =?utf-8?B?cGpzMHUrUmo5RHI3d0hDNEFVdnF0dmVvN3pzcXF4elU1dFFwaGNqUEpKOXdD?= =?utf-8?B?aEcrUDgzMHM1RmNkNGE5Zy9yMVRLeXJaOVlYVElSZHNMdWY2VmQ5SjJFK2th?= =?utf-8?B?MiszRXV2NSs5S3hhTDVPdjViYU81ZGR4TG9jN3VQZDFEQjNoZDI0ZFYzOWsy?= =?utf-8?B?dU95UmxHNGhyTGYxV2RyKzNQZlV6Q1ZWRHVmMjYzNnBqWmdkZnhUdWpLZnla?= =?utf-8?B?cDkvU1pHSFgrUk9qbmJCU0l6NWxOdUVYaWNUdWNya0Z6TWk0ZTA0Tytwb2Jn?= =?utf-8?B?ZjZtQ0Vqdkc0V3FtREdQcWZCM09UU2Vhc2o2UGttWGgvRGIwNEo5WHBPMngy?= =?utf-8?B?NDhybmVCVnAxemlOZnowNFpJdlJoNEF1REg3aDNkc3NKeHMxdi9URHV5bWo3?= =?utf-8?B?Ykc5TEtpZDZBVkZwTDB0cXdvYzF0WFJPd09LNGczUjRQUVRSNlNhYTZBSXdC?= =?utf-8?B?V2RRS01rVHJydG5seFd2SXVkRi9VdHhuZ3k2a0hJSFFDT2hidmZKb2t5aFBH?= =?utf-8?B?bUFwRGF6SzhzeU5Hd1NLTnRRUjdvZFRDM29jdXV2S09LL0Q1bDFmRUU4bGZT?= =?utf-8?B?enB6cDZSdUlldEZTWEYyZlZEQVZoUWV4MENKZE9sOCtJOEdHZyt4cDZUREor?= =?utf-8?B?Mk5zazBrRGxqY2RCczFMWlVFai9PNFkrRWR1eEpXT3lQcUFVUm5xY01JM0kw?= =?utf-8?B?dmZaaUZraEpLbG40Zmp6b2FucUtkaUdTeTJHQUFvK0xKTGtXOEZSaXdNTDRt?= =?utf-8?B?Nlh1WnRwblNMbkRxZnE2SEd2Wk9KdzM2Y1hBbFhWVDhzbnFZVHlHZ2Nmdkcz?= =?utf-8?B?SWhwNVpLVDZNQWU1Qml0TnlRejByaUlnVjk4QTIxZXhwQnN3NFJlMXNyRXZQ?= =?utf-8?B?c2hKUEVab2IzcXlsZkN4QmxNTk4yR01LcFRTREUwcTQ3L2lydThNS0UwREdS?= =?utf-8?B?cTVpM0ZNanpXcTh2Y1NWaWUzdXFnbkVVTmk0S29YODMvYkxYZ2pST0VXb0VD?= =?utf-8?B?L3g5czZ2Uzh2QUF3bllHZjUrRHUzMUtFZEdOTHVrV0UvYlVEVDlCY08wUEtx?= =?utf-8?B?RlpjbVVrWkxaMlAyS1ByekpDdDhEUDViTEQzMUd1QUhZRTNSN21NYUNlNzR2?= =?utf-8?B?WURYejkzUmlYaVlrakFYaXpnUndubVVRdXVjbkQ2Uk5YMXFzajdwSzJvSEw3?= =?utf-8?B?andyYUVGWFNRVmFYSStqZDY1eWpNUnFCQ0R4YkVtenZzRHppQnNBbFFTQ0dE?= =?utf-8?Q?DpvZYP0VXcZmanFXBMpGjG/04fs+XQ2TTF5lrN28Y0=3D?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIwODY0OzY6UzhLd1NKZ2FONC9kaldXQWpnVzh0eHJ6OEpx?= =?utf-8?B?cFV6WFZZV1dINk9BUS9wZ216QmhCMlFQNFRlelpaeFFsZTJRUUlWSmNqalVG?= =?utf-8?B?SlU1UENtNnhlMHcwWmc5YU9meDlGc0RWamZLeXEyR25CTTZtdU5icHU5S3JC?= =?utf-8?B?Mi9iQysvVHU1RG9sblo0YjM2N3I5d3dJT3U3Qlk0TXB1Z3ROWU51alRpcWtu?= =?utf-8?B?SHZleEVhRndWZjBUSE9sQzk1dmRUUWk4RFE3T2sxK2lyeUlhL3FkWDNDbng0?= =?utf-8?B?VHZLTDN2RXdrckJUSmR6Q3FZOEpoYnhjN2UzcHhFZWlHKzhRZW5hUU9BYTcy?= =?utf-8?B?STFDNzBMalRnYjY5dW5SVEtsam0zaXE3QTdMaHNlRGVhVXpldE5YTVlxc1F2?= =?utf-8?B?OHZyM1NSdU0wc3oxS2FzSFh4d3hWaElla0U4dTFEMDFWbGhEdlVYRWJkUjA2?= =?utf-8?B?NGR5cmlFbnkxZ1greS9ISjMyMmNTRU9qaXdwU0UzUGFTaUdUMFBWWVp4dUdM?= =?utf-8?B?TmM4T0tHczN2bUcza3V0MGQ0WlJUa0o0TlM0MXFvYjdKUkgyNjM3bkNhMTVS?= =?utf-8?B?bTUzc1Q1NGZaU0lRRTRYQ29YM3hQVTRvUlpKNVZXYVVHNk4wKzBLL3dUM0tK?= =?utf-8?B?R3N3VXora3duQzRDalRNRzVjVVBZQ2tSOEFteVlDeUFKUGswMm9uekNqMGp2?= =?utf-8?B?d1RiekNKQ0FETjNtN3lKT3gxU25OOHBGNnZENE1JWlR0WnhEZHpzQ0hUVUx2?= =?utf-8?B?cmxRS0xFd3RiOXdFUnEyMFR6c3FmcW92bnNRV0hvWWlwRkhmYmhqeEdOWnIz?= =?utf-8?B?UzZXdU5TanB2N3RVcmpYZ3k1WWlXeWtPWlFCa0h4NlN4bm1WZmRxZExSVjk4?= =?utf-8?B?bE93VUJ6RnVJQmFxRXF2Y3l0NzNCOWZ2L3hrR00rQWw3STRZaytNQitYUUNl?= =?utf-8?B?T3V5TDEyQzlvRFVLa1RqdFA2WUpVS2pYbXZ2R0ZScVdSOWtkS2ZlZ2FUTVlH?= =?utf-8?B?SUZoeVlweWZrTXpzd1BJOThtRGJDTWxORGtrbHBSc3BIY1BBV3NqQWc1RzI0?= =?utf-8?B?bVh2b0w5UVNMaDlJQkVRUUJZNEgzOUloY3JKcmpMRktLWGpDL0Y5RWZWc0RF?= =?utf-8?B?bUo0eCtlRnFnMU9JaTlLTlN0Smdlc005Zkw2dFYvV3RnTnhtaE1keVlZcklJ?= =?utf-8?B?NncvMmpLc2FtU09BZHh4N3ZTSGUzTUdZOTZ1Smd6SlpUcmtsVWJkR3ptcVRM?= =?utf-8?B?ODVHZFlsSU15T1JPK1hIa0VxRk5kUW5rRG55SDM1VncvQWZWVGtEdGppaWVl?= =?utf-8?B?Unk1YlRmL0UzbktTVjhWM01FT2dWK1BZUUJZaVR2N3Z0Z1RiOXJ1U2lpbTdC?= =?utf-8?Q?QTV/4LX?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0864; 5:PyxeVCwPtjn0ln4RIB6DbtNPOLXZzdXN4mDD9Hof2LQqVhqJHnV3Ayen6EEJgdv48HtvksIlb8FYUHYKtUUMqhw3RuXawtP1Pl8BkorB6G1fMNsRLOOrGuAvHQuq6lmkLvdLwpbZVGF3ZZewvE0l03tC8qTtmJPKKgoMYI9H4ddzXRAW5kLV2oY5Bkl9cIbtHFnILDky4cMLzbsq4H86SzAqQVDUXP5HLnKwuBIqgJOMmUIXWdLdlpmVwGKEK46wi+j/ZI/76vB9/ubIr68nkOF6zBMk0IJiVU15nSXqh04WUWHS6wmUzQVSyoc9qoah8k1hU21V4S+yRqnBvvZUcgOGZfJIC/UvlBqdU5ZrfuQcL3GNLfYG8Zam2Ho6sJZChzOHyfVUh4fxPtvGqAM/d4jg86RvrzNFFx7+SQiHGB3o5QAJ4hheJY46M7Ks5HL6VS1lMPl39Q5kQhuRbMviGTKYsvs7etwzgVU8o9za9p0U9Xt77yKxe+0E+v7DSz33; 24:srVGA+kblfijS0chy7QpuNohSpF2Ny8pidU5EdvwQp2yCPWNqPKz/8s+iRqBrMUv249VhyXx39XujGyEFSBLr2C3Mha2d6iFCvAzxJ/hIk0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0864; 7:lu9ELyh74z8jRj0DPRsrpasgJSSNLhEWk4xoo183OdtBnlTO4Ef3rqe8ssgQUE3BHzQauBhS83V8XqHxtDjCdjYonhlaurNhoYqMF8YVDQoKcVQXF6fpSTSHpAs7bWXpcsODGNPYMrTY5OUYxzbymMOU9VwXtY5DlldPPbNybgWITmqHAktFEXOM8pdKWjIHt9AGmoQ6q6+ziHZM2UUNagqd0PNsXCobZI9agdqguO7D2oke2MD6AErdDSwhfKhDLYB/qCsjApf50elW6/6AkdYnzGQPvJf1anbT96mTW88jv1Qe+iM4xDnppufrTmXPAWXixE862xou9rYk9qYL4+gc2pJfve7GwuqEiPI6XZzSIVxUuP7rNk8t1pYQlqPUAoURitGtHH2kVf3nFGElSEIyCXCcHU6nX6np8nK9mzfOJBNROrUoKvgmqGCaIo9LbRjLfjkrx7p4kNqSA5SYYHIF20nNjVRt5nuYWDejVLffYyArK6Lsw/YIFsD6RHXWJGrTyWMUf//k05yEjfNB//2ZkSyFZifOUCRrwAkcEmeLmiSIsyYoyF5+j/NBGT/O0ml9BCeBe7jK4E0bwjt5lcTONFZWVGZe/NDp/kIWvkm2pFJQ+cQUZsVa/zkxIUrxkqgMuzYFIvPvkdLoZrl7wExO+UArZTqtXtQrgubbhKXcArXo8vNg8MqCQ7BeDVVj9oSOm6a/09+SEtA3KqGsTVBYB1UlJT5EpFES8NVcycoyI7qBfNuKxzqImjfg9KhUADseE/QUfFECWtqEPD2eYEImoK0SNugjmqYokpY9PlU= X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2017 12:59:31.6610 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0864 Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 12:59:40 -0000 Paul, Peter: Thank you for the feedback. Peter, since Paul's recollection is on the spot, it appears to be reasonable to use his text as a starting point. S3.2 can be clarified by replacing the existing paragraph to something like the following (please feel free to discard, edit, or adopt): A user agent or proxy adds a "log me" marker in 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, causing it to maintain state to ensure that all requests and responses in the dialog are "log me" marked. When a user agent or proxy is configured to add a "log me" marker in messages, the duration that the user agent or proxy will be so configured is out of the scope of this document. For instance, the user agent client or proxy could be configured to add a "log me" marker for a certain number of requests, or it could be configured to mark messages with a temporal scope (i.e., 9:00am - 10:00am every day), or it could be configured to mark messages when it encounters a specific "User-Agent" header. On the other hand, when a user agent or proxy detects that a dialog- initiating request is being "log me" marked, the scope of such marking extends to the lifetime of the dialog. In addition, as discussed in Section 3.7, "log me" marked dialogues that create related dialogues (REFER) may transfer the marking to the related dialogues. In such cases, the entire "session", identified by the Session-ID header, is "log me" marked. Thanks, On 06/15/2017 05:30 AM, Dawes, Peter, Vodafone Group wrote: > Hello Vijay, Paul, > Paul's summary is correct and the review comment from Vijay indicates that section 3.2 needs to be clearer on configuration vs. per-dialog scope of "log me" marking. > > An example of configuration is that a service provider might have a test terminal programmed to run through a set of SIP sessions (call, call re-directed at set up, call transfer) and this terminal would be configured to "log me" mark all of them. An example of per-dialog scope is a SIP terminating user agent, which needs to be aware that a dialog is being "log me" marked (i.e. it needs to be stateful) in order to mark any in-dialog requests that it sends (e.g. BYE). Such a terminating UA knows that when the dialog ends it can close its signalling log for that dialog and stop marking requests that it sends. Such a user agent does not use configuration to perform "log me" marking. > > We will clarify S3.2 in the next revision. > > Regards, > Peter > >> -----Original Message----- >> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 14 June 2017 22:17 >> To: insipid@ietf.org >> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07 >> >> On 6/14/17 3:18 PM, Vijay K. Gurbani wrote: >>> Hello, >>> >>> I was asked by the authors to review >>> draft-ietf-insipid-logme-marking-07. My review is below. >>> >>> Summary: good stuff, but some issues need to be addressed as >>> documented next. >>> >>> MAJOR: >>> >>> - S3.2: So, it appears from the last sentence that "log me" is scoped by >>> the dialogue. If through some configuration, a SIP UA is configured >>> to insert the "logme" parameter, then the UA will continue inserting >>> the parameter for all dialogues created by the UA until configured to >>> stop inserting the parameter, right? >>> >>> If so, then the scope of the "logme" parameter is driven by >>> configuration more than a dialogue. This should be made clear in the >>> text, as there are many places that state that "logme" is scoped to a >>> dialogue (S6.4.5, for instance). >>> >>> I believe this is an important aspect to clarify: Is the "logme" >>> scoped by a dialogue or through configuration, as time limited as that >>> configuration may be? My reading of the draft suggests that the >>> scoping is through configuration, and S6.4.5 appears to support this >>> (in my reading, at least). >> >> I'm not an author, so this can be a test of how clear they have been. >> >> IIUC, a given logme "session" is dialog scoped. (Though not exactly, since in >> the presence of B2BUAs it becomes a set of related dialogs.) This is identified >> by the SessionID. Those entities that did not initiate the logging need to keep >> state for that duration. And of course this then is tied to the resulting logs. >> >> Some entities may also have some other state that causes them to initiate >> logging "sessions". The duration of that state is undefined. >> >> Now the authors can say if I got it right. >> >> Thanks, >> Paul >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks Email: vijay.gurbani@nokia-bell-labs.com / vkg@bell-labs.com Web: https://www.bell-labs.com/usr/vijay.gurbani Calendar: http://goo.gl/x3Ogq From nobody Fri Jun 16 07:30:25 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3673812EB8B for ; Fri, 16 Jun 2017 07:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5m35qigTeGn for ; Fri, 16 Jun 2017 07:30:20 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id E27ED12E04D for ; Fri, 16 Jun 2017 07:30:19 -0700 (PDT) Received: from [85.158.136.83] by server-1.bemta-5.messagelabs.com id 24/FD-01992-A7BE3495; Fri, 16 Jun 2017 14:30:18 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRWlGSWpSXmKPExsWi75nTqVv12jn S4McDJYvGB9PYLebff8Zk8eBHL5vFrekT2R1YPKb83sjqMfnxHEaPJUt+Mnk0fVvEFsASxZqZ l5RfkcCasXzHH8aCTZ4Vr2/8ZGtg3OHRxcjFISSwnVHiy/MbzBDOYUaJKdea2OCcq+v+M0I4m xglZi16ztTFyMHBJmAvMWNPTBcjJ4eIQIpEw65eNhCbWaBYYv+3z4wgtrCAi8SBS5PAykUEXC Xe3qiGKHeT2DH/LwuIzSKgKrH1cR9YK69AqMTauXuYIFY1MklcXXiVHSTBKeAu8WTDebAGRgF ZiS+Nq5khdolL3HoynwnElhAQkFiy5zwzhC0q8fLxP1aQvcwCmhLrd+lDlCtKTOl+yA6xS1Di 5MwnYCOFgG74t3IR0wRGsVlIps5C6J6FpHsWku4FjCyrGDWKU4vKUot0jSz0kooy0zNKchMzc 3QNDUz1clOLixPTU3MSk4r1kvNzNzECY7CegYFxB2PfKr9DjJIcTEqivO+fOEcK8SXlp1RmJB ZnxBeV5qQWH2KU4eBQkuBlfQWUEyxKTU+tSMvMASYDmLQEB4+SCK/NS6A0b3FBYm5xZjpE6hS jLse5yVu/MAmx5OXnpUqJ8/KDzBAAKcoozYMbAUtMlxhlpYR5GRkYGIR4ClKLcjNLUOVfMYpz MCoJ80aBrOLJzCuB2/QK6AgmoCOCLjiAHFGSiJCSamB00tPp0Z7V9+Ss+gLVUM++/T2/dgcKB ns/tOLJ/fiWv2NDsIb09v+vehLMZ3JHuiw+yfhjf9k32wdBL7g/BFu+c1xw81sbn5DJukjpyz NZdysVsbfl/Lt9OOSG4qQQBoaAQ5XiEQLygY+ZxfJd/sfUZe19klckccjZJcFD68oT7QutN1r 22yuxFGckGmoxFxUnAgAEtZ3BRwMAAA== X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-14.tower-36.messagelabs.com!1497623418!109046425!1 X-Originating-IP: [47.73.108.137] X-StarScan-Received: X-StarScan-Version: 9.4.19; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29450 invoked from network); 16 Jun 2017 14:30:18 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe06hw.internal.vodafone.com) (47.73.108.137) by server-14.tower-36.messagelabs.com with SMTP; 16 Jun 2017 14:30:18 -0000 Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 16:30:12 +0200 Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH09W.internal.vodafone.com (47.73.211.207) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 16:30:12 +0200 Received: from VOEXC16W.internal.vodafone.com (145.230.101.18) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 16 Jun 2017 16:30:11 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.50]) by voexc16w.internal.vodafone.com ([145.230.101.18]) with mapi id 14.03.0352.000; Fri, 16 Jun 2017 16:30:11 +0200 From: "Dawes, Peter, Vodafone Group" To: "Vijay K. Gurbani" , Paul Kyzivat CC: "insipid@ietf.org" , "Arun Arunachalam (carunach) (carunach@cisco.com)" Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-marking-07 Thread-Index: AQHS5UMMAPKNYGXfF0SXCMdcYfdsIKIkux6AgAD5WQCAAA3ngIAByRLg Date: Fri, 16 Jun 2017 14:30:09 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15B988D@VOEXM31W.internal.vodafone.com> References: <077dae6c-8d9f-fb26-c18f-749e529b395d@nokia-bell-labs.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99E15B75F3@VOEXM31W.internal.vodafone.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 14:30:24 -0000 SGVsbG8gVmlqYXksDQpUaGFua3MgZm9yIHRoZSBzdWdnZXN0ZWQgdGV4dCwgdGhpcyBzZWVtcyBh IGdvb2QgYXBwcm9hY2guIEFsc28gdGhhbmtzIGZvciBhbGwgb2YgeW91ciBvdGhlciByZXZpZXcg Y29tbWVudHMgd2hpY2ggSSBhZ3JlZSBuZWVkIHRvIGJlIHJlc29sdmVkIGluIHRoZSBuZXh0IHJl dmlzaW9uIG9mIHRoZSBkcmFmdC4gSSBoYXZlIG9uZSByZXNwb25zZSByZWdhcmRpbmcgdGhlIGZv bGxvd2luZyBjb21tZW50IG9uIFMzLjQuMToNCg0KPi0gUzMuNC4xOiBJIGRvbid0IHNlZSB0aGUg cmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHR3byBzZW50ZW5jZXMuDQo+ICBQZXJoYXBzIHNpbXBs ZXIgdG8gc2F5Og0KPg0KPiAgICAgV2hlbiBhIHVzZXIgZGV2aWNlIGluc2VydHMgdGhlICJsb2cg bWUiIG1hcmtlciwgdGhlIG1hcmtlciBNVVNUIGJlDQo+ICAgICBiZSBwYXNzZWQgdW5jaGFuZ2Vk IGluIHRoZSBUbyBhbmQgRnJvbSBoZWFkZXJzIGFjcm9zcyBhbiBlZGdlIHByb3h5DQo+ICAgICBv ciBhIEIyQlVBIGFkamFjZW50IHRvIHRoZSB1c2VyIGRldmljZS4gDQo+DQoNClRoZSBjdXJyZW50 IFMzLjQuMSBtaXhlcyB0d28gaWRlYXMsIGZpcnN0bHkgdGhhdCBvbmx5IGF1dGhvcml6ZWQgYW5k IGF1dGhlbnRpY2F0ZWQgdXNlciBhZ2VudHMgYXJlIGFsbG93ZWQgdG8gbWFyayBzaWduYWxsaW5n ICgiRWRnZSBwcm94eSBvciBCMkJVQSBjaGVja3Mgd2hldGhlciB0aGUgdXNlciBkZXZpY2UgaXMg YWxsb3dlZCB0byBtYWtlL3JlY2VpdmUgZS5nLiBjYWxscywgYmFzZWQgb24gYXV0aGVudGljYXRp b24gYW5kIG9uIGF1dGhvcml6YXRpb24uIikgYW5kIHNlY29uZGx5IHRoYXQgbWFya2luZyBtdXN0 IGJlIHBhc3NlZCB1bmNoYW5nZWQuIEFzIHlvdSBzYXksIHRoZSBjdXJyZW50IGRyYWZ0IGlzIGNv bmZ1c2luZyBzbyBpbiB0aGUgbmV4dCByZXZpc2lvbiB3ZSB3aWxsIHRyeSB0byBiZXR0ZXIgZXhw bGFpbiB0aGVzZSB0d28gYXNwZWN0cy4NCg0KUmVnYXJkcywNClBldGVyDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVmlqYXkgSy4gR3VyYmFuaSBbbWFpbHRvOnZpamF5 Lmd1cmJhbmlAbm9raWEtYmVsbC1sYWJzLmNvbV0NCj4gU2VudDogMTUgSnVuZSAyMDE3IDEzOjU5 DQo+IFRvOiBEYXdlcywgUGV0ZXIsIFZvZGFmb25lIEdyb3VwIDxQZXRlci5EYXdlc0B2b2RhZm9u ZS5jb20+OyBQYXVsDQo+IEt5eml2YXQgPHBhdWwua3l6aXZhdEBjb21jYXN0Lm5ldD4NCj4gQ2M6 IGluc2lwaWRAaWV0Zi5vcmc7IEFydW4gQXJ1bmFjaGFsYW0gKGNhcnVuYWNoKSAoY2FydW5hY2hA Y2lzY28uY29tKQ0KPiA8Y2FydW5hY2hAY2lzY28uY29tPg0KPiBTdWJqZWN0OiBSZTogW0luc2lw aWRdIFJldmlldyBvZiBkcmFmdC1pZXRmLWluc2lwaWQtbG9nbWUtbWFya2luZy0wNw0KPiANCj4g UGF1bCwgUGV0ZXI6IFRoYW5rIHlvdSBmb3IgdGhlIGZlZWRiYWNrLg0KPiANCj4gUGV0ZXIsIHNp bmNlIFBhdWwncyByZWNvbGxlY3Rpb24gaXMgb24gdGhlIHNwb3QsIGl0IGFwcGVhcnMgdG8gYmUg cmVhc29uYWJsZSB0bw0KPiB1c2UgaGlzIHRleHQgYXMgYSBzdGFydGluZyBwb2ludC4gIFMzLjIg Y2FuIGJlIGNsYXJpZmllZCBieSByZXBsYWNpbmcgdGhlIGV4aXN0aW5nDQo+IHBhcmFncmFwaCB0 byBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIChwbGVhc2UgZmVlbCBmcmVlIHRvIGRpc2Nh cmQsIGVkaXQsIG9yDQo+IGFkb3B0KToNCj4gDQo+ICAgQSB1c2VyIGFnZW50IG9yIHByb3h5IGFk ZHMgYSAibG9nIG1lIiBtYXJrZXIgaW4gYSByZXF1ZXN0IG9yIHJlc3BvbnNlDQo+ICAgZm9yIHR3 byByZWFzb25zOiBlaXRoZXIgaXQgaXMgY29uZmlndXJlZCB0byBkbyBzbyBvciBpdCBoYXMgZGV0 ZWN0ZWQNCj4gICB0aGF0IGEgZGlhbG9nIGlzIGJlaW5nICJsb2cgbWUiIG1hcmtlZCwgY2F1c2lu ZyBpdCB0byBtYWludGFpbiBzdGF0ZQ0KPiAgIHRvIGVuc3VyZSB0aGF0IGFsbCByZXF1ZXN0cyBh bmQgcmVzcG9uc2VzIGluIHRoZSBkaWFsb2cgYXJlICJsb2cgbWUiDQo+ICAgbWFya2VkLg0KPiAN Cj4gICBXaGVuIGEgdXNlciBhZ2VudCBvciBwcm94eSBpcyBjb25maWd1cmVkIHRvIGFkZCBhICJs b2cgbWUiIG1hcmtlciBpbg0KPiAgIG1lc3NhZ2VzLCB0aGUgZHVyYXRpb24gdGhhdCB0aGUgdXNl ciBhZ2VudCBvciBwcm94eSB3aWxsIGJlIHNvDQo+ICAgY29uZmlndXJlZCBpcyBvdXQgb2YgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBGb3IgaW5zdGFuY2UsIHRoZQ0KPiAgIHVzZXIgYWdl bnQgY2xpZW50IG9yIHByb3h5IGNvdWxkIGJlIGNvbmZpZ3VyZWQgdG8gYWRkIGEgImxvZyBtZSIN Cj4gICBtYXJrZXIgZm9yIGEgY2VydGFpbiBudW1iZXIgb2YgcmVxdWVzdHMsIG9yIGl0IGNvdWxk IGJlIGNvbmZpZ3VyZWQgdG8NCj4gICBtYXJrIG1lc3NhZ2VzIHdpdGggYSB0ZW1wb3JhbCBzY29w ZSAoaS5lLiwgOTowMGFtIC0gMTA6MDBhbSBldmVyeQ0KPiAgIGRheSksIG9yIGl0IGNvdWxkIGJl IGNvbmZpZ3VyZWQgdG8gbWFyayBtZXNzYWdlcyB3aGVuIGl0IGVuY291bnRlcnMgYQ0KPiAgIHNw ZWNpZmljICJVc2VyLUFnZW50IiBoZWFkZXIuDQo+IA0KPiAgIE9uIHRoZSBvdGhlciBoYW5kLCB3 aGVuIGEgdXNlciBhZ2VudCBvciBwcm94eSBkZXRlY3RzIHRoYXQgYSBkaWFsb2ctDQo+ICAgaW5p dGlhdGluZyByZXF1ZXN0IGlzIGJlaW5nICJsb2cgbWUiIG1hcmtlZCwgdGhlIHNjb3BlIG9mIHN1 Y2ggbWFya2luZw0KPiAgIGV4dGVuZHMgdG8gdGhlIGxpZmV0aW1lIG9mIHRoZSBkaWFsb2cuICBJ biBhZGRpdGlvbiwgYXMgZGlzY3Vzc2VkIGluDQo+ICAgU2VjdGlvbiAzLjcsICJsb2cgbWUiIG1h cmtlZCBkaWFsb2d1ZXMgdGhhdCBjcmVhdGUgcmVsYXRlZCBkaWFsb2d1ZXMNCj4gICAoUkVGRVIp IG1heSB0cmFuc2ZlciB0aGUgbWFya2luZyB0byB0aGUgcmVsYXRlZCBkaWFsb2d1ZXMuICBJbiBz dWNoDQo+ICAgY2FzZXMsIHRoZSBlbnRpcmUgInNlc3Npb24iLCBpZGVudGlmaWVkIGJ5IHRoZSBT ZXNzaW9uLUlEIGhlYWRlciwgaXMNCj4gICAibG9nIG1lIiBtYXJrZWQuDQo+IA0KPiBUaGFua3Ms DQo+IA0KPiBPbiAwNi8xNS8yMDE3IDA1OjMwIEFNLCBEYXdlcywgUGV0ZXIsIFZvZGFmb25lIEdy b3VwIHdyb3RlOg0KPiA+IEhlbGxvIFZpamF5LCBQYXVsLA0KPiA+IFBhdWwncyBzdW1tYXJ5IGlz IGNvcnJlY3QgYW5kIHRoZSByZXZpZXcgY29tbWVudCBmcm9tIFZpamF5IGluZGljYXRlcw0KPiB0 aGF0IHNlY3Rpb24gMy4yIG5lZWRzIHRvIGJlIGNsZWFyZXIgb24gY29uZmlndXJhdGlvbiB2cy4g cGVyLWRpYWxvZyBzY29wZSBvZg0KPiAibG9nIG1lIiBtYXJraW5nLg0KPiA+DQo+ID4gQW4gZXhh bXBsZSBvZiBjb25maWd1cmF0aW9uIGlzIHRoYXQgYSBzZXJ2aWNlIHByb3ZpZGVyIG1pZ2h0IGhh dmUgYSB0ZXN0DQo+IHRlcm1pbmFsIHByb2dyYW1tZWQgdG8gcnVuIHRocm91Z2ggYSBzZXQgb2Yg U0lQIHNlc3Npb25zIChjYWxsLCBjYWxsIHJlLQ0KPiBkaXJlY3RlZCBhdCBzZXQgdXAsIGNhbGwg dHJhbnNmZXIpIGFuZCB0aGlzIHRlcm1pbmFsIHdvdWxkIGJlIGNvbmZpZ3VyZWQgdG8gImxvZw0K PiBtZSIgbWFyayBhbGwgb2YgdGhlbS4gQW4gZXhhbXBsZSBvZiBwZXItZGlhbG9nIHNjb3BlIGlz IGEgU0lQIHRlcm1pbmF0aW5nDQo+IHVzZXIgYWdlbnQsIHdoaWNoIG5lZWRzIHRvIGJlIGF3YXJl IHRoYXQgYSBkaWFsb2cgaXMgYmVpbmcgImxvZyBtZSIgbWFya2VkDQo+IChpLmUuIGl0IG5lZWRz IHRvIGJlIHN0YXRlZnVsKSBpbiBvcmRlciB0byBtYXJrIGFueSBpbi1kaWFsb2cgcmVxdWVzdHMg dGhhdCBpdA0KPiBzZW5kcyAoZS5nLiBCWUUpLiBTdWNoIGEgdGVybWluYXRpbmcgVUEga25vd3Mg dGhhdCB3aGVuIHRoZSBkaWFsb2cgZW5kcyBpdA0KPiBjYW4gY2xvc2UgaXRzIHNpZ25hbGxpbmcg bG9nIGZvciB0aGF0IGRpYWxvZyBhbmQgc3RvcCBtYXJraW5nIHJlcXVlc3RzIHRoYXQgaXQNCj4g c2VuZHMuIFN1Y2ggYSB1c2VyIGFnZW50IGRvZXMgbm90IHVzZSBjb25maWd1cmF0aW9uIHRvIHBl cmZvcm0gImxvZyBtZSINCj4gbWFya2luZy4NCj4gPg0KPiA+IFdlIHdpbGwgY2xhcmlmeSBTMy4y IGluIHRoZSBuZXh0IHJldmlzaW9uLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBQZXRlcg0KPiA+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGluc2lwaWQgW21h aWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsDQo+ID4+IEt5 eml2YXQNCj4gPj4gU2VudDogMTQgSnVuZSAyMDE3IDIyOjE3DQo+ID4+IFRvOiBpbnNpcGlkQGll dGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbSW5zaXBpZF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYt aW5zaXBpZC1sb2dtZS1tYXJraW5nLTA3DQo+ID4+DQo+ID4+IE9uIDYvMTQvMTcgMzoxOCBQTSwg VmlqYXkgSy4gR3VyYmFuaSB3cm90ZToNCj4gPj4+IEhlbGxvLA0KPiA+Pj4NCj4gPj4+IEkgd2Fz IGFza2VkIGJ5IHRoZSBhdXRob3JzIHRvIHJldmlldw0KPiA+Pj4gZHJhZnQtaWV0Zi1pbnNpcGlk LWxvZ21lLW1hcmtpbmctMDcuICBNeSByZXZpZXcgaXMgYmVsb3cuDQo+ID4+Pg0KPiA+Pj4gU3Vt bWFyeTogZ29vZCBzdHVmZiwgYnV0IHNvbWUgaXNzdWVzIG5lZWQgdG8gYmUgYWRkcmVzc2VkIGFz DQo+ID4+PiBkb2N1bWVudGVkIG5leHQuDQo+ID4+Pg0KPiA+Pj4gTUFKT1I6DQo+ID4+Pg0KPiA+ Pj4gLSBTMy4yOiBTbywgaXQgYXBwZWFycyBmcm9tIHRoZSBsYXN0IHNlbnRlbmNlIHRoYXQgImxv ZyBtZSIgaXMgc2NvcGVkIGJ5DQo+ID4+PiAgICB0aGUgZGlhbG9ndWUuICBJZiB0aHJvdWdoIHNv bWUgY29uZmlndXJhdGlvbiwgYSBTSVAgVUEgaXMgY29uZmlndXJlZA0KPiA+Pj4gICAgdG8gaW5z ZXJ0IHRoZSAibG9nbWUiIHBhcmFtZXRlciwgdGhlbiB0aGUgVUEgd2lsbCBjb250aW51ZSBpbnNl cnRpbmcNCj4gPj4+ICAgIHRoZSBwYXJhbWV0ZXIgZm9yIGFsbCBkaWFsb2d1ZXMgY3JlYXRlZCBi eSB0aGUgVUEgdW50aWwgY29uZmlndXJlZCB0bw0KPiA+Pj4gICAgc3RvcCBpbnNlcnRpbmcgdGhl IHBhcmFtZXRlciwgcmlnaHQ/DQo+ID4+Pg0KPiA+Pj4gICAgSWYgc28sIHRoZW4gdGhlIHNjb3Bl IG9mIHRoZSAibG9nbWUiIHBhcmFtZXRlciBpcyBkcml2ZW4gYnkNCj4gPj4+ICAgIGNvbmZpZ3Vy YXRpb24gbW9yZSB0aGFuIGEgZGlhbG9ndWUuICBUaGlzIHNob3VsZCBiZSBtYWRlIGNsZWFyIGlu IHRoZQ0KPiA+Pj4gICAgdGV4dCwgYXMgdGhlcmUgYXJlIG1hbnkgcGxhY2VzIHRoYXQgc3RhdGUg dGhhdCAibG9nbWUiIGlzIHNjb3BlZCB0byBhDQo+ID4+PiAgICBkaWFsb2d1ZSAoUzYuNC41LCBm b3IgaW5zdGFuY2UpLg0KPiA+Pj4NCj4gPj4+ICAgIEkgYmVsaWV2ZSB0aGlzIGlzIGFuIGltcG9y dGFudCBhc3BlY3QgdG8gY2xhcmlmeTogSXMgdGhlICJsb2dtZSINCj4gPj4+ICAgIHNjb3BlZCBi eSBhIGRpYWxvZ3VlIG9yIHRocm91Z2ggY29uZmlndXJhdGlvbiwgYXMgdGltZSBsaW1pdGVkIGFz IHRoYXQNCj4gPj4+ICAgIGNvbmZpZ3VyYXRpb24gbWF5IGJlPyAgTXkgcmVhZGluZyBvZiB0aGUg ZHJhZnQgc3VnZ2VzdHMgdGhhdCB0aGUNCj4gPj4+ICAgIHNjb3BpbmcgaXMgdGhyb3VnaCBjb25m aWd1cmF0aW9uLCBhbmQgUzYuNC41IGFwcGVhcnMgdG8gc3VwcG9ydCB0aGlzDQo+ID4+PiAgIChp biBteSByZWFkaW5nLCBhdCBsZWFzdCkuDQo+ID4+DQo+ID4+IEknbSBub3QgYW4gYXV0aG9yLCBz byB0aGlzIGNhbiBiZSBhIHRlc3Qgb2YgaG93IGNsZWFyIHRoZXkgaGF2ZSBiZWVuLg0KPiA+Pg0K PiA+PiBJSVVDLCBhIGdpdmVuIGxvZ21lICJzZXNzaW9uIiBpcyBkaWFsb2cgc2NvcGVkLiAoVGhv dWdoIG5vdCBleGFjdGx5LA0KPiA+PiBzaW5jZSBpbiB0aGUgcHJlc2VuY2Ugb2YgQjJCVUFzIGl0 IGJlY29tZXMgYSBzZXQgb2YgcmVsYXRlZCBkaWFsb2dzLikNCj4gPj4gVGhpcyBpcyBpZGVudGlm aWVkIGJ5IHRoZSBTZXNzaW9uSUQuIFRob3NlIGVudGl0aWVzIHRoYXQgZGlkIG5vdA0KPiA+PiBp bml0aWF0ZSB0aGUgbG9nZ2luZyBuZWVkIHRvIGtlZXAgc3RhdGUgZm9yIHRoYXQgZHVyYXRpb24u IEFuZCBvZiBjb3Vyc2UgdGhpcw0KPiB0aGVuIGlzIHRpZWQgdG8gdGhlIHJlc3VsdGluZyBsb2dz Lg0KPiA+Pg0KPiA+PiBTb21lIGVudGl0aWVzIG1heSBhbHNvIGhhdmUgc29tZSBvdGhlciBzdGF0 ZSB0aGF0IGNhdXNlcyB0aGVtIHRvDQo+ID4+IGluaXRpYXRlIGxvZ2dpbmcgInNlc3Npb25zIi4g VGhlIGR1cmF0aW9uIG9mIHRoYXQgc3RhdGUgaXMgdW5kZWZpbmVkLg0KPiA+Pg0KPiA+PiBOb3cg dGhlIGF1dGhvcnMgY2FuIHNheSBpZiBJIGdvdCBpdCByaWdodC4NCj4gPj4NCj4gPj4gCVRoYW5r cywNCj4gPj4gCVBhdWwNCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4gaW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4gPj4gaW5zaXBp ZEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lu c2lwaWQNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gaW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4gPiBpbnNpcGlkQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlkDQo+ID4NCj4g DQo+IA0KPiAtIHZpamF5DQo+IC0tDQo+IFZpamF5IEsuIEd1cmJhbmksIEJlbGwgTGFib3JhdG9y aWVzLCBOb2tpYSBOZXR3b3Jrcw0KPiBFbWFpbDogdmlqYXkuZ3VyYmFuaUBub2tpYS1iZWxsLWxh YnMuY29tIC8gdmtnQGJlbGwtbGFicy5jb20NCj4gV2ViOiBodHRwczovL3d3dy5iZWxsLWxhYnMu Y29tL3Vzci92aWpheS5ndXJiYW5pDQo+IENhbGVuZGFyOiBodHRwOi8vZ29vLmdsL3gzT2dxDQo=