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

The INSIPID charter has been extended to include this work.

It would be good to see discussion of this draft on the list, or alternatively, if any of you think you can better this with an alternative, the submission of your own draft.

We haven't decided when yet, but at some point we will have a call to make a requirements draft a working group document.

Regards

Keith 

> -----Original Message-----
> From: insipid-bounces@ietf.org 
> [mailto:insipid-bounces@ietf.org] On Behalf Of Dawes, Peter, 
> Vodafone Group
> Sent: 18 October 2013 12:14
> To: Paul Kyzivat; insipid@ietf.org
> Subject: 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
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid
> 