Shippers' Declaration for Dangerous Goods

Cargo XML Task ForceFace-to-Face Meeting MinutesDate: October 4 th – 6 th , 2011Location:Face-to-Face meeting, GenevaParticipants: The list of Participants is enclosed as Annex 11. Welcome & Introduction- IATA welcomed the members to the meeting, initiated a round table introductionand reminded the group of the competition law compliance.- IATA asked the members if additional items were to be included into the agenda,to which a member asked to insert an item in the AOB section on thecommunication with the other industry groups regarding the move from Cargo-IMP to XML.- The members agreed to the proposed amended agenda.- IATA informed the members that the goal of the meeting would be to:‣ Discuss the result of the IATA Cargo Messaging Survey‣ Review of the Booking message‣ Review of the Response (Error & Acknowledgment) standard message‣ Review of updated existing specifications‣ Discuss technical issues‣ Discuss the Customs Status Notification (CSN) message‣ Review the progress on the Proof of Concepts‣ Discuss the development of the Cargo XML Manual‣ Define the Next Steps- IATA prepared a general presentation detailing the items for discussion andinformed the members that the presentation would be shared with the group.- IATA to share with the group the presentation made during the meeting.2. Adoption of the minutes of the September 21 st , 2011 conference call- The Task Force Members adopted the minutes of September 21st, 2011conference call without modifications.3. Information on the result of the IATA Cargo Messaging Survey- IATA proposed to start the discussion by presenting the results of the AirlineSurvey on Cargo Messaging.Page 1 of 16

- IATA explained that the survey was conducted from 13 th to 30 th September 2011to identify the exact industry situation and the future plans for cargo messagingimplementation.- IATA mentioned that 34 replies were received from airlines so far, one reply froma freight forwarder and one reply from a Ground Handling Agent. IATA explainedthat primarily the survey was destined to airlines but as it was also made availableto the CXMLTF members, freight forwarders and ground handlers were able toprovide their answers.- IATA explained that the survey was also made available to FIATA with the adviceto have it sent to their members to identify the industry messaging situation fromthe freight forwarders’ side.- IATA presented the results, which raised the below questions:‣ 95% of respondents use Cargo-IMP‣ 67% use currently FWB version 16- A member asked that if the FWB 16 was used, if that meant that alloptional and mandatory requirements were adopted. IATA replied that notall functionalities were adopted within the message because there wereoptional data but that all mandatory would be available. IATA remindedthat the FWB was to be used in relation with Resolution 600a.- A member mentioned that for the OCI line composition there were differentbusiness models on how it was to be used and that C2K would need toadd it to be C2K compliant.‣ 21% use currently XML(Waybill 38%; House Waybill 15%; Flight Manifest 15%; Invoice 15%)‣ 43% plan to move to XML in the near future- IATA mentioned that the result in the usage of XML was very encouragingas 60% from the 34 airlines would be in XML in the short term.- A member stressed that if airlines were capable of XML this would notimply that GHAs were capable as well and that it would be necessary toapproach the GHAs in that respect.- IATA mentioned that a similar survey would also be carried out with theGround Handling Agents by means of the IATA Ground Handling Council(IGHC).- IATA asked the Freight Forwarders present at the meeting to encourage FIATA topush the survey to their members to understand the messaging situation from allsupply chain stakeholders.- Members highlighted that the translation from one format to the other would begoing on for a while especially if systems cannot handle the different formats.- IATA mentioned that some airlines were currently changing their operatingsystems to include XML capabilities and that in the e-AWB framework airlineswere also inserting in the EDI Agreement a technical annex on the possibilities toreceive both formats, Cargo-IMP and XML.Page 2 of 16

