From: Keith McCloghrie <kzm>
Message-Id: <200606081530.IAA19664@cisco.com>
Subject: Re: DISCUSS: draft-ietf-imss-fc-vf-mib
To: brc@zurich.ibm.com (Brian Carpenter)
Date: Thu, 8 Jun 2006 08:30:35 -0700 (PDT)
Cc: iesg@ietf.org, MAP@MAP-NE.com, black_david@emc.com, scott.kipp@mcdata.com,
g.ramkumar@mcdata.com, kzm@cisco.com
In-Reply-To: <E1FoFmN-00086L-WB@ietf.org> from "Brian Carpenter" at Jun 08, 2006 04:22:11 AM
Brian,
Thank-you for clarifying the question. I did not answer the email
yesterday because I wasn't exactly sure what "Updates RFC NNNN" means.
Discuss:
Does this MIB normatively update RFC 4044, i.e. will implementations
of RFC 4044 need to be modified to remain conformant? If so,
this needs to be mentioned in the header, Abstract and Introduction.
RFC 4044 was defined before Virtual Switches were standard
and represented only physical Switches, so the RFC 4044
tables were not defined as read-create. With the advent of
Virtual Switches, Virtual Switches can now be created by
administrators and read-create tables are required. The
StorageType of RFC 4044 tables were not defined and
StorageTypes used in this MIB should also apply to the
RFC4044 tables that this MIB augments.
The answer is: No. The only *need* to update an implementation of
RFC 4044 is because such an implementation populates its MIB with
information about all kinds of Fibre Channel switches, and T11 has
defined a Virtual Switch as a new kind of Fibre Channel switch.
draft-ietf-imss-fc-vf-mib explains this and describes how it
affects RFC 4044. But note:
a) the need to modify an RFC 4044 implementation is because of T11's
definition of Virtual Switch, not because of draft-ietf-imss-fc-vf-mib.
I.e., the need has existed ever since T11 specified Virtual Switches,
and it is independent of whether draft-ietf-imss-fc-vf-mib is defined.
b) a similar situation occurs with MIBs whenever a new media-specific
MIB is defined, with respect to such a MIB's relationship to RFC 2863.
In such a situation, support for the new type of interface requires the
implementation of RFC 2863 to be updated to include the new interfaces
in the IF-MIB; the new media-specific MIB just explains how. Further,
precedence indicates that this scenario (of explaining how a new
specific type is included in a previously-specified generic MIB) does
not require the use of "Updates RFC NNNN". Specifically, many
media-specific (e.g., RFC 3635, 4044, etc.) have this relationship to
RFC 2863 but no RFC has ever been marked as "Updates RFC 2863".
In addition to the above, it is not needed to remain compliant, but it
is possible to update an implementation of RFC 4044 due to the
definition of teh new MIB. Specifically, draft-ietf-imss-fc-vf-mib
defines extensions to RFC 4044. For example, an optional capability in
RFC 4044 is to support write access to the MIB.
draft-ietf-imss-fc-vf-mib provides the means to specify a StorageType,
which applies to just one write-able object in RFC 4044 (specifically,
fcmSwitchDomainId) when its value is modified via a network management
protocol such as SNMP. Specifically, StorageType specifies whether the
new value is volatile or non-volatile. With RFC 4044, this volatility
was left unspecified; with draft-ietf-imss-fc-vf-mib-02.txt it can now
be specified by a network management application. So specifying the
volatility is a new optional feature.
Keith.