Subject: [imss] RE: imss WG Last Call: FC-SP MIB

From: [email-masked]
Date: Thu, 1 Nov 2007 13:10:12 -0400

The WG Last Call on this MIB has ended, but in addition to my
comments, I think it would be prudent to wait for Bert to finish
wading through this MIB before producing a revised version and
submitting it to the ADs/IESG.

Bert - do you have a timeframe for completing your review.

Thanks,
--David (imss WG chair)
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Black, David 
> Sent: Tuesday, October 09, 2007 8:18 PM
> To: [email-masked]'
> Cc: Black, David; 'Romascanu, Dan (Dan)'
> Subject: imss WG Last Call: FC-SP MIB
> Importance: High
> 
> This is to announce an imss WG Last Call on the following
> MIB draft:
> 
>             MIB for Fibre-Channel Security Protocols (FC-SP)
>                    draft-ietf-imss-fc-fcsp-mib-00.txt
> 
> This WG Last Call will run through 12 midnight Eastern Time on
> Friday, October 26, 2007 (your WG chair hopes to deal with
> Last Call results during the week of October 29th and hopes
> that any revisions can be completed prior to the November
> 19th Internet Draft submission cutoff for the Vancouver meeting).
> 
> Technical comments *must* be sent to the imss mailing list.
> Editorial comments may be sent directly to the draft editor
> (but please cc: me):
> 
> 		Keith McCloghrie [[email-masked]]
> 
> In order to try to set a good example, I have completed my
> WG chair review of the MIB prior to announcing this Last Call.
> 
> I found two technical concerns:
> (1) The MIB defines precedence values for traffic selectors
> 	as opposed to implicitly presenting them in order of
> 	precedence.  I guess this is ok, but Section 4.7 should
> 	explain why this approach was chosen.
> (2) Section 4.9 defines rate control for Authentication
> 	failures on a per-fabric granularity.  That strikes
> 	me as overly coarse, and I wonder if per-SA would
> 	be a more appropriate/useful granularity.
> 
> I also found a number of editorial concerns:
> 
> Section 1, 2nd paragraph.  Remove the sentence starting
> with "This latest draft" or insert an instruction to the
> RFC Editor to remove it before publication as an RFC.
> 
> Section 3.1 - Delete "The" at the start of the first paragraph.
> 
> Should Section 3.5 and subsequent subsections of Section 3
> all be subsections of Section 3.4 Security?
> 
> Section 3.10 - "To provide better scaling, the Switch Connectivity
>    Objects are not Fabric-wide information such that they are
>    distributed only to where they are needed."
> 
> "information such that they are" -> information, but are"
> 
> Section 3.10 introduces "Active Zone Set" but does not explain
> what this term means.
> 
> T11FcSpPolicyNameType - the DESCRIPTION needs to explain the
> concept of "restricted" - how does a "restricted" entity
> differ from the corresponding unrestricted entity?
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 

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

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Fri, 2 Nov 2007 16:07:21 +0100

David,

Things are not going as I wanted. 
I was on vacation for a week, just returned this morning.

I have serious workload next week that I must give priority.
The week after I am at IEEE 802.1 meetings (with quite a bit
of MIB related work as well). So It seem it will be at least in
the last week of November that I can seriously get to it (I had
planned (in fact I started) to do so earlier). But it is
also possible that yet other high priority activities get in the 
way at that time. Can't elaborate now on that though.

I will not feel offended if you do not want to wait for that 
and instead look for another MIB Doctor for review.

