Re: Next Generation ADSL (ADSL2) poll

Bob,

When it is ready for comments, I plan to provide input. Paradyne
currently using an enterprise MIB module based on an interpretation of
an early version of TR-090. My take is that an IETF MIB module is
needed to support ADSL2 and ADSL2plus.

My understanding is that there were some actions items from the 62nd
IETF meeting. I have indicated what I thought the actions were in blue
below.

Thanks for moving this forward!

Best Regards,

Clay

ADSLMIB Working Group - Minutes

62nd IETF, Minneapolis, MN USA

March 7, 2005

2. Faye noted that the draft and TR-090 do not support a

method of connecting multiple channels to the interface MIB.

She suggested that we petition IANA to provide another ADSL

interface type, adsl_channel, in addition to the ones

already assigned (fast and interleaved).

Moti noted that while the model uses an index to identify

the channel in question, that he was not adverse to having

another interface type layered into the draft. The
attendees

agreed to "take it to the list".

3. Faye pointed out a problem with multi-channel bandwidth

limitation, stating that the summation of the available

maximum bandwidth allocations should be equal to the maximum

available on the line. Otherwise, it was an "oversubscription"

issue.

Bob Ray pointed out that the aggregate maximum-per-

channel bandwidth (sum of channels) defined in the channel

as line impairment would render useless any assignment.

Moti stated that this discussion was pointless in that,

in his opinion and experience, no one ever subdivided an

adsl line is this way; that it was over-engineering, a

solution in search of a problem.

The chair urged the issue be "taken to
the list".

4. Faye mentioned that the draft does not maintain separate

objects for ATU-C and ATU-R as RFC 2662 does. She argued

that having them separate was "nicer". Moti said that the

use of the word "nicer" was subjective and he wouldn't try

to base a decision on it because of that. Bob Ray noted that

the approach of using an index has been used in the RFC 3276

and RFC 3728.

The chair urged the issue be "taken to
the list".

7. Faye commented that the name of Moti's draft needed to be

better than "next generation", or "ng". Moti stated that he

didn't want to name it adsl2 as that implied restrictions as

to the scope of adsl variants the draft might address.

Faye suggested that the issue be "taken
to the list" and all

concurred.

8. Faye again mentioned the lack of separate objects for

ATU-C and ATU-R, stating that having another index object

made it difficult to implement RFC 3276. "Too many indices".

In response, Moti asked if there were any implementation
reports

on RFC 2662 [note: a working group milestone that should be

addressed very soon now]. There was mention of two or three.

9. Moti then discussed things that are missing in his draft.

- test management support. Moti is adamant that "tests"

and "diagnostics" are distinct. Faye asked pointedly

if there is any user data being passed when a diagnostic

is being run.

- sub-carrier snr measurement time.

- psd masks.

Moti stated that these omissions were not because he didn't
think

they should be omitted, rather that that they were complex and

required more thought.

Faye suggested that the issue about
interface status during

diagnostics (up, down, under test) be taken to the list.

10. Moti briefly discussed the data returned by the diagnostics

and that it made sense, in his opinion, to have them returned

as OCTET STRINGs of fixed size rather than have an index. It was

agreed that this was the better approach (given the overhead

associated with walking an array of bytes). It was also noted

that the bit ordering within these values needs to be specified

in the draft.

11. Faye noted that if the draft used ifIndex for channel

identification (see note 2, above), that Moti's "templates"

would not be needed. Moti commented that "profile" and

"template" mean the same thing in the draft.

When Moti and Bob didn't understand how channel templates

wouldn't be needed, Faye agreed to produce an
example illustrating

her point. "On the list".

12. There was a brief discussion as to whether the draft needed

to address ATM objects. It was decided to leave
this "for the

list".

On 4/8/2005 9:10 AM, Ray, Robert wrote:

Next Generation ADSL (ADSL2) poll

Moti and Menechem's draft for ADSL2 is
available online at:

http://www.ietf.org/internet-drafts/draft-morgenstern-ngadsl-mib-00.txt

I need a show of hands from the
working group community as to who,

is interested in this work, who will
contribute to this work, and who plans

on using the product of this work.

Having only three attendees in
Minneapolis for Moti's presentation was

not a very convincing display of interest.

Please respond, to the list (not just
to me), as soon as you can.

Bob Ray

----------

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

-- Paradyne Mail --

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