Subject: [mile] IODEF2 5070-bis-14 notes after reading

From: Tomáš Čejka <[email-masked]>
Date: Thu, 01 Oct 2015 21:41:52 +0200

Hello,
I've read the current version of IODEF2
(https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/) and I
have some notes.
I don't know if it is the latest version, maybe some of my notes are
already solved.

1) P22 ThreatActor Class
  Figure contains "Actor". Should it be "Actor" instead of "ThreadActor"?

2) Sec. 3.9 P25 (P stands for page) HEXBIN data type
  I think it would be helpful to specify byte order of data in HEXBIN
(network or host order?). It is used for frame, packet, ipv4-packet,
ipv6-packet.
  In addition, what should be content of e.g. ipv4-packet in comparison
to frame? Is the data type in this context just "a label" that should
make parsing faster?

3) P36 Application " . One. The application"
  Something is missing before "One"?

4) P86 Certificate
  I am missing a 'meaning'/'description' attribute.  This attribute
would explain where does the certificate come from or what it was used for.

5) P103 contains TODO

6) P104 "The IndicatorReference class has one attributes:"
  Combination of "one" and "attributes" seems to me as a mistake.

7) P107 'All attributes of with a name prefixed by "ext-" have been
removed.'
  "of with" seems to me as a mistake.
  Is this statement really true? I saw some occurences of "ext-"
attributes such as ext-value, ext-type, ext-offsetunit

8) Sec. 5.2 P111 example: probably missing end of Incident element
(</Incident>)

9) P164 "The IODEF parser should handle this content with care to
prevent unintentional automated execution."
  I would prefer usage of "MUST" instead of "SHOULD", since the
manipulation with malicious code can be dangerous...

I have some language related notes, however, English is not my native
language. So I believe you will reject anything that I mention by my
mistake:

10) P9 "data types are implement as"
  "implemented as"?

11) P19 "This identifier can then used to reference"
  I miss "be" - maybe: "identifier can be used"?

12) P62 "A free-from description"
  "form" instead of "from"

13) P72 "The domain contact information associated with this domain
should be used in lieu of explicit definition with the Contact class."
  I would suggest to avoid "in lieu of" because it complicates the
readability (even though I have found the meaning using
www.thefreedictionary.com). I think it can be written in some simpler way...

14) P78 "Identifies the format and semantics of the the
element body of this class."
  "the the" is probably a mistake

Regards,
Tomas Cejka

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 14 Oct 2015 15:10:28 +0000

Hello Tomas!

Thank you for the detailed feedback.  Your review is very much appreciated.  Detailed comments are inline.  Expect your changes to incorporated into the -15 draft by the end of the week.

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Tomáš Cejka
> Sent: Thursday, October 01, 2015 3:42 PM
> To: [email-masked]
> Subject: [mile] IODEF2 5070-bis-14 notes after reading
> 
> Hello,
> (https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/) and I have
> some notes.
> I don't know if it is the latest version, maybe some of my notes are already
> solved.

-14 was the latest.  It's the one you reviewed.

>   Figure contains "Actor". Should it be "Actor" instead of "ThreadActor"?

Correct.  Fixed.

>   I think it would be helpful to specify byte order of data in HEXBIN (network
> or host order?). It is used for frame, packet, ipv4-packet, ipv6-packet.
>   In addition, what should be content of e.g. ipv4-packet in comparison to
> frame? Is the data type in this context just "a label" that should make parsing
> faster?

I need help understanding your observation.  HEXBIN is xs:hexBinary, Schema's way of transcoding any binary octet (or stream of octets) into text.  Are you suggesting that we specify a given byte order when using HEXBIN for the frame, ipv4-packet, etc.?

The difference between an ipv4-packet and frame is that a frame may have layer 2 information.

>   Something is missing before "One"?

Fixed.  There was an extra period.

> 4) P86 Certificate
>   I am missing a 'meaning'/'description' attribute.  This attribute would explain
> where does the certificate come from or what it was used for.

Makes sense.  Certificate/Description has been added.

> 5) P103 contains TODO

The write-up on IndicatorExpression parsing needed a detailed write-up.  It will be in -15.

>   Combination of "one" and "attributes" seems to me as a mistake.

Fixed.  This turned out to be a common typo.

> 7) P107 'All attributes of with a name prefixed by "ext-" have been removed.'

Fixed.  The draft has gone back and forth a few times on how to revise attributes.  The text hasn't up to date.  "ext-" attributes are still valid so this statement was removed.

> 8) Sec. 5.2 P111 example: probably missing end of Incident element

Fixed.  Adding the closing </Incident> makes this snippet much more readable.

> 9) P164 "The IODEF parser should handle this content with care to prevent
> unintentional automated execution."

Agreed.  The text now reads MUST.

> language. So I believe you will reject anything that I mention by my

Your proof reading was very helpful!

> 10) P9 "data types are implement as"

Fixed.

>   I miss "be" - maybe: "identifier can be used"?

Fixed.

> 12) P62 "A free-from description"

Fixed.

> 13) P72 "The domain contact information associated with this domain should
> be used in lieu of explicit definition with the Contact class."
>   I would suggest to avoid "in lieu of" because it complicates the readability
> (even though I have found the meaning using www.thefreedictionary.com).
> I think it can be written in some simpler way...

Fixed.  The text now uses "instead of".
 
> 14) P78 "Identifies the format and semantics of the the element body of this
> class."

Fixed.

Thanks!
Roman