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

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

Keith,

Thanks for the new version of draft-ietf-imss-fc-rtm-mib-04.txt. 

If you can generate draft-ietf-imss-fc-fspf-mib-03.txt in the next day
or so, this would be helpful, so that the two documents are at the same
level wrt. Spencer's comments. 

I would like to submit both docs for IESG discussion on the 11th. They
seem to be in good shape and were also reviewed by Bert. If GenART need
more time, I expect them to say so before the agenda shows up or DEFER
after it's in the air. 

Dan



 
 

> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]] 
> Sent: Monday, May 01, 2006 5:23 PM
> To: Romascanu, Dan (Dan)
> Cc: Keith McCloghrie; General Area Review Team; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: Gen-ART review of draft-ietf-imss-fc-rtm-mib-03.txt
> 
> 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