Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI)
draft-ietf-storm-iscsimib-04

IANA has reviewed draft-ietf-storm-iscsimib-03 and has the following comments:

IANA has a question about the action.

IANA understands that, upon approval of this document, there are no new actions for IANA to complete.

IANA understands that this is the definition of a MIB for iSCSI and that the document obsoletes RFC 4544.

IANA confirms that the the following IANA-assigned OBJECT IDENTIFIER value is recorded in the SMI Numbers registry:

Descriptor OBJECT IDENTIFIER value
---------- -----------------------
iscsiMibModule { mib-2 142 }

Question->Since the document obsoletes RFC 4544, do the authors intend
to include this document as the second Reference for the mib-2 142
in the registry?

IANA further understands that no additional actions are required upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)) to Proposed Standard


The IESG has received a request from the STORage Maintenance WG (storm)
to consider the following document:
- 'Definitions of Managed Objects for Internet Small Computer System
  Interface (iSCSI)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a portion of the Management Information Base
  (MIB) for use with network management protocols. In particular, it
  defines objects for managing a client using the Internet Small
  Computer System Interface (iSCSI) protocol (SCSI over TCP).

  This document obsoletes RFC4544.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/ballot/


No IPR declarations have been submitted directly on this I-D.

February 17, 2012 MIB DOCTOR Review: http://www.ietf.org/id/draft-ietf-storm-iscsimib-01.txt 

Performed by Michael R. MacFaden, VMware, Inc
According to http://tools.ietf.org/html/rfc4181

This review only covers syntax, SMIv2 rules usage of the MIB module itself, not the draft.
Some of the things mentioned below exist the prior version of the mib, not this update.

1 boilar plate - check
2. Narative Sections - check
3. Security Consideratons - check
4. IANA Considerations - missing editors note.
  Section 9 needs the following verbage to be added.
      Editor's Note (to be removed prior to publication):  this draft
      makes no additional requests of the IANA.
5. No new namespaces
6. References section - check
7. copyright notice - check
8. Intellectual Property section - missing
9. This change updates existing mib rfc http://www.ietf.org/rfc/rfc4544.txt - check
  Backward compability checks: (oids, object-identities, remained the same)

Other items checked --
sytax check: smilint -l9 - no errors
smicng : not run
spelling: Aspell --- no misspellings found.
URLs validated: checked for valid, not-broken links:
            http://www.iana.org/assignments/protocol-numbers

References in MIB module  not found in normative (sec 10.1)
IscsiTransportProtocol TC ->  "RFC791, RFC1700
enumerations: each element described
  - IscsiDigestMethod

DiscontinuityTime is syntax: TimeStamp
All Counters: define their discontinuity timestamp.

Uncommon stuff:
1)  In IscsiPortalAttributesEntry has RowStatus as second item int he conceptual row,
not after iscsiPortalStorageType.

2) iscsiPortalRoles does not have a DEFVAL when most others do in this conceptual table.
iscsiPortalAddrType has def val of IPV4? when the iscsiPortalAddr has no default to go with it?

3) iscsiNodeAttributesEntry  sez:
  An entry (row) containing mana
  vs 'conceptual row' which is used inconsistently.

4)  (e.g. not created via this MIB).  vs MIB module. There is but one MIB as Dr Case would say.

5) 64 bit counters with SNMPv1 support for 32 bit high/low? kinda
  iscsiSsnTxDataOctets, iscsiSsnRxDataOctets, provides only low word: iscsiSsnLCTxDataOctets, iscsiSsnLCRxDataOctets
  Compliance phrasing is a bit odd:
  "A Low Capacity shadow object of iscsiSsnTxDataOctets
        for those systems that don't support Counter64.
    instead of 'for those systems which are accessible via SNMPv1 only'

6) Notifications are required to have a rate limited implementation by a description,
  yet the number of times the failure occurred  is not conveyed in the notifcation varbind list.
    iscsiTgtLoginFailure, iscsiIntrLoginFailure, iscsiInstSessionFailure

    To avoid sending an excessive number of notifications due
        to multiple errors counted, an SNMP agent implementing this
        notification SHOULD NOT send more than 3 notifications of
        this type in any 10-second time period."

Signed,
Mike MacFaden

