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

["Edward Beili" <[e-mail]>]

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