Subject: [dispatch] New Version Notification for draft-kaithal-dispatch-sip-log-information-00.txt

From: "Adarsh Kaithal (akaithal)" <[email-masked]>
Date: Thu, 13 Oct 2011 12:10:14 +0530

Hi All

Introduction of the draft:-

The current mechanisms to debug issues in SIP network are not very

efficient.  It requires to enable debugging logs across different

devices, recreate the problem and then collect the logs.  The idea is

to provide a solution to automatically enable relevant logs (SIP

messages and any other debugging logs meaningful to SIP devices), and

also to indicate where the logs are to be collected or stored.  The

enabling of logs will happen at all the SIP devices(upstream or

downstream).  This will help to get the logs from all the SIP devices

in a Common logging format (CLF).  The solution extends SIP to

provide the infrastructure to enable logging for upstream and

downstream devices with each server deciding how much troubleshooting

information it wants to log - with freedom to simply ignore requests

if required.  This document specifies a new header called "Log-Me"
Header

in all the SIP messages

Link to the draft:- 

http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt

Let me know if the working group is interested to solve this problem and
comments on the draft.

Best Regards,

Adarsh

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Oct 2011 10:40:39 +0200

Can I draw your attention to

http://tools.ietf.org/html/draft-dawes-sipping-debug-04

which I believe was a similar attempt to resolve this problem.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adarsh Kaithal (akaithal)
Sent: 13 October 2011 07:40
To: [email-masked]
Subject: [dispatch] New Version Notification for draft-kaithal-dispatch-sip-log-information-00.txt

Hi All

if required.  This document specifies a new header called "Log-Me" Header

in all the SIP messages

Link to the draft:-

Let me know if the working group is interested to solve this problem and comments on the draft.

Best Regards,
Adarsh

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 13 Oct 2011 12:58:29 -0500

> efficient. It requires to enable debugging logs across different
[...]

Adarsh: I am sure you are aware of the working going on in SIPCLF
[1]...while your draft mentions "Common Logging Format", I am
not sure whether you meant the SIPCLF or not.

And, one more comment --- in the Security Considerations section,
mandating TLS does not appear to do much good.  A SIP entity can
operate over TLS but end up sending the log to a recipient
using cleartext smtp/ftp/http/tftp thereby negating the benefits
of TLS.

[1] http://datatracker.ietf.org/wg/sipclf/

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Adarsh Kaithal (akaithal)" <[email-masked]>
Date: Fri, 14 Oct 2011 10:10:48 +0530

Hi Keith,

We have already looked in to this before starting with the new one.

The approach on the new draft is different but I agree the goal is same.

I would request you to go through the new draft and let me know your
comments.

Thanks,

Best Regards,

Adarsh

From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, October 13, 2011 2:11 PM
To: Adarsh Kaithal (akaithal); [email-masked]
Subject: RE: New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

Keith

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adarsh Kaithal (akaithal)
Sent: 13 October 2011 07:40
To: [email-masked]
Subject: [dispatch] New Version Notification for
draft-kaithal-dispatch-sip-log-information-00.txt

Hi All

in all the SIP messages

Link to the draft:- 

Best Regards,

Adarsh

---

From: "Sandeep K.S (sandks)" <[email-masked]>
Date: Fri, 14 Oct 2011 20:09:41 +0530

Hello Vijay,

Thanks for your review and the comments.

Our responses to your comments are below:

1. Adarsh: I am sure you are aware of the working going on in SIPCLF
[1]...while your draft mentions "Common Logging Format", I am
not sure whether you meant the SIPCLF or not.
<sandeep> By "Common Logging Format", we are actually referring to the
work being done as part of SIPCLF WG itself. We could probably add a
citation to the WG here for more clarity.

2. And, one more comment --- in the Security Considerations section,
mandating TLS does not appear to do much good.  A SIP entity can
operate over TLS but end up sending the log to a recipient
using cleartext smtp/ftp/http/tftp thereby negating the benefits
of TLS.
<sandeep> In section 4. Applicability Statement, we have already
mentioned this - " 5) If SIP signaling is secure then logging MUST be
secure.".
 Also as part of the log-type in the ABNF, we have specified sftp as one
of the logging methods, and have provided provision to support any other
(secure) mechanism via the 'other-type' log-type option. So with this,
we are insisting that if SIP signaling is via TLS, then the logging MUST
use sftp or any other secure mechanism.

