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

[Keith McCloghrie <[e-mail]>]

Dan,

As you have probably seen, draft-ietf-imss-fc-rtm-mib-04.txt is now
available.

In addition, please note Spencer made four comments, and that the second
and third are also applicable to draft-ietf-imss-fc-fspf-mib-02.txt,
for which the exact same edits for those two comments would fix the
issues.  Do you want me to generate a draft-ietf-imss-fc-fspf-mib-03.txt,
or perhaps there's a GenART review for draft-ietf-imss-fc-fspf-mib-02.txt
and we should wait for that ??

Keith.
 
> Keith,
> 
> It would be better to release version 04, if you can do it in the next
> few days. I would like to place this document on the agenda of the 5/11
> meeting. 
> 
> Thanks and Regards,
> 
> Dan
> 
> > -----Original Message-----
> > From: Keith McCloghrie [mailto:[e-mail]] 
> > Sent: Thursday, April 27, 2006 11:38 PM
> > To: Romascanu, Dan (Dan)
> > Cc: Keith McCloghrie; General Area Review Team; 
> > [e-mail]; [e-mail]; [e-mail]; Romascanu, 
> > Dan (Dan); [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: Gen-ART review of draft-ietf-imss-fc-rtm-mib-03.txt
> > 
> > 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