Stephen Farrell has entered the following ballot position for
draft-ietf-mile-rfc5070-bis-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------



(1) 3.6: Does one confidence value apply to all of these?
That seems wrong. And over-confidence is attributing
threat actor identity is a real issue with real
consequences, hence the discuss to make sure we bottom out
on this. I think it's just too error-prone to be ablve to
associate one confidence value with two things about
which one can have very different concreteness. Mixing up
high confidence in a campaign with a lack of confidence
in threat actor identification is precisely the kind of
thing that goes wrong, or that could be deliberately
manipulated (for eventual media/marketing reasons).
(This overlaps with but isn't quite the same as Alissa's
2nd discuss point. In this case, I'm explicitly worried
about the threat actor identity confidence, as that has
possibly severe impacts, so the resolution here could
differ from what results from Alissa's discuss.)

(2) 3.18.1 - you provide a way to specify e.g. an address
and netmask, or v6 prefix. But you don't specify any way
to say that some of the address (or prefix) bits are not
real or are additionally masked for privacy reasons. E.g.
If everyone in 2001:1:1:beef::/64 is misbehaving, but I
don't (yet) want to specify the exact prefix, I might
want to say " some 2001:1:1:xxxx::/64" is misbehaving,
meaning one /64 in 2001:1:1::/48 is being bad and not the
entire /48. Why is support for that not required?  (IPFIX
does have that as an option, and it's been added to CDNI
too.) Same idea can apply to other address forms too.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- 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.