Subject: [mile] Comments on draft-ietf-mile-jsoniodef-06

From: Takahiko Nagata <[email-masked]>
Date: Tue, 20 Nov 2018 20:14:14 +0900

Dear Authors of draft-ietf-mile-jsoniodef-06,

This is Takahiko Nagata.
I would like to 9 comments on draft-ietf-mile-jsoniodef-06.

(1) Figure 1: JSON Data Types, RFC reference wrong, should refer RFC7203
"STRUCTURED" IODEF Data Type refer "RFC 7213".
But correctly, should refer "RFC 7203".

(2) Figure 2: CBOR Data Types, "INTEGER" IODEF Data Type shoud include 
Major type 0/1
"INTEGER" IODEF Data Type on draft-ietf-mile-jsoniodef-06
is only assinged Major type 6 tag 2/3.
(Positive bignum, Negative bignum)

But shoud include Major type 0/1,
(unsigned integer/negative integer, uint8-64)
because:
  (a) almost value in IODEF is enough length by uint8-64
  (b) CDDL prelude "integer" include int(uint(#0) / nint(#1))

(3) PAddressType should be choosen text / ML_String.
Now PAddressType is only define as MLStringType in CDDL.
 > PAddressType = MLStringType

But, in Figure 1: JSON Data Types, POSTAL is mapped both
string and ML_STRING.
So, PAddressType should be choosen both in CDDL.
 > PAddressType = MLStringType / text

(4) CDDL group choice of Node is wrong
In CDDL of IODEF, Node is defined as:
```
Node = {
  ( DomainData:[+ DomainData]
   ? Address:[+ Address]) /
  (? DomainData:[+ DomainData]
   + Address:[+ Address])
```
But to choice group, we should use "//" (double slash).
see: 2.2.2.  Choices of draft-ietf-cbor-cddl-05

(5) RFC7203 refers RFC 5070 (ex: sci:AttackPattern -> Reference)
For example, in CDDL of jsoniodef, Reference has "ReferenceName" property
and it's based on RFC7970.
```
Reference = {
  ? observable-id: IDtype
  ? ReferenceName: ReferenceName
...
ReferenceName = {
  specIndex: integer
  ID: IDtype
}
```

Some entity based on RFC7203 also refers "Reference",
but strictly along by RFC7203, we should refer "Reference" of RFC5070.
And this structre is difference between RFC7970 and RFC5070.
(ex: ReferenceName, enum in RFC7970, ML_STRING in RFC5070)
But we should not change as it is, I think it better.
(should refer "Reference" based on RFC7970, even if RFC7203 based item)

(6) In Section 2.2.3. StructuredInfo, we should update sample of RawData.
In Section 2.2.3,
```
    "StructuredInformation": {
      "SpecID": "oval",                                         //ENUM
      "RawData": "<<<strings encoded with base64>>>"            //BYTE
    }
```

In CDDL of IODEF,
```
StructuredInformation = {
...
  ? RawData: [+ ExtensionType]
```

(7) In Section 2.2.4. EXTENSION, we should update sample
In Section 2.2.4,
```
    "ExtensionType": {
      "value": "xxxxxxx",                                      //String
      "name": "Syslog",                                        //String
      "dtype": "string",                                       //String
```

In CDDL of IODEF,
```
ExtensionType  = {
  ? ssvalue: text
  ? name: text
  dtype: "boolean" / "byte" / "bytes" / "character" / "date-time" /
```
"value"->"ssvalue", type of dtype is ENUM.

(8) Need update IODEF Classes table(class Assessment)
In table IODEF Classes,
```
    +-----------------------------+--------------------+---------------+
    | Assessment                  | occurence?         |               |
      ...
    |                             | SystemImpact*      |               |
    |                             | BusinessImpact*    |               |
    |                             | TimeImpact*        |               |
    |                             | MonetaryImpact*    |               |
    |                             | IntendedImpact*    |               |
```

In CDDL of IODEF,
```
Assessment = {
...
  Impact: [+ {SystemImpact: SystemImpact} /
           {BusinessImpact: BusinessImpact} / {TimeImpact: TimeImpact} /
           {MonetaryImpact: MonetaryImpact} /
           {IntendedImpact: BusinessImpact}]
```

(9) missing observable-id of Expectation, In table IODEF Classes

Best Regards,
Takahiko Nagata

---

From: Takeshi Takahashi <[email-masked]>
Date: Fri, 30 Nov 2018 16:09:04 +0900

Dear Takahiro,

Thank you very much for your kind comments.
We have revised our draft to reflect your comments.
The latest version of the draft is already available on our github.

https://github.com/milewg/draft-ietf-mile-jsoniodef/blob/master/draft-ietf-mile-jsoniodef-06.txt.pdf

Let me reply each of your comments inline below.

> But correctly, should refer "RFC 7203".

Based on your comment, we've corrected it.

>   (b) CDDL prelude "integer" include int(uint(#0) / nint(#1))

Based on your comment, we've added those major types..

>  > PAddressType = MLStringType / text

Based on your comments, we've corrected the inconsistency.

> see: 2.2.2.  Choices of draft-ietf-cbor-cddl-05

Based on your comments, we've corrected it.

> ....

I concur your view.
The current RFC7970 refers the RFC7203, which refers to RFC5070.
This is a mess, and we should not inherit the mess.

Though this issue is outside the scope of this document itself, I'll
discuss this issue in the next meeting. (We may end up with adding
some text or filing an errata for RFC7203 and RFC7970.)

> ....

Based on your comment, we have fixed the inconsistency.

> "value"->"ssvalue", type of dtype is ENUM.

Based on your comment, we have fixed the inconsistencies.

> ....

Based on your comment,we have added it.

Thank you very much for your kind review.
Take

2018年11月20日(火) 20:14 Takahiko Nagata <[email-masked]>:
> ....
> ....
> ....
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

-- 
--
Takeshi Takahashi, Ph.D., CISSP, PMP
"Practice makes perfect!"