- IATA mentioned that in EDIFACT there was a “firm booking request” whichaim was to assign an AWB number and that codes could assist doing this.Consignor internal ID and Account Number- Members asked to clarify the definitions of the Consignor Account Number(the account number assigned to the Consignor) and the Consignor Internal ID(the internal ID assigned to the Consignor) to understand by whom the IDwere assigned to.- IATA explained that if a Freight Forwarder was considered as the Consignorthen the Account Number would be assigned by the Carrier however‣ The internal ID would be his own ID‣ The standard ID would be for example the DUNS number.- Members asked IATA to check the UNTDED and WCO data elementsdefinition and to clarify the definitions in the specification.Transport and Booking DetailsLocation Code- Members questioned the code list used for the “Location Code” data elementsas the specification mentioned the UN/LOCODE whereas usually it would bethe IATA Code List that should be used.- A member mentioned that for Off Airport Points there were no IATA codesavailable, to which the group stated that for air freight the IATA 3 letter codelist should be primarily used and if no code was available then theUN/LOCODE would be used.- IATA proposed to qualify the location by adding a new data element“Scheduled Departure Location Code Coded” in the specification to referencethe code list used that specifies the Location (I=IATA; U=UNLOCODE), whichwould result in adding an attribute to the location field in the XML message.- The members agreed with the inclusion of the location qualifier and proposedto have this changed throughout the specification.- Members agreed to include a condition for the “Location Code” in theexplanation column that “For Air Freight the IATA 3 letter airport/city codemust be used”.- IATA will amend the XML booking specification and will replicate the changeinto all specifications.- A member raised the concern that conditions would create implementationproblems and that these should be well documented.Schedule Date/Time- Members raised some concern regarding the “Schedule Date/Time” dataelement as a Mandatory element and explained that when freight forwardersrequest a booking, the airline asks to tender the shipment by a certain timeand thug the latest acceptance time was missing in the specification.Page 4 of 16

- Members mentioned as well that the response time would have to addressmore data elements.- Members proposed to separate the schedule time from the date and to createnew optional data elements for the schedule departure and arrival:‣ “Scheduled Departure Date” and “Time of Availability at Origin”‣ “Scheduled Arrival Date” and “Time of Availability at Destination”.- IATA will amend the XML booking specification accordingly.- The members stressed the difficulty to have the request for booking and therequest for schedule & availability as one single request message because theresponse for availability would be different from the response for booking.- Members explained that if more than one process was described in a singlemessage the definition of that message would get diluted.- Stephen Smith (DGF) showed the Finnair booking portal to the group to clarify theintention the future message(s) should serve.- Michael Weber (Kuehne & Nagel) reiterated the need to take advantage of thetechnology with regards to Web Services with the aim to detach from the strictCargo-IMP messages. He mentioned that if parties agreed to move towards WebServices the request and answer should be treated in the same time whereby themessage would trigger the process.- Members mentioned that the minimum request in booking was to access thecapacity as soon as possible but that the airlines’ responses were too long andthat was the reason why parties still use the phone capabilities.- IATA mentioned that the importance of the new XML message was to cover theCargo-IMP capabilities and to enhance them. This would lead to not being able torevert back to Cargo-IMP.- Members agreed to move forward with 2 separate message specifications:one for the booking and one for the schedule & availability.- The group reiterated the need to minimize the number of mandatory dataelements but that the booking request should have sufficient information to enablethe evaluation and response.- Member agreed that the rating details would be included within the bookingrequest and booking response but that these should be optional in the message.Exception Handling Code- Members asked which procedure would need to be followed in case of a rebookingand if the same message would over right the previous one.- Members proposed to include a new optional data element “ExceptionHandling Code” relating to the procedure that would indicate exceptionalbusiness practices and rules.- The group stressed the need to ensure that the new code list was commonlyunderstood as each airline was doing it differently and proposed to use asubset of the existing Cargo 2000 Exception code list. As these codes werePage 5 of 16

proprietary to Cargo 2000 IATA would need their approval knowledge andconsent.- IATA will amend the XML booking specification accordingly.- IATA will coordinate with the Cargo 2000 representatives to query about thepossible use of the Exception code list for the XML booking message.- The members endorsed the XML e-booking functional specifications Version 0.7.- IATA to send the amended XML e-booking functional specifications Version 0.7 tothe group.- IATA to amend the XML Booking message specification according to the itemsdiscussed and to prepare 2 separate message specifications.5. Review of the Waybill specification- IATA presented the outstanding issues resulting from the conference calldiscussions and emails received by parties implementing the IATA XMLspecification.Rating Details, the Line Item Details Cardinality, Dimensions & ULD Nº Details- It was agreed that a sub-group (Lufthansa, UNISYS, Korean Air, Kuehne &Nagel) would be set up to fix the structure and cardinality of the Line ItemDetails including the Rating Details and the Dimensions & ULD NumberDetails.- IATA will coordinate the work of the sub-group on the line item details.Collect charges in destination currency- A member pointed out that the schema does not reflect the specification andthe way it was structured today would require a change of cardinality of theelements included in the “Collect Charges Amount in Destination Currency”Grouping Element.- IATA proposed to create in the schema a specific sub-group for the “CollectCharges Amount in Destination Currency” Grouping Element as stated in thespecification without changing any cardinality, to which the members agreed.- IATA will update the Waybill specification and the related schema accordingly.Other Customs, Security and Regulatory Control Information (OCI Line)- A member highlighted that in the OCI Grouping Element the following dataelements were mentioned as Mandatory whereas in Cargo-IMP these wereconditional (at least one of the elements should be completed):‣ Country Code‣ Information Identifier‣ Customs, Security and Regulatory Control Information Identifier- IATA proposed to change the cardinality for the 3 data elements fromMandatory to Optional and include a comment in the “Conditions” columnPage 6 of 16

