Title: 	                        CM - ETD Correction

PDR Reference:				97080001
Originator Reference: 			CMETD
SARPs Document Reference:		CM SARPs, Section 2.1.4.2.1
Status: 					ADOPTED
PDR Revision Date: 			22/09/97 (SUBMITTED -> ACCEPTED -> PROPOSED)
						20/10/97 (PROPOSED -> RESOLVED)
PDR Submission Date:  			18/08/97
Submitting State/Organization: 	ATNP WG3/SG2
Submitting Author Name: 		Saccone, G
Submitting Author E-mail Address: 	gsaccone@ccgate.hac.com
Submitting Author Supplemental 
Contact Information:			ph 1 604 821-5182,
                                    fx 1 604 279-5980
SARPs Date:		               	IV1.1, March 97
SARPs Language: 				English

Summary of Defect: 
ETD, as presented in the CMLogonRequest does not match the definition in the ICAO Manual of ATS Data Link Applications.  The SARPs include Date and Time while the manual only has Time.

Assigned SME: 				Sub-Volume II SME

Proposed SARPs amendment: 

The date was added for the operational concern that a repetitive flight plan aircraft may be delayed and another aircraft, with the same flight ID and ETD, may subsequently take off.  This could result in a confusing and potentially dangerous operational scenario.  However, the ADSP has determined that there is not necessarily a need for the date in ETD (or EOBT, as it is now called).

In order to resolve this situation, there are a some options:

1.	Do nothing
2.	Change the ASN.1 of CM to match the ICAO Manual of ATS Data Link Applications,
3.	Add only comments to the ASN.1 and additional guidance, outlining a local solution, and
4.	Change chapter 7.

1.  The do nothing solution is deemed to be insufficient.  There will be a disconnect between the CM SARPs and the ICAO manual that can cause confusion, with possible saftety and operational impacts.  Therefore this option was not considered further.

2.  Changing the ASN.1 would alleviate the problem by aligning the SARPs with the ICAO manual.  However, this would change current implementations that have already incorporated the CM ASN.1.  The ADS Panel did not say that the inclusion of the date was incorrect, only not needed at this point.  Therefore, another solution would allow the (compilable) ASN.1 to remain as is.  Therefore this option was not considered further.

3.  If the date may be useful at a future time and its inclusion is not wrong, a local implementation can simply provide a system date in the field when creating the ETD component and ignore that field when receiving the component.  This will not add significantly to the message overhead, and the only change to the SARPs would be a note in the ASN.1, which would not affect the backwards compatibility.  Additionally, the CM guidance would explain this.  This is viewed as an acceptable solution.

4.  Changing chapter 7 would force all implementers to use the date field in the same way.  Option 3 allows more flexibility and has less impact on the SARPs.  This option was not considered further.

The proposed SARPs amendment is solution 3, i.e. a note to be included in the ASN.1:

Insert, after Date:

Date ::= SEQUENCE
	{
	year		Year,
	month		Month,
	day		Day
	}

-- The Date field does not have to correspond to the flight if the field is not to be used;
-- the field's value can be assigned a meaningless, but compliant, value locally.  If operational
-- use of the Date field is intended, there must be bilateral agreements in place to ensure its
-- proper use.  This is a local implementation issue.

Additionally, this will be explained in more detail in the CM guidance.

SME Recommendation to CCB: 		-

CCB Decision:  				CCB-2 (Langen): SUBMITTED
						atnp_ccb_chair: ACCEPTED (22/09/97)
						atnp_ccb_chair: RESOLVED (20/10/97)