Subject: comments on draft-ietf-ipfc-mib-framework-01

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Nov 1999 19:06:49 +0100

Here are some comments on text in draft-ietf-ipfc-mib-framework-01:

: Semantic content - enough information should be provided to program
: against without knowing about the vendor and implementation.

Is this the same as section 7.5 in RFC 2578? Why not point to it?

: Revision and revision compatibility - revision should be embedded in
: MIBs so a processing entity can identify the MIB and process it
: accordingly.  Backward compatibility is required.

MIBs are by definition backward compatible. It is generally not
allowed to change sematics of definitions (section 10 in RFC 2578).
Hence, I do not understand the purpose of this object.

: All objects that are not implemented by an agent should either return a
: "no such instance" error when accessed, or should return a null value
: for the object. Null values consist of 0 for INTEGER type objects, and
: the Null string for OCTET STRING type objects.

Not sure I understand this correctly. The error you get when accessing
a non-existing object is well defined in the SNMP protocol version you
are using. Also, there is no reason to define the Null values for
various data types - it really depends on the MIB object.

: A mode may be provided where all MIB objects are treated as read-only
: objects, regardless of their definition in the MIB. This mode will
: satisfy some of the security requirements of customers who feel that
: SNMPv1 security measures are insufficient to guard against unauthorized
: access.

: Conformance to a MIB should not require the implementation of write access,
: although vendors are encouraged to provide full control of their device
: through a remote protocol. For MIB objects that are only writable,
: conformance does not require implementation of the object.

This means that the MIB definition has to have conformance statements
that allow for a read-only implementation. You can do that without
requiring that these objects are not implemented. That is, you can
define an object to be read-write and require only read-only 
implementation in a conformance definition.

: For SNMP Sets to objects that are protected as described above, an SNMP
: "generic error" response should be returned by the SNMP agent to the
: originator of the SNMP Set request.

This violates the SNMP protocol definition. You can not do that.  With
regard to the security aspect, I think it is important to point to
SNMP security as defined in SNMPv3. The view-based access control model
can also be used with SNMPv1. The protocol definition itself describes
what happens if you try to write an object which is not writable.

: It's advisable that a MIB object exist within each FC MIB that contains
: the version number of the particular FC MIB. This MIB object should be
: at a fixed OID within the MIB, such that future versions of the MIB are
: backward compatible with respect to the version number object. Backward
: compatibility for this MIB object allows an NMS to support multiple
: versions of a particular FC MIB.

Again, MIBs do not have a versioning problem.

: Fibre Channel MIBs should be located under the "Fibre Channel" branch
: of 1.3.6.1.3.42.2

What is the purpose? MIB branches are assigned by the IANA. Or is this
statement just intended for MIBs under development?

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>