Subject: [mile] AD review of draft-ietf-mile-enum-reference-format-06

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Jul 2014 17:49:04 -0400

Hello Adam, David, and others,

Nice job on the enum draft!  I just completed my review and have some
comments and suggestions included below.  I also looked at the apps area
review and agree that some of the language could be cleaned up a bit for a
newcomer to read it more easily.  Many of us have been working in this
space for a while and are used to the terminology, so his points were good
(IMO).  I have some suggestions to assist with his review and my own.

In the abstract, the apps area reviewer provided some alternate text that
looks helpful.  Minimally, the term external entities is too vague.  In
case you play with the language from what was there and what the apps
reviewer suggested, here is another suggestion:
s/reference external entities/reference enumeration values for other XML
schemas or data formats/

Introduction:
Consider the following change to the first sentence.
From: There is an identified need to specify a format to include relevant
   enumeration values in an IODEF document.
To: There is an identified need to specify a format to include relevant
   enumeration values from other data representation formats in an IODEF
document.

Section 2.  The use of the word reference would be confusing to someone new
reading this section when they reach the last use of this term in the first
paragraph as the usage changes.  A change to the phrase could help quite a
bit.  The apps reviewer provided alternate text that gets rid of that word
as well when correcting the issue with the term 'resulting'.  The below may
not be needed if the text is changed enough from the apps review, but I'm
listing it anyway so it is clear the current usage of the term reference
(last instance in this sentence) is also confusing.

From: There are several ways to
   accomplish this goal, but the most appropriate at this point is to
   require a specific format for the ReferenceName string of the IODEF
   [IODEF] Reference class, and use an IANA registry to manage the
   resulting reference formats.

To: There are several ways to
   accomplish this goal, but the most appropriate at this point is to
   require a specific format for the ReferenceName string of the IODEF
   [IODEF] Reference class, and use an IANA registry to manage the
   resulting values in the specified format.

Defining enumeration specification/format/data representation and values
would be very helpful to include in this section prior to the second
sentence of the second paragraph (or in a terminology section).  Then use
the terms enumeration format and enumeration values (or something else) as
opposed to 'enumerations' in case there is any doubt as to which is being
discussed.

Perhaps at the start of the third paragraph, the following change:
s/such enumerations/enumeration values/

Note: for what it worth, I like the apps reviewer's suggestion of SpecIndex.

Security Considerations:
Could you include a reference to the Security Considerations Section of
RFC5070 or the text?  The language on considerations for both
confidentiality (really CIA) and parsers could be important, especially if
this is used in combination with other standards or specifications instead
of IODEF.  The security considerations section in the RFC5070-bis draft is
a bit better than RFC5070.  If you reference the -bis version, then the
draft may get held up for publication until RFC5070-bis gets an RFC#.

You'll get asked about privacy and RFC5070's security considerations covers
that a bit as well.

For this draft specifically, a sentence or two on privacy would be good.
 Here is some text to help you get started:
This is establishing a container for publicly available enumeration values
to be included in an IODEF document, so the enumeration values themselves
may not include privacy-related information.  If the Reference class
includes an enumeration value in combination with other data in an IODEF
document, the resulting combination could expose information.  An example
might include attack vectors or system descriptions used in a
privacy-related incident.

A pointer back to IODEF on this should be sufficient to have the sender of
the IODEF document sender convey a privacy policy using the
iodef:restriction attribute. Then protections described in RFC5070's
security considerations section for confidentially, integrity, and
authenticity can be used - RID or maybe at some point PLASMA (but that's
probably not far enough along yet).

I think that's it.

Thanks!

-- 

Best regards,
Kathleen

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 3 Jul 2014 11:17:51 -0500

Kathleen,

Thank you for your review.  I’m going to be responding to Tim’s app review shortly.  I will fold some of your suggestions into that response (thank you), and then address your distinct comments separately.

Regards,

Adam

On Jul 1, 2014, at 4:49 PM, Kathleen Moriarty <[email-masked]> wrote:

> Nice job on the enum draft!  I just completed my review and have some comments and suggestions included below.  I also looked at the apps area review and agree that some of the language could be cleaned up a bit for a newcomer to read it more easily.  Many of us have been working in this space for a while and are used to the terminology, so his points were good (IMO).  I have some suggestions to assist with his review and my own.
> 
> In the abstract, the apps area reviewer provided some alternate text that looks helpful.  Minimally, the term external entities is too vague.  In case you play with the language from what was there and what the apps reviewer suggested, here is another suggestion: 
> s/reference external entities/reference enumeration values for other XML schemas or data formats/
> 
> Introduction:
>    enumeration values from other data representation formats in an IODEF document.  
> 
> Section 2.  The use of the word reference would be confusing to someone new reading this section when they reach the last use of this term in the first paragraph as the usage changes.  A change to the phrase could help quite a bit.  The apps reviewer provided alternate text that gets rid of that word as well when correcting the issue with the term 'resulting'.  The below may not be needed if the text is changed enough from the apps review, but I'm listing it anyway so it is clear the current usage of the term reference (last instance in this sentence) is also confusing. 
> 
> Defining enumeration specification/format/data representation and values would be very helpful to include in this section prior to the second sentence of the second paragraph (or in a terminology section).  Then use the terms enumeration format and enumeration values (or something else) as opposed to 'enumerations' in case there is any doubt as to which is being discussed.
> 
> Could you include a reference to the Security Considerations Section of RFC5070 or the text?  The language on considerations for both confidentiality (really CIA) and parsers could be important, especially if this is used in combination with other standards or specifications instead of IODEF.  The security considerations section in the RFC5070-bis draft is a bit better than RFC5070.  If you reference the -bis version, then the draft may get held up for publication until RFC5070-bis gets an RFC#.
> 
> You'll get asked about privacy and RFC5070's security considerations covers that a bit as well.   
> 
> For this draft specifically, a sentence or two on privacy would be good.  Here is some text to help you get started:  
> This is establishing a container for publicly available enumeration values to be included in an IODEF document, so the enumeration values themselves may not include privacy-related information.  If the Reference class includes an enumeration value in combination with other data in an IODEF document, the resulting combination could expose information.  An example might include attack vectors or system descriptions used in a privacy-related incident.  
> 
> A pointer back to IODEF on this should be sufficient to have the sender of the IODEF document sender convey a privacy policy using the iodef:restriction attribute. Then protections described in RFC5070's security considerations section for confidentially, integrity, and authenticity can be used - RID or maybe at some point PLASMA (but that's probably not far enough along yet).
> 
> I think that's it.
> 
> Thanks!
> 
> -- 
> 
> Best regards,
> Kathleen
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile