Subject: [Ips] MIB Doctor review: ips-fcip-mib-5-reviewed.txt

From: [email-masked]
Date: Fri, 22 Oct 2004 16:42:51 -0700

All,

A new FCIP MIB will soon be published (it has been submitted to the ID
office.
Below is a list of issues/changes requested from the expert review of the
MIB along with the resolution to the comments.
If anyone sees any issues with the new MIB, please let David or I know or
post to the IPS mailing list ASAP.

Thanks to Anil and Ravi for getting this updated.

Elizabeth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 22, 2004 1:51 PM
To: Elizabeth Rodriguez
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ips] MIB Doctor review: ips-fcip-mib-5-reviewed.txt

Elizabeth, Keith, Mike:

Ravi and I have submitted an updated draft-ietf-ips-fcip-mib-06.txt
(attached below), addressing the comments from MIB Doctor (Mike M) and
Elizabeth.

Please find my responses marked with Anil> within the text below.

Elizabeth wrote:

One thing that has changed since you first published this MIB is the
boilerplate and guidelines for the MIB.
I am including a sample boilerplate that some have been using, for your
reference.

Anil> Updated.

MIB Doctor (Mike MacFaden) wrote:

This is full review.

A. Documentation Guidelines
   o Correct MIB boilerplate (3.1)                  -> present
   o Narrative Section (3.2)                        -> present, needs work
   o Definitions Section (3.3)                      -> present
   o Intellectual Property Section (3.4)            -> present, does not
match sectio 5, rfc3668.

Anil> Fixed.

   o References section (3.5)                       -> present, missing
iana url for iftype

Anil> Added.

   o Security section (3.6)                         -> present
   o IANA Considerations Section (3.7)              -> warning, has "mib-2
8889" instead of "XXX"

Anil> Fixed.

   o Copyright Notices section (3.8)                -> present,
       - Copyright found in MODULE-IDENTITY?        -> NO

Anil> Added.

   o Spelling?                                      -> 2 words (occurred,
conections)

Anil> Corrected.

   o Definitions section detail

Here are the diagnostics from certain mib syntax checkers:
Diagnostics  from Version 0.4.2 smilint
 version 0.4.2 of smilint -m -s -l 6 --> no errors detected.
  Bill Fenner's automated check here:
  http://www.icir.org/fenner/mibs/htmllint/FCIP-MGMT-MIB.html

Comments/Nits:
  1. Narrative section should use complete token:  "described in [BB2],"
     should be "[FCBB2]"

Anil> Fixed.

  2. Description for fcipEntityTcpConPort needs to remove duplicate:
"entity entity"

Anil> Fixed.

  3. Description for fcipLinkFcipBB2LkaTimeOuts mispells "occured"

Anil> Fixed.

  4. Description for fcipTcpConnGroup  mispells "conections"

Anil> Fixed.

  5. Narrative section could use an ascii art picture depicting FC Device/FC
Entity/FCIP Link,
     Data Engine relationship to make the relationships easier to grasp.

Anil> Added. Primary reference is always in base FCIP draft.

  6. Narrative section 2.5: interpreted the prose to mean at any point in
time
     either the Dynamic Route Table is populated or the Static Route Table
is populated.
     I am not clear as to how to determine which table is being used.

Anil> Added wording to indicate that both can co-exist, and Static Route
Table takes precedence in case of conflicts.

  7. Narative "3. Relationship to other MIBs" states:
        Objects accessible from other MIBs applicable to FCIP devices have
        not been included in this MIB.
     I would add to this introduction something like :
         The following lists all other applicable MIB modules/objects that
should be present
         with FCIP-MGMT-MIB>

Anil> Added.

  8. IANA ifType 'fcipLink' not in this document yet, will need to be before
last call.

Anil> Added.

  9. Section 3.2 relation to Interfaces. This section should describe what
should go into the
     ifStackTable for ifType 'fcipLink' or ifXTable. Suggest you set
ifUpper/ifLower for this ifIndex to 0.
     That is the simple answer and will not lead to an explosion of entries
in ifStackTable.
     FC-MGMT-MIB is a good example for how to document interaction with
ifTable/ifXTable/ifStackTable.
     My suspicion is that there is no need to have this ifEntry at all given
the descriptions presented.

