Subject: [Ipoverib] RE: draft-ietf-ipoib-ibif-mib-01.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 23 Nov 2001 21:22:58 +0100

I have not followed the details (I am not on 
the ipoverib mailing list)... so I do not have all
the context of the discussions.

Anyway... some observations/comments inline

Bert 

> -----Original Message-----
> From: Paceline Systems [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 7:41 PM
> To: [email-masked]
> Cc: 'Wijnen, Bert (Bert)'
> Subject: Re: draft-ietf-ipoib-ibif-mib-01.txt
> 
> 
> Hi Sean and Bill,
> There are two areas where the IETF and the IBTA are at 
> somewhat at odds in terms of what is mandatory and optional.
> The first is adminStatus in the interface MIB which is R/W,
> but in the IB interface MIB is (primarily) R/O.
>
I think the ifAdminStatus is defined with a MAX-ACCESS of R/W
and in the ifCompliance3 definitions it shows that it can be
implemented R/O.
See RFC2863.

> The second area is the interface counters (input/output 
> bytes/packets).

> p.8 2.2.7 For ifAdminStatus, the I-D states "If write access 
> is implemented the default value for this attribute should
> be 'up' to avoid requiring the use of a SNMP manager to
> enable the interface." Not sure how to address this.

> p.11 2.4 Since PortCounters.PortXmitData, PortCounters.PortRcvData,
> PortCounters.PortXmitPkts, and PortCounters.PortRcvPkts are 
> optional and all return 0 if not implemented (according to
> the IBTA 1.0a vol 1 p. 766 Table 189), ifInOctets, ifInUcastPkts,
> ifOutOctets, and ifOutUcastPkts which are based on these should
> be indicated to return NO-SUCH-OBJECT. 
>
I believe it is not allowed to just return zero for a counter that
does not exist or is not implemented. In that case a noSuchInstance
should be returned I think, because other interfaces may actually
return valid values for this column, right?

> This is legal but non-IF-MIB-compliant and is better than being
> illegal by always returning 0 for these objects.

> p.15 defines ibIfNotifications, yet this doesn't appear 
> anywhere else in the MIB.
>
> 	ibIfNotifications OBJECT IDENTIFIER ::= { ibIfMIB 2}
> 
> p.21 ibIfVlTrafficIfIndex should be { IbIfVLTrafficEntry 1 } 
> rather than ibIfPortStatEntry 1 }.
> p.23 ibIfFullCompliance. From RFC 2580, "5. Mapping of the 
> MODULE-COMPLIANCE macro
> The MODULE-COMPLIANCE macro is used to convey a minimum set 
> of requirements with respect to implementation of one or 
> more MIB modules."
> Based on that, it would appear that only ibIfBasicCompliance 
> is needed.
>
It is perfectly all right to have multiple compliance statements.
In fact we're seeing more and more of these in which case a
FullCompliance supports everything (including write/create access)
while another ReadOnly compliance often supports only read-only
implementation. You can check draft-ietf-diffserv-mib-16.txt for
a good example.

Bert
> -- Hal Rosenstock
>    Paceline Systems
>    [email-masked]

_______________________________________________
IPoverIB mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipoverib