Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP)
draft-ietf-ips-fcip-mib-09

[Ballot discuss]
There is one thing that I would like to understand before approving this document.  Specifically:

Why does the FCIP MIB have its own TCP Connection Table, rather than augmenting the original TCP Connection Table?

[Ballot comment]
!! Missing Reference for citation: [RFC4001]
  P007 L008: -- [RFC4001], [RFC4044], [RFC2863], [RFC2580], and [RFC3411].

[Ballot comment]
Nits from Gen-ART review by John Loughney:

1) Please expand FCIP (and FC) in the title & abstract. Its hard to keep
track of all of the acronyms in the IETF.
2) Subsections in Section 2 need a blank line between the subsection
title & the text.

[Ballot discuss]
The security considerations include:
  >
  > In particular, write access to
  > fcipDiscoveryDomainName and fcipEntityAddress can cause a loss of
  > reachability to portions of the SAN, ...
  >
  This is the first place that Storage Area Networks are discussed
  in the document.  While FC is often used to implement SAN, this
  seems like an odd place for this to come to light.  Can it be worded
  in a more general manner?

Late Last Call Comments:
Upon approval of this document the IANA will make a MIB OID assignment under the transmission branch.  Specifically, { transmission 224 } is requested.  This registration will take place in the following registry:
http://www.iana.org/assignments/smi-numbers

MIB Doctor is now OK with revision 9.

One last nit (can be fixed by RFC-Editor note):


!! Missing Reference for citation: [RFC4001]
  P007 L008: -- [RFC4001], [RFC4044], [RFC2863], [RFC2580], and [RFC3411].

MIB Doctor re-review comments posted to IPS list

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Sunday, October 16, 2005 22:02
To: 'ravin@lightsand.com'
Cc: 'Ipswg (E-mail)'
Subject: MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt


OK, I have re-checked the new revision (08) of this document.

Here are my findings:

When you revise a MIB module, then both the LAST-UPDATED
and REVISION clauses must be kept in sync.

  C:\bwijnen\smicng\work>smicng fcip.inc
  W: f(fcip.mi2), (39,21) The first revision should match the
    last update for MODULE-IDENTITY fcipMIB


There still seem to be citation/reference issues:

  !! Missing citation for Normative reference:
  P029 L052: [FC-SW-3]  Fibre Channel Switch Fabric -3 (FC-SW-3), T11/03-018v4,