stipulating that at least one of the three data elements should be completed,which the group accepted.- A member informed that the “Customs Origin Code” data element should notbe included into the OCI Grouping Element and proposed to consider it as anindependent element within the “Transport and Booking Details” GroupingElement, to which the group agreed.- IATA will update the Waybill specification and the related schema accordingly.- Members stressed the need to separate the Customs aspects from theSecurity aspects in the light of new requirements, which raised somediscussion amongst the group.- IATA mentioned that currently the Cargo Security Declaration information wasencapsulated in the OCI line and was defined by consignment and not bypiece otherwise the piece would need to be identified at piece level.- Members asked IATA to review the definitions in the OCI Grouping element toreflect the current situation.- The group agreed at this point to leave the discussion on the separation ofCustoms from Security aspects for further considerations.Waybill discrepancy in the schema- Airlines outside of the Task Force implementing the IATA XML Messagesasked some clarification on the Waybill specification and schema:‣ ‘Means of Transport ID’ within the Waybill-XML is as optional but does notmatch data element 4.2.3 = Routing Carrier Code in the FWB/16 which is amandatory data element.‣ “We need to consider that in the future we receive Waybill-XML into oursystem and have to transmit FWBs to e.g. handling agents or Customsinterface systems and ensure that all data elements mandatory in CIMPare mandatory in XML and all data elements optional in CIMP are optionalin XML as well.”- The group reviewed the query and mentioned that the flight rooting should notbe mixed with the FWB rooting and that this should be conveyed back to theairline that raised that point.- The member discussed the conversion of the XML to Cargo-IMP and agreedthat the future should allow the Cargo-IMP to be translated into the XMLmessage and not to ensure the functionality for an XML to be converted backinto a Cargo-IMP message as the way forward was the exchange of XMLmessages.- The members recognize that implementation constraints would take placeespecially with regards to limitations from the core systems but that atransitional period should allow moving forward to XML.Page 7 of 16

ULD Number Details (= Optional)- A member raised the concern to have the “Tare Weight” data elementMandatory in the Waybill XML whereas the element was not in the FWB and ifan FWB with this data element would be received, the XML would getrejected.- The members agreed to change the cardinality of the “Tare Weight” dataelement from Mandatory to Optional.- IATA will update the Waybill specification and the related schema accordingly.Dimension Grouping Element- A member raised the concern of having the “Weight” data element in the“Dimension” Grouping Element as Mandatory whereas the dimension dataelements were all Optional and proposed to:‣ Change the “Weight” data element from Mandatory to Optional;‣ Change the Unit of Measurement, Length, Width, Height and Quantity fromOptional to Mandatory;‣ Include a note in the Condition/Explanation Column for the “Dimensions”,“Volume”, “ULD” Grouping Elements as well as for the “No DimensionAvailable” data element stating that the elements must be included if it wasnot already included into the other elements.- The group agreed to the proposed changes.- IATA will update the Waybill specification and the related schema accordingly.Harmonized Commodity- A member explained that the source of the Harmonized code couldn’t alwaysbe defined. It was highlighted that having the “Harmonized Commodity CodeCoded” data element as Mandatory in the Waybill XML whereas the elementwas not in the FWB could result in the XML message to be rejected.- The members agreed to change the cardinality of the “Harmonized CommodityCode Coded” data element from Mandatory to Optional and to insert a note inthe Condition/Explanation Column stating that the data element wasMandatory if the Commodity Code was more than 6 digits.- IATA will update the Waybill specification and the related schema accordingly.Consignor Declaration Details- A member questioned having the “Consignor Text” data element as aMandatory field as this was a free text field.- IATA mentioned that within the e-Air Waybill the declarations were part of theEDI agreement and that such information would not be needed in themessage. IATA would verify that this was in line with Resolution 600a.- IATA proposed to withdraw the “Consignor Text” data element as well as thewhole “Consignor Declaration” Grouping Element and to keep only thePage 8 of 16

