Re: [Insipid] draft-dawes-dispatch-logme-reqs after IETF#88

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Tue, 11 February 2014 10:05 UTC

Return-Path: <Peter.Dawes@vodafone.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029B71A07D0 for <insipid@ietfa.amsl.com>; Tue, 11 Feb 2014 02:05:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham
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 9KYJoiVNv7WP for <insipid@ietfa.amsl.com>; Tue, 11 Feb 2014 02:04:59 -0800 (PST)
Received: from mailout09.vodafone.com (mailout09.vodafone.com [195.232.224.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1194E1A07E0 for <insipid@ietf.org>; Tue, 11 Feb 2014 02:04:59 -0800 (PST)
Received: from mailint09.vodafone.com (localhost [127.0.0.1]) by mailout09.vodafone.com (Postfix) with ESMTP id 3A0F0E1A77 for <insipid@ietf.org>; Tue, 11 Feb 2014 11:04:51 +0100 (CET)
Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint09.vodafone.com (Postfix) with ESMTPS id 255E4E1A75; Tue, 11 Feb 2014 11:04:51 +0100 (CET)
Received: from VOEXC21W.internal.vodafone.com (145.230.103.126) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.146.2; Tue, 11 Feb 2014 11:04:50 +0100
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.123]) by VOEXC21W.internal.vodafone.com ([145.230.103.126]) with mapi id 14.03.0146.002; Tue, 11 Feb 2014 11:04:49 +0100
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 after IETF#88
Thread-Index: Ac8S4EdE5CU+hhHLR+GO87oHorGijQAF//+ZAAIkjeABOfRl8AAZOl4AAo2vTvAABCFmAAEenRhw
Date: Tue, 11 Feb 2014 10:04:49 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D997397E9C4@VOEXM31W.internal.vodafone.com>
References: <4A4F136CBD0E0D44AE1EDE36C4CD9D997394ABE4@VOEXM31W.internal.vodafone.com> <201401162019.s0GKJQHH012866@rcdn-core2-3.cisco.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D997394AD08@VOEXM31W.internal.vodafone.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D997394C66D@VOEXM31W.internal.vodafone.com> <52E13F82.10701@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D997395E62D@VOEXM31W.internal.vodafone.com> <52F27E08.3090904@alum.mit.edu>
In-Reply-To: <52F27E08.3090904@alum.mit.edu>
Accept-Language: en-GB, de-DE, 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 after IETF#88
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 11 Feb 2014 10:05:03 -0000

Hello Paul,
Thanks for the guidance. For my needs, it is not essential to specify how to transmit or access logs. I will revise http://www.ietf.org/id/draft-dawes-insipid-logme-solutions-00.txt and take out text about sending logs to a server that was left in the example solutions. 

Regards,
Peter

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] 
Sent: 05 February 2014 18:08
To: Dawes, Peter, Vodafone Group; insipid@ietf.org
Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs after IETF#88

On 2/5/14 10:45 AM, Dawes, Peter, Vodafone Group wrote:
> Hello Paul,
> Thanks for reviewing the draft. In 
> http://www.ietf.org/id/draft-dawes-insipid-logme-solutions-00.txt

I have tried to leave all of the text about sending logged information to a server as descriptive because the related requirement is not currently in the requirements draft.

(was REQ9: A log-me marker may include a locator of the server that collects logs.  This locator is known as the diagnostic server identifier and may be an address of a server.  A SIP entity can use the diagnostic server identifier to send collected logs to the diagnostic
server.)

Therefore the solutions draft does not describe the protocol details of sending logs or the related security. Three alternative next steps are possible

(1) REQ 9 or similar gets re-instated and I define log sending and security

(2) a requirement is agreed that SIP entities send some kind of flag to a debug server to indicate that they have a log to collect

