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

Hi,

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.

Cheers,
Szilveszter

-----Original Message-----
From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Mirja Kühlewind
Sent: Thursday, March 05, 2015 21:17
To: Salvatore Loreto; Joe Hildebrand (jhildebr) <jhildebr@cisco. com>
Cc: spud@ietf.org
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
listed:

- 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.

Mirja

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@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud