Re: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt)

Szilveszter Nadas <> Fri, 06 March 2015 09:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1C1491ACD41 for <>; Fri, 6 Mar 2015 01:45:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ypu50SCxs0_s for <>; Fri, 6 Mar 2015 01:45:52 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12BD31ACD3D for <>; Fri, 6 Mar 2015 01:45:51 -0800 (PST)
X-AuditID: c1b4fb2d-f79aa6d00000359d-41-54f9774da8a5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3E.E1.13725.D4779F45; Fri, 6 Mar 2015 10:45:49 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 10:45:48 +0100
From: Szilveszter Nadas <>
To: =?iso-8859-1?Q?Mirja_K=FChlewind?= <>, Salvatore Loreto <>, "Joe Hildebrand (jhildebr) <jhildebr@cisco. com>" <>
Thread-Topic: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt)
Thread-Index: AQHQVqf7LkbhqrxUUECt4gIbIRb7a50ORH2AgADtuNA=
Date: Fri, 6 Mar 2015 09:45:48 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja5v+c8Qg0uHzC3O7jnObrFh9RQW i0UXnjI6MHtM+b2R1WPJkp9MHsc+fGULYI7isklJzcksSy3St0vgyrh98zljwQ2xijmTXRsY 9wl1MXJySAiYSMw6/IgJwhaTuHBvPVsXIxeHkMARRokHC75COYsYJSZ8fs0GUsUmYCHRsHIz WEJE4BijxNPLn5hBEswCyhIzFu5i7GLk4BAWyJH49FoMJCwikCtx9+g5JgjbSuLQ9ndg5SwC KhJPvzaygti8Ar4SN9vPQS37xyTR+uUz2DJOAT2JvzPugTUwAp33/dQaJohd4hK3nsyHOltA Ysme88wQtqjEy8f/WCFsRYmr05dD1etJ3Jg6hQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7Cwk LbOQtMxC0rKAkWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmBUHdzyW3cH4+rXjocYBTgY lXh4DSR+hgixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbHM 6NT+7cfd9/9e/myDtfeFhl8L/Lcyf12vE+14Q2DG3t+25ZFb96ak7+f7teKsw4x3s7v/T7mt OfdJ3TXBrQvKi16dVox4uc9M3Ozloqow+zL1dqYL07nPls+67t39L239S7Hd8U2v1xYXXGDO dN3O/tPl0nP3/yu3BxnwrDzSuGPKf6Pdf8/ZK7EUZyQaajEXFScCALxYaViLAgAA
Archived-At: <>
Cc: "" <>
Subject: Re: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Mar 2015 09:45:54 -0000


I do not really see how these constraints contradicts extensibility. Also I see a value in pre-discussion in mailing list. I tis not really important for me whether any of the drafts is modified.

It would be funny to ossify middlebox signaling with a protocol which is supposed to help in solving ossification for E2E communication. :) I think I accept the constrains below, it would be very hard to incrementally deploy SPUD otherwise. 

A question related to this is in the back of my mind for a while. Shall SPUD standardize the minimum amount of common/necessary signaling information elements and allow any signaling solution, even proprietary, using SPUD to reach the middleboxes? Or shall SPUD include most of the information elements needed? I am in favor of the first, because that allows innovation, though clearly interop is much more a hassle. (If you think about 5-tuple ICMP, that is in fact an example of the first.) Also the first principle would help focusing the scope of the WG more, which might be an advantage. Maybe even signaling protocol design guidelines could be created similarly to the proposed transport protocol design guidelines. Clearly the constraints below do require a different thinking about how to design signaling protocols over SPUD.


-----Original Message-----
From: Spud [] On Behalf Of Mirja Kühlewind
Sent: Thursday, March 05, 2015 21:17
To: Salvatore Loreto; Joe Hildebrand (jhildebr) <jhildebr@cisco. com>
Subject: Re: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt)

Hi Salvatore,

in the slides we are currently preparing for the BoF we have three constraints

- Information exposure is declarative
- All entities may trust but verify
- Information must be incrementally useful (e.g. not all nodes might support spud)

I think this narrows down the scope. I bet we will discuss this further in the BoF and therefore leave for now this as it is.


On 04.03.2015 19:20, Salvatore Loreto wrote:
> Hi Joe,
> extensibility is mentioned in several part of the draft 02, however I 
> am missing extensibility be listed in the requirements and assumptions 
> list in section 2.
> I would like SPUD would permit extension to provide additional info, 
> but at same time I would also have a clear explanation on the 
> limitations, i.e. where extensions are effective, when extension should be ignored etc.
> br
> Salvatore
> _______________________________________________
> Spud mailing list

Spud mailing list