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

[Ballot comment]
= 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.

[Ballot comment]
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.

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-hardie-privsec-metadata-insertion-05.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-hardie-privsec-metadata-insertion@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Design considerations for Metadata Insertion) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Design considerations for Metadata Insertion'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-02-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IAB has published [RFC7624] in response to several revelations of
  pervasive attack on Internet communications.  This document considers
  the implications of protocol designs which associate metadata with
  encrypted flows.  In particular, it asserts that designs which do so
  by explicit actions of the end system are preferable to designs in
  which middleboxes insert them.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-hardie-privsec-metadata-insertion/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-hardie-privsec-metadata-insertion/ballot/


No IPR declarations have been submitted directly on this I-D.

There are some minor nits noted by I-D nits that we'll fix as we go.