Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
I just have two small points, both of which should be easy to address.
-- Section 5 --
The shepherd writeup is silent about review by any XML schema experts. How
confident are we that the XML in here has had sufficient review?
-- Section 6 --
I question whether what's here is sufficient. Yes, it's important to ensure
confidentiality (etc.) of this sort of payload. But apart from that, are there
really no security or privacy concerns involved with reporting such things as
incident attack patterns, what software platform the attacks are being made on,
what vulnerabilities were exploited by the attacks, and so on? Is there really
nothing further to say here?
-- Section 1 --
The number of cyber attacks is growing day-by-day
Nit: You're not using "day by day" as an adjective here, so you shouldn't
hyphenate it. Similarly with "machine readable" in a few places:
"machine-readable information", but "the information is machine readable".
-- Section 4.5.1 ---
It is recommended
that Method class SHOULD contain the extension elements whenever
2119 usage point: "RECOMMENDED" and "SHOULD" mean the same thing, so why the
lower-case "recommended"? Why not this?:
It is RECOMMENDED
that Method class contain the extension elements whenever
This applies to subsequent sections, as well. You're inconsistent about whether
you include "SHOULD", but you are consistent in lower-case "recommended",
leaving me a little unsure. I prefer my version throughout, but whatevere you
choose, please make it consistent.
I support Barry's DISCUSS points.
I note that the all-caps "URGED" in Section 6 is defined in neither RFC 2119
nor RFC 6169. Might it be better to say "RECOMMENDED" here?
Thanks for handling my discuss points.
--- old comments below, I didn't check if they'd been
handled, feel free to ping me if I should check
- section 3, last para: does this mean we're putting up
IODEF as an alternative to NEA and/or SACM? I think it'd
be better to drop that use-case or if not to distinguish
it from other IETF protocols that do the same thing. (Or
maybe I'm confused?)
- 4.1: I get weirdness when I try to de-reference the
1st reference URI , is that just me? I get a
directory listing for the 2nd.  When I look at 
and load the xsd file I find there, I don't find the
string "AttackPattern." How is that IANA registry entry
going to be useful? It confuses me mightily;-)
- 4.1: I don't understand the last para at all
- 4.3: s/This draft/This specification/ (Same thing at
the start of section 5)
- section 5: Are you really asking that receiver's do
XML schema validation? You say "MUST be able to" which
is not quite the same, but generally doing schema
validation on the fly is very dangerous and error prone.
Maybe you mean that they MUST be able to process inputs
that conform to the relevant schema and fail-safe for
other inputs that don't conform? But at what level? Say
if an XML document is received that has a Remediation
element with no SpecID - should the entire input
Document be ignored or what?
- section 6: "URGED" in caps is odd, and saying "areas
of concern" but then only having one subsection seems
- section 6 generally: I support Barry's discuss
- section 6: Isn't this missing something about access
control and filtering outbound documents? Maybe all
that's needed is a reference to some other RFC, but
won't it be common to do such authorization and
- section 6: You mention signatures - do you mean use of
XMLDSIG? If so, a reference would be good and it'd be
even better to say which element might be signed, and to
check that that element has an ID so the signature
Reference can point to the to-be-signed data.
- section 7: In the absence of a definition of
Cybersecurity, I think its a bad idea to have an IANA
registry with that term in the title. (Just a personal