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

"Diego R. Lopez" <> Wed, 27 July 2016 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84C0B12DD5B for <>; Wed, 27 Jul 2016 01:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.907
X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FTHcxEy84bUd for <>; Wed, 27 Jul 2016 01:12:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B50912DD4D for <>; Wed, 27 Jul 2016 01:12:08 -0700 (PDT)
Received: from ( []) by IMSVA (Postfix) with ESMTP id C0F2188646; Wed, 27 Jul 2016 10:12:05 +0200 (CEST)
Received: from (unknown []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP110", Issuer "ESTGVMSP110" (not verified)) by (Postfix) with ESMTPS id A740A88642; Wed, 27 Jul 2016 10:12:05 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 27 Jul 2016 10:12:03 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 27 Jul 2016 08:12:01 +0000
Received: from ([]) by ([]) with mapi id 15.01.0549.014; Wed, 27 Jul 2016 08:12:01 +0000
From: "Diego R. Lopez" <>
To: Toerless Eckert <>
Thread-Topic: [Spud] No. Operators don't need SPUD for mobile network management
Thread-Index: AQHR59ZQAZ9dSVphdk+nxEZCFW2nwaAr7WwA
Date: Wed, 27 Jul 2016 08:12:01 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 26175e5f-1bcd-43f4-8cd1-08d3b5f5aff3
x-microsoft-exchange-diagnostics: 1; AM4PR0601MB2164; 6:+Pbk9XhHVJW1J7pPFHf1e8ZW0wgvriKlCVPfHnD6Pyc5iYYzMjixtl4Ttd7GBoaGdSDsyfo5b6JwYwzZTksbIwj4YK5FzUehXEI4CZ8/5g/y5lxorHkP0qhIgl0l53B+k0ZbqKqoQDgYc6Hijt6uIDGa4YFubBD2Y78wN+6sR8GYOWp+TVvPfGp/t0jGrGejZaR+NlZlbuPuQFICUqeEPtQUUwb1EsH2CabdTYMqSQ+TBGMdVSukWgKTinJjByHCvZ2fNTp8fpeqdfGMdP1aRct9xS1VG1vsMwtRuXU8b7E=; 5:pgNQUXhRY01XKHpOwuaT9qIa5nxIqRUb3rU/sta8aOou9ZeEP1b0GZHilPKdyr+ixwsUcLbWKWSpU0evXaerUtbmvg0WoX35lHZJ4biwhsASQxOz9Ah2+zgYQOBo/RTxiy8MG53nZMyMfrB3mI4SbQ==; 24:ayvrakzjC9LrEdQDrWvdO0ZizTB0Mvy6nB2rwZXm0UTeh4P7VZR+EDZASf9/+93N9XfhWOEg3u3NuNVF6HVjY/hvqjcSN5Yh1uXfgpF9Iqw=; 7:yX6E2IZsf3Ea7t6wFx+8UMo3ZcXLAros/IXfOhhDUm7YiP4LuQkiYSAAj5BJ7ZmAyyIWadUd54qRbRHd6iBjxdhkEMA0iNoSGP/fw8Vyk13BUmmzNNDGd1iy/aZdVIivPwlePOYIebg3MV0HcqfxHBo17+wQy1P4N2eB5CvFxGPGl5jYxeVjc1vfm3jDCAmS32EFKVfh7E3XgNoPXP3v2mJ2CIg27ChZPHXRPcpIOnD+Qy1l3Lva4dUl8m69AMOm
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0601MB2164;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(60795455431006)(40392960112811)(271806183753584)(95692535739014)(155532106045638)(213716511872227);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM4PR0601MB2164; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0601MB2164;
x-forefront-prvs: 0016DEFF96
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(199003)(252514010)(24454002)(189002)(110136002)(36756003)(106116001)(106356001)(122556002)(10400500002)(87936001)(86362001)(105586002)(11100500001)(19617315012)(189998001)(97736004)(66066001)(81166006)(50986999)(8936002)(19580395003)(76176999)(19580405001)(68736007)(4326007)(81156014)(7846002)(2900100001)(101416001)(16236675004)(3660700001)(77096005)(3846002)(2906002)(15975445007)(5002640100001)(82746002)(7906003)(83716003)(33656002)(586003)(2950100001)(102836003)(7736002)(92566002)(6116002)(3280700002)(54356999)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0601MB2164;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_555AC66BA7494BC29BDFF17BBCC10519telefonicacom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2016 08:12:01.0518 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0601MB2164
Archived-At: <>
Cc: "" <>
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 08:12:12 -0000

I agree with Toerless here. There is a lot of arguments going back and forth and recording them in a structured way would (1) provide a very valuable input for this and future discussions on this matter (that for sure will happen), and (2) avoid the kind of incomplete and/or emotionally loaded statements (like the one Toerless pointed) that are common in this kind of discussions.

Be goode,

On 27 Jul 2016, at 09:13 , Toerless Eckert <<>> wrote:

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.


Spud mailing list<>

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

Tel:    +34 913 129 041
Mobile: +34 682 051 091


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição