Re: IPS WG Last Call: iSNS MIB

> 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 protected]> and cc:'d to me
> (David Black <[email protected]>) 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.

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