Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 1 Sep 2016 17:39:37 +0000

This is a friendly reminder to the WG that WGLC ends on Friday September 9th.  Please send any comments prior to that.

Thanks,

Gonzalo

> On Aug 20, 2016, at 1:18 AM, Gonzalo Salgueiro (gsalguei) <[email-masked]> wrote:
> 
> Dear INSIPID Participants, 
> 
> We have finally completed the Session-ID draft and it is now in the RFC Editor’s queue. It is now time to move forward with the completion of the pending bottlenecked milestones. The first one of these is draft-ietf-insipid-logme-reqs, which has previously received sufficient review and currently has no pending unaddressed issues.
> 
> This message begins a Working Group Last Call on draft-ietf-insipid-logme-reqs-07 (https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-07), to end on Friday September 9th, 2016. Please post comments and feedback to the [email-masked] list, including just a simple "looks good” if you have read the draft and have no material comments.
> 
> I kindly request the authors to please address any WGLC comments in a timely fashion.
> 
> It is my hope we can muster the energy for a final push to finish up the two remaining milestones and then close out this WG.
> 
> Regards, 
> 
> Gonzalo (as chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 1 Sep 2016 14:47:03 -0400

Here are some comments on the document:

* Section 4:

I'm not clear of the intent of this section. It doesn't seem to include 
requirements, yet it has normative statements. It reads more like a 
mechanism.

I think this section should be rewritten. Perhaps as a set of 
assumptions/prerequisites for the environment where you are seeking a 
solution.

* Section 5:

I think the requirements in this section are a bit mixed up. Some are 
requirements that are to be met by a log-me *mechanism*. Others seem to 
be requirements that should be levied by a log-me mechanism on those who 
are implementing the mechanism. These are both useful things, but they 
are different. Perhaps they should be in two separate lists.

* REQ2

This talks about "network boundaries". I think more definition is needed 
to clarify exactly what constitutes a network boundary and what the 
impediments are for something to cross it. (Perhaps by referencing RFC7092.)

* REQ3 (and section 6.1)

Do you have a particular definition of "trust domain" in mind? Again, I 
think some sort of definition is needed.

Also, more discussion of motivation for removing at trust domains is 
needed. IMO there is often little motivation for removing the marking on 
*exit* from a trust domain, and in fact good reason for not doing so. 
OTOH, there may indeed be good reason for removing from a request that 
is *entering* a trust domain. (And some might want to remove the 
indicator on exit in order to ensure that neighbors *aren't* aware they 
are debugging.)

* REQ6/7

Do you really mean *proxy*? I suspect you really mean *intermediary*, 
including both proxies and B2BUAs?

	Thanks,
	Paul

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 7 Sep 2016 14:39:58 +0000

Hello Paul,
Thanks very much for your review comments and suggestions, the authors will discuss and try to resolve them in the next version. I have outlined my thoughts on resolving the comments in-line below.

Regards,
Peter

> -----Original Message-----
> From: insipid [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 01 September 2016 19:47
> To: [email-masked]
> Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
> 
[PD] Section 4 is currently a mixture of describing the motivating scenario, some pre-requisites (such as logging ends when a dialog ends) and requirements that do not apply to the logme marker itself. We can try to better group these aspects.

> are implementing the mechanism. These are both useful things, but they are
> different. Perhaps they should be in two separate lists.
[PD] We can try to group the requirements by who or what they impact.

> 
> * REQ2
> 
> This talks about "network boundaries". I think more definition is needed to
> clarify exactly what constitutes a network boundary and what the
[PD] We can revise REQ2 to make the scenarios clear, perhaps by a combination of referring to some of the figures in RFC5853, which has many examples of network boundaries  even though it does not use the term "network boundary", and giving the RFC7092 categories of B2BUA that could manipulate the logme marker in SIP. 
> 
> * REQ3 (and section 6.1)
> 
> Do you have a particular definition of "trust domain" in mind? Again, I think
> some sort of definition is needed.
> 
[PD] We can define trust domain as it applies to these requirements. A trust domain contains all SIP entities under configuration control of the network operator that is performing (e.g.) regression testing plus all SIP entities that are under configuration control of peer network operators who have agreed to participate in that (e.g.) regression testing. The purpose of trust domain requirements is to prevent network operators inadvertantly triggering logging in networks that are not part of any testing or troubleshooting. 
 
> Also, more discussion of motivation for removing at trust domains is needed.
> IMO there is often little motivation for removing the marking on
> OTOH, there may indeed be good reason for removing from a request that is
> *entering* a trust domain. (And some might want to remove the indicator
> on exit in order to ensure that neighbors *aren't* aware they are
> debugging.)
[PD] We can clarify the role of trust domains.
> including both proxies and B2BUAs?
[PD] "proxies" was used to make it clear that SIP entities that are currently stateless are able to implement logme and still stay stateless. We can consider the B2BUA types in RFC7092 to see whether this wording needs to cover some subtleties of intermediary types.  
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 7 Sep 2016 10:48:42 -0400

> Thanks very much for your review comments and suggestions, the authors will discuss and try to resolve them in the next version. I have outlined my thoughts on resolving the comments in-line below.

Sounds good. I'll keep an eye out for the next version.

	Thanks,
	Paul

---

From: Paul Giralt <[email-masked]>
Date: Wed, 14 Sep 2016 12:46:47 -0400

Sorry for the delay in commenting. Here’s some feedback:

Abstract: It states "that marks the PDU as a candidate for logging”. Does this really just mark the particular message for logging or does it mark the entire session for logging? Section 4 says "Subsequent responses and requests in the same dialog are logged” which means to me that the indicator affects the logging of more than just the PDU, but then Section 5, REQ7 makes it possible for stateless intermediaries to only log based on the presence of the marker. Then REQ9 makes it seem like the marker must be present in all messages in the dialog.

Section 1 Introduction: Why are we singling out service providers? Wouldn’t this be useful in large enterprise environments as well?

Section 4: This was already mentioned, but requiring that messages be logged in their long form doesn’t seem like a good idea to me. This could be computationally intensive and what is the reason for the failure is that a device is not handling headers in their compact form correctly? Seems like we should try to preserve as much of the original, raw message as possible.

Section 5, REQ 5: What about new requests within the same dialog / session (e.g. ACK or re-INVITE)? I think those should also include the log me marker as well.

REQ8: Should update to latest session-id draft. Also, I have some concerns about using Session-ID as the test case identifier. The Session-ID can change (in fact will change for every session because the initial INVITE will have a null remote UUID).

6.2.1 - “MUST not” should be “MUST NOT”

Also, there is a non-normative use of “must” and “must not” in this section. Is that intentional? Does the debugging configuration have to be supplied by a server? Can the debug configuration not be done locally on the terminal?

Same thing with the logs. Do they have to be sent to a server? Can they just be retained locally on the terminal?

I only see mention of Proxies, but not other intermediaries such as B2BUA’s. I think there should be some call out to be encompassing of all intermediaries.

-Paul

> This message begins a Working Group Last Call on draft-ietf-insipid-logme-reqs-07 (https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-07 <https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs>), to end on Friday September 9th, 2016. Please post comments and feedback to the [email-masked] <mailto:[email-masked]> list, including just a simple "looks good” if you have read the draft and have no material comments.
>

---

From: "Arun Arunachalam (carunach)" <[email-masked]>
Date: Wed, 14 Sep 2016 22:36:50 +0000

Thanks for the feedback Paul !

Please see inline.

On Sep 14, 2016, at 12:46 PM, Paul Giralt (pgiralt) <[email-masked]<mailto:[email-masked]>> wrote:

The marking applies to an individual message but the originating UA / proxy adds the logme marker for all messages in a session.

I think the Service provider was the initial use case. Yes, its applicable within large enterprise networks as well. We can broaden the use case.

Good point.

I think REQ 9 address this scenario - "If applied, "log me" marking MUST begin with the dialog-creating request and SHOULD continue to the dialog end.”

How about using the local UUID of the Session-ID generated by the originating UA / proxy as a test identifier (if the admin wants the system to auto-generate a test ID)?

Agree. The key is to have the action that enables “logme” to be authorized. There are different ways the action could be taken - through local terminal, api etc..

Regarding logs, looks like we didn't update 6.2.1 when we added the following text.

      When and how signalling logs are retrieved is out of scope of this
      document.  Logs might be retrieved by logging on to the SIP entity
      that contains the logs, by sending logs to a central server that
      is co-ordinating debugging, by storing them on removable media for
      later manual collection, or by some other method.

We will update this section.

We plan to include B2BUA / intermediaries, gateways in the next version based on input from Alberto Llamas.

Thanks!
Arun

-Paul

On Aug 20, 2016, at 1:18 AM, Gonzalo Salgueiro (gsalguei) <[email-masked]<mailto:[email-masked]>> wrote:

This message begins a Working Group Last Call on draft-ietf-insipid-logme-reqs-07 (https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-07<https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs>), to end on Friday September 9th, 2016. Please post comments and feedback to the [email-masked]<mailto:[email-masked]> list, including just a simple "looks good” if you have read the draft and have no material comments.

Regards,

Gonzalo (as chair)
_______________________________________________
insipid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/insipid

---

From: Paul Giralt <[email-masked]>
Date: Wed, 14 Sep 2016 19:30:58 -0400

Thanks Arun. See below…

> On Sep 14, 2016, at 6:36 PM, Arun Arunachalam (carunach) <[email-masked]> wrote:
> 

I think using just the local UUID makes more sense because this will be consistent throughout the life of the session as long as the originating endpoint is still in the call. It’s possible that some B2BUA could remove the originator from the session (e.g. call gets transferred) but at that point, the device that requested the session be logged is no longer in an active session anyway.

That said, what if the admin doesn’t want the system to auto-generate a test ID? Where would that go? The local UUID must be in a very specific format to comply with drafy-ietf-insipid-session-id, so you can’t put any arbitrary text in for the local UUID. I think either you need to stipulate that the test ID will always be automatically generated or find some other place to put it.

Also, should intermediaries be required to or at least allowed to continue indicating log me markings on other messages related to the session even if the originating device is no longer participating in the session?

-Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 16 Sep 2016 05:33:43 +0000

Hi -

This concludes the WG LC for draft-ietf-insipid-logme-reqs<https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-07>.  Thanks to all who provided review comments.

I request that the authors please work with reviewers on resolving the pending comments that were raised. Once there is consensus on the necessary edits please publish a new version (-08). I’ll review that version and prepare the shepherd write-up in preparation for publication.

Thanks,

Gonzalo

Regards,

Gonzalo (as chair)

---

From: "Arun Arunachalam (carunach)" <[email-masked]>
Date: Thu, 22 Sep 2016 14:13:37 +0000

Hi Paul,

Please see inline.

On Sep 14, 2016, at 7:30 PM, Paul Giralt (pgiralt) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Arun. See below…

On Sep 14, 2016, at 6:36 PM, Arun Arunachalam (carunach) <[email-masked]<mailto:[email-masked]>> wrote:

I think there is value in giving the admin the ability to specify their own identifier.

One option would be to have a user defined test identifier as shown below:

   test-identifier = (alphanum / "_") *(alphanum "_")

If the user defined test identifier is not present, the log analysis server would use the local UUID of the originator’s Session-ID as the test identifier.

This will be useful to perform an end-to-end call flow analysis.

The good thing about originator based log me marking is the “ability / control” to disable logging simply by disconnecting the call at the originator (the device requesting to enable logging).

This control no longer exists if we allow the intermediaries to continue marking even after the originator is no longer in the session.

Thanks!
Arun

-Paul

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Thu, 29 Sep 2016 15:57:48 +0000

Hi Arun,

Sorry for not replying earlier. Inline…

> On Sep 22, 2016, at 10:13 AM, Arun Arunachalam (carunach) <[email-masked]> wrote:
> 
> Hi Paul,
> 
> Please see inline.
> 
>> On Sep 14, 2016, at 7:30 PM, Paul Giralt (pgiralt) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Thanks Arun. See below…
>> 
>>> On Sep 14, 2016, at 6:36 PM, Arun Arunachalam (carunach) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

I like this in concept. The concern I have is whether it meets the privacy requirements stipulated for additional parameters in the Session-ID header. If someone puts a value of the person’s name or perhaps a ticket number, that could be considered personally identifiable information which is not allowed to be present in the Session-ID header. I’m not sure how we’d reconcile these requirements. We may have to just live with the test ID being something random.

> This control no longer exists if we allow the intermediaries to continue marking even after the originator is no longer in the session.

I guess this could be left up to the implementation of the intermediary. It is free to add a logme marker to whatever it wants to, so even if the originator drops off, there is no reason why it can’t add the identifier to related sessions. This is probably something worth mentioning in the draft, but might not be necessary in the requirements doc.

-Paul

---

From: "Arun Arunachalam (carunach)" <[email-masked]>
Date: Thu, 29 Sep 2016 18:13:16 +0000

Thanks Paul !

(1) Agree, let’s have a random test id given REQ 4 of RFC 7206<https://tools.ietf.org/html/rfc7206#section-5>.

(2) We can update REQ 6 as shown below to incorporate your comment:

 REQ6: A SIP intermediary MAY insert a "log me" marker into requests and
      responses.  The typical case for which a intermediary needs to insert a
      "log me" marker is for compatibility with UAs that have not
      implemented "logme" marking, i.e. when a UA has not marked a
      request or when responses received on a dialog of interest for
      logging do not contain an echoed "log me" marker.  Another use
      case is when the session origination UA that inserted log me marker
      is no longer participating in the session (e.g: call transfer scenarios)
      and the intermediary adds "log me" marker in related sessions to enable
      end-to-end signaling analysis. In these cases, the entity that inserts a
      "log me" marker is stateful inasmuch as it must remember when a dialog is
      of interest for logging.  An entity that inserts a "log me" marker
      SHOULD also log the SIP request or response as per REQ4.

Arun

On Sep 29, 2016, at 11:57 AM, Paul Giralt (pgiralt) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Arun,

On Sep 22, 2016, at 10:13 AM, Arun Arunachalam (carunach) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Paul,

Please see inline.

Thanks Arun. See below…

-Paul

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Thu, 29 Sep 2016 18:14:43 +0000

Looks good to me.

-Paul

> On Sep 29, 2016, at 2:13 PM, Arun Arunachalam (carunach) <[email-masked]> wrote:
> 
> Thanks Paul !
> 
> (1) Agree, let’s have a random test id given REQ 4 of RFC 7206 <https://tools.ietf.org/html/rfc7206#section-5>.
> 
>> On Sep 29, 2016, at 11:57 AM, Paul Giralt (pgiralt) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Arun,
>> 
>>> On Sep 22, 2016, at 10:13 AM, Arun Arunachalam (carunach) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Paul,
>>> 
>>> Please see inline.
>>>