Re: [Insipid] Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT)

"Arun Arunachalam (carunach)" <> Wed, 01 February 2017 10:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E65FF129D1B; Wed, 1 Feb 2017 02:52:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.219
X-Spam-Status: No, score=-17.219 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vDwuow35hrg1; Wed, 1 Feb 2017 02:52:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D78B4129C65; Wed, 1 Feb 2017 02:52:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13184; q=dns/txt; s=iport; t=1485946352; x=1487155952; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yO9PcBQYCGvYRZxfMeSLj3Lt/q5tuhChhBFw0vzYmtw=; b=fLLhSLXFpJFKFdRkLhvZcgmWTkJstuOlryEm22VvvAM8MlVNhjll+kzh 4T5V1RVvkAxPmHD6Qbk5Nd6Bu5BigWapAAgLmFhnnTF+7I11K9PcTPK/l VD7E32ZHM4s3J+UwFiPy0GXd2x2DtuZXgG2g0xtljqVmVuOIoNdnPuBig k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.33,319,1477958400"; d="scan'208,217";a="201304409"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2017 10:52:31 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v11AqVWR004788 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Feb 2017 10:52:31 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Feb 2017 04:52:30 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 1 Feb 2017 04:52:31 -0600
From: "Arun Arunachalam (carunach)" <>
To: Mirja Kuehlewind <>
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-insipid-logme-reqs-12:_(with_COMMENT)?=
Thread-Index: AQHSe99s8wzrsgaLj0CIteOL96PpwaFUX2aA
Date: Wed, 1 Feb 2017 10:52:30 +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_524AEBF8B31043C79EE211451AE27912ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "Arun Arunachalam \(carunach\)" <>, "" <>, "Gonzalo Salgueiro \(gsalguei\)" <>, "" <>, The IESG <>, "" <>
Subject: Re: [Insipid] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-insipid-logme-reqs-12=3A_=28with_COMMENT=29?=
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, 01 Feb 2017 10:52:35 -0000

Hi Mirja,

Thanks for taking the time to review and sharing your feedback!

We discussed<> about the need to publish the requirement doc with Ben Campbell during AD evaluation process.

We would like to share key points from the discussion to IESG team for consideration:

(1) The primary objective of this requirements draft is to give an high-level understanding of the motivating scenario, concept definitions (e.g. network boundary), and provide clarity on the complete list of requirements that a proposed solution needs to satisfy. In our logging and troubleshooting scenarios, the requirements list has been identified through discussions and consensus among INSIPID working group members. The solution draft defines the protocol mechanism details. Implementors / Developers are expected to reference both documents.

(2) INSIPID working group has been following this top down approach for quite a while as can been seen from the decisions from 2013 and 2014. The group has worked for a long time on acceptable requirements and we think that it is valuable to freeze them now and publish them as a reference that explains the problem scope and defines the target for the solution to fulfil.

(3) Working group decisions:

(a) IETF 87, Berlin, 2013 the meeting notes ( say " Log-me requirements: Alternatives to LogMe draft should be submitted in following weeks. Solution draft will come later."
(b) IETF 88, Vancouver, 2013, it is noted ( that "Proposal is to remove the solution text in the current version and adopt the requirements part as WG draft.- Paul K: Had a bunch of comments.  Not sure the subset of requirements is ready to be adopted. There is still a bunch of trust issues with storing the log.- Gonzalo S: Solution discussion has not even begun yet. This is purely the requirements we are talking about"
(c) And the working group milestones have been stable since February 2014 (
"Changed milestone "Requirements for marking SIP sessions for logging to IESG (Informational)", set due date to September 2014 from June 2014.
Changed milestone "Protocol for marking SIP sessions for logging to IESG (Proposed Standard)", set due date to December 2014 from November 2014.”

Arun & Peter (co-authors)

On Jan 31, 2017, at 11:31 AM, Mirja Kuehlewind <<>> wrote:

Mirja Kühlewind has entered the following ballot position for
draft-ietf-insipid-logme-reqs-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I don't see a value in publishing this draft as a stand-alone document.
If needed content can be merged into draft-ietf-insipid-logme-marking
(maybe in the appendix); especially the security considerations belong in
the spec itself.