MIB II

[[e-mail]]

    Date: Tue, 20 Apr 93 14:34:35 EDT
    From: "Adel Fahmy" <[e-mail]>

    I have a comment, or query, on the use of the atportType to determine the 
    format of addresses used in objects such as rtmpNextHop, zipZoneFrom, etc..

    My comment is specifically for the case when the portType is frame-relay, 
    where the MIB suggests that the addresses be in DLCI format... well, in our 
    implementation based on RFC 1294 (multiprotocol over frame-relay), these 
    addresses (NextHop, etc...) are actually normal AppleTalk type addresses 
    (net number, node id) which get mapped at the DLC layer into DLCIs (The 
    Inarp process establishes the mapping).  What I'm trying to say is that 
    since the subject addresses are at the AppleTalk address level, why are we 
    using the DLCI format?  This argument would probably carry over to the X25 
    case as well.  For ppp, however, and since no AppleTalk net number or node 
    id needs to be assigned, the use of a null string seems to be appropriate.

There isn't a standard for running AppleTalk over Frame Relay as yet.  As a 
result, there cannot be a value "FrameRelayTalk" for atportType.

We certainly ought to address at least router to router interaction for 
AppleTalk over Frame Relay.  What you are doing is interesting and, if 
possible, you might want to share your approach.  As I understand it, rfc1294 
gives you a method of multiprotocol encapsulation, along with some references 
to inverse arp (RFC 1293 IP).  

Would you care to describe your use of inverse arp as it relates to AppleTalk?  
Have you extended rfc1293?

For PPP, you may want to refer to the ATCP document.

/bob