Hi Bert,
See the embedded (intermediate) response.
Best Regards,
Moti Morgenstern
Senior Systems Engineer
ECI Telecom Ltd.
Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49517
Tel.: +972-3-9266258
Fax: +972-3-9287342
Cell: +972-54-5786258
e-mail: [email protected]
www.ecitele.com
"Wijnen, Bert
(Bert)"
<[email protected] To
om> "'Ray, Robert'"
Sent by: <[email protected]>
adslmib-bounces@i cc
etf.org "Adslmib \(E-mail\)"
<[email protected]>
Subject
02/01/2006 19:12 [Adslmib] AD review:
draft-ietf-adslmib-adsl2-04.txt
Sorry that it took so long to review.
Here is what I get from SMICng:
E: f(adsl2.mi2), (3689,16) Index item "adsl2PMLHist15MInterval"
must be defined with syntax that includes a range
E: f(adsl2.mi2), (3833,16) Index item "adsl2PMLHist1DInterval"
must be defined with syntax that includes a range
E: f(adsl2.mi2), (3977,16) Index item "adsl2PMLHistInit15MInterval"
must be defined with syntax that includes a range
E: f(adsl2.mi2), (4083,16) Index item "adsl2PMLHistinit1DInterval"
must be defined with syntax that includes a range
E: f(adsl2.mi2), (4348,16) Index item "adsl2PMChHist15MInterval"
must be defined with syntax that includes a range
E: f(adsl2.mi2), (4451,16) Index item "adsl2PMChHist1DInterval"
must be defined with syntax that includes a range
Not sure I understand why you did not inlcude such a range?
<<<<Moti: I've fixed this problem. The value ranges have been added
according
<<<< to what we describe in the introduction (section 2.6.1 and
2.6.2)
I see:
ngdslTCMIB MODULE-IDENTITY
::= { transmission xxx }
-- RFC Ed.: we suggest to put it under { transmission 230 } because
-- this is the first available number.
and I also see:
ngdslMIB MODULE-IDENTITY
::= { transmission xxx }
-- RFC Ed.: we suggest to put it under { transmission 231 } because
-- this is the first available number.
Now if you go to http://www.iana.org/assignments/ianaiftype-mib
then you will see that 231 and 232 have been taken by now.
So asking for 231 does not make sense (anymore).
But besides, I see that you have gotten 230 assigned for adsl2.
So it seems weird to me to then askl it to be used for the TC MIB module.
<<<<Moti: The reference quoted concerns the ifType. We actually do need
<<<< more than the value (ifType=230) already allocated for adsl2.
For RFC2662, I see that we also had a TC and that we had
adsltcmib MODULE-IDENTITY
::= { transmission 94 2 } -- adslMIB 2
And
adslMIB MODULE-IDENTITY
::= { transmission 94 }
adslLineMib OBJECT IDENTIFIER ::= { adslMIB 1 }
So we could follow a similar approach here.
<<<<Moti: Yes. We'll adopt the same approach for this MIB.
Then (I do not recall if you answered this earlier) I wonder that
the IfType is adsl2, but we root the ngdslMIB underneath it.
I understand (from wg mail discussion) that this new MIB module is
also to address the ngdsl and vdsl2 in the future.
Is the plan to have a vdsl2 ifType in the future? If so, how does that
fit with this MIB document?
We then use ngdls as the MIB module name and adsl2 as prefix for
all objects. Not very consistent is it?
<<<<Moti: In the beginning of the work we assumed that this MIB will serve
<<<< for all new DSL technologies. As a result of recent changes in
ITU-T
<<<< management model we understand that for VDSL2 there will be a
need for
<<<< revising existing management tables/attributes as well as
adding few new
<<<< ones.
<<<< Some of those changes (e.g., use of subcarrier groups, using
band number
<<<< as a table index) will unnecessarily complicate the use of the
VDSL2
<<<< line MIB for operators that prefer to deploy ADSL2 "only".
<<<< So now we understand that the existing MIB should be called
ADSL2 line MIB.
<<<< It will support, as designed, the ADSL2, ADSL2+, RE-ADSL2 and
"old" ADSL
<<<< lines. Another MIB will be required for VDSL2. It will also
support backward
<<<< compatibility to ADSL2/ADSL2+, RE-ADSL2 and ADSL, at the cost
of using
<<<< the more complicated approach of VDSL2 line management.
The reason I get a bot confused is this:
- abstract says:
This document defines a Management Information Base (MIB) module for
use with network management protocols in the Internet community. In
particular, it describes objects used for managing parameters of the
"Asymmetric Digital Subscriber Line" family of interface types,
especially including ADSL, ADSL2, and ADSL2+.
- And then the first table DESCRIPTION states:
adsl2LineTable OBJECT-TYPE
SYNTAX SEQUENCE OF Adsl2LineEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table adsl2LineTable contains configuration,
command and status parameters of the ADSL2 line.
The index of this table is an interface index where the
interface has an ifType of adsl2(230)."
- So will ifTypes with ifType adsl also be in this table?
Can they be in this table? MUST they be in this table?
<<<<Moti: This is a complicated situation. What we understand is that
<<<< in case the SNMP agent supports only RFC2662 then any ADSL
<<<< line will be given the ifType=adsl and accordingly the EMS
will
<<<< manage it with RFC2662.
<<<< However, NE that supports (also) ADSL2 will prefer to manage
all
<<<< lines using the ADSL2 Line MIB. So, all ADSL/ADSL2/ADSL2+
<<<< and RE-ADSL interfaces will be given ifType=adsl2 (230) and
will be
<<<< managed with the same line MIB. The NE will still be able to
indicate
<<<< that a specific interface is ADSL "only" using an attribute
within the
<<<< inventory table (adsl2LInvTransmissionCapabilities).
<<<< Similarly an NE that will support VDSL2 lines will naturally
be in
<<<< favor of using the same ifType=vdsl2 (???) for all xDSL
technologies.
<<<< The specific capabilities of each xDSL interface will be
reflected by
<<<< the same kind of attribute in the VDSL Line MIB.
I see read-create table(s) like adsl2LineConfTemplateTable and
adsl2LineConfProfTable but nowhere can I find what the persistency
behaviour is of the rows in these tables. Pls check all writable
objects and tables and make sure you describe the expected persistency
behaviour and/or use StorageType objects (RFC2579) for tables.
<<<<Moti: We'll add references to the persistency aspect of tables/objects.
In your RowStatus object DESCRIPTION clauses I see:
Before a profile can be deleted or taken out of service
(by setting this object to 'destroy' or 'outOfService'),
it must be first unreferenced from all associated
lines."
I think you mean notInService instead of outOfService, see RFC2579.
<<<<Moti: Will be corrected
You must also state whihc objects if any can or cannot be changed
if a row is active.
<<<<Moti: Will be corrected
I need to study this more and better before I can complete my review.
Bert
_______________________________________________
Adslmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/adslmib
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.