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

Hi Peter,

A few followups.

On 7/31/13 8:31 AM, Dawes, Peter, Vodafone Group wrote:
> 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.

OK. The issue is new state that must be retained to support this draft.

And its more of an issue for proxies, because proxies usually hold less 
state. (Many are not dialog stateful.)

> 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.

I don't recall why I mentioned this.

> 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.

That defines a file format, not a protocol. You could potentially 
specify a protocol that can carry a file in CLF format.

> 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.

This is entangled with choosing the protocol for transmission.

> 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.

	Thanks,
	Paul

> 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
>