Subject: [Ips] IPS WG Last Call: iSNS MIB

From: [email-masked]
Date: Fri, 3 Mar 2006 10:02:58 -0500

And you thought this would never happen ... :-)

This message announces an IP Storage (ips) Working Group
Last Call on the iSNS MIB draft:

               Definitions of Managed Objects for iSNS 
                   (Internet Storage Name Service)

			draft-ietf-ips-isns-mib-08.txt

This WG Last Call will end at 12:00 midnight (end of day) Eastern
Time on Friday, March 17, 2006.  All technical comments and
requests for changes need to be posted to this list.  Editorial
comments and corrections may be sent directly to the draft
editor, Scott Kipp <[email-masked]> and cc:'d to me
(David Black <[email-masked]>) as WG chair. 

If serious technical issues arise, they will be discussed during
the IPS WG's meeting in Dallas.

Thanks,
--David (IPS WG Chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 3 Mar 2006 09:52:58 -0800 (PST)

> (David Black <[email-masked]>) as WG chair. 
 
See below.

Keith.
-----------------

1. Incorrect usage of MODULE-COMPLIANCE:

>  isnsServerComplianceV1 MODULE-COMPLIANCE
>       STATUS                  current
>       DESCRIPTION
>   "This set of groups is required for full implementation
>    by an iSNS Server if it has the resources to keep
>    track of the number of registered objects in iSNS Server
>    instances over time."
>       MODULE       -- this module
>       MANDATORY-GROUPS {
>           isnsServerNumObjGroup
>                        }
>       ::= { isnsCompliances 3 }

   First, MODULE-COMPLIANCE statements are not accummulative.  In other
   words, each MODULE-COMPLIANCE, including the one quoted above,
   specifies the minimum requirements needed to claim a particular
   level of compliance.  The one above says it is "for full
   implementation by an iSNS Server", and it requires support for just
   a single object group.  Therefore, any iSNS Server which supports
   the isnsServerNumObjGroup can claim to be a full implementation
   of the MIB, irrespective of any other groups/objects it might/might
   not support.  This is clearly wrong.

   Second, a MODULE-COMPLIANCE is the wrong place to put an "if" clause.

   To resolve both of these, change the above MODULE-COMPLIANCE into
   a GROUP clause, which specifies isnsServerNumObjGroup as Conditional
   Mandatory, and include this GROUP clause in (presumably) each of the
   remaining MODULE-COMPLIANCE clauses:  isnsIscsiServerComplianceV1 &
   isnsIfcpServerComplianceV1.

2. Compilations errors/warnings:

- the position of isnsSrvrInstCntrlNodeAuth in its SEQUENCE doesn't
  match its OID; move it to come after isnsSrvrInstEnblCntrlNdeMgtScn
  in the SEQUENCE,
- you are required to have at least one read-able object in every table.
  In your MIB, isnsCntlNodeFcPortTable & isnsRegIscsiNodeTable only have
  one object which is not-accessible.  You must change the one object
  in both cases to be read-only, and  because they are now read-only,
  they now need to be included in an OBJECT-GROUP.
- MODULE-COMPLIANCE appears twice in the IMPORTS clause; delete the
  duplicate.
- delete the items in the IMPORTS which are never used:
  Gauge32, ZeroBasedCounter32 ZeroBasedCounter64,
  InterfaceIndexOrZero, PhysicalIndexOrZero & StorageType

3. The Abstract section:

- if I recall correctly, the Abstract section is not supposed to
  include references.

4. References

- section 2 begins:

      The iSNS protocol can be used by IP based storage devices for
      dynamic registration and discovery of storage devices in the
      network [RFC 471]. 

  I suspect this reference should be to [RFC4171] ??

- when the unused TC's (see above) are removed, then a number of the
  References will no longer be referenced and need to be removed.

5. IANA Considerations

- delete "4371" from:

                   ::=  { transmission 4371 }

  it is inappropriate to list unassigned values.

- I don't think this qualifies as a MIB which should go under the
  "transmission" subtree -- the rule of thumb for the transmission
  subtree is that the "{ transmission nnn }" OID is assigned to the
  media-specific MIB (see section 4 of RFC 2863) for the type of
  interface to which ifType=nnn has been assigned.

  I suggest that this MIB ask for an assignment under the "mib-2"
  subtree.  To do this, just change each occurrence of "transmission"
  to "mib-2".

6. Editorial:

- isnsRegIscsiNodeEntry's DESCRIPTION includes the words:

       ...   The RowStatus managed object provides a method to
       delete registered nodes ...

  but there is no RowStatus object in this MIB.  Delete the sentence.

- I personally don't like the indentation and spacing scheme used in
  the MIB, but since the same scheme is used very consistently, it's
  not a problem.

- I personally don't have a problem with the OID hierarchy in this MIB,
  but Appendix D of RFC 4181 recommends a different layout.