Skip to main content

Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding
RFC 4069

Revision differences

Document history

Date Rev. By Action
2021-04-15
08 (System) Received changes through RFC Editor sync (added Errata tag)
2015-10-14
08 (System)
2012-08-22
08 (System) post-migration administrative database adjustment to the Yes position for Bert Wijnen
2005-05-18
08 (System) This was part of a ballot set with: draft-ietf-adslmib-vdsl-ext-mcm
2005-05-18
08 Amy Vezza [Note]: 'RFC 4069' added by Amy Vezza
2005-05-18
08 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-05-09
08 (System) RFC published
2005-02-10
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-02-09
08 Amy Vezza IESG state changed to Approved-announcement sent
2005-02-09
08 Amy Vezza IESG has approved the document
2005-02-09
08 Amy Vezza Closed "Approve" ballot
2005-02-08
08 Bert Wijnen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen
2005-02-08
08 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to Yes from Discuss by Bert Wijnen
2005-02-04
08 (System) Removed from agenda for telechat - 2005-02-03
2005-02-03
08 Amy Vezza State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead by Amy Vezza
2005-02-03
08 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Amy Vezza
2005-02-03
08 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to Discuss from Yes by Bert Wijnen
2005-02-03
08 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2005-02-03
08 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-02-03
08 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2005-02-03
08 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-02-03
08 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-02-03
08 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-02-02
08 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2005-02-02
08 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-02-02
08 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-01-31
08 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2005-01-31
08 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-01-31
08 Michelle Cotton
IANA Last Call Comments:
Upon approval of this document the IANA will assign a transmission number for vdslExtSCMMIB.  Number 227 was suggested, however this has …
IANA Last Call Comments:
Upon approval of this document the IANA will assign a transmission number for vdslExtSCMMIB.  Number 227 was suggested, however this has since been assigned.  At the point of approval the IANA will assign the next available number.
2005-01-31
08 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-01-27
08 Bert Wijnen Placed on agenda for telechat - 2005-02-03 by Bert Wijnen
2005-01-27
08 Bert Wijnen [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen
2005-01-27
08 Bert Wijnen Ballot has been issued by Bert Wijnen
2005-01-27
08 Bert Wijnen Created "Approve" ballot
2005-01-19
08 Amy Vezza Last call sent
2005-01-19
08 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-01-19
08 Bert Wijnen State Changes to Last Call Requested from AD Evaluation::AD Followup by Bert Wijnen
2005-01-19
08 Bert Wijnen Last Call was requested by Bert Wijnen
2005-01-19
08 (System) Ballot writeup text was added
2005-01-19
08 (System) Last call text was added
2005-01-19
08 (System) Ballot approval text was added
2005-01-19
08 Bert Wijnen Merged with draft-ietf-adslmib-vdsl-ext-mcm by Bert Wijnen
2005-01-17
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-01-17
08 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-08.txt
2005-01-12
08 Bert Wijnen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Bert Wijnen
2005-01-12
08 Bert Wijnen
AD review comments:
-----Original Message-----
From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org]On Behalf Of Wijnen, Bert (Bert)
Sent: Wednesday, January 12, 2005 16:16
To: Menachem Dodge; Randy …
AD review comments:
-----Original Message-----
From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org]On Behalf Of Wijnen, Bert (Bert)
Sent: Wednesday, January 12, 2005 16:16
To: Menachem Dodge; Randy Presuhn; Adslmib (E-mail)
Cc: Michael Sneed; rray@pesa.com
Subject: [Adslmib] RE: SCM MIB


Sorry that it took so long to look at this.
However... there are still errors that prevent even a basic SYNTAX check.
It is caused by formatting issues.

SMICng tells me:

      C:?wijnensmicngwork>smicng vdslscm.inc 
      W: f(vdslscm.mi2), (308,1) Name of item "eSCMPhysBandCurrConstellationSize"
          must start with uppercase letter
          Item name changed to "ESCMPhysBandCurrConstellationSize"
      E: f(vdslscm.mi2), (308,35) Syntax error
      E: f(vdslscm.mi2), (312,13) Syntax for a SEQUENCE definition is
          "::=" "SEQUENCE" "{"
            [","]... "}"

This is caused by wierd formatting on page 10. And for no good reason as far as I can tell.

page 7 (lines 7/8) have weird formatting to, but are syntactically correct
page 14 also has that wierd formatting on one line. (I can deal with that).

