RE: [Insipid] Review of draft-ietf-insipid-logme-reqs-11

"Dawes, Peter, Vodafone Group" <> Tue, 10 January 2017 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E39DE1294EE; Tue, 10 Jan 2017 06:51:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.056
X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xApgLQtx8Hxf; Tue, 10 Jan 2017 06:51:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22425129422; Tue, 10 Jan 2017 06:51:21 -0800 (PST)
Received: from [] by id 76/E9-31649-8E4F4785; Tue, 10 Jan 2017 14:51:20 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRWlGSWpSXmKPExsWi75nTqfv8S0m Ewb8VOhYLb0VYPNs4n8Vi/v1nTBZXVjUyW3xY+JDFgdVjyZKfTB4HDzIGMEWxZuYl5VcksGZs n3+VtWCxZsWGJzOZGxgfKHYxcnEICWxnlJi1ZTEThHOYUWLa+8NQziZGie2rr7N1MXJwsAnYS 8zYE9PFyMkhIuAqcWDvEWaQGmaB5YwSfxoa2EASwgKOEruPHGaBKHKSWHRkGzuEbSTRtWE1K4 jNIqAq8fHjTEYQm1cgVOLU1Q1gcSEBX4nLlxaA1XMK+EnserYSzGYUkJX40riaGcRmFhCXuPV kPhOILSEgILFkz3lmCFtU4uXjf6wQNToSC3Z/YoOwtSWWLXzNDLFLUOLkzCcsELtUJf6tXMQ0 gVF0FpKxs5C0z0LSPgtJ+wJGllWM6sWpRWWpRbqmeklFmekZJbmJmTm6hgbGermpxcWJ6ak5i UnFesn5uZsYgfFVz8DAuIPx8lenQ4ySHExKorzLPpdECPEl5adUZiQWZ8QXleakFh9ilOHgUJ LgZQXGq5BgUWp6akVaZg4w0mHSEhw8SiK8HCBp3uKCxNzizHSI1ClGRSlx3m8gMwVAEhmleXB tsORyiVFWSpiXkYGBQYinILUoN7MEVf4VozgHo5IwLx/IeJ7MvBK46a+AFjMBLY60KwZZXJKI kJJqYOxa5JBu9LBhaazoPbN7L1du7RMWzu66Waz5gE3tpdOc8x6znfknf5bhfvvO/cYa3UVsL QvvB2x16uw8viVc4Kfc1089jtkSpYZ8h7Y78vyJ8Lya2me0RkBycWjAv5tO6hHNN7Z/eJ9ZXR C+2SYm1zj4f6v/Za3JglnLjdTvpTlmmGiHeOlKK7EUZyQaajEXFScCAFpVWsQpAwAA
X-Originating-IP: []
X-StarScan-Version: 9.1.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20516 invoked from network); 10 Jan 2017 14:51:19 -0000
Received: from (HELO ( by with AES256-SHA encrypted SMTP; 10 Jan 2017 14:51:19 -0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 10 Jan 2017 15:51:11 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 10 Jan 2017 15:51:10 +0100
Received: from ([]) by ([]) with mapi id 14.03.0294.000; Tue, 10 Jan 2017 15:51:09 +0100
From: "Dawes, Peter, Vodafone Group" <>
To: Sean Turner <>, "" <>
Subject: RE: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
Thread-Index: AQHSaJGvOGgPjzgqkUKSx9NtoblxqqExzr0A
Date: Tue, 10 Jan 2017 14:51:09 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jan 2017 14:51:28 -0000

Hello Sean,
Thanks very much for your review, some proposals and answers from the co-authors inline below to cover the points raised.

Best regards,

> -----Original Message-----
> From: insipid [] On Behalf Of Sean Turner
> Sent: 07 January 2017 02:57
> To:
> Cc:;;
> Subject: [Insipid] Review of draft-ietf-insipid-logme-reqs-11
> Reviewer: Sean Turner
> Review result: Has Nits
> After getting over my initial reaction that was something like "srsly!? we're
> going to standardize the exact opposite of 'do not track'", I realized that this
> is a requirements draft for an IETF approved WG and a chartered work item
> of that WG :)
> 0) s3.2: Is the intent to define a protocol mechanism to determine if the two
> or domains are part of the same trust domain?  This requirement could be
> achieved by saying out-of-band bilateral agreements are the mechanism to
> establish the domain.

