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