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

["Romascanu, Dan \(Dan\)" <[e-mail]>]

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