Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-marking-09

Ben Campbell <ben@nostrum.com> Tue, 26 June 2018 20:56 UTC

Return-Path: <ben@nostrum.com>
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 AD0D5130EDF for <insipid@ietfa.amsl.com>; Tue, 26 Jun 2018 13:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 UhKPHPqzI9rg for <insipid@ietfa.amsl.com>; Tue, 26 Jun 2018 13:56:14 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496EC130EDE for <insipid@ietf.org>; Tue, 26 Jun 2018 13:56:14 -0700 (PDT)
Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5QKu3fI005635 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jun 2018 15:56:04 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <72A2B9DA-6F0D-4E7A-872C-A2A4DBB79521@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7F930535-8A53-4A32-AA5B-3EBA19AB37DE"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 26 Jun 2018 15:56:02 -0500
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E3200559@VOEXM31W.internal.vodafone.com>
Cc: "insipid@ietf.org" <insipid@ietf.org>, "Arun Arunachalam (carunach) (carunach@cisco.com)" <carunach@cisco.com>, "Gonzalo Salgueiro (gsalguei@cisco.com)" <gsalguei@cisco.com>
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E3200559@VOEXM31W.internal.vodafone.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/cjONc6xpEV9iStX2CWbr6L0iXaA>
Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-marking-09
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jun 2018 20:56:19 -0000

Hi,

I think this version is ready for IETF Last Call. I will request that shortly.

I have one remaining comment, which can be resolved along with any LC feedback:

In section 7: "An end user or network administrator MUST give permission for a
   terminal to perform "log me" marking in the context of regression
   testing or troubleshooting a problem.  “

I think this really means “a terminal MUST NOT insert “log me” marking without permission…”, right? As it stands, it could be read to mean that the administrator is not allowed to withhold permission.

Thanks!

Ben.




