Title: CM - Erroneous handling of unexpected QOS

PDR Reference:                                            	98050003
Originator Reference:                              	ATNSI_CM02 
SARPs Document Reference:                  	CM SARPs, Sections 2.1.5.4.7.1
Status:                                            		REJECTED 
PDR Revision Date:                                 	20/05/98 (REJECTED)
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 
SARPs Language:                            	English

Summary of Defect:

1/ It is not specified that a D-START indication with an unexpected QOS can only be received in the IDLE state by a CM-ASE.

2/ Since the CM-ASE cannot but be in the IDLE state, there is no timer to stop. 

3/ Furthermore, the CM-ASE does not need to "enter" the IDLE state at the end of the exception handling procedure, but just needs to "remain" in the IDLE state.

Assigned SME:                              		Sub-Volume II SME

Proposed SARPs amendment: 

The requirement in section 2.1.5.4.7.1 should be changed to:

If a D-START indication QOS Priority parameter does not have the abstract value of "high priority flight safety message" or if the QOS Residual Error Rate parameter does not have the abstract value of "low", if the CM-ASE is in the IDLE state, the CM-ASE shall:

a) if the CM-ASE is a CM-air-ASE, create an CMAircraftMessage APDU 
with a CMAbortReason [invalid-QOS-parameter] APDU message element,

b) if the CM-ASE is a CM-ground-ASE, create an CMGroundMessage 
APDU with a CMAbortReason [invalid-QOS-parameter] APDU message element,

c) invoke D-ABORT request with:

	1) the abstract value "provider" as the D-ABORT Originator parameter value, and
	2) the APDU as the D-ABORT User Data parameter value, and

d) remain in the IDLE state.

SME Recommendation to CCB:                 		

1/ The requirements of the Exception Handling Section apply whatever the entering state is. This is why none of these requirements indicates the entering state.
2/ It is true that the D-START indication may only be received in the IDLE state.  Therefore, the stop all timers is not necessary.  However, the protocol will still work with this statement in.
3/ For the second comment on being able to "remain" in the IDLE state as opposed to "entering" the IDLE state, it should be kept in mind that an abort implies problems with the protocol, so entering the IDLE state is a sure way that upon handling an abort, the ASE is reset to a known state.  Since both of these cases, if left as are currently, do not affect interoperability, this PDR is rejected.
CCB Decision:                                      		atnp_ccb_chair: SUBMITTED (12/05/98)
						atnp_ccb_chair: REJECTED (20/05/98)