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

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