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

[Keith McCloghrie <[e-mail]>]

Spencer,
 
Thnaks for the comments.

> 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.
 
Thanks for catching that.

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

Adding [FC-SW-4] as a reference is easy, and I can also include an
extra paragraph to mention Virtual Fabrics at the end of section 3.
I hope it will be sufficient to do so by lifting some text out of
FC-SW-4, even though FC-SW-4's definitions are somewhat circular --
specifically, a Virtual Fabric is defined in terms of Virtual Switches,
which are defined in terms of a "Core Switch" for which the definition
includes Virtual Fabric :-(.

> 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. 
 
Yes, that will be an improvement (minus the typo that you caught in your
subsequent message).

Thanks,
Keith.

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