Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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.)?
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.
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.
Thank you for addressing my DISCUSS point with added text recommending against the use of the ipv6 netmask.
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....
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.
Ben has this well, well in hand: Thanks, Ben. :-)
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)
Recuse. I am a co-author of this draft.