Subject: RE: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB):

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Mon, 3 Dec 2007 23:24:02 +0100

Inline

Bert Wijnen  

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]] 
> Sent: Thursday, November 29, 2007 10:05 AM
> To: WIJNEN, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB):
> 
> Bert
> 
> Thanks for your first (of many, I'm sure!!) sets of comments 
> on the document.
> 
> > Here are my comments/questions on the T11-FC-SP-TC-MIB module
> >
> > 1. I find it somewhat weird to see:
> > 
> >      t11FcTcMIB  MODULE-IDENTITY
> >         LAST-UPDATED  "200708130000Z"
> >         ORGANIZATION  "For the initial versions, T11.
> >                        For later versions, the IETF's IMSS Working 
> > Group."
> > 
> >    The one version that gets formally published is the one in the
> >    upcoming RFC. At that time there are basically no 
> "initial" versions
> >    other than the one in the RFC. 
> 
> First, I feel it's valuable to acknowledge T11 in the MIB 
> module itself, not just in the RFC, because: a) they deserve 
> the acknowledgement, and b) it indicates that this MIB 
> benefitted from their Fibre Channel expertise.
> 
> Second, RFC 2578 says:
> 
>    The ORGANIZATION clause, which must be present, contains a textual
>    description of the organization under whose auspices this 
> information
>    module was developed.
> 
> and there were two such organizations: an initial one and a later one.
> So, we could change the word "version" to something else if 
> you like, but otherwise, I think it's kosher.
> 
> Would you prefer it to say something like:
> 
>           ORGANIZATION  "This MIB module was a coordinated development
>                          of two organizations: T11 began the 
> development
>                          and the IETF's IMSS Working Group 
> finished it."
> 

Sounds fine to me.

> > 2. looking at T11FcSpPolicyHashFormat and T11FcSpPolicyHashValue I 
> > wonder
> >    if/how often the TCS will need to be updated? And when 
> that is done,
> >     a. do we then want to create a new RFC or
> >     b. should this become an iana  maintained module? 
>  
> The definition is intentionally designed such that the 
> answers to your questions are: never, no, and no.  That is, 
> the TC provides a REFERENCE to the location in FC-SP where 
> values are defined, the syntax of both objects is based on 
> the field sizes, not on assigned values, and the DESCRIPTION 
> lists the "first two" assignments, but only as an FYI, not as 
> the definitive specification.  In other words, the TCs are 
> written so that they do not have to be updated when new 
> assignments are made, which avoids the work of creating a new 
> RFC and avoids creating extra work for IANA.
> 
> >    If we need to create a new MIB module ourselves (option a), then
> >    we could be more specific this time by making the SYNTAX for
> >    T11FcSpPolicyHashValue as follows:
> > 
> >        SYNTAX        OCTET STRING (SIZE (20 | 32))
> > 
> >    because there are no other lengths possible given the currently
> >    specified/valid formats.
>  
> See above -- the syantax is based on the field size, not on 
> the currently assigned values.  That is, it is based on Table 
> 106, not on Table 107, of FC-SP (06-157v3)
> 

OK

> > 3. I am not sure if (how) it is wise to merge values from
> >    3 different tables in the FC-SP spec (tables 17/18, 48 and 52)
> >    into one Textual Convention for the code and one for CodeExp.
> >  
> >        T11FcSpAuthRejectReasonCode
> >        T11FcSpAuthRejReasonCodeExp
> > 
> >    In some cases, not all values are valid, are they? The set of
> >    reasons and Reason Explanations is different for the 3
> >    types of messages listed in the DESCRIPTION clause.
> > 
> >    Maybe it is OK, but I am somewhat worried.
> 
> If they were three unrelated values, then I would share your concern. 
> However, all three types are potential values of a reason 
> code (or reason code explanation).  In effect, the merge here 
> is the same as woudl be done by using a C-language "union" 
> construct, but the
> SMIv2 doesn't have one.  The merge is possible in this case 
> because the combined set of potential values can all be 
> included uniquely by assigning a unique named-number 
> enumeration for each one.
>

