Skip to main content

JSON Binding of the Incident Object Description Exchange Format


No Objection

(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)


Note: This ballot was opened for revision 10 and is now closed.

Warren Kumari
No Objection
Comment (2019-09-04 for -10) Sent
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....
Roman Danyliw
Comment (2019-08-27 for -10) Not sent
Recuse. I am a co-author of this draft.
Alexey Melnikov Former IESG member
(was Discuss, Yes) Yes
Yes (2020-02-10 for -13) Sent
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?


   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.
Adam Roach Former IESG member
No Objection
No Objection (2019-09-04 for -10) Sent
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)
Alissa Cooper Former IESG member
No Objection
No Objection (for -10) Not sent

Alvaro Retana Former IESG member
No Objection
No Objection (for -10) Not sent

Barry Leiba Former IESG member
No Objection
No Objection (2019-09-04 for -10) Not sent
Ben has this well, well in hand: Thanks, Ben.  :-)
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-02-26 for -13) Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Not sent

Ignas Bagdonas Former IESG member
No Objection
No Objection (for -10) Not sent

Mirja K├╝hlewind Former IESG member
No Objection
No Objection (2019-08-30 for -10) Sent
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.
Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2019-11-18 for -11) Sent
Thank you for addressing my DISCUSS point with added text recommending against the use of the ipv6 netmask.