Subject: [Insipid] Proposed New Requirement: Marking for Logging

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Mon, 26 Mar 2012 19:38:02 +0000

Hello James, All,
Thanks for presenting your requirements draft for the session identifier. The requirement I propose to add is on slide 7 of my presentation in the INSIPID meeting materials (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf) as follows:

"It must be possible to mark a session identifier as inserted for logging purposes"
"...in order to keep network operations and maintenance steps and also SIP entity data volume and processing load to practical levels when troubleshooting"

Slides 1-6 illustrate the reasons behind this proposed requirement.

Regards,
Peter

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Mar 2012 01:21:38 -0400

Peter,

Let me try to understand...

There might be numerous calls happening all the time, but you do not wish to
do logging for all of those calls that appear to be working properly.
However, you'd like to introduce an extra flag that would trigger logging
for a particular session when that flag is set.  So, the logging would turn
on only for flagged calls.  Is that correct?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dawes, Peter, Vodafone Group
> Sent: Monday, March 26, 2012 3:38 PM
> To: James M. Polk; [email-masked]
> Cc: DRAGE, Keith (Keith); Hadriel Kaplan
> Subject: [Insipid] Proposed New Requirement: Marking for Logging
> 
> Hello James, All,
> Thanks for presenting your requirements draft for the session identifier.
> The requirement I propose to add is on slide 7 of my presentation in the
> INSIPID meeting materials
> (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf) as
> follows:
> 
> "...in order to keep network operations and maintenance steps and also SIP
> entity data volume and processing load to practical levels when
> troubleshooting"
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Tue, 27 Mar 2012 05:30:22 +0000

Hi Paul,
Yes that is correct, and having such a flag on the very few calls of interest simplifies the operation of the core network (network entity default behaviour can be to check for the flag and log such signalling). 

Rgds,
Peter 

----- Original Message -----
From: Paul E. Jones [mailto:[email-masked]]
Sent: Tuesday, March 27, 2012 07:21 AM
To: Dawes, Peter, Vodafone Group; 'James M. Polk' <[email-masked]>; [email-masked] <[email-masked]>
Cc: 'DRAGE, Keith (Keith)' <[email-masked]>; 'Hadriel Kaplan' <[email-masked]>
Subject: RE: [Insipid] Proposed New Requirement: Marking for Logging

Peter,

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Mar 2012 19:33:03 +0200

I don't quite get this. It sounds like you are bundling two things that 
don't need to be bundled:
- the session-id
- a request to log the call

I see no need to couple those things. If you can mark the call to be 
logged, and if it happens to have a sesson-id, then there will be data 
about the call, including the session-id, in logs of all the systems 
traversed. But you can still have session-ids without logging, and you 
can have logging without session-ids.

	Thanks,
	Paul

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 28 Mar 2012 15:43:55 +0000

Hello Paul,
One of the use cases of session-id is end-to-end troubleshooting, including when session end points are in different networks, and I believe that the marking is needed to make this troubleshooting practical and scaleable. So I believe these two things need to be bundled.

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 27 March 2012 18:33
To: [email-masked]
Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging

I don't quite get this. It sounds like you are bundling two things that don't need to be bundled:
- the session-id
- a request to log the call

I see no need to couple those things. If you can mark the call to be logged, and if it happens to have a sesson-id, then there will be data about the call, including the session-id, in logs of all the systems traversed. But you can still have session-ids without logging, and you can have logging without session-ids.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Mar 2012 23:06:24 +0200

Peter,

Surely there is a lot of trouble shooting that could proceed using 
session id *without* a way to signal a request to log this call.

The ability to make such a signal might indeed be useful. But its 
separable. It especially doesn't have to be in the same header.

And I expect that if we end up defining a new header for session id, it 
will have an extension point (e.g. parameters) that could be used to 
define such a signal.

	Thanks,
	Paul