AD review of: draft-ietf-adslmib-vdsl-ext-mcm-04.txt

1. In your sect 2.4 you speak about the expected persistency behaviour.
   That is goodness. You need to say something about thet in all the
   vdslXxxEntry DESCRIPTION clauses of any read-create or read-write 
   tables.

2. RowStatus objects.
   - I see them speak aboput "ouOfService", but such a value does not
     exists, it is "notInService".
   - You need to say if (which) any object can or cannot be changed
     when a row is active.

3. I see
    vdslLineMCMConfProfileTxBandNumber OBJECT-TYPE
        SYNTAX       Unsigned32
   and wonder if a value of zero is valid? In principle we do not like
   index objects to allow for a zero value. If there are good reasons 
   to still allow a zero value, then we prefer to see that explained
   in the DESCRIPTION clause. This comes back a number of times and
   causes these errors/warnings with SMICng:
      C:\bwijnen\smicng\work>smicng vdslmcm.inc
      E: f(vdslmcm.mi2), (185,17) Index item "vdslLineMCMConfProfileTxBandNumber"
         must be defined with syntax that includes a range
      E: f(vdslmcm.mi2), (277,17) Index item "vdslLineMCMConfProfileRxBandNumber"
         must be defined with syntax that includes a range
      E: f(vdslmcm.mi2), (368,17) Index item "vdslLineMCMConfProfileTxPSDNumber"
         must be defined with syntax that includes a range
      E: f(vdslmcm.mi2), (456,17) Index item "vdslLineMCMConfProfileMaxTxPSDNumber"
         must be defined with syntax that includes a range
      E: f(vdslmcm.mi2), (549,17) Index item "vdslLineMCMConfProfileMaxRxPSDNumber"
         must be defined with syntax that includes a range

      *** 6 errors and 6 warnings in parsing

4. I see (a number of times):
            A default profile with an index of 'DEFVAL', will
            always exist and its parameters will be set to vendor
            specific values, unless otherwise specified in this
            document."
   Does that mean that in ech of those tables there will always be an entry
   with an infex of 'DEFVAL' ?? If so, what are the index values of the
   other index objects in that case?  If not, then what does it mean?

5. In the security considerations section, you do not specify the
   writable objects that are sensistive. I guess they all are sensistive.
   But pls explain why. What can happen if unauthorized people fiddle
   with the values or create/delete rows in the tables?

6. I have (in a spearate email) already expressed my concerns over the
   way you assign the OID to the MODULE-IDENTITY. If you want to do it
   this way, we need IANA instructions on how to administer that namespace,
   see my other email.

Nits:
1. The references to RFC3411, RFC3418 and RFC3593 seem to be superfluous.
   There are no citations in the text, so probably they can/should be removed.

2. I hope you are aware that the MODULE-COMPLIANCE statement you have defined
   mandates that everyone MUST implement the first table as read-create table.
   That means, a read-only implementation cannot claim compliance.
   Such is fine, as long as the WG has consensus on that and is aware that 
   that is what you have documented.

admin notes:

when you do a new revision, pls replace front page boilerplate text:
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.
with the new RFC3667/8 boilerplate. I.e. this:
   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.
mmm... I see you sort of have that already. Oh well... I think the
above is what will soon become the requirement.

The abstract has:
  VDSL-LINE-MIB, RFC 3728 [RFC3728], which handles line code
  independent objects.
And RFC-Editor does not want citations in the abstratc.
This can be fixed by: s/ [RFC3728]//

Please add an IANA Considerations section, see www.ietf.org/ID-Checklist.html

Thanks, Bert