Re: [Spud] No. Operators don't need SPUD for mobile network management

Toerless Eckert <> Wed, 27 July 2016 07:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B2D312D1DA for <>; Wed, 27 Jul 2016 00:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.322
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xc9SVevyOHMo for <>; Wed, 27 Jul 2016 00:13:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC52A12D197 for <>; Wed, 27 Jul 2016 00:13:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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: =?us-ascii?q?A0CwAgDeXZhX/4cNJK1egz9WfAG2bYIPg?= =?us-ascii?q?X0khyg4FAEBAQEBAQFdHAuFChNaITQFSYhEDp0ZnUUBAQEBAQUBAQEBAQEBIIp?= =?us-ascii?q?3gUqCSBACAYNHgi8FjwqKJ4YYiFoKgWxOhAyIeZAlHjaEGBwyAYhAAQEB?=
X-IronPort-AV: E=Sophos;i="5.28,428,1464652800"; d="scan'208";a="133983539"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2016 07:13:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u6R7D3QM013167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Wed, 27 Jul 2016 07:13:04 GMT
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id u6R7D35Y012038 for <>; Wed, 27 Jul 2016 00:13:03 -0700
Received: (from eckert@localhost) by (8.13.8/8.13.8/Submit) id u6R7D39e012037 for; Wed, 27 Jul 2016 00:13:03 -0700
Date: Wed, 27 Jul 2016 00:13:03 -0700
From: Toerless Eckert <>
To: "" <>
Message-ID: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/
Archived-At: <>
Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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: 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.