Subject: [Adslmib] Comments on Ver 04 of IETF VDSL Draft MIB.

From: "Umberto Bonollo" <[email-masked]>
Date: Fri, 4 Oct 2002 19:32:37 +1000

Hi Bob,
Thanks for your efforts on SHDSL and VDSL.

Some comments on Ver 04 of the MIB:

1. When vdslLineCoding = mcm(),
the variable called vdslMCMConfProfileRowStatus is superfluous as the row
entry for this MCM profile table
can be automatically created when vdslLineConfProfileRowStatus is accessed.
That is, all you need is vdslLineConfProfileRowStatus as any extended
dependent row entries just get created
automatically by the SNMP agent since everything else is determined.

1.1 Recommend just omitting vdslMCMConfProfileRowStatus from the MIB (If you
use another RowStatus
variable like at present and de-couple the extended bit, then you buy into
more complicated management
scenarios for when the extended bit it is "missing").

2. Obviously, these comments would apply to the relevant SCM table used in a
similar way when vdslLineCoding = scm(),
therefore recommend just omitting vdslSCMConfProfileRowStatus from the MIB
for similar reasons just stated.

3. Other usages of RowStatus type variables for optional manager created
components are OK.

Umberto Bonollo ([email-masked])
Senior Computer Scientist
NEC Australia

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

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 8 Oct 2002 14:40:25 -0700 (PDT)

Hi -

> From: "Umberto Bonollo" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Date: Fri, 4 Oct 2002 19:32:37 +1000
> Message-ID: <[email-masked]>
> Subject: [Adslmib] Comments on Ver 04 of IETF VDSL Draft MIB.
...
> automatically by the SNMP agent since everything else is determined.

I think there are some problems with this line of reasoning.
The vdslLineCoding belongs to the vdslLineEntry, indexed
by ifIndex.  As currently written, multiple entries from
this table may reference a given vdslLineConfProfileEntry.
Nothing in the MIB currently constrains them to have the same
vdslLineCoding type, nor does anything in the MIB require
there to be any vdslLineEntry referencing a particular
vdslLineConfProfileEntry when its RowStatus is set to active.
I think the current design is ok, and that attempting to handle
creation of vdslMCMConfProfileEntries as a side effect would
actually *increase* complexity.

BTW., there are some problems with the details of the
current definitions.  I think the description of
vdslLineMCMConfProfileTable needs some work.

Currently, it says:

|vdslLineMCMConfProfileTable OBJECT-TYPE
|        SYNTAX       SEQUENCE OF VdslLineMCMConfProfileEntry
|        MAX-ACCESS   not-accessible
|        STATUS       current
|        DESCRIPTION
|            "This table contains information on the VDSL line
|            configuration.  One entry in this table reflects a
|            profile defined by a manager which can be used to
|            configure the VDSL line.
|
|            This table MUST be implemented for multiple carrier VDSL
|            lines.  This table MUST NOT be implemented for Single
|            carrier VDSL lines."
|        ::= { vdslMibObjects 12 }

Suggestions:
   - refine first paragraph to say that the table contains
     *additional* information on *multiple carrier* vdsl lines
   - the second paragraph is just wrong.  it should talk about
     entries, rather than the table

> scenarios for when the extended bit it is "missing").

As I mentioned above, since the bit that would allow the
decision is in another table with entries in a many-to-one
relationship to these.

> for similar reasons just stated.
...

same problem.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------
_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Umberto Bonollo" <[email-masked]>
Date: Wed, 16 Oct 2002 16:38:47 +1000

Hi Randy, thanks for your comments - the core of what you say is OK:

To Bob Ray (here is the next iteration of my proposal for profiles,
which probably applies to Ver 05 too):

1. To complete my suggestion, of viewing profiles as either MCM/ SCM/ or
Other type,
I needed to/ now propose
we add the following variable called vdslLineConfType
to vdslLineConfProfileTable:

 vdslLineConfType OBJECT-TYPE
        SYNTAX       INTEGER
                     {
                     other(1),
                     mcm(2),
                     scm(3)
                     }
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "Type of VDSL Line Configuration Profile."
        DEFVAL { mcm }

2. Then we don't need vdslMCMConfProfileRowStatus and
vdslSCMConfProfileRowStatus (so we remove them).

3. Now just use vdslLineConfProfileRowStatus with the
appropriate value for vdslLineConfType (or use the default):

3.1 when vdslLineConfType = mcm, agent creates base profile entry and
    MCM related profile objects

3.2 when vdslLineConfType = scm, agent creates base profile entry and
    SCM related profile objects

3.3 when vdslLineConfType = other, agent creates base profile entry only.

4. I don't see what value there is in allowing an scm() line coding line to
reference an mcm() type profile. The MIB agent can actively reject
such strange scenarios.

5. Bob, for SCM and MCM line coding, is it optional that the SCM-specific
and
MCM-specific profile tables can omitted? The current profile solution
implies that the MCM-specific and SCM-specific tables might not have
a row entry created because the Manager didn't access their additional
RowStatus variable.
The above proposal reduces potentially meaningless cases.

6. Finally, should another kind of VDSL coding come along, a future RFC can
simply
add another enum value i.e. type to vdslLineConfType.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Randy Presuhn
Sent: Wednesday, 9 October 2002 7:40
To: [email-masked]
Subject: Re: [Adslmib] Comments on Ver 04 of IETF VDSL Draft MIB.

Hi -

...

Currently, it says:

Suggestions:

...

same problem.

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 16 Oct 2002 17:30:33 -0700 (PDT)

Hi -

> From: "Bob Ray" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>, <[email-masked]>
> Subject: RE: [Adslmib] Comments on Ver 04 of IETF VDSL Draft MIB.
> Date: Wed, 20 Mar 2002 18:30:20 -0600
> Message-ID: <[email-masked]>
> In-Reply-To: <[email-masked]>
> 
> Randy Presuhn writes:
> 
> >This raises a very basic question about this attribute: is it
> >an intrinsic property of the line, or is it something that
> >management can provision / change? 
> 
> In my opinion, one of the two (MCM, SCM) is equivalent to
> Betamax -- only we don't know which one yet.
...

Would it be reading too much into your analogy to conclude
that it does not make sense for this attribute to be read-
write or read-create?  (I don't know of any hardware that
supports both VHS and Betamax.)