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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Apr 2015 12:20:21 -0700

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."

If, on the other hand, people think there aren't privacy issues, I'd like
to see that assertion along with supporting arguments.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Apr 2015 23:20:29 +0200

> http://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement/
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.

Or asked differently: should an applicability statement document review 
and discuss the security considerations of each of the use cases mentioned?

Regards, Benoit
> .

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Apr 2015 18:20:31 -0400

> On Apr 22, 2015:5:51 PM, at 5:51 PM, Ben Campbell <[email-masked]> wrote:
> 
> On 22 Apr 2015, at 16:20, Benoit Claise wrote:
> 
>> The question is: can we rely on the security considerations of RFC 7326, RFC 7460, and RFC 7461?
>> For example:
>> 
> 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.

	Would this fix resolve Stephen’s comments as well?

	—Tom

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Apr 2015 16:51:58 -0500

On 22 Apr 2015, at 16:20, Benoit Claise wrote:

>> Please refer to 
>> http://www.ietf.org/iesg/statement/discuss-criteria.html

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. "

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Apr 2015 23:21:49 +0100

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

Basically, yes. I think a truth-in-advertising statement like that
would be useful.

Thanks,
S.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Apr 2015 18:40:05 -0400

Cool. If that is the case, then I’d like to direct the document editors to make this change ASAP and re-spin
the draft. 

	—Tom

> On Apr 22, 2015:6:21 PM, at 6:21 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Apr 2015 22:03:12 -0500

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

>> (By the way, it looks like the references to 7460 and 7461 elsewhere 
>> in the draft still point to outdated drafts.)
>>
>>>
>> issues. But I agree with Stephen that it's kind of late to ask the WG 
>> to analyze those.
>>
>> 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.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 23 Apr 2015 09:02:06 +0200

Hi Ben,

Thanks for proposing text (btw, it makes a lot of sense)
That surely helps the authors.

Regards, Benoit
>>> 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.
>>>
>>> issues. But I agree with Stephen that it's kind of late to ask the 
>>> WG to analyze those.
>>>
>>> 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. “
>>
>> 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.
>
>>