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

Hi Peter,

It will be very important in the cases when intermediated entity (proxy or B2BUA) also try to debug and collect the data for debugging without UA intervention.

Best Regards,
Adarsh

> -----Original Message-----
> From: Dawes, Peter, Vodafone Group [mailto:Peter.Dawes@vodafone.com]
> Sent: Monday, December 10, 2012 11:38 PM
> To: Dale R. Worley; dispatch@ietf.org
> Cc: Adarsh Kaithal (akaithal); Sandeep K.S (sandks)
> Subject: 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