[Ips] MIB Doctor reviews for: draft-ietf-ips-scsi-mib-07.txt

["Wijnen, Bert (Bert)" <[e-mail]>]

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
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, October 11, 2005 21:00
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: SCSI MIB re-review comments
> Importance: High
> 
> 
> Bert,
> 
> I'm still looking for your MIB Doctor expert (re)-review
> comments on the IP Storage SCSI MIB:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-07.txt
> 
> I may be out of runway to get a revised draft prior to
> the Vancouver IETF (I think you were originally going
> to re-review this a month ago), so would it make sense to
> send this MIB to IETF Last Call, and deal with any re-review
> comments from you as IETF Last Call comments?
> 
> Thanks,
> --David

_______________________________________________
Ips mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ips