WG Last Call: draft-ietf-hubmib-efm-cu-mib-07.txt

=20
WG members,

The revision 7 has been out since march 2nd (i.e. last weekend).
As promised, this is a new WG Last Call to make sure everyone
is OK with the changes that have been made based on various
reviews and mailing list discussions.

The WG Last Call ends at the end of IETF week, so that is
on March 23rd.

Bert Wijnen
HUBMIB WG chair

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]=20
> Sent: donderdag 22 februari 2007 10:45
> To: Edward Beili
> Cc: Dan Romascanu (E-mail); Hub Mib
> Subject: RE: [Hubmib] My review of:=20
> draft-ietf-hubmib-efm-cu-mib-06.txt
>=20
> Thank you Edward!
>=20
> WG members,
> As soon as the new document shows up I plan to issue another=20
> WG Last Call, so people can check the latest changes.
> Pls be prepared!
>=20
> Bert=20
>=20
> > -----Original Message-----
> > From: Edward Beili [mailto:[email protected]]
> > Sent: woensdag 21 februari 2007 22:54
> > To: Wijnen, Bert (Bert)
> > Cc: Hub Mib; Dan Romascanu (E-mail)
> > Subject: RE: [Hubmib] My review of:=20
> > draft-ietf-hubmib-efm-cu-mib-06.txt
> >=20
> > Bert,
> >=20
> > - RFC3410 is moved to Informative References
> >=20
> > - RFCs 2863, 2864, 3635, G.991.2 and G.992.1 are moved to Normative=20
> > References
> >=20
> > - I left ANFP as an Informative Reference, since it's=20
> purpose in the=20
> > MIB is to serve an example.
> >=20
> > The latest version of the draft is attached together with the=20
> > extracted MIB files.
> > I'm sending it to the internet-drafts, so it'll be=20
> published in a day=20
> > or two.
> >=20
> > Thanks for your thorough reviews,
> > -E.
> >=20
> >=20
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email protected]]
> > > Sent: Wednesday, February 21, 2007 16:51
> > > To: Edward Beili
> > > Cc: Dan Romascanu (E-mail); Hub Mib
> > > Subject: RE: [Hubmib] My review of:=20
> > > draft-ietf-hubmib-efm-cu-mib-06.txt
> > >=20
> > > Looks good now. One thing (I should have seen yesterday
> > too) is that
> > > you need to move a few informative refrences to the normative=20
> > > references and vice versa
> > >=20
> > > - I think RFC3410 is informative (it is also an informational
> > >   RFC).
> > >=20
> > > - RFC2863 and RFC2864 are normative, because we IMPORT from those.
> > >=20
> > > - Since we use them in REFERENCE clauses or we use profiles
> > >   from (as listed in DESCRIPTION clauses), I think that also
> > >   ANFP< but certainly 991.2 and 992.1 are normative, no?
> > >=20
> > > - Since we state:
> > >    3.4.  Relation to Ethernet-Like and MAU MIB modules
> > >=20
> > >    The implementation of EtherLike-MIB [RFC3635] and MAU-MIB
> > >    [I-D.ietf-hubmib-rfc3636bis] is REQUIRED for the EFMCu
> > interfaces.
> > >=20
> > >   We probably also better make RFC3635 a normative ref.
> > >=20
> > > With that I think we would be ready.
> > >=20
> > > Further, I would like to react to a few of Ed's rebuttals:
> > >=20
> > > > > - But I do want you to fix SMICng reported error:
> > > > >=20
> > > > >   E: f(rfc2864.mi2), (168,26) Item "ifStackGroup2" should be
> > > IMPORTed
> > > > >  =20
> > > > >   since you do list that as a mandatory group.
> > > >=20
> > > > [EB] ifStackGroup2 is already imported, I've fixed that in
> > > the version
> > > > I sent before.
> > > >=20
> > >=20
> > > My appology, the error is in RFC2864, not in the EFM-CU-MIB.
> > >=20
> > > > > > >- Did we resolve the use of Rowstatus for the=20
> ifCapStackTable
> > > > > > >  and ifInvCapStackTable? In any event, pls re-check the
> > > > > > >  feedback we've got on that. I do not think that what we
> > > > > > >  currently have in the MIB module is acceptable.
> > > > > >=20
> > > > > > [EB] Replaced with TruthValue.
> > > > >=20
> > > > > This is much better.
> > > > > I wonder if it would now be better to rename the object from=20
> > > > > ifCapStackStatus to ifCapStackCapability to better
> > represent its
> > > > > purpose. Same for possibly renaming ifInvCapStackStatus into=20
> > > > > ifInvCapStackCapability.
> > > > >=20
> > > > > I am not hung up on it though.
> > > >=20
> > > > [EB] ifCapStack already stands for "Interface=20
> Capability Stack" -=20
> > > > appending "Capability" would make it "Interface=20
> Capability Stack=20
> > > > Capability". How about: ifCapStackAbility ?
> > > > Or we can leave it ifCapStackStatus, to emphasize its
> > > similarity with
> > > > IfStackTable
> > > >=20
> > >=20
> > > Your argument for consistency with ifCapStackStatus makes sense.
> > > And as I said, I am not hung up on it.
> > > So I am OK now.
> > >=20
> > >=20
> > > > [EB] I've found only one table without the persistency=20
> definition
> > > > (efmCuPme10PStatusTable) and corrected it - now all tables
> > > contain the
> > > > persistency behavior definition in the DESCRIPTION=20
> clause for the=20
> > > > table.
> > > > Basically only the Status tables are non-persistent.
> > > > Would that be satisfactory?
> > > >=20
> > >=20
> > > Yep.
> > >=20
> > > I think we made good progress.
> > >=20
> > > Pls correct the references (as stated at the top of this
> > > email) and then you can submit to internet-drafts as far as I am=20
> > > concenrned.
> > >=20
> > > Next step is then (another) W Last Call to givbe anyone a=20
> chance to=20
> > > look at the latest changes.
> > >=20
> > > Bert
> > >=20
> >=20
>=20
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>=20