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

["WIJNEN, Bert \(Bert\)" <[e-mail]>]

I am starting to take a look at this document.
Will take a while. It has 249 pages and 6 MIB modules.

One thing I do see that may need some action is the
fact that this document has normative dependencies 
on these 2 documents:

[IPSP-IKE-ACTION]
     Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec
     Security Policy IKE Action MIB", draft-ietf-ipsp-ikeaction-mib-
     nn.txt, work-in-progress, 19 October 2006.

[IPSP-IPSEC-ACTION]
     Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec
     Security Policy IPsec Action MIB", draft-ietf-ipsp-ipsecaction-mib-
     nn.txt, work-in-progress, 19 October 2006.


However, I do not see that any IMPORT is done for those 2 IPSP MIB
modules,
so maybe the dependency is not really normative? I will find out when
I read the whole FC-SP MIB document. Sofar I did notice:

- 4.8.6.  The T11-FC-SP-CERTS-MIB Module

   This MIB module specifies extensions to IPSP MIBs [IPSP-IPSEC-ACTION]
   and [IPSP-IKE-ACTION] which are specific to Fibre Channel.  In
   particular, it specifies one table, t11FcSpCertsTable, with a row per
   certificate indicating how that certificate is being used, and
   containing the "name" of the certificate.  This "name" can be used to
   obtain information, which is independent of FC-SP, about the
   certificate from the ipsaCredentialTable (and from the
   ipsaCredentialSegmentTable if the certificate is longer than 1024
   bytes).

- In the T11-FC-SP-CERTS-MIB (page 230/231:

           Since FC-SP leverages a subset of IPsec and IKEv2 (see RFC
           4595), a subset of the management information defined for
           the use of certificates with IPsec/IKEv2 is also applicable
           to FC-SP.  Thus, this MIB module leverages RFC wwww and
           RFC xxxx for the management of certificates, CAs and CRLs.
   -- RFC Editor: replace wwww with actual RFC number for
   -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC number for
   -- [IPSP-IKE-ACTION] & remove this note

           Specifically, the information defined in this MIB module
           consists of a pointer into the IPsec/IKEv2 MIB modules,
           plus minimal additional item(s) of information which are
           considered to be important in a Fibre Channel environment.

So it does sound normative. So I have a warning:

I have been reviewing those 2 IPSP documents a few times over the last
(mmmm probably) 2-3 or 2-4 years, and I must warn you that the cycle
times on
those documents are EXTREMELY slow. The current revisions are:

   draft-ietf-ipsp-ikeaction-mib-02.txt
   draft-ietf-ipsp-ipsecaction-mib-02.txt

which showed up as I-D on 10 Nov 2006, and both are still in Revised ID 
needed. Those MIB documents are also pretty complex, and so if/when a
new revision will eventually show up (if at all), then whoever needs to
re-review will need a serious block of time to actually do so. 
My personal experience is pretty bad/sad with those 2 documents, and
I must admit that I am completely de- or un-motivated at this point in 
time to re-review them a again if/when they do show up. But possibly 
Dan can convince me otherwise at that time.

Anyway, I just wanted the authors/editors/wg-chair and WG members to
be aware of this risky normative dependency.

Bert Wijnen  

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Wednesday, October 10, 2007 2:18 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: [imss] 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 [[e-mail]]
> 
> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
> 
> 
> _______________________________________________
> imss mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/imss
> 


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