There is no intent to define a protocol mechanism to determine if two or
more domains are part of the same trust domain. s3.2 explains the meaning
of the term "trust domain" as it is used in this draft because the term "trust
domain" does not have a fixed meaning throughout its use in RFCs. RFC 3324
section 2.3 defines "trust domain" for network asserted identity and this
definition is re-used by RFC 7316 for a private network indicator. "Trust
domain" is used without definition in RFC6404. So we define the term " trust
domain" as it applies to log-me marking.

> 1) s5.1: REQ1 - Did you mean to say "using SIP standard logging format"?  Is
> there another logging format other than SIP CLF?

We am not aware of any other SIP logging formats and SIP CLF is expected to be used, but the logging format will be defined in the solutions draft.  

> 2) s5.1: Should the must be MUST in the following:
>   All log retrieval mechanisms must adhere to
>   authorization and privacy protection policies
>   set forth by the network administrator.

This "must" was left lower case as retrieval itself is out of scope, but we think
capitalizing MUST would be consistent with the rest of the draft so we
can do that. Although this MUST does not impact interoperability, we
extended the use of MUST beyond interoperability required to satisfy RFC
2119 as a result of a comment from area director Ben Campbell.

> 3) s5.2: REQ3 seems odd to me - Isn't this kind of like a SIP thing?
> I mean if SIP doesn't allow adding new headers then didn't somebody sink
> your battleship?  But SIP does allow you to add arbitrary headers so I think
> I'm missing something as to why this is needed?

The purpose of REQ3 is to make it clear that the solution needs a new
protocol element, i.e. "log me" marking cannot be done using existing SIP.
The text says: "REQ3: It MUST be possible to mark a SIP request or response
as of interest for logging by inserting a "log me" marker.  This is known as "log
me" marking. "

> 4) s5.2: REQ3 - Reads a bit awkward to me how about:
>   It MUST be possible to mark a SIP request or response for
>   logging by inserting a "log me" marker.
> i.e., remove "of interest"

We can see your point. The purpose of the words "of interest" is to avoid
suggesting that marking requests and responses forces them to be logged.
The decision of whether to honour the log-me marking is largely left to the
admin policy (e.g. s6.2.1 says " The presence of a "log me" marker
might cause some SIP entities to log signaling.") but "log me" marking is not
expected to force logging in all cases.
The following revision of REQ3 would clarify:
REQ3: It MUST be possible to mark a SIP request or response to be considered for logging by inserting a "log me" marker.

> 5) s5.2: REQ4 - Again this seems like a basic SIP thing - I mean are there fields
> that SIP requires be stripped?

The purpose of REQ4 (It MUST be possible for a "log me" marker to cross
network boundaries.) is to ensure that the log me marker is not defined in a
way that will very probably cause it to be removed by real-world networks
such as described earlier in the draft in s3.1 ("A  network boundary is
significant in this document because manipulation of signaling at the
boundary could prevent end-to-end testing or troubleshooting. "). Also,
some protocol elements might change at a network boundary, for example
an outgoing network boundary may obfuscate some fields, or an incoming
network boundary might translate the request URI from a public identity to
one that is private to that network.

> 6) Is there a missing requirement based on the security considerations that
> requires the this marker MUST be removed at the earliest opportunity if it
> has been incorrectly inserted?

We can move the text "The presence of a "log me" marker might cause some SIP entities to log signaling.  Therefore, this marker MUST be removed at the earliest opportunity if it has been incorrectly inserted."
from s6.2.1 and add a REQ12 in s5.3.

> _______________________________________________
> insipid mailing list