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

[Keith McCloghrie <[e-mail]>]

Hi Bert,
 
> I am starting to take a look at this document.

Thanks.

> Will take a while. It has 249 pages and 6 MIB modules.

Understood, but the hope is that it will take less time/effort than
the cumulative time/effort of reviewing 6 separate documents.

> 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 agree that such a "dependency" is a little risky, because I too
submitted some comments on those MIBs.  The reason that I'm using
quotes around "dependency" is because it is not the definitions in this
MIB which depend on any definitions in those MIBs, but rather the
explanation of why this MIB has the set of (certificate-related)
objects that it does.  Without such explanations, the definitions in
this MIB would appear incomplete, and it seems to me that making it
complete requires either:

1. the reference to the IPSP MIB modules that it currently has, or
2. definition of new MIB objects which duplicate/overlap with the IPSP
   MIB modules.

Given that the IPSP MIB modules are still expected to get approved (in the
future), then I'd say #2 is at least undesirable, and probably unacceptable.

So, if you can provide guidance on how to reference the IPSP MIB modules
in a way which avoids creating normative dependencies, then please do.

Keith.


> 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
> 


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