[Gen-art] Gen-ART review of draft-ietf-imss-fc-rtm-mib-04.txt

["Spencer Dawkins" <[e-mail]>]

Version 04 addresses all the comments I had in my review of 03. From my 
perspective, ready for publication as a Proposed Standard.

Thanks,

Spencer


>I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Summary: This document is almost ready for publication as a Proposed 
> Standard. I do have a question on Section 5.3, listed below.
>
> I also identified two editorial comments (not part of the Gen-ART review 
> for Brian). I hope this is useful.
>
> Thanks,
>
> 1.  Introduction
>
>   This memo defines a portion of the Management Information Base (MIB)
>   for use with network management protocols in the Internet community.
>   In particular, it describes managed objects for information related
>   to the Fibre Channel network's Routing Table for routing within a
>   Fabric.  Managed objects specific to particular routing protocols,
>   such as FSPF, are not specified in this MIB module.
>
> Spencer (NIT): FSPF is not exanded until later in the document (and should 
> have the reference to [FC-SW-4] that doesn't appear until Section 4). 
> Suggest "... such as Fabric Shortest Path First (FSPF) protocol [FC-SW-4], 
> ..." as replacement text.
>
> 5.3.  Fabric Index
>
>   The latest standard for an interconnecting Fabric containing multiple
>   Fabric Switch elements is [FC-SW-4] (which replaces the previous
>   revision [FC-SW-3]).  [FC-SW-4] specifies the operation of both a
>   single Fabric in a physical infrastructure, as well as the support of
>   multiple Virtual Fabrics operating within one (or more) physical
>   infrastructures.  Whether operating on a physical Fabric (i.e.,
>   without Virtual Fabrics) or within a Virtual Fabric, the operation of
>   FSPF within a Fabric is identical.  Therefore, this MIB defines all
>   Fabric-related information in tables which are INDEX-ed by an
>   arbitrary integer, named a "Fabric Index", the syntax of which is
>   IMPORTed from the T11-TC-MIB.  When a device is connected to a single
>   physical Fabric, without use of any virtual Fabrics, the value of
>   this Fabric Index will always be 1.  In an environment of multiple
>   virtual and/or physical Fabrics, this index provides a means to
>   distinguish one Fabric from another.
>
> Spencer: I can guess what a Virtual Fabric is, but I'm guessing and the 
> term hasn't been introduced yet, and there's no reference for it. Not a 
> critical problem, but since there's a nice overview in Section 3, maybe it 
> could have a sentence or two that introduces the concept, before it 
> appears in Section 5.3?
>
> 5.5.  The t11FcRouteTable's INDEX
>
>   Providing the same useful feature in the MIB in this document,
>   results in having an unusually large number (ten) of objects in the
>   t11FcRouteTable's INDEX clause.  However, all ten are either integers
>   or strings of length 0 or 3 octets.  Thus, the aggregate number of
>   sub-identifiers to be appended to an OBJECT-TYPE's OID when naming an
>   instance of an object in this table, is at most 22 sub-identifiers,
>   i.e., less than the *minimum* number to be appended for the
>   inetCidrRouteTable table.  In other words, while ten is an unusually
>   large number of objects in an INDEX clause, the resultant OIDs are
>   not unusually large.
>
> Spencer (more than a NIT): This paragraph is really tortured, until you 
> get to the last sentence, which seems all that's needed anyway (suggest 
> "While this useful feature results in an unusually large number (ten) of 
> objects in the t11FcRouteTable's INDEX clause, all ten are all ten are 
> either integers or strings of length 0 or 3 octets, so the resulting OIDs 
> are not unusually large."). But the reason I flagged this as "more than a 
> nit" was that "length 0 or 3 octets" was confusing - the point is, 
> "maximum length of 3 octets", isn't it? FC people are very aware of 
> FCAddressIdentifier structure, but no one else is, so "0 or 3 octets" is a 
> distraction, and the wordy paragraph just made it worse.
>
>
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art