Subject: [Adslmib] Summary for RFC 3276 respin

From: "Clay Sikes" <[email-masked]>
Date: Fri, 16 Apr 2004 19:00:55 -0400

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 --

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 16 Apr 2004 20:39:30 -0700

Hi -

> From: "Clay Sikes" <[email-masked]>
> To: "Bob Ray" <[email-masked]>; "Rajesh Abbi" <[email-masked]>; "Lee Nipper" <[email-masked]>; "Matt Beanland"
<[email-masked]>
> Cc: "IETF ADSL MIB List" <[email-masked]>; "Clay Sikes" <[email-masked]>
> Sent: Friday, April 16, 2004 4:00 PM
> Subject: [Adslmib] Summary for RFC 3276 respin
...
> 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.

(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.)

Randy