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