ADSL2 and Minneapolis IETF

Bob Ray <rray <at> pesa.com>
2005-02-07 15:10:51 GMT

I've requested a meeting slot at the 62nd IETF (March 6-11).
I've also requested that an area director be in attendance
as (per Moti's suggestion) we intend to amend the charter to
encompass ADSL2.
So, we need a volunteer to make a presentation on an ADSL2
MIB which will hopefully address the DSL Forum's decisions
and suggestions on the subject.
Any volunteers?
--
--
Bob Ray <rray <at> pesa.com>

RE: Minneapolis Agenda

Bob Ray <robertray <at> knology.net>
2005-02-09 03:09:33 GMT

Moti Morgenstern writes:
>I think that it is about time (before it becomes too late...) the WG
>should expand its charter to cover ADSL2. For ADSL2 we already have
>the G.997.1 from ITU and the TR-90 from the DSL Forum as well as
>actual deployment and still even not a draft MIB.
Thanks Moti. We've been lucky enough to have a volunteer to present
the DSL Forum recommendations for ADSL2 at the Minneapolis meeting.
I truly hope you can attend.
>When this formal action is done the WG (and I consider myself a
>member of the group) will be able to work on the MIB itself.
I know your help will be greatly appreciated. I know I have found
your help invaluable.
Bob Ray

The IESG has approved the following documents:
- 'Definitions of Managed Object Extensions for Very High Speed Digital
Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line
Coding '
<draft-ietf-adslmib-vdsl-ext-scm-08.txt> as a Proposed Standard
- 'Definitions of Managed Object Extensions for Very High Speed Digital
Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line
Coding '
<draft-ietf-adslmib-vdsl-ext-mcm-06.txt> as a Proposed Standard
These documents are products of the ADSL MIB Working Group.
The IESG contact persons are Bert Wijnen and David Kessens.
Technical Summary
Document draft-ietf-adslmib-vdsl-ext-mcm-06.txt defines a portion
of the Management Information Base (MIB) for use with network
management protocols in the Internet community. In particular,
it describes objects used for managing the Line Code Specific
parameters of Very High Speed Digital Subscriber Line (VDSL)
interfaces using Multiple Carrier Modulation (MCM) Line Coding.
It is an optional extension to the VDSL-LINE-MIB, RFC 3728,
which handles line code independent
Document draft-ietf-adslmib-vdsl-ext-scm-08.txt defines a portion
of the Management Information Base (MIB) for use with network
management protocols in the Internet community. In particular,
it describes objects used for managing the Line Code Specific

A draft adsl2 line MIB

<Moti.Morgenstern <at> ecitele.com>
2005-02-17 11:27:33 GMT

Hi all,
I'm going to briefly present the attached document to the ADSLMIB working
group at the Minneapolis meeting. It has been submitted as an initial draft
but may have missed the deadline by minutes so it may not be accessible in
the IETF site.
(See attached file: draft-ietf-morgenstern-adsl2-00.txt)
Regards,
Moti Morgenstern
e-mail: Moti.Morgenstern <at> ecitele.com

Re: A draft adsl2 line MIB

Let us know when you are ready for comments; I think this version of
the draft is meant to primarily spark a discussion at the IETF meeting.

One thing that may warrant a discussion at the meeting is the placement
of the TCs, especially the Adsl2TransmissionModeType. It may be a good
idea to consider putting some or all the TCs into something like an
ADSL-TC MIB module. The primary reason is that they may need to be
adjusted over time. I would expect that it would be faster to turn a TC
MIB module than an ADSL MIB module. For example, I would suspect that
there may be new bits defined for the Adsl2TransmissionModeType as time
goes on.

Hi all,
I'm going to briefly present the attached document to the ADSLMIB working
group at the Minneapolis meeting. It has been submitted as an initial draft
but may have missed the deadline by minutes so it may not be accessible in
the IETF site.
(See attached file: draft-ietf-morgenstern-adsl2-00.txt)
Regards,
Moti Morgenstern
e-mail: Moti.Morgenstern <at> ecitele.com
_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.orghttps://www1.ietf.org/mailman/listinfo/adslmib

Re: A draft adsl2 line MIB

<Moti.Morgenstern <at> ecitele.com>
2005-02-17 20:31:24 GMT

Hi Clay,
You say: "It may be a good idea to consider putting some or all the TCs
into something like an ADSL-TC MIB module." and I absolutely agree.
The reason I included all TC in the same document is because I didn't feel
like creating two initial drafts before the WG review the management model.
Best regards,
Moti Morgenstern
e-mail: Moti.Morgenstern <at> ecitele.com

RE: A draft adsl2 line MIB

I agree
with the sentiment for a separate TC MIB. Precedent was made early on to
separate the IanaIfType MIB from the ifType of the IF-MIB for ease of
maintenance and to allow a different organization to have ownership. Then the
ATM working group broke out its TC so the standard became rfc2514/2515 for the
TC and ATM MIBs.

Let us know when you are ready for comments; I think this version of the draft
is meant to primarily spark a discussion at the IETF meeting.

One thing that may warrant a discussion at the meeting is the placement of the
TCs, especially the Adsl2TransmissionModeType. It may be a good idea to
consider putting some or all the TCs into something like an ADSL-TC MIB
module. The primary reason is that they may need to be adjusted over
time. I would expect that it would be faster to turn a TC MIB module than an
ADSL MIB module. For example, I would suspect that there may be new bits
defined for the Adsl2TransmissionModeType as time goes on.

Re: draft-ietf-adslmib-gshdslbis-08

C. M. Heard <heard <at> pobox.com>
2005-02-23 08:44:28 GMT

On Mon, 21 Feb 2005, Clay Sikes wrote:
[ ... overview of changes snipped ... ]
> Next, I'm asking for two things:
> 1. Look over the changes and make sure I didn't break anything.
> I especially need Bert, Randy, and Mike to review the changes.
All of my review comments seem to have been addressed. I
particularly commend the effort that you put into the Security
Considerations section; it looks like a lot of thought went into
that. The work that you put into the section on notification
throttling is also appreciated. As for the formatting/editorial
changes, it all looks for the better ... I did not see anything
that got broken.
> 2. Before we push this draft any further, I would like to propose
> a significant change to the draft and am looking for anyone
> who thinks the proposal is a bad idea. I would like to break
> out the TCs such that they are in a separate TC-MIB module.
> The reason is that it has taken a lot of time to update this
> MIB module to support G.shdsl.bis. If there needs to be a
> future update, and the annex list is a concern, the change may
> go faster if only a TC Module needs to be updated. This would
> require at least another spin of the draft along with creating
> a dependency. In anyone feels that this a bad idea, please
> let me know. I will not move forward on this if the group
> feels it's a bad idea.
Unfortunately, moving TCs (or other any definitions) to a different
MIB module breaks backward compatibility with any MIB modules
(including, possibly, enterprise MIB modules) that IMPORT those TCs
from HDSL2-SHDSL-LINE-MIB. For this reason, it is usually not
considered acceptable to move definitions from one MIB module to
another. See RFC 2578, Section 10, next-to-last paragraph on p. 37.
Mike

RE: draft-ietf-adslmib-gshdslbis-08

Bob Ray <rray <at> pesa.com>
2005-02-24 13:56:06 GMT

Mike Heard writes:
>Unfortunately, moving TCs (or other any definitions) to a different
>MIB module breaks backward compatibility with any MIB modules
>(including, possibly, enterprise MIB modules) that IMPORT those TCs
>from HDSL2-SHDSL-LINE-MIB. For this reason, it is usually not
>considered acceptable to move definitions from one MIB module to
>another. See RFC 2578, Section 10, next-to-last paragraph on p. 37.
I take the blame for this. The HDSL2 => HDSL2/g.SHDSL => g.SHDSL.bis
is still burdened with my first attempt at an internet draft.
Sorry, Clay.
Bob

Re: draft-ietf-adslmib-gshdslbis-08

Clay Sikes <csikes <at> paradyne.com>
2005-02-28 14:00:08 GMT

Bob,

I hope you don't feel I was trying to put any blame on you or anyone
else. Hindsight is always 20/20.
I was just worried about another spin taking a long time after the
draft becomes a standard. Hopefully that won't happen.

- Clay

Bob Ray wrote:

Mike Heard writes:

Unfortunately, moving TCs (or other any definitions) to a different
MIB module breaks backward compatibility with any MIB modules
(including, possibly, enterprise MIB modules) that IMPORT those TCs

>from HDSL2-SHDSL-LINE-MIB. For this reason, it is usually not

considered acceptable to move definitions from one MIB module to
another. See RFC 2578, Section 10, next-to-last paragraph on p. 37.