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

[Keith McCloghrie <[e-mail]>]

Bert,

There's an updated version at:

  ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fcsp-mib-01.txt

I included (see the Change Log) updates based on several of the
emails in which you have already sent comments.  (I'll reply
to those emails in another message after this one, re: chnages that
I haven't made.)

I can't submit it as an updated I-D because new submissions are
suspended until after (the beginning? of) the IETF next week.  If
and when there are more changes that need to be made before the
submission, the submitted version will be different to this
version.  Thus, on page 1, I list the filename as:

    "(preliminary) draft-ietf-imss-fc-fcsp-mib-01.txt"

Keith.
 
> Sure. Pls go ahead and make the changes (I am used for
> you doing that pretty quick normally).
> 
> Bert Wijnen  
> 
> > -----Original Message-----
> > From: Keith McCloghrie [mailto:[e-mail]] 
> > Sent: Tuesday, November 27, 2007 3:00 AM
> > To: [e-mail]
> > Cc: [e-mail]; WIJNEN, Bert (Bert); [e-mail]; 
> > [e-mail]
> > Subject: Re: [imss] imss WG Last Call: FC-SP MIB
> > 
> > I agree.
> > 
> > Bert, that's one less MIB module for you to review, and there 
> > will be a number of editorial changes associated with 
> > removing T11-FC-SP-CERTS-MIB
> > -- is it worth me making those editorial changes before you 
> > continue your review, so that your review will check that I 
> > found all the ones in the parts that you haven't yet reviewed ?
> > 
> > Keith.
> >  
> > > Keith,
> > > 
> > > At this juncture, I favor approach 3:
> > > 
> > > > 3. Decide that the value of the one extra piece of information
> > > > (t11FcSpCertUsage) is not important enough for this MIB 
> > to have any
> > > sort
> > > > of dependency, and to decide not to define the 
> > T11-FC-SP-CERTS-MIB 
> > > > at the present time.
> > > 
> > > The extra information classifies a certificate as authentication 
> > > (entity has private key) vs. trust anchor (used to verify 
> > certificates 
> > > presented by other entities) and indicates which of the 
> > certificates 
> > > is the default.  Both of these are generic to certificates (i.e., 
> > > there's nothing special to FC that requires them), and 
> > hence arguably 
> > > belong in a certificate MIB somewhere as opposed to an FC MIB.  In 
> > > addition, I expect that the PKIX folks will probably have things to 
> > > say about how to do certificate usage "right" which won't have much 
> > > resemblance to what's in the MIB ;-).  Finally, starting 
> > work on trust 
> > > anchor management is on the PKIX agenda for Vancouver, and hence 
> > > staying out of that entire area is probably a prudent step towards 
> > > getting this MIB done in the nearer future.
> > > 
> > > Unless there's objection from anyone else on the mailing 
> > list, I think 
> > > we should just drop the CERTS-MIB.
> > > 
> > > Thanks,
> > > --David
> > > ----------------------------------------------------
> > > David L. Black, Distinguished Engineer EMC Corporation, 176 
> > South St., 
> > > Hopkinton, MA  01748
> > > [phone]             FAX: [phone]
> > > [e-mail]        Mobile: [phone]
> > > ----------------------------------------------------
> > > 
> > > > -----Original Message-----
> > > > From: Keith McCloghrie [mailto:[e-mail]]
> > > > Sent: Monday, November 26, 2007 12:21 PM
> > > > To: [e-mail]
> > > > Cc: Keith McCloghrie; Black, David; [e-mail]; 
> > > > [e-mail]
> > > > Subject: Re: [imss] imss WG Last Call: FC-SP MIB
> > > > 
> > > > 
> > > > Here are three alternatives for what we could do:
> > > > 
> > > > 1. Continue with the "dependency" as-is, but with the additional 
> > > > note on compliance that you suggest.
> > > > 
> > > > 2. Generalize the "dependency" so that it doesn't 
> > actually refer to 
> > > > [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but instead 
> > says something
> > > > like:
> > > > 
> > > >   Prior to the definition of the T11-FC-SP-CERTS-MIB, 
> > work had started
> > > >   in the IETF to specify a set of MIBs for managing 
> > IPsec/IKEv2.  The
> > > >   work was far enough along for the definition of FC-SP MIBs to
> > > >   leverage them as prior work, and to define a small extension of
> > > >   importance in the Fibre Channel environment.  However, 
> > the approval
> > > >   process for the IPsec/IKEv2 MIBs was delayed such that the 
> > > > definition
> > > >   of FC-SP MIBs caught-up with and was expected to 
> > overtake those for
> > > >   IPsec/IKEv2.  In order not to create a dependency, this document
> > > >   defines only the extension, and it does so in a generic 
> > manner so
> > > >   that the extension can be applied to any MIB for 
> > IPsec/IKEv2, either
> > > >   the completion of the previously-begun work or any 
> > alternative which
> > > >   might begin in the future.
> > > > 
> > > > I think a simple technical change is all that is required to make 
> > > > the definitions (in T11-FC-SP-CERTS-MIB) generic.  
> > Specifcially, I 
> > > > suggest we change syntax of t11FcSpCertPointer to be an OID, such 
> > > > that it can point to any table, i.e.,  not only into the 
> > > > ipsaCredentialTable, but also into any other MIB's table.
> > > > 
> > > > I think the above would allow the references to be Informational.
> > > > 
> > > > 3. Decide that the value of the one extra piece of information
> > > > (t11FcSpCertUsage) is not important enough for this MIB 
> > to have any 
> > > > sort of dependency, and to decide not to define the 
> > > > T11-FC-SP-CERTS-MIB at the present time.
> > > > 
> > > > Keith.
> > > > 
> > > >  
> > > > > W.r.t.
> > > > > > > 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.
> > > > > > 
> > > > > 
> > > > > yep... that sounds unacceptable. At the other hand, you 
> > may end up 
> > > > > having you approved I-D in the RFC-Editor queue for 
> > many years to 
> > > > > come waiting for the dependent IPSP MIB module 
> > documents to come 
> > > > > through (sorry... even though there was a message about 
> > the status 
> > > > > of IPSP MIB modules in August this year, I have seen no 
> > activity 
> > > > > since. I keep being very pessimistic about a reasonable 
> > result in 
> > > > > this space).
> > > > > 
> > > > > Maybe one of the ADs (possibly security ADs) can say something 
> > > > > about this issue or about the "dependency". As long as the docs 
> > > > > are listed as normative references, your doc will get 
> > block at the 
> > > > > RFC-Editor gates till those normative docs are ready to 
> > become an 
> > > > > RFC as well.
> > > > > 
> > > > > 
> > > > > > 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.
> > > > > > 
> > > > > 
> > > > > If I read your section 4.6, then it seems that the 
> > > > > ipsaCredentialTable, the ipsaCredentialSegmentTable and the 
> > > > > ipiaCredMngCRLTable are needed to manage CAs and CRLs.
> > > > > So that to me seems quite a dependency. Are you guys 
> > aware of how 
> > > > > your implementations will/might run without those tables? Have 
> > > > > they currently been implemented in prorpietary ways?
> > > > > Or have pre-RFC implementations been fielded? 
> > > > > 
> > > > > >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to 
> > > > > >state
> > > > > that those tables from IPSP MIB modules have to be supported in 
> > > > > order to let your MIB modules/security-features work, no?
> > > > > 
> > > > > Bert
> > > > > > 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