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

[[e-mail]]

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Randy Presuhn
Sent: Friday, March 26, 2004 4:23 AM
To: [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/adslmib

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