Re: FW: Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02. txt

On Mon, 2004-03-29 at 08:24, [email protected] wrote:

> section 2 says:
>    The MIB module is located in the MIB tree under MIB 2 transmission,
>    as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section
>    of this document.
> but this is not how the MODULE-IDENTITY is done, and there is no "MIB-2
> Integration" section!
> >>>>> 
>   Menachem:  I will replace this paragraph by:
> 
>    The MIB module is located in the MIB tree under the vdslMIB, which 
>    in turn is found under MIB 2 transmission, refer to RFC 3728 
>    [RFC3728].
> 
> >>>>>>

Looks accurate to me.  You might consider changing 

	", refer to RFC 3728" 

to

".  The reader is referred to RFC 3728 [RFC3728] for further discussion
of this subject."

> The table of table relationships in section 2.3 doesn't
> quite match up with what the MIB says.  For example,
> the relationship with entries in vdslLineMCMConfProfileTxBandTable
> appears to be 1:(0..n) rather than 1:(0..1), due to the presence of the
> second index, vdslLineMCMConfProfileTxBandNumber.
> Ditto vdslLineMCMConfProfileTxBandTable,
> vdslLineMCMConfProfileTxPSDTable, etc.
> 
> >>>>>>
> 
> 	Menachem: I'll change these to (0..n)
> 

Ok by me.

> 
> >>>>>>
> 
> section 3 says:
>     For MCM VDSL lines, the following group is optional:
>       -  vdslMCMGroup
> This is the only group defined here.  Earlier sections also
> say things like "None, some or all of the objects in this
> group MAY be implemented for MCM VDSL lines."  This seems odd. I can
> understand how implementation of this MIB module might be optional, but
> if someone implements it, surely *something* is required.  As the
> document is currently worded, an implementation that implements none of
> it would seem to be able to claim conformance! Is this what is intended?

This wording is a by-product of splitting one draft into three.
The intent is that a MCM-based VDSL agent does not have to implement
this MIB to be compliant with RFC 3728.


> >>>>>>
> 
> 	Menachem: Replace with : 
> 
> 
>    If the MCM VDSL Line Extension MIB is implemented then all of the
> objects in this group MUST be implemented. 
> 

Which addresses Randy's concern.

> vdslLineMCMConfProfileTable: "The entries in this table MUST NOT be used
> for single carrier (SCM) VDSL lines."  What enforces this constraint?
> 
> >>>>>
> 
> 	Menachem: I will remove this sentence.
> 
> 

Ok by me.

> >>>>>>
> 
> 
> 
> vdslLineMCMConfProfileEntry: "A default profile with an
> index of 'DEFVAL', will always exist" begs the question:
> when there is a vdslLineConfProfileEntry with an index of "DEFVAL", will
> it apply to *both* the MCM and the SCM "DEFVAL" entries?
> 
> 
> >>>>>>
> 
> 	Menachem: I will remove this sentence. As these are optional a
> default value is not necessary.
> 
> >>>>>>

A default vdslLineConfProfileEntry will exist (per RFC 3728).  That
it will apply to both MCM and SCM "DEFVAL" entries is true as it
(vdslLineConfProfileEntry) contains no line code specific objects.

If I rephrase Randy's question, then, perhaps he is asking if a
vdslLineConfProfileEntry may exist that applies to BOTH an
MCM modem and a SCM modem.  To which I answer, heartily, "Yes!".

Further, if an agent implements the MCM MIB, then it MUST have a
'DEFVAL' entry in the vdslLineMCMConfProfileTable.  That this entry
does not apply to SCM modems (or coffee pots for that matter) is not
something I intend to lose sleep over.

That is, Randy is right, although I thought the point was ... obvious.

> 
> Are there any constraints on the values of vdslMCMConfProfileTxBandStart
> and vdslMCMConfProfileTxBandStop? For example, can they overlap with the
> values used in other rows?  What is meant by "validate the profile" (in
> the RowStatus column)? Just this row? Or the whole thing?
> 
> 
> Same questions for *RxBand*.
> 
> 
> >>>>>
> 
> 	Menachem: Bob, what do you suggest ?
> 
> >>>>>
> 

A given MCM line is configured with a band table.  A band table consists
of a collection of rows, each defining a specific band.  

These bands must not overlap.  

To validate a band table entry (vdslLineMCMConfProfileTxBandEntry) then
means to ensure that it makes sense in the context of a profile entry. 

A band must be internally consistent (Stop > Start).

A band must be externally consistent in the context of all bands defined
for that profile.

I think we should add words that state this (to both the Tx and Rx
structures).

> 
> vdslLineMCMConfProfileMaxTxPSDTone: can multiple rows be defined for a
> particular profile with the same value for this column?
> 
> 
> >>>>>
> 
> 	Menachem: Bob, what do you suggest ?
> 
> >>>>>

I have to look that one up...  I think they are distinct.  Maybe someone
else can speak up quickly?

> 
> 
> vdslLineMCMConfProfileTxPSDPSD: UNITS says "dBm" but description says
> "dB", but then says the offset is in units of "dbm/Hz"
> 
> >>>>>>
> 
> 	Menachem: I will change all units to dBm/Hz.
> 
> >>>>>>
> 

Ok.

> 
> 
> vdslLineMCMConfProfileMaxRxPSDTable: same issues as for
> vdslLineMCMConfProfileMaxTxPSDTable.
> 
> 
> For the indexes like vdslLineMCMConfProfileMaxTxPSDNumber,
> is there any significance to the order of the entries in
> a profile?
> 
> >>>>>
> 
> 	Menachem: The order is not significant. Bob, if you agree then
> I'll add a comment stating this.
> 
> >>>>>

Ok.

> 
> 
> 
> For ALL RowStatus objects, please see the "NOTE WELL" on page 8 of RFC
> 2579.  Specifically:
>   - can other columns be modified when a row is active?
> Since the other columns in these tables lack DEFVALs, it
> might also be a good idea to say whether rows can go active
> if these other columns have not yet been set.
> 
> 
> >>>>>
> 
> 	Menachem: Bob, what do you suggest ?
> 
> >>>>>

My opinion is that a row must be internally and externally
consistent (see above) before it can become active.  I don't
think a band table should support being changed "on-the-fly"
(which is what the NOTE WELL is asking us to consider).  That
is, if a line is live using one band table, don't change the
band table.  Either 

a) create a new band table/profile and switch to that one, or
b) disable the line then change the band table/profile.

If everyone else is ok with this, then we just need to say so...

> Section 5: one minor thing to think about is that due to the way in
> which "referenced" profile entries cannot be deleted, a line
> configuration (to which a manager does not have access), by referencing
> a profile, might prevent that manager from modifying the profile,
> particularly if modification of active profiles is prohibited.
> 
> >>>>>
> 
> 	Menachem: Bob, what do you suggest ?
> 
> >>>>>

I think this is just the way it should be.

> 
> 
> Additional Editorial comments:
> RFC 3667 section 5.1 requires an "IPR Disclosure Acknowledgement"
> 
> >>>>>>
> 
> 	Menachem: I'll add this section before the Full Copyright
> Statement:
> 
> 9.  IPR Disclosure Acknowledgement	
> 
>    "By submitting this Internet-Draft, I certify that any applicable
>    patent or other IPR claims of which I am aware have been disclosed,
>    and any of which I become aware will be disclosed, in accordance with
>    RFC 3668."
> 
> >>>>>>>
> 

Sigh.  What a world, eh?

-- 
Bob Ray <[email protected]>