headers
Michael Sneed | 4 Jan 2005 16:55
Picon
Favicon

FW: DSL Forum Liaison

Please see the attached liason from the DSL Forum.  The question now is, 
should this WG undertake work to generate MIBs for this.

Should anyone not be able to read .doc or .pdf files, please contact me and 
I'll attempt to convert to some readable format.

>From: "Peter Adams" <p.f.adams <at> btopenworld.com>
>To: <sneedmike <at> hotmail.com>,<rray <at> pesa.com>
>Subject: DSL Forum Liaison
>Date: Tue, 4 Jan 2005 14:34:37 -0000
>
>Dear Mike and Bob,
>
>Following the completion of work on ADSL2 network element management at the 
>Orlando meeting (6 to 9 Dec 2004) of the DSL Forum there is attached a 
>liaison and a technical report.
>
>Best regards,
>
>
>Peter Adams
>
>DSL Forum Operations and Network Management Working Group Chair
Attachment (LiaisonIETF.doc): application/msword, 47 KiB
Attachment (TR-090.pdf): application/pdf, 92 KiB
_______________________________________________
Adslmib mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Faye Ly | 4 Jan 2005 19:14
Favicon

RE: FW: DSL Forum Liaison

Mike,

I think a MIB is definitely needed as new flavors of ADSL are being
deployed.  I would recommend keep this new MIB as close as the existing
RFC 2662 as possible to maintain the consistency and make the EMS's job
easier.

Best,

-faye

-----Original Message-----
From: adslmib-bounces <at> ietf.org [mailto:adslmib-bounces <at> ietf.org] On
Behalf Of Michael Sneed
Sent: Tuesday, January 04, 2005 7:56 AM
To: adslmib <at> ietf.org
Subject: [Adslmib] FW: DSL Forum Liaison

Please see the attached liason from the DSL Forum.  The question now is,

should this WG undertake work to generate MIBs for this.

Should anyone not be able to read .doc or .pdf files, please contact me
and 
I'll attempt to convert to some readable format.

>From: "Peter Adams" <p.f.adams <at> btopenworld.com>
>To: <sneedmike <at> hotmail.com>,<rray <at> pesa.com>
>Subject: DSL Forum Liaison
>Date: Tue, 4 Jan 2005 14:34:37 -0000
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bob Ray | 4 Jan 2005 22:05

RE: FW: DSL Forum Liaison

On Tue, 2005-01-04 at 12:14, Faye Ly wrote:
> Mike,
> 
> I think a MIB is definitely needed as new flavors of ADSL are being
> deployed.  I would recommend keep this new MIB as close as the existing
> RFC 2662 as possible to maintain the consistency and make the EMS's job
> easier.
> 
> Best,
> 
> -faye
> 

A volunteer!!  

I think we also need to have two LCS MIBs to complete RFC2662...
Perhaps IETF versions of the two line code specific MIBs the
DSL Forum generated?  

--

-- 
Bob Ray <rray <at> pesa.com>
Permalink | Reply | 0 comments |
headers
Moti.Morgenstern | 5 Jan 2005 08:50

RE: FW: DSL Forum Liaison


Hi Faye and all,

The need for a DIFFERENT model for the New Generation ADSL family was a
fundamental assumption in TR-90 of DSLF, as the document itself describes.
The reasons for that were mainly
- The number of DSL modes supported,
- The flexible number of channels supported
- The required support for STM and packet modes beside the existing ATM
mode
- The additional features specified

The TR-90 model has several major changes compared to RFC2662. For example
the profiles (configuration, thresholds) are more complex. There are "low"
level profiles that are then combined to "higher" level profiles, which we
call templates.

However, as the members of the DSLF NM&OP WG are also those who were
involved in creating RFC2662 we tried to preserve some concepts. The
operator still has to attach a single configuration profile and a single
thresholds profile to each line (as he/she does today) but those are now
called templates. Also, the DSL modes bitmap, the line status bitmap, the
inventory can be planned as backward compatible.

Hence, the chance of creating an SNMP MIB for the New Generation ADSL
family to be "as close as the existing RFC 2662" is probably very low.

Regards,
Moti Morgenstern
(Continue reading)

Permalink | Reply | 3 comments |
headers
C. M. Heard | 9 Jan 2005 05:04
Picon
Favicon

MIB Doctor Review of draft-ietf-adslmib-gshdslbis-07.txt

Howdy,

Bert Wijnen asked me to do take a quick look at
draft-ietf-adslmib-gshdslbis-07.txt before it is sent out for IETF
last call.  I think that there are some issues with the Security
Considerations section in the draft that warrant a clean-up before
the document goes to the IESG, and I have also found a few minor
editorial ssues.  Regarding the MIB module itself, I looked only at
the changes that have been made since RFC 3276;  based on that, it
appears to be in good shape and ready to go.

Details are in the MIB Doctor check list below.  (It does not quite
match Appendix A of draft-ietf-ops-mib-review-guidelines-03.txt
because it is based on a new version of the checklist that the MIB
Doctors have been discussing on the mreview list.  You are the first
guinea pigs :)

1.) I-D Boilerplate -- OK

2.) Abstract -- OK

3.) MIB Boilerplate -- OK

4.) Security Considerations Section -- this section does not comply
with the Security Guidelines for IETF MIB Modules at
http://www.ops.ietf.org/mib-security.html.  Editorially, the
material appears in an unexpected order, which makes it hard it hard
to read.  Also, there are several redundant/obsolete paragraphs that
appear to be the result of splicing the text from the current
guidelines onto the front of the old security text.  There are also
(Continue reading)

Permalink | Reply | 4 comments |
headers
Wijnen, Bert (Bert | 10 Jan 2005 14:17
Picon
Favicon

RE: MIB Doctor Review of draft-ietf-adslmib-gshdslbis-07.txt

Thanks very much Mike for your thourough review.

I think we can do one of two things:

- I go ahead with IETF Last Call and the editors/authors address
  your comment as part of any other IETF last Call comments
- The editors/authors address your comments forst before I issue
  IETF Last Call.

I slightly prefer the latter. Editors/authors?

Bert

> -----Original Message-----
> From: C. M. Heard [mailto:heard <at> pobox.com]
> Sent: Sunday, January 09, 2005 05:04
> To: ADSL MIB (E-mail)
> Cc: Wijnen, Bert (Bert)
> Subject: MIB Doctor Review of draft-ietf-adslmib-gshdslbis-07.txt
> 
> 
> Howdy,
> 
> Bert Wijnen asked me to do take a quick look at
> draft-ietf-adslmib-gshdslbis-07.txt before it is sent out for IETF
> last call.  I think that there are some issues with the Security
> Considerations section in the draft that warrant a clean-up before
> the document goes to the IESG, and I have also found a few minor
> editorial ssues.  Regarding the MIB module itself, I looked only at
> the changes that have been made since RFC 3276;  based on that, it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Clay Sikes | 10 Jan 2005 15:10

Re: RE: MIB Doctor Review of draft-ietf-adslmib-gshdslbis-07.txt

Bert and Mike,

Let's hold off on the IETF Last Call and I'll look over and work the issues.

- Clay

Wijnen, Bert (Bert) wrote:

>Thanks very much Mike for your thourough review.
>
>I think we can do one of two things:
>
>- I go ahead with IETF Last Call and the editors/authors address
>  your comment as part of any other IETF last Call comments
>- The editors/authors address your comments forst before I issue
>  IETF Last Call.
>
>I slightly prefer the latter. Editors/authors?
>
>Bert
>
>  
>
>>-----Original Message-----
>>From: C. M. Heard [mailto:heard <at> pobox.com]
>>Sent: Sunday, January 09, 2005 05:04
>>To: ADSL MIB (E-mail)
>>Cc: Wijnen, Bert (Bert)
>>Subject: MIB Doctor Review of draft-ietf-adslmib-gshdslbis-07.txt
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Ray | 11 Jan 2005 20:34

Minneapolis Agenda

The 62nd IETF meeting is just around the corner (March 6-11)
in Minneapolis.

Should we schedule a meeting of the ADSLMIB working group?
If so, what should be on the agenda?

a) consider shutting down working group?
b) presentation of current document status (gshdslbis, vdsl lcs, etc)
c) consider expanding the charter to cover other work?
d) consider LCS specific MIBs for ADSL?
e) consider VDSL2 extensions to VDSL MIB?

Thoughts?  Volunteers?

--

-- 
Bob Ray <rray <at> pesa.com>
Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 12 Jan 2005 16:16
Picon
Favicon

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:mhdo <at> zahav.net.il]
Sent: Tuesday, November 16, 2004 23:27
To: Randy Presuhn; Adslmib (E-mail); Wijnen, Bert (Bert)
Cc: rray <at> pesa.com; 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 smilint <at> ibr.cs.tu-bs.de
    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
Adslmib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib
Permalink | Reply | 1 comment |
headers
Wijnen, Bert (Bert | 12 Jan 2005 16:41
Picon
Favicon

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:\bwijnen\smicng\work>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
-----Original Message-----
From: Menachem Dodge [mailto:mhdo <at> zahav.net.il]
Sent: Sunday, December 19, 2004 23:13
To: internet-drafts <at> ietf.org
Cc: Michael Sneed; rray <at> pesa.com; Wijnen, Bert (Bert)
Subject: Submission of LCS MIB draft

 
Dear Sir/Madam,
 
 
    I would like to submit the draft: draft-ietf-adslmib-vdsl-ext-mcm-05.txt.
 
    Please find the document attached.
 
    Kindest Regards,
 
    Menachem Dodge.
 
 
 
_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib
Permalink | Reply | 0 comments |

Gmane