Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Wed, 31 July 2013 12:34 UTC

Return-Path: <Peter.Dawes@vodafone.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 C324B11E81A3 for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 05:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.486
X-Spam-Level:
X-Spam-Status: No, score=-4.486 tagged_above=-999 required=5 tests=[AWL=-2.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWXimadsgkOB for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 05:34:38 -0700 (PDT)
Received: from mailout11.vodafone.com (mailout11.vodafone.com [195.232.224.80]) by ietfa.amsl.com (Postfix) with ESMTP id DF41611E818F for <insipid@ietf.org>; Wed, 31 Jul 2013 05:32:08 -0700 (PDT)
Received: from mailint11.vodafone.com (localhost [127.0.0.1]) by mailout11.vodafone.com (Postfix) with ESMTP id 8C13E2A09BF for <insipid@ietf.org>; Wed, 31 Jul 2013 14:31:55 +0200 (CEST)
Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint11.vodafone.com (Postfix) with ESMTPS id 7B17B2A0836; Wed, 31 Jul 2013 14:31:55 +0200 (CEST)
Received: from VOEXC11W.internal.vodafone.com (145.230.101.13) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 31 Jul 2013 14:31:55 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.36]) by voexc11w.internal.vodafone.com ([145.230.101.13]) with mapi id 14.03.0146.002; Wed, 31 Jul 2013 14:31:54 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)
Thread-Index: AQHOh090Gf3fTJI8hUe/mT1XtHhuh5l9lmLQ
Date: Wed, 31 Jul 2013 12:31:53 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com>
References: <51EDEF82.3060908@alum.mit.edu>
In-Reply-To: <51EDEF82.3060908@alum.mit.edu>
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
Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 31 Jul 2013 12:34:44 -0000

Hello Paul,
Thanks for the questions, I can add some discussion of these points by expanding on the potential solutions clause 7 in the next version of the draft. Extra text will be along the lines of the answers below.
 
1) For "when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time."
The stateful entities can be the sending and receiving UA, and a SIP proxy if the UAs do not insert and echo the log-me marker (REQ5, REQ6). I can describe this behaviour in the potential solutions.
How logging stops is hinted at in clause 4 but I can give examples in the potential solutions. I do not propose that the draft specifies how logging is configured to be started and stopped though, the main focus of the draft is to add a marker for sessions of interest to logging. 

2) For " Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers."
These are good questions, it might well be that the Session-ID: value becomes the test case identifier. 

3) For protocol to transmit the logs, RFC 6872 "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model" has been suggested so I will look into this. 

4) For " trust by the server doing the logging of the log server, and authorization by the log server of those sending logs " I think mechanisms exist for mutual authentication of sender and receiver so I can add something.

I will also try to ensure that the descriptions of proposed solutions cover all aspects of the draft (log server, test case id) and thanks for spotting the syntax error in Fig. 3.

Regards,
Peter

-----Original Message-----
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 23 July 2013 04:51
To: insipid@ietf.org
Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)

Some questions about this draft:

The requirements and other discussion imply certain behavior by servers that support this. I'd like to hear more explicit discussion of what that expected behavior is, within the potential solutions.

E.g., when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time.

Section 7.1:

This says the header is first inserted by the UAC. There might be reason to have it inserted by the UAS in some cases, or even a proxy or B2BUA based on policy for debugging a UA that can't be controlled.

Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers.

I want to hear more about sending the address of the server collecting logs. For this to be useful there must be an explicit or implicit protocol used to transmit the logs. Is there one such protocol or many? 
If many, how do you know which will be supported? What about trust by the server doing the logging of the log server, and authorization by the log server of those sending logs? Will all servers doing logging want to use a server chosen by the one inserting the logme request?

Section 7.2:

Where does the test case id go with this solution?

In Figure 3 the call-info in the figure is syntactically incorrect. The parameter is a domain name, but it is required to be a URL.

	Thanks,
	Paul
_______________________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid