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

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Mon, 08 July 2019 07:57 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5AD120121 for <mile@ietfa.amsl.com>; Mon, 8 Jul 2019 00:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS6wmvYyfwVH for <mile@ietfa.amsl.com>; Mon, 8 Jul 2019 00:57:02 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id B1E22120118 for <mile@ietf.org>; Mon, 8 Jul 2019 00:57:01 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTPS id x687v05G052134; Mon, 8 Jul 2019 16:57:00 +0900 (JST)
Received: from mailfs.nict.go.jp (mailfs.nict.go.jp [133.243.18.9]) by gw2.nict.go.jp with ESMTP id x687v0TA052131; Mon, 8 Jul 2019 16:57:00 +0900 (JST)
Received: from LAPTOP9DLCDU5S (ssh1.nict.go.jp [133.243.3.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailfs.nict.go.jp (NICT Mail Spool Master Server) with ESMTPSA id 220097C82AB; Mon, 8 Jul 2019 16:57:00 +0900 (JST)
From: "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp>
To: "'Alexey Melnikov'" <alexey.melnikov@isode.com>, <mile@ietf.org>
References: <7f1f695a-79c1-5c18-96ed-eeafef1c44d6@isode.com>
In-Reply-To: <7f1f695a-79c1-5c18-96ed-eeafef1c44d6@isode.com>
Date: Mon, 8 Jul 2019 16:56:59 +0900
Message-ID: <174c301d53562$b8cff040$2a6fd0c0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: ja
Thread-Index: AQIIVKMcgG02zWRayXYE2A4G8S9iuKZaEoTg
X-Virus-Scanned: clamav-milter 0.101.2 at zenith2m8
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/5jtRiTx9Yz4_xwIsyJlQpNluPR4>
Subject: Re: [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, 08 Jul 2019 07:57:05 -0000

Hi Alexey,

Thank you very much for your kind review.
We have just submitted the revision (09 version).

Let me reply how we have addressed your comments below.

> 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
>     information.
>
> 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?

Thank you. The abstract and introduction were changed accordingly.

> 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.

Thank you. The references were changed.
Some types are now defined in this document (in Section 2.2) to avoid the
reference problem.

> In Section 2.2.2:
>
> URL needs a reference. Probably RFC 3986.

Changed. Thank you.

> In Section 2.2.3:
>
>     The STRUCTUREDINFO data
>     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.

"dtype" is removed now. Thank you.

> 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).

The reference is added. Thank you.

> 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
>
>        appearances.

The sentence was rewritten to avoid the word "equally". Thank you.

> In the same section:
>
> Typo: reprensetend (should be "represented")

Corrected. Thank you.
There were other typos throughout the document. We've corrected them.

> 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?

This is explained now in Section 3.2 (last bullet). Thank you.

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

This section is informative. This is now clearly written at the beginning of
Appendix. B.
Thank you.

Best regards,
Take




-----Original Message-----
From: mile <mile-bounces@ietf.org>; On Behalf Of Alexey Melnikov
Sent: Tuesday, June 18, 2019 4:04 AM
To: mile@ietf.org
Subject: [mile] AD review of draft-ietf-mile-jsoniodef-08

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
are:

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
    information.

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:

    The STRUCTUREDINFO data
    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

       appearances.

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,

Alexey

_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile