Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10

"DOLLY, MARTIN C" <> Thu, 24 November 2016 04:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95ACA129492; Wed, 23 Nov 2016 20:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id avRGTZWFDEfD; Wed, 23 Nov 2016 20:55:51 -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 A91C0129427; Wed, 23 Nov 2016 20:55:51 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id uAO2EluE039325; Wed, 23 Nov 2016 21:20:37 -0500
Received: from ( []) by with ESMTP id 26wq5jrmdk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Nov 2016 21:20:36 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id uAO2KZ6M024216; Wed, 23 Nov 2016 21:20:35 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uAO2KPLA024144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Nov 2016 21:20:27 -0500
Received: from ( []) by (RSA Interceptor); Thu, 24 Nov 2016 02:20:13 GMT
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 21:20:13 -0500
From: "DOLLY, MARTIN C" <>
To: Ben Campbell <>
Thread-Topic: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10
Thread-Index: AQHSM75F9hgUgWsLKk2QETbSI72JqqDmzBmQgAD1CID//7XMQIAAYxgA//+xEK4=
Date: Thu, 24 Nov 2016 02:20:12 +0000
Message-ID: <>
References: <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_6FC083A45D79487BA0F3291171F6D14Cattcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-24_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611240035
Archived-At: <>
Cc: Arun Arunachalam <>, "Dawes, Peter, Vodafone Group" <>, "" <>, Gonzalo Salgueiro <>, "" <>
Subject: Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10
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: Thu, 24 Nov 2016 04:55:53 -0000

Longer than most of my short answers
Initially meant in controlled deployments

Maybe SIP or now the world version of SiP being done in 3GPP.

Not IETF. In would have been interoperable

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
Cell: +1.609.903.3360<tel:+1.609.903.3360>

On Nov 23, 2016, at 9:02 PM, Ben Campbell <<>> wrote:

I'm not sure I follow you, but I assume you either mean either that you like version 10 the way it is, or you like some component of it better than my suggestion.

Please note that my proposals on requirements language, which I think are the most material suggestions, are contingent on the answers to some of my earlier questions about how the behavior definition is divided between this and the solution draft.


On 23 Nov 2016, at 19:08, DOLLY, MARTIN C wrote:


The initial proposal was easier


Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
Cell: +1.609.903.3360<tel:+1.609.903.3360>

On Nov 23, 2016, at 7:34 PM, Ben Campbell <<><>> wrote:

Hi, thanks for the response. Comments inline.


On 23 Nov 2016, at 8:59, Dawes, Peter, Vodafone Group wrote:

Hello Ben,
Thanks very much for your initial AD evaluation of draft-ietf-insipid-logme-reqs-10, below is our response. The review was long so we used some XML-style tags to structure the response according to your major and minor concerns.

Peter and Arun (co-authors)

- What is the archival value for this draft after the mechanism is complete? Is there really a reason to publish it as an RFC? Could the info here be stored in the working group wiki, included in the solution draft, or even allowed to expire once the mechanism is complete? I contrast this to the session-id requirements document, since that explored the details of some tricky concepts (such as "session".) It's not clear to me that this draft does the same. I also note that logme-marking already seems to replicate a good deal of this draft, and seems to dive even deeper into use cases, and in some areas seems to have moved beyond the requirements in this draft.
I ask because the question is likely to come up in IESG review, and also because the publication process creates a lot of effort for the working group, RFC editor, reviewers, etc.

The primary objective of a requirements draft is to provide clarity on the complete list of requirements that a proposed solution needs to satisfy for a given problem. In our logging and troubleshooting scenarios, the requirements list has been identified through discussions and consensus among INSIPID working group members.

That's my understanding of what a requirements draft typically does. But this draft seems to also put requirements on behavior, which seem like protocol requirements to me. So as written, it seems like protocol/behavior requirements are either spread or repeated between the requirements and solution draft. This seems to make life harder than necessary for the implementer.

There are other reasonable work divisions, for example you might have an requirements + architecture draft and a separate solution draft, or you might have a SIP element behavior draft and a data format draft, etc.

In this draft, we have clearly documented the requirements from the perspective of:
-    When the logging is started and stopped
-    Passing the log-me marker across SIP entities
-    Privacy considerations

These are all reasonable categories. My concern is how things are divided between this and the solution draft within those categories. For example, a requirement of the form of "The logging indication must be able to be sent across B2BUAs" vs "A B2BUA must copy the <foo> parameter".

The solution document will provide insights into the "how" details. These two documents help a network developer, administrator and support engineer to understand the guiding requirements upon which the solution will be built