“Consignor Declaration Signature” data element in the specification, which thegroup agreed to.- IATA will update the Waybill specification and the related schema accordingly.Security information- Members questioned having the security and customs information linkedtogether and asked to further consider the possibility to separate them.- IATA mentioned that the security/customs information were to be included inthe OCI line or in other specific data elements within the specification. IATAreferred to the 2009 “Other Customs Information Fields” document listing thecodes related to the “Customs Information Identifier” and crosschecking themwith the data element in which they would be available (example below):- The members mentioned that duplication of information could occur if thesame information would be included in different data element and proposedfor the sake of clarity to distinguish the Commercial messages (e.g. invoice,Packing List) from the Transportation messages (e.g. Waybill, House Waybill).- The members proposed to keep in the Commercial messages the“ConsignorTax/Customs Information” Grouping element for all parties but toremove it from the Transportation messages, which the group agreed to.- IATA will update the Waybill specification and the related schema accordingly.6. Review of the Response (Error & Acknowledgment) standard message- IATA presented the Response (Error & Acknowledgment) specification and listedthe data elements, which had been previously agreed by the members during theconference calls.- A member mentioned that freight forwarders would want to identify if the messagewas received by the airline or not, following which the members discussed thedifferent scenarios when an acknowledgment was needed.- Members explained that the recipient’s system could reply in a synchronouslymanner but if the system couldn’t, than the recipient would have to send aResponse message as “Received” in the Response Type. The membersquestioned having in addition the need to acknowledge it as proposed in thematrix.- The members proposed to modify the “Category” field definition as well as thematrix by modifying from Mandatory to Optional the need to acknowledge whenthe Response Type was “Received” to avoid unnecessary traffic of messages.- IATA reiterated the fact that MIP error code list would be the basis of a specificcode list.Page 9 of 16

- IATA updated the definition and the matrix in the specification accordingly with theproposed changes.RESPONSE TYPEReceived Processed RejectedRESPONSESUMMARYCATEGORIESAcknowledgement Optional Mandatory ProhibitedWarning Prohibited Optional OptionalError Prohibited Prohibited Mandatory- The group endorsed the Response (Error & Acknowledgment) specification andasked IATA to make the schemas available to the group.7. Technical Discussion- IATA reminded that the UTF8 would be the default character set however localrequirements may require a bilateral agreement for a different character set.Case-Sensitivity Fields- The members emphasized the need to consider how the case sensitivity would behandled as issues arose with the EU ICS implementation with fields containinglower and upper case.- The members asked IATA to further investigate with the WCO and its Data Modelto understand how this issue was addressed on their side.- The members recognized the need to set best practice and suggested that theupper case be used.- IATA to further investigate with the WCO on the use of lower and upper case intheir Data Model.Kuehne & Nagel proposal on WSDL (Web Services Description Language) files- Samuli Hiltunen (Kuehne & Nagel) presented their proposal on WSDL (WebServices Description Language) open standard files. The purpose of thepresentation was to propose to the CXMLTF to recommend the use of the WSDLas a standard:‣ To exchange messages with common functionalities and name with theaim of keeping it simple and reusable;‣ To provide parties with the necessary information when startingimplementing synchronous systems;‣ To avoid maintaining multiple web services.- Samuli Hiltunen (Kuehne & Nagel) stated that the intention was not to impose theuse of WSDL but to ensure the CXMLTF proposed some standard in that respect.Page 10 of 16

