Skip to main content

JSON Binding of the Incident Object Description Exchange Format
RFC 8727

Revision differences

Document history

Date Rev. By Action
2023-03-30
14 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2023-02-08
14 (System) Received changes through RFC Editor sync (added Errata tag)
2020-08-05
14 (System)
Received changes through RFC Editor sync (created alias RFC 8727, changed title to 'JSON Binding of the Incident Object Description Exchange Format', changed abstract …
Received changes through RFC Editor sync (created alias RFC 8727, changed title to 'JSON Binding of the Incident Object Description Exchange Format', changed abstract to 'The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information.  This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).', changed pages to 88, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-08-05, changed IESG state to RFC Published)
2020-08-05
14 (System) RFC published
2020-08-03
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-07-29
14 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-04-20
14 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-03-10
14 (System) IANA Action state changed to No IANA Actions from In Progress
2020-03-10
14 (System) RFC Editor state changed to EDIT
2020-03-10
14 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-03-10
14 (System) Announcement was received by RFC Editor
2020-03-10
14 (System) IANA Action state changed to In Progress
2020-03-10
14 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-03-10
14 Amy Vezza IESG has approved the document
2020-03-10
14 Amy Vezza Closed "Approve" ballot
2020-03-10
14 Amy Vezza Ballot approval text was generated
2020-03-10
14 Alexey Melnikov IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-03-10
14 Alexey Melnikov RFC Editor Note was changed
2020-03-10
14 Alexey Melnikov RFC Editor Note for ballot was generated
2020-03-10
14 Alexey Melnikov RFC Editor Note for ballot was generated
2020-03-01
14 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-14.txt
2020-03-01
14 (System) New version approved
2020-03-01
14 (System) Request for posting confirmation emailed to previous authors: Mio Suzuki , Takeshi Takahashi , Roman Danyliw
2020-03-01
14 Takeshi Takahashi Uploaded new revision
2020-02-27
13 Alexey Melnikov Removed from agenda for telechat
2020-02-26
13 Benjamin Kaduk
[Ballot comment]
Thank you for the updates in the -13; they are a good improvement!

I did notice a couple things while reviewing the diff …
[Ballot comment]
Thank you for the updates in the -13; they are a good improvement!

I did notice a couple things while reviewing the diff from -12 to -13 that
I'll mention here, in case there might be any further tweaks to make.

In Figure 7 it looks like the encoded text includes an embedded CR+LF.
I don't think this is forbidden by anything, but is perhaps superfluous.

Thanks for the table of CBOR map keys in Section 5.  I note that slightly
shorter encodings might be possible by using negative integers as well as positive
ones, with "steps" for the encoding size occurring at 24, 256, etc., and -25, -257, etc.

[I did not check the examples for correct use of the CBOR map key values, on the
assumption that they were mechanically generated.]

The definition of StructuredInfo underwent a change that was not quite mechanical:
"(RawData: [+ BYTE] // Reference:[+ Reference])" became
"(iodef-RawData => [+ BYTE], iodef-Reference => [+ Reference])" (dropping the grouping
choice operator "//").  I don't remember if there was a reason to make this change, so
I mention it in case it was not deliberate.
2020-02-26
13 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-02-13
13 Alexey Melnikov Telechat date has been changed to 2020-03-05 from 2020-02-20
2020-02-10
13 Alexey Melnikov
[Ballot comment]
Thank you for addressing my earlier DISCUSS. Below are a few minor questions/comments based on your most recent changes to the document:

2.2.5.  …
[Ballot comment]
Thank you for addressing my earlier DISCUSS. Below are a few minor questions/comments based on your most recent changes to the document:

2.2.5.  Structured Information

  When embedding the raw data, base64 encoding defined in Section 4 of
  [RFC4648] SHOULD be used for JSON IODEF while binary representation
  SHOULD be used for CBOR IODEF.

Why are you using SHOULD twice above? Is there any reason why you are not using MUST?

2.2.6.  EXTENSION

  Note that this data type is prepared in [RFC7970] as its generic

I think you meant "specified" here instead of "prepared".

  extension mechanism.  If a data item has internal structure that is
  intended to be processed outside of the IODEF framework, one may
  consider using StructuredInfo data type mentioned in Section 2.2.5.

In 3.2:

  o  The elements of ML_STRING type in XML IODEF document are presented
      as either STRING type or ML_STRING type in JSON IODEF document.
      When converting from XML IODEF document to JSON one or vice versa,
      the information contained in the original data of ML_STRING type
      must be preserved.  When STRING is used instead of ML_STRING,
      parsers can assume that its xml:lang is set to "en".  Otherwise it

I am not sure what "Otherwise" is used for here? Are you saying that the default
is either "en" or another value agreed by both receiver and sender?
If this is what you intended, then I think the sentence starting with "Otherwise"
is not correct, as it will cause non interoperable behaviour. I.e., if the default is
not "en", the language tag has to be specified in the JSON document.

      is expected that both receiver and sender have some external
      methods to agree upon the language used in this field.
2020-02-10
13 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2020-02-10
13 Alexey Melnikov Telechat date has been changed to 2020-02-20 from 2019-09-05
2020-02-10
13 Alexey Melnikov [Ballot comment]
Thank you for addressing my DISCUSS.
2020-02-10
13 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss
2020-02-10
13 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-13.txt
2020-02-10
13 (System) New version approved
2020-02-10
13 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2020-02-10
13 Takeshi Takahashi Uploaded new revision
2020-01-15
12 Benjamin Kaduk
[Ballot discuss]
We use a subset of the JSON "number" type to represent integers, which
inherits JSON's range limits on numbers.  My understanding is that …
[Ballot discuss]
We use a subset of the JSON "number" type to represent integers, which
inherits JSON's range limits on numbers.  My understanding is that such
limits are not present in IODEF XML (e.g., we do not specify a
totalDigits value), so this is a new limitation of the JSON format that
needs to be documented (and, technically, drops us out of full parity
with the XML form).

Can the shepherd please report on what level of validation has occurred
on the CDDL syntax, the mappings between RFC 7970's content and this
document's content, and the consistency between the formal syntax and
the body text (e.g., listings of enum values, member fields of each
type, etc.)?
2020-01-15
12 Benjamin Kaduk
[Ballot comment]
It's somewhat surprising to see CBOR used but with CBOR maps required to
use string form for representing map keys (i.e., no short …
[Ballot comment]
It's somewhat surprising to see CBOR used but with CBOR maps required to
use string form for representing map keys (i.e., no short integer key
values are defined).  Some of the strings that are map keys in the JSON
objects are fairly long; is this extra space not a concern for the
overall CBOR encoded document (e.g., due to containing a large quantity
of binary data such that encoding overhead is a small relative portion
of the encoded document)?

I guess that since it seems to only be used in (non-normative) Appendix
B, [jsonschema] can remain as an informative reference, though it would
be nice to have a citation where it is actually used in the document, as
opposed to just in the Introduction.  Since it is an informative
reference, the following point is not Discuss-worthy: The current
citation gives no absolute locator, leaving me somewhat unclear about
whether to consult draft-zyp-json-schema or something on json-schema.org
or some other source.  The contents of Appendix B suggest it is the
second of those...

Section 2.1

Using CBOR major type 2 for HEXBIN implies that actual binary values
are recorded directly, i.e., without any "hex" encoding.  We should be clear
about this one way or the other, and I didn't really see anything in the
CDDL schema that called this out.

Section 2.2.2

It's not claer to mey why using a plain text string is allowed for
representing a ML_STRING, as on the face of it that could lose language
information.  Is the idea that this is supposed to inherit from some
higher-level element, or just to reflect an efficiency of encoding when
neither of the optional language/translation-id fields are present?
Regardless, we should be more clear about that, since neither here nor
Section 5 includes any discussion thereof.  I see that Section 3.2 does
have a brief statement about this being a change from RFC 7970, but I'd
still like to see a little more clarity on this point.

Section 3.2
  o  The elements of ML_STRING type in XML IODEF document are presented
      as either STRING type or ML_STRING type in JSON IODEF document.

Why?

Section 6

I think we are making use of some fields whose content is controlled by
IANA, so we may wish to consider asking IANA to update the description
of the registry(ies) in question to include the JSON and CBOR usage.
2020-01-15
12 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2019-12-24
12 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-12.txt
2019-12-24
12 (System) New version approved
2019-12-24
12 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2019-12-24
12 Takeshi Takahashi Uploaded new revision
2019-11-18
11 Suresh Krishnan [Ballot comment]
Thank you for addressing my DISCUSS point with added text recommending against the use of the ipv6 netmask.
2019-11-18
11 Suresh Krishnan [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss
2019-11-18
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-11-18
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-11-18
11 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-11.txt
2019-11-18
11 (System) New version approved
2019-11-18
11 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2019-11-18
11 Takeshi Takahashi Uploaded new revision
2019-09-05
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-09-05
10 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-09-05
10 Alexey Melnikov
[Ballot discuss]
Well spotted by Mirja/Adam:

[RFC8259] should be a Normative reference.

Also please change the reference to [RFC7159] to point …
[Ballot discuss]
Well spotted by Mirja/Adam:

[RFC8259] should be a Normative reference.

Also please change the reference to [RFC7159] to point to [RFC8259].
2019-09-05
10 Alexey Melnikov Ballot discuss text updated for Alexey Melnikov
2019-09-05
10 Alexey Melnikov [Ballot discuss]
Well spotted by Mirja: [RFC8259] should be a Normative reference.
2019-09-05
10 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from Yes
2019-09-04
10 Barry Leiba [Ballot comment]
Ben has this well, well in hand: Thanks, Ben.  :-)
2019-09-04
10 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-09-04
10 Adam Roach
[Ballot comment]
Thanks for the work people put into this document. I have very little to add to what has already been commented on by …
[Ballot comment]
Thanks for the work people put into this document. I have very little to add to what has already been commented on by other IESG members, although id-nits did turn up some issues regarding the version of JSON being cited, and the apparent omission of a citation to RFC 8259 in the Normative Dependency section:

  == Missing Reference: 'RFC8259' is mentioned on line 157, but not defined

  == Missing Reference: 'RFC7159' is mentioned on line 202, but not defined

  ** Obsolete undefined reference: RFC 7159 (Obsoleted by RFC 8259)
2019-09-04
10 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-09-04
10 Benjamin Kaduk
[Ballot discuss]
We use a subset of the JSON "number" type to represent integers, which
inherits JSON's range limits on numbers.  My understanding is that …
[Ballot discuss]
We use a subset of the JSON "number" type to represent integers, which
inherits JSON's range limits on numbers.  My understanding is that such
limits are not present in IODEF XML (e.g., we do not specify a
totalDigits value), so this is a new limitation of the JSON format that
needs to be documented (and, technically, drops us out of full parity
with the XML form).

The JSON "examples" seem to be using a "//" notation for comments, that
is not valid JSON nor described by draft-zyp-json-schema, thus appearing
to make the examples malformed (absent some other disclaimer of the
commenting convention).

How does STRUCTUREDINFO relate to EXTENSION?  What makes one vs the
other appropriate for a given piece of information?  Since the former is
only in  RFC 7203 and not 7970, we do not have an easy reference for
their interplay, given 7970's minimal discussion of the use of 7203.
(It sounds like STRUCTUREDINFO is for structures from other published
specifications and EXTENSION is for more local/custom things, but I'm
not entirely sure if that's exactly the intended split.)

Can the shepherd please report on what level of validation has occurred
on the CDDL syntax, the mappings between RFC 7970's content and this
document's content, and the consistency between the formal syntax and
the body text (e.g., listings of enum values, member fields of each
type, etc.)?
2019-09-04
10 Benjamin Kaduk
[Ballot comment]
It's somewhat surprising to see CBOR used but with CBOR maps required to
use string form for representing map keys (i.e., no short …
[Ballot comment]
It's somewhat surprising to see CBOR used but with CBOR maps required to
use string form for representing map keys (i.e., no short integer key
values are defined).  Some of the strings that are map keys in the JSON
objects are fairly long; is this extra space not a concern for the
overall CBOR encoded document (e.g., due to containing a large quantity
of binary data such that encoding overhead is a small relative portion
of the encoded document)?

I guess that since it seems to only be used in (non-normative) Appendix
B, [jsonschema] can remain as an informative reference, though it would
be nice to have a citation where it is actually used in the document, as
opposed to just in the Introduction.  Since it is an informative
reference, the following point is not Discuss-worthy: The current
citation gives no absolute locator, leaving me somewhat unclear about
whether to consult draft-zyp-json-schema or something on json-schema.org
or some other source.  The contents of Appendix B suggest it is the
second of those...

Section 1

  processing is JSON.  To facilitate the automation of incident
  response operations, IODEF documents should support JSON
  representation.

Is it documents or implementations that should support the JSON
representation?

Section 2.1

The string "STRUCTUREDINFO" does not appear in RFC 7203, so I think we
need some additional locator information to indicate what behavior we're
referring to.

Using CBOR major type 2 for HEXBIN implies that actual binary values
are recorded directly, i.e., without any "hex" encoding.  We should be clear
about this one way or the other, and I didn't really see anything in the
CDDL schema that called this out.

Section 2.2.2

It's not claer to mey why using a plain text string is allowed for
representing a ML_STRING, as on the face of it that could lose language
information.  Is the idea that this is supposed to inherit from some
higher-level element, or just to reflect an efficiency of encoding when
neither of the optional language/translation-id fields are present?
Regardless, we should be more clear about that, since neither here nor
Section 5 includes any discussion thereof.  I see that Section 3.2 does
have a brief statement about this being a change from RFC 7970, but I'd
still like to see a little more clarity on this point.

  Examples are shown below.

  "MLStringType": {
    "value": "free-form text",                              //STRING
    "lang": "en",                                            //ENUM
    "translation-id": "jp2en0023"                          //STRING
  }

That looks more like a schema than an example (especially with those
//-comments!).  Also, nit-level, but there's only one, so "examples"
plural does not apply.

Section 2.2.4

  SoftwareReference class is a reference to a particular version of
  software.  Examples are shown below.

"class" seems to be the prevailing RFC 7970 terminology but is not used
much in this document; we seem to use "type" instead.

  "SoftwareReference": {
    "value": "cpe:/a:google:chrome:59.0.3071.115",    //STRING
    "spec-name": "cpe",                                //ENUM

RFC 7970 suggests that the value portion is interpreted solely within
the context defined by the "spec-name", so it's unclear to me if the
initial "cpe:" prefix in this example is representative.

Section 2.2.5

I'd suggest to add a sentence along the lines of "Note that the
structure of this information is not interpreted in the IODEF JSON, and
the word 'structured' indicates that the data item has internal
structure that is intended to be processed outside of the IODEF
framework.

  When embedding the raw data, base64 encoding defined in Section 4 of
  [RFC4648] SHOULD be used for encoding the data, as shown below.

Does this apply just to JSON or to CBOR as well?  I'm not sure if the
CBOR HEX encoding actually uses raw binary or not, which would be more
compact (and more recommendable?).

Section 3.1

[[I stopped verifying mappings at DetectionPattern]]

Section 3.2

  o  Attributes and elements of each class in XML IODEF document are
      both presented as JSON attributes in JSON IODEF document, and the
      order of their appearances is ignored.

Are there any practical consequences of this loss of information that we
should discuss?

  o  The elements of ML_STRING type in XML IODEF document are presented
      as either STRING type or ML_STRING type in JSON IODEF document.

Why?

Section 5

  SpecID = "urn:ietf:params:xml:ns:mile:mmdef:1.2" /  "private"

This enum is managed by IANA; shouldn't we have some sort of signal in
the CDDL to indicate it is extensible?  (Applies to any enum maintained
by IANA.)

  PortlistType = text .regexp "\\d+(\\-\\d+)?(,\\d+(\\-\\d+)?)*"

\d matches by unicode properties; I think that we want just [0-9] here?

Section 6

I think we are making use of some fields whose content is controlled by
IANA, so we may wish to consider asking IANA to update the description
of the registry(ies) in question to include the JSON and CBOR usage.

Appendix B

Is it more useful to have a non-normative JSON schema in the document,
or a pointer to a tool that can generate one from the CDDL?
(Alternately, how was this one generated -- were there any manual
modifications needed from the output of some tool?)
2019-09-04
10 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-09-04
10 Warren Kumari
[Ballot comment]
Thank you for this document -- like Linda Dunbar (the OpsDir reviewer), I'm wondering why this is Standards Track -- I looked in …
[Ballot comment]
Thank you for this document -- like Linda Dunbar (the OpsDir reviewer), I'm wondering why this is Standards Track -- I looked in the Shepherds Write Up hoping for some clue, but was unsuccessful finding any justification....
2019-09-04
10 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-09-04
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-09-04
10 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-09-03
10 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-09-03
10 Suresh Krishnan
[Ballot discuss]
* Section 5 (CDDL) and Appendix B (JSON schema)

I am trying to understand how "ipv6-net-mask" will be used since there is no …
[Ballot discuss]
* Section 5 (CDDL) and Appendix B (JSON schema)

I am trying to understand how "ipv6-net-mask" will be used since there is no such thing, and "ipv6-net" already covers the only possible way of denoting prefixes. Can you please clarify why and how you intend to use this? I remember reading and balloting on RFC7970 and it did not (IMHO rightly) have a category for this.
2019-09-03
10 Suresh Krishnan [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan
2019-08-30
10 Mirja Kühlewind
[Ballot comment]
One quick question: Shouldn't this document reference RFC8259 (normatively)? Or is it see as sufficient that it is referenced indirectly by RFC8610? …
[Ballot comment]
One quick question: Shouldn't this document reference RFC8259 (normatively)? Or is it see as sufficient that it is referenced indirectly by RFC8610?

And minor editorial comment: the introduction should probably also say something about CBOR.
2019-08-30
10 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-08-27
10 Roman Danyliw [Ballot comment]
Recuse. I am a co-author of this draft.
2019-08-27
10 Roman Danyliw [Ballot Position Update] New position, Recuse, has been recorded for Roman Danyliw
2019-08-26
10 Amy Vezza Placed on agenda for telechat - 2019-09-05
2019-08-23
10 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup
2019-08-23
10 Alexey Melnikov Ballot has been issued
2019-08-23
10 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2019-08-23
10 Alexey Melnikov Created "Approve" ballot
2019-08-23
10 Alexey Melnikov Ballot writeup was changed
2019-08-16
10 Derrell Piper Request for Last Call review by SECDIR Completed: Ready. Reviewer: Derrell Piper.
2019-08-01
10 Linda Dunbar Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Linda Dunbar. Sent review to list.
2019-08-01
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-07-26
10 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-07-26
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mile-jsoniodef-09, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mile-jsoniodef-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-07-23
10 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-10.txt
2019-07-23
10 (System) New version approved
2019-07-23
10 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2019-07-23
10 Takeshi Takahashi Uploaded new revision
2019-07-16
09 Robert Sparks Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Robert Sparks. Sent review to list.
2019-07-15
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derrell Piper
2019-07-15
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derrell Piper
2019-07-15
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2019-07-15
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2019-07-12
09 Takeshi Takahashi Added to session: IETF-105: mile  Mon-1810
2019-07-11
09 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2019-07-11
09 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2019-07-11
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-07-11
09 Amy Vezza
The following Last Call announcement was sent out (ends 2019-08-01):

From: The IESG
To: IETF-Announce
CC: ncamwing@cisco.com, draft-ietf-mile-jsoniodef@ietf.org, mile-chairs@ietf.org, mile@ietf.org, alexey.melnikov@isode.com …
The following Last Call announcement was sent out (ends 2019-08-01):

From: The IESG
To: IETF-Announce
CC: ncamwing@cisco.com, draft-ietf-mile-jsoniodef@ietf.org, mile-chairs@ietf.org, mile@ietf.org, alexey.melnikov@isode.com, Nancy Cam-Winget
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CBOR/JSON binding of IODEF) to Proposed Standard


The IESG has received a request from the Managed Incident Lightweight
Exchange WG (mile) to consider the following document: - 'CBOR/JSON binding
of IODEF'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Incident Object Description Exchange Format defined in RFC 7970
  provides an information model and a corresponding XML data model for
  exchanging incident and indicator information.  This draft gives
  implementers and operators an alternative format to exchange the same
  information by defining an alternative data model implementation in
  CBOR/JSON.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mile-jsoniodef/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mile-jsoniodef/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-07-11
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-07-11
09 Amy Vezza Last call announcement was changed
2019-07-11
09 Alexey Melnikov Last call was requested
2019-07-11
09 Alexey Melnikov Last call announcement was generated
2019-07-11
09 Alexey Melnikov Ballot approval text was generated
2019-07-11
09 Alexey Melnikov Ballot writeup was generated
2019-07-11
09 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-07-08
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-07-08
09 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-09.txt
2019-07-08
09 (System) New version approved
2019-07-08
09 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2019-07-08
09 Takeshi Takahashi Uploaded new revision
2019-06-17
08 Alexey Melnikov IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-04-24
08 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2019-04-15
08 Nancy Cam-Winget

1. Summary
This document proposes a JavaScript Object Notation (JSON) data model for the security incident reports and indicators as defined by the IODEF ( …

1. Summary
This document proposes a JavaScript Object Notation (JSON) data model for the security incident reports and indicators as defined by the IODEF (RFC 7970) data model.  While the IODEF information model has been instantiated in XML in RFC 7970, an alternative more compact data model using CDDL and JSON is defined in this document.   

2. Nancy Cam-Winget is the document shepherd and Alexey Melnikov is the responsible AD.

3. Review and Consensus
The MILE working group has been working on the JSON definition for roughly 18 months and has had good discussion and review.  There has been good support and agreement that IODEF needed an update from XML to JSON format representation and this draft has received several reviews.

4. Intellectual Property
The authors are in full compliance with BCPs 78 and 79 and there is no known IPR directly related to this document.

5. Other Points
The document is well written and been reviewed by both the working group participants as well as practitioners of IODEF, JSON and CDDL.  As the document shepherd, I see no issues with the document.
The document does not create any IANA registry requirements.
ID-Nits shows some warnings in the embedded CDDL, although in looking at the raw text it looks to be fine. 
2019-04-15
08 Nancy Cam-Winget Responsible AD changed to Alexey Melnikov
2019-04-15
08 Nancy Cam-Winget IETF WG state changed to Submitted to IESG for Publication from WG Document
2019-04-15
08 Nancy Cam-Winget IESG state changed to Publication Requested from I-D Exists
2019-04-15
08 Nancy Cam-Winget IESG process started in state Publication Requested
2019-04-15
08 Nancy Cam-Winget Changed consensus to Yes from Unknown
2019-04-15
08 Nancy Cam-Winget Intended Status changed to Proposed Standard from None
2019-04-08
08 Nancy Cam-Winget

1. Summary
This document proposes a JavaScript Object Notation (JSON) data model for the security incident reports and indicators as defined by the IODEF ( …

1. Summary
This document proposes a JavaScript Object Notation (JSON) data model for the security incident reports and indicators as defined by the IODEF (RFC 7970) data model.  While the IODEF information model has been instantiated in XML in RFC 7970, an alternative more compact data model using CDDL and JSON is defined in this document.   

2. Nancy Cam-Winget is the document shepherd and Alexey Melnikov is the responsible AD.

3. Review and Consensus
The MILE working group has been working on the JSON definition for roughly 18 months and has had good discussion and review.  There has been good support and agreement that IODEF needed an update from XML to JSON format representation and this draft has received several reviews.

4. Intellectual Property
The authors are in full compliance with BCPs 78 and 79 and there is no known IPR directly related to this document.

5. Other Points
The document is well written and been reviewed by both the working group participants as well as practitioners of IODEF, JSON and CDDL.  As the document shepherd, I see no issues with the document.
The document does not create any IANA registry requirements.
ID-Nits shows some warnings in the embedded CDDL, although in looking at the raw text it looks to be fine. 
2019-04-07
08 Nancy Cam-Winget Notification list changed to Nancy Cam-Winget <ncamwing@cisco.com>
2019-04-07
08 Nancy Cam-Winget Document shepherd changed to Nancy Cam-Winget
2019-04-01
08 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-08.txt
2019-04-01
08 (System) New version approved
2019-04-01
08 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2019-04-01
08 Takeshi Takahashi Uploaded new revision
2019-03-11
07 Takeshi Takahashi Added to session: IETF-104: mile  Tue-1120
2019-01-03
07 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-07.txt
2019-01-03
07 (System) Posted submission manually
2018-11-03
06 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-06.txt
2018-11-03
06 (System) New version approved
2018-11-03
06 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2018-11-03
06 Takeshi Takahashi Uploaded new revision
2018-11-02
05 Takeshi Takahashi Added to session: IETF-103: mile  Mon-1610
2018-10-22
05 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-05.txt
2018-10-22
05 (System) New version approved
2018-10-22
05 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2018-10-22
05 Takeshi Takahashi Uploaded new revision
2018-07-17
04 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-04.txt
2018-07-17
04 (System) New version approved
2018-07-17
04 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2018-07-17
04 Takeshi Takahashi Uploaded new revision
2018-07-09
03 Takeshi Takahashi Added to session: IETF-102: mile  Thu-0930
2018-03-18
03 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-03.txt
2018-03-18
03 (System) New version approved
2018-03-18
03 (System) Request for posting confirmation emailed to previous authors: Roman Danyliw , Mio Suzuki , Takeshi Takahashi
2018-03-18
03 Takeshi Takahashi Uploaded new revision
2018-03-17
02 Takeshi Takahashi Added to session: IETF-101: mile  Thu-1810
2018-01-11
02 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-02.txt
2018-01-11
02 (System) New version approved
2018-01-11
02 (System) Request for posting confirmation emailed to previous authors: mile-chairs@ietf.org, Mio Suzuki , Takeshi Takahashi
2018-01-11
02 Takeshi Takahashi Uploaded new revision
2017-11-11
01 Takeshi Takahashi This document now replaces draft-takahashi-mile-jsoniodef instead of None
2017-11-11
01 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-01.txt
2017-11-11
01 (System) New version approved
2017-11-11
01 (System) Request for posting confirmation emailed to previous authors: Mio Suzuki , Takeshi Takahashi
2017-11-11
01 Takeshi Takahashi Uploaded new revision
2017-11-10
00 Takeshi Takahashi Added to session: IETF-100: mile  Thu-1810
2017-09-27
00 Takeshi Takahashi New version available: draft-ietf-mile-jsoniodef-00.txt
2017-09-27
00 (System) WG -00 approved
2017-09-26
00 Takeshi Takahashi Set submitter to "Takeshi Takahashi ", replaces to (none) and sent approval email to group chairs: mile-chairs@ietf.org
2017-09-26
00 Takeshi Takahashi Uploaded new revision