Subject: [Gen-art] REVIEW: draft-ietf-imss-fc-vf-mib-02.txt

From: "Michael A. Patton" <[email-masked]>
Date: Wed, 7 Jun 2006 01:54:31 -0400 (EDT)

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.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 7 Jun 2006 14:50:04 +0300

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:[email-masked]] 
> Sent: Wednesday, June 07, 2006 8:55 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 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 
> 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.
> 
> 
> 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.
> 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:
> 
> 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.
> 
> Section 4 seems to have an errant paragraph break in the 
> middle of a sentence.
>

---

From: [email-masked]
Date: Thu, 8 Jun 2006 06:39:52 -0400

> I actually think the comments from David
> Harrington are more critical.  Mine takes just a simple decision, his
> comments are more far-reaching thus harder to evaluate and entail a
> more substantial change if accepted.
> 
> 	-MAP
> 
> P.S.  This is on _today's_ agenda, right?

Apparently it is, but with the pair of Discusses against the draft,
it should not get approved this time.  Wearing my imss WG chair hat,
I think a revised draft is appropriate because the "does this draft
update RFC 4044?" issue looks like it's going to involve some
careful text crafting that I'd prefer not to see done in haste.

Many thanks to the reviewers,
--David (imss WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 8 Jun 2006 13:47:00 +0300

I agree. 

Dan

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, June 08, 2006 1:40 PM
> To: [email-masked]; Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [Gen-art] RE: REVIEW: draft-ietf-imss-fc-vf-mib-02.txt
> 
> > I actually think the comments from David Harrington are 
> more critical.  
> > Mine takes just a simple decision, his comments are more 
> far-reaching 
> > thus harder to evaluate and entail a more substantial change if 
> > accepted.
> > 
> > 	-MAP
> > 
> Apparently it is, but with the pair of Discusses against the 
> draft, it should not get approved this time.  Wearing my imss 
> WG chair hat, I think a revised draft is appropriate because 
> the "does this draft update RFC 4044?" issue looks like it's 
> going to involve some careful text crafting that I'd prefer 
> not to see done in haste.
>

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 8 Jun 2006 10:54:44 -0400

Completely agree with Michael, no humility about it.  As usual
authors are certainly allowed to ignore comments with import 
that is not consistent with their expert knowledge. 

We do provide a pointer to a FAQ that explains why we are doing
a review, and it's alright if you haven't read that.  :-)

I know it can be cumbersome to deal with comments from a lot of
people that are not experts on the technology, but that doesn't
justify discouraging comments generally - especially given the
tendency for IDs to be insufficiently reviewed in general...

--
Eric Gray

--> -----Original Message-----
--> From: Michael A. Patton [mailto:[email-masked]] 
--> Sent: Thursday, June 08, 2006 3:24 AM
--> To: [email-masked]
--> Cc: [email-masked]; [email-masked]
--> Subject: Re: [Gen-art] RE: REVIEW: draft-ietf-imss-fc-vf-mib-02.txt
--> 
-->    Date: Wed, 7 Jun 2006 10:31:56 -0700 (PDT)
-->    From: "C. M. Heard" <[email-masked]>
--> 
-->    In my humble opinion ANY group in the IETF that reviews MIB
-->    documents should be obliged to follow RFC 4181/BCP 111.
--> 
--> In my humble opinion, it is completely unreasonable to expect GenART
--> members to be intimately familiar with the details of every group
--> within the IETF.  I doubt there is anyone that could meet that
--> requirement.  We are generalist reviewers as described in the
--> referenced FAQ, and not expected to be experts in the area of any
--> drafts we review.
--> 
--> It would be fine to respond to a review comment by saying "this is
--> standard practice in the ... community."  However, responding by
--> saying, "You can't review this because you don't know our existing
--> practice" completely misses the point of GenART.
--> 
--> 	-MAP
--> 
--> _______________________________________________
--> Gen-art mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/gen-art
-->

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 8 Jun 2006 19:25:19 +0300

The document was just discussed in the IESG telechat. 

Brian has yet to read Keith's other mail, but it looks that (based on my
rendition)  the chances for Brian to accept Keith's arguments are good.

With David accepting Keith proposed edits in this mail, the way is paved
for me clearing the DISCUSS opened based on his comment. 

