RE: My review of: draft-ietf-hubmib-efm-cu-mib-06.txt

Thank you Edward!

WG members,
As soon as the new document shows up I plan to issue another
WG Last Call, so people can check the latest changes.
Pls be prepared!

Bert=20

> -----Original Message-----
> From: Edward Beili [mailto:[email protected]]=20
> 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=20
> Normative References
>=20
> - I left ANFP as an Informative Reference, since it's purpose=20
> in the 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 published=20
> in a day 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=20
> too) is that=20
> > 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=20
> 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 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=20
> represent its=20
> > > > 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 Capability Stack" -=20
> > > appending "Capability" would make it "Interface 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 definition
> > > (efmCuPme10PStatusTable) and corrected it - now all tables
> > contain the
> > > persistency behavior definition in the DESCRIPTION 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 chance to=20
> > look at the latest changes.
> >=20
> > Bert
> >=20
>=20