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

["Wijnen, Bert \(Bert\)" <[e-mail]>]

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 

> -----Original Message-----
> From: Edward Beili [mailto:[e-mail]] 
> Sent: woensdag 21 februari 2007 22:54
> To: Wijnen, Bert (Bert)
> Cc: Hub Mib; Dan Romascanu (E-mail)
> Subject: RE: [Hubmib] My review of: 
> draft-ietf-hubmib-efm-cu-mib-06.txt
> 
> Bert,
> 
> - RFC3410 is moved to Informative References
> 
> - RFCs 2863, 2864, 3635, G.991.2 and G.992.1 are moved to 
> Normative References
> 
> - I left ANFP as an Informative Reference, since it's purpose 
> in the MIB is to serve an example.
> 
> The latest version of the draft is attached together with the 
> extracted MIB files.
> I'm sending it to the internet-drafts, so it'll be published 
> in a day or two.
> 
> Thanks for your thorough reviews,
> -E.
> 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> > Sent: Wednesday, February 21, 2007 16:51
> > To: Edward Beili
> > Cc: Dan Romascanu (E-mail); Hub Mib
> > Subject: RE: [Hubmib] My review of: 
> > draft-ietf-hubmib-efm-cu-mib-06.txt
> > 
> > Looks good now. One thing (I should have seen yesterday 
> too) is that 
> > you need to move a few informative refrences to the normative 
> > references and vice versa
> > 
> > - I think RFC3410 is informative (it is also an informational
> >   RFC).
> > 
> > - RFC2863 and RFC2864 are normative, because we IMPORT from those.
> > 
> > - 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?
> > 
> > - Since we state:
> >    3.4.  Relation to Ethernet-Like and MAU MIB modules
> > 
> >    The implementation of EtherLike-MIB [RFC3635] and MAU-MIB
> >    [I-D.ietf-hubmib-rfc3636bis] is REQUIRED for the EFMCu 
> interfaces.
> > 
> >   We probably also better make RFC3635 a normative ref.
> > 
> > With that I think we would be ready.
> > 
> > Further, I would like to react to a few of Ed's rebuttals:
> > 
> > > > - But I do want you to fix SMICng reported error:
> > > > 
> > > >   E: f(rfc2864.mi2), (168,26) Item "ifStackGroup2" should be
> > IMPORTed
> > > >   
> > > >   since you do list that as a mandatory group.
> > > 
> > > [EB] ifStackGroup2 is already imported, I've fixed that in
> > the version
> > > I sent before.
> > > 
> > 
> > My appology, the error is in RFC2864, not in the EFM-CU-MIB.
> > 
> > > > > >- 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.
> > > > > 
> > > > > [EB] Replaced with TruthValue.
> > > > 
> > > > This is much better.
> > > > I wonder if it would now be better to rename the object from 
> > > > ifCapStackStatus to ifCapStackCapability to better 
> represent its 
> > > > purpose. Same for possibly renaming ifInvCapStackStatus into 
> > > > ifInvCapStackCapability.
> > > > 
> > > > I am not hung up on it though.
> > > 
> > > [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
> > > 
> > 
> > Your argument for consistency with ifCapStackStatus makes sense.
> > And as I said, I am not hung up on it.
> > So I am OK now.
> > 
> > 
> > > [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?
> > > 
> > 
> > Yep.
> > 
> > I think we made good progress.
> > 
> > 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 
> > concenrned.
> > 
> > Next step is then (another) W Last Call to givbe anyone a chance to 
> > look at the latest changes.
> > 
> > Bert
> > 
> 

_______________________________________________
Hubmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hubmib