Re: [MIB-DOCTORS] Change the boilerplate

["David Harrington" <[e-mail]>]

The design of IETF management is that the data models are separate from the
protocols that carry the data.
This is based on the precedent set by RFC1052, where the IAB made the
deliberate decision to separate them so that the temporary simple protocol
SNMP could be replaced by the more full-featured CMIP when it was ready.

A MIB module might be used with SNMPv3 (the recommended approach), or
SNMPv1/v2 (for secure networks, or at the administrator's discretion for
other reasons).
A MIB module might be used with a newer version of SNMP, such as SNMPv4,
should we ever choose to develop a later version.
A MIB module might also be used with other protocols, such as IPFIX or
Netconf or protocols standardized by other SDOs, and so on, when
appropriate.
A MIB module might also be used with other protocols, such as a proprietary
protocol used within a closed network.
So SHOULD is appropriate. 

David Harrington
[e-mail]
[phone]
> -----Original Message-----
> From: MIB-DOCTORS [mailto:[e-mail]] On Behalf Of
> Bert Wijnen (IETF)
> Sent: Thursday, July 10, 2014 3:15 AM
> To: Benoit Claise; MIB Doctors (E-mail)
> Cc: Adrian Farrel; 'Alissa Cooper'
> Subject: Re: [MIB-DOCTORS] Change the boilerplate
> 
> it is always interesting to see that when we get new ADs that we must
> rediscuss this whole topic.
> 
> But yes, there are/were implementations/deployments where one uses
> dedicated (secure) networks
> for the network management systems, and so that would work under a
> SHOULD.
> 
> I do not recall if that was/is the only reason why we agreed on a SHOULD
> instead of MUST.
> 
> Bert
> 
> On 09/07/14 17:58, Benoit Claise wrote:
> > MIB doctors,
> >
> > Let me focus the discussion a little bit.
> > Alissa refers to this sentence in the boilerplate at
> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
> >
> >         Implementations SHOULD provide the security features described
by
> the
> >         SNMPv3 framework (see [RFC3410]), and implementations claiming
> compliance
> >         to the SNMPv3 standard MUST include full support for
authentication
> and
> >         privacy via the User-based Security Model (USM) [RFC3414] with
the
> AES
> >         cipher algorithm [RFC3826].
> >
> >
> > Alissa's feedback is:
> >
> >     It is a little disconcerting that use of SNMPv3 is provided as a
SHOULD-
> level requirement without discussion of deployment
> >     scenarios and regardless of the sensitivity of the data being made
> available by any new MIB. For example, the tradeoffs between
> >     security and utility might be reasonable if (1) I'm using an older
SNMP
> version on my closed home network to monitor my own
> >     energy use, but not if (2) my ISP is using it to monitor the same
thing. The
> text quoted above basically  endorses unauthorized
> >     energy monitoring if the provider does not support SNMPv3, whereas
it
> seems like what we would want to be saying is that in
> >     cases like (2) SNMPv3 is required.
> >
> > Can one of the old timers (who was part of the discussion) explain the
> SHOULD rational? Personally, I can see two use cases in favor
> > off the SHOULD: an older SNMP version in a closed network,  or a private
> data communication network dedicated to network management
> > with special protection out of SNMP (like encrypted tunnel)
> >
> > Should we now modify this sentence to say?
> >
> >     MUST provide the security features described by the
> >     SNMPv3 framework (see [RFC3410])
> >
> > Regards, Benoit
> >
> >> MIB doctors,
> >>
> >> It seems that the "Security Guidelines for IETF MIB modules" receives
> comment for each MIB module submitted to the IESG.
> >> Is it time to modify it, or are we redoing the same discussions over
and
> over?
> >>
> >> Regards, Benoit
> >>
> >>
> >> -------- Original Message --------
> >> Subject: 	Re: Alissa Cooper's Discuss on draft-ietf-eman-energy-
> monitoring-mib-12: (with DISCUSS and COMMENT)
> >> Date: 	Tue, 8 Jul 2014 13:02:50 -0700
> >> From: 	Alissa Cooper <[e-mail]>
> >> To: 	Benoit Claise <[e-mail]>, The IESG <[e-mail]>
> >> CC: 	<[e-mail]>,
<eman-
> [e-mail]>
> >>
> >>
> >>
> >> Hi Benoit,
> >>
> >> On 7/8/14, 1:44 AM, "Benoit Claise" <[e-mail]
> <mailto:[e-mail]>> wrote:
> >>
> >>     Hi Alissa,
> >>
> >>     Thanks for your review.
> >>>     Alissa Cooper has entered the following ballot position for
> >>>     draft-ietf-eman-energy-monitoring-mib-12: 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 tohttp://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-energy-monitoring-
> mib/
> >>>
> >>>
> >>>
> >>>
----------------------------------------------------------------------
> >>>     DISCUSS:
> >>>
----------------------------------------------------------------------
> >>>
> >>>     Section 11 is missing a discussion of the privacy considerations
of
> >>>     energy and power monitoring. I would suggest something along the
> lines of
> >>>     the following:
> >>>
> >>>     "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."
> >>
> >>     Regarding your first sentence, I propose the following text, which
would
> be in line with Security Guidelines for IETF MIB
> >>     modules at
http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
> >>
> >>         Some of the readable objects in this MIB module (i.e., objects
with a
> >>         MAX-ACCESS other than not-accessible) may be considered
sensitive
> or
> >>         vulnerable in some network environments.  It is thus important
to
> >>         control even GET and/or NOTIFY access to these objects and
possibly
> >>         to even encrypt the values of these objects when sending them
over
> >>         the network via SNMP.  These are the tables and objects and
their
> >>         sensitivity/vulnerability:
> >>
> >>         Access to the content of the eoPowerStateTable, eoEnergyTable,
and
> >>         eoACPwrAttributesTable MIB tables can reveal sensitive
> >>         information about individuals' activities and habits
> >>
> >> Sounds good to me.
> >>
> >>
> >>     Since this document is essentially a MIB module, your last sentence
is
> covered by
> >>
> >>              implementations
> >>              claiming compliance to the SNMPv3 standard MUST include
full
> >>              support for authentication and privacy via the User-based
> >>              Security Model (USM) [RFC3414
> <http://tools.ietf.org/html/rfc3414>] with the AES cipher algorithm
> >>              [RFC3826  <http://tools.ietf.org/html/rfc3826>].
> >>
> >> RFC 6988 notes the need for privacy protections for stored data, which
> the above text does not speak to, so I still think a
> >> reference to RFC 6988 would add value here.
> >>
> >> It is a little disconcerting that use of SNMPv3 is provided as a
SHOULD-
> level requirement without discussion of deployment
> >> scenarios and regardless of the sensitivity of the data being made
> available by any new MIB. For example, the tradeoffs between
> >> security and utility might be reasonable if (1) I'm using an older SNMP
> version on my closed home network to monitor my own energy
> >> use, but not if (2) my ISP is using it to monitor the same thing. The
text
> quoted above basically  endorses unauthorized energy
> >> monitoring if the provider does not support SNMPv3, whereas it seems
> like what we would want to be saying is that in cases like
> >> (2) SNMPv3 is required.
> >>
> >> I understand that this is basically boilerplate language for MIB docs,
so I'm
> not sure what can be done, but it seems unfortunate.
> >>
> >> Alissa
> >>
> >>
> >>
> >>>
----------------------------------------------------------------------
> >>>     COMMENT:
> >>>
----------------------------------------------------------------------
> >>>
> >>>     Section 12.1:
> >>>     "New Assignments (and potential deprecation) to Power State Sets
> >>>              shall be administered by IANA and the guidelines and
procedures
> >>>              are specified in [EMAN-FMWK], and will, as a consequence,
the
> >>>              IANAPowerStateSet Textual Convention should be updated."
> >>>
> >>>     Not sure what this sentence means.
> >>     Good catch.
> >>     NEW:
> >>
> >>              "New Assignments (and potential deprecation) to Power
State Sets
> >>              shall be administered by IANA and the guidelines and
procedures
> >>              are specified in [EMAN-FMWK], and will, as a consequence,
update
> the
> >>              IANAPowerStateSet Textual Convention."
> >>
> >>
> >>     Regards, Benoit (as a document author)
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> MIB-DOCTORS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mib-doctors
> >
> >
> >
> > _______________________________________________
> > MIB-DOCTORS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mib-doctors
> >
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mib-doctors