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

Hi Paul,
I have now updated the requirements draft to -03 (http://www.ietf.org/id/draft-dawes-dispatch-logme-reqs-03.txt) to include the following:

1) For when servers are expected to be stateful and when logging stops, added a new clause for functionality that is common to all solutions
	7.1.  Functionality Common to all Solutions 
       		7.1.1.  Starting and Stopping log-me marking
         			7.1.1.1.  General
         			7.1.1.2.  Configuration for log-me marking
         			7.1.1.3.  Maintaining State

3) For protocol to transmit the logs, I can't think of any consideration that is specific to transmitting logged information so transmission can pick from the same protocol options that are available to transmit any file (ftp, mailto, http...)

4) For " trust by the server doing the logging of the log server, and authorization by the log server of those sending logs " I have added some sub-clauses (6.2.2, 6.2.3) to the Security Considerations clause. I guess that ftp, mailto, http etc. already have defined security solutions for authentication and encryption so I didn't add much detail at this stage to avoid just copying descriptions.

	6.  Security Considerations 
     		6.1.  Trust Domain  
    		 6.2.  Security Threats  
       			6.2.1.  Log-me marking  
       			6.2.2.  Debug server address  
       			6.2.3.  Sending logged information  

5) For where the test case goes in the Call-Info: header field solution in 7.3 (was in 7.2 in version -02) I have stated that using Session-ID is the only possibility and I have corrected the syntax of the Call-Info: header field in Figure 3 to make the domain name a URL.   

Regards,
Peter

-----Original Message-----
From: Dawes, Peter, Vodafone Group 
Sent: 31 July 2013 13:32
To: 'Paul Kyzivat'; insipid@ietf.org
Subject: RE: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid)

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