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

[Paul Kyzivat <[e-mail]>]

On 10/18/13 7:14 AM, Dawes, Peter, Vodafone Group wrote:
> 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

Thanks, this is better.

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

IIUC, your intent is to put a URL into requests that will be used by 
multiple elements to send their logs. That means:
- it must be a protocol that has a URL
- the URL must not identify a destination that will be overwritten
   each time another server uploads to it.
- the element inserting the URL must have reason to expect that
   all the servers that are doing logging will support that URL format.
- the servers doing the uploading must understand *how* to use
   the protocol of the URL for uploading a file. (E.g., if it is an
   http url, then is a POST used? How is the log file packaged in it?)

I think this means that it will be necessary to specify one or more URL 
formats, and how they should be used for this purpose.

How does this relate to the test name? I would think that maybe the 
place you want to put the test name is in the URL, because its main use 
is probably to identify where it is deposited.

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

Other comments, by section:

Section 6.2.2:

What about change of log server? What should happen if the request that 
initiated logging had one log server URL, and then a subsequent request 
has a different URL? Does the new one just replace the old one, with the 
last one in effect when logging stops being the one that is used? Or are 
changes ignored? Or does a change cause the log to date to be sent to 
the old server and then a new log started that will be sent to the new 
server?

Section 7.1.1:

Another question re ending of logging: Consider a case where a server 
has been getting a LogMe in a particular dialog. Then it stops getting 
it. Should this be an indication that logging should be stopped? Or is 
it to be treated as a case where the upstream element forgot to include it?

Section 7.2.6, Figure 4:

In (1) there is 'debugServer-"d2.foocorp.com"'. There is also a Debug 
Server of d1.foocorp.com in the signaling path. Multiple issues with this:
- it's potentially confusing. Is it intended to imply that the presence
   of this address in the LogMe *caused" the debug server to be in
   the signaling path? I don't think so. I think it is just a coincidence
   of names.

- 'd1.foocorp.com' is not a URL.

- the flow doesn't show the log being sent when logging ends.
   It would be good to show that.

Section 7.3:

a mailto URL does seem like it could serve the purpose better than most 
I can think of.  But the logs could easily become too big to be accepted 
by many mail servers. Conceivably the test id could be encoded in the 
mailbox address. Otherwise I guess you would probably put the session id 
in the subject line of the mail.

	Thanks,
	Paul

> Regards,
> Peter
>
>
> -----Original Message-----
> From: Dawes, Peter, Vodafone Group
> Sent: 31 July 2013 13:32
> To: 'Paul Kyzivat'; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: 23 July 2013 04:51
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
>