List Info

Thread: imss WG Last Call: FC-SP MIB




imss WG Last Call: FC-SP MIB
country flaguser name
United States
2007-10-09 19:17:33
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 [kzmcisco.com]

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
black_davidemc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------



_______________________________________________
imss mailing list
imssietf.org
https://w
ww1.ietf.org/mailman/listinfo/imss

RE: imss WG Last Call: FC-SP MIB
country flaguser name
United States
2007-10-15 04:58:52
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: Black_Davidemc.com [mailto:Black_Davidemc.com]

> Sent: Wednesday, October 10, 2007 2:18 AM
> To: imssietf.org
> Cc: dromascaavaya.com; Black_Davidemc.com
> 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 [kzmcisco.com]
> 
> 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
> black_davidemc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
> 
> _______________________________________________
> imss mailing list
> imssietf.org
> https://w
ww1.ietf.org/mailman/listinfo/imss
> 


_______________________________________________
imss mailing list
imssietf.org
https://w
ww1.ietf.org/mailman/listinfo/imss

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )