Design Considerations for Metadata Insertion
RFC 8165

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

(Alia Atlas) Yes

(Ben Campbell) Yes

Alissa Cooper Yes

Comment (2017-03-15 for -07)
No email
send info
= 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.

(Stephen Farrell) Yes

Mirja Kühlewind Yes

Comment (2017-03-13 for -07)
No email
send info
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.

(Kathleen Moriarty) Yes

Comment (2017-03-13 for -07)
No email
send info
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.

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Alexey Melnikov No Objection

Comment (2017-03-15 for -07)
No email
send info
I support this document, but I am not convinced that it will have the desired effect.

Alvaro Retana No Objection