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

[Keith McCloghrie <[e-mail]>]

David,

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

Thanks for your review. 

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

This point has a bearing on two issues related to the use of Precedence
objects in an INDEX clause.  First, the question of whether an object
containing a Precedence value should be in an INDEX clause or not.
There are pros and cons:

pro: having a Precedence object in a table's INDEX clause allows the
     table's rows to be retrieved (by SNMP getNext/getBulk) in order
     of Precedence.
con: in a read-write/create table, objects which are not in the INDEX
     clause can be modified with a single PDU (SNMP setRequest), but an
     object in an INDEX clause can only be changed by deleting its row(s)
     and creating new row(s); this is not only two SNMP PDUs, but also
     there is a "gap", a time-period between the two, and for a Security
     MIB during such a gap, there is either too much or too little
     security, where "too little" is likely a security hole.

Note that the "con" applies only to read-write/create tables, and so
having t11FcSpSaTSelNegOutPrecedence in the INDEX clause of the
(read-only) t11FcSpSaTSelNegOutTable table is justified by the pro.

There are two other xxxPrecedence objects, t11FcSpSaTSelDrByPrecedence
and t11FcSpSaTSelPropPrecedence, which are both in read-write/create
tables, but one of them is in an INDEX clause and the other is not.
As far as I can remember, this difference was created inadvertently,
and I'm unable (at present) to think of any reason to justify the
inconsistency.

The second issue is that, when a Precedence object is used in an INDEX
clause, its value serves not only as an indication of precedence, but
also to distinguish one traffic selector from another.  In other words,
Precedence values in INDEX clauses in this MIB have two functions:
"Traffic Selector index" and "Precedence vaue".  So, the choice of
whether such an object is called a "Precedence" or a "TrafSelectorIndex"
is a terminology issue, not a structural issue.   Its use in the INDEX
clauses clearly indicates its purpose as an index, without it being
so named explicitly.  Thus, I think a greater increase in clarity is
achieved by naming it as xxxPrecedence.

So, I think the document should be changed in two ways:

1. t11FcSpSaTSelDrByPrecedence and t11FcSpSaTSelPropPrecedence should
be made consistent, either have both in their respective table's INDEX
clause, or, neither in their respective table's INDEX clause.  Further,
I'll make a suggestion based on my expectation of the likely usage of
this MIB; specifically, that the majority of the expected usage of this
MIB will be for read-only monitoring, with 
its capability for read-write configuration rarely implemented, and
even more rarely used.  Thus, I recommend that we optimize for reading,
not for writing.  Thus, I recommend we combine the semantics of
t11FcSpSaTSelPropPrecedence and t11FcSpSaTSelPropIndex with the former
taking the latter's place in the INDESX clause of the
t11FcSpSaTSelPropTable table.

2. that I add words (a subset of the above) to section 4.7 so as to
provide an explanation of the use of Precedence values in INDEX clauses.

> (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 think the question here is whether it's likely that authentication
failures will occur on many SA's at the same time -- if it is likely,
then per-Fabric rate control allows for plenty of notifications in
isolated cases without getting overloaded when many SA's have the
problem.  But, if there's no correlation between occurrences on
different SA's, then the odds of many SA's having the problem at the
same time is presumably negligible, and I agree that per-SA would be
better.

(Aside: MIB objects which are powerful enough to slow down the rate of
Authentication failures is, unfortunately, wishful thinking :-).

> I also found a number of editorial concerns:
 
I'll make all of your editorial suggestions.

Keith.


> 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