Re: X25 MIB and network identification

["Dean D. Throop" <[e-mail]>]

> >Message-Id: <[e-mail]>
> >Date: Fri, 14 Feb 92 01:25:34 PST
> >From: "Walter Pinkarschewsky, RE02-G/D9 830-3521" <[e-mail]>
...
> 
> 	It seems to me that what is needed is some form of parameter
> 	in the x25InfoTable that uniquely identifies the network to
> 	which the DTE/DCE is connected.
> 
> 	After that, any network dependent kludges can be left as a private
> 	matter between your software and your favourite network provider.
> 

This topic was discussed earlier on the mailing list.

We talked about three options for doing this.

The first suggestion was to create an enumeration of the networks 
such as: 

x25InfoNetwork OBJECT-TYPE
	SYNTAX	INTEGER {
		network_1(1),
		network_2(2),
		...
		other(n)
		}
	ACCESS 	read-only
	STATUS  mandatory
	DESCRIPTION
		"Identifies the network this PLE is connected to."
	::= { x25InfoTableEntry n }

The problem with this is the difficulity of enumerating all the 
networks and the difficulity of adding new networks in the future.  

This brought about suggestion number two; use an object identifier 
to name the networks: 

x25InfoNetwork OBJECT-TYPE
	SYNTAX	OBJECT IDENTIFIER
	ACCESS 	read-only
	STATUS  mandatory
	DESCRIPTION
		"Identifies the network this PLE is connected to."
	::= { x25InfoTableEntry n }

The problem here is how to translate OBJECT IDENTIFIERs into 
meaningful network names and how to administer the addition of new 
identifiers.  Simply saying IANA would administer it didn't really 
address the administration problem.  

The third ideas was to use a text string that simply named the 
network.  Maybe use ifDescr.  This provides the network administrator 
with the name of the PDN to which the link connects.  It doesn't 
allow dynamic configuration of software function.  This suggestion 
was adopted and the LAPB MIB today does say that the ifDesc field 
must identify the PDN or network to which the link connects.  

As for using such an object to control software behavior, it was 
felt better to break the altered behavior into individiual 
functions that could be seperately controlled.  This would allow 
more flexability than having one single parameter to control many 
subfunctions of software behavior.  In fact the LAPB MIB object, 
lapbParmActionInitiate, is an example of such an object.  

As we actually start defining such objects we want to avoid 
creating a lot of objects that only pertain to a limited segment of 
the market place.  We don't want to burden all vendors with options 
that only pertain to a few networks served by a small number of 
vendors.  The community at large would be better served if those 
vendors created their own MIB with the options specific to their 
market.  

I'm currently skeptical about adding objects to the MIB to name 
networks or control features specific to just one or two networks.  
I would like to see good proposal that address the above issues and 
know the objects have broad support.  If we can really find some 
useful objects, I'll added them to the MIB but I haven't seen a 
proposal that provides enough information to justify inclusion yet.  

That is why I posted (or reposted) the proposal from Spider about 
Extended Format.  If we get half a dozen other vendors saying the 
object would be useful for half a dozen other networks, we'll add 
it to the MIB.  If we just have one vendor saying this is useful for 
one PDN, I don't feel all other vendors should have to support it.  
As for how many vendors and how many networks, I don't have a hard 
and fast rule so we'll be flexable until we need a concrete rule.  


Dean Throop		[e-mail]