- The group recognized the need to set standards and proposed to share thedocument with the other members of the Task Force for further consideration.- IATA to share the presentation to the other members of the Task Force members.8. Review the Customs Status Notification (CSN) message- IATA asked the members prior to the face-to-face meeting to come back to thegroup on the functions expected by Customs that the message would have toaccommodate.- The member mentioned the following:‣ The CSN was currently not used as it was designed for because themessage was not triggered from the Customs system.‣ There was a usage problem wit the CSN message as all the needed datacan’t be provided.‣ With regards to the EU ICS each Member States has its own application asno standard was available.‣ GLSHK were using CSN to distribute customs replies (Accept, Hold, andHold-Release) to both carrier and GHA systems.‣ The CSN XML message should be as flexible as possible and used tocommunicate any kind of regulatory information between any involvedparties. To achieve this the Cargo-IMP CSN message itself (which wouldrequire consultation and approval of other bodies) shouldn’t be re-purpose,but a brand new XML message that replaces the CSN would need to bedesigned adding as well functions.‣ The split entries for declared House Waybills should be considered‣ While the list below (which was a ‘non-standard’ list) maps to the ICSresponses from EU MS, there were other status types for goodsdeclarations which would need to be considered.- ACKNOWLEDGED, ACCEPTED, ACCEPTED_ARRIVAL,REJECTED, ON_HOLD (non EU), RELEASED‣ The development of a new CSN XML message should be the opportunityto possibly rectify some issues with regards to the content of the message.- The group recognized that the following items would need to be addressed:‣ Customs, Security and other regulatory information would need to be look at.‣ If there was a need of a new message and if there was, what structureshould it have?‣ Can the FSU message with the OCI line meet the CSN requirement?- The members emphasized the need to have a clear business understanding ofthe interface between the Customs and Ground Handlers as well as whatinformation could be provided.Page 11 of 16

- The group agreed to set up a working group that would have the aim to draft adocument for the CSN highlighting:‣ What is the CSN currently used for and what are the existing fields;‣ The business needs and what is expected (adding or changing fields);‣ The inclusion of security aspects and customs exchange.- Some members proposed to join the group, such as Axel Klein (Lufthansa), SteveHill (CHAMP). It was as well proposed to have members of the CDITF, CBPP andCUSAG as part of the group.- The group mentioned that EU requirements would need to be addressed as well.- IATA to start drafting the CSN functional specification and to set up the group.9. Discuss the development of the Cargo XML Manual- IATA mentioned to the Cargo XML Manual would be based on the existing Cargo-IMP manual and that Functional Specifications would be defined in that respect.- IATA explained that the manual would include:‣ XML structure, Descriptions, formats, code lists, cardinality, Cargo-IMPreferences‣ XML schemas‣ International Standard used‣ User list (based on a survey on “who is using what”).- The members reiterated the need to include in the manual some businessprocesses and implementation guidelines as well as technical recommendationon the physical exchange communication.- IATA to keep the group up to date on the progress of the manual and to share thefunctional specification for feedback.10. Discuss the Proof of Concept progress- IATA asked the members to provide updated information on the IATA XMLstandard message Proofs of Concepts (PoC).- Members stated that the PoCs were on going. Brian Toms (Delta) mentioned thatDelta joined the Unisys and Kuehne & Nagel PoC.- Members asked if the Flight Manifest message would be piloted as it was a keymessage for the movement of freight and stressed that as a group they wouldneed to ensure that the specifications were validated by means of PoCs.- Members reiterated that not only message should be piloted but also the processitself.- A member mentioned that an implementation plan could be defined to share thevision with the Industry.- Members to keep the group up to date on the progress of the proofs of concepts.Page 12 of 16

11. XML communication mechanism- Bernard Heuzeveldt (KLM) emphasized the lack of formalized way ofcommunicating between the different communities with respect to the differentinitiatives especially regarding the move from Cargo-IMP to XML. He presented ascheme and stated that the expectations of one industry group with regards theother industry groups were not always known.- Bernard Heuzeveldt (KLM) gave as an example the work undertaken by Cargo2000 with the Master Operating Plan review and mentioned that some milestoneswould need to be reviewed in the light of the use of XML Messages instead of theCIMP messages. He mentioned that in the future the cooperation betweenCXMLTF and C2K would need to be reinforced (e.g. with the XML e-bookingmessages).- Bernard Heuzeveldt (KLM) proposed to IATA to come to the next Cargo 2000meeting in Frankfurt to give an update and inform the group on the latestdevelopment of the XML standards.12. Next Steps2012 Priorities- IATA mentioned that the core and widely used Cargo-IMP messages had beendeveloped in XML and asked the members about the 2012 priorities and ifadditional Cargo-IMP message should be developed or if the focus should be onother areas (e.g. GHA related messages)- The members discussed the following messages:‣ Unit Load Device Manifest (FUM)‣ Freight Booked List Request (FBR)‣ Status Request (FSR)‣ Surface Transportation Movement (STM) & Conveyance Message (MVT)‣ Mail related messageNext Steps- IATA will update the schema of the XML messages following the discussion andshare it with the group.- IATA mentioned that the next steps would be the following:Page 13 of 16

