Re: [MIB-DOCTORS] Change the boilerplate - Alissa's DISCUSS

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Jul 10, 2014 at 04:13:08PM +0200, Benoit Claise wrote:
> Dear all,
> 
> The email below refers to Alissa's DISCUSS
> See 
> http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ballot/#alissa-cooper
> 
> 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].
> 
> From the discussion (Dan andBert's feedback, on top of mine) , it seems 
> that there are valid reasons to keep a SHOULD here in the generic 
> boilerplate.
> 
> So what next?
> - Should we justify the reasons in the boiler plate
> - Should we  give some freedom in the boilerplate?
> 
>         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].
> 
>         <if there are use cases where a MUST is required, described 
> them here>
> 
>   Now, I hope it will not be abused by Security ADs, requesting a MUST 
> for every single MIB module.
> - Something else?
> - Stop writing MIB modules :-)
> 

Do nothing, re-discuss this every other year. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>