Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt

Hello Dale,
I think you are right that the UAS (or some entity near it) would have to echo the mark from requests to responses, alternatively at least one entity will have to be stateful and mark requests and responses so I will need to modify REQ4 on that point. Similarly, for requests that have crossed the trust domain boundary and had the log-me marking removed, a SIP entity at the network edge receiving a response would have to be stateful and re-insert the log-me marking. 

Probably the test case identifier could be Session-ID, although it would be convenient for the test equipment to be able to insert its own identifier. I did not expect this test case identifier to have any function in the SIP protocol, its purpose is to help the diagnostic server aggregate logging data. 

The diagnostic server identifier is a locator for a server that is accumulating the logging information and, as you suggest, it would be useful to standardize the manner in which logging information is transmitted to the specified server. I think that draft http://tools.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt suggests something in clause 5 with 

log-type =  "mailto" / "http"/ "syslog" / "tftp" /"ftp" /"sftp" / "local" / other-type

I think you are right that log-me marking will in some cases be inserted by a proxy that handles a UA's requests rather than by the UA itself, so I will make sure that is clear in the requirements.

Thanks for all of the useful pointers.

Regards,
Peter

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. Worley
Sent: 07 December 2012 16:24
To: dispatch@ietf.org
Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt

The situation regarding statelessness seems to me to be unclear.

Marking could be entirely stateless (at least for proxies) if each request and response to be logged was marked.  But to make that work, we require that the UAS (or some entity near it) echoes the mark from requests to responses.  Either we need to codify the mark-echoing, or we need to require proxies be transaction-stateful, in regard to remembering the mark on requests requires logging responses.

At the dialog level, the "Skeleton Diagnostic Procedure" says:

   o  Subsequent responses and requests in the same dialog are logged.

This requires dialog-state in the UAs and intermediate entities, in order to remember to log subsequent requests and responses.  We could avoid requiring the intermediate entities to have dialog-state if we require the UAs to remember that log-me is in effect for the dialog and apply it to all subsequent requests.

Given that log-me marking is removed from requests when they cross trust boundaries, how does a network apply the log-me marking to the corresponding responses when they arrive across the trust boundary?
That can't depend on any marking on the response as supplied by the non-trusting network.

In regard to the test case identifier and the diagnostic server identifier, are these intended to be opaque strings, or what?

If the test case identifier is just to identify the test, its role could be taken by Session-ID.  If it is required that the test equipment can specify the test case identifier, we need a further data item.

In regard to the diagnostic server identifier, is it an opaque string to be interpreted according to an unspecified policy, or is it a locator for a server that is accumulating the logging information?  If the latter, we presumably intend to standardize the manner in which logging information is transmitted to the specified server.

In practice, it would seem to me that operators will often have the log-me market inserted not by the customer's UA but by a proxy that handles the UAs requests.  I don't see that this would cause problems for the design, but it's a use case to keep in mind.

Dale
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch