Subject: [mile] Questions about Section 6.2 of draft-ietf-mile-implementreport-00

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 24 Jul 2014 14:38:22 +0000

Hello Daisuke and Chris!

Thanks for documenting implementation experiences in draft-ietf-mile-implementreport-00.

In your IETF 90 presentation on draft-ietf-mile-implementreport-00, section 6.2 was highlighted.

--[ Section 6.2, bullet point #1]--
IODEF has category attribute for NodeRole class.  Though various
categories are described, they are not enough.  For example, in
the case of web mail servers, you should choose either "www" or
"mail".  One suggestion is selecting "mail" as the category
attribute and adding "www" for another attribute.
--[end bullet point #1]--

I need help understanding whether a change is necessary in 5070bis. Currently a Node class can have multiple NodeRole children, so the following would be valid:

<Node>
   <NodeRole category="www" />
   <NodeRole category="mail" />
   ...

When the text states that the enumerated values in @category "are not enough", can you clarify what this means.  Is it that this attribute is missing an important enumerated value or that you'd like to compose them in some other way.

Per the provided example, I believe that webmail is such a significant type of service that we should add that as a distinct enumerate value

--[ Section 6.2, bullet point #2]--
The numbering of Incident ID needs to be considered.  Otherwise,
information, such as the number of incidents within certain period
could be observed by document receivers.  For instance, we could
randomize the assignment of the numbers.
--[end bullet point #2]--

Agreed.  This advice of randomizing the identifiers is a good one.  It should likely apply not just to IncidentID but also IndicatorID.  I'll add text to Section 9, Security Considerations.

Thanks for the feedback!

Roman

---

From: Eric Burger <[email-masked]>
Date: Thu, 24 Jul 2014 11:04:45 -0400

The definition of IncidentID is a string, not a number. The free text says “incident tracking number.”

Is there ANY reason for this to be a number? Relax that constraint, and you can say an IncidentID is a “globally unique identifier.” The good news is all you have to do is change “incident tracking number” in Section 3.4 to “incident tracking identifier.” We also should have text here and in the Security Considerations section pointing out a monotonically increasing integer is a very bad idea for the IncidentID.

Question for the community: are there implementations out there that ignored the XSD and the class definition and will crash if they see something like 
	<IncidentID name=“csirt.example.com”>magic1234hash</IncidentID>

???

On Jul 24, 2014, at 10:38 AM, Roman D. Danyliw <[email-masked]> wrote:
[snip]
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 28 Jul 2014 18:34:11 +0000

Hi Eric!

I think this suggestion is a good clarification.  The IncidentID and AlternativeID class only uses "incident tracking number" in the initial sentence of the descriptive paragraphs.  You're right, otherwise the rest of the text uses the term "identifier", and the element bodies are defined as xs:string.  Replacing "incident tracking number" with "incident tracking identifier" would be better language.

Roman

-----Original Message----
From: mile [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Thursday, July 24, 2014 11:05 AM
To: [email-masked]
Subject: Re: [mile] Questions about Section 6.2 of draft-ietf-mile-implementreport-00

The definition of IncidentID is a string, not a number. The free text says "incident tracking number."

Is there ANY reason for this to be a number? Relax that constraint, and you can say an IncidentID is a "globally unique identifier." The good news is all you have to do is change "incident tracking number" in Section 3.4 to "incident tracking identifier." We also should have text here and in the Security Considerations section pointing out a monotonically increasing integer is a very bad idea for the IncidentID.

Question for the community: are there implementations out there that ignored the XSD and the class definition and will crash if they see something like 
	<IncidentID name="csirt.example.com">magic1234hash</IncidentID>

???