Hope the responses have clarified your doubts.

Regards
Sandeep

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vijay K. Gurbani
Sent: Thursday, October 13, 2011 11:28 PM
To: [email-masked]
Subject: Re: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

[...]

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 14 Oct 2011 20:59:08 +0530

Adarsh,

I skimmed through your draft. IIUC, your intention is to log SIPCLF
messages in all SIP devices during the session, SIPCLF with session-id
(dialog-id) will serve the purpose to collect the session in all the SIP
devices, "Log-me" header is used to enable the logging mechanism in each
SIP devices dynamically.  I like the idea in high level but the draft
has lot of loose ends:

1)      SIP header passing through B2BUA has lot of challenges because
lot of SIP services enables specific services which results in zero or
one or more messages is the other side of the B2BUA. Session-id is the
crucial for this work to move ahead but Dispatch has to first dispatch
session-id WG first.  For the time being, let us assume the world is
full of SIP proxy, then dialog-id shall be used as unique id to identify
the dialog.

2)      "Log-me" MUST NOT direct the other device to use the logging
type (tftp, sftp) because it involves the device control of another SIP
entity. In case device control is desired as part of this functionality,
there is an ongoing dispatch discussion on device control whose
mechanism has to integrated into this header. IMO, device control should
not integrated with this. Let implementers choose their own mechanism as
a starting point.

3)      SIP primitives like REFER, join has to be well defined. "Log-me"
may not pass across automatically.

4)      There is no stopping "logging" mechanism within the dialog 

5)      How this header applies to SUBSCRIBE, REGISTER, PUBLISH, OPTIONS

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adarsh Kaithal (akaithal)
Sent: Thursday, October 13, 2011 12:10 PM
To: [email-masked]
Subject: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

Hi All

in all the SIP messages

Link to the draft:- 

Best Regards,

Adarsh

---

From: "Adarsh Kaithal (akaithal)" <[email-masked]>
Date: Tue, 18 Oct 2011 10:27:25 +0530

Hi Partha,

Thanks for your comments.

It is good to have session-id , it will solve our purpose  and we can
use this to indentify the session end to end. 

Please see the response inline.

Best Regards,

Adarsh

From: Ravindran Parthasarathi [mailto:[email-masked]] 

Sent: Friday, October 14, 2011 8:59 PM

Subject: RE: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

Adarsh,

1) SIP header passing through B2BUA has lot of challenges because lot of
SIP services enables specific services which results in zero or one or
more messages is the other side of the B2BUA. Session-id is the crucial
for this work to move ahead but Dispatch has to first dispatch
session-id WG first.  For the time being, let us assume the world is
full of SIP proxy, then dialog-id shall be used as unique id to identify
the dialog.

[Adarsh] I agree, I have put a clause of B2BUA not to remove the
"Log-Me" header. It can add one of its own but have to have same tag to
match the call <have to put this in draft> .

2) "Log-me" MUST NOT direct the other device to use the loSessgging type
(tftp, sftp) because it involves the device control of another SIP
entity. In case device control is desired as part of this functionality,
there is an ongoing dispatch discussion on device control whose
mechanism has to integrated into this header. IMO, device control should
not integrated with this. Let implementers choose their own mechanism as
a starting point.

[Adarsh] This is not a device control. I am putting data to use those
server to put the logs that it. There is nothing like controlling the
device. 

3) SIP primitives like REFER, join has to be well defined. "Log-me" may
not pass across automatically.

[Adarsh] "Log-Me" is an optional header and it can present REFER and
JOIN, if it present in the REFER the subsequent  INVITE etc should have
the "LOG-Me" as well. I will explain more about Join in the draft.

[Adarsh] I have not provided that mechanism purposefully as I have put a
applicability statement "Each entity is free to simply ignore request ,
if it is not interested in log collection, or busy with other
activities." As this is call based so one complete dialog will be
logged, I did not find much use of stop logging mechanism within the
dialog. It will be over kill.

[Adarsh] yes it is applicable for SUBSCRIBE, REGISTER and OPTION. I need
to thing about PUBLISH use cases before adding it in the RFC.

Thanks

Partha

To: [email-masked]

Hi All

in all the SIP messages

Link to the draft:- 

Best Regards,

Adarsh