Early Review of draft-grimminck-safe-ioc-sharing-10
review-grimminck-safe-ioc-sharing-10-artart-early-bray-2026-05-21-00
| Request | Review of | draft-grimminck-safe-ioc-sharing-10 |
|---|---|---|
| Requested revision | 10 (document currently at 12) | |
| Type | Early Review | |
| Team | ART Area Review Team (artart) | |
| Deadline | 2026-06-19 | |
| Requested | 2026-05-21 | |
| Requested by | Eliot Lear | |
| Authors | Stefan Grimminck | |
| I-D last updated | 2026-06-29 (Latest revision 2026-06-10) | |
| Completed reviews |
Artart Early review of -10
by Tim Bray
(diff)
Secdir Early review of -11 by Daniel Migault (diff) |
|
| Comments |
GOALS An independent submission review is meant to achieve two overarching goals: Is the document appropriate for publication as an independent submission? What improvements to the work should be made prior to publication? Reviews may be posted publicly on the RFC Editor web site, with author approval. In this posting, your anonymity will be respected if you requested it. ________________________________________________________________ CONTENTS OF REVIEWS Questions that the ISE would like you to answer: A. Is the subject of this document relevant to the RFC Series? Although the series was originally broadly scoped to include any aspect of computer networking, its scope has become centered on the Internet. This includes changes to the TCP, UDP, and IP protocols, services atop those protocols, formats that are transported by those protocols, as well as related hardware issues (e.g., how to run IP over X hardware). More speculative are documents specific to particular link layer or physical layer technologies. Your opinion here will be useful, although the Independent Submissions Editor, in consultation with the ISEB, will make the final decision. B. Is this document technically competent, as far as you can tell? Does the work build upon industry state-of-the-art? Are protocols and interfaces well specified? C. Is this document in reasonable (not necessarily final) editorial shape? Works should concisely and clearly make their point. Was it easy to discern the point, and could you understand the approach being offered? D. Are the Abstract and Introduction of this document reasonably clear? Does the introduction provide enough background for those Internet techies who may not be experts in the particular subject matter? Do the Title and Abstract fairly and accurately summarize the contents? E. Does the document make clear upfront how the specification does/does not relate to past or current IETF activities? F. How else can the document be improved? |
|
| Assignment | Reviewer | Tim Bray |
| State | Completed | |
| Request | Early review on draft-grimminck-safe-ioc-sharing by ART Area Review Team Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/art/to5HpD7ppzCgswcLeCJvGgOTcwA | |
| Reviewed revision | 10 (document currently at 12) | |
| Result | Ready w/nits | |
| Completed | 2026-05-21 |
review-grimminck-safe-ioc-sharing-10-artart-early-bray-2026-05-21-00
This is an ARTART early review. This document is in good shape. Speaking as a developer, I think that I could implement the processes it describes without too much difficulty. I'm a little surprised that the need for this exists, I'd have thought that infosec people would have the necessary guardrails in place. But I'll assume the demand is real. Nits: 1. I wonder if, in the title, it should be URI instead of URL. 2. Section 4. "an obfuscator that does not decode percent-encoded delimiters in the input MUST leave them as percent-encoded sequences" is hard to understand. What kind of obfuscator is that? An example would be helpful. 3. I'm wondering if it would be helpful to assert that people SHOULD NOT hand-edit obfuscated documents, because it would be really easy to break the obfusciation and thus reversability. 4. Section 4.3 "Bare IPv6 literals without surrounding URI brackets (e.g., "2001:db8::1" appearing on its own line in a report)" why the bit about "on its own line", wouldn't this be true also for a literal in running text, delimited by spaces or ()? 5. Section 4.3 "Implementations SHOULD recognize bare IPv6 by" - a bit arm-wavey, as an implementor I'd like to have a regexp or pseudocode algorithm for this. Hmm, last sentence of 4.3 blesses the use of "reasonable heuristics". The risk here is that the first popular open-source implementation makes choices that come to define what the interoperable base is. But maybe this is OK because of the excellent test vectors. 6. Section 4.4 "Implementations MAY instead extract each nested indicator and emit it as a separate obfuscated indicator alongside the primary one" Don't understand. An example would help. 7. Section 9. A bit redundant, feels like it's echoing things specified earlier 8. Section 10. This is excellent. It'd be good to stick this in a GitHub repo and ask implementors to enrich it. More is better. 9. Section 10. Maybe include an example of an IPv6 literal in running text? (see comment #4 above).