Bob Ray | 7 Feb 16:10 2005

ADSL2 and Minneapolis IETF

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>
Bob Ray | 9 Feb 04:09 2005
Picon

RE: Minneapolis Agenda

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 | 9 Feb 19:58 2005
Picon

Protocol Action: 'Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding' to Proposed Standard

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
(Continue reading)

Moti.Morgenstern | 17 Feb 12:27 2005

A draft adsl2 line MIB


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

Attachment (draft-ietf-morgenstern-adsl2-00.txt): application/octet-stream, 230 KiB
_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib
Clay Sikes | 17 Feb 18:48 2005

Re: A draft adsl2 line MIB

Hi Moti and Menachem,

Thank you for working a MIB for the next generation ADSL!

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.

Best Regards,
Clay Sikes
Paradyne Corp.

Moti.Morgenstern <at> ecitele.com wrote:
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.org https://www1.ietf.org/mailman/listinfo/adslmib
-- Paradyne Mail --
_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib
Moti.Morgenstern | 17 Feb 21:31 2005

Re: A draft adsl2 line MIB


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
PHIL BERGSTRESSER | 18 Feb 00:00 2005

RE: A draft adsl2 line MIB

Clay et al,

 

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.

 

It can be named ADSL-TC without the suffix MIB too.

 

More work to manage it, but useful.

 

Phil

Philip N. Bergstresser

Design Engineer

SNMP Network Management

ADTRAN, Inc.

Huntsville, AL  35806

 

 

 

 

-----Original Message-----
From: adslmib-bounces <at> ietf.org [mailto:adslmib-bounces <at> ietf.org]On Behalf Of Clay Sikes
Sent: Thursday, February 17, 2005 11:49 AM
To: Moti.Morgenstern <at> ecitele.com
Cc: adslmib <at> ietf.org
Subject: Re: [Adslmib] A draft adsl2 line MIB

 

Hi Moti and Menachem,

Thank you for working a MIB for the next generation ADSL!

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.

Best Regards,
Clay Sikes
Paradyne Corp.

 

-- Paradyne Mail --
_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib
C. M. Heard | 23 Feb 09:44 2005
Picon

Re: draft-ietf-adslmib-gshdslbis-08

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
Bob Ray | 24 Feb 14:56 2005

RE: draft-ietf-adslmib-gshdslbis-08

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
Clay Sikes | 28 Feb 15:00 2005

Re: draft-ietf-adslmib-gshdslbis-08

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.
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 _______________________________________________ Adslmib mailing list Adslmib <at> ietf.org https://www1.ietf.org/mailman/listinfo/adslmib
-- Paradyne Mail --
_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib

Gmane