Subject: ADSL Line MIB and the Entity MIB

From: "Gregory Bathrick" <[email-masked]>
Date: Fri, 23 Oct 1998 17:47:52 -0700

Entity MIB working group,

I am developing an ID for ADSL management within the adslmib working
group.   The purpose of this ID is to define that managed objects of an
ADSL
line and to a certain extend it endpoints: ATUC and ATUR:

     Central Office                                            CPE

         ATUC      -------------------------      ATUR
                                     adsl line

In the ID, I have included guidance on how to implement the entity mib
for ADSL.  It identifies both the ATUC and ATUR as physical entities
in the entPhysicalTable and associates each together using  the
entAliasMappingTable.  Would agree with these decision?

Regards,
Greg

http://www.ietf.org/internet-drafts/draft-ietf-adslmib-adsllinemib-01.txt

-------------

6.2  Relationship with RFC 2037 [25]

Implementation of the Entity MIB [25] is optional.  It in no way alters
the informati
on required in the adslLineMib, nor does it alter the relationship with
IF-MIB, ifInd
ex, and ifStackTable.

The Entity MIB introduces a standardized way of presenting the
components of complex
systems, such as a Digital Subscriber Line Access Multiplexer (DSLAM),
that may conta
in multiple racks, shelves, line cards, and/or ports.   The Entity MIB's
main goal is
 to present these system components, their containment relationship, and
mapping info
rmation with other MIBs such as the Interface MIB and the adslLineMib.

If implemented, the Entity MIB should include entities for the ATU-C and
ATU-R in the
 entPhysicalTable.  The MIB's entAliasMappingTable would  contain
mapping information
 identifying the 'ifIndex' object associated with each ATU-C and ATU-R.
Also associa
ting the relationship between the ifTable and Entity MIB, the
entPhysicalTable contai
ns an 'entPhysicalName' object, which approximates the semantics of the
'ifName' obje
ct from the Interface MIB.

---

From: Keith McCloghrie <[email-masked]>
Date: Sat, 24 Oct 1998 12:38:24 -0700 (PDT)

If I understand correctly, the likelihood of the device being in the
same chassis/rack with other similar devices and/or other equipment, is
quite likely for an ATU-C, but quite unlikely for an ATU-R.  Thus, while
your statement:

 > ATU-R in the entPhysicalTable. 

would seem to apply for the ATU-C, it would seem unnecessary to include
any additional physical entity for an ATM-R.

Keith.

> --------------198E2F4D3B8DA08B8FEBF584
> Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
> Content-Description: Card for Gregory Bathrick
> Content-Disposition: attachment; filename="vcard.vcf"
> Content-Transfer-Encoding: 7bit
> 
> begin:          vcard
> fn:             Gregory Bathrick
> n:              Bathrick;Gregory
> org:            AGCS New Ventures
> adr:            2500 W Utopia Road;;;Phoenix;AZ;85027;USA
> email;internet: [email-masked]
> title:          Product Development Leader
> tel;work:       602-582-7679
> tel;fax:        602-582-7697
> x-mozilla-cpt:  ;29872
> x-mozilla-html: TRUE
> version:        2.1
> end:            vcard
> 
> 
> --------------198E2F4D3B8DA08B8FEBF584--
> 
>