> On Jun 25, 2018, at 6:04 AM, Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com> wrote:
> 
> Hello Ben, All,
> We have submitted revision -11 to correct the order of sections as per Ben's reviews to:
> 
> 6.  Augmented BNF for the "logme" Parameter
> 7.  Security Considerations
> 8.  IANA Considerations
> 
> Sorry for the mistake!
> Peter and Arun
> 
> 
> 
> Dear Ben, All,
> The authors have posted version -10 of the logme-marking draft to respond to your review comments. We made changes as a result of all comments except two, namely in section 4.5.2.1. where we think the use of the term "proxy" is correct as per RFC 7989 and section 4.5.2.1.1. which we believe does not belong with error cases and is in the right place.
> Summary of changes in -10 is below.
> 
> Best regards,
> Peter and Arun
> 
> In section 3.6.  Format of Logged Signaling, changed MUST to SHOULD in "The entire SIP message (SIP headers and message body) MUST be logged"
> 
> A new section 4.1 Scope of Marking has been added that collects together the aspects of the logme mechanism that ensure logs are only for sessions being tested and that have user or administrator consent. This new section spells out requirements that are implicit in the mechanism, so these requirements do not change the mechanism.
> 
> RFC 7206 (Session-ID requirements) has been moved from the normative to the informative references section.
> 
> The last paragraph of the Abstract is re-worded to clarify that operators need prior agreement in order to pass a "log me" marker end-to-end.
> 
> Updated the requirements language clause to the RFC 8174 recommendation. Kept the extra sentence explaining that requirements are not for interoperability but are for "log me" operation.
> 
> Revised the normative statements in the section "Session-ID logme Parameter" to make them consistent. The MUST in 3.1 is used to emphasize that if Session-ID is passed unchanged then logme is also passed unchanged unless this document specifically says to remove it. Also, revised the text referring to an external network to refer to a network boundary because the important consideration is crossing a network boundary.
> 
> Added a reference to clause 5.2.  "Log Me" Marker Appears Mid-Dialog saying that logme appearing mid-dialog is an error and that such a dialog is not logged.
> 
> In section 3.1, rather than change the MUST to SHOULD in "The "logme" parameter shown in Figure 1 does not introduce any device-specific or user-specific information and MUST be passed unchanged through SIP B2BUAs or other intermediaries." as per the comment from Ben, re-worded to link Session-ID and logme together saying "The "logme" parameter shown in Figure 1 does not introduce any device-specific or user-specific information and MUST be passed unchanged with the Session-ID header..."
> 
> In section 3.4.2.  To and From an External Network, changed the two occurrences of the normative language SHOULD to more descriptive language.
> 
> In section 3.6 Format of Logged Signalling, changed the text about logging the entire message to "The entire SIP message (SIP headers and message body) SHOULD be logged since troubleshooting might be difficult if information is missing."
> The new subclause "Scope of Marking" includes guidance to minimize "log me" marking so that only the dialogs under test or troubleshooting get marked and avoid the temptation to just mark everything.
> 
> In 4.2 Endpoints and 4.3 SIP Intermediaries Acting on Behalf of Endpoints, changed the word "principles" to "rules" since the bullet lists are rules that must be followed for the logme mechanism to work.
> 
> In 4.3 SIP Intermediaries Acting on Behalf of Endpoints, moved the text regarding user consent to logging to the beginning of the clause to emphasize this aspect.
> 
> In order to make section 4.5.1.  Stateless processing consistent with other draft text, added a reference to 4.5.2 Stateful processing and some extra descriptive text to make it clear in which cases stateless processing is not possible.
> 
> In section 5.1.  Missing "Log me" Marker in Dialog Being Logged, added explicit references to error and non-error cases to the text immediately above this final paragraph. This subclause makes it clear that a missing marker is not always an error.
> 
> In section 7.1.  "Log Me" Authorization, added text to say that permission for marking must be limited in scope and duration to only what is necessary to for problem solving or testing.
> 
> In section 7.4.1.  Personal Identifiers, added text to describe the behaviour of an intermediary that is marking on behalf of a user.
> 
> In section 7.4.4.  Preventing Fingerprinting, stated that it is fingerprinting of users that is being prevented.
> 
> In section 7.4.5.  Retaining Logs, re-worded to say that the retention period should be minimized.
> 
> In section 7.4.6.  User Control of Logging, the word MUST has been changed to lower case and now reads: "Consent to turn on "log me" marking for a given session must be provided by the end user or by the network administrator."
> 
> RFC 3323 moved to the normative references section.
> 
> Fixed issues flagged by IDNits and also raised by the document shepherd writeup.
> 
> In section 3.1.  Session-ID logme Parameter, changed "Logging is most effective." to "Logging for diagnostic purposes is most effective." and changed " session identifier is passed through" to ". typically passed through." as suggested.
> 
> In sections 3.2 and 5.1 changed "proxy" to "intermediary" as suggested.
> 
> In section 3.7.  Marking Related Dialogs, removed the word "below" from the reference to figure 2. Also added that Alice's terminal inserts "log me" markers in its requests and responses in dialog2.
> 
> In section 3.8. Forked Requests, changed the text to active voice.
> 
> In section 4.5.2.1.  "Log Me" marking not supported by Originating UA, we think the usage of Proxy is correct. According to RFC 7989 both proxies and B2BUAs can add Session-ID headers:
> The term "intermediary" refers to any entity along the call-signaling path
>   between the aforementioned endpoints, including B2BUAs and SIP
>   proxies.
> 
> It was commented that section 4.5.2.1.1.  Missing "Log me" Marker Non-Error Cases belongs with the error cases but the authors specifically moved this text because it is not an error case but a case of an intermediary acting on behalf of a UA.
> 
> In section 5.1.1.  Missing "Log me" Marker Error Cases, added the messages exchanged with Network B to figure 9.
> 
> In section 5.2.  "Log Me" Marker Appears Mid-Dialog, changed the term "edge proxy" to "intermediary close to the terminating user agent" as suggested.
> 
> In section 7.4.  Privacy, changed from one sentence to two to correct comma splice.
> 
> Moved section 6. IANA Considerations to before section 7. Security Considerations.
> 
>> -----Original Message-----
>> From: Ben Campbell <ben@nostrum.com>;
>> Sent: 15 June 2018 03:53
>> To: Arun Arunachalam (carunach) <carunach@cisco.com>;
>> Cc: Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com>;; draft-
>> ietf-insipid-logme-marking.all@ietf.org
>> Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-marking-09
>> 
>> Thanks, please submit an update whenever you are ready.
>> 
>> Ben.
>> 
>>> On Jun 14, 2018, at 1:51 PM, Arun Arunachalam (carunach)
>> <carunach@cisco.com>; wrote:
>>> 
>>> Thanks Ben!
>>> 
>>> We will use SHOULD as per your recommendation.
>>> 
>>> Thanks!
>>> Arun
>>> 
>>> 
>>> 
>>>> On Jun 14, 2018, at 2:34 PM, Ben Campbell <ben@nostrum.com>; wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Jun 13, 2018, at 6:05 PM, Arun Arunachalam (carunach)
>> <carunach@cisco.com>; wrote:
>>>>> 
>>>>> Thanks Ben!
>>>>> 
>>>>> We will incorporate your comments. The word "ability" in #2 refers to
>> anonymization.
>>>>> 
>>>>> Our suggestion to log the entire message comes from observations in the
>> real-world. The primary objective of "logme" is to help with troubleshooting.
>> In most cases, we would require the entire message to perform a useful and
>> complete analysis.
>>>>> 
>>>>> The messages are logged only for specific calls of interest (that by itself
>> minimizes the logged information).
>>>> 
>>>> Log minimization can apply both to what messages get logged and what
>> gets logged for each message.
>>>> 
>>>>> 
>>>>> Can we please consider usefulness over log minimization for the default
>> logme related logging behavior?
>>>> 
>>>> I am perfectly happy with non-mormative text that encourages logging
>> everything and describes why you want to. My objection is to text that
>> forbids other choices if people think they have good reason. Privacy
>> protections are generally a good reason.
>>>> 
>>>> The bottom line is, I object to stating that intermediaries MUST log entire
>> messages. My preference would be to recommend anonymization. As a
>> compromise, I could accept language to the effect that intermediaries
>> SHOULD log entire messages, but MAY anonymize messages or otherwise
>> redact privacy-sensitive information. (But please keep in mind that it's likely
>> that other IESG members will object to even a SHOULD).
>>>> 
>>>> Thanks,
>>>> 
>>>> Ben.
>>>> 
>>>>> 
>>>>> Please let us know your thoughts.
>>>>> 
>>>>> Thanks!
>>>>> Arun
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jun 13, 2018, at 5:07 PM, Ben Campbell <ben@nostrum.com>;
>> wrote:
>>>>>> 
>>>>>> Thanks for the response. In summary, I think your comments resolve
>> my major comment(3), mostly resolve (1), but do not resolve (2). Please see
>> details below:
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> Ben.
>>>>>> 
>>>>>>> On Jun 8, 2018, at 8:05 AM, Dawes, Peter, Vodafone Group
>> <Peter.Dawes@vodafone.com>; wrote:
>>>>>>> 
>>>>>>> Dear Ben,
>>>>>>> Thanks very much for the in-depth review, we authors have reviewed
>> all of the points raised and drafted a new revision proposing solutions.
>> Because the comment count was high (we recorded 33 in total!) we think it
>> would be most efficient to resolve the 3 major review comments first. The
>> major comments and our proposed resolutions are as follows:
>>>>>>> 
>>>>>>> (1) "I think there are still privacy issues in this document. In particular,
>> compliant intermediaries are normatively required to log, and to log entire
>> messages. Log minimization is a common tenant of privacy, and these
>> requirements effectively forbid it. IMO, the draft should avoid normative
>> requirements about whether a device logs, and how much it logs."
>>>>>>> 
>>>>>>> Although the text is not at the beginning of the draft, section 6.4.6
>> "User Control of Logging" states the logging can be skipped if local policy
>> doesn't allow. We have drafted a new clause called "Scope of Marking" that
>> can be placed as a new high-level clause 3 or as the first sub-clause of 4. "SIP
>> Entity Behaviour" that refers to this text and would increase its visibility. We
>> included the text of this clause in the response to your major comment (3).
>>>>>> 
>>>>>> That text helps. I think it would help more to make the statement
>>>>>> that entities are never required to log if local policy prohibits
>>>>>> it earlier in the document. (Perhaps state it authoritatively in
>>>>>> the proposed new section, and have the later section refer back to
>>>>>> it.)
>>>>>> 
>>>>>>> 
>>>>>>> (2) "Likewise, the requirement to log entire messages without change
>> effective forbids pseudonymization or anonymization. There is text in the
>> privacy considerations suggesting this is the UA responsibility-I don't think
>> that's good enough, especially in the case where an intermediary inserts the
>> logme parameter on behalf of a non-supporting  endpoint. I'd like to see it
>> possible for an intermediary to anonymize logs, and some guidance that it
>> should do so unless there is a reason not to."
>>>>>>> 
>>>>>>> We would like to maintain the requirement to log the entire message
>> because it gives predictable behaviour. The approach of the draft is to ensure
>> that logging only happens by prior agreement, and that logged data is within
>> a network that already has a relationship with the user. Would it satisfy your
>> comment to accommodate anonymization if the endpoint or intermediary
>> has that ability?
>>>>>> 
>>>>>> I'm not sure I understand the last sentence. Does "that ability" refer to
>> the ability to anonymize, or the requirement to only log by prior agreement?
>>>>>> 
>>>>>> But this is not just about anonymization, it's also about log
>> minimization. I think a normative requirement to log the entire message will
>> get objections during the IESG review. I think a better approach would be to
>> allow the intermediary flexibility about what it logs, and perhaps add non-
>> normative guidance that points out that troubleshooting may be made more
>> difficult if the log does not contain enough information, and that
>> implementors cannot always predict what information will be needed for
>> troubleshooting purposes.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> (3) " I think one of the major values of this mechanism is to allow an
>> operator to only log details for sessions being tested, and avoid the
>> temptation to just log everything in case they need it someday. I suggest this
>> be emphasized early in the document. Along those lines, I'd like to see text
>> that talks about configuring endpoints and intermediaries to insert the
>> parameter to include guidance about the timescale and granularity of such a
>> configuration. There is text in the privacy considerations suggesting that you
>> this should be configured on a per session basis with a limited timeframe,
>> but If there are normative requirements to that effect, I missed them."
>>>>>>> 
>>>>>>> We propose to add the following "Scope of marking" section, either as
>> a new high-level clause 3, or as the first sub-clause of 4. "SIP Entity
>> Behaviour". This collects together a description of the safeguards of logging
>> only sessions being tested, the limits on logging granularity, and the
>> requirements that are implicit in the mechanism to prevent logging beyond
>> the boundaries of what is intended and has user consent.
>>>>>> 
>>>>>> Adding the proposed text as a new section 3 would resolve my major
>> comment (3). However, I do have some editorial comments on the proposed
>> text, below:
>>>>>> 
>>>>>>> 
>>>>>>> (3. or 4.1.)  Scope of Marking
>>>>>>> 
>>>>>>> "Log me" marking is intended to be limited, in time period and
>>>>>>> number of dialogs marked, to the minimum needed to troubleshoot a
>>>>>>> particular problem or perform a particular test.
>>>>>>> 
>>>>>>> o  SIP entities MUST be configured to "log me" mark only dialogs
>>>>>>> needed for the current testing purpose e.g. troubleshooting or
>>>>>>> regression testing.  The mechanisms in this clause ensure that
>>>>>>> "log me" marking begins at dialog creation and, other than cases
>>>>>>> of marking related dialogs or premature ending, ends when the
>>>>>>> dialog being "log me" marked ends.
>>>>>>> 
>>>>>>> o  SIP entities MUST be configured to initiate "log me" marking on
>>>>>>> a  dialog creating side.
>>>>>> 
>>>>>> That MUST is really a statement of fact that later requirements in the
>> document require this, right?
>>>>>> 
>>>>>> Also, " dialog creation side" seems vague. Do you mean "at dialog
>> creation"?
>>>>>> 
>>>>>>> The mechanisms in this clause limit  initiation of "log me"
>>>>>>> marking to the dialog creating side, the  dialog terminating side
>>>>>>> detects an incoming "log me" marker and  reacts accordingly.
>>>>>>> 
>>>>>>> Note that the error cases described in clauses 5.1 and 5.2 cause
>>>>>>> SIP entities to stop "log me" marking, and the requirements in
>>>>>>> Section 7 also place requirements on SIP entities, including
>>>>>>> allowing SIP entities to not log signaling based on local policies
>>>>>>> (see Section 7.4.6).
>>>>>>> 
>>>>>>> Thanks again for the review,
>>>>>>> Peter and Arun
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Arun Arunachalam (carunach) <carunach@cisco.com>;
>>>>>>>> Sent: 01 June 2018 08:43
>>>>>>>> To: Ben Campbell <ben@nostrum.com>;
>>>>>>>> Cc: draft-ietf-insipid-logme-marking.all@ietf.org; Arun
>>>>>>>> Arunachalam
>>>>>>>> (carunach) <carunach@cisco.com>;
>>>>>>>> Subject: Re: [Insipid] AD Evaluation of
>>>>>>>> draft-ietf-insipid-logme-marking-09
>>>>>>>> 
>>>>>>>> Thanks Ben.
>>>>>>>> 
>>>>>>>> We are working on it and will share the response by next week.
>>>>>>>> 
>>>>>>>> Peter and Arun
>>>>>>>> 
>>>>>>>>> On Jun 1, 2018, at 12:48 AM, Ben Campbell <ben@nostrum.com>;
>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Just a reminder - I have not seen a response to my review from
>>>>>>>>> the
>>>>>>>> authors.
>>>>>>>>> 
>>>>>>>>> Thanks!
>>>>>>>>> 
>>>>>>>>> Ben.
>>>>>>>>> 
>>>>>>>>>> On May 8, 2018, at 4:36 PM, Ben Campbell <ben@nostrum.com>;
>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> This is my AD evaluation of
>>>>>>>>>> draft-ietf-insipid-logme-marking-09. I have
>>>>>>>> separated my comments into Major, Minor, and Editorial. I would
>>>>>>>> like to at least resolve the major comments prior to IETF last call.
>>>>>>>>>> 
>>>>>>>>>> As a preface, please remember that the related requirements
>>>>>>>>>> document
>>>>>>>> created controversy during the IESG review. Some of the
>>>>>>>> controversial normative language was moved from that document to
>>>>>>>> this one. Therefore, we can expect some of that controversy to
>>>>>>>> reoccur. Hopefully if we can resolve my major comments, we can
>> avoid much of that.
>>>>>>>>>> 
>>>>>>>>>> Thanks!
>>>>>>>>>> 
>>>>>>>>>> Ben.
>>>>>>>>>> 
>>>>>>>>>> ----------------------------------
>>>>>>>>>> 
>>>>>>>>>> Major Comments:
>>>>>>>>>> 
>>>>>>>>>> 1) I think there are still privacy issues in this document. In
>>>>>>>>>> particular,
>>>>>>>> compliant intermediaries are normatively required to log, and to
>>>>>>>> log entire messages. Log minimization is a common tenant of
>>>>>>>> privacy, and these requirements effectively forbid it. IMO, the
>>>>>>>> draft should avoid normative requirements about whether a device
>>>>>>>> logs, and how much it logs. It is reasonable to include
>>>>>>>> non-normative guidance that troubleshooting might require
>> information than might otherwise be logged.
>>>>>>>>>> 
>>>>>>>>>> Likewise, the requirement to log entire messages without change
>>>>>>>>>> effective
>>>>>>>> forbids pseudonymization or anonymization. There is text in the
>>>>>>>> privacy considerations suggesting this is the UA responsibility-I
>>>>>>>> don't think that's good enough, especially in the case where an
>>>>>>>> intermediary inserts the logme parameter on behalf of a
>>>>>>>> non-supporting  endpoint. I'd like to see it possible for an
>>>>>>>> intermediary to anonymize logs, and some guidance that it should do
>> so unless there is a reason not to.
>>>>>>>>>> 
>>>>>>>>>> 2) I think one of the major values of this mechanism is to
>>>>>>>>>> allow an
>>>>>>>> operator to only log details for sessions being tested, and avoid
>>>>>>>> the temptation to just log everything in case they need it
>>>>>>>> someday. I suggest this be emphasized early in the document.
>>>>>>>> Along those lines, I'd like to see text that talks about
>>>>>>>> configuring endpoints and intermediaries to insert the parameter
>>>>>>>> to include guidance about the timescale and granularity of such a
>>>>>>>> configuration. There is text in the privacy considerations
>>>>>>>> suggesting that you this should be configured on a per session basis
>> with a limited timeframe, but If there are normative requirements to that
>> effect, I missed them.
>>>>>>>>>> 
>>>>>>>>>> 3) There is a normative downref to RFC7206. I don't think that
>>>>>>>>>> is necessary
>>>>>>>> or appropriate. It doesn't appear to be cited, so maybe it can just go
>> away?
>>>>>>>>>> 
>>>>>>>>>> Minor Comments:
>>>>>>>>>> 
>>>>>>>>>> Abstract, last paragraph: "However, such marking can be carried
>>>>>>>>>> end-to-
>>>>>>>> end including the originating and terminating SIP user agents,
>>>>>>>> even if a session originates and terminates in different
>>>>>>>> networks.": While the draft allows this when there is agreement
>>>>>>>> between operators to do so, it seems like it is not the default
>>>>>>>> case. Stating it this way without limitation in the abstract is likely to
>> give the wrong idea.
>>>>>>>>>> 
>>>>>>>>>> §2: There are instances of 2119 keywords in lower case. Unless
>>>>>>>>>> you intend
>>>>>>>> those to be normative, please use the boilerplate from RFC 8174
>> instead.
>>>>>>>>>> 
>>>>>>>>>> §3.1, first paragraph: I think "...MUST be passed unchanged."
>>>>>>>>>> is too
>>>>>>>> strong. This only allows the exception for external networks.
>>>>>>>> There may be any number of local policy reasons to not pass the
>>>>>>>> parameter through. I suggest making this a SHOULD, and mentioning
>>>>>>>> that local policy might disallow it. (Note that this MUST is
>>>>>>>> redundant to the one in §3.4.2. It seems like the normative
>>>>>>>> requirement belongs there, and that the mention in §3.1 should be
>> descriptive.
>>>>>>>>>> 
>>>>>>>>>> §3.2, 2nd paragraph: What is expected to happen when such an
>>>>>>>>>> error
>>>>>>>> condition occurs?
>>>>>>>>>> 
>>>>>>>>>> §3.4.1: See comment to §3.1
>>>>>>>>>> 
>>>>>>>>>> §3.4.2: I don't think it's appropriate to use 2119 keywords to
>>>>>>>>>> describe the
>>>>>>>> agreements. between operators. It's reasonable to say
>>>>>>>> (non-normatively) that end-to-end troubleshooting will be made
>>>>>>>> easier if such agreements exist.
>>>>>>>>>> 
>>>>>>>>>> §3.6: (See major comment 1.) It's reasonable to say that
>>>>>>>>>> logging the entire
>>>>>>>> message without change might make troubleshooting easier. But a
>>>>>>>> SIP network element should be able to apply local policy to
>>>>>>>> decide what (and
>>>>>>>> whether) to log. I think a better approach would have been to
>>>>>>>> define the meaning of "logme" to mean "this message is of
>>>>>>>> interest for troubleshooting or testing", and then let devices
>>>>>>>> decide what to do about that based on local policy.
>>>>>>>>>> 
>>>>>>>>>> §4 (See major comment 1): This needs some guidance not to
>>>>>>>>>> minimize
>>>>>>>> "log me" marking so that only the dialogs under test or
>>>>>>>> troubleshooting get marked. Otherwise, people will be tempted to
>> just mark everything.
>>>>>>>>>> 
>>>>>>>>>> §4.1: Since the bullet points are listed as "principles", I
>>>>>>>>>> suggest using
>>>>>>>> descriptive language rather than normative keywords. (Same for
>>>>>>>> §4.2)
>>>>>>>>>> 
>>>>>>>>>> §4.2:
>>>>>>>>>> - This behavior will likely be a red flag to reviewers. Please
>>>>>>>>>> mention the
>>>>>>>> consent requirement up front.
>>>>>>>>>> - Is the restriction that the intermediaries that insert logme
>>>>>>>>>> on behalf of
>>>>>>>> the endpoints be the first SIP hop from the endpoints intended to
>>>>>>>> be normative? (How much work does it need to do to verify this?
>>>>>>>> For e.g., there may be edge cases where looking at Via headers
>>>>>>>> may not be sufficient to tell an endpoint from a b2bua.)
>>>>>>>>>> 
>>>>>>>>>> §4.4.1: It seems like there are other normative requirements
>>>>>>>>>> that
>>>>>>>> effectively prevent stateless processing in many cases.
>>>>>>>>>> 
>>>>>>>>>> §5.1, last paragraph: This needs to talk about how it interacts
>>>>>>>>>> with
>>>>>>>> intermediaries that add the log-me parameter on behalf of
>>>>>>>> endpoints that don't support it. It seems like they will see missing
>> markers all the time.
>>>>>>>>>> 
>>>>>>>>>> §6.1: Again, this needs some guidance to discourage an end user
>>>>>>>>>> or
>>>>>>>> administrator turning on log-me for all dialogs.
>>>>>>>>>> 
>>>>>>>>>> §6.4.1: (See major comment 1) This seems unhelpful in the case
>>>>>>>>>> where an
>>>>>>>> intermediary inserts log-me on behalf of an end-point that doesn'
>> support it.
>>>>>>>>>> 
>>>>>>>>>> §6.4.4: This doesn't seem right; the SIP privacy mechanism is
>>>>>>>>>> about
>>>>>>>> avoiding identifying the user, not avoiding fingerprinting of a
>>>>>>>> UA. OTOH, as far as I can tell, log-me doesn't make
>>>>>>>> fingerprinting "worse" except in the case where it introduces
>>>>>>>> full-message logging without the knowledge of the endpoint.
>>>>>>>>>> 
>>>>>>>>>> §6.4.5: Is the need to enable logging on a per-session basis or
>>>>>>>>>> specific time
>>>>>>>> period stated normatively somewhere that I missed? Also, I think
>>>>>>>> this can do better than making the retention period
>>>>>>>> "out-of-scope". I suggest non- normative language that log
>>>>>>>> records captured for troubleshooting or test purposes should not be
>> retained longer than necessary for that purpose.
>>>>>>>>>> 
>>>>>>>>>> §6.4.6: The "MUST" in the first paragraph seems redundant to
>>>>>>>>>> already
>>>>>>>> stated requirements; please state it descriptively. Also, It
>>>>>>>> seems like the last paragraph is incompatible with some existing
>> MUST level requirements.
>>>>>>>>>> 
>>>>>>>>>> §10.2: It seems like the reference to 3323 should be normative
>>>>>>>>>> as
>>>>>>>> currently used.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Editorial Comments:
>>>>>>>>>> 
>>>>>>>>>> - IDNits returns a number of issues; please check. (I see that
>>>>>>>>>> the shepherd
>>>>>>>> writeup also points these outs; is there a reason they were not
>>>>>>>> fixed as a result of that review?)
>>>>>>>>>> 
>>>>>>>>>> §3.1:
>>>>>>>>>> - "Logging is most effective.": I suggest "Logging for
>>>>>>>>>> diagnostic purposes is
>>>>>>>> most effective."
>>>>>>>>>> - " session identifier is passed through": I suggest  ". more
>>>>>>>>>> likely to be be
>>>>>>>> passed through."
>>>>>>>>>> 
>>>>>>>>>> §3.2:
>>>>>>>>>> - First paragraph: Is "As indicated in [RFC8123] REQ111,"
>>>>>>>>>> really needed? It
>>>>>>>> doesn't seem to add information to this document.
>>>>>>>>>> - 2nd paragraph: I suggest s/proxy/intermediary
>>>>>>>>>> 
>>>>>>>>>> §3.7:
>>>>>>>>>> - 2nd paragraph:
>>>>>>>>>> - "Figure 2 below": Don't assume all presentations of the RFC
>>>>>>>>>> will keep the
>>>>>>>> same relative positioning for the figure. Better to just say "Figure 2".
>>>>>>>>>> - "Her terminal is configured to log signalling": That makes it
>>>>>>>>>> sound like
>>>>>>>> her terminal is configured to insert the logme parameter into all
>> requests.
>>>>>>>> Can this be scoped more tightly?
>>>>>>>>>> - " Alice's terminal logs related REFER dialog2" : And inserts
>>>>>>>>>> the logme
>>>>>>>> parameter?
>>>>>>>>>> 
>>>>>>>>>> -  4th paragraph: Unmatched closing parenthesis.
>>>>>>>>>> - Figure 2: It would be helpful to mention that parts of the
>>>>>>>>>> messages in
>>>>>>>> examples are elided for clarity (e.g. no SDP, "." for content-length).
>>>>>>>>>> 
>>>>>>>>>> §3.8: By what? (Please consider active voice; in this case
>>>>>>>>>> passive voice
>>>>>>>> obscures the actor).
>>>>>>>>>> 
>>>>>>>>>> §4.2, first paragraph: "The intermediaries that are known to be
>> closest."
>>>>>>>> That's the point of the whole section; I moving it to the
>>>>>>>> beginning of the paragraph.
>>>>>>>>>> 
>>>>>>>>>> §4.4.2.1: Is "Proxy 1" really a "proxy" as defined in RFC3261?
>>>>>>>>>> Does this
>>>>>>>> assume that Alice's UA did insert Session-ID?
>>>>>>>>>> 
>>>>>>>>>> §4.4.2.1.1: Seems like this example belongs with the text about
>> errors.
>>>>>>>>>> 
>>>>>>>>>> §5.1.1, figure 9: "Network B" doesn't seem to participate in
>>>>>>>>>> the
>>>>>>>> exchange-why is it in the picture?
>>>>>>>>>> 
>>>>>>>>>> §5.2: I don't think the term "edge proxy" captures the idea
>>>>>>>>>> that we are
>>>>>>>> talking about an intermediary immediately adjacent to an endpoint.
>>>>>>>>>> 
>>>>>>>>>> §6.4: comma splice
>>>>>>>>>> 
>>>>>>>>>> §7: This section should come before the security considerations.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> insipid mailing list
>>>>>>>>>> insipid@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>