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

worley@ariadne.com (Dale R. Worley) Fri, 13 July 2018 02:26 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9D130F06 for <insipid@ietfa.amsl.com>; Thu, 12 Jul 2018 19:26:57 -0700 (PDT)
X-Quarantine-ID: <Gf29OU_m_0gB>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "From"
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Level:
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf29OU_m_0gB for <insipid@ietfa.amsl.com>; Thu, 12 Jul 2018 19:26:56 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F5B130DCF for <insipid@ietf.org>; Thu, 12 Jul 2018 19:26:56 -0700 (PDT)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id dnlBfc9UgZ6PIdnnLfC5FN; Fri, 13 Jul 2018 02:26:55 +0000
Received: from hobgoblin.ariadne.com ([24.91.37.100]) by resomta-ch2-13v.sys.comcast.net with ESMTPA id dnnKf8QhcL5P9dnnKfD9z9; Fri, 13 Jul 2018 02:26:55 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w6D2QrvC025493; Thu, 12 Jul 2018 22:26:53 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w6D2Qrob025488; Thu, 12 Jul 2018 22:26:53 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
From: worley@ariadne.com (Dale R. Worley)
To: draft-ietf-insipid-logme-marking.all@ietf.org, insipid@ietf.org
Sender: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Thu, 12 Jul 2018 22:26:53 -0400
Message-ID: <87k1pzuaz6.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfBROiEC+UHC22mpgnXweL/8S76C6zqplKtrFm/tBSjDQYxHqVEuIeC3WR1eCStl6J8GSw76u7BqIRGa0gIVhTXvqgHjp1g1DIbw+RTSLfMHUM+5p2Zk5 gpmKJ+LwflzCRRytE1CO2cDw///JaJvhvYs3/rEB3DRgLeUfnEw1INCSY5QS+Dpu2Re+OdoNoW8yDakBTb3XrAD9Vra7RKZ0UYA27W9PxsCvYimmqjTDbMsb oZJMMqTBIWJO1GWVm2I2fw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/GvsyPV_NMt-kls36JdPe-Ewp-WA>
Subject: [Insipid] last call for draft-ietf-insipid-logme-marking-11
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 02:26:58 -0000

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