Summary for RFC 3276 respin

Hi Everyone,

There has been some great discussion this week over the draft that was 
sent out. Thanks for all that participated! I looked back through the 
threads and want to summarize the issues along with potential direction 
moving forward.


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.

Also, it sounds like the description for line rates could be clarified 
that the rates include user data (payload) and framing if applicable. In 
addition, since all rates are either directly or indirectly associated 
with an ifIndex and not a wire pair, the descriptions could be clarified 
that the rates are a sum of all wire pairs.


2. Wire Pair

The question here becomes, "Will we get an increase in the future?" We 
could do one of three things: (1) Add wirePair3 and wirePair4 as we did 
in the -00 draft,  (2) Change the TC to be Integer32  or INTEGER with a 
lower bound of 1 and either without an upper bound or a large upper 
bound. (3) Put this an all the other TCs in a separate draft so that if 
there is a change in the future, only the RFC with the TCs would have to 
change.

I'm not sure if number 3 is of any value.

Number 2 is my favorite. In should not have to change in the future. 
Especially for something like Integer32(1..2147483647).  The mapping 
would be: 1 for wirePair1, 2 for wirePair2, 3 for wire wirePair3, ..., n 
for wirePair n. The values are the same as the enumerations in the RFC. 
I don't seen any interoperability  "over the wire" so it should be ok 
with RFC 2578, Section 10.
 

3. Other Enhancements

Lee Nipper, Verilink Corp.,  suggested adding an object that would 
display the user data rate (payload). This sounds like great idea in 
that the end user would not have to consider do I have framing or not 
and if I do, is it 8 kbits/s I subtract. Let the device do the math for him.

Matt Beanland, Extel Communications, suggested two new objects. (1) Some 
sort of training state indicator for a wire pair and (2) an indication 
that a wire pairs is swapped. The idea of a training state seem like it 
would be of great help. Today, it is hard to determine the operational 
state of a pair. We have current attenuation and SNR margin, but is that 
enough? These could be optional and specified as such in conformance 
statements for the cases where the chip sets and handle it. I

4. Extend, Replace, or all New

Based on the above issues, what make the most sense for past and future 
implementations. Are the changes radial enough to produce a draft to 
eventually replace the RFC?  Should we break out SHDSL as it's own MIB?


Thoughts are appreciated.

Thanks,
Clay


-- Paradyne Mail --