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

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

Hi, Keith,

The changes you propose would would for me.

Thanks especially for your proposed change to 5.3. I don't think a lot of 
description is required, just enough to clearly identify what's being 
discussed.

Spencer


> 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