Subject: [mile] Stephen Farrell's No Objection on draft-ietf-mile-rfc5070-bis-25: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 07 Jul 2016 02:42:02 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-mile-rfc5070-bis-25: No Objection

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/

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

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.