draft-ietf-mile-rfc5070-bis-24.txt   draft-ietf-mile-rfc5070-bis-25.txt 
MILE Working Group R. Danyliw MILE Working Group R. Danyliw
Internet-Draft CERT Internet-Draft CERT
Obsoletes: 5070, 6685 (if approved) June 20, 2016 Obsoletes: 5070, 6685 (if approved) June 24, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: December 22, 2016 Expires: December 26, 2016
The Incident Object Description Exchange Format v2 The Incident Object Description Exchange Format v2
draft-ietf-mile-rfc5070-bis-24 draft-ietf-mile-rfc5070-bis-25
Abstract Abstract
The Incident Object Description Exchange Format (IODEF) defines a The Incident Object Description Exchange Format (IODEF) defines a
data representation for security incident reports and indicators data representation for security incident reports and indicators
commonly exchanged by operational security teams for mitigation and commonly exchanged by operational security teams for mitigation and
watch and warning. This document describes an updated information watch and warning. This document describes an updated information
model for the IODEF and provides an associated data model specified model for the IODEF and provides an associated data model specified
with XML Schema. This new information and data model obsoletes with XML Schema. This new information and data model obsoletes
Request for Comment (RFC) 5070 and 6685. Request for Comment (RFC) 5070 and 6685.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 22, 2016. This Internet-Draft will expire on December 26, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 110, line 48 skipping to change at page 110, line 48
IODEF documents MUST be well-formed XML. It is RECOMMENDED that IODEF documents MUST be well-formed XML. It is RECOMMENDED that
recipients validate the document against the schema described in recipients validate the document against the schema described in
Section 8. However, mere conformance to this schema is not Section 8. However, mere conformance to this schema is not
sufficient for a semantically valid IODEF document. The text of sufficient for a semantically valid IODEF document. The text of
Section 3 describes further formatting and constraints; some that Section 3 describes further formatting and constraints; some that
cannot be conveniently encoded in the schema. These MUST also be cannot be conveniently encoded in the schema. These MUST also be
considered by an IODEF implementation. Furthermore, the enumerated considered by an IODEF implementation. Furthermore, the enumerated
values present in this document are a static list that will be values present in this document are a static list that will be
incomplete over time as select attributes can be extended by a incomplete over time as select attributes can be extended by a
corresponding IANA registry per Section 10.2. Therefore, IODEF corresponding IANA registry per Section 10.2. Therefore, IODEF
implementations MUST periodically update their schema and MAY need to implementations SHOULD periodically update their schema and MAY need
update their parsing algorithms to incorporate newly registered to update their parsing algorithms to incorporate newly registered
values. values.
4.4. Incompatibilities with v1 4.4. Incompatibilities with v1
The IODEF data model in this document makes a number of changes to The IODEF data model in this document makes a number of changes to
[RFC5070]. These changes were largely additive -- classes and [RFC5070]. These changes were largely additive -- classes and
enumerated values were added. However, some incompatibilities enumerated values were added. However, some incompatibilities
between [RFC5070] and this new specification were introduced. These between [RFC5070] and this new specification were introduced. These
incompatibilities are as follows: incompatibilities are as follows:
skipping to change at page 159, line 8 skipping to change at page 159, line 8
actions might be explicitly requested in the document or the result actions might be explicitly requested in the document or the result
of analytical logic that triggered on data in the document. For this of analytical logic that triggered on data in the document. For this
reason, care must be taken by IODEF implementations to properly reason, care must be taken by IODEF implementations to properly
authenticate the sender and receiver of the document. The sender authenticate the sender and receiver of the document. The sender
needs confidence that sensitive information and timely requests for needs confidence that sensitive information and timely requests for
action are sent to the correct recipient. The recipient may action are sent to the correct recipient. The recipient may
interpret the contents of the document differently based on who sent interpret the contents of the document differently based on who sent
it; or vary actions based on the sender. While the sender of the it; or vary actions based on the sender. While the sender of the
document may explicitly convey confidence in the data in a granular document may explicitly convey confidence in the data in a granular
way using the Confidence class, the recipient is free to ignore or way using the Confidence class, the recipient is free to ignore or
refine this information to make its own assessment. refine this information to make its own assessment. Ambiguous
Confidence elements (where it is unclear to which of a set of other
elements the Confidence element relates) in a document MUST be
ignored by the recipient.
Certain classes may require out-of-band coordination to agree upon Certain classes may require out-of-band coordination to agree upon
their semantics (e.g., Confidence@rating="low" or DefinedCOA). This their semantics (e.g., Confidence@rating="low" or DefinedCOA). This
coordination MUST occur prior to operational data exchange to prevent coordination MUST occur prior to operational data exchange to prevent
the incorrect interpretation of these select data elements. When the incorrect interpretation of these select data elements. When
parsing these data elements, implementations should validate, when parsing these data elements, implementations should validate, when
possible, that they conform to the agreed upon semantics. These possible, that they conform to the agreed upon semantics. These
semantics may need to be periodically reevaluated. semantics may need to be periodically reevaluated.
Executable content of various forms could be embedded into the IODEF Executable content of various forms could be embedded into the IODEF
 End of changes. 6 change blocks. 
7 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/