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

From: [email-masked] (Dale R. Worley)
Date: Fri, 7 Dec 2012 11:24:29 -0500 (EST)

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

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Mon, 10 Dec 2012 18:08:11 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 07 December 2012 16:24
To: [email-masked]
Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Adarsh Kaithal (akaithal)" <[email-masked]>
Date: Tue, 11 Dec 2012 05:03:37 +0000

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

> From: Dawes, Peter, Vodafone Group [mailto:[email-masked]]
> Sent: Monday, December 10, 2012 11:38 PM
> To: Dale R. Worley; [email-masked]
> 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
> 
> 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.
> 
> 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.
> 
> 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
> 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