Subject: [Adslmib] Proposed changes to draft ADSL2 MIB

From: Scott Andrew Baillie <[email-masked]>
Date: Thu, 16 Jun 2005 18:35:20 +1000

Dear Bob, Moti and Menachem (& List),
As fellow co-editors,
please find attached our proposed changes
to draft-morgenstern-ngadsl-mib-00.txt as a
stepping stone towards Version "01".

There are two attached files:
1. DRAFT-ADSL2-MIB is our proposed changes
to Version "00", which upgrades the MIB file in
draft-morgenstern-ngadsl-mib-00.txt with
numerous substantive changes,
whilst retaining the character
of the previous contribution.

2. ChangesMade.txt describes the changes
we made in DRAFT-ADSL2-MIB and the
rationale for each change.

Please feel free to discuss.

Yours Sincerely,
Scott Baillie ([email-masked])
NEC Australia
&
Umberto Bonollo ([email-masked])
NEC Australia

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

---

From: "Ray, Robert" <[email-masked]>
Date: Wed, 22 Jun 2005 14:35:57 -0500

Editors:

Do you plan to use the xml2rfc tool at http://xml.resource.org/?

The RFC Editor really likes us to use this.  Clay Sikes, author of
http://www.ietf.org/internet-drafts/draft-ietf-adslmib-gshdslbis-11.txt,
has experience with this tool having written the g.shdslbis draft in
XML.  
 
Bob Ray

---

From: [email-masked]
Date: Thu, 23 Jun 2005 17:46:00 +0300

Hi Scott, Umberto and WG members,

Thanks you for joining the "task force".
Menachem and I reviewed your proposed changes.
Attached please find a per proposed change response.
We agreed to some of the proposed changes/enhancements.
However, we disagree on several changes and need
further clarifications regarding others.
(See attached file: response to Baillie and Bonollo 050623.txt)
We also would appreciate input from other members.

Best Regards,
Moti Morgenstern & Menachem Dodge
ECI Telecom Ltd.
Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49517
Tel.: +972-3-9266258/9268421
Fax: +972-3-9287342
www.ecitele.com
_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: [email-masked]
Date: Sun, 26 Jun 2005 18:03:14 +0300

Hello Clay,

      Thank you kindly for your email and the attached xml file and your
offer for help.
Moti and I, will begin putting the ADSL2 draft into the XML format and I'm
sure your experience will be
very useful if we run into any hitches. Any tips that you may have, would
be most welcome.

Best Regards,
Menachem Dodge
ECI Telecom Ltd.

Tel:      +972-3-9268421
Mobile: +972-54-5788421
Fax:      +972-3-9287342

---

From: "Ray, Robert" <[email-masked]>
Date: Wed, 29 Jun 2005 07:43:25 -0500

In reviewing the suggestions from Scott and Umberto along with Moti and
Menachem's responses, I agree with the summary Moti last sent with the
exception of the following:

>Change 5
>--------
>Description of change:
>  Merge the contents of the tables :
>  adsl2LineStatusTable,
>  adsl2LineCommandTable,
>  adsl2LineConfigTable
>  into one single table ( adsl2LineTable ).
>
>Our Response:
>  The reason we separated the configuration parameters from the status
>  parameters and the commands is for clarity of the management model. 
>  It's not that a single table cannot include a mixture of read-write 
>  and read-only objects, as long as they refer to the same category 
>  (e.g., Obviously one expects to see the command result located 
>  at the same table where the command resides.) 
>  At first glance the proposed merge seems harmless. Initially the 
>  status parameters are located in the beginning of the table. Then
come
>  the command related parameters and finally the configuration
parameters. 
>  However, assume we need to update the MIB with a new status
parameter. 
>  This parameter would need to be appended at the end of the table (for
>  backward compatibility reason) and that greatly reduces the clarity
of
>  the MIB. 
>  Also we failed to understand why is it important that "some of the
old 
>  tables were really quite small".

I disagree with Moti's assertion that they should be separated for
clarity.  Logically, if they belong in one table (i.e. there are no
candidate keys, no repeating fields, etc.), then they belong in one
table.  

Whether a table is "small" or "large" is of no consequence as long as it
is logically consistent.

-- Just my opinion.

Bob Ray