Thanks for the explanation. If the WG is OK with that (which I guess
is the ase cuase no concern was raised in WG LC), then fine.
 
> > 4. T11FcSpPolicyNameType
> >    I find it very unfriendly that Internationalized names are not
> >    defined/allowed. But I do see that the base spec [FC-SP] does
> >    not allow it, so I guess we can only model the spec that T11
> >    has approved (or will approve).
> 
> Perhaps, Claudio and David can take this comment back to T11 
> for consideration in FC-SP2.
>

I think that would be good
 
> > 5. Personal and subjective preference: I would rename
> > 
> >      T11FcSpAlphaNumNameOrNull
> > 
> >    into
> > 
> >      T11FcSpAlphaNumNameOrNone
> > 
> >    The "Null" often makes people think of 0 (zero).
>  
> I checked existing RFCs, and I found one xxOrNull and four 
> xxOrNone TCs, two of which (VlanIdOrNone and 
> VlanIdOrAnyOrNone) are integer-valued with "None" 
> representing zero !!  So, the precedent is not that clear 
> (except for the one you defined yourself:-).  Perhaps the 
> greatest clarity would be:  T11FcSpAlphaNumNameOrAbsent ??
>

I can live with Null. Absent would be somewhat better to my
subjective preference; so would None. Up to you.
 
> > 6. As reported by the SYNTAX checkers, I would change the underlying
> >    SYNTAX for T11FcSpiIndex and T11FcSpPrecedence to be
> > 
> >     SYNTAX   Unsigned32 (0..4294967295)
> > 
> >    instead of:
> > 
> >     SYNTAX   Unsigned32  -- the default range: (0..4294967295)
> 
> I did change them, but please note that RFC 2578 defines it as:
> 
>   Unsigned32 ::=
>       [APPLICATION 2]
>           IMPLICIT INTEGER (0..4294967295)
> 
> so the change is unquestionably redundant.
> 

Thanks for the change.
I like it to see an explicit statement that zero is valid in the
index.

> > 7. I wonder if it would be good (I think it would be) to add a
> >    REFERENCE clause to each of the Encryption and Authentication
> >    algorithms specified by the OBKECT-IDENTITIES.
> 
> It will be somewhat repetitious because all of the ENCR_xxx 
> are in Table 70, and all of the AUTH_xxx are in Table 71, but 
> if you're concerned that the macros could be extracted and 
> displayed individually rather than as part of the MIB, then 
> yes, there is a circumstance where it would be advantageous.
> 

That is what the REFERENCE clause is intended for I think.

Bert
> Thanks,
> Keith.

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

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Mon, 3 Dec 2007 23:53:09 +0100

New MIB modules pass the SYNTAX Check nearly clean.

Only one warning:
   ./T11-FC-SP-TC-MIB:327: warning: type `T11FcSpiIndex' has no format
specification

Bert Wijnen  

> Sent: Wednesday, November 28, 2007 10:34 AM
> To: WIJNEN, Bert (Bert)
> Cc: Keith McCloghrie; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [imss] imss WG Last Call: FC-SP MIB
> 
> 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
> > 
> > > Sent: Tuesday, November 27, 2007 3:00 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; WIJNEN, Bert (Bert); [email-masked]; 
> > > [email-masked]
> > > 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
> > > > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > > > [email-masked]        Mobile: +1 (978) 394-7754
> > > > ----------------------------------------------------
> > > > 
> > > > > Sent: Monday, November 26, 2007 12:21 PM
> > > > > To: [email-masked]
> > > > > Cc: Keith McCloghrie; Black, David; [email-masked]; 
> > > > > [email-masked]
> > > > > 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
> > > > > > > > 
> > > > > > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > > > > > Sent: Wednesday, October 10, 2007 2:18 AM
> > > > > > > > > To: [email-masked]
> > > > > > > > > Cc: [email-masked]; [email-masked]
> > > > > > > > > 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 [[email-masked]]
> > > > > > > > > 
> > > > > > > > > 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
> > > > > > > > > [email-masked]        Mobile: +1 (978) 394-7754
> > > > > > > > > ----------------------------------------------------
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >