RE: SCM MIB

Pls not too many ????? marks in the subject line. I easily discard such emails
(too much SPAM coming with that attribute).
 
W.r.t. the ranges.... as long as you (and the WG) are sure that they mak sense, then fine.
 
Looking forward to new rev on Monday
 
Bert
 
 
 -----Original Message-----
From: Menachem Dodge [mailto:[email protected]]
Sent: Thursday, January 13, 2005 21:07
To: Wijnen, Bert (Bert); Randy Presuhn; Adslmib (E-mail)
Cc: [email protected]; Michael Sneed
Subject:  ??????  SCM MIB



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  <mailto:[email protected]> (Bert) 
To: Menachem Dodge <mailto:[email protected]>  ; Randy Presuhn <mailto:[email protected]>  ; Adslmib (E-mail) <mailto:[email protected]>  
Cc: [email protected] <mailto:[email protected]>  ; Michael  <mailto:[email protected]> 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/ <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 <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>  :
 
  - 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] <mailto:[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 <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