Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

"Arun Arunachalam (carunach)" <> Wed, 14 September 2016 22:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1D6012B0B5 for <>; Wed, 14 Sep 2016 15:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.029
X-Spam-Status: No, score=-16.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FdGy9oISKpzE for <>; Wed, 14 Sep 2016 15:36:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21BA512B0B6 for <>; Wed, 14 Sep 2016 15:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=20330; q=dns/txt; s=iport; t=1473892613; x=1475102213; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MvEmOQcKtDO6y7hTPAt3k+MhTxMMTQ00tDm62Aoc+5A=; b=ODmr3Hi5vVm3H7Tvr4OLFEaWHIkvGejmoD+lHmShDXodz4rUlZW4npA0 BNNVn1fVs0FXDmyzJwOY16HIkpRB4iKhBFT6GQrk54Dg6MuOD989qNIsN 06YqwubTNn19tW1oTAEAMzYmua8bE1t1F0IdDZKkLdzFop5GRTsg2k/pT E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCd0NlX/5JdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzoBAQEBAR5XbQ8HjSymFoUQggMZAQqFMEoCHIExOBQBAgEBAQEBAQF?= =?us-ascii?q?eJ4RiAQEEAQEBIEsLEAIBCD8DAgICJQsUEQIEDgWISg6wGow4AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWIKgiCToQqgxgrgi8FlBWFUwGGJIkvgW6EYIM2hV6GeoV?= =?us-ascii?q?hg3oBHjaCfxuBT3CGIn8BAQE?=
X-IronPort-AV: E=Sophos;i="5.30,336,1470700800"; d="scan'208,217";a="323773695"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2016 22:36:51 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u8EMapto002049 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Sep 2016 22:36:51 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Sep 2016 17:36:50 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 14 Sep 2016 17:36:50 -0500
From: "Arun Arunachalam (carunach)" <>
To: "Paul Giralt (pgiralt)" <>
Thread-Topic: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
Thread-Index: AQHSDqeZWDIJ0TRtXU6Q4aH4MVNnb6B553oA
Date: Wed, 14 Sep 2016 22:36:50 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_984E4584C85041988F781839A027C36Aciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "Arun Arunachalam \(carunach\)" <>, "" <>, "Dawes, Peter, Vodafone Group" <>, "" <>, "Gonzalo Salgueiro \(gsalguei\)" <>
Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Sep 2016 22:36:56 -0000

Thanks for the feedback Paul !

Please see inline.

On Sep 14, 2016, at 12:46 PM, Paul Giralt (pgiralt) <<>> wrote:

Sorry for the delay in commenting. Here’s some feedback:

Abstract: It states "that marks the PDU as a candidate for logging”. Does this really just mark the particular message for logging or does it mark the entire session for logging? Section 4 says "Subsequent responses and requests in the same dialog are logged” which means to me that the indicator affects the logging of more than just the PDU, but then Section 5, REQ7 makes it possible for stateless intermediaries to only log based on the presence of the marker. Then REQ9 makes it seem like the marker must be present in all messages in the dialog.

The marking applies to an individual message but the originating UA / proxy adds the logme marker for all messages in a session.

Section 1 Introduction: Why are we singling out service providers? Wouldn’t this be useful in large enterprise environments as well?

I think the Service provider was the initial use case. Yes, its applicable within large enterprise networks as well. We can broaden the use case.

Section 4: This was already mentioned, but requiring that messages be logged in their long form doesn’t seem like a good idea to me. This could be computationally intensive and what is the reason for the failure is that a device is not handling headers in their compact form correctly? Seems like we should try to preserve as much of the original, raw message as possible.

Good point.

Section 5, REQ 5: What about new requests within the same dialog / session (e.g. ACK or re-INVITE)? I think those should also include the log me marker as well.

I think REQ 9 address this scenario - "If applied, "log me" marking MUST begin with the dialog-creating request and SHOULD continue to the dialog end.”

REQ8: Should update to latest session-id draft. Also, I have some concerns about using Session-ID as the test case identifier. The Session-ID can change (in fact will change for every session because the initial INVITE will have a null remote UUID).

How about using the local UUID of the Session-ID generated by the originating UA / proxy as a test identifier (if the admin wants the system to auto-generate a test ID)?

6.2.1 - “MUST not” should be “MUST NOT”

Also, there is a non-normative use of “must” and “must not” in this section. Is that intentional? Does the debugging configuration have to be supplied by a server? Can the debug configuration not be done locally on the terminal?

Same thing with the logs. Do they have to be sent to a server? Can they just be retained locally on the terminal?

Agree. The key is to have the action that enables “logme” to be authorized. There are different ways the action could be taken - through local terminal, api etc..

Regarding logs, looks like we didn't update 6.2.1 when we added the following text.

      When and how signalling logs are retrieved is out of scope of this
      document.  Logs might be retrieved by logging on to the SIP entity
      that contains the logs, by sending logs to a central server that
      is co-ordinating debugging, by storing them on removable media for
      later manual collection, or by some other method.

We will update this section.

I only see mention of Proxies, but not other intermediaries such as B2BUA’s. I think there should be some call out to be encompassing of all intermediaries.

We plan to include B2BUA / intermediaries, gateways in the next version based on input from Alberto Llamas.



On Aug 20, 2016, at 1:18 AM, Gonzalo Salgueiro (gsalguei) <<>> wrote:

Dear INSIPID Participants,

We have finally completed the Session-ID draft and it is now in the RFC Editor’s queue. It is now time to move forward with the completion of the pending bottlenecked milestones. The first one of these is draft-ietf-insipid-logme-reqs, which has previously received sufficient review and currently has no pending unaddressed issues.

This message begins a Working Group Last Call on draft-ietf-insipid-logme-reqs-07 (<>)s>), to end on Friday September 9th, 2016. Please post comments and feedback to the<> list, including just a simple "looks good” if you have read the draft and have no material comments.

I kindly request the authors to please address any WGLC comments in a timely fashion.

It is my hope we can muster the energy for a final push to finish up the two remaining milestones and then close out this WG.


Gonzalo (as chair)
insipid mailing list<>