Design Considerations for Metadata Insertion
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana No Objection
(Alia Atlas; former steering group member) Yes
(Alissa Cooper; former steering group member) Yes
= Section 5 = "It would not be available at all during this period" -- this seems to be imagining an alternative reality where the forwarded header is not already inserted by proxies, which confused me. I think this first paragraph either needs to be clear that it is imagining an alternative history in which the forwarded header was never inserted by proxies, or it should not include the quoted text above, since at this point one could wait for browsers to be upgraded to support a client-based insertion mechanism while proxies are still inserting the same info. = Section 7 = Is there some citation that could be provided to support the assertion that network-provided location is "often" more coarse than device-provided location? I have been inclined to believe it but it seems like a mildly contentious claim.
(Ben Campbell; former steering group member) Yes
(Kathleen Moriarty; former steering group member) Yes
Section 3 just has one design pattern, restoration of data, right? Should the heading be design pattern and not design patterns or are you considering data minimization a design pattern too? I don't think so, but wanted to ask for clarity in the document. Section 4 then starts off with a statement: "Avoid this design pattern". I think it would be clearer to reword as, "Avoid the restoration of information design pattern" or make it clear that section 3 is talking about one design pattern (like the introduction). Theres a word left out in section 5, 3rd paragraph "There also tensions with latency of operation." s/There also/There are also/ Section 7, second sentence: s/metadat/metadata I also agree with the SecDir reviewers comments: https://mailarchive.ietf.org/arch/msg/secdir/8buJWINMRQmtN0Ls78yFAPjr3ug The suggested updates don't appear to have made it to this last version. Are changes coming to clarify the text? I can't tell from the end of that thread.
(Mirja Kühlewind; former steering group member) Yes
I fully support the publication of this document, however, given this is not an IAB document (anymore), I would recommend to do some more re-wording to rather talk about a design pattern that should be applied in future protocol design work than to give advise about what should not be done. Also I think it would be good to add a little bit more text that further discusses/explains that endpoints may also need a way to detect middlebox insertion/manipulation to provide an incentive to support host-based explicit actions for metadata provisioning.
(Stephen Farrell; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
I support this document, but I am not convinced that it will have the desired effect.
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection