[storm] prelim review of draft-ietf-storm-ifcpmib-00.txt

["David Harrington" <[e-mail]>]

Hi,

I am a MIB Doctor. I have chosen to unofficially review this draft.
This is NOT an official MIb Doctor review or a complete review.
I am doing this review to advise you about things that may or may not
hold up your document in an official MIB Doctor review. Addressing the
concerns might make later approval easier.

1) I already posted the idnits output.
2) It is good that the MIB module passes libsmi - a really good sign!

3) 4) BCP 139 (RFC 5249) points to a series of templates for MIB
documents, that help to layout documents in a manner that makes it
easier for MIB Doctors to do their reviews. The templates can be found
at tools.ietf.org.

I edited the templates for the MIB Doctors; the templates are now out
of date, due to the IETF Trust updates, but most of the information
should still be relevant.

In some cases, the templates represent exact wording that must be
used, such as for the security considerations.
Other aspects may not need to be followed closely, but the information
will need to be there, and it is easier if it is clearly marked so MIB
Doctors can find it.

4) The IETF Management Framework has long held that there should be a
separation between the data modeling language (SMI), the data models
(MIB modules), and the protocol(s) that can carry the data.
Theoretically, SNMP is only one protocol that can carry MIB module
information. In practice, SNMP has been the only protocool that did
so, so many documents like RFC4369 were not careful about keeping
these separate.

In recent years, as the IETF has moved away from an attitude of "write
a MIB" to do management, and to consider the requirements of the
managed technology and operational environment, the IETF has a adopted
a multi-protocol approach to management. We now have IETF standards
for syslog and Netconf, plus other protocols. As a result, references
to SNMP in a MIB module document should be couched as an example
protocol that can access the MIB data.

It would be a good thing to find any references to SNMP, and reword
those to make them examples, so that other protocols could also be
used to access the MIB data.

The abstract is the first instance I found of this.

5) I recommend rewording the abstract to read more this way:

   This memo defines a portion of the Management Information Base
(MIB)
   for use with network management protocols.  In particular it
defines
   objects to monitor and control iFCP Gateway instances, and their 
   associated sessions. 

The description in the abstract that discusses iFCP and iFCP gateways
can 
be moved the Introduction or an Overview section.
This would be more consistent with BCP 139, and avoid the problem
mentioned in 4).

6) There is an xml2rfc template available. Use of xml2rfc will help
you avoid issues such as lines that are too long, copyright
boilerplate updates, author address sections, etc. So you might pass
idnits more easily. This is a significant investment of time if you
are not currently using xml2rfc, but it can save you lots of time
later, if multiple revisions are required (and multiple revisions are
common during the approval process).

7) MIB Doctors tend to be an anal sort, and one point that is often
raised is that the MIB module in your document is not a MIB. There is
only one MIB and it is made up of many MIB modules. You should change
this to avoid having the problem later. For example, 

8) "statistics are provided in both standard and low-capacity
(counter32) methods." Both Counter64 and Counter32 are standard
counters. Change "standard" to "high-capacity".

9) IPsec is spelled IPsec, not IPSec. The security considerations
boilerplate was written that way for a reason.

10) The IANA section should read this way:


        The MIB module in this document uses the following
IANA-assigned
        OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

        Descriptor        OBJECT IDENTIFIER value
        ----------        -----------------------
        sampleMIB         { mib-2 XXX }

with the sampleMIB and XXX values filled in accordingly.

11)  from
http://www.rfc-editor.org/rfc-editor/instructions2authors.txt 

      4.1.  First-Page Header

      Please see the front page of this memo for an example of the
front
      page heading.  On the first page there is no running header.
The
      top of the first page has the following items left justified:

      "Network Working Group"

         This traditional title must be left-justified on the first
line
         of the heading.  It denoted the ARPAnet research group that
         founded the RFC series.

The top of the first page is not for the WG name.

***However***, a new guidelines to authors of internet-drafts has just
been published, that doesn't mention this.
See http://www.ietf.org/id-info/guidelines.html and discuss it with
your chairs.

11) The copyright notice in the MODULE-IDENTITY should refer to RFC
XXX in which the MIB module appears.  There should be a note to the
RFC editor to fill in the XXX (or whatever) when the RFC is published.

(unless the IETF Trust changed this and I am not up-to-date).

12) I think the description in ifcpLclGtwyInstAddrTransMode
OBJECT-TYPE may be problematic.
Per RFC2578:
   As experience is gained with an information module, it may be
   desirable to revise that information module.  However, changes are
   not allowed if they have any potential to cause interoperability
   problems "over the wire" between an implementation using an
original
   specification and an implementation using an updated
   specification(s).
While iFCO might declare address translation obsolete, I think you
cannot prove
that this value will always be (1) in all implementations. I think the
correct way to
describe this situation os to deprecate the value in the enumeration,
in case anybody 
anywhere has implemented it, and describe that it has been obsoleted
by iFCP.
Change the "will" to "should" (or SHOULD)
Then you write two compliance clauses - one that describes compliance
to 4369 and a 
new compliance clause for this document.

I also note that the DEFVAL clause names the obsolete value. ;-)

You are using REFERENCE "RFC4172". Is this being updated to make
address translation obsolete?
If so, you should change the reference.

13)    ifcpSessionRmtNpFcidAlias          OBJECT-TYPE
s/This is obsolete/This object is obsolete/

14) This is sort of a follow-on to point 12)
   ifcpGatewayCompliance MODULE-COMPLIANCE probably should be
deprecated in case anybody implemented the MIB with the obsolete
enumeration value (which may be likely given that it was the DEFVAL)

15) In my experience, naming the compliance clause to match the RFC
that defines it has worked fairly well.
What will happen if a new update is done, and the new update also has
NoTrans ?
Most vendors claim compliance to an RFC, so naming your compliance
clause by its RFC makes this consistent.

Hope this helps,

David Harrington
[e-mail]
[e-mail]
[e-mail]