I see it is used in a REFERENCE clause in the MIB
See below at problem with RFC2571

  !! Missing citation for Normative reference:
  P030 L030: [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black, "Definition

  !! Missing citation for Normative reference:
  P030 L018: [RFC2571]  Harrington, D., Presuhn, R., and B. Wijnen, "An

RFC2571 has been obsoleted by the way by RFC3411.
I think you IMPORT from RFC3411
Further your IMPORT from RFC4001, which causes a normative reference
that I am missing.

Normally you add some text just before the MIB module starts aka

  The following MIB modules has IMPORTS from [RFC3411] and [RFC4001]
  and refers  to [FC-SW-3] in REFERENCE clauses.


Below is my revision 7 review, and I am commenting on the ones that
have (as far as I can tell) not been addressed yet:

Following has not been addressed.
> - Table fcipLinkErrorsTable contains a lot of Counter32 columns.
>  Each of the DESCRIPTION clauses is supposed to describe if there
>  can be discontinuity situations, and if so, which timer is to
>  be used to detect that.
>
I know Keith has some disagreement with me, but I prefer that
it is made clear to the readers/implementors as to do/expect.
At least I'd like to see in the Table or Entry DESCRIPTION clause
that all counters have "xxx as discontinuity indicator"

> - I think the Security COnsiderations section is weak.
>  It lists sensitive objects, but it does not describe much about
>  why they are sensitive and what kind of damage can happen if
>  improperly changed.
>  The security guidelines on www.ops.ietf.org  explains how it
>  should be done in an acceptable manenr
>

I don't think I see any change to the security considerations.
Oh well... we'll see what security ADs will have to day about it.

Bert

My MIB-Doctor review to revision 7.

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Wednesday, April 20, 2005 12:43
To: 'ravin@lightsand.com'
Cc: Ipswg (E-mail)
Subject: MIB Doctor review: draft-ietf-ips-fcip-mib-07.txt


I have done a MIB-Doctor review of this draft.

Below are my comments. Some are serious, some are
mor nits/admin-related. But it would be good to address
them and to spin a new rev. Pls do so quickly.
Since my last review (rev 5, early Nov 2004) 5 months
have gone by.

Pls consider the MIB Review Guidelines as per (now approved as BCP)

  http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.txt

See also guidelines for security considerations at
 
  http://www.ops.ietf.org/mib-security.html

The revision 7 does compile clean. But...
some of it is just minor admin things, but quite a few are serious.

- Top of page 4
    Each FCIP Entity managed by this MIB is referred to as a FCIP
    Instance. The MIB is broken up as follows:
  I would change both "MIB" occurences into "MIB module".

- Section 4 should probably have a statement that it be removed
  by the RFC-Editor before publication as RFC.

- This statement
        ::= { mib-2 8889 } -- TO BE ASSIGNED by IANA
  is NOT ALLOWED. One must do a
        ::= { mib-2 nnn } -- nnnn TO BE ASSIGNED by IANA

- The MODULE DESCRIPTION clause states:
    DESCRIPTION "The module defines management information specific to
                FCIP devices."
  So it is missing the mandatory COPYRIGHT statement. It should read:
    DESCRIPTION "The module defines management information specific to
                FCIP devices.

                Copyright (C) The Internet Society (2005).  This
                version of this MIB module is part of RFC xxxx; see
                the RFC itself for  full legal notices."

- The REVISION description says:
    DESCRIPTION
            "Initial version of the FCIP MIB module."
  It would be much better to say:
    DESCRIPTION
            "Initial version of the FCIP MIB module, published
            as RFC xxxx."

- The two Textual Conventions are named: FcDomainId and FcEntityMode.
  I would prefer them to be named fcipDomainId and FcipEntityMode
  so that we have a more consistent naming convention within the
  MIB module itself and less risk for future name clashes in other
  MIB modules.  I can see it is kind of consistent with the FcXxx
  TCs they import from FC-MGMT-MIB, but that fact also explains
  why there is a potential risk for future name clashes. Oh well,
  I guess this is what they have chosen. So...

- In the FcDomainId TC they talk about FC entity while they talk
  about FCIP entity in FcEntityMode TC. Is that intentional
  or just inconsistent?

- I see (in
  FcDomainIdOrZero ::= TEXTUAL-CONVENTION
    STATUS current
    DESCRIPTION
            "The Domain Id (of a FC swit
            has been assigned."
    SYNTAX  Integer32 (0..239)

  While the FcDomainId in this MIB document is:
    SYNTAX    OCTET STRING (SIZE(1))
  That is pretty inconsistent between the two MIB modules.
  This sort of proves my previous point about inconsistencies
  and/or name clashes right away.

- In the DESCRIPTION clause of the read-write object fcipDynIpConfType
  I would like to see a statement about expected persistency behaviour.
  In other words, what happens on a restart?

- On page 10 I see:
    REFERENCE
      "IETF IPS Working Group - draft-ietf-ips-fcovertcpip-12.txt"
  That makes that internet-draft normative (I think). Just so you know.

- I see:
  fcipEntityId  OBJECT-TYPE
    SYNTAX OCTET STRING (SIZE(8))
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION
      "The FCIP entity identifier."
    REFERENCE
      "IETF IPS Working Group - draft-ietf-ips-fcovertcpip-12.txt"
    ::= { fcipEntityInstanceEntry 1 }
  I think it would be good to add a few words to the description clause
  to explain what the format of such an FCIP entity identifier look like.
  In fact, maybe it should be a Textual Convention too.

- fcipEntityAddress
  The decription clasue should state that the format of this object is determined
  by the value of fcipEntityAddressType, as explained in the RFC4001 in the TC
  DESCRIPTION for the InetAddress TC.

  Same for fcipLinkLocalFcipEntityAddress and fcipLinkRemFcipEntityAddress
  maybe others?

- Description clause of fcipEntityStatus MUST describe which columns can
  or cannor be changed if the row in in active state.

  Same for fcipLinkStatus... maybe others

- I am finding various DESCRIPTION clauses pretty meager, for example
  fcipLinkCost. fcipLinkLocalFcipEntityMode

- I find it strange that fcipEntityId is of  SYNTAX OCTET STRING (SIZE(8))
  while fcipLinkRemFcipEntityId as a SYNTAX Unsigned32

- I cannot find any details of the persistency behaviour for fcipLinkTable !!??

  same for fcipStaticRouteTable... and may be others?

  same for read-write column in fcipDiscoveryDomainTable

- Table fcipLinkErrorsTable contains a lot of Counter32 columns.
  Each of the DESCRIPTION clauses is supposed to describe if there
  can be discontinuity situations, and if so, which timer is to
  be used to detect that.

- I think the Security COnsiderations section is weak.
  It lists sensitive objects, but it does not describe much about
  why they are sensitive and what kind of damage can happen if
  improperly changed.
  The security guidelines on www.ops.ietf.org  explains how it
  should be done in an acceptable manenr

- I do not see a IANA COnsiderations section, which is mandatory,
  and specifically so because a MIB OID needs to be assigned.

- $ idnits draft-ietf-ips-fcip-mib-07.txt
  idnits 1.58

  draft-ietf-ips-fcip-mib-07.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
 
- !! Bad reference -- !MISSING.]
  P031 L019: [RFC2012}  McCloghrie, K., "SNMPv2 MIB for the Transmission Control

  !! Missing Reference for citation: [RFC2012]
  P005 L019:    Objects relevant to TCP must be obtained from this group [RFC2012].

  That is cause by a accolade instead of a square bracket in the reference sect.

  Also... RFC2012 has now been obsolted by RFC4022. That is what happens if there
  are long periods between my comments and a ready for re-review.

- !! Missing Reference for citation: [FC-MGMT-MIB]
  P005 L036:    be a regular FC interface.  As stated in [FC-MGMT-MIB], a regular

  That reference is indeed missing. Or maybe it intends to point to this:

    [FCMGMT]    McCloghrie, K., "Fibre Channel Management MIB",
                , February 2003.

  Then the citation should be changed to 'FCMGMT]
  And the cirrent revivion of the fcmgmt-mib is revision 6 as in the RFC-Ed queue.
 
- A NORMATIVE reference is needed for every document from which an IMPORT is done.
  So that means we are missing normative references (and citations somehwere in
  the text) to:

    INET-ADDRESS-MIB ... RFC4022
   

Oh well....

Bert

Recording for the archive my comments to revision 5.
Now checking if they have been fixed.

Bert

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Sunday, November 07, 2004 17:17
To: Michael MacFaden
Cc: Keith McCloghrie (E-mail)
Subject: RE: [Ips] MIB Doctor review: ips-fcip-mib-5-reviewed.txt


OK, so it seems to me that if Keith can get the authors/WG to make the
changes that he listed in his email, that that seems to address Mike's
concerns... But... I looked at it (during my long flight....)

Let me note, that on page 25 you start with a
  - ******************************
line which cuases a syntax error on MIB compile.

After I fix that, I get from SMICNG:
  E: f(fcip.mi2), (260,27) Index item "fcipLinkIndex" must be
    defined with syntax that includes a range
  E: f(fcip.mi2), (414,17) Index item "fcipLinkIndex" must be
    defined with syntax that includes a range
  E: f(fcip.mi2), (619,27) Index item "fcipDiscoveryDomainIndex"
    must be defined with syntax that includes a range
  E: f(fcip.mi2), (673,27) Index item "fcipLinkIndex" must be
    defined with syntax that includes a range

Might as well fix that, and probably make sure that indexing does start at
1 as opposed to at zero!?

Some more (admin related) nits:

- the abstract is not suppoed to contain citations
- Sect 3.1... do we really want to reference MIB II or would it be better
  to reference the follow on MIB for TCP, namely RFC2012 or RFC2012bis
  I think that would make sense!

- I see several places with (quite some) ASN.1 comments in the mIB module.
  Why does that not go into DESCRIPTION clauses at appropriate places?

Other concerns I have:
- I find the DESCRIPTION clause ofr this TC very meager.
  Who assigns values, or how are they assigne?
  What is a "domain ID anyway?
  FcDomainId ::= TEXTUAL-CONVENTION
    STATUS    current
    DESCRIPTION    "The Domain ID of a FC entity."
    SYNTAX    OCTET STRING (SIZE(1))

- For TC FcEntityMode I wonder if E-type Port or B-type port is defined
  somewhere, and a ptr may be handy/useful

- For table fcipEntityInstanceTable I see not STorageType object nor do
  I see any stuff in a DESCRIPTION clause to talk about persistency
  behaviour !!??

- fcipEntityAddress
  According to RFC3291 (or its follow on) the DESCIPTION clause MUST
  specify which AddressType object controls the format.

  Also, I see not restrictions on the AddressType in the MODULE-COMPLIANCE,
  so that to me means a DNS name is allowd. In that case, the DESCRIPTION
  clause MUST include text about how/when the DNS name is resolved.

- For
  fcipEntityTcpConnPort  OBJECT-TYPE
    SYNTAX Unsigned32  (0..65535)
  I think you want to use TC InetPortNumber

- fcipEntityStatus DESCRIPTION clause states:
          request. fcipEntityTcpConnPort takes the default value
          zero(0) if no value is supplied at the time of row creation.
  So I would have expected a DEFVAL fo rthast object..


Keith... do I have to go on?
I had expected you as SNMP technical advisor to find/flag these things?

Other nits:
*** matchref -- match citations and references.
    Input file: draft-ietf-ips-fcip-mib-06.txt


!! Missing citation for Normative reference:
  P031 L017: [RFC1323]  Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for

!! Missing citation for Normative reference:
  P031 L020: [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black, "Definition

!! Missing citation for Normative reference:
  P030 L045: [RFC2571]  Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture

There are 7 instances of too long lines in the document,
-- the longest one being 5 characters in excess of 72.

Bert

Bert

> -----Original Message-----
> From: Michael MacFaden [mailto:mrm@kazeon.com]
> Sent: Friday, November 05, 2004 19:11
> To: Wijnen, Bert (Bert)
> Cc: Keith McCloghrie (E-mail)
> Subject: RE: [Ips] MIB Doctor review: ips-fcip-mib-5-reviewed.txt
>
>
> >Bert writes:
> > I would like to hear your reaction to Keiths response
>
> I agree with Keith (and appreciate the detail).
> If the document covers section 4, then consistent implementations of
> this mib module are more likely.
>
> Mike
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: Friday, November 05, 2004 8:50 AM
> > To: Michael MacFaden
> > Cc: Keith McCloghrie (E-mail)
> > Subject: FW: [Ips] MIB Doctor review: ips-fcip-mib-5-reviewed.txt
> >
>
> .....
>
> >
> >
> > Bottom line: a) the MIB needs to address the items listed in
> > section 4 of RFC 2863, b) I think it's OK for the document to
> > say that it is redundant for an fcipLink interface to appear
> > in the ifStackTable and thus it is not required, but it does
> > need to allow fcipLink's to be represented in the
> > ifStackTable and to say how.
> >
> > Keith.
> >
>