[DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Thu, 16 February 2017 01:27 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dmm@ietf.org
Delivered-To: dmm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFC7129463; Wed, 15 Feb 2017 17:27:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com>
Date: Wed, 15 Feb 2017 17:27:14 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/NwUVZOHREOH9WAD4oaearHAurv0>
Cc: max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org
Subject: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 01:27:14 -0000
Stephen Farrell has entered the following ballot position for draft-ietf-dmm-4283mnids-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't consider that merely mentioning that there are some privacy issues (maybe) is nearly sufficient here. Instead I would argue that any of these identifier types that could have privacy implications need to be specifically justified or else dropped. By specifically justified, I mean that there ought be an argument (and a fairly holistic one) that the Internet is better, and not worse, if we define a codepoint that allows MIPv6 (and later, other protocols) to use that identifier. I do accept that my position is perhaps innovative, in terms of IETF processes, so I'll split the discuss into two parts, one process oriented and mostly for the IESG, and the second relating to the content of the draft. (1) For the IESG: is it ok that we introduce (codepoints for) a slew of new long-term stable privacy-sensitive identifiers just because they might someday be needed, or do we need to have specific justification for defining such things? I would argue the latter, but that may need us to validate that there is IETF consensus for that somehow, and perhaps in the meantime hold on to this draft. Part of my reasoning is that once we define such codepoints (e.g. for IMSIs) then that inevitably means that other protocols, and not just MIPv6, will do the same eventually, so accepting this draft basically means accepting that we end up commonly and perhaps carelessly, passing such highly-sensitive information about on the Internet in many protocols and in many contexts. My argument here I think does adhere to various of our BCPs that do argue for security and privacy, but I do also accept that this may be novel and to some extent goes against another of our generally accepted ideas which is that we benefit from folks documenting things even if those things are sub-optimal in various ways. So I'd argue this is a real case for an IESG discussion - I know what I think, but what do the rest of you think? (2) For the authors: to the extent you are willing to, and want to get ahead of the discussion on point (1) above, can you in fact provide an argument, for each of the identifiers here that have privacy-sensitivity, that the Internet is better overall if we define these codepoints knowing that if we do define a way to represent e.g. an IMSI in MIPv6 that is likely to be copied elsewhere? Note for the authors: I think it's entirely fine for you to do nothing pending the discussion of point (1) above, if that's your preference. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While I'm entirely sympathetic to Mirja's discuss point, I don't think that a statement here can really constrain how these identifiers, once they are defined, are used in other protocols. While there is a chance that some IESG sometime might say "hold on, RFCxxxx (this doc) says you SHOULD encrypt if <that> identifier is used" the chances that a future IESG notice this isn't that high, but it's also even more likely that the designers of future protocols will successfully argue that since not all identifiers are privacy sensitive, their specific protocol need not adhere to the SHOULD. In the end, I think that should or SHOULD will be ineffective.
- [DMM] Stephen Farrell's Discuss on draft-ietf-dmm… Stephen Farrell
- Re: [DMM] Stephen Farrell's Discuss on draft-ietf… Suresh Krishnan
- Re: [DMM] Stephen Farrell's Discuss on draft-ietf… Charlie Perkins
- Re: [DMM] Stephen Farrell's Discuss on draft-ietf… Suresh Krishnan
- Re: [DMM] Stephen Farrell's Discuss on draft-ietf… Sri Gundavelli (sgundave)
- [DMM] FW: Stephen Farrell's Discuss on draft-ietf… Sri Gundavelli (sgundave)
- Re: [DMM] Stephen Farrell's Discuss on draft-ietf… Stephen Farrell