RE: Proposed changes to draft ADSL2 MIB

"Ray, Robert" <[email protected]>
Newsgroups gmane.ietf.adslmib
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.