Title: ADS - Erroneous exception handling for D-ABORT indication

PDR Reference:                        	98050009
Originator Reference:                   	ATNSI_ADS06 
SARPs Document Reference:               	ADS SARPs, Section 2.2.1.5.3.14.4
Status:                               	RESOLVED 
Impact :						C (Clarification)
PDR Revision Date:                   	17/08/98 (FORWARDED -> RESOLVED)
							25/06/98 (PROPOSED -> FORWARDED)
							11/06/98 (SUBMITTED -> ACCEPTED -> 
										PROPOSED)
PDR Submission Date:                 	12/05/98 
Submitting State/Organization:         	AIRSYS ATM (ACI/ATNSI)
Submitting Author Name:               	Ilkiewicz, M / Stokes, S.
Submitting Author E-mail Address:           										michel.ilkiewicz@cdv.vly.sextant.thomson.fr 
				Shawn.Stokes@ATNSI.COM 
Submitting Author Supplemental 
Contact Information:                       
SARPs Date:                             	IV2.2, March 98 
SARPs Language:                          	English

Summary of Defect:

The LI module does not request the AB module to abort with reason invalid-PDU on receipt of a D-ABORT PDU with originator equal to user and containing a valid ADS-provider-abort PDU.

This is erroneous, since a SARPs conformant ASE does not send this PDU with this originator in a D-ABORT request.

Assigned SME:                              		Sub-Volume II SME

Proposed SARPs amendment: 

The requirement should be changed from:

When the user data parameter value of D-ABORT indication is a valid APDU and is not an ADS-provider-abort-PDU

to:

When the user data parameter value of D-ABORT indication with originator equal to user is not empty or when the user data parameter value of D-ABORT indication with originator equal to provider is a valid APDU and is not an ADS-provider-abort-PDU

SME Recommendation to CCB:                 		

In Section 2.2.1.5.4.3.6, the ground LI module is filtering the PDUs which are not allowed to be present in the User Data parameter of the D-ABORT indication parameter. The ADS-provider-abort PDU is allowed. Therefore this PDU can not be rejected with reason "invalid-PDU". The proposed solution is therefore rejected.

The check should be performed by the AB module in section 2.2.1.5.3.14.4 as follows:

2.2.1.5.3.14.4 Upon receipt of a D-ABORT indication with the originator parameter value set to the abstract value "user" and with data in the <User Data> parameter, the AB module shall:

Anyway, the proposed change would make the SARPs more accurate but would not change the behaviour of the ASEs. With the current specifications, the user data sent (by error) with a ADS-user abort are simply ignored. With the proposed change, the error is detected.
  
CCB Decision:                	atnp_ccb_chair: SUBMITTED (12/05/98)
					atnp_ccb_chair: ACCEPTED(11/06/98)
					CCB-6 (Utrecht) : FORWARDED (25/06/98)
					atnp_ccb_chair : RESOLVED (17/08/98)(1)

(1) CCB agreed that this PDR should be upgraded to RESOLVED status and should appear as part of the first annual amendment to Doc 9705. FORWARDED status is not appropriate since it indicates a PDR which has been referred to an ATNP WG for addition to its work program, i.e. a enhancement or major change to the baseline.