RE: REVIEW: draft-ietf-imss-fc-vf-mib-02.txt

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

Michael,

Thank you for your review. 

I am copying the mreview (MIB Doctors) list, because of your first
'minor' comment. The reason is that the authors seem to have followed in
the document the guidelines defined in RFC 4181 in what concerns
boilerplate and references, also listed at
http://www.ops.ietf.org/mib-boilerplate.html. The re-ordering of
sentences that you suggest would have triggered a MIB Doctor review
comment. 

Dan
 
 

> -----Original Message-----
> From: Michael A. Patton [mailto:MAP@MAP-NE.com] 
> Sent: Wednesday, June 07, 2006 8:55 AM
> To: gen-art@ietf.org
> Cc: scott.kipp@mcdata.com; gramkumar@stanfordalumni.org; 
> kzm@cisco.com; Romascanu, Dan (Dan)
> Subject: REVIEW: draft-ietf-imss-fc-vf-mib-02.txt
> 
> Attached is my review of the specified document, submitted as 
> part of the Gen-ART process.  For background on Gen-ART, 
> please see the FAQ at 
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> 
> Document Tag: draft-ietf-imss-fc-vf-mib-02.txt Document 
> Title: The Virtual Fabrics MIB Intended Status: Proposed 
> Standard Shepherding AD: Dan Romascanu Review Trigger: 
> Telechat 2006-06-08
> 
> To the Author/Editor: Please wait for direction from your 
> document shepherd or AD before posting a new version of the draft.
> 
> 
> ----------------  Begin review  ----------------
> 
> Summary: This draft is basically ready for publication, but 
> has nits that
> 	may need to be fixed before publication.
> 
> 
> Major concern
> -------------
> 
> It seems to me that section 5.2 is saying that this RFC (when 
> issued) will update some of the definitions in RFC4044.  If 
> that's really true, it should have an "Updates RFC4044" at 
> the top.  I must admit that I don't fully understand the 
> implications of the change described in 5.2, but I think it 
> calls for such a classification.
> 
> 
> Minor comments
> --------------
> 
> I had a couple of minor questions about the classification of 
> two of the references.  In both cases, I think I finally 
> convinced myself that having them only Informative was 
> probably OK, even though the main text that referred was 
> worded as if they were more Normative.
> But here's some discussion...
> 
> Is RFC3410 really only Informative, or should it be 
> Normative?  The first paragraph of section 2 seems to imply 
> that RFC3410 is needed for understanding.  However, that's 
> really just an indirect reference saying that 3410 lists 
> documents that are needed.  In fact only documents in section 
> 7.1 of 3410 are needed and they are all listed separately 
> under normative references in this draft and are all called 
> out in the other paragraph of section 2.  All of this causes 
> a little bit of confusion on what's really needed for the 
> background from section 2.  I think this could all be made 
> clearer by rewording section 2 (mostly to change the order 
> and thus the prominence of things), perhaps something like:
> 
>    This memo specifies a MIB module that is compliant to the
>    SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD
>    58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].  For
>    additional background, see the overview of the documents that
>    describe the current Internet-Standard Management Framework in
>    section 7 of RFC 3410 [RFC3410].
> 
>    Managed objects are accessed via a virtual information store,
>    termed the Management Information Base or MIB.  MIB objects are
>    generally accessed through the Simple Network Management
>    Protocol (SNMP).  Objects in the MIB are defined using the
>    mechanisms defined in the Structure of Management Information
>    (SMI).
> 
> The other confusing reference designation is 3411.  For some 
> of the same reasons, this initially appears to be Normative 
> from the way it's referenced in 5.1.  But further examination 
> shows that it's probably not.  However, in this case I have 
> no good ideas how to make the confusion less likely, so 
> unless something occurs to the authors or the RFC editor, I 
> guess we just let this one slide.  It's only a minor 
> confusion, anyway.
> 
> ----------------------------------------------------------------
>    The following editorial issue is noted for the convenience of
>    possible copy editors but is not part of the technical review.  If
>    another draft is not required, just hold onto these for the RFC
>    Editor.
> 
> Typos
> -----
> 
> Section 4 seems to have an errant paragraph break in the 
> middle of a sentence.
>