[Insipid] last call for draft-ietf-insipid-logme-marking-11

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

I happened to see the Gen-Art last call review of
draft-ietf-insipid-logme-marking-11.  It looks like a useful tool if we
can get people to use it.  But it seems to me that the draft could use
some work in the following way:

The draft seems to be deeply oriented toward making logging working well
in situations that span multiple networks, and in particular, where the
UAs may not actually support "logme", but rather intermediaries provide
logme support on behalf of the UAs.  This requires a lot of discussion
of course.

But the draft doesn't pay enough attention to the numerous situations
where one dialog is replaced by, or otherwise related to, another.  A
lot of services, when implemented in SIP, result in generating new
dialogs, often replacing old ones.  For example, suppose a dialog is
operating with "logme", and an INVITE-with-Replaces arrives at one of
the UAs, *without* "logme".  What should happen?  Naively, you would
think that the new dialog should be logged, but there's no way for the
UAS of INVITE-with-Replaces to initiate "logme" in that dialog.

Seemingly related to this lack of attention is:

   3.3.  Identifying Test Cases

   The local Universally Unique Identifier (UUID) portion of Session-ID
   [RFC7989] in the initial SIP request of a dialog is used as a random
   test case identifier.  This provides the ability to collate all
   logged SIP requests and responses to the initial SIP request in a
   dialog or standalone transaction.

This overlooks that requests generated by one UA have one local UUID in
Session-ID, while requests generated by the other UA have a different
local UUID.  And the various dialogs in a call transfer will have
various combinations of UUIDs; there will be no single UUID that all of
the requests involved will share.  This isn't insurmountable -- all
practical SIP debugging tools have ways of accumulating the identifiers
of a related set of dialogs -- but the fact that the draft doesn't
recognize that complexity suggests that the consequences of that for
"logme" haven't been thought through.

Dale