Re: [mile] AD Review of RFC5070-bis IODEFv2

["Roman D. Danyliw" <[e-mail]>]

Thanks for this detailed review! I'll make the necessary changes.

Roman

> On Apr 26, 2016, at 1:51 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
> Thank you very much for your work on this draft!  It's a complex
> document and it reads very well.  I have a mix of comments and nits to
> be addressed before this goes to IESG review.  I also see that the
> IANA changes are requested to be done in the RFC editor queue, can we
> do that sooner to prevent multiple reviewers from commenting on the
> same thing?  I can find someone to help if needed.
> 
> In the introduction, there should be a summary of changes from
> RFC5070.  Change logs are usually deleted upon publication and last
> call reviewers usually look for this in the introduction.  A pointer
> to section 4.4 would be good as well here.
> 
> Section 3.3.1
> Did the WG discuss (sorry if I missed it), just replacing the values
> for TLP with what is there now?  Or are there other groups using what
> was there in v1?  Having duplication means that applications have to
> program in the equivalence, which is fine, just one more thing to do
> or that could cause confusion.
> 
> Section 3.9 Contact class
> 
> I noticed that nothing is required and wanted to make sure that is
> what the WG wanted for this class.  The class can be used with no
> required elements.
> 
> 3.18.2
> the category list is impressive!
> 
> Section 3.19
> Shouldn't this be TimeDomainWasChecked?
> DateDomainWasChecked
>      Zero or one.  DATETIME.  A timestamp of when the domain listed in
>      the Name class was resolved.
> 
> I had to read the description to realize it was a full timestamp,
> which is good as that's what incident handlers need.
> 
> 3.26
> I like the improvements to the HashData class!
> 
> 3.29.5
> The new way to represent expressions is pretty clear/easy to
> understand, which is good!  Especially for those that don't read.
> 
> Security Considerations section:
> 
> First paragraph - please explicitly mention that the data can be both
> security and privacy sensitive here.  Details can come later in a
> privacy section that needs to be added.
> 
> The privacy section should to include options for handling data in
> sensitive fields, such as using role based contact information instead
> of individuals contact info as well as protecting sensitive data with
> encryption (object level and transport MUST - but is covered in a
> transport).
> 
> Contact info (email, telephone, postalAddress, etc.), IPs,
> target/source information, any identifiers that can be linked to
> individuals.
> 
> RFC6973 is a great resource and a quick read.
> 
> Nits:
> 
> Section 2.15.1, "a" is repeated twice at the end of the flowing text:
> spec-name
>      Required.  ENUM.  Identifies the format and semantics of the
>      element body of this class.  Formal standards and specifications
>      can be referenced as well as a free-form text description with a a
> 
> Section 3.10.1
> change describes to described in the last line of the first paragraph:
> From: "to be describes in either free-form or machine readable form."
> To: "to be described in either free-form or machine readable form."
> 
> Section 3.14, 4th line, EvenData should be EventData
> "recursive definition of EvenData allows for the grouping of related"
> 
> Section 5, line 4, change "ad" to "add"
> There is support to ad additional enumerated values and new classes.
> 
> Schema/UML comparison
> 
> There is a mismatch between PostalAddress in the UML and the Schema in
> the Contact class.  The UML has it as 0-1 and the schema has it as
> 0-unbounded
> 
> <xs:element name="Contact">
>      <xs:complexType>
>        <xs:sequence>
>          <xs:element ref="iodef:ContactName"
>                      minOccurs="0" maxOccurs="unbounded"/>
>          <xs:element ref="iodef:ContactTitle"
>                      minOccurs="0" maxOccurs="unbounded"/>
>          <xs:element ref="iodef:Description"
>                      minOccurs="0" maxOccurs="unbounded"/>
>          <xs:element ref="iodef:RegistryHandle"
>                      minOccurs="0" maxOccurs="unbounded"/>
>          <xs:element ref="iodef:PostalAddress"
>                      minOccurs="0" maxOccurs="unbounded"/>
> 
> DomainData Class -
> This isn't an error, just a point of inconsistency.  MaxOccurs value
> is explicitly set here and not in other places since 1 is the default.
> 
> 
> Thank you!
> -- 
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile
>