The Virtual Fabrics MIB
draft-ietf-imss-fc-vf-mib-02

[Ballot comment]
From the SecDire review by Uri Blumenthal:

  Minor nit: the draft formatting program killed a couple of text lines.
  Malformatted end of page 4, missing text on page 9.

[Ballot comment]
I would suggest that the authors address the totality of the comments included in the Gen-Art review performed by Michael A. Patton and recorded at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-imss-fc-vf-mib-02-patton.txt.

[Ballot 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.

[Ballot discuss]
I am entering this DISCUSS to make room for David Harrington's comments on the MIB Doctors list.

There are also a set of comments from Gen-Art review that need to be addressed (probably to be entered by Brian as DISCUSS or COMMENT)

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.

> 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.

> 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.

> 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. "

> "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."

Making these changes would eliminate any reference to RFC3411 and RFC2741.

ANA Last Call Comments:

Upon approval of this document, the IANA will assign a mib-2 number for T11-FC-VIRTUAL-
FABRIC-MIB in the Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) at the following
location:
http://www.iana.org/assignments/smi-numbers

We understand this to be the only IANA Action.

AD review posted to WG list:

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, March 09, 2006 02:37
To: Black_David@emc.com; scott.kipp@mcdata.com; Keith McCloghrie
(E-mail); g.ramkumar@mcdata.com
Cc: Imss (E-mail); Dan Romascanu (E-mail)
Subject: [imss] AD review for: draft-ietf-imss-fc-vf-mib-01.txt



- SMICng states
  C:\bwijnen\smicng\work>smicng t11fcvf.inc
  E: f(t11fcvf.mi2), (77,4) Row "t11vfCoreSwitchEntry" may not have columns with M
  AX-ACCESS of read-write if any column is read-create
  E: f(t11fcvf.mi2), (219,4) Row "t11vfPortEntry" may not have columns with MAX-AC
  CESS of read-write if any column is read-create

  *** 2 errors and 0 warnings in parsing

  Probably has to do with the read-create comment I make below as well.

- When I see:
  t11vfCoreSwitchSwitchName OBJECT-TYPE
      SYNTAX      FcNameIdOrZero
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The Core Switch_Name (WWN) of this Core Switch. A
            zero-length string for this field is not allowed. "
      ::= { t11vfCoreSwitchEntry 1 }

  I wonder if it would not be better to use a

      SYNTAX      FcNameIdOrZero (SIZE(8 | 16))

  Because that at the same time makes the restriction (zero-length
  not allowed) machine-readable!!

-  t11vfCoreSwitchMaxSupported OBJECT-TYPE
      SYNTAX      Unsigned32

  Reading the description clause, it seems to me that a value of zero
  is not allowed. So I would add a range to exclude zero.

- Mmm a read-create SYNTAX in a row that does not have a RowStatus
  SYNTAX:
    t11vfCoreSwitchStorageType OBJECT-TYPE
      SYNTAX      StorageType
      MAX-ACCESS  read-create
  Peobably just read-write?

- t11vfVirtualSwitchCoreSwitchName
  is a zero-length string allowed? ANd if so what does that mean?


- t11vfLocallyEnabledRowStatus
  Meager DESCRIPTION clause.
  Missing if any objects can be changed if in active state

- In MODULE-COMPLIANCE I See
          OBJECT t11vfVirtualSwitchRowStatus
          MIN-ACCESS read-only
          DESCRIPTION
              "Write access is not required."

  Would you want to add the SYNTAX is many just active in that case?

- In MODULE-IDENTITY macro:
            Copyright (C) The Internet Society (2006).  This version of
            this MIB module is part of RFC yyyy; see the RFC itself for
            full legal notices."
  -- RFC Ed.: replace yyyy with actual RFC number & remove this note
      REVISION        "200601230000Z"
      DESCRIPTION
              "Initial version of this MIB module, published as RFCxxxx."
  -- RFC-Editor, replace yyyy with actual RFC number & remove this note

  Probaly xxxx and yyyy are the same !!??

NITS:


- the formatting of the MIB in this document is not a preal of beauty.
  If you do a new rev, you may want to pay some attention to that.
  Actually formatting is somewhat weird at several places.

- The acknowledgement section seems to indicate that it is an INCITS work
  item and has nothing to do with IETF.
  The acknowledgement section of the other imss MIBs I reviewed earlier
  this week were better at that.
  Might at least want to thank IETF IMSS WG members?

- IANA COnsiderations section at a weird (at least different than normal)
  place.