Ballot for draft-ietf-mile-implementreport
Yes
No Objection
Abstain
No Record
Note: This ballot was opened for revision 09 and is now closed.
Having an implementation report that actually provides references to available code is useful - as long as there is some permanence to the links.
Nevil Brownlee performed the OPS DIR review. Here is his feedback. I have performed an Operations Directorate review of draft-ietf-mile-implementreport-09 "This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups." This draft is a collection of information about Security Incident reporting protocols, and the implementation of systems that use them to share such information. It is simply a collection of information, it makes no attempt to compare the various standards or implementations. As such, it will be of interest to Network Operators who wish to collect and share such data. Operationally, Operators would need to decide which incident data collection group they want to be part of, that choice will strongly influence their choice of reporting protocol and applications to gather and distribute the data. The draft seems (to me) to need quite a bit of copy-editing, I list a few changes and suggestions below ... S1 RFC5070-bis. Is there an Internet Draft about this, or some other document you could reference? It's mentioned again in section 3.1, but there's nothing about it in the References section. S2.1 s/provides a solutions/provides solutions/ S2.3 s/IODEF formatted-message to/IODEF formatted-messages to/ s/by REN-ISAC are designed/by REN-ISAC is designed/ S3.2 "IODEF-SCI is the IETF draft" there's no reference to such a draft, there should be. "It also equips the interface ..." Exactly what does this mean? S4.2.2 s/prevents from accidentally/prevents accidentally/ s/ensure it is a well formed format/ ensure it is well formed/ S5.1 "General availability of Threat Central will be in 2014." It's now well into 2016 - this needs updating! Overall, I think the material in this draft is interesting, but it needs quite a bit of tidying/updating to get it ready for publishing.
Nevile Brownlee performed the opsdir review. I don't think the draft is entirely ready to publish and I hope some editing will ensue but I that in the hands of shepherd, and responsible AD. Hi all: I have performed an Operations Directorate review of draft-ietf-mile-implementreport-09 "This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups." This draft is a collection of information about Security Incident reporting protocols, and the implementation of systems that use them to share such information. It is simply a collection of information, it makes no attempt to compare the various standards or implementations. As such, it will be of interest to Network Operators who wish to collect and share such data. Operationally, Operators would need to decide which incident data collection group they want to be part of, that choice will strongly influence their choice of reporting protocol and applications to gather and distribute the data. The draft seems (to me) to need quite a bit of copy-editing, I list a few changes and suggestions below ... S1 RFC5070-bis. Is there an Internet Draft about this, or some other document you could reference? It's mentioned again in section 3.1, but there's nothing about it in the References section. S2.1 s/provides a solutions/provides solutions/ S2.3 s/IODEF formatted-message to/IODEF formatted-messages to/ s/by REN-ISAC are designed/by REN-ISAC is designed/ S3.2 "IODEF-SCI is the IETF draft" there's no reference to such a draft, there should be. "It also equips the interface ..." Exactly what does this mean? S4.2.2 s/prevents from accidentally/prevents accidentally/ s/ensure it is a well formed format/ ensure it is well formed/ S5.1 "General availability of Threat Central will be in 2014." It's now well into 2016 - this needs updating! Overall, I think the material in this draft is interesting, but it needs quite a bit of tidying/updating to get it ready for publishing. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
One high level comment: I personally would rather see this as an appendix of RFC5070bis than an own document. Minor comments: - Please add a refernce to RFC5070-bis - http://siis.realmv6.org/implementations/ - this link did not work for me. Should this information be hosted somewhere, were long-time hosting is guaranteed? - I don't understand the following sentence; is there a reference missing? "IODEF-SCI is the IETF draft that extends IODEF so that IODEF document can embed structured cybersecurity information (SCI)" - What is the following sentence suposed to tell me? "Note that users can enjoy this software with their own responsibility." - draft-field-mile-rolie-02 should also be a real reference; and maybe "XEP-0268 (http://xmpp.org/extensions/xep-0268.html)" as well? In general check references where needed. - This is in the past: "General availability of Threat Central will be in 2014" - There are also a couple of other nits (e.g. missing articles) that probably will be fixed by the RFC editor, but maybe double-check if you do an update.
I think that this document is already outdated and that it doesn't have any archival value — I am then ABSTAINing. I like the fact that the authors provide a link to a "more complete list of implementations", which (in my opinion) results in the archival value of this document to be lowered even more. [However, the link didn't load for me. :-(] The information in Section 5.1. (Threat Central, HP -- picking on this section just because it is the first one) reads like a marketing brochure ("…a security intelligence platform that enables automated, real-time collaboration between organizations to combat today's increasingly sophisticated cyber attacks…"), and it provides information that is obviously not current: "General availability of Threat Central will be in 2014".
I'm going to have to agree with Alvaro on this one. I do not understand the purpose of publishing this, since it seems to be a snapshot of an moving target. It will be out of date very quickly. I don't see how that is helpful, and can imagine it might be harmful if future readers treat this as current information. A paragraph or two about why is valuable as an RFC might help. This is reminiscent of an RFC 6982 "implementation status section", but that RFC explicitly recommends such sections be removed before publication. In any case, I also cannot load the page referenced at the end of section 1. Hopefully that's a transient problem, but please make sure at the end of section 1 works prior to publication. (And hopefully forever if the resulting RFC continues to reference it.)
I concur with Alvaro and Ben on this one. There is too much that is too close to marketing text and that would not really help an implementer or someone investigating these RFCs, or someone further developing those RFCs. It seems to me that only sections 7.1 and 7.4 contain the kind of information that I'd expect to find in an RFC like this. As far as I can see only those two sections actually refer to sections of, or content from, the RFCs concerned in a way that is useful to document in an RFC. I also could not access the URL in section 1. That seems like it really would need fixing. (I will admit that I may be somewhat biased here - IMO any document with 26+ occurrences of the string "cyber" is likely not a good candidate for an RFC;-)
I do agree with Alvaro's position that this document does not have much archival value.