Re: Initialing X.25 calls
Ragnar Paulson <ragnar@software.group.com> Tue, 04 February 1992 00:10 UTC
Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa24257; 3 Feb 92 19:10 EST
Received: from dg-rtp.rtp.dg.com by NRI.NRI.Reston.VA.US id aa24234; 3 Feb 92 19:10 EST
Received: from uunet.ca by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA12586; Mon, 3 Feb 1992 18:50:01 -0500
Received: from tsgfred by mail.uunet.ca with UUCP id <53569>; Mon, 3 Feb 1992 18:49:45 -0500
Received: from rosie.group.com by tsgfred.software.group.com id aa19745; Mon, 3 Feb 92 18:47:03 EST
Subject: Re: Initialing X.25 calls
To: x25mib@dg-rtp.dg.com
Date: Mon, 03 Feb 1992 18:39:36 -0500
Cc: Ragnar Paulson <ragnar@software.group.com>
In-Reply-To: <9202031925.AA27867@commtg3>; from "Dean D. Throop" at Feb 3, 92 2:25 pm
Reply-To: ragnar@software.group.com
X-Mailer: ELM [version 2.2 PL13]
From: Ragnar Paulson <ragnar@software.group.com>
Message-Id: <9202031839.aa22242@rosie.software.group.com>
> > > > I believe you are correct. The IP to X.25 address mapping for > addresses not in use comes from an ipNetToMediaTable. > This table does not have any way to indicate X.25 call parameters > to use to place the call. > > The ioxConTable only contain entries for existing calls and > that table does indicate the call parameters used for the call. > Way back when, we discussed being able to specify various facilities for various calls. I started it with a request to have a specail version of the ipNetToMediaTable for the iox MIB. As I recall the ioxConTable was the result of that discussion. The comment in my copy of the MIB (Dated October 4 1991) says: ioxConTable OBJECT-TYPE SYNTAX SEQUENCE OF IoxConEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The information available about possible or existing X.25 connections carrying IP traffic for this interface." The keyword being possible. There doesn't seem to be any reason why this table can't be used to define the entries for making calls as well as for existing calls. In the case of incoming calls the above table probably is no good for displaying the facilities that were present, unless they set that appeared just happen to match a preconfigured table in the PLP MIB. So if anything it seems to be more suited for configuring our table of IP to Facility mappings than for displaying what facilities appeared on an existing call. On the other hand, if we're re-examining all this why don't we simplify it and get rid of the ioxConX25FcltyIndex ioxConX25fcltyCcittIndex ioxConX25CallParamIndex and just specify the facilities in the iox table. Any decent API to X.25 will allow a higher layer entity to specify whatever facilities it needs on a per call basis. Having to preconfigure a table in the PLP and then specify the table when making the call seems like unnecessary overhead. This is not how our implementation of X.25 or RFC877 works. Does anyones? If not why, why implement the MIB this way. I should have brought this all up a long time ago I guess, but I just let it slip by. At the time I thought it was a reasonable compromise but judging by the past couple weeks mail we should go back and look at it again. -- Ragnar Paulson email: ...uunet!tsgfred!ragnar The Software Group Limited or: ragnar@software.group.com Phone: 416 856 0238
- Re: Initialing X.25 calls Dean D. Throop
- Re: Initialing X.25 calls Dean D. Throop
- Re: Initialing X.25 calls Ragnar Paulson