(3) collection of logs is left outside the scope of log-me.
>
> To me it would seem that (1) is possible to specify, for example regarding your questions:
> [And how do they discover where to send it, and what protocol to use 
> to do so?] the server address could be carried along with the logme 
> marker. The protocol could be mandated as e-mail (mailto:) [How do the servers establish trust in this destination when sending logs? Is 6.2.2 the whole story? (That doesn't seem very practical.)] Maybe a simple way is to have a white list of domain names on the sending entity [Since you have said the logs are to be encrypted, *how* are they encrypted so that the server can decode and others cannot?] I imagine that many methods are possible e.g. TLS or some kind of public key encryption but I would need to consult experts on the best way to do it.
>
> Do you think (1) is possible to specify, or does transmitting logs securely and to the right destination pose too many problems?

I don't see much difference between (1) and (2) from a standardization perspective. (2) still requires sending *something*, so you still need to specify a protocol. It just decomposes the problem into two steps. I think you would still need to specify both of those.

It would certainly be simpler to do *nothing* about transmitting or accessing the logs. I don't know if that meets your needs.

If you need to do something, it is certainly possible to define. It will be more work - I think substantially more.

You might consider publishing something without this, but with an extensibility hook that allows you to then do more work for the log transmission.

But I am fundamentally opposed to defining a parameter for this without specifying any semantics for the identifier.

	Thanks,
	Paul

> Regards,
> Peter
>
>
> -----Original Message-----
> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul 
> Kyzivat
> Sent: 23 January 2014 16:13
> To: insipid@ietf.org
> Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs after IETF#88
>
> Some questions about this draft:
>
> Solution A:
>
>      User agents and SIP proxies may send logged information to a debug
>      server.
>
> And how do they discover where to send it, and what protocol to use to do so?
>
> Solution B:
>
>      Call-Info: mailto:"SIP logging"<siplogs@d1.foocorp.com>;
>                 purpose="debug"
>
> Is the use of a mailto URL normative, or just an example?
>
> How do the servers establish trust in this destination when sending 
> logs? Is 6.2.2 the whole story? (That doesn't seem very practical.)
>
> Since you have said the logs are to be encrypted, *how* are they encrypted so that the server can decode and others cannot?
>
> How should the log be formatted within the mail? How is the test case name included in the mailed log?
>
> Solution C:
>
> As with solution A, how is the log sent?
>
> 	Thanks,
> 	Paul
>
>
> On 1/22/14 10:38 PM, Dawes, Peter, Vodafone Group wrote:
>> Hello All,
>> I have submitted the draft below which describes a solution to the log me requirements and gives a few specific protocol options (the ones that were in clause 7 of the requirements draft reviewed in Vancouver) that could be used to code a log-me marker.
>
>>
>> http://www.ietf.org/id/draft-dawes-insipid-logme-solutions-00.txt
>>
>> This draft has more protocol description than was previously in the requirements draft and tries to give a complete picture of what user agents and SIP proxies need to do to provide log-me marking. It would be good if I could present this solutions draft at IETF#89 for insipid to discuss.
>>
>> Rgds,
>> Peter
>>
>>
>> -----Original Message-----
>> From: Dawes, Peter, Vodafone Group
>> Sent: 17 January 2014 05:22
>> To: 'James Polk'
>> Cc: DRAGE, Keith (Keith) (keith.drage@alcatel-lucent.com); 
>> insipid@ietf.org; Gonzalo Salgueiro (gsalguei@cisco.com)
>> Subject: RE: [Insipid] draft-dawes-dispatch-logme-reqs after IETF#88
>>
>> Thanks James, now submitted as draft-dawes-insipid-logme-reqs-00:
>>
>> http://datatracker.ietf.org/doc/draft-dawes-insipid-logme-reqs/
>>
>> Peter
>>
>> -----Original Message-----
>> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of James 
>> Polk
>> Sent: 16 January 2014 20:19
>> To: Dawes, Peter, Vodafone Group
>> Cc: DRAGE, Keith (Keith) (keith.drage@alcatel-lucent.com); 
>> insipid@ietf.org; Gonzalo Salgueiro (gsalguei@cisco.com)
>> Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs after IETF#88
>>
>> Peter
>>
>> To be blunt, if you seriously want this draft to be considered for INSIPID WG adoption you need to put "-insipid-" in the filename, and stop putting "-dispatch-" in the filename.
>>
>> Linking the drafts is simple work for the chairs to do, if that's your concern.
>>
>> James
>>
>> At 11:31 AM 1/16/2014, Dawes, Peter, Vodafone Group wrote:
>>> Hello All,
>>> Following up from IETF#88 I have uploaded a revised logme 
>>> requirements draft (version -04).
>>>
>>> https://datatracker.ietf.org/doc/draft-dawes-dispatch-logme-reqs/
>>>
>>> As per the comments in Vancouver, version -04 does not include REQ9 
>>> regarding a logging server address and the related sub-clause 6.2.2.
>>> Also, clause 7 on potential solutions has been removed. These 
>>> requirements seem to be stable now.
>>>
>>> I will upload a related solutions draft by the end of next week 
>>> (Friday
>>> 24) at the latest and I hope we can discuss solution options here on 
>>> the list and then later on at IETF#89 at the beginning of March.
>>>
>>> Regards,
>>> Peter
>>> _______________________________________________
>>> insipid mailing list
>>> insipid@ietf.org
>>> https://www.ietf.org/mailman/listinfo/insipid
>>
>> _______________________________________________
>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid
>> _______________________________________________
>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid
>>
>
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid
>