Question(s):
4/17
Meeting, date:
Study Group:
17
Working Party:
1/17
Source:
Editor of X.1541 (ex X.iodef)
Title:
A.5 justification information for draft new X.1541 (ex X.iodef) "Incident object description exchange format"
Contact:
Name
Organization
Country
Tel: +
xx
E-mail:
a@b.com
Contact:
Tel: +xx
E-mail:a@b.com
Abstract:
This TD contains the A.5 justification for draft new X.1541 (ex X.iodef) "Incident object description exchange format" including the following normative references: IETF RFC 5070 (2007).
1Introduction
According to ITU procedures, as described in
ITU-T Recommendation A.5
, any normative reference to documentation produced outside the ITU (other than ISO and IEC texts) needs to be evaluated by the study group or working party before a decision is made to incorporate the reference in an ITU-T Recommendation.
This TD contains the A.5 justification information for new X.1541 (ex X.iodef) "Incident object description exchange format".
2Referred documents and respective justifications
- IETF RFC 5070 (2007): The Incident Object Description Exchange Format
-
Approved Dec 2007
-
Essential to implementation of capabilities set forth in Recommendation
-
Complete A.5 justification information can be found in
Annex 1
.
Annex 1
A.5 justification information for the reference to IETF RFC 5070 (2007)
1
Clear description of the referenced document:
IETF RFC 5070 (2007): The Incident Object Description Exchange Format
2
Status of approval:
Approved Dec 2007
3
Justification for the specific reference:
Essential to implementation of capabilities set forth in Recommendation
4
Current information, if any, about IPR issues:
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=5070
5
Other useful information describing the "Quality" of the document:
Global deployed since 2007 and universally used for incident object exchange purposes.
6
The degree of stability or maturity of the document:
Stable
7
Relationship with other existing or emerging documents:
Extensively referenced, including X.1500, X.rid, X.ridt
8
Any explicit references within that referenced document should also be listed:
6.1 Introduction[b-IETF RFC5070] section 1 is informative.6.1.1 Terminology[b-IETF RFC5070] section 1.1 is informative.6.1.2 Notations[b-IETF RFC5070] section 1.2 is informative.6.1.3 About the IODEF data model[b-IETF RFC5070] section 1.3 is informative.6.1.4 About the IODEF implementation[b-IETF RFC5070] section 1.4 is informative.6.2 IODEF data types[b-IETF RFC5070] section 2 is informative.6.2.1 Integers[IETF RFC5070] section 2.1 is normative.6.2.2 Real numbers[IETF RFC5070] section 2.2 is normative.6.2.3 Characters and strings[IETF RFC5070] section 2.3 is normative.6.2.4 Multilingual strings[IETF RFC5070] section 2.4 is normative.6.2.5 Bytes[IETF RFC5070] section 2.5 is normative.6.2.6 Hexadecimal bytes[IETF RFC5070] section 2.6 is normative.6.2.7 Enumerated types[IETF RFC5070] section 2.7 is normative6.2.8 Date-time strings[IETF RFC5070] section 2.8 is normative.6.2.9 Timezone string[IETF RFC5070] section 2.9 is normative.6.2.10 Port lists[IETF RFC5070] section 2.10 is normative.6.2.11 Postal address[IETF RFC5070] section 2.11 is normative.6.2.12 Person or organization[IETF RFC5070] section 2.12 is normative.6.2.13 Telephone and Fax numbers[IETF RFC5070] section 2.13 is normative.6.2.14 Email string[IETF RFC5070] section 2.14 is normative.6.2.15 Uniform resource locator strings[IETF RFC5070] section 2.15 is normative.6.3 The IODEF data model[b-IETF RFC5070] section 3 is informative.6.3.1 IODEF-document class[IETF RFC5070] section 3.1 is normative.6.3.2 Incident class[IETF RFC5070] section 3.2 is normative.6.3.3 IncidentID class[IETF RFC5070] section 3.3 is normative.6.3.4 AlternativeID class[IETF RFC5070] section 3.4 is normative.6.3.5 RelatedActivity class[IETF RFC5070] section 3.5 is normative.6.3.6 AdditionalData class[IETF RFC5070] section 3.6 is normative.6.3.7 Contact class[IETF RFC5070] section 3.7 is normative.6.3.7.1 RegistryHandle class[IETF RFC5070] section 3.7.1 is normative.6.3.7.2 PostalAddress class[IETF RFC5070] section 3.7.2 is normative.6.3.7.3 Email class[IETF RFC5070] section 3.7.3 is normative.6.3.7.4 Telephone and Fax Classes[IETF RFC5070] section 3.7.4 is normative.6.3.8 Time classes[IETF RFC5070] section 3.8 is normative.6.3.8.1 StartTime[IETF RFC5070] section 3.8.1 is normative.6.3.8.2 EndTime[IETF RFC5070] section 3.8.2 is normative.6.3.8.3 DetectTime[IETF RFC5070] section 3.8.3 is normative.6.3.8.4 ReportTime[IETF RFC5070] section 3.8.4 is normative.6.3.8.5 DateTime[IETF RFC5070] section 3.8.5 is normative.6.3.8.6 Method Class[IETF RFC5070] section 3.9 is normative.6.3.8.7 Reference class[IETF RFC5070] section 3.9.1 is normative.6.3.8.8 Assessment class[IETF RFC5070] section 3.10 is normative.6.3.8.9 Impact class[IETF RFC5070] section 3.10.1 is normative.6.3.8.10 TimeImpact class[IETF RFC5070] section 3.10.2 is normative.6.3.8.11 MonetaryImpact class[IETF RFC5070] section 3.10.3 is normative.6.3.8.12 Confidence class[IETF RFC5070] section 3.10.4 is normative.6.3.9 History class[IETF RFC5070] section 3.11 is normative.6.3.9.1 HistoryItem class[IETF RFC5070] section 3.11.1 is normative.6.3.10 EventData class[IETF RFC5070] section 3.12 is normative.6.3.10.1 Relating the Incident and EventData classes[IETF RFC5070] section 3.12.1 is normative.6.3.10.2 Cardinality of EventData[IETF RFC5070] section 3.12.2 is normative.6.3.11 Expectation class[IETF RFC5070] section 3.13 is normative.6.3.12 Flow class[IETF RFC5070] section 3.14 is normative.6.3.13 System class[IETF RFC5070] section 3.15 is normative.6.3.14 Node class[IETF RFC5070] section 3.16 is normative.6.3.15 Counter class[IETF RFC5070] section 3.16.1 is normative.6.3.15.1 Address class[IETF RFC5070] section 3.16.2 is normative.6.3.15.2 NodeRole class[IETF RFC5070] section 3.16.3 is normative.6.3.16 Service class[IETF RFC5070] section 3.17 is normative.6.3.16.1 Application class[IETF RFC5070] section 3.17.1 is normative.6.3.17 OperatingSystem class[IETF RFC5070] section 3.18 is normative.6.3.18 Record class[IETF RFC5070] section 3.19 is normative.6.3.18.1 RecordData class[IETF RFC5070] section 3.19.1 is normative.6.3.18.2 RecordPattern class[IETF RFC5070] section 3.19.2 is normative.6.3.18.3 RecordItem class[IETF RFC5070] section 3.19.3 is normative.6.4 Processing considerations[b-IETF RFC5070] section 4 is informative.6.4.1 Encoding[IETF RFC5070] section 4.1 is normative.6.4.2 IODEF namespace[IETF RFC5070] section 4.2 is normative.6.4.3 Validation[IETF RFC5070] section 4.3 is normative6.5 Extending the IODEF[b-IETF RFC5070] section 5 is informative.6.5.1 Extending the enumerated values of attributes[IETF RFC5070] section 5.1 is normative.6.5.2 Extending classes[IETF RFC5070] section 5.2 is normative.6.6 Internationalization issues[IETF RFC5070] section 6 is normative.6.7 Examples[b-IETF RFC5070] section 7 is informative.6.7.1 Worm[b-IETF RFC5070] section 7.1 is informative.6.7.2 Reconnaissance[b-IETF RFC5070] section 7.2 is informative.6.7.3 Bot-net reporting[b-IETF RFC5070] section 7.3 is informative.6.7.4 Watch list[b-IETF RFC5070] section 7.4 is informative.6.8 The IODEF schema[IETF RFC5070] section 8 is normative.6.9 Security considerations[IETF RFC5070] section 9 is normative.6.10 IANA considerations[IETF RFC5070] section 10 is normative.6.11 Acknowledgements[b-IETF RFC5070] section 11 is informative.6.12 References6.12.1 Normative[IETF RFC5070] section 12.1 is normative.Unless otherwise stated in this Recommendation, the references in RFC5070 section 12.1 shall be considered as informative.6.12.2 Informative[b-IETF RFC5070] section 12.2 is informative.
9
Qualification of ISOC/IETF:
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
10
Other (for any supplementary information):
None
_________________
-
PAGE
1
-