Bert Wijnen  

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2007 6:10 PM
> To: [email-masked]; WIJNEN, Bert (Bert)
> Cc: [email-masked]
> Subject: RE: imss WG Last Call: FC-SP MIB
> 
> comments, I think it would be prudent to wait for Bert to 
> finish wading through this MIB before producing a revised 
> version and submitting it to the ADs/IESG.
> 
> > This is to announce an imss WG Last Call on the following MIB draft:
> > 
> > This WG Last Call will run through 12 midnight Eastern Time 
> on Friday, 
> > October 26, 2007 (your WG chair hopes to deal with Last 
> Call results 
> > during the week of October 29th and hopes that any revisions can be 
> > completed prior to the November 19th Internet Draft 
> submission cutoff 
> > for the Vancouver meeting).
> > 
> > Editorial comments may be sent directly to the draft editor (but 
> > please cc: me):
> > 
> > In order to try to set a good example, I have completed my WG chair 
> > review of the MIB prior to announcing this Last Call.
> > 
> > Section 1, 2nd paragraph.  Remove the sentence starting with "This 
> > latest draft" or insert an instruction to the RFC Editor to 
> remove it 
> > before publication as an RFC.
> > 
> > Should Section 3.5 and subsequent subsections of Section 3 all be 
> > subsections of Section 3.4 Security?
> > 
> > Section 3.10 introduces "Active Zone Set" but does not explain what 
> > this term means.
> > 
> > T11FcSpPolicyNameType - the DESCRIPTION needs to explain 
> the concept 
> > of "restricted" - how does a "restricted" entity differ from the 
> > corresponding unrestricted entity?
> > 
> > Thanks,
> > --David

---

From: [email-masked]
Date: Fri, 16 Nov 2007 11:57:13 -0500

Bert,

If there's a reasonable possibility that you'll be able to
complete this review by the end of the year, I'd prefer to
wait for that review rather than go looking for another
MIB doctor (which could take even longer).  Is that a
reasonable possibility?

Thanks,
--David

> From: WIJNEN, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, November 02, 2007 11:07 AM
> To: Black, David; [email-masked]
> with "This

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Fri, 16 Nov 2007 19:57:34 +0100

Yes, I can commit to complete this before the end of the year.

Bert Wijnen  

> Sent: Friday, November 16, 2007 11:57 AM
> To: WIJNEN, Bert (Bert); [email-masked]
> wait for that review rather than go looking for another MIB 
> doctor (which could take even longer).  Is that a reasonable 
> possibility?
> 
> Thanks,
> --David
> > The week after I am at IEEE 802.1 meetings (with quite a bit of MIB 
> > related work as well). So It seem it will be at least in 
> the last week 
> > of November that I can seriously get to it (I had planned 
> (in fact I 
> > started) to do so earlier). But it is also possible that yet other 
> > high priority activities get in the way at that time. Can't 
> elaborate 
> > now on that though.
> > 
> > I will not feel offended if you do not want to wait for that and 
> > instead look for another MIB Doctor for review.
> > 
> > Bert Wijnen
> > 
> > > David L. Black, Distinguished Engineer EMC Corporation, 176 South 
> > > St., Hopkinton, MA  01748
> > > > David L. Black, Senior Technologist EMC Corporation, 176 South 
> > > > St., Hopkinton, MA  01748

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Mon, 26 Nov 2007 15:46:51 +0100

1. T11-FC-SP-TC-MIB

   C:\bwijnen\smicng\imss>smicng T11-FC-SP-TC-MIB.inc
   W: f(T11-FC-SP-TC-MIB), (40,15) The first revision should match
      the last update for MODULE-IDENTITY t11FcTcMIB
   *** 0 errors and 1 warning in parsing

   C:\bwijnen\smicng\imss>smilint ./T11-FC-SP-TC-MIB
   ./T11-FC-SP-TC-MIB:44: revision for last update is missing

   I think it would be good to to get the REVISION and LAST-UPDATED
   timestamps in sync. No big deal though.

2. T11-FC-SP-ZONING-MIB

   C:\bwijnen\smicng\imss>smicng T11-FC-SP-ZONING-MIB.inc
   W: f(T11-FC-SP-ZONING-MIB), (404,20) Variable "ifIndex" in
notification
      "t11FcSpZsFabricJoinSuccessNotify" is an index for a table
   W: f(T11-FC-SP-ZONING-MIB), (420,20) Variable "ifIndex" in
notification
      "t11FcSpZsFabricJoinFailureNotify" is an index for a table

   *** 0 errors and 2 warnings in parsing

   C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-ZONING-MIB
   .. OK

   I think this is OK in this situation.