Anil> Given that fcipLink interfaces may be viewed as independant of the
physical interfaces,
there does not appear to be a lot of value in specifying ifStackTable
entries. Also looked at FC-MGMT-MIB for guidance, no mention of
ifStackTable. We feel that entries in ifTable suffice to describe these
interfaces, and additional ifStackTable entries would serve little purpose.

 10. Section 3.4 shouldn't need such a statement. Typically one is
narrowing/clarifying
     the definition of ifTable objects for the particular interface. Any
"conflict"
     should be revised in the working group.
     "(RFC 2863 takes precedence over these guidelines in the event of any
conflict.)"

Anil> Statement removed.

 11. Definition of "ifSpeed" is ambiguous. If you do a bind(INADDR_ANY) then
which speed should you use?

Anil> ifSpeed of an FCIP Link is the same as that of the physical
interface. At best, it would be able to use the full bandwidth of the
interface.There is no way to gauge the available speed at any given instant.

 12.  ifPromiscuousMode        This will normally be 'false'
      so under what conditions would it be true?

Anil> It will never be true. Accordingly, removed the word "normally".

 13. Suggest: ifConnectorPresent       This will normally be 'false'.
      you plainly state this is set to 'false'

Anil> Done.

 14. Section 3.3 seems rather shallow -- not sure how this mib module
generally affects this one.

Anil> Only point we were making here is that on an FCIP device, there is
bound to be an FC interface(s),
and that we expect the FC portion of the management is fully handled by the
FC Mgmt MIB.

 15. FcEntityMode -> does not give guidance when to use other(1), assume
that might be used if
     the value is not yet set?

Anil> At this time, there is no other known interoperable method. 
Anil> Removed
the value 'other'.

 16. Can the items in the FCIP group be changed at any time or is there some
state a FCIP Device
     should be in before one changes fcipDynIpConfType,
fcipEntitySACKOption?

Anil> There is no state an FCIP Device needs to be in before such changes.

 17. RFC 1323, 2474 not listed in Normative reference section.

Anil> Added.

 18. fcipEntityName should use SnmpAdminString not DisplayString

Anil> Done.

 19. I assume if I configure a fcipEntityInstanceTable and set it to
active(1), then the tcpConnTable(if ipv4)
     will be visible to show the TCP state (eg LISTEN)? Might want to
mention what setting fcipLinkStatus
     to active will do. Also describe what setting it to destroy(6) will do.
RMON2 mib provides
     good examples of documenting what your RowStatus object does. Same
issue for fcipLinkStatus
     At a minimum, specify what needs to be set in order to make a row
active, and define the defaults
     for those optional ones. fcipStaticRouteStatus too -- wasn't sure what
is considered valid agent
     behavior to create rows in this table if dynamic routing was active.

Anil> Updated descriptions of fcipEntityRowStatus, fcipLinkStatus, and
fcipStaticRouteStatus to specify
behavior for active(1) and destroy(6) values.

 20. fcipLinkLocalFcipEntityMode  -- should the be read-only?

Anil> Yes, it's read-only.

 21. fcipTcpConnTable might benefit from a TimeStamp object containing the
creating time of the tcp session.

Anil> We could not agree upon sufficient need to add the above object.

 22.  fcipDiscoveryDomainName is SYNTAX DisplayString  --> should be
SnmpAdminString?

Anil> Yes, changed.

 23. fcipLinkErrorsTable doesn't list any discontinutity object. Assuming
default.

Anil> Could not find sufficient justification for such an object. 
Anil> However,
note that links have corresponding
interfaces which do have continuity objects.

 24. Copyright should be updated to 2004 at next revision

Anil> Fixed.

 26. Section 6 lists objects but does not describe why viewing the
identification or topology information
     is considered senstive. No mention of writable objects that if abused
could lead to disruption
     are described. See section 3.6 of [1].

Anil> Added two writable objects to section. As for the readable objects
already specified, we feel that
specifying that these are identification or topology information tells you
why they are considered sensitive (which is essentially what the FC Mgmt MIB
does).

MIB has been updated and verified to be free of compile errors. Change log
added to reflect changes since the -05 version.

Regards,
Anil R. and Ravi N.
(See attached file: draft-ietf-ips-fcip-mib-06.txt)

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