Re: DISCUSS: draft-ietf-imss-fc-vf-mib (fwd)

[Keith McCloghrie <kzm@cisco.com>]

FYI.

Keith.
---------------
Forwarded message:
> 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.
>