Re: REVIEW: draft-ietf-imss-fc-vf-mib-02.txt

[Keith McCloghrie <kzm@cisco.com>]

Hi Dave,

> It is appropriate in a MIB module to list RFC2578-80 (SMIv2) as
> Normative, since they define the language used in the MIB.
 
Agreed.

> It is appropriate in a MIB module to list RFC3410 as Informative,
> because SNMP is not the only protocol that can transport MIB data, in
> accordance with the Internet-Standard Management Framework.

Agreed, and because it is appropriate to list RFC3410 as Informative,
it is also appropriate to use SNMP as an example of a remote network
management protocol for transporting MIB data.  I will refer to this
point multiple times below.

> This document may require documents in the RFC341x series (SNMPv3
> standard) to be listed as Normative because they reference aspects of
> SNMPv3 explicitly. But it seems bad practice to do this, and they
> could eliminate the Normative reference by eliminating these
> unnecessary references in the text.

Agreed.

> > Section 5 says 
> >    "This MIB module provides the means for monitoring the 
> >    operation of, and configuring some parameters of, one or more 
> >    instances of Fibre Channel Virtual Fabric functionality. 
> >    (Note that there are no definitions in this MIB module of 
> >    "managed actions" which can be invoked via SNMP.) "
> 
> The second sentence seems totally unnecessary. Implementers need to
> know what is in the Mib module, not what is not in the MIB module.

I suggest that it seems unnecessary to you because you are an SNMP and
MIB expert but a Fibre Channel novice, but please remember that this
document is the product of two standardization committees.  INCITS's
T11 committee started the work in order to provide the technical
expertise on Fibre Channel.  The IETF has continued the work so as to
provide the expertise on MIBs.  That second sentence was put in
specifically to address a comment made by a member of T11 who is a
Fibre Channel expert and a MIB novice.  To take it out would be to
rescind a decision taken in T11.

In fact, I consider the sentence to be necessary because Fibre Channel
defines its own (link layer) network management protocols which do
provide the capability of "managed actions".  Thus, the mention of SNMP
is needed to distinguish the use of this MIB from the use of such Fibre
Channel management protocols.

In any case, T11 members did not object to the inclusion of section 3,
all of which is redundant as far as a Fibre Channel expert is
concerned, and is present for those in the IETF and beyond who are
novices on Fibre Channel.  Thus, I suggest that you as an SNMP/MIB
expert should not object to something which is redundant as far as you
are concerned, but informative for a T11 participant.

If you would prefer, it could be reworded esuch that SNMP is only used
as an example, e.g.,

       This MIB module provides the means for monitoring the 
       operation of, and configuring some parameters of, one or more 
       instances of Fibre Channel Virtual Fabric functionality. 
       (Note that there are no definitions in this MIB module of 
       "managed actions" which can be invoked via a remote network
       management protocol such as SNMP.)

> > Section 5.1 saya:
> >    "For example, one such grouping accommodates a single SNMP agent
> > having 
> >    multiple AgentX [RFC2741] sub-agents, with each sub-agent 
> >    implementing a different Fibre Channel management instance. "
> 
> I recommend this implementation suggestion be removed. It is
> unnecessary, and only one viable approach of many. The standard SMIv2
> row-instancing should be adequate, as would different SNMP
> contextNames or contextEngineIDs, or different SNMPv1 communtities.
> Eliminating this unnecessary example would eliminate the only
> reference to agentX.

A similar issue occurs here.  If this text required the use of AgentX,
or even required the use of SNMP, then I would agree with you, but it
doesn't -- the sentence begins with "For example,".  It is included to
make it easier for Fibre Channel experts with little MIB/SNMP expertise
to understand the document.  What harm does it do ??

> > And
> >    "The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-
> >    MIB [RFC4044] as the index value to uniquely identify each 
> >    Fibre Channel management instance within the same SNMP 
> >    context ([RFC3411] section 3.3.1). "
> 
> Unless the use of fcmInstanceIndex somehow uniquely identifies each
> instance in a manner that is not consistent with normally SMIv2 rules,
> and it is not obvious to me that such is the case, then I think this
> could be worded as:
> 
>     "The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-
>     MIB [RFC4044] as the index value to uniquely identify each 
>     Fibre Channel management instance. "

Again, the reference to SNMP contexts here was intended to be informative
in nature, and informative from a compliance perspective.  That is, the
document's mistake is to list RFC 3411 as a Normative Reference, when
it should be listed as an Informative Reference, and the reference to
SNMP contexts should be given only as an example.  Thus, I propose that
the wording be changed:

     "The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-
     MIB [RFC4044] as the index value to uniquely identify each 
     Fibre Channel management instance, for example within the
     same SNMP context ([RFC3411] section 3.3.1)."

> > "t11vfVirtualSwitchEntry" says 
> > 	"With the definition and usage of virtual switches,
> > fcmSwitchTable now applies to virtual switches which (unlike
> physical
> > fabrics) are create-able via SNMP."
> 
> This could be worded:
>  	"With the definition and usage of virtual switches,
>  fcmSwitchTable now applies to virtual switches as well as physical
>  fabrics, and instances in the table may be created by a remote
> management application."
 
I'd like to suggest an alternate wording:

    	"With the definition and usage of virtual switches,
    fcmSwitchTable now applies to virtual switches as well as
    physical switches, and (in constrast to physical switches)
    it is appropriate to provide the capability for virtual
    switches to be created via remote management applications,
    e.g., via SNMP.

As you said above, with RFC 3410 listed as Informative, SNMP is an
example of a protocol which can be used to transport MIB data.
The other reason for my alternate wording is to retain in the sentence
the original intent of the word "unlike", which serves to explain
why the new usage requires a row-creation capability when the old one
did not.

> Making these changes would eliminate any reference to RFC3411 and
> RFC2741.
 
Why is is necessary to eliminate *Informative* references, which provide
useful information to those who are not experts ??

Keith.