Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding
draft-ietf-adslmib-vdsl-ext-mcm-06

[Ballot comment] Reviewed by Mary Barnes, Gen-ART Summary: ---------- Drafts are ready to publish as Proposed Standard, with the assumption being that they've been run ...

[Ballot comment]
Reviewed by Mary Barnes, Gen-ART

Summary:
----------
Drafts are ready to publish as Proposed Standard, with the assumption
being that they've been run through the appropriate MIB validation
tools. See a few minor nits below.

Nits (applicable to both drafts):
----------------------------------
- Global - many of the left `single quotes' are angled, whereas the
  right ones are straight up and down. 

- Section 2.2.1 - Remove "(VTUC)" and "(VTUR)" from Vtuc and Vtur
  definitions. The acronym isn't defined anywhere, nor is it defined
  in RFC 3728, so having those terms preface the definitions adds no
  value and implies that Vtuc and Vtur have meaning beyond what's
  listed in the naming conventions. OR, "VTUC" and "VTUR" need to be
  expanded/defined.

- Section 4 - Contact-Info - Do the chairs need to be listed? I've
  not seen that done for other MIBs in other areas (but, I'm not a
  MIB expert). If they are going to be listed, I don't see why Bob
  needs to be listed twice. Why not just label him as
  "Co-chair/co-editor"?



Nits (draft-ietf-adslmib-vdsl-ext-scm-01.txt):
-----------------------------------------------
- Copyright date should be 2005.

IANA Last Call Comments: Upon approval of this document the IANA will assign a transmission number for vdslExtMCMMIB. Number 228 was suggested, however at the ...

IANA Last Call Comments:
Upon approval of this document the IANA will assign a transmission number for vdslExtMCMMIB. Number 228 was suggested, however at the point of approval the IANA will assign the next available number in the registry.

AD review posted -----Original Message----- From: Wijnen, Bert (Bert) Sent: Wednesday, January 12, 2005 16:41 To: 'Menachem Dodge'; Adslmib (E-mail) Cc: Michael Sneed; rray ...

AD review posted
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Wednesday, January 12, 2005 16:41
To: 'Menachem Dodge'; Adslmib (E-mail)
Cc: Michael Sneed; rray@pesa.com
Subject: RE: Submission of LCS MIB draft


IDNITS tool says: cool:
----------
$ idnits draft-ietf-adslmib-vdsl-ext-mcm-05.txt
idnits 1.58

draft-ietf-adslmib-vdsl-ext-mcm-05.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3667/3668 boilerplate...
    the boilerplate looks good.
    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of 1id-guidelines.txt yet).

  Miscellaneous warnings:

    None.

    No nits found.
------------

SMICng tells me:
C:wijnensmicngwork>smicng vdslmcm.inc
W: f(vdslmcm.mi2), (11,5) "ifIndex" imported but not used
----------

vdslLineMCMConfProfileTable in DESCRIPTION clause states:
          All read-create objects defined in this MIB module SHOULD be
          stored persistently."
You probably mean "All read-create-objects defined in this table..."

Same for: vdslLineMCMConfProfileTxBandTable and vdslLineMCMConfProfileRxBandTable
  and vdslLineMCMConfProfileTxPSDTable and vdslLineMCMConfProfileMaxTxPSDTable
  in fact for all tables it seems

---------
Question:
    vdslLineMCMConfProfileTxWindowLength OBJECT-TYPE
        SYNTAX      Unsigned32 (1..255)

will that range ever byet us in the future? Just wondering/asking.

Similar questions or some of the other ranges specified in this MIB module.
As long as we know what we (as a WG) are doing, then I am fine with it.

-----------
I do not understand:
    vdslLineExtMCMMibCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
            "The compliance statement for SNMP entities which
            manage VDSL interfaces."
        MODULE  -- this module
        GROUP      vdslLineExtMCMGroup
        DESCRIPTION
            "This group is an optional extension for VDSL lines which
            utilize Multiple Carrier Modulation (MCM)."
        ::= { vdslLineExtMCMCompliances 1 }

I Understand this whole MIB module is optional, So I would assume if someone does not
implement it then they do not claim compliance.
But what does it mean if you claim compliance and there is only a single group and
that group is optional. Does this mean you can claim compliance and not implement anything?
I think I would make the single group MANDATORY. If you claim compliance then you MUST
implement that one and only group.
Makes sense?
You did so in the SCM module (which makes sense to me)

-----------
6.  Security Considerations

  There are a number of management objects defined in this MIB module
  with a MAX-ACCESS clause of read-create.  Such objects may be
  considered sensitive or vulnerable in some network environments.
  The support for SET operations in a non-secure environment without
  proper protection can have a negative effect on network operations.
  These are the tables and objects and their sensitivity/vulnerability:

                vdslLineMCMConfProfileTable,
                vdslLineMCMConfProfileTxWindowLength,
                ... more in teh list ...

But where does it describe what the vulnerability is? What would happen if someone
gets write access while not authorized. What are the risks?
I guess it is there, but I am just confused by seeing this para first:

  Some of the readable objects in this MIB module (i.e., objects with a
  MAX-ACCESS other than not-accessible) may be considered sensitive or
  vulnerable in some network environments.

There are no read-only objects, but the writable objects of course are also readable,
so we do want to understand what vulnerabilities (if any) there are for unauthorized
reading. I don't think I see any words on that, do I

Bert

-----Original Message----- From: Wijnen, Bert (Bert) Sent: Saturday, September 04, 2004 16:15 To: Adslmib (E-mail) Subject: AD review of: draft-ietf-adslmib-vdsl-ext-mcm-04.txt 1. In your ...

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Saturday, September 04, 2004 16:15
To: Adslmib (E-mail)
Subject: 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:wijnensmicngwork>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