1. ITEM #1 reference to retrieval and archiving is removed

2. Item#2 Justification of FINE – sample generic usage "for reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention" e.g. in one scenario, CERT-A may have received a report of an incident from one of its constituencies. The attacker in this case is from a constituency of CERT-B. CERT-A will want to communicate all or parts of the incident report to CERT-B. CERT-B will receive the incident report investigate it and probably return all or parts of the investigation results to CERT-A."

3. Item#2-1 The designer/developer/implementor of the Exchange Format. CERTS and other organizations that use implementations of format The Audience

4. Item#3 Move “Goals” to introduction

5. Item#4 Introduction to the Terminology section

6. Item#5,6 Ternimology: Damage and Impact Damage The intended or unintended direct consequence of an attack. E.g. lost data, unusable system, unavailability of services. Impact The result of the attack in a wider sense. It covers all results of the attack direct and indirect. The impact may be given in financial and/or economic terms.

7. Item#7 Ternimology: Computer Security Incident vs Incident Report

8. Item#8 Ternimology: Target vs Victim Drop or keep ?

9. Item#9 Ternimology: Attack vs Event Event => Any occurance Security incident => Adverse event Attack => Some security incidents

10. Item#10 Ternimology: Regroup definitions CSIRT Event Computer/Network Security Incident Incident Report Attack Target Damage Impact

11. Item#11 Ternimology: Incident some aspect of computer system or network security is compromised

12. Item#12 Operational Model Diagram Remove reference to Statistics packages Other Org => collaborators, involved parties, etc.

13. Item#13 Life Cycle of a report the report itself evolves. The states: - handling - complete/closed - waiting the report is updated based on interaction with/ investigation by CSIRTs; Not one CSIRT can vouch for the full report

14. Item#14 Life Cycle of a report vs Life cycle of data The opening or closing of a report does not validate or invalidate the assertions in the report.

15. Item#15 Move requirements from Operational Model to requirements

16. Item#16 Requirement # 7.5: definition of “Current Owner”

17. Item#17 Requirement # 7.6 and 7.8 Additional Reference vs Reference to Advisory

18. Item#18 Requirement # 7.11 Time reporting Time will be reported in format that can easily be resolved to UTC and/or localtime.

19. Item#19 Requirement # 7.14 Move from Content requirements to General requirements 5.6. The Format for Incident report Exchange must have a well defined semantics and provide a standard way for extensibility in terms of addition of components and/or extending the components.

20. New Requirement 5.7. FINE must allow multilingual reports. And in case there multiple language versions of a component of the report FINE must be provide a way to identify which version is authentic. An Incident Report may be multilingual i.e. different parts of the Incident Report may use different languages. It is also possible that multiple versions of parts of the report exist, each version in a different language. The versions may not be consistent.

21. Item#20 Security Considerations: References to sections corrected.