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

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

> -----Original Message-----
> From: Black, David 
> Sent: Tuesday, October 09, 2007 8:18 PM
> To: 'imss@ietf.org'
> 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 [kzm@cisco.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_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 

_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss