Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-07.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 20 Apr 2005 12:43:18 +0200

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", 
                <draft-ietf-ips-fcmgmt-mib-04.txt>, 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

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

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 20 Apr 2005 07:02:32 -0700 (PDT)

Hi Bert,

> more nits/admin-related.

All the nits/admin-related you found appear to be valid.  I can respond
to a few of the others.

> ...
 
I think it's intentional.

>   and/or name clashes right away.
 
While it seems like an "inconsistency", it originates in the Fibre
Channel specifications which seem to define a Domain_ID as an integer
value stored in a 1-byte field.  E.g., in a header for the FSPF (routing)
protocol, there is a 4-byte field defined as:

    Recipient Domain_ID: This field shall specify the Domain_ID of the
    neighbor Switch. If the neighbor Domain_ID is known, then the
    Recipient Domain_ID value shall be set to 000000h||Domain_ID. If
    the neighbor Domain_ID is unknown, then the Recipient Domain_ID
    value shall be FFFFFFFFh.

    Valid values for the Domain_ID are: 01h-EFh.

The usage of concatenation (000000h||Domain_ID) requires it to be an octet
string; having a *range* of values (01h-EFh) requires it to be an integer.
So, it's both !!  

>   That makes that internet-draft normative (I think). Just so you know.
 
This is now RFC 3821.

Keith.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 20 Apr 2005 17:42:44 +0200

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2005 16:03
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-07.txt
> 
> 
> Hi Bert,
> 
> All the nits/admin-related you found appear to be valid.

Good to see that we agree on that.

> I can respondto a few of the others.
> 
> > ...
> >
Mmm... then maybe some additional text in the DESCRIPTION clauses as
to what one and the other mean migth be helpfull to readers like 
myself.

> string; having a *range* of values (01h-EFh) requires it to 

Thanks for the explanation. In such a (intentional case), I would 
probably the rename the two TCs to FcIntegerDomainIdOrZero and
FcStringDomainId or some such. The FcDomainIdOrZero is alread
in RFC-Ed queue I believe, so changing that is not easy at this point.
Maybe rename the one in this doc to: FcDomainIdInOctetForm ?
And add some of the above explanantion to the DESCRIPTION clause?
Possibly also add another reference in the REFENCES section for
      REFERENCE "FC-SW, rev 3.3, 21 October 1997, section 3."
I did a quick hunting around on T11 web page, but could not find
it yet. I see under FC-SW a cover letter from 1997, but no document.
So a (better) ptr to the underlying spec might be very helpfull.

> >   That makes that internet-draft normative (I think). Just 
OK good, so it can easily be a normative reference then.
Would be good to update it with the RFC number.
I think that draft name is used at several places!

Bert

---

From: "Robert Snively" <[email-masked]>
Date: Wed, 20 Apr 2005 09:52:27 -0700

FC-SW, rev 3.3, Oct 1997 is obsolete and has been withdrawn.
It was never a standard at that level. It is available
from some standards documentation companies.  Contact me
if you are interested in that particular issue.

The present document is INCITS 384:2004, FC-SW-3.  By
copyright regulations of INCITS, it can be purchased on
the INCITS store for $18 per download or $60 for a paper
copy.  The next revision is FC-SW-4.  FC-SW-4 is presently
in development and is available in draft form on www.t11.org
under the "drafts" button.

Robert Snively, Chair INCITS TC T11

Brocade Communications Systems, Inc.
1745 Technology Drive
San Jose, CA 95110

+1 408 333 8135
[email-masked] 

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Wijnen, Bert (Bert)
> Sent: Wednesday, April 20, 2005 8:43 AM
> To: 'Keith McCloghrie'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-07.txt
> 
> 
> Inline
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 25 Apr 2005 11:19:52 +0200

> All IEEE 802 standards more than 12 months old are available for free 
> download on the Web via the "Get IEEE  802 program".
> 
Even better these days, on page http://standards.ieee.org/getieee802/
I now see:

   The Get IEEE 802R program makes IEEE 802R standards available at no charge
   in PDF format thanks to the sponsors listed to the right. This program
   grants public access to view and download current individual IEEE Local
   and Metropolitan Area Network standards at no charge.

    - New IEEE 802R standards are included in the program after they have
      been published in PDF for six months.

So already after 6 months!

Bert

---

From: [email-masked]
Date: Wed, 27 Apr 2005 12:27:06 -0600

Actually, the delay for Get IEEE 802 is six months after publication rather than 12.

Pat Thaler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Bernard Aboba
Sent: Sunday, 24 April, 2005 3:38 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-07.txt

>For most (if not all) IEEE documents that we need to look at during IETF
>review, the IEEE makes available the underlying document to the specific
>WG.

Indeed, we have a letter from the chair of IEEE 802 to this effect.

>Afterwards approval I am not sure if you can still freely get at it.

---

From: [email-masked]
Date: Wed, 27 Apr 2005 13:07:06 -0600

I'm happy we are able to currently make IEEE 802 documents freely available through the Get IEEE 802 (R) program. However, I don't think free availability of referenced documents to users of IETF standards is relevant from the point of view of IETF policy with regard to referencing documents.

At the time the first IEEE 802 related MIB work was done in IETF, Get IEEE 802 did not exist and the documents had to be bought (perhaps on paper even - how primitive).  The program is currently available through the sponsorship of IEEE 802, Wi-Fi Alliance and Cisco. As far as I know, within IEEE, only IEEE 802 standards have such a program. Continued availability of the program is subject to periodic review. 

Free document availability of references for reviewers is another matter.

Regards,
Pat Thaler
IEEE 802 Vice Chair