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

["Dawes, Peter, Vodafone Group" <[e-mail]>]

Hi Dale,
Thanks for checking draft -11 and for your comments. Regarding related dialogs, the draft has section 3.7 (opening paragraph copied below). Section 3.7 also includes a signalling example with REFER and points out how UUIDs can be used to link sessions together ("dialog3 is not logged by Alice's terminal, however the test case identifier ab30317f1a784dc48ff824d0d3715d86 is also the test case identifier local-uuid) in INVITE F5.  Also, the test case identifier of dialog2, which is logged by Alice's terminal, can be linked to dialog1 and dialog3 because the remote-uuid component of dialog2 is the test case identifier ab30317f1a784dc48ff824d0d3715d86"). 

Session-ID must be supported for logme, so implementers will need to understand RFC 7989 and its concept of related sessions. 

Regards,
Peter

3.7.  Marking Related Dialogs


   "Log me" marking is done per-dialog and typically begins at dialog
   creation and ends when the dialog ends.  However, dialogs related to
   a "log me" marked dialog MAY also be "log me" marked.  An example is
   call transfer described in section 6.1 of [RFC5589] and the logged
   signaling for related dialogs can be correlated using Session-ID
   values as described in section 10.9 of [RFC7989].

> -----Original Message-----
> From: Dale R. Worley <[e-mail]>
> Sent: 13 July 2018 04:27
> To: [e-mail]; [e-mail]
> Subject: last call for draft-ietf-insipid-logme-marking-11
> 
> 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