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
Hubmib@ietf.org
https://www1.ietf.org/mailman/listinfo/hubmib