Fibre Channel Routing Information MIB
draft-ietf-imss-fc-rtm-mib-04

IANA Last Call Comments:

Upon approval of this document, the IANA will
assign a mib-2 number for T11-FC-ROUTE-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
for this document.

Keith McCloghrie promised a new rev based on below.

AD review posted to WG list:


-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Monday, March 06, 2006 19:34
To: Black_David@emc.com; cds@cisco.com; skode@cisco.com; Keith
McCloghrie (E-mail); sgai@cisco.com
Cc: Imss (E-mail); Dan Romascanu (E-mail)
Subject: [imss] AD review of: draft-ietf-imss-fc-rtm-mib-02.txt


This document is ready for IETF Last Call.

One topic that I would prefer to see addressed:

- When I see:
    t11FcRouteDestAddrId OBJECT-TYPE
      SYNTAX      FcAddressIdOrZero
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The destination Fibre Channel Address Identifier of
          this route.  A zero-length string for this field is
          not allowed."
      ::= { t11FcRouteEntry 1 }

  I then wonder why the syntax is not:

      SYNTAX      FcAddressIdOrZero (SIZE(3))

  So that the restriction that zero-length is not allowed is
  also machine readable.

  COuld be addressesd after IETF Last Call, even with an RFC-Editor note.

Mainly have some NITs below.
You may consider them as initial IETF Last Call comments.
Let me know if you rather do a new rev first or if you
prefer to do IETF LC now. I will probably let IETF LC extend
beyond the IETF week, because people are probably busy reviewing
documents for the IETF week itself.

- t11FcRouteRowStatus has a pretty meager DESCRIPTION clause
  For example, from the DESCRIPTION clause of t11FcRouteIfDown
  it seems that maybe a 'destroy' to the RowStatus object
  may not take immediate effect? You might want to describe that.
  It is also unclear if any writeable objects can be written
  when a row is active?


- The 4 OBJECT clauses that you did as comments in the
  MODULE-COMPLIANCE are normally put as comments inside the
  DESCRIPTION clause of the MODULE-COMPLIANCE clause itself.
  That way the text is better kept when MIB module gets
  extracted from RFC. Not a blocking comment though.

- Section 7 seems redundant with the back matter, and might as
  well be removed.

- In the references section, are the details for [FC-SW-4] now
  known? If so, might want to fill them out.

Bert