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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 7 Jun 2006 18:20:25 +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 
> <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: "David Harrington" <[email-masked]>
Date: Wed, 7 Jun 2006 13:56:13 -0400

Hi,

I'll comment on this.

While it certainly debatable about how well we have achieved the goal,
part of the goal of the Internet-Standard Management Framework is to
keep a separation between MIB modules and the protocols that transport
the data.

The boilerplate has a reference to RFC3410, that is Informational
because, at least theoretically, SNMP is only one protocol that could
carry MIB objects. The references to RFC2578, 2579, and 2580 are
Normative because it is necessary to understand the SMIv2 modeling
language to understand the data model specified in the MIB module
defined in this document.

But that raises some additional problems with this document. In
multiple places in this document, there are statements that something
related to this MIB module can be done using SNMP.

Section 5 says 
   "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 SNMP.) "

Section 5.1 saya:
   "For example, one such grouping accommodates a single SNMP agent
having 
   multiple AgentX [RFC2741] sub-agents, with each sub-agent 
   implementing a different Fibre Channel management instance. "
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). "

"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."

1) I think it is bad practice to discuss SNMP within a MIB module. It
is conceivable that other protocols could be used with this MIB
module.
2) I think it has been best current practice to not discuss agentX
when defining protocol or MIB solutions, since agentX is a protocol
that is used in certain implementations, and it is independent of both
SNMP and SMIv2.
3) I also feel uneasy about the discussions of multiple instances
within an SNMP context. Is this in any way different than the normal
SMIv2 mechanisms for identifying instances?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan
(Dan)
> Sent: Wednesday, June 07, 2006 11:20 AM
> To: Michael A. Patton; [email-masked]
> [email-masked]; [email-masked]
> Subject: RE: REVIEW: draft-ietf-imss-fc-vf-mib-02.txt
> 
> Michael,
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jun 2006 13:56:13 -0400

Hi,

I'll comment on this.

Section 5 says 

Section 5.1 saya:

David Harrington
[email-masked] 
[email-masked]
[email-masked]

(Dan)

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 7 Jun 2006 10:31:56 -0700 (PDT)

All,

In my humble opinion ANY group in the IETF that reviews MIB
documents should be obliged to follow RFC 4181/BCP 111.  One of the
reasons we wrote the document was to ensure that different MIB
Doctors would provide consistent reviews.  Authors have a right to
expect the same from other review groups.

Of course, if there is something you don't agree with in RFC 4181
or in the standard MIB boilerplate, then it's fair to open a
discussion on making changes, but until there is agreement on those
changes the existing review standards should prevail.

Mike Heard

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 7 Jun 2006 17:53:06 -0400

Hi,

Let me put my comments in a more actionable state for purposes of IESG
resolution:
 
It is appropriate in a MIB module to list RFC2578-80 (SMIv2) as
Normative, since they define the language used in the MIB.

It is appropriate in a MIB module to list RFC3410 as Informative,
because SNMP is not the only protocol that can transport MIB data, in
accordance with the Internet-Standard Management Framework.

This document may require documents in the RFC341x series (SNMPv3
standard) to be listed as Normative because they reference aspects of
SNMPv3 explicitly. But it seems bad practice to do this, and they
could eliminate the Normative reference by eliminating these
unnecessary references in the text.

>    "managed actions" which can be invoked via SNMP.) "

The second sentence seems totally unnecessary. Implementers need to
know what is in the Mib module, not what is not in the MIB module.

>    implementing a different Fibre Channel management instance. "

I recommend this implementation suggestion be removed. It is
unnecessary, and only one viable approach of many. The standard SMIv2
row-instancing should be adequate, as would different SNMP
contextNames or contextEngineIDs, or different SNMPv1 communtities.
Eliminating this unnecessary example would eliminate the only
reference to agentX.

>    context ([RFC3411] section 3.3.1). "

Unless the use of fcmInstanceIndex somehow uniquely identifies each
instance in a manner that is not consistent with normally SMIv2 rules,
and it is not obvious to me that such is the case, then I think this
could be worded as:

    "The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-
    MIB [RFC4044] as the index value to uniquely identify each 
    Fibre Channel management instance. "
 
> fabrics) are create-able via SNMP."

