[mile] AD review of draft-ietf-mile-jsoniodef-08

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 17 June 2019 19:04 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 05C771202AF for <mile@ietfa.amsl.com>; Mon, 17 Jun 2019 12:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AjAUNF3yJHAp for <mile@ietfa.amsl.com>; Mon, 17 Jun 2019 12:04:34 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com []) by ietfa.amsl.com (Postfix) with ESMTP id 068A91206D6 for <mile@ietf.org>; Mon, 17 Jun 2019 12:04:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1560798263; d=isode.com; s=june2016; i=@isode.com; bh=Odqu45oIQenXQ5IuDdR7/Ys7wYnAdpBX59JbGGxSqQs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IhpxHu2HfTXLjCVp0rQ/7mqZ6nI0xAnN4iqFSfTyXnfeoIJvJf9i38sAbhno4U6+xeXcJK 5NUhXXp6EpJ/iVjq6B3cYcOjwcvzHLzapIRfNz0jR1SlwO84+jOCO1c0OlHn7VG1qwL7OI PMiUB2c1EyvsdZPraPwBm3lenoDohJc=;
Received: from [] (dhcp-215.isode.net []) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XQfkNwBOeTGT@waldorf.isode.com>; Mon, 17 Jun 2019 20:04:23 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: "mile@ietf.org" <mile@ietf.org>
Message-ID: <7f1f695a-79c1-5c18-96ed-eeafef1c44d6@isode.com>
Date: Mon, 17 Jun 2019 20:04:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/WnnNoxjHOEpd0qSLvl65d-XtFCM>
Subject: [mile] AD review of draft-ietf-mile-jsoniodef-08
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 17 Jun 2019 19:04:36 -0000

Hi all,

Sorry for the delay, I have read the draft a couple of months ago, but 
didn't get around to writing down my review comments. Finally, here they 

In the Introduction:

    IODEF JSON provides all of the expressivity of IODEF XML.  It gives
    implementers and operators an alternative format to exchange the same

I find the document is lacking some text about motivation for doing the 
JSON representation. Can some text be added? Otherwise I can see other 
people would ask why bother?

In 2.1: ENUM

"ENUM"  is only defined in draft-zyp-json-schema-03, however 
draft-zyp-json-schema-04 has removed it. The draft is expired. I think 
you need a proper normative reference here or maybe you decide to remove 
this from the document.

Please use RFC 8610 as the reference for CDDL.

In Section 2.2.2:

URL needs a reference. Probably RFC 3986.

In Section 2.2.3:

    type is implemented as an object with "SpecID", "ext-SpecID",

    "ContentID", "dtype", "RawData", "Reference" elements.

Maybe I am confused, but in Section 5 I don't see "dtype" to be defined 
as a member of StructuredInfo.

In the same section:

"base64" needs a normative reference to RFC 4648. Please also include 
the section reference (Section 4 of RFC 4648 for base64 encoding or 
Section 5 of RFC 4648 for URL-safe base64 encoding).

In Section 3.2:

    o  This document treats attributes and elements of each class defined
       in [RFC7970] equally

Can you please clarify what you mean by "equally" in this context?

       and is agnostic on the order of their


In the same section:

Typo: reprensetend (should be "represented")

I realized that the same issue is present in the XML mapping, but can 
you clarify what would be the content of "EmailBody" is an email message 
has complicated MIME structure and includes multiple body parts?

Appendix B: can you please clarify whether this is Normative or Informative?

Thank you,