RE: Special protocol contraints expressed in MIBs

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Nobody has yet answered, so let me comment a bit
Inline

Bert 

> -----Original Message-----
> From: Kevin Lingle [mailto:klingle@cisco.com]
> Sent: Thursday, February 14, 2002 6:07 PM
> To: mibs@ops.ietf.org
> Subject: Special protocol contraints expressed in MIBs
> 
> 
> hi,
> 
> is it illegal to define a mib such that you are constraining it's
> implementors to use specific protocol constructs (not sure if that's
> the righ term or not).
> 
It is not clear to me what you mean.
But for example, if you want to specify a MIB that has only 64-bit
counters (so that woul mean that use of the MIB with SNMP would
be limited to SNMPv2c or SNMPv3), then that is acceptable. I would
say that (in IETF terms) the WG would have to agree that there is
no objection to that approach.

> for example, if you have an application that has very significant
> security requirements, would it be wrong to define a mib for which
> SNMPv3 is an explicit requirement for implementations?
> 
If you look at our security guidelines for MIBs at www.ops.ietf.org
then you will see that we basically already have that requirement.
It is always the user/deployment choice to use proper security.
The MIB writers need to point out what the secuirty issues are
what the risks are and recommend protocols that protect against 
the risks. So you see that we recommend SNMPv3 with USM and VACM
for security sensistive MIB access (be it read or write).

> or, if you have a requirement that a notification be reliable, 
> is it wrong to explicitly state in the description that Informs 
> must be used for that notification?
> 
I think this is somewhat different.
In the MIB you specify the notifications.
How they get send (TRAP or INFORM) is up to the operational 
personell, when they configure the MIBs in RFC2573.

I have no objection to adding some text to a description clause
that would encourage USERS (i.e. not implementers, cause they
have no control) to use INFORMs so that the notifications can
be checked to arrive.

> is there any section of snmp std rfcs that can be used to support
> the idea that such practices are either illegal (from a snmp std
> point of view) or strongly discouraged (from a normal mib design
> conventions point of view)?
> 
There are no general rules that I can point you to that would
address your "generic" questions.
There is nothing in any RFC (I think... ) that says that you cannot
just do Counter64s (which would make SNMPv1 unable to access them).

W.r.t. the INFORM, there is no way that I can see that allows you
define a notification such that it can only be sent with INFORM.
I think if you look at the design of SNMP and the MIBs that allow
you configure an SNMP engine, then it clearly shows that we
want the USERs to decide how they want notifications
to be filtered and send and that we do not want MIB writers to
prescribe how notifications must be sent.

Same with security. We want the protocols to provide secure mechanisms
(and so we MANDATE that at least one security mechanism be implemented
on all systems, but we want users to be able to slect if they use it 
or not). So if you have objects in a MIB that are sensitive, then we 
want you to describe the issues and we want you to recommend to use
a secure mechanism. 

> if it's not illegal to do such things, is it regarded as 
> highly improper?
> if so, why?
> 
> if there is no legal exclusion for such practices in the rfcs, how
> does one oppose such issues when they are manifested in a MIB module
> under design?
> 
> is there anything that AGENT-CAPABILITIES can do to help out in
> these situations?  such that the mib may be defined generally
> (without such impositions of protocol) but implementations of
> that mib may be so constrained by virtual of how the agent-capabilites
> are defined.
> 
implementations can always specify in an AGENT-CAPABILITIES taht they
do not support specific objects or that they do not support write
access for certain objects. But... the way that a lot of systems are
build, it seems to me that at the object level, you do not know
if access was made by a specific SNMP version or under a specific
security level. That control is at the (master) agent.


> thanks for the insight!
> kevin

Hope my comments help

Bert