Reviewer: Bron Gondwana Review result: Ready with Nits I'm the ARTART reviewer for this document. Ouch, 200 pages! I admit I didn't read all the examples, just grepped them for keywords. I do appreciate giving many examples to help implementations check their behaviour against those examples; and wish there was a way to do so by reference without including them inline in a document which is rendered as paginated text. Generally I'm very impressed with the clarity of writing; as with draft-ietf-lamps-e2e-mail-guidance which I also reviewed, it's a pleasure to read this document. I have no editorial comments. My one concern with HP-Removed and HP-Obscured is that some or any of these could be multi-valued headers; and it would be possible to remove or obscure a header (with the more complex hcp algorithms; hcp_minimal only affects a header which SHOULD be single-valued) and have legimitate intermediates add another header with the same name. This is somewhat handled by the language in this draft around things like "List-Unsubscribe", but if the sender happened to have one of these and protect it, then an intermediate adding it might be unintentionally making the message appear to be tampered with. And the intermediate can't know that this header is being tamper protected; because the HP-Obscured and HP-Removed headers are NOT visible to the intermediate. My initial proposal around this was to have some kind of count in HP-Obscured (or multiple of them with the same name), and any multi-valued header, include one per removal in HP-Removed - but I'm unsure whether this is overthinking things. Bron. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
