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

"Paul Giralt (pgiralt)" <> Mon, 22 August 2016 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EACC312D7D1 for <>; Mon, 22 Aug 2016 12:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.068
X-Spam-Status: No, score=-15.068 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 D2IGeUvdTQOY for <>; Mon, 22 Aug 2016 12:43:36 -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 91E7F12D1E0 for <>; Mon, 22 Aug 2016 12:43:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16436; q=dns/txt; s=iport; t=1471895016; x=1473104616; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QtLAsY829EOO6ysS7w+FKjapU9jWXTPS8edd+FAKTwU=; b=PeFCZmGnVpk6zo2G8eLxjQ9PUSD116Kmtw80SciZshDMuOFUxgtrshxg kkUmr6XB1KDS9b6VUpvx1mbJwXiWzqtrReIX4TY7CxMQOOyN2ne+CV3GH 3zEnolLfCydNY6UlTDnsVycGg3IkVMdVwxDz3t382oj6Csw5iT6p1txg6 s=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AwDuVLtX/5ldJa1dg0RWbQ8HsneFC?= =?us-ascii?q?IF9JIUvSgKBZTgUAgEBAQEBAQFeJ4ReAQEEAQEBIUsLBQsCAQgYJwMCAicLFBE?= =?us-ascii?q?CBA4FDogbCA6tbpAJAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgkFhiuBeIJVh0Erg?= =?us-ascii?q?i8FmUgBgz2Bc2+If4FthFyDM4VUjD+DdwEeNoISHIFMcIV8fwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,561,1464652800"; d="asc'?scan'208,217";a="138686038"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 19:43:35 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u7MJhYd9019055 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Aug 2016 19:43:35 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 15:43:34 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 15:43:34 -0400
From: "Paul Giralt (pgiralt)" <>
To: "Gonzalo Salgueiro (gsalguei)" <>
Thread-Topic: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
Thread-Index: AQHR/K0H0F29HKaK50S5ehMOaySFjqBVpKKA
Date: Mon, 22 Aug 2016 19:43:34 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_5D8DDE0C-184D-48DA-9CF4-F213D14B5DB4"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "Dawes, Peter, Vodafone Group" <>, "Arun Arunachalam \(carunach\)" <>, "" <>
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: Mon, 22 Aug 2016 19:43:39 -0000

Apologies - the feedback below is for draft-ietf-insipid-logme-marking, not draft-ietf-insipid-logme-reqs

I will send separate feedback for draft-ietf-insipid-logme-reqs.


> On Aug 22, 2016, at 3:40 PM, Paul Giralt (pgiralt) <> wrote:
> Some feedback on this document
> Section 5.1: I didn’t quite understand the point of this section. Shouldn’t configuration be totally out of scope of the document? I didn’t feel like this section added any value to the document.
> Section 5.2: Perhaps mention that another criteria a proxy or UA can use is a calling / called party number. This actually seems like the most likely scenario for troubleshooting.
> Section 5.7: Should this be a normative statement? (e.g. An intermediary forking a request MUST copy log-me markings to all forked requests).
> Section I’m confused about this section. What does “controlled by explicit configuration of the originating side” mean? I would think signaling-only B2BUAs should still copy log-me markings from originating to terminating by default. I’m thinking the situation of a soft-switch in an SP network acting as a signaling-only B2BUA as opposed to a proxy or proxy-B2BUA (7092 is not very clear as to which one a soft switch falls into). In such a scenario, the desired behavior would be to always copy log-me from originator to terminator.
> But then in Section 5.8.4, the reader is referred back to 5.8.2/3 for how to behave even if they are media terminating. This type of B2BUA would more likely be an SBC where a network operator might want to filter out log-me messages because they act as a trust boundary in which case the forwarding from originating to terminating should be configurable.
> Section 5.9.1 and 5.9.2: The references to 7206 should be replaced with the RFC number assigned to [draft-ietf-insipid-session-id-27]/ 7206 doesn’t actually define the Session-ID header.
> Section 5.9.2: A Session-ID may change within the same dialog due to protocol interworking somewhere further downstream. Is the intention really for this to generate a separate log file? How does this affect the requirement that a new logging session cannot start mid-dialog? From the perspective of the device doing the logging, the dialog may not have changed, but the Session-ID changed.
> Section 6.2.1: What determines whether a marker has been “incorrectly inserted”?
> Section 6.2.2: What do you mean by “it MUST NOT be readable by an unauthorized third party”? I’m not clear what “it” refers to. Seems like it refers to “activating a debug” but I’m not sure what “activating a debug MUST not be readable” means.
> Section 6.3: Suggesting that logs SHOULD be encrypted seems like a stretch to me. Of course that doesn’t have to be followed, but most platforms today don’t encrypt their log files. I’d rather this say something like
>    A SIP entity that has logged information MUST protect the logs, such that
>    the logs can only be read by a person authorized to do so.
> If others feel we should impose encryption, I’m okay with it staying a SHOULD but realistically seems unlikely most will implement it.
> As far as I can tell, a device implementing log-me MUST implement [draft-ietf-insipid-session-id-27], correct? Seems like this should be called out at the beginning of the document (and of course added as a normative reference once the RFC number is assigned).
> Does I-D.ietf-insipid-logme-reqs really have to be a normative reference? Seems like it should be Informative.
> Nits:
> s/signalling/signaling/g
> I’d prefer is the references were not duplicated in the text (e.g. RFC 7206 [RFC7206] or defined in draft-ietf-insipid-logme-reqs [I-D.ietf-insipid-logme-reqs])
> -Paul
>> 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 ( <>), 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.
>> Regards,
>> Gonzalo (as chair)
>> _______________________________________________
>> insipid mailing list
>> <>
> _______________________________________________
> insipid mailing list