MIB Doctor Review part 1 - SMI syntax check

February 17, 2012 MIB DOCTOR Review: http://www.ietf.org/id/draft-ietf-storm-iscsimib-01.txt 

Performed by Michael R. MacFaden, VMware, Inc
According to http://tools.ietf.org/html/rfc4181

This review only covers syntax, SMIv2 rules usage of the MIB module itself, not the draft.
Some of the things mentioned below exist the prior version of the mib, not this update.

1 boilar plate - check
2. Narative Sections - check
3. Security Consideratons - check
4. IANA Considerations - missing editors note.
  Section 9 needs the following verbage to be added.
      Editor's Note (to be removed prior to publication):  this draft
      makes no additional requests of the IANA.
5. No new namespaces
6. References section - check
7. copyright notice - check
8. Intellectual Property section - missing
9. This change updates existing mib rfc http://www.ietf.org/rfc/rfc4544.txt - check
  Backward compability checks: (oids, object-identities, remained the same)

Other items checked --
sytax check: smilint -l9 - no errors
smicng : not run
spelling: Aspell --- no misspellings found.
URLs validated: checked for valid, not-broken links:
            http://www.iana.org/assignments/protocol-numbers

References in MIB module  not found in normative (sec 10.1)
IscsiTransportProtocol TC ->  "RFC791, RFC1700
enumerations: each element described
  - IscsiDigestMethod

DiscontinuityTime is syntax: TimeStamp
All Counters: define their discontinuity timestamp.

Uncommon stuff:
1)  In IscsiPortalAttributesEntry has RowStatus as second item int he conceptual row,
not after iscsiPortalStorageType.

2) iscsiPortalRoles does not have a DEFVAL when most others do in this conceptual table.
iscsiPortalAddrType has def val of IPV4? when the iscsiPortalAddr has no default to go with it?

3) iscsiNodeAttributesEntry  sez:
  An entry (row) containing mana
  vs 'conceptual row' which is used inconsistently.

4)  (e.g. not created via this MIB).  vs MIB module. There is but one MIB as Dr Case would say.

5) 64 bit counters with SNMPv1 support for 32 bit high/low? kinda
  iscsiSsnTxDataOctets, iscsiSsnRxDataOctets, provides only low word: iscsiSsnLCTxDataOctets, iscsiSsnLCRxDataOctets
  Compliance phrasing is a bit odd:
  "A Low Capacity shadow object of iscsiSsnTxDataOctets
        for those systems that don't support Counter64.
    instead of 'for those systems which are accessible via SNMPv1 only'

6) Notifications are required to have a rate limited implementation by a description,
  yet the number of times the failure occurred  is not conveyed in the notifcation varbind list.
    iscsiTgtLoginFailure, iscsiIntrLoginFailure, iscsiInstSessionFailure

    To avoid sending an excessive number of notifications due
        to multiple errors counted, an SNMP agent implementing this
        notification SHOULD NOT send more than 3 notifications of
        this type in any 10-second time period."

Signed,
Mike MacFaden

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

David L. Black (david.black@emc.com) is the Document Shepherd.
The Document Shepherd has reviewed this version of the document
and believes that it is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had sufficient review from key WG members.  This is a
minor update of the iSCSI MIB and benefits from WG review of the
iSCSI drafts to which it corresponds.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

The WG is largely silent, but the Document Shepherd believes that the
need for this MIB update is clearly understood by the WG as a whole,
and no objections have been raised.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough.

Yes.

        Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

A MIB Doctor review is required.

  (1.h) Has the document split its references into normative and
        informative?

Yes.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

RFC publication requests have already been submitted for the two
Internet-Drafts that are normative references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section has been checked.  No IANA action is
required because the existing MIB object identifier value is reused.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes, relying on MIB checks run by the authors.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

  This document defines a portion of the Management Information Base
  (MIB) for use with network management protocols. In particular, it
  defines objects for managing a client using the Internet Small
  Computer System Interface (iSCSI) protocol (SCSI over TCP).

  This document makes minor updates to the iSCSI MIB originally
  defined in RFC 4544 to match the current SCSI specifications.

    Working Group Summary

  Nothing exceptional to note.

    Document Quality

  There are multiple implementations of the iSCSI MIB (RFC 4544)
  that is updated by this document.