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

[Keith McCloghrie <[e-mail]>]

Dan,

The ID-State-Tracker says that this I-D is in the "Waiting for Writeup"
state, and thus the state diagram says that after your writeup and
"Go-Ahead", it will enter the "IESG evaluation" state.

So, do you want me to make the changes (outlined below) now and submit an
updated draft-ietf-imss-fc-rtm-mib-04.txt, or wait until later ??

Thanks,
Keith.
 
> 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