The IESG decided to put the document in 'AD follow-up'. 

My suggestion is to include the changes suggested by Keith in RFC Editor
notes. After the DISCUSSes are cleared, it can go to approved. 

Any comments on this proposed plan of record? 

Dan

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Thursday, June 08, 2006 7:06 PM
> To: 'Keith McCloghrie'
> Cc: 'David Harrington'; Romascanu, Dan (Dan); 'Michael A. 
> Patton'; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: REVIEW: draft-ietf-imss-fc-vf-mib-02.txt
> 
> Hi Keith,
> 
> Yup, I agree with your comments. 
> 
> > Agreed, and because it is appropriate to list RFC3410 as
> Informative,
> > it is also appropriate to use SNMP as an example of a 
> remote network 
> > management protocol for transporting MIB data.  I will 
> refer to this 
> > point multiple times below.
> 
> Agreed, as long as the MIB doesn't create dependencies on 
> SNMP as the only protocol.
>  
> > > > Section 5 says
> [...]
> > > The second sentence seems totally unnecessary. Implementers need
> to
> > > know what is in the Mib module, not what is not in the MIB module.
> > 
> [..]
> > 
> > If you would prefer, it could be reworded esuch that SNMP is only
> used
> > as an example, e.g.,
> > 
> >        This MIB module provides the means for monitoring the 
> >        operation of, and configuring some parameters of, one or more
> 
> >        instances of Fibre Channel Virtual Fabric functionality. 
> >        (Note that there are no definitions in this MIB module of 
> >        "managed actions" which can be invoked via a remote network
> >        management protocol such as SNMP.)
> 
> I'm OK with this wording.
> 
> > 
> > > > Section 5.1 saya:
> [...]
> > A similar issue occurs here.  If this text required the use of
> AgentX,
> > or even required the use of SNMP, then I would agree with you, but
> it
> > doesn't -- the sentence begins with "For example,".  It is included
> to
> > make it easier for Fibre Channel experts with little MIB/SNMP 
> > expertise to understand the document.  What harm does it do ??
> 
> I think it biases the proposal to one of many different 
> possible solutions, which may favor some vendors over others. 
> I think it biases the proposal to a solution that is external 
> to SNMP, even though SNMP has built-in features that could 
> have served as examples.
> But I can live with it.
> 
> > 
> > > > And
> > > >    "The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-
> > > >    MIB [RFC4044] as the index value to uniquely identify each 
> > > >    Fibre Channel management instance within the same SNMP 
> > > >    context ([RFC3411] section 3.3.1). "
> > > 
> > [...]
> > That is, the
> > document's mistake is to list RFC 3411 as a Normative Reference,
> when
> > it should be listed as an Informative Reference, and the reference
> to
> > SNMP contexts should be given only as an example.  Thus, I propose 
> > that the wording be changed:
> > 
> >      "The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-
> >      MIB [RFC4044] as the index value to uniquely identify each 
> >      Fibre Channel management instance, for example within the
> >      same SNMP context ([RFC3411] section 3.3.1)."
> 
> That works for me. In fact making it an example resolves my 
> concern that the wording seemed to imply something special.
> 
> > 
> > > > "t11vfVirtualSwitchEntry" says 
> > > > 	"With the definition and usage of virtual switches, 
> > > > fcmSwitchTable now applies to virtual switches which (unlike
> > > physical
> > > > fabrics) are create-able via SNMP."
> >  
> > I'd like to suggest an alternate wording:
> > 
> >     	"With the definition and usage of virtual switches,
> >     fcmSwitchTable now applies to virtual switches as well as
> >     physical switches, and (in constrast to physical switches)
> >     it is appropriate to provide the capability for virtual
> >     switches to be created via remote management applications,
> >     e.g., via SNMP.
> 
> I like your wording much better than the original, and better 
> than mine.
> 
> > > Making these changes would eliminate any reference to RFC3411 and 
> > > RFC2741.
> >  
> > Why is is necessary to eliminate *Informative* references, which 
> > provide useful information to those who are not experts ??
> 
> I already told Dan I didn't consider the elimination of these 
> necessary.
> > 
> > Keith.
> > 
> 
> Thanks for the fast response.
> dbh
> 
>