This could be worded:
 	"With the definition and usage of virtual switches,
 fcmSwitchTable now applies to virtual switches as well as physical
 fabrics, and instances in the table may be created by a remote
management application."

Making these changes would eliminate any reference to RFC3411 and
RFC2741.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: "Michael A. Patton" <[email-masked]>
Date: Thu, 8 Jun 2006 03:23:35 -0400 (EDT)

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

---

From: "Michael A. Patton" <[email-masked]>
Date: Thu, 8 Jun 2006 03:35:24 -0400 (EDT)

If I understand your referenced message, it is only responding to one
of my points, the minor comment about the wording of and
classification of the references in Section 2.  And you forwarded on
to the MIB doctors because the referenced text is standard
boilerplate.

Well, if it's standard boilerplate, then that's a sufficient
explanation for it being worded that way and I withdraw my suggestion
for clearer text.  After all, when I look at a MIB to use it (as
opposed to when I'm reviewing it for (human) readability), I never look
at that section, so how it's worded probably has very little effect on
interoperability.

However, you haven't responded to the major concern about "Updates
4044" which I see from other messages is also of concern to Brian.

	-MAP

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Jun 2006 11:36:47 +0200

Yes, GEN-ART reviewers are expected to be generalists
and looking for issues on the basis of general knowledge
and common sense. They aren't supposed to be doing the
job of specialist reviewers, but of course there can be
issues on the borderline. No blame, no shame, please.

     Brian

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 8 Jun 2006 08:31:10 -0700 (PDT)

Hi Dave,

> Normative, since they define the language used in the MIB.
 
Agreed.

> accordance with the Internet-Standard Management Framework.

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.

> unnecessary references in the text.

Agreed.

> know what is in the Mib module, not what is not in the MIB module.

I suggest that it seems unnecessary to you because you are an SNMP and
MIB expert but a Fibre Channel novice, but please remember that this
document is the product of two standardization committees.  INCITS's
T11 committee started the work in order to provide the technical
expertise on Fibre Channel.  The IETF has continued the work so as to
provide the expertise on MIBs.  That second sentence was put in
specifically to address a comment made by a member of T11 who is a
Fibre Channel expert and a MIB novice.  To take it out would be to
rescind a decision taken in T11.

In fact, I consider the sentence to be necessary because Fibre Channel
defines its own (link layer) network management protocols which do
provide the capability of "managed actions".  Thus, the mention of SNMP
is needed to distinguish the use of this MIB from the use of such Fibre
Channel management protocols.

In any case, T11 members did not object to the inclusion of section 3,
all of which is redundant as far as a Fibre Channel expert is
concerned, and is present for those in the IETF and beyond who are
novices on Fibre Channel.  Thus, I suggest that you as an SNMP/MIB
expert should not object to something which is redundant as far as you
are concerned, but informative for a T11 participant.

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.)

> Eliminating this unnecessary example would eliminate the only

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 ??

>     Fibre Channel management instance. "

Again, the reference to SNMP contexts here was intended to be informative
in nature, and informative from a compliance perspective.  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)."

>  fabrics, and instances in the table may be created by a remote
 
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.

As you said above, with RFC 3410 listed as Informative, SNMP is an
example of a protocol which can be used to transport MIB data.
The other reason for my alternate wording is to retain in the sentence
the original intent of the word "unlike", which serves to explain
why the new usage requires a row-creation capability when the old one
did not.

> Making these changes would eliminate any reference to RFC3411 and
 
Why is is necessary to eliminate *Informative* references, which provide
useful information to those who are not experts ??

Keith.

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 Jun 2006 12:06:16 -0400

Hi Keith,

Yup, I agree with your comments. 

> point multiple times below.

Agreed, as long as the MIB doesn't create dependencies on SNMP as the
only protocol.
 
> > > Section 5 says 
[...]
> > know what is in the Mib module, not what is not in the MIB module.
[..]

>        management protocol such as SNMP.)

I'm OK with this wording.

> > > Section 5.1 saya:
[...]
> 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.

> [...] 
> That is, the

That works for me. In fact making it an example resolves my concern
that the wording seemed to imply something special.

>     switches to be created via remote management applications,

I like your wording much better than the original, and better than
mine.

> 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