Subject: FW: [Adslmib] Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02. txt

From: [email-masked]
Date: Mon, 29 Mar 2004 16:24:50 +0200

Hi Bob,

	Please see in-line, marked by >>>>> my intended changes,
subsequent to Randy's comments. 
I'd like your opinion on these issues. 

	I've handled all the other items raised by Randy's and Bert's
emails.

	Regards,
	Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Presuhn
Sent: Friday, March 26, 2004 4:23 AM
To: [email-masked]
Subject: [Adslmib] Technical comments on
draft-ietf-adslmib-vdsl-ext-mcm-02. txt

Hi -

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

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].

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)

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?

	Menachem: Replace with : 

  The MCM VDSL Line Extension MIB contains the following MIB group:

   o   vdslMCMGroup :

   This group supports MIB objects for defining configuration profiles
   and for montioring individual bands of Multiple Carrier Modulation 
   (MCM) VDSL modems.  It contains the following tables:
   
       - vdslLineMCMConfProfileTable 
       - vdslLineMCMConfProfileTxBandTable
       - vdslLineMCMConfProfileRxBandTable
       - vdslLineMCMConfProfileTxPSDTable 
       - vdslLineMCMConfProfileMaxTxPSDTable 
       - vdslLineMCMConfProfileMaxRxPSDTable 

   If the MCM VDSL Line Extension MIB is implemented then all of the
objects
   in this group MUST be implemented. 

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.

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.

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 ?

vdslLineMCMConfProfileMaxTxPSDTone: can multiple rows be defined for a
particular profile with the same value for this column?

	Menachem: Bob, what do you suggest ?

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.

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.

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 ?

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 ?

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."

The last word of section seven is indented differently from
the rest.  (Another way to look at it is that all of the content of
section seven except the last line is indented one space too far.)

Randy

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

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

---

From: Bob Ray <[email-masked]>
Date: Mon, 29 Mar 2004 10:36:13 -0600

>    in turn is found under MIB 2 transmission, refer to RFC 3728 

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."

> 	Menachem: I'll change these to (0..n)

Ok by me.

> 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.

> objects in this group MUST be implemented. 
> 

Which addresses Randy's concern.

> 	Menachem: I will remove this sentence.

Ok by me.

> 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.

> 	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).

> 	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?

> 	Menachem: I will change all units to dBm/Hz.

Ok.

> I'll add a comment stating this.

Ok.

> 	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...

> 	Menachem: Bob, what do you suggest ?

I think this is just the way it should be.

>    and any of which I become aware will be disclosed, in accordance with

Sigh.  What a world, eh?

-- 
Bob Ray <[email-masked]>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 29 Mar 2004 13:40:38 -0800

Hi -

> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, March 29, 2004 6:24 AM
> Subject: FW: [Adslmib] Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02. txt
...

> Menachem: I will remove this sentence.

This doesn't address the underlyng issue.  What happens when the profile
for an SCM line uses a name that has MCM entries?  My proposal, as someone
who knows nothing about this technology, would be to use words something like this:
"If an entry in this table is referenced by a line which is does not use MCM,
it has no effect on the operation of that line."

...
> default value is not necessary.

Disagree.  The "DEFVAL" row is not a default value; it is a default
profile, which is required to exist in implementations of this MIB module.
The underlying question is whether it is possible / meaningful to
have default profiles for both SCM and MCM lines, and if it is,
whether there would be any problem from them both having the
index of "DEFVAL", since there would be attributes required to
have the same values for both as a consequence of any "shared"
profile configuration tables.

...
> Menachem: I'll add this section before the Full Copyright
...

I'm checking with Scott Bradner to find out whether this is the right place
for it, since it will be removed at RFC time.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 29 Mar 2004 19:56:15 -0800

Hi -

> From: "Randy Presuhn" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, March 29, 2004 1:40 PM
> Subject: Re: [Adslmib] Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02. txt
...
...

According to Scott Bradner, the IPR disclosure acknowledgement belongs
"at the head of the ID", so I'm assuming this means with the other page 1
stuff that goes into internet drafts that gets removed / replaced during
the RFC publication process.

Randy