[mile] Alexey Melnikov's Yes on draft-ietf-mile-jsoniodef-13: (with COMMENT)

Alexey Melnikov via Datatracker <noreply@ietf.org> Mon, 10 February 2020 11:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mile@ietf.org
Delivered-To: mile@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F730120143; Mon, 10 Feb 2020 03:19:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-mile-jsoniodef@ietf.org, Nancy Cam-Winget <ncamwing@cisco.com>, mile-chairs@ietf.org, ncamwing@cisco.com, mile@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <158133359232.4113.3743042372265721969.idtracker@ietfa.amsl.com>
Date: Mon, 10 Feb 2020 03:19:52 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/H3VditLRQrSJuhIhp47DTgoLHi8>
Subject: [mile] Alexey Melnikov's Yes on draft-ietf-mile-jsoniodef-13: (with COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2020 11:19:52 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-mile-jsoniodef-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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


   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

      is expected that both receiver and sender have some external
      methods to agree upon the language used in this field.