RE: RFC3276 respin

> If ("IF") there were another spin on RFC3276, then, would the following
> list of changes suffice to support g.shdsl.bis (from Clay's list)?
> 
> 1. Hdsl2ShdslWirePair TC - add wirePair3(3) and wirePair4(4)
> 2. hdsl2ShdslSpanConfWireInterface - add sixWire(3) and eightWire(4)
> 3. hdsl2ShdslStatusMaxAttainableLineRate - remove the range limit
> 4. hdsl2ShdslStatusActualLineRate - remove the range limit
> 5. hdsl2ShdslSpanConfMinLineRate - remove the range limit
> 6. hdsl2ShdslSpanConfMaxLineRate - remove the range limit
> 
> Would these do it?  Would this be all?  Would this break any existing
> implementations (at least of embedded agents)?  Would the above break
> any management apps?  
> 
> It doesn't look like it would - it sure looks like any new devices
> would simply have a "looser" range of values in 5 objects.
> 
Formally, I do not think that you can remove the range limits.
See RFC2578, sect 10.

However, I agree that it does not seem to be harmfull. It certainly
would not have any impact for the on the wire protocol.

I think I could go along with the change if we were to update the
current MODULE-COMPLIANCE such that the current ranges are inlcuded
there, and then do a new MODULE-COMPLIANCE that allows for the new
values, certainly for the read-write objects. 

Similar fixes to MODULE-COMPLIANCE would be recommend for the enumerated
objects.

Hope this helps,
Bert
> -- 
> Bob Ray <[email protected]>
> 
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
>