Subject: [dispatch] Event Streaming Open Network Draft & BoF Request

From: Emiliano Spinella <[email-masked]>
Date: Sat, 29 Jan 2022 13:03:25 +0100

Hello everyone,

I have submitted a new draft for discussion:
https://datatracker.ietf.org/doc/draft-spinella-event-streaming-open-network/

The draft contains several images which are broken in the Datatracker html
version (still dealing with SVG Tiny 1.2 format). In the meantime, you can
read the draft including images at:
https://github.com/syndeno/draft-spinella-event-streaming-open-network

The general idea of an Event Streaming Open Network is to have an open
framework for the discovery, name resolution and overall communication of
event streams. The participants of this network could use whatever event
broker implementation they want. Thus, they would be able to consume and
produce events independently of the event broker used by their peers.

The document describes the motivation, design and an initial implementation
of a (free and open) way to connect event streams across different network
participants. The purpose is to facilitate cross-organizational event flow
connections over the Internet. This work has been highly influenced by the
Email architecture and its protocols (RFC5321, RFC3501 and RFC6068; among
others). Also, it leverages unicast DNS-SD for resource discovery (RFC6763).

Although a A BoF request has been submitted for this topic (
https://datatracker.ietf.org/doc/bofreq-spinella-event-streaming-open-network/),
I would like to request agenda time for a presentation in Dispatch during
IETF 113.

I would be happy to hear your feedback about this draft.

Thanks,
Emiliano

-- 
_LEGAL NOTICE: The content of this email message, including the attached 
files, is confidential and is protected by article 18.3 of the Spanish 
Constitution, which guarantees the secrecy of communications. If you 
receive this message in error, please contact the sender to inform them of 
this fact, and do not broadcast its content or make copies.
_
_*** This 
message has been verified with removal tools for viruses and malicious 
content ***
_
_This legal notice has been automatically incorporated into 
the message.
_

*---------------------------------------------*
*AVISO 
LEGAL: El contenido de este mensaje de correo electrónico, incluidos los 
ficheros adjuntos, es confidencial y está protegido por el artículo 18.3 de 
la Constitución Española, que garantiza el secreto de las comunicaciones. 
Si usted recibe este mensaje por error, por favor póngase en contacto con 
el remitente para informarle de este hecho, y no difunda su contenido ni 
haga copias.
*
_*** Este mensaje ha sido verificado con herramientas de 
eliminación de virus y contenido malicioso ***
_
_Este aviso legal ha sido 
incorporado automáticamente al mensaje._

---

From: Tim Bray <[email-masked]>
Date: Sat, 29 Jan 2022 11:39:01 -0800

Having been a designer of AWS EventBridge and worked with the AWS Managed
Kafka service, I'm reasonably well-exposed to these issues.  I suspect
that (a) a standardized framework such as proposed here would be generally
useful, but (b) it would be a ton of work and I'd be hesitant to take it on
without plausible commitments to put the work in.

The draft is immensely long and the ratio of motivation and evangelism to
specification much too high, but the breakdown of components seems broadly
sane. There are issues, for example: (a) it wouldn’t be OK to require
Kubernetes, or specific programming languages for compliance and (b) the
draft doesn't say anything about message schemas, which are a big and
fairly central problem in these applications.

I'd also wonder to what extent this work is being addressed by the CNCF.

On Sat, Jan 29, 2022 at 4:03 AM Emiliano Spinella <
[email-masked]> wrote:

> The document describes the motivation, design and an initial
> implementation of a (free and open) way to connect event streams across
> different network participants. The purpose is to facilitate
> cross-organizational event flow connections over the Internet. This work
> has been highly influenced by the Email architecture and its protocols
> (RFC5321, RFC3501 and RFC6068; among others). Also, it leverages unicast
> DNS-SD for resource discovery (RFC6763).
>
> *LEGAL NOTICE: The content of this email message, including the attached
> this fact, and do not broadcast its content or make copies.*
> **** This message has been verified with removal tools for viruses and
> malicious content ****
> *This legal notice has been automatically incorporated into the message.*
> *AVISO LEGAL: El contenido de este mensaje de correo electrónico,
> incluidos los ficheros adjuntos, es confidencial y está protegido por el
> artículo 18.3 de la Constitución Española, que garantiza el secreto de las
> comunicaciones. Si usted recibe este mensaje por error, por favor póngase
> en contacto con el remitente para informarle de este hecho, y no difunda su
> contenido ni haga copias.*
> **** Este mensaje ha sido verificado con herramientas de eliminación de
> virus y contenido malicioso ****
> *Este aviso legal ha sido incorporado automáticamente al mensaje.*
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Emiliano Spinella <[email-masked]>
Date: Sun, 30 Jan 2022 00:18:47 +0100

Hello Tim, thanks for your feedback!

Let me address your points:

*(a) a standardized framework such as proposed here would be generally
useful, but (b) it would be a ton of work and I'd be hesitant to take it on
without plausible commitments to put the work in.*

Yes, but maybe the topic is worthy of a discussion within the IETF.

*The draft is immensely long and the ratio of motivation and evangelism to
specification much too high, but the breakdown of components seems broadly
sane. *

This document is an extract from my Master's thesis, so it definitely needs
to be reworked to match the audience. This is the first time I publish an
I-D so any advice is appreciated.

*There are issues, for example: (a) it wouldn’t be OK to require
Kubernetes, or specific programming languages for compliance and*

Yes. The implementation section within the draft is an initial approach,
specially for the PoC described at the end. There could be many approaches
and not necessarily described in an IETF document.

*(b) the draft doesn't say anything about message schemas, which are a big
and fairly central problem in these applications.*

Schemas are referenced within the document as "Payload Format". This
nomenclature is based on the distinctions made by Urquhart in his book Flow
Architectures. The schema of a topic is known by the "Flow Processor"
component within the architecture. Since every subscription would need one
instance of this component, each would host a reference to the
corresponding schema (i.e. an URL to an Avro schema). However, the document
does not drill down on this subject and should address it. Thanks for the
comment, I will rework it.

*I'd also wonder to what extent this work is being addressed by the CNCF.*

As far as I am aware, the CNCF has one related project called CloudEvents,
which focuses on the Payload Format and not on the Metadata Format. This
draft addresses the Metadata Format and its protocol. Basically,
CloudEvents focuses on the message schema but not on how peers negotiate a
subscription. There is also the case of Nats, whose protocol combines both
formats.

Thanks,
Emiliano

On Sat, Jan 29, 2022 at 8:39 PM Tim Bray <[email-masked]> wrote:

>> The draft contains several images which are broken in the Datatracker
>> html version (still dealing with SVG Tiny 1.2 format). In the meantime, you
>> can read the draft including images at: