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

[Paul Kyzivat <[e-mail]>]

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:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: 23 January 2014 16:13
> To: [e-mail]
> 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"<[e-mail]>;
>                 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) ([e-mail]);
>> [e-mail]; Gonzalo Salgueiro ([e-mail])
>> 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:[e-mail]] On Behalf Of James
>> Polk
>> Sent: 16 January 2014 20:19
>> To: Dawes, Peter, Vodafone Group
>> Cc: DRAGE, Keith (Keith) ([e-mail]);
>> [e-mail]; Gonzalo Salgueiro ([e-mail])
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/insipid
>>
>> _______________________________________________
>> insipid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/insipid
>> _______________________________________________
>> insipid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/insipid
>>
>
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
>