Title: ARF - Errors in the ARF protocol PDR Reference: 98070002 Originator Reference: SARPs Document Reference: ARF SARPs, sections 2.2.2.5.3.4.10.1, 2.2.2.5.3.4.11.1, 2.2.2.5.3.5.3.1 Tables 2.2.2.5-2 and 2.2.2.5-19 Status: RESOLVED Impact : B (Bug) PDR Revision Date : 28/09/98 (PROPOSED -> RESOLVED) 04/09/98 (ACCEPTED -> PROPOSED) 17/08/98 (SUBMITTED -> ACCEPTED) PDR Submission Date: 08/07/98 Submitting State/Organisation: CENA/CHARME Submitting Author Name: Jean, M. Submitting Author E-mail Address: jean@cenatls.cena.dgac.fr Submitting Author Supplemental Contact Information: Tel: +33 5 62 25 95 89 Fax: +33 5 62 25 95 99 SARPs Date: ICAO Edition 2.3 (Doc 9705 - 1st edition - 1998) SARPs Language: English Summary of Defect: 1/ The reception of a D-ABORT indication (originator=user/provider) should be allowed when the PM is in the state RF-I-END. 2/ The actions on receipt of a D-ABORT ind primitive and D-P-ABORT ind primitive are not described in state table 2.2.2.5-19. 3/ The table listing the parameters used in the D-START request should indicate that the DS-user version number is used. It should also refer to the ADS-start-forward primitive and not to the ADS-forward-contract primitive. 4/ In sections 2.2.2.5.3.5.3.1 and 2.2.2.5.3.5.3.2, the test condition on the version number upon receipt of a D-START indication ("if the version number parameter is not compatible with the version number of the ASE") is not detailed enough. Assigned SME: Sub-Volume II SME Proposed SARPs amendment: 1/ Change section 2.2.2.5.3.4.10.1 from: If in the RF-I-START state or the RF-I-ACTIVE state, the initiating ADS-RF-ASE shall : a) stop any timers, b) invoke ADS-user-abort indication, and c) enter the RF-I-IDLE state. to If in the RF-I-START state, the RF-I-ACTIVE state or the RF-I-END state, the initiating ADS-RF-ASE shall : a) stop any timers, b) if not in the RF-I-END state, invoke ADS-user-abort indication, and c) enter the RF-I-IDLE state. 2/ Change section 2.2.2.5.3.4.11.1 from: If in the RF-I-START state or the RF-I-ACTIVE state, the initiating ADS-RF-ASE shall : a) stop any timers, b) invoke ADS-provider-abort indication... 2.2.2.5-9, and c) enter the RF-I-IDLE state. to If in the RF-I-START state, the RF-I-ACTIVE state or the RF-I-END state, the initiating ADS-RF-ASE shall : a) stop any timers, b) if not in the RF-I-END state, invoke ADS-provider-abort indication... 2.2.2.5-9, and c) enter the RF-I-IDLE state. 3/ append the following two lines to Table 2.2.2.5-19 (): RF-I-IDLE RF-I-START RF-I-ACTIVE RF-I-END D-ABORT ind Cannot stop any timer stop any timer with originator= occur ADS-user-abort ind " user " D-ABORT ind Cannot stop any timer stop any timer with originator occur ADS-provider-abort ind " provider " or D-P-ABORT ind 4/ Change cell (DS-user version number, Derivation of Parameter Value) in table 2.2.2.5-2 from: Not used to: ADS-RF-ASE version number 5/ In table 2.2.2.5-2, in cells (Called peer id) and (Quality of Service) change from: ADS-forward-contract request To ADS-start-forward request 6/ Add the following note to section 2.2.2.5.3.5.3.1 Note.- By "compatible" is meant that the receiving ASE and user is able to react to the received protocol in the correct way. If the version numbers are equal, they will always be compatible. If the receiving ASE and user has a version number greater than the initiating version number, then they will be compatible only if the receiving system is able to downgrade itself to the lower version number. If the receiving ASE and user has a version number less than the initiating version number, then the receiving system has no way of knowing whether or not the systems are compatible. It would, therefore, have to assume that it is not compatible. SME Recommendation to CCB: PROPOSED CCB Decision: atnp_ccb_chair: SUBMITTED (06/07/98) Atnp_ccb_chair: ACCEPTED (17/08/98) CCB-7 (Bordeaux): RESOLVED (28/09/98)