Skip to main content

Design Considerations for Metadata Insertion
draft-hardie-privsec-metadata-insertion-08

Yes

(Alia Atlas)
(Ben Campbell)
(Stephen Farrell)

No Objection

(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Suresh Krishnan)

Note: This ballot was opened for revision 07 and is now closed.

Alia Atlas Former IESG member
Yes
Yes (for -07) Unknown

                            
Alissa Cooper Former IESG member
Yes
Yes (2017-03-15 for -07) Unknown
= 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 IESG member
Yes
Yes (for -07) Unknown

                            
Kathleen Moriarty Former IESG member
Yes
Yes (2017-03-13 for -07) Unknown
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 IESG member
Yes
Yes (2017-03-13 for -07) Unknown
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 IESG member
Yes
Yes (for -07) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2017-03-15 for -07) Unknown
I support this document, but I am not convinced that it will have the desired effect.
Alvaro Retana Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -07) Unknown