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

[[e-mail] (Dale R. Worley)]

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