‣ Develop the updated schemas for the Response message (error andacknowledgment);‣ Update the specifications and the schema for the XML Waybill;‣ Review the specifications and schemas for the existing messages;‣ Update the IATA XML e-booking functional specifications;‣ Review the Shippers’ Declaration for Dangerous Goods Version 2;‣ Develop the Customs Status Notification (CSN) specification.‣ Develop the Cargo XML Manual Functional Specifications- IATA will provide the Members with:‣ The minutes of the face-to-face meeting in Geneva;‣ The presentation made by IATA during the meeting;‣ The presentation made by Kuehne & Nagel during the meeting;‣ The updated XML message specifications and schema;- IATA proposed to have the next conference call scheduled on Monday October21 st , 2011 at 1500 Geneva time.- IATA will provide will send to the group the invitation to the next conference callas well as the supporting material.- IATA will come back to the group with proposed dates for the next CXMLTF faceto-facemeeting avoiding conflict with other meetings.* * * * * * * * * * *Page 14 of 16

LIST OF PARTICIPANTS – OCTOBER 4 th – 6 th , 2011 ANNEX 1Participants:COMPANYCATHAY PACIFIC CARGOCHAMPDESCARTESDESCARTESDHL GLOBAL FORWARDINGDL/NW CARGO SYSTEMSGLSHKETHIHADKLM CARGOKUEHNE + NAGELKUEHNE + NAGELLUFTHANSALUFTHANSATRAXONUNISYSIATAIATAIATAMEMBERSFelix YanSteve HillJos NuijtenKarl RunmoStephen SmithBrian TomsEugene NgTahir SyedBernard HeuzeveldtMichael WeberSamuli HiltunenStefan CypraAxel KleinJames HendersonVenkatesh PazhyanurAndrea Graf-GruberBill AchesonFrederic LegerExcused:COMPANYAMERICAN AIRLINESBRITISH AIRWAYSCARGOLUXCATHAY PACIFIC CARGOCATHAY PACIFIC CARGOCHAMPCHAMPCHAMPCHINA AIRLINESCHINA AIRLINESCSCBCSGDESCARTESDESCARTESDHL GLOBAL FORWARDINGDL/NW CARGO SYSTEMSDL/NW CARGO SYSTEMSEGYPTAIR CARGOMEMBERSDick DoughertyKeith DavisChris LopezJackson ChanFrancis YuenChuck HoltonJean BracciFred WerginzDaniel WuFrances NgaiPaul HughesSamson PaoHenk SchaafsmaDouwe TolsmaJulian DucasseRodney MeltonMaria VuMagdy SalehPage 15 of 16

EGYPTAIR CARGOEMIRATESEMIRATESFEDEXGLSHKHACTLHACTLHACTLHACTLINDITEX GROUPINDITEX GROUPINDITEX GROUPINDITEX GROUPINFOSKYKOREAN AIRLINE CARGOKUEHNE + NAGELMALAYSIA AIRLINESMALAYSIA AIRLINESMALAYSIA AIRLINESMALAYSIA AIRLINESNIIT TECHNOLOGIESNIIT TECHNOLOGIESNIIT TECHNOLOGIESNIIT TECHNOLOGIESSAS CARGO GROUPSAS CARGO GROUPSINGAPORE AIRSITASITPRO / TNLSWISSPORTTRAXONTRAXONUN/CEFACT TBG3UNISYSUNITED AIRLINESOla ShawerAngelo BernaschinaNandakumar VenkatesanTerrell S. PughKeith WK. LamKing Keung ChanEthon KwanKelly ChakWilson YipMiguel Lopez AlvarezDiego TeijeiroAlejandro Taboada ArosaMarina Arias RodriguezNelly TongJustin G. ParkSilke HiltunenEikhwan Bazura BaharinAzmanArmanSulaimanAbhishek SehgalAshok Kumar SinghAtul GuptaSubash WaliMugo PetersenClaus RingbyNazim RosMansour Rezaei-MazinaniIan HoggPaul MarsmanJosef KrejcirEdward DorrHenk van MaarenThomas ZurickMark ShunickPage 16 of 16