The Incident Object Description Exchange Format Version 2
draft-ietf-mile-rfc5070-bis-26

Thank you for addressing my DISCUSS and COMMENT.

I am out of my depth here…

I noticed that rfc6685 Updated rfc5070, which this document Obsoletes.  rfc6685 just "specifies additional expert reviews for IODEF extensions".  But a similar consideration was not included in the bis.  Is it not needed?

Should this document also Obsolete rfc6685?

I concur with Alissa's and Alexey's discuss points.

Additionally, I think the rest of the points in Robert Spark's secdir review[1] deserve responses.

The shepherd writeup mentions a desire for more XML review. Did that occur? (I note that it also says the XML had been mechanically verified.)

[1] https://mailarchive.ietf.org/arch/msg/mile/0Io60Sdn--hRzQWN3Q0keCYIA1w

From a quick assessment of this bis document, I believe there are no OPS aspects to look at.

Thanks for handling my discuss.

- comments below were on -22, I didn't check if they'd been
addressed or not. (Happy to chat more if that's useful)

- My review is based on [1]
[1] https://tools.ietf.org/rfcdiff?url1=rfc5070&url2=draft-ietf-mile-rfc5070-bis-22

- "cyber" galore - yuk! Which of the fourteen (14!) uses
of that ill-defined marketing term are useful or even
well defined?  RFC5070 had zero uses of such terms. Why
is it a good plan for us to damage the RFC series via the
use of such marketing nonsense? Someone may answer that
this is accepted in industry these days, and that is
true, but is nonetheless not a good enough reason for us
to assist with the promulgation of anti-scientific
non-concepts. My suggestion is to try s/cyber//g and then
to see what if anything is less clear - perhaps we'll
find that things are more clear. (And yes, it's a bit of
a bugbear of mine:-) The use of "cyber indicator" instead
of just "indicator" in 3.19 is a good example of how that
phrase makes the spec less clear. 

- 2.5.1, does base64 need a reference and aren't there
multiple variants (url-encoded, etc, sorry for being
vague - I have to look that stuff up afresh every time I
need to write code to handle it;-)

- 2.8: So you don't like leap-seconds? It's often good to
be clear if that bit of ABNF is expected to be enforced
along with schema validation or not. 

- 2.12: What about EAI?

- 3.13.1 - is CoA expanded somewhere? (See, I just looked
at the diff:-)

- 3.18.1 - I think it'd be good to refer to the RFC for
wriing down IPv6 addresses and prefixes. I forget it's
number though:-) And who uses ipv6-net-mask? Don't we all
use prefixes?

- 3.21 - the hash and signature data are underspecified.
You could mean any of pgp, smime or dkim. Or you could
mean this is just a crypto binary value and you don't
care about semantics, just pattern matching.

- 4.3 - I also think that recommending schema validation
of input documents is a bad plan. (Even if that was
already in 5070.)

- section 9: defining how to format privacy sensitive
data means that this spec absolutely does introduce
privacy issues.

- 9.1: you could not here the DoS and possible other
attacks (e.g. spoofed .xsd files loaded over port 80)
that follow on from on-line schema

- 9.2: Have there been any cases of people using IODEF
for bad reasons? I mean that e.g. sending info about
attacks or phish emails is good. But using this format to
send information about tracking an individual for
marketing purposes would be bad. Has the latter occurred
though?  (Just wondering, I don't know.) validation.