Re: AD review of draft-ietf-hubmib-wis-mib-04.txt

On Sun, 15 Dec 2002, C. M. Heard wrote:
> > On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote:
> > > - Sections 3.1, 3.2 and 3.3 talk about requirements to
> > >   implement pieces of other MIB modules. I see some of
> > >   it (from sonet mib) back in the MODULE-COMPLIANCE.
> > >   Should we not just include all of the required objects
> > >   from other MIB modules in the MODULE-COMPLIANCE?
> > 
> > This subject was discussed at some length on the WG mailing
> > list.  The resolution was that we prefer, wherever possible,
> > simply to reference an existing compliance statement.  That
> > was possible for the EtherLike-MIB (we point to
> > dot3Compliance2) and the MAU-MIB (we point to mauModIfCompl3).
> > It was not possible for the SONET-MIB, however, because we
> > needed to make some objects [that are optional in]
> > sonetCompliance2 mandatory for WIS applications.
> 
> No change:  since there was no feedback, I have assumed that the
> rationale provided for keeping the existing compliance scheme
> was OK.

The consensus that was documented in the recently revised MIB review
guidelines document -- which postdates the -06 version of the
ETHER-WIS MIB -- is that modules incorporated by reference SHOULD be
mentioned in the DESCRIPTION clause of a MODULE-COMPLIANCE statement
as well as in the surrounding documentation, as John Flick has done
in the recently-submitted EtherLike-MIB and the MAU-MIB drafts.

If the AD, chair, and WG have no objections, I shall (after the
IETF-56 I-D blackout ends) update the ETHER-WIS compliance statement
to bring it into conformance with this guideline.  It will need to
mention the IF-MIB's ifCompliance3 statement, the
IF-INVERTED-STACK-MIB's ifInvCompliance statement, the
EtherLike-MIB's dot3Compliance2 statement, and the MAU-MIB's
mauModIfCompl3 statement.

In addition, after further review, I find that the following comment
I made against the -04 draft was erroneous --

% While going over this stuff I notice that the MIB as presently
% written requires that a conformant implementation  allow any
% combination of values for etherWisDeviceTxTestPatternMode and
% etherWisDeviceRxTestPatternMode, but in fact hardware that is
% based on the 802.3ae Clause 45 MDIO registers won't allow all
% combinations to be set.

-- since the 802.3ae Clause 45 MDIO registers _do_ in fact allow all
combinations to be set.  I would therefore like to remove the
compliance statement language that I added to the -05 draft stating
that an implementation doesn't have to allow different test modes in
the transmit and receive path.

Regards,

Mike Heard