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

"Wijnen, Bert \(Bert\)" <[email protected]> Mon, 23 Apr 2007 10:18:43 +0200
Newsgroups gmane.ietf.hubmib
Message-ID <[email protected]>
Mmm.. this one dropped through the cracks at the end of the=20
IETF week. But... that just means you all have had more time=20
to review.

We have seen no additional comments, so as WG chair I declare=20
that we have consensus to forward this document to our AD for
IETF Last Call and IESG consideration as a PS RFC.

I will prepare the proto-write-up and then (assuming no new
concerns come up during that preparation) request publication.
I will copy the WG list on that request.

Bert Wijnen
Chair of the IETF HUBMIB WG=20

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]=20
> Sent: Tuesday, March 06, 2007 11:42 PM
> To: Hub Mib
> Subject: [Hubmib] WG Last Call: draft-ietf-hubmib-efm-cu-mib-07.txt
>=20
> =20
> WG members,
>=20
> 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=20
> is OK with the changes that have been made based on various=20
> reviews and mailing list discussions.
>=20
> The WG Last Call ends at the end of IETF week, so that is on=20
> March 23rd.
>=20
> Bert Wijnen
> HUBMIB WG chair
>=20
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email protected]]
> > 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=20
> another WG Last=20
> > Call, so people can check the latest changes.
> > Pls be prepared!
> >=20
> > Bert
> >=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=20
> Normative=20
> > > References
> > >=20
> > > - I left ANFP as an Informative Reference, since it's
> > purpose 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 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
> > > 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=20
> 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
> > ifCapStackTable
> > > > > > > >  and ifInvCapStackTable? In any event, pls=20
> re-check the =20
> > > > > > > > feedback we've got on that. I do not think that=20
> what we =20
> > > > > > > > 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=20
> object from=20
> > > > > > ifCapStackStatus to ifCapStackCapability to better
> > > represent its
> > > > > > purpose. Same for possibly renaming=20
> ifInvCapStackStatus into=20
> > > > > > ifInvCapStackCapability.
> > > > > >=20
> > > > > > I am not hung up on it though.
> > > > >=20
> > > > > [EB] ifCapStack already stands for "Interface
> > Capability Stack" -
> > > > > appending "Capability" would make it "Interface
> > Capability Stack
> > > > > 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
> > > > > 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=20
> far as I am=20
> > > > concenrned.
> > > >=20
> > > > Next step is then (another) W Last Call to givbe anyone a
> > chance to
> > > > look at the latest changes.
> > > >=20
> > > > Bert
> > > >=20
> > >=20
> >=20
> > _______________________________________________
> > Hubmib mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/hubmib
> >=20
>=20
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>=20