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

"Mirja Kuehlewind (IETF)" <> Wed, 01 February 2017 11:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72FB4129D1C for <>; Wed, 1 Feb 2017 03:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rh_MiY5Q9kIZ for <>; Wed, 1 Feb 2017 03:34:33 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 601C2126B6D for <>; Wed, 1 Feb 2017 03:34:32 -0800 (PST)
Received: (qmail 18259 invoked from network); 1 Feb 2017 12:27:49 +0100
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Feb 2017 12:27:49 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: "Mirja Kuehlewind (IETF)" <>
In-Reply-To: <>
Date: Wed, 1 Feb 2017 12:27:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Arun Arunachalam (carunach)" <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: "" <>, "" <>, The IESG <>, "" <>, "Gonzalo Salgueiro \(gsalguei\)" <>
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 11:34:37 -0000

Hi Arun, Hi Peter,

I do see well the value of having and working on this document in the wg process. I just don’t see any archivable value of it that justifies to run through the IETF process to the end and publish it as an RFC.

Alternatively, you can simply declare this document as done in the wg (also mark the milestone as done) and potentially copy parts of it in (the appendix of) the final protocol document if you still think by then that there are parts that should be achieved in the RFC series.

Again, I don’t think this document has a stand-alone value for anybody who is not involved in the wg process and I don’t think it will have any historical value in future, and therefore this document does not need to be published in the RFC series.


> Am 01.02.2017 um 11:52 schrieb Arun Arunachalam (carunach) <>om>:
> 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.”
> Thanks!
> 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.