Tony Kerr@ECSOFT
04/06/99 16:48
     
Title:                   ULCS - Abort inconsistencies 
PDR Reference:                     99030004 
Originator Reference:
SARPs Document Reference:          Doc. 9705 Table 4.3-4, 4.3.3.4.5.1.1, 
4.3.3.6.3.1.1
Status:                       RESOLVED
Impact:                       C (Clarification)
PDR Revision Date:            17/05/99 (PROPOSED -> RESOLVED)
                                   19/04/99 (ACCEPTED -> PROPOSED)
                              09/04/99 (SUBMITTED -> ACCEPTED)
PDR Submission Date:               26/03/99 
Submitting State/Organisation:     Eurocontrol
Submitting Author Name:       Conor Molloy, Airtel ATN 
Submitting Author E-mail Address:  conor@airtel-atn.com 
Submitting Author Supplemental Contact Information:
                    3, Haigh Terrace, Dun Laoghaire,
                    Co. Dublin, Ireland
                    Tel: +353-1-284-2821
SARPs Date:                   First edition - 1998 
SARPs Language:                    English
     
Summary of Defect:
There seems to be a conflict in V2.3 of the SARPS in Sub-volume IV
     
In 4.3.3.6.3.1.1 it states that P-U-ABORT indication can only be invoked 
when the CF is any state except RELEASE COLLISION. While Table 4.3-4 shows 
P-U-ABORT indication as a valid event in the RELEASE COLLISION state.
     
As the text takes precedence we are following the text. But this looks like 
a defect.
     
Assigned SME:                 SME 4 (A. Kerr)
     
SME Analysis:
It appears that the state table is correct and the text is in error.
Early drafts of the ULCS SARPs did allow (P-U-ABORT ind, STA4), both in the 
state table and also in the text.  Then in Jul 96, a defect report (UL-DR 
089) was raised as a result of GEODE modelling, saying that P-U-ABORT ind 
and the corresponding A-ABORT ind cannot validly occur in Release Collision 
state.  The draft SARPs were modified to disallow P-U-ABORT, and also 
A-ABORT ind,  when in STA4 in both the state table and also in the text. 
However, it seems that DR 089 was wrong - there must have been an error in 
the GEODE model, as it is easy to construct a scenario where P-U-ABORT can 
be received when in STA4.
Somehow, mysteriously (there was no corresponding PDR), the state table got 
changed back for P-U-ABORT ind between Nov 96 and Mar 97, but the text did 
not.  Also, the text and state table for (A-ABORT ind, STA4) never got 
changed back.
     
So, the following changes are proposed, which completely reverse UL-DR 089:
     
Proposed SARPs amendment:
     
Table 4.3-4 (State Table)
Cell (A-ABORT ind, STA4) to be changed from blank to:
 (STA0, D-ABORT ind)
     
Change 4.3.3.4.5.1.1
from:
<<Invocations of the A-ABORT Indication primitive by the ACPM shall be 
allowed when the CF is in any of the states ASSOCIATION PENDING, DATA 
TRANSFER, or RELEASE PENDING; if an invocation occurs when the CF is in any 
other state then an error has occurred (see 4.3.3.1.2.4).>>
to:
<<Invocations of the A-ABORT Indication primitive by the ACPM shall be 
allowed when the CF  is in any valid state, except the NULL state; if an 
invocation occurs when the CF is in the NULL state then an error has 
occurred (see 4.3.3.1.2.4).>>
     
Change 4.3.3.6.3.1.1
from:
<<Invocations of the P-U-ABORT Indication primitive by the supporting 
service shall be allowed when the CF is in any valid state, except RELEASE 
COLLISION; if an invocation occurs when the CF is in the RELEASE COLLISION 
state then an error has occurred (see 4.3.3.1.2.4).>>
to:
<<Invocations of the P-U-ABORT Indication primitive by the supporting 
service shall be allowed when the CF is in any valid state.>>
     
Impact on Interoperability:
     
There is no impact on interoperability, as the Dialogue is aborted anyway. 
If the proposed change is not applied, then a P-U-ABORT indication received 
when in the RELEASE COLLISION state would cause a false error to be logged 
and the error handling procedures to be invoked, i.e. an Abort indication 
to be given to the user.  If the proposed change is applied, then an Abort 
indication will still be given to the user, but in a more orderly manner, 
and ACSE will be tidied up.
     
SME Recommendation to CCB:    Progress to RESOLVED
     
CCB Decision:        RESOLVED (CCB-9, Naples)