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 PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Romascanu, Dan
(Dan)
> Sent: Wednesday, June 07, 2006 11:20 AM
> To: Michael A. Patton; gen-art@ietf.org
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: REVIEW: draft-ietf-imss-fc-vf-mib-02.txt
>
> 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 PROTECTED]
> > Sent: Wednesday, June 07, 2006 8:55 AM
> > To: gen-art@ietf.org
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]; 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
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
