Subject: Re: [mile] Mail regarding draft-ietf-mile-rolie-csirt

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Mon, 22 Jul 2019 20:59:03 +0000

Chris,

Thanks for the review!

Responses below (in bold).

-Stephen

Section 4.1.2 has an empty bullet. And also one in 4.2.2.
-----
Fixed
-----

"that is required and recommended to expose in the MISP Manifest

      format.  THis ensures”

“THis" -> "This"

------
Fixed
------
Section 5:

"This section defines additional link relationships that

   implementations MUST support.  These relationships are not registered
   in the Link Relation IANA table as their use case is too narrow.
   Each relationship is named and described.”

This seems really bizarre.  Why not create the entries in the registry?  (I don’t buy into the narrow use case.)

------

We struggled with this when we first did RFC8322. The Link Relation IANA table contains a relatively small number of relations,
ones that have been registered for general use on the internet. It's stuff like "next" and "prev" and various versioning and archiving links.
I'm of the opinion that the links here in this draft are not for general use on the internet, and it's probably not worth the fight convincing IANA that they are, given that
it wouldn't add much (or any) value to the draft.

I'm happy to discuss if the group sees it differently.
------

Section 6.1 some awkward English:

"These

   categories IODEF content exposure provides valuable metadata for the
   searching and organization of IODEF documents.”

------

Fixed - I rewrote this sentence
------

Security considerations:

Is there any overlap/consideration about how the sharing parameters (private, public, etc.) would map into a ROLIE server?

------

Fixed - Good idea, I've added a new paragraph
------

chris