Re: [Spud] No. Operators don't need SPUD for mobile network management
Toerless Eckert <eckert@cisco.com> Wed, 27 July 2016 07:13 UTC
Return-Path: <eckert@cisco.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D312D1DA for <spud@ietfa.amsl.com>; Wed, 27 Jul 2016 00:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.322
X-Spam-Level:
X-Spam-Status: No, score=-14.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc9SVevyOHMo for <spud@ietfa.amsl.com>; Wed, 27 Jul 2016 00:13:05 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC52A12D197 for <spud@ietf.org>; Wed, 27 Jul 2016 00:13:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2132; q=dns/txt; s=iport; t=1469603584; x=1470813184; h=date:from:to:subject:message-id:mime-version; bh=vMM4aw0qx9S6cnnSHbCJ2yBPkatP0y0RsJFC2VMmh5E=; b=TZRFEiHr+aDdh6QWyaN3OZ3jGBvT0U6DXuQhkLZIat5e+XHGPsxi2Bij Tgy/3SfFx4bNMXq9uzq4UvcwQ2eC6ctTWYtC+Z/jNBqjLSsxxnH0g4eO0 O8RwvXrhhST0ZJqNpFLGh3mtjJ5/0b9bOEFFW+quuAixE15G/b227kFHS A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CwAgDeXZhX/4cNJK1egz9WfAG2bYIPgX0khyg4FAEBAQEBAQFdHAuFChNaITQFSYhEDp0ZnUUBAQEBAQUBAQEBAQEBIIp3gUqCSBACAYNHgi8FjwqKJ4YYiFoKgWxOhAyIeZAlHjaEGBwyAYhAAQEB
X-IronPort-AV: E=Sophos;i="5.28,428,1464652800"; d="scan'208";a="133983539"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2016 07:13:04 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6R7D3QM013167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <spud@ietf.org>; Wed, 27 Jul 2016 07:13:04 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6R7D35Y012038 for <spud@ietf.org>; Wed, 27 Jul 2016 00:13:03 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6R7D39e012037 for spud@ietf.org; Wed, 27 Jul 2016 00:13:03 -0700
Date: Wed, 27 Jul 2016 00:13:03 -0700
From: Toerless Eckert <eckert@cisco.com>
To: "spud@ietf.org" <spud@ietf.org>
Message-ID: <20160727071303.GC21039@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.2i
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/vIxj2ZjsfZ6au6JM23s2K6Lhqlc>
Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2016 07:13:06 -0000
Wrt to these mail threads: Is there any way how the process can be improved ? I think it's a frustrating waste of time to have proponents and opponents volunteer a lot of good or bad insight/opinions, but nothing of this gets put into persistent documentation (draft -> RFC). Or at worst only the folks who want a WG have the job have to try to figure out of to create something that persists and the opponents can just continue to reject those texts claiming they've not been included in the work. I think we are seeing so much controversy about the pro and cons of exposing various parts of the communication to the network path and/or modifying them in middleboxes, that we MUST have a WG that is at least capturing and structuring that discussion and making both sides contribute to the work of detailing the claims made and responding to the other side. Example: "government will abuse this". Ok, please explain in enough detail the most easily described, in your opinion most likely workflow how this would look like. And then lets describe if/how this compares with pre-existing alternatives for the government to achieve this (eg: tracking at app level). Or please explain how removing all options of observation does not cause regression on the ability to manage networks or even worse options of perpass (eg: http://queue.acm.org/detail.cfm?id=2904894 as pointed out before). And a lot more similar questions. It just does IMHO not make sense to ask these questions/have that discussion purely in email without an RFC target to put it in and both sides having ownership of the result. I am also concerned that without such written analsysis, its not even possible for ADs (or other readers) to technically vet any possible protocol constructive charter goals. Instead, its going to be a lot easier to just make decisions based on counting a rough mayority of opposition. But that would be rejecting work (for which there is a sufficient amount of interest) primarily based on a mayority of IMHO not technically well enough substantiated opposition. Cheers Toerless
- Re: [Spud] No. Operators don't need SPUD for mobi… Fossati, Thomas (Nokia - GB)
- Re: [Spud] No. Operators don't need SPUD for mobi… Smith, Kevin, (R&D) Vodafone Group
- Re: [Spud] No. Operators don't need SPUD for mobi… Mikael Abrahamsson
- Re: [Spud] No. Operators don't need SPUD for mobi… Frode Kileng
- Re: [Spud] [E] No. Operators don't need SPUD for … Mishra, Sanjay
- Re: [Spud] No. Operators don't need SPUD for mobi… Mikael Abrahamsson
- Re: [Spud] No. Operators don't need SPUD for mobi… Eggert, Lars
- Re: [Spud] No. Operators don't need SPUD for mobi… Mikael Abrahamsson
- Re: [Spud] No. Operators don't need SPUD for mobi… Frode Kileng
- Re: [Spud] No. Operators don't need SPUD for mobi… Mikael Abrahamsson
- Re: [Spud] No. Operators don't need SPUD for mobi… Frode Kileng
- Re: [Spud] No. Operators don't need SPUD for mobi… Frode Kileng
- Re: [Spud] No. Operators don't need SPUD for mobi… Toerless Eckert
- Re: [Spud] No. Operators don't need SPUD for mobi… Tom Herbert
- Re: [Spud] No. Operators don't need SPUD for mobi… Natasha Rooney
- [Spud] No. Operators don't need SPUD for mobile n… Frode Kileng
- Re: [Spud] No. Operators don't need SPUD for mobi… Diego R. Lopez
- Re: [Spud] No. Operators don't need SPUD for mobi… Toerless Eckert
- Re: [Spud] No. Operators don't need SPUD for mobi… Tom Herbert
- Re: [Spud] No. Operators don't need SPUD for mobi… Fossati, Thomas (Nokia - GB)
- Re: [Spud] No. Operators don't need SPUD for mobi… Christian Huitema
- Re: [Spud] No. Operators don't need SPUD for mobi… Eggert, Lars