Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding
draft-ietf-adslmib-vdsl-ext-scm-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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-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 |