JSON Binding of the Incident Object Description Exchange Format
draft-ietf-mile-jsoniodef-14
Yes
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
Recuse
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
Recuse
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? 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.
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
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.