Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the Yes position for Bert Wijnen
2005-05-18
06 (System) This was part of a ballot set with: draft-ietf-adslmib-vdsl-ext-scm
2005-02-10
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-02-09
06 Amy Vezza IESG state changed to Approved-announcement sent
2005-02-09
06 Amy Vezza IESG has approved the document
2005-02-09
06 Amy Vezza Closed "Approve" ballot
2005-02-08
06 Bert Wijnen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen
2005-02-08
06 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to Yes from Discuss by Bert Wijnen
2005-02-04
06 (System) Removed from agenda for telechat - 2005-02-03
2005-02-03
06 Amy Vezza State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead by Amy Vezza
2005-02-03
06 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Amy Vezza
2005-02-03
06 Bert Wijnen [Ballot discuss]
I need to check if the comments warrant an update or some
RFC-Editor note
2005-02-03
06 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to Discuss from Yes by Bert Wijnen
2005-02-03
06 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2005-02-03
06 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-02-03
06 Harald Alvestrand
[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.
2005-02-03
06 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2005-02-03
06 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-02-03
06 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-02-03
06 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-02-02
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2005-02-02
06 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-02-02
06 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-01-31
06 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2005-01-31
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-01-31
06 Michelle Cotton
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.
2005-01-31
06 Scott Hollenbeck
[Ballot comment]
Last call hasn't finished yet, but I may be offline before the telechat on the 3rd.  I'm entering a no-ob now based on …
[Ballot comment]
Last call hasn't finished yet, but I may be offline before the telechat on the 3rd.  I'm entering a no-ob now based on my current reading of the documents.
2005-01-31
06 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-01-27
06 Bert Wijnen Placed on agenda for telechat - 2005-02-03 by Bert Wijnen
2005-01-27
06 Bert Wijnen Status date has been changed to 2005-01-27 from 2005-01-12
2005-01-27
06 Bert Wijnen [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen
2005-01-27
06 Bert Wijnen Ballot has been issued by Bert Wijnen
2005-01-27
06 Bert Wijnen Created "Approve" ballot
2005-01-19
06 Amy Vezza Last call sent
2005-01-19
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-01-19
06 Bert Wijnen State Changes to Last Call Requested from AD Evaluation::AD Followup by Bert Wijnen
2005-01-19
06 Bert Wijnen Last Call was requested by Bert Wijnen
2005-01-19
06 (System) Ballot writeup text was added
2005-01-19
06 (System) Last call text was added
2005-01-19
06 (System) Ballot approval text was added
2005-01-17
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-01-17
06 (System) New version available: draft-ietf-adslmib-vdsl-ext-mcm-06.txt
2005-01-12
06 Bert Wijnen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Bert Wijnen
2005-01-12
06 Bert Wijnen
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: …
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
2005-01-12
06 Bert Wijnen
2005-01-12
06 Bert Wijnen Status date has been changed to 2005-01-12 from 2004-09-04
2004-12-20
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-12-20
05 (System) New version available: draft-ietf-adslmib-vdsl-ext-mcm-05.txt
2004-09-04
06 Bert Wijnen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Bert Wijnen
2004-09-04
06 Bert Wijnen
-----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 …
-----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
2004-09-04
06 Bert Wijnen Status date has been changed to 2004-09-04 from 2004-07-20
2004-07-20
06 Bert Wijnen State Changes to AD Evaluation from Publication Requested by Bert Wijnen
2004-07-20
06 Bert Wijnen Status date has been changed to 2004-07-20 from
2004-06-02
04 (System) New version available: draft-ietf-adslmib-vdsl-ext-mcm-04.txt
2004-05-18
06 Dinara Suleymanova Draft Added by Dinara Suleymanova
2004-04-06
03 (System) New version available: draft-ietf-adslmib-vdsl-ext-mcm-03.txt
2004-03-17
02 (System) New version available: draft-ietf-adslmib-vdsl-ext-mcm-02.txt
2004-02-16
01 (System) New version available: draft-ietf-adslmib-vdsl-ext-mcm-01.txt
2003-09-24
00 (System) New version available: draft-ietf-adslmib-vdsl-ext-mcm-00.txt