3. T11-FC-SP-SA-MIB

   C:\bwijnen\smicng\imss>smicng T11-FC-SP-SA-MIB.inc
   E: f(T11-FC-SP-SA-MIB), (1781,36) Item "t11FcSpSaTSelSpiDirection" in
      sequence "T11FcSpSaTSelSpiEntry" has conflicting syntax specified

   bw: caused by INTEGER and T11FcSaDirection TC (which has underlying
       SYNTAX of INTEGER (enumerated). So I am not sure it is a real
       error. At the other hand, the/a fix is easy, namely change

       T11FcSpSaTSelSpiEntry ::= SEQUENCE {
          t11FcSpSaTSelSpiInboundSpi     T11FcSpiIndex,
          t11FcSpSaTSelSpiTrafSelIndex   Unsigned32,
          t11FcSpSaTSelSpiDirection      INTEGER,
          t11FcSpSaTSelSpiTrafSelPtr     Unsigned32
       }

       into:

       T11FcSpSaTSelSpiEntry ::= SEQUENCE {
          t11FcSpSaTSelSpiInboundSpi     T11FcSpiIndex,
          t11FcSpSaTSelSpiTrafSelIndex   Unsigned32,
          t11FcSpSaTSelSpiDirection      T11FcSaDirection,
          t11FcSpSaTSelSpiTrafSelPtr     Unsigned32
       }

       It would also make it more consistent with other places where you
       have used T11FcSaDirection TC.

   E: f(T11-FC-SP-SA-MIB), (512,14) Index item "t11FcSpSaPropIndex" must
      be defined with syntax that includes a range

   bw: I tend to agree with that. For example I wonder of zero is a
valid
       index value. If it is, then we better explicitly include it (and
add 
       text to the DESCRIPTION clause what that means). If it is not,
       then we better exclude it.

   E: f(T11-FC-SP-SA-MIB), (684,14) Index item
"t11FcSpSaTSelPropListIndex"
      must be defined with syntax that includes a range
   E: f(T11-FC-SP-SA-MIB), (684,42) Index item "t11FcSpSaTSelPropIndex"
      must be defined with syntax that includes a range

   bw: same story for those above 2 error messages.

   E: f(T11-FC-SP-SA-MIB), (928,14) Index item "t11FcSpSaTransListIndex"
      must be defined with syntax that includes a range
   E: f(T11-FC-SP-SA-MIB), (928,39) Index item "t11FcSpSaTransIndex"
must
      be defined with syntax that includes a range

   bw: same story for those above 2 error messages.

   E: f(T11-FC-SP-SA-MIB), (1069,42) Index item
"t11FcSpSaTSelDrByPrecedence"
      must be defined with syntax that includes a range

   bw: would be easy to fix in TC module:

   T11FcSpPrecedence ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS       current
      DESCRIPTION
           "The precedence of a Traffic Selector.  If a frame
           matches with two or more Traffic Selectors, then the match
           which takes precedence is the one with the Traffic Selector
           having the numerically smallest precedence value.  Note that
           precedence values are not necessarily contiguous."
      SYNTAX   Unsigned32  -- the default range: (0..4294967295)

    Why not just specify that range. It makes sense (I guess) that
    a value of zero in this case is valid, and so would also be
    a valid/acceptable INDEX value. We betetr make that explicit
    (or so I think).

   E: f(T11-FC-SP-SA-MIB), (1259,38) Index item
"t11FcSpSaPairInboundSpi"
      must be defined with syntax that includes a range

   bw: same as above.

   E: f(T11-FC-SP-SA-MIB), (1457,38) Index item
"t11FcSpSaTSelNegInIndex"
      must be defined with syntax that includes a range

   bw: SO is zero a valid/acceptable index? If so we better explicitly
       include that. If not, then we must exclude it.

   E: f(T11-FC-SP-SA-MIB), (1624,38) Index item
"t11FcSpSaTSelNegOutPrecedence"
      must be defined with syntax that includes a range

   bw: see comment above on the use of T11FcSpPrecedence TC

   E: f(T11-FC-SP-SA-MIB), (1774,14) Index item
"t11FcSpSaTSelSpiInboundSpi"
      must be defined with syntax that includes a range

   bw: see above

   E: f(T11-FC-SP-SA-MIB), (1774,42) Index item
"t11FcSpSaTSelSpiTrafSelIndex"
      must be defined with syntax that includes a range

   bw: Is zero a valid/acceptable value. It seems to me that in this
case
       we prefer NOT to allow for zero. So make that explicit.

   W: f(T11-FC-SP-SA-MIB), (1257,32) Row "t11FcSpSaPairEntry" does not
have
      a consistent indexing scheme - index items from current table must
come
      after index items from other tables
   W: f(T11-FC-SP-SA-MIB), (1456,32) Row "t11FcSpSaTSelNegInEntry" does
not
      have a consistent indexing scheme - cannot specify an index item
from
      additional "base row" t11FcSpSaPairEntry, since can have only one
      "base row" which is t11FcSpSaIfEntry
   W: f(T11-FC-SP-SA-MIB), (1623,32) Row "t11FcSpSaTSelNegOutEntry" does
not
      have a consistent indexing scheme - cannot specify an index item
from
      additional "base row" t11FcSpSaPairEntry, since can have only one
      "base row" which is t11FcSpSaIfEntry
   W: f(T11-FC-SP-SA-MIB), (1772,32) Row "t11FcSpSaTSelSpiEntry" does
not
      have a consistent indexing scheme - cannot specify an index item
      from additional "base row" t11FcSpSaPairEntry, since can have only
      one "base row" which is t11FcSpSaIfEntry

   The "non-consistent indexing scheme" issue is possibly just a
warning.
   In these cases I always ask the author: Pls check that what you did
   is what you intended. If so, then I think the above 4 are fine.
   I must say that the indexing certainly is not immediately obvious.
   I will need to go look in detail to convince myself.

   *** 12 errors and 4 warnings in parsing

   C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-ZONING-MIB
   .. OK

4. T11-FC-SP-POLICY-MIB

   C:\bwijnen\smicng\imss>smicng T11-FC-SP-POLICY-MIB.inc
   E: f(T11-FC-SP-POLICY-MIB), (1528,14) Index item
      "t11FcSpPoAuthProtIdentifier" must be defined with syntax
      that includes a range

   bw: Assuming that http://www.t11.org/ftp/t11/pub/fc/sp/06-157v3.pdf 
       is the proper document to look at, for table 11.
       From that table one could conclude that value zero is part
       of the "all others", but at the other hand, I would have put
       value zero as reserved at the top of the table if value
       zero is valid. 
   
   So... is it valid? In any event, I would make the range (0-4billion)
   or 1-4billion) explicit I think.

   E: f(T11-FC-SP-POLICY-MIB), (3443,14) Index item
      "t11FcSpPoNaAuthProtIdentifier" must be defined with syntax
      that includes a range

   bw: same story.

   *** 2 errors and 0 warnings in parsing

   C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-POLICY-MIB
   .. OK

5. T11-FC-SP-CERTS-MIB

   C:\bwijnen\smicng\imss>smicng T11-FC-SP-CERTS-MIB.inc
   E: f(T11-FC-SP-CERTS-MIB), (90,38) Index item "t11FcSpCertIndex"
      must be defined with syntax that includes a range

   bw: seems (to me) that we would want to exlude zero as an
       acceptable value.

   *** 1 error and 0 warnings in parsing

   C:\bwijnen\smicng\imss>smilint -l 6 -m -s ./T11-FC-SP-CERTS-MIB
   .. OK

6. T11-FC-SP-AUTHENTICATION-MIB

   C:\bwijnen\smicng\imss>smicng T11-FC-SP-AUTHENTICATION-MIB.inc
   Successful parsing

   C:\bwijnen\smicng\imss>smilint -l 6 -m -s
./T11-FC-SP-AUTHENTICATION-MIB
   .. OK

Bert