Definition of Managed Objects for Small Computer System Interface (SCSI) Entities
draft-ietf-ips-scsi-mib-09

[Ballot discuss]
Revision to -09 is to be done...

I will hold the sole Discuss till we check
the -09 for Harald's comments and for its inclusion
of the new security considerations and ref fixes
(Bert's Last Call fixes).

a

[Ballot discuss]
Based on Gen-ART review by Harald Alvestrand, and reactions by David Black:

HTA: [SAM-2] and [SPC2] are normative references (defines format for ScsiLUN and other things), but are listed as Working Drafts in the REFERENCE clauses of multiple MIB objects. (In the references section, the draftness seems implied by the URL only)
Is this stable enough for an IETF standard reference?
Or are the references in the MIB wrong?

DLB: (1) The REFERENCE clauses are wrong...
(2) For the normative references, the actual references are to the real
standards (ANSI INCITS)...

...Issue (1) is sufficient to require a respin of the document

HTA: The term "running at high speed" is a gating criterion for whether or not the HS counters are mandatory, but I can't see that it's defined in a testable way.

DLB: ...we'll see about writing a "MUST implement"
requirement for the Counter64 items based on interface speed

[Note]: 'Last Call ends 16 Jan - Last Call comment from Bert is handled in Note to
RFC Editor; PROTO shepherd black_david@emc.com' added by Allison Mankin

[Note]: 'Last Call ends 16 Jan - Last Call comment from Bert is handled in Note to
RFC Editor

PROTO shepherd black_david@emc.com' added by Allison Mankin

12/1 email from David Black to the IPS mailing list:

The SCSI MIB requires a revision to address issues found in
expert review by the assigned MIB Doctor.  That revised draft
is expected in the next couple of weeks.

MIB Doctor review posted to IPS mailing list

-----Original Message-----
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org]On Behalf Of
Wijnen, Bert (Bert)
Sent: Sunday, October 16, 2005 21:03
To: Black_David@emc.com
Cc: Ipswg (E-mail); mankin@psg.com
Subject: [Ips] MIB Doctor reviews for: draft-ietf-ips-scsi-mib-07.txt


Blush... I am really kind of ashamed to often take so long on
the review of these MIB documents. But at the other hand, we as
MIB doctors have quite a few coming at us over the last year,
and the MIB doctors are less eager as a year ago (to say it
nicely).

Oh well, here we go.

------- Compilation/synax issues:

    C:\bwijnen\smicng\work>smicng scsi.inc
    W: f(scsi.mi2), (69,19) The first revision should match the
      last update for MODULE-IDENTITY scsiMIB
    *** 0 errors and 1 warning in parsing

  easy to fix. And I guess you want to use a more current date
  anyways.

------- More or less serious concerns:

- scsiInstAlias
  I would like to see (in DESCIPTION clause) what the persistency
  behaviour is of this read-write object. Further, it is unclear to
  me what this means:
      After reset, the value of this object should remain unchanged."
  What is a "reset"?

  Same for scsiInstScsiNotificationsEnable

  And probably so for other read-write and read-create objects
  in this MIB Module. Pls check them all.

------- I wonder about:

- The  ScsiIdentifier ::= TEXTUAL-CONVENTION
      DISPLAY-HINT  "223a"
  Is that 223a valif? I doubt it given the DESCRIPTION clause.
  Or maybe I do not understand that description clause well enough?
  I am confused by 223a while the max length is 262.
  I am confused by 223a, because it does not look like the octets
  are guaranteed to be ascii (or are they?)

- Same fo ScsiName

- I am a bit surprised by the ScsiName to be (0-262) length and
  ScsiNameIdOrZero to be (0 | 8) length. It looks like ScsiName is
  diffferent than ScsiNameId (which is not defined). I guess it
  is OK, but I can't say it is very crisp and clear.

- I think I would not do:
    scsiAdmin      OBJECT IDENTIFIER ::= { scsiMIB  1 }
    scsiObjects      OBJECT IDENTIFIER ::= { scsiMIB  2 }
    scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  3 }
    scsiConformance  OBJECT IDENTIFIER ::= { scsiMIB  4 }
    scsiNotificationsPrefix OBJECT IDENTIFIER ::= { scsiNotifications 0 }
  but instead
    scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  0 }
    scsiAdmin        OBJECT IDENTIFIER ::= { scsiMIB  1 }
    scsiObjects      OBJECT IDENTIFIER ::= { scsiMIB  2 }
    scsiConformance  OBJECT IDENTIFIER ::= { scsiMIB  4 }

- I see:
    scsiDeviceTable  OBJECT-TYPE
      SYNTAX          SEQUENCE OF ScsiDeviceEntry
      MAX-ACCESS      not-accessible
      STATUS          current
      DESCRIPTION
        "A list of SCSI Devices contained in each instance this agent is
        reporting."
  Is it indeed in "each instance"? The way I read that it means that one
  device is (must be?) contained in each instance.
  Or did you mean "contained in an instance" ??
  I guess my ignorance of SCSI implementations shows.

- I really wonder why you use scsiTrnsptTable and why you do not
  use scsiTransportTable instead. It makes it so much clearer.
  In fact I do wonder so about all the abbreviations you use in
  the MIB module.

------- nits:

- abstract states:

  This memo defines a Management Information Base (MIB), namely managed
  objects for Small Computer System Interface (SCSI) entities,
  independently of the interconnect subsystem layer.

  while its is only a portion of the MIB (we have only one MIB composed
  of many MIB modules). The way we normally express that is:

  This memo defines a portion of the Management Information Base (MIB),
  for use with network management protocols in the Internet community.
  In particular it describes managed objects for Small Computer System
  Interface (SCSI) entities, independently of the interconnect subsystem
  layer.

- it seems to me that the 2nd para in section 1 is redundant (all of that
  is also in the 3rd pare) and so I would remove 2nd para.

- When you use text (like on page 5)
    "... SCSI-related MIBs."
  I would rather see:
    "... SCSI-related MIB modules."
  This to express that we have a single MIB which is composed of many
  MIB modules. I am not too much hung up on it. You may want to check
  for consistency. Sometimes you nicely use MIB Module, other times not.
  I have by the way no issue if you use "MIB" in the figure.

- I think I would use "TCP-MIB" (the real module name) instead of "TCP MIB"
  i.e. add a hyphen. You may want to check several other MIB module names
  for such consistency of use of MIB names too.

- You may want to update the copyright in the MODULE DESCRIPTION clause
  to be for 2005. Honestly, I believe/hope we can approve this doc this
  year!

- Please add an IANA considerations section

- I would move sect 11 into an appendix (I think).
  I also wonder why you do:
        Note that "-NA-" means zero-length string.
  While I would think that a notation of "" would work fine.

  Note that I have not checked the example in detail.

------- for completeness (for you to check/evaluate):

  $ idnits draft-ietf-ips-scsi-mib-07.txt
  idnits 1.77 (21 Aug 2005)

  draft-ietf-ips-scsi-mib-07.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack an IANA Considerations section.
  * Looks like you're using RFC 2026 boilerplate. Better change to RFC
    3978/3979.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 81 pages

  Miscellaneous warnings:
  - Line 3328 has weird spacing: '...ntation  is ru...'
  - Line 3642 has weird spacing: '...sEnable  true...'

    Run idnits with the --verbose option for more detailed information.

------- for completeness, for you to evaluate:

  !! Missing citation for Normative reference:
    P078 L008:    [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "Architecture


  RFC2012 has been obsoleted by RFC4022. You may want to update your ref/citations.
Bert