RE: Summary for RFC 3276 respin

> > 1. Line Rates
> >
> > It seems like we all agree that the all line rates should be changed to
> > an unbounded Unsigned32. Removing the restrictions on the upper limit
> > will prevent us from making having to make any changes should the upper
> > limits that exist today change in the future. This is really good in
> > that Annex G in the G.991.2, 12/2003, still has a provisional rate.
> ...
> 
> I agree that this seems like the right thing to do.
> 
> However, as far as I can tell, the rules for revising MIB modules do
> not support this change, and would require us to create new objects
> that lacked the old, over-specified range constraints.  I think we should
> check with the AD to see whether the need to maintain interoperability
> with the installed base is sufficient justification in this 
> case to bend the rules.
> There needs to be some thought to verify that both old manager/new agent
> and new manager/old agent scenarios would work.
> 
So... if we do remove the constraints in the objects themselves, can we 
then not achieve the proper interoperability/backward compatibility via
a change to the existing MODULE-COMPLIANCE (to specify the constraint)
and then add a new MODULE-COMPLIANCE without the constraints.

> (The lesson, of course, is that constraints given in a MIB should be
> those inherent in the architecture of the stuff being managed, not
> just the current technology.)
> 
Yep... or define them in the MODULE-COMPLIANCE.
Adding an extra MODULE-COMPLIANCE is always easy.

bert
> Randy
> 
>