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

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

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


 
 

> -----Original Message-----
> From: David B Harrington [mailto:dbharrington@comcast.net] 
> Sent: Thursday, June 08, 2006 7:06 PM
> To: 'Keith McCloghrie'
> Cc: 'David Harrington'; Romascanu, Dan (Dan); 'Michael A. 
> Patton'; gen-art@ietf.org; scott.kipp@mcdata.com; 
> gramkumar@stanfordalumni.org; mreview@ops.ietf.org
> 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
> 
>