Re: [eman] Ben Campbell's Discuss on draft-ietf-eman-applicability-statement-10: (with DISCUSS)

"Ben Campbell" <ben@nostrum.com> Thu, 23 April 2015 03:03 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC521B2E3B; Wed, 22 Apr 2015 20:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5eNGCMuV2EC; Wed, 22 Apr 2015 20:03:31 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FF21B2E3A; Wed, 22 Apr 2015 20:03:30 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3N33C7N089718 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2015 22:03:23 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
Date: Wed, 22 Apr 2015 22:03:12 -0500
Message-ID: <A86B6F26-185E-4B81-B57A-3DBA46737066@nostrum.com>
In-Reply-To: <FC8494B3-6774-4E9F-B04C-5483F75E8061@lucidvision.com>
References: <20150422192021.30691.70336.idtracker@ietfa.amsl.com> <5538109D.1070103@cisco.com> <DBA94551-493C-4FFD-8C9F-49D9A3D2351C@nostrum.com> <FC8494B3-6774-4E9F-B04C-5483F75E8061@lucidvision.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/eman/AAKPeYJnwFNb0NH64aEqCVYWWCU>
X-Mailman-Approved-At: Wed, 22 Apr 2015 20:07:58 -0700
Cc: eman-chairs@ietf.org, eman@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [eman] Ben Campbell's Discuss on draft-ietf-eman-applicability-statement-10: (with DISCUSS)
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions about the Energy Management Working Group <eman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eman>, <mailto:eman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eman/>
List-Post: <mailto:eman@ietf.org>
List-Help: <mailto:eman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2015 03:03:32 -0000

On 22 Apr 2015, at 17:20, Thomas D. Nadeau wrote:

>> On Apr 22, 2015:5:51 PM, at 5:51 PM, Ben Campbell <ben@nostrum.com> 
>> wrote:
>>
>> On 22 Apr 2015, at 16:20, Benoit Claise wrote:
>>
>>> On 22/04/2015 21:20, Ben Campbell wrote:
>>>> Ben Campbell has entered the following ballot position for
>>>> draft-ietf-eman-applicability-statement-10: Discuss
>>>>
>>>> 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 
>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> http://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> [edited to fix missing word]
>>>>
>>>> I agree with Stephen's comments that the security considerations 
>>>> are
>>>> sorely lacking. I understand his reasoning for not asking the group 
>>>> to do
>>>> considerably more work at this point in the process. But I'd like 
>>>> to see
>>>> at least an explicit mention that power management as described in 
>>>> some
>>>> of the use cases in this draft may have significant privacy
>>>> considerations--even if that mention takes the form of "We haven't 
>>>> fully
>>>> analyzed privacy issues, and leave that work to a follow on 
>>>> effort."
>>> The question is: can we rely on the security considerations of RFC 
>>> 7326, RFC 7460, and RFC 7461?
>>> For example:
>>>
>>> In certain situations, energy and power monitoring can reveal
>>> sensitive information about individuals' activities and habits.
>>> Implementors of this specification should use appropriate privacy
>>> protections as discussed in Section 9 of RFC 6988 and monitoring of
>>> individuals and homes should only occur with proper authorization.
>>
>> It would help if the security considerations in the applicability 
>> statement referenced those docs :-) Even so, references scoped to the 
>> MIBs are not completely satisfying when the draft says it is equally 
>> applicable to things like YANG and NETCONF.
>>
>> (By the way, it looks like the references to 7460 and 7461 elsewhere 
>> in the draft still point to outdated drafts.)
>>
>>>
>>> Or asked differently: should an applicability statement document 
>>> review and discuss the security considerations of each of the use 
>>> cases mentioned?
>>
>> That would be nice--really, each use case may have different privacy 
>> issues. But I agree with Stephen that it's kind of late to ask the WG 
>> to analyze those.
>>
>> Would you consider adding something to the effect of the following to 
>> the security considerations?
>>
>> NEW:
>>
>> " [RFC7460] section X and [RFC7461] section Y mention that power 
>> monitoring and management MIBs may have certain privacy implications. 
>> Applications of this spec that use other mechanisms (e.g. YANG) may 
>> have similar implications, which are beyond this scope of this 
>> document. There may be additional privacy considerations specific to 
>> each use case; this document has not attempted to analyze these. “
>
> 	This is a (thankfully) simple, and reasonable approach. My only 
> question is why are we mentioning Yang here? The WG only produced SNMP 
> MIBs.

I suggested mentioning Yang here because section 1.1 mentioned that the 
information model was equally applicable to non-SNMP approaches such as 
YANG and NETCOMF. I'd be willing to entertain arguments that such things 
are not really applications of this spec, i.e. I won't complain if you 
drop that sentence.

>
> 	Would this fix resolve Stephen’s comments as well?
>
> 	—Tom