[Adslmib] RE: Submission of LCS MIB draft

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Wed, 12 January 2005 15:50 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23509 for <adslmib-web-archive@ietf.org>; Wed, 12 Jan 2005 10:50:19 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CokzK-0000Vg-IM for adslmib-web-archive@ietf.org; Wed, 12 Jan 2005 11:04:52 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CokgP-0003xc-Ac; Wed, 12 Jan 2005 10:45:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cokcf-0003BU-F0 for adslmib@megatron.ietf.org; Wed, 12 Jan 2005 10:41:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22865 for <adslmib@ietf.org>; Wed, 12 Jan 2005 10:41:23 -0500 (EST)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cokqe-0000Hy-JF for adslmib@ietf.org; Wed, 12 Jan 2005 10:55:56 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0CFfH9L008985 for <adslmib@ietf.org>; Wed, 12 Jan 2005 09:41:18 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <ZXP4S3HC>; Wed, 12 Jan 2005 16:41:16 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155062BE558@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Menachem Dodge <mhdo@zahav.net.il>, "Adslmib (E-mail)" <adslmib@ietf.org>
Date: Wed, 12 Jan 2005 16:41:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 1.9 (+)
X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b
Cc: Michael Sneed <sneedmike@hotmail.com>, rray@pesa.com
Subject: [Adslmib] RE: Submission of LCS MIB draft
X-BeenThere: adslmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ADSLMIB <adslmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/adslmib>, <mailto:adslmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:adslmib@ietf.org>
List-Help: <mailto:adslmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/adslmib>, <mailto:adslmib-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1258513576=="
Sender: adslmib-bounces@ietf.org
Errors-To: adslmib-bounces@ietf.org
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b

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 <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 <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:\bwijnen\smicng\work>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: Menachem Dodge [mailto:mhdo@zahav.net.il]
Sent: Sunday, December 19, 2004 23:13
To: internet-drafts@ietf.org
Cc: Michael Sneed; rray@pesa.com; Wijnen, Bert (Bert)
Subject: Submission of LCS MIB draft


  
Dear Sir/Madam, 
 
 
    I would like to submit the draft: draft-ietf-adslmib-vdsl-ext-mcm-05.txt.
 
    Please find the document attached.
 
    Kindest Regards,
 
    Menachem Dodge.
 
 
 

_______________________________________________
Adslmib mailing list
Adslmib@ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib