=?windows-1255?b?4fLw6envOiBTQ00gTUlC?=

"Menachem Dodge" <[email protected]> Thu, 13 Jan 2005 22:07:16 +0200

Newsgroups	gmane.ietf.adslmib
Message-ID	<001201c4f9ab$7b365a60$351d19ac@dodge>

Hello Bert,

It seems that the file has somehow been corrupted so I will fix these broken lines and pages
and also the other issues of the BandUsage and BandId Descriptions.

Regarding the vdslLineSCMPhysBandCurrConstellationSize, as the constellation is increased
the Signal to Noise Ratio decreases. With a value of 14 the Signal is basically down to the noise
level so values of 15 and 16 are for future proof. Therefore I propose keeping the range at 16.

Hopefully I can have this done by Monday.

Menachem.

----- Original Message -----
From: Wijnen, Bert (Bert)
To: Menachem Dodge ; Randy Presuhn ; Adslmib (E-mail)
Cc: [email protected] ; Michael Sneed
Sent: Wednesday, January 12, 2005 5:16 PM
Subject: 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:\bwijnen\smicng\work>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
<seqName> "::=" "SEQUENCE" "{"
<seqItem> [","<seqItem>]... "}"

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

-----Original Message-----
From: Menachem Dodge [mailto:[email protected]]
Sent: Tuesday, November 16, 2004 23:27
To: Randy Presuhn; Adslmib (E-mail); Wijnen, Bert (Bert)
Cc: [email protected]; Michael Sneed
Subject: SCM MIB

Hello All,

I would like to thank both Bert and Randy for their comments on the SCM MIB.

I have posted the draft draft-ietf-adslmib-vdsl-ext-scm-07 with the changes that Bert and Randy have suggested.

The following changes have been made:

1. TEXTUAL_CONVENTION has been imported.
2. transmission has been imported.
3. VDSL_MIB is no longer imported.
4. vdslLineSCMPhysBandId is set to not_accessible.
5. I have extracted and sent the MIB to to [email protected]
6. Request transmission 227 instead of 98 which is in use.
7. Made the necessary spacing changes as suggested by Randy.
8. Changed the security section according to the Boiler plate at http://www.ops.ietf.org/mib-security.html
9. Modified the acknowledgement section.

Regards,

Menachem.

_______________________________________________
Adslmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/adslmib