Re: Comments on X.25 MIB, 12 June, 1992

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

Andy G.:

Thanks for the comments on the X.25 MIB.  I've considered your 
comments and have the following responses.

>To: [e-mail]
>From: [e-mail]
>Subject: Comments on X.25 MIB, 12 June, 1992
>
>From:	NAME: Andy Goldthorpe               
>	FUNC: DAS23                           
>	TEL: [phone]                      <GOLDTHORPE AT A1 AT SES6A>
>To:	[e-mail]@r11f@mrgate
>
>
>Comments on X.25 Packet Layer MIB
>
>
>Comment  : #1
>Location : Page 2, clause 1.1
>Type     : Question
>Question : Why has the x121Address been extended to 17 digits?  There is no
>	   change to X.121 in the 1988 X.25 standard.

In the 1988 version of X.25, Section 5.2.1.2.1 states "The maximum 
value of a DTE address field length indicator is 17." While this 
isn't exactly an X.121 address, the objects in the MIB that contain 
the DTE address fields are defined as X121Addresses.  As such I 
believe we should allow for the potentially longer strings in the 
future.  Implementations that only need 14 bytes can use this 
definition and other implementations based on 1988 can still use 
the objects defined with a type of X121 Address.  

>Comment  : #2
>Location : Page 9, clause 5.3
>Type     : Major technical
>Rationale: Reference is made to the ISO work on X.25 management and the
>	   Committee Draft of 10733.  It should be noted that this work has
>	   advanced cosiderably, particularly in light of CCITT comments on
>	   X.25 management.
>Proposal : ISO SC6 is meeting in July to consider the DIS ballot of 10733.
>	   CCITT has submitted a considerable input to this meeting.  The
>	   results of this meeting (which may be an IS) should be
>	   considered and referenced, and the MIB aligned.

Unfortunatly the results of that ballot are not yet available.  The 
concensus from the last working group was to recommend the 
documents for advancement as a proposed standard with the editing 
changes agreed to.  While the MIB started with the objects of 10733, 
it isn't required to track it through the ISO standardization 
process.  Once an updated 10733 is available, the working group 
should consider the impact of any changes.  I believe we should look 
at the advances in 10733 when the X.25 MIB is considered for 
advancement from proposed standard to draft standard.  It maybe 
there will be enough changes so the X.25 MIB will not go to draft 
but will remain as a proposed standard for another review period.  

>
>Comment  : #3 (ref #1)
>Location : Page 13, clause 6
>Type	 : Major technical
>Rationale: X.121 addresses are a maximum of 14 digits in length.  They may
>	   be preceeded by an escape code (1 digit) or TOA/NPI (2 digits).
>	   In neither case does the total equal 17 digits.
>Proposal : Reduce the length to 14 digits unless there is a good answer to
>	   comment #1.

See response to comment #1

>
>Comment  : #4
>Location : Page 16, x25AdmnMaxActiveCircuits OBJECT-TYPE
>Type	 : Major technical
>Rationale: The maximum number of active circuits is limited to 4095: Logical
>	   Channel 0 is used for network signalling.
>Proposal : Change SYNTAX INTEGER TO (0..4095).

I have heard that some networks actually use Logical Channel 0 as 
a data channel and they could indeed have 4096 channels.  While the 
MIB doesn't go out of its way to support these implementations, it 
doesn't hurt much to define the object to allow 4096 even though 
most implementations only allow a maximum of 4095.  

>Comment	 : #5 (as for #4)
>Location : Page 24, x25OperMaxActiveCircuits OBJECT-TYPE
>
See response to comment #4.

>Comment	 : #6
>Location : Page 20, x25AdmnNumberPVCs OBJECT-TYPE
>Type	 : Major technical
>Rationale: Logical Channels are numbered from 0 to 4095.  LC0 is used for
>	   network signalling: LC1 to LC4095 are available for PVCs.
>Proposal : Change SYNTAX INTEGER to (1..4095).

The x25AdmnNumberPVCs specifies the number of PVs not the
first or last PVC.  This assumes the first PVS uses LCN 1.
A value of zero indicates the PLE doesn't have any PVCs
configured.  It probably should be (0..4095).

>Comment	 : #7 (as for #6)
>Location : Page 28, x25OperNumberPVCs OBJECT-TYPE
>
>Comment	 : #8
>Location : Page 34, x25StatInInterrupts OBJECT-TYPE
>Type	 : Question
>Question : How is the method of counting determined - per PLE or per PVC/VC?
>	   How is the method indicated?

This would be per PLE.

>
>Comment	 : #9 (as for #8)
>Location : Page 35, x25StatOutInterrupts OBJECT-TYPE
>
This would be per PLE.

>Comment	 : #10
>Location : Pages 39-40, x25Channelxxx
>Type	 : Major technical
>Rationale: Logical Channels are nymbered from 0 to 4095.  LC0 is used for
>	   network signalling: LC1 to LC4095 are available.
>Proposal : Change SYNTAX INTEGER to (1..4095).

A value of zero is provided to indicate no Logical Channels are
configured of the specified type.  If values were restricted to
1..4095, it wouldn't be possible to specify that zero channels
requested of a certain range.

>
>Comment	 : #11
>Location : Pages 39-40, x25Channelxxx
>Type	 : Question
>Question : How is conformance to Logical Channel Assignment rules achieved?
>	   Is this implementation dependent?  For example, how is range
>	   overlap avoided?

This is an implementation detail left up to the Agent.

>
>Comment	 : #12 (as for #10)
>Location : Page 42, x25CircuitChannel OBJECT-TYPE

I agree the range should be 1..4095.
>
>Comment	 : #13 (as for #10)
>Location : Page 52, x25ClearedCircuitChannel OBJECT-TYPE

I agree the range should be 1..4095.


I'd like to hear from other members of the working group.
Should we change the MIB at start another review period,
or just change the MIB and send it to the SNMP area director?

Dean Throop		[e-mail]