IDNITS tool (available at: http://ietf.levkowetz.com/tools/idnits/)  tells me:
----
$ idnits draft-ietf-adslmib-vdsl-ext-scm-07.txt
idnits 1.58

draft-ietf-adslmib-vdsl-ext-scm-07.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 :

  - The page length should not exceed 58 lines per page, but there was 1 longer page, the
    longest (page 14) being 75 lines
  - It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages

  Miscellaneous warnings:

    None.

    No nits found.
---

So at the next revision, pls try to address the length of page 14.

---

I can live with: VdslSCMBandUsage
But wonder if  the objects that use this SYNTAX could not just be of syntax TruthValue
(for example):
  vdslLineSCMConfProfileBandUsage OBJECT-TYPE
        SYNTAX      VdslSCMBandUsage
could be:
  vdslLineSCMConfProfileBandInUse OBJECT-TYPE
        SYNTAX      TruthValue
Of course you would have to IMPORT TruthValue from RFC2579. But it would be re-using an existing
TC/SYNTAX, which I think is goodness. It is not a blocking comment though.

-----
When I see:
    vdslLineSCMConfProfileBandId OBJECT-TYPE
        SYNTAX      VdslSCMBandId
        MAX-ACCESS  not-accessible
        STATUS  current
        DESCRIPTION
          "The BandId for this entry, which specifies which band
          is being referred to.  Specified as an INTEGER, the
          possible values are:
          optionalBand (1), firstDownstreamBand (2),
          firstUpstreamBand (3), secondDownstreamBand (4),
          secondUpstreamBand (5), thirdDownstreamBand (6),
          thirdUpstreamBand (7)"
The Would say that only the 1st sentence of the DESCRIPTION clause is needed.
The reason why you use a TC is so that you do not have to repeat the same text multiple times.
Also, if an enumeration is ever added in the future, you would only have to update
the TC and not all DESCRIPTION clauses for the change.
I can live with it, but it seems redundant and may bite back in future.

-----

SAme remark for:
    vdslLineSCMPhysBandId OBJECT-TYPE
        SYNTAX      VdslSCMBandId
        MAX-ACCESS  not-accessible
        STATUS  current
        DESCRIPTION
            "The BandId for this entry, which specifies which band
            is being referred to.  Specified as an Unsigned32, the
            possible values are:
            optionalBand (1), firstDownstreamBand (2),
            firstUpstreamBand (3), secondDownstreamBand (4),
            secondUpstreamBand (5), thirdDownstreamBand (6),
            thirdUpstreamBand (7)"

With the addition that in any event "Unsigned32" is incorrect!

---------
Question:

    vdslLineSCMPhysBandCurrConstellationSize OBJECT-TYPE
        SYNTAX      Unsigned32 (0..16)

is that a reasonable RANGE? Will we not be exposed (in the future) to possibly bigger size,
in which case we would have to make incompatible change? WOuld it be better to hav no
range here and do a range in the MODULE-COMPLIANCE, so that future extension can be more
easily accomodated? Just wondering and making sure we do this consciously.

Bert
2005-01-12
08 Bert Wijnen Status date has been changed to 2005-01-12 from 2004-10-27
2004-11-15
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-11-15
07 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-07.txt
2004-10-27
08 Bert Wijnen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Bert Wijnen
2004-10-27
08 Bert Wijnen
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Wednesday, October 27, 2004 14:31
To: Menachem Dodge
Cc: Adslmib (E-mail); Michael Sneed; rray@pesa.com
Subject: RE: [Adslmib] RE: …
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Wednesday, October 27, 2004 14:31
To: Menachem Dodge
Cc: Adslmib (E-mail); Michael Sneed; rray@pesa.com
Subject: RE: [Adslmib] RE: draft-ietf-adslmib-vdsl-ext-scm-06


Here is my review (a bit later than I had hoped/promised):

SMICng tells me now:
  E: f(vdslscm.mi2), (1,1) Construct "TEXTUAL-CONVENTION" used
    in VDSL-LINE-EXT-SCM-MIB, but not defined or imported

You must IMPORT the TEXTUAL -CONVENTION

  E: f(vdslscm.mi2), (82,11) Leading sub-Id "transmission" is
    not known in current module

You must IMPORT transmission

  E: f(vdslscm.mi2), (431,17) Item "vdslLineSCMConfProfileBandId"
    in object-group "vdslLineExtSCMGroup" has access of
    "not-accessible"

normally, not-accessible objecst should not be losted in an object group


  W: f(vdslscm.mi2), (13,5) "vdslMIB" imported but not used

You no longer should IMPORT vdslMIB if not used.

Pls fix syntax errors first.

You can extract the MIB and send it to smilint@ibr.cs.tu-bs.de
which will then send back a SYNTAX report.
For help, just send subjectline help to smilint@ibr.cs.tu-bs.de

Bert
2004-10-27
08 Bert Wijnen Status date has been changed to 2004-10-27 from 2004-09-03
2004-10-18
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-10-18
06 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-06.txt
2004-09-03
08 Bert Wijnen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Bert Wijnen
2004-09-03
08 Bert Wijnen
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, September 03, 2004 22:46
To: Adslmib (E-mail)
Subject: [Adslmib] AD review of: draft-ietf-adslmib-vdsl-ext-scm-05.txt


OK …
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, September 03, 2004 22:46
To: Adslmib (E-mail)
Subject: [Adslmib] AD review of: draft-ietf-adslmib-vdsl-ext-scm-05.txt


OK here are my other review comments:

Serious issues

1. The SMICng compilation/syntax issues I reported earlier.
  - must use INTEGER for enumartions, not Unsigned32.
  - must use Unsigned32, not unsigned32
  - index item "vdslLineSCMConfProfileBandId" must be not-accessible

2. I see:
  vdslLineSCMConfProfileBandUsage OBJECT-TYPE
        SYNTAX      Unsigned32
        MAX-ACCESS  read-create
        STATUS  current
        DESCRIPTION
          "Indicates whether this band is in use.
          Specified as an Unsigned32, the two
          possible values are:
          Unused(1),
          InUse(2)"
        ::= { vdslLineSCMConfProfileBandEntry 2 }
  Seems to me you would rather do that as an enumeration, using INTEGER
  don't you think so?

3. I see:
    vdslLineSCMConfProfileBandRowStatus OBJECT-TYPE
        SYNTAX      RowStatus
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
          "This object is used to create a new row or modify or
          delete an existing row in this table.

          A profile activated by setting this object to `active'.
  s/profile/profile is/
          When `active' is set, the system will validate the profile.

          Before a profile can be deleted or taken out of
          service, (by setting this object to `destroy' or
          `outOfService') it must be first unreferenced
  s/outOfService/notInService/
          from all associated lines."
      ::= { vdslLineSCMConfProfileBandEntry 7 }
 
  The RowStatus TC does not have a value of outOfService but it does
  have a notInService value.
  You MUST describe in this DESCRIPTIOON clause if any coluns in the
  row can or cannot be changed while the row is in active state.

4. For table: vdslLineSCMConfProfileBandTable
  I see not text about the persistency of that table.
  Either there needs to be a StorageType column or you must describe
  in the DESCRIPTION clause of the Table or Entry what the persistence
  behaviour is. I see that in sect 2.4 you state that the entries MUST
  be persistent. So This issue can be fixed by putting similar text
  in the DESCRIPTION clause of vdslLineSCMConfProfileBandEntry

5. vdslLineSCMPhysBandUsage
  should probably be an enumeration (INTEGER as base type).
  WOuld it make sense to do a TC cause you are using it twice?

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. vdslLineSCMConfProfileBandId
    ....
        DESCRIPTION
          "The BandId for this entry, which specifies which band
          is being referred to.  Specified as an Unsigned32, the five
          possible values are:
  and then you go on to list 7 instead of 5.
  How about s/five//
  I already pointed out in an earlier email that enumerations must
  be done with a bse type of INTEGER, so also s/Unsigned32/INTEGER/
  or may be better: s/Unsigned32/enumeration/

2. I also mentioned that the 2 enumerations for BandId might be better
  done as a TC. And I also wonder if BandId is a good name.
  to me it sounds more like a BandType, But this may be just personal
  taste, so telling me so and to shut up is fine.

3. vdslLineSCMPhysBandTable
  DESCRIPTION clause talks about 5 bands again while you have enumerated 7.

4. 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.

5. It seems that reference [RFC3593] can/should be removed. It is not cited
  anywhere and I do not understand why it is here.

6. It seems there are no citations to RFC3411 and RFC3418, so probably there
    do not need to be references to them either.

admin notes:

when you do a ner 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.

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


Thanks, Bert
2004-09-03
08 Bert Wijnen Status date has been changed to 2004-09-03 from 2004-07-20
2004-07-20
08 Bert Wijnen State Changes to AD Evaluation from Publication Requested by Bert Wijnen
2004-07-20
08 Bert Wijnen Status date has been changed to 2004-07-20 from
2004-06-14
05 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-05.txt
2004-06-02
04 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-04.txt
2004-05-18
08 Dinara Suleymanova Draft Added by Dinara Suleymanova
2004-04-06
03 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-03.txt
2004-03-22
02 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-02.txt
2004-02-16
01 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-01.txt
2003-09-24
00 (System) New version available: draft-ietf-adslmib-vdsl-ext-scm-00.txt