JSON binding of IODEF
draft-ietf-mile-jsoniodef-10

Summary: Needs a YES. Has 3 DISCUSSes. Needs 2 more YES or NO OBJECTION positions to pass.

Benjamin Kaduk Discuss

Discuss (2019-09-04)
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.)?
Comment (2019-09-04)
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?)

Suresh Krishnan Discuss

Discuss (2019-09-03)
* 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.

Alexey Melnikov (was Yes) Discuss

Discuss (2019-09-05)
Well spotted by Mirja/Adam:

[RFC8259] should be a Normative reference.

Also please change the reference to [RFC7159] to point to [RFC8259].

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Warren Kumari No Objection

Comment (2019-09-04)
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....

Mirja Kühlewind No Objection

Comment (2019-08-30)
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.

Barry Leiba No Objection

Comment (2019-09-04)
Ben has this well, well in hand: Thanks, Ben.  :-)

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2019-09-04)
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)

Roman Danyliw Recuse

Comment (2019-08-27)
Recuse. I am a co-author of this draft.

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record