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