►
From YouTube: IETF113-DISPATCH-20220321-0900
Description
DISPATCH meeting session at IETF113
2022/03/21 0900
https://datatracker.ietf.org/meeting/113/proceedings/
B
A
This
is
our
first
ever
hybrid
meeting,
so
both
hello
to
the
people
who
are
joining
us
virtually
and
hi
to
folks
in
the
room.
We've
got
a
bit
of
setup
to
do
this
morning,
being
everyone's
first
session,
we're
just
going
to
spend
a
bit
longer
on
the
logistics
that
you
can
expect
to
see
in
other
sessions
across
the
week
and
then
we're
going
to
get
dispatching
so
hi,
I'm
kirsty
payne.
For
those
who
don't
know
me,
I'm
one
of
the
co-chairs
of
dispatch.
I've
been
kindly
joined
by
brand.
C
A
C
A
A
So
this
covers
things
like
patent
patent
applications,
but
also
just
to
make
everyone
aware
that
everything's
being
recorded
in
the
room
and
online
as
well
and
all
of
this
good
stuff,
all
of
those
bcps
that
we
suggest
you
read
if
you
haven't
already
and
then
I
always
like
to
put
in
a
note
really
well,
because
this
is
the
important
things.
I
think
that
we
should
just
really
be
aware
of
to
build
a
good
itf
culture,
as
we
all
return
so
meetings
and
virtual
meetings
and
mailing
lists
are
intended
for
professional
collaboration
and
networking.
A
But
if
you
have
any
concerns
about
any
behaviour,
talk
to
the
ombuds
team
they're
there
to
allow
you
to
confidentiality
at
confidentially,
raised
concerns
about
harassment
or
any
other
conduct.
You
see
in
the
itf.
It's
really
important,
especially
as
we're
coming
back
to
create
an
environment
where
many
people
with
different
backgrounds
are
treated
with
dignity
and
respect.
A
Anyone
who
participates
in
the
itf
is
expected
to
behave
according
to
professional
standards
and
have
appropriate
workplace
behavior
and
again,
if
you
think
that
that's
falling
short
talk
to
the
ombuds
team
so
specifically
do
not
engage
in
harassment
while
you're
in
virtual
meetings
in
person,
meetings,
social
events
or
on
mailing
lists.
It
is
not
acceptable
and
if
you
believe,
you've
been
harassed
them
or
you
see
someone
else
being
harassed.
Then
please
raise
your
concerns
and
confidence
to
ombuds
team.
A
Okay,
so
itf
113
meeting
tips.
This
session
is
being
recorded
for
people
in
the
room.
Please
sign
into
the
session
using
the
meet
echo
lite
client.
If
you
use
the
full
version
client,
then
your
video
will
probably
appear
on
this
screen,
which
will
be
delightful
for
everyone
in
the
room,
but
maybe
a
bit
embarrassing
for
you,
so
do
use
the
lights,
client
and,
very
importantly,
cue
management.
So
if
you
get
up
and
stand
up
at
the
mic,
but
you
have
not
clicked
this
button
in
meet
echo
to
say
you
will
be
joining
the
queue.
A
We
won't
be
calling
your
name
out,
so
you
will
just
be
standing
at
the
mic
for
quite
a
while
wondering
what's
going
on
so
make
sure
you
join
the
queue
on
the
meet
echo
client
and
then
stand
up
to
go
to
the
queue
now
for
those
joining
virtually
we're
going
to
be
calling
the
queue
in
the
order
it
appears
on
meet
echo.
So
there
is
no
preference
for
virtual
or
in-person
participants.
It's
just
the
order
in
which
you
click
to
join
the
queue
for
remote
participants.
Hi.
Welcome
it's
great
to
have
you
here
as
well.
A
Here
are
some
resources
you
can
find
the
agenda
and
all
the
meeting
materials
there
and
specifically
for
dispatch.
We
need
note
takers,
so
it's
been
a
while,
since
we
got
to
actually
look
at
people
in
the
room
and
stare
as
people
avoid
our
gaze
to
pick
a
note-taker
but
head
on
over
to
notes.itf.org
and
help
us
take
accurate
and
good
notes
for
the
session.
You
know
they're
useful.
You
know
you
love
them,
so
please
contribute
and
we've
got
jabba
and
zulip
as
well
in
the
room.
C
I
just
wanted
to
add
one
thing
to
that,
which
is
that
the
qr
code
in
the
media
echo
light
is
not
just
so.
You
can
ask
questions.
It's
also
the
blue
sheets.
So
instead
of
passing
around
a
piece
of
paper
covered
in
in
people's
slimy
handwriting,
take
a
photo
of
that
qr
code
or
navigate
to
the
agenda
and
click
on
it.
There
either
way
once
you
open
that
medeco
light
client
log
in
with
your
data
tracker,
login,
that's
what's
going
to
get
you
listed
as
being
present
in
the
room.
So
please
do
that.
Thanks.
A
A
A
F
E
E
E
There
is,
there
is
the
feedback
loop
mechanism
for
a
long
time
which
allows
mailbox
providers
to
follow
forward
complaints
from
their
users.
Back
to
the
sender,
however,
the
current
implementation
must
be
set
up
manually
by
the
sender,
with
each
provider
that
provides
a
feedback
loop
in
addition
to
setting
up
a
feedback
loop
for
the
first
time.
There
is
also
the
revalidation
of
an
already
existing
and
setup
loop.
E
If
you
want
to
change,
for
example,
the
complaint
email
address,
you
need
to
go
through
all
providers
and
change
the
address
which
is
time
consuming
as
well.
Nowadays,
where
dkm
gains
more
and
more
importance
in
reputation
building,
it
also
gets
more
relevant
for
feedback
loops
feedback
group
provider,
move
from
ip
based
ones
to
dicken-based
ones
or
a
mixed
version
of
it,
which
makes
it
harder
to,
for
example,
main
maintain
it
for
customers
when
it
comes
to
to
sending
platforms
or
esp's.
E
E
E
E
E
This
is
the
complexer
one.
It
requires
a
double
signature,
which
is
a
common
practice
when
it
comes
to
sending
platforms
who
are
sending
mails
for
their
customers
yeah.
Could
you
move
on
thanks?
So
how
should
this
draft
be
dispatched?
I
think
ad
sponsoring
would
be
the
best
way.
Currently,
there
is
no
obvious
working
group
for
el,
for
it,
the
email
core
working
group
is
currently
rejecting
work,
as
they
are
updating
the
course
backs.
E
A
Okay,
super
so
we'd
like
to
invite
people
to
come
to
the
mic
and
express
their
opinion
on
ditch
dispatch
question
here
are
the
options,
as
the
author
sees
them.
Of
course,
you
may
see
others
so
just
remember
to
click
the
join
q
button
and
then
come
to
the
mic
in
the
room
or
we'll
call
the
virtual
queue,
as
it
appears
so.
John
levine
first.
B
G
Okay,
thank
you.
I
think
this
is
a
reasonable
proposal.
I
mean
I,
I
run
an
informal
site
called
abuse
net,
which
is
essentially
a
database
of
contact
addresses,
and
this
would
move
the
contact
addresses
into
the
message.
I'm
not
particularly
worried
about
that.
Some
of
the
some
of
the
notices
might
go
to
spammers.
I
mean
either
they'll
ignore
them
or
they'll.
Take
you
or
they'll,
stop
sending
you
mail,
neither
of
which
makes
your
situation
worse,
and
I
and
I
I
know
the
authors
and
I
think,
there's
there's
some.
G
There
is
some
interest
for
to
be
a
useful
experiment.
You
actually
need
to
have
some
people
who
are
interested
in
performing
the
experiment
and
I
believe
it's.
I
believe
that
some
people,
some
of
these
people
may
exist
and
I'm
looking
forward
to
see
what
braun
has
to
say
about
it.
So
I
think
it
it's
it's
worth
it.
This
is.
It
seems
this
is
the
edwards
harmless.
I
think
it's
worth
advancing.
C
Regarding
this
spec
itself,
there
is
currently
an
issue
with
dkim
replay
attacks
and
I'm
not
sure
how
this
would
solve
that
that
you
have
an
email
which
is
perfectly
legitimate
to
the
one
destination
it
gets
to.
But
if
someone
then
replays
that
to
a
million
people
by
basically
sfvc,
seeing
just
having
receipt
to
an
address
that
was
not
involved
with
the
original
email,
you'll
wind
up
getting
a
lot
of
feedback
from
that
which
will
cause
domain
reputation.
Problems
for
the
sender,
so
we're
going
to
have
to
solve
that
problem
too.
C
A
I
A
We
don't
have
anyone
else
in
the
queue
in
the
room
or
virtually
just
pause.
I
think
the
sense
of
the
room
is
that
this
is
worthwhile
work
that
can
go
forward
modular.
The
problems
that
bronn
just
mentioned,
that
we
need
to
address,
but
just
have
a
kind
of
reading
of
the
room
which
is
nice
to
be
able
to
do
in
person
actually
for
a
change
can
see
how
many
of
you
are
smiling
and
nodding
behind
your
masks.
So
I
think
that
we've
heard
a
lot.
A
This
should
either
be
ad
sponsored
or
a
new
working
group
created
we'll
just
kind
of
pause
and
wait
for
murray
to
share
his
thoughts
in
the
chat
being
the
ad
that
would
sponsor
likely,
and
then
I
can
see
in
jabba,
colin
jennings,
is
just
sharing
giving
the
security
feedback
just
raised.
I
don't
think
ad
sponsor
is
a
good
path.
Cullen.
Do
you
want
to
come
to
the
mic
and
just
sort
of
elaborate
on
that
slightly.
F
J
Okay,
so
look
I'm
not.
I
don't
fully,
I'm
not
an
expert
in
space.
I
don't
know
whether
the
security
issue
raised
was
totally
you
know
bona
fide,
but
it
sounded
like
a
real
issue
and
if
so,
I
think
that
that
pushes
you
towards
this
is
a
little
bit
more
complicated
and
having
a
working
group
environment
to
deal
it
in
would
probably
be
better
than
than
just
ad
sponsored
would
be,
would
be
my
leaning,
but
that's
that's
said
from
a
point
of
not
deep
knowledge
on
this
space.
A
We'll
just
wait
for
murray
to
share
his
thoughts
in
chat
and
then
we'll
loop
back
at
the
end
of
the
session
to
confirm
that
dispatch
outcome.
But
for
now
thank
you,
john
philippe,
for
your
presentation.
It's
really
great
to
have
you
here
presenting
virtually
thank
you
very
much
for
bringing
your
work
to
itf.
A
L
K
So
this
draft
is
about
encrypted
client,
hello,
which
is
a
tls
feature
that
allows
you
to
encrypt
the
client
hello,
to
a
a
server,
a
cover
server,
which
is
fronting
for
servers
in
the
back
end,
in
order
to
protect
the
identity
of
the
server
that
a
client
is
trying
to
connect
to.
So
it's
a
privacy
feature
to
basically
hide
the
sni.
The
server
name,
indication.
K
And
so
in
steven's
setup
of
ech
he
has
a
number
of
front-end
servers
that
have
their
public
keys
that
are
rotated
regularly,
so
these
keys
are
used
by
the
client
to
encrypt
the
traffic.
To
these
cover
servers,
the
client
learns
about
these
keys
from
dns,
but
in
order
to
get
those
keys
in
dns,
you
need
some
mechanism,
and
currently
this
setup
doesn't
use
dynamic,
dns
or
some
other
api.
K
K
K
K
K
K
H
M
M
M
N
N
O
Yeah
so
ted
touched
on
a
couple
of
things
I
agree
with
I'm
not
sure
yet
as
to
whether
the
generalization
is
necessary
here.
What
I
do
think,
however,
is
that
the
solution,
whatever
it
is,
will
require
a
little
bit
more
operator
input
than
than
just
stephen's
little
experiment,
and
so
I
think
ultimately,
this
is
the
sort
of
thing
that
needs
to
go
through
a
working
group
either
way,
I
don't
know
whether
that's
http
or
tls,
probably
http.
P
Okay,
okay,
hello
people
in
a
room
in
vienna,
so
I
I
got
in
queue
to
respond
to
alexi
about
hp
api
that
that's
not
what
the
hba
api
working
group
is
for.
I
would
not
want
to
see
it
burdened
with
kind
of
reviewing
things
for
for
whether
they're
good
apis
or
not.
I
think
that
would
be
bad
for
what
we're
trying
to
do
there.
So
please
don't
try
to
use
it.
That
way.
P
P
P
Q
Q
Basically,
what
you
need
to
do
is
to
have
a
credential
for
the
host
rather
than
the
service
running
on
the
host,
and
so
you
might
be
able
to
do
it
in
tls.
It
might
be
a
different
working
group
of
its
own
it.
It
is
quite
a
complicated
piece
of
issue
and
I
don't
think
that
it
fits
into
the
way
that
we've
been
solving
this
doing
tls
and
http
in
the
past.
Q
Q
Or
oh
yes,
yes,
basically,
what
we
have
lacked
in
ietf
for
20
years
now
is
a
generic
way
of
service
of
secure
service
discovery
in
that,
if
you
want
to
talk
to
internet
protocol
named
fred,
there
should
be
a
way
of
finding
the
hosts
that
you
want
to
talk
to.
That
is
the
ip
addresses
the
protocols
that
you
want
to
talk
to
the
versions,
the
tls
parameters,
etc.
Q
We
should
have
that
stuart
cheshire
did
some
of
that
with
his
dns
discovery
piece,
but
that's
not
a
that's
only
one
option.
This
is
something
that
we
should
have
done
as
an
itf
wide
resource
that
everybody
is
encouraged
to
use
20
years
ago,
and
it
should
subsume
well
known
and
all
that
stuff
as
well,
because
if
we
were
to
produce
ourselves
a
version
of
http
over
quick
or
something
like
it
specifically
for
web
services,
that's
not
trying
to
also
serve
your
web
browser.
Q
We
would
probably
break
out
instead
of
using
dot
well
known.
We
would
break
that
out
into
a
separate
service
layer
where
you
would
say
I
want
to
talk
to
this
service
at
this
dns
address,
rather
than
I
talked
to
a
reserved
urls,
because
you
know
the
your
reserve
urls
are
flaky,
it
was
always
a
hack,
so
I
I
think
that
what
we
really
need
to
do
is
to
do
that.
General
service
discovery.
A
Okay,
thank
you
very
much.
Php
a
few
of
you.
It's
well
noted
we'll
just
see
that
we've
got
a
few
people
in
the
queue
so
we'll
race
through
those
at
this
point
and
then
yeah,
we'll
just
sort
of
close
it
and
maybe
invite
francesca
to
come
with
a
summary
at
the
end
as
well
from
her
point
of
view,
so
rich
saltz
you're
next,
in
the
queue.
R
We
want
to
make
it
easy
for
them
to
configure.
Steven's
draft
also
has
test
figure
test
vectors.
Let's
not
try
to
solve
the
problem.
Let's
put
this
point
down
and
if
it
becomes
generalizable.
Let's
do
that
after
we've
gotten
the
second
data
point.
We
need
two
points
to
draw
a
line
segment.
So
I'd
like
to
dispatch
this
perhaps
to
dns
op,
which
is
where
server
speed
came
in,
but
this
draft
alone
is
meets
a
real
pressing
need
in
the
industry.
Thank
you.
I
Hello,
yes,
I
I
have
no
strong
opinions
over
whether
or
not
this
is
the
right
solution
to
the
problems
or
how
much
the
problems
really
exist.
But
I
think
if
this
is
the
right
solution,
I
think
we
need
to
generalize
it
at
least
to
the
level
of
svcb
records,
and
that
is
because
the
svcb
records
the
dns
records
are
usually
used
to
communicate
at
configs.
I
It's
a
very
generalized
record.
It's
blocking!
Well,
it's
a
kitchen
sink
key
value
pair.
Essentially,
so,
if
we're
going
to
do
a
solution
like
this,
it
needs
to
be
something
that's
at
least
general
to
that
level,
because
there
could
be
plenty
of
times
in
the
future
that
something's
added
to
those
records
that
needs
a
similar
mechanism
to
update
to
the
zone
file.
So
it's
it's
an
extremely
generalizable
problem
and
it
should
be
generalized
and
should
be
dispatched
accordingly.
S
Now,
we've
not
always
done
that,
but
we
want
to
make
sure
that
the
rest
of
the
world
learns
to
love
security
as
well
and
how
it
helps
us
do
the
right
thing.
So,
as
opposed
to
trying
to
get
everything
done
in
the
tls
working
group.
That's
fully
related
to
the
tls
working
group.
We
could
you
know
we
can
set
this
free
and
get
it
to
another
set
of
experts
who
might
help
but
get
better
deployed
thanks.
B
Hello,
so
I
haven't
heard
any
clear
consensus
in
the
discussion,
both
in
jabber
and
in
the
room.
What
I've
heard
is
that
this
needs
a
working
group.
This
is
probably
not
going
to
go
to
ad
sponsored,
probably
not
a
new
working
group,
because
there
was
yeah
at
least
that's
my
impression
yeah.
I
think.
Maybe
we
can
continue
this
discussion
in
the
mailing
list.
If
there
is
no
other
opinions
and
then
yeah,
we,
we
will
take
into
account
everything
that
was
said
anyway.
A
B
A
G
G
G
So
yeah
I've
already
gone
back
and
forth
with
brian
a
little
bit
on
this.
We
have
learned
not
to
attempt
to
tell
mail
software
how
to
how
to
speak
to
how
to
speak
to
users.
So
our
proposal
says
nothing
about
what
a
user
agent
would
do,
but
since
everybody
asks
it
can
do
everything
from
what
it
does
now
just
to
ignore
it
or
to
gray
them
out
or
automatically
delete
them
or
let
the
user,
let
the
users
delete
them,
but
again
in
in
use
that
this
is
pretty.
G
I
mean
the
the
semantics
are
a
little
different,
but
but
it
seems
it
doesn't
seem
hard
to
implement
next,
please
so
how
to
dispatch
it,
and
I
should
have
updated
this
a
little
bit.
The
the
the
the
the
short
version
of
this
is
whatever
we
do
with
the
on
philippe's
draft.
We
should
probably
do.
We
should
probably
do
the
same
thing
with
this
draft.
It's
a
small
change.
It's
you
know
it's
a
it's
another
email
header
and
that's
it
for
my
slides.
M
Hi
john
yeah,
I
like
it.
Actually
I
represent
a
vendor
who
implemented
this
in
x400,
but
I
actually
have
it
also
used
in
internet
mail
in
our
webmail
client.
So
that
sounds
very
sensible
to
do
with.
I
was
actually
surprised
that
it
was
not
defined
one
for
internet
mail
other
than
for
gateways,
so
make
sense,
don't
really
have
an
opinion
about
where
to
do
it.
T
S
S
G
T
Hello
just
a
word
of
support
for
this,
because
I
know
of
at
least
one
very
big
implementation
of
something
similar
that
doesn't
follow
any
standards
or
it
has,
you
know,
uses
some
different
headers.
I
think
it
would
be
great
to
have
a
standardized
way
of
well
of
doing
that,
rather
than
vendors
doing
their
own
thing.
L
A
Okay,
so
I've
heard
so
far
we're
definitely
not
email
core,
although
on
the
on
the
slide,
there's
a
suggestion
of
ad
sponsorship
just
want
to
check.
If
there's
any
violent
disagreement
to
ad
sponsorship,
does
it
require
a
bit
more
discussion
than
that
or
do
you
think
that's
an
acceptable
route?
So
if
you
have
any
objections
to
ad
sponsorship,
then
please
join
the
queue
and
express
your
view
and
express
why
and
an
alternative
route.
Please.
A
A
L
L
So,
for
those
who
are
not
familiar
with
it,
mls
is
the
messaging
layer
security
protocol,
it's
being
worked
on
in
the
sec
area
in
the
mls
working
group.
It's
an
efficient
group,
keying
protocol,
so
as
joiners
and
levers
are
processed
in
a
group.
When
you
encrypt
a
message
for
a
group,
it
goes
to
the
current
members.
L
This
work
was
strongly
motivated
by
folks
who
are
doing
group
chat,
applications
or
instant
messaging
applications
that
want
efficient
group
security
using
security,
properly
properties
that
are
similar
to
the
double
ratchet
protocol.
That's
used
in
signal
telegram,
whatsapp
wire
and
I'm
sure
dozens
of
others.
L
L
L
L
L
L
Since
then,
the
industry
has
moved
on
and
what
you
could
consider
to
be
common
features
of
an
instant
messaging
service
have
expanded
rapidly
and
are
you
know
there
are
dozens
of
features
which
are
implemented
in
in
multiple
products,
but
mostly
the
the
assumptions
about
what
it
means
to
have
end
and
security
has
changed.
Mls
looks
very
different
than
s
mime
or
pgp.
L
The
first
one
was
to
allow
mls
groups
and,
and
members
of
mls
groups
to
negotiate
the
content
using
mime,
of
course,
so
right
now,
the
base
mls
protocol
does
not
contain
any
way
to
specify
the
format
of
its
application
data.
I
think
this
is
a
bit
unusual
for
an
itf
protocol.
I
think
most
itf
protocols
they
specify
what
the
format
of
the
next
layer
is,
or
they
provide
some
other
way
of
determining
what
the
content
of
the
next
layer
is.
L
So
the
first
question
here
is:
do
we
think
this
negotiation
work
is
useful
and
if
so,
where
should
it
live?
Mls
has
been
pretty
laser
focused
on
the
mls
protocol
and
the
mls
architecture
and
federation
documents
are
next
up
in
the
docket
and,
as
I
said,
they
don't
have
a
lot
of
traditional
application.
U
L
Next
slide,
please,
okay
and
then
I
wrote
another
another
document
to
provide
more
of
an
example
than
anything
else
for
a
an
example
of
a
common
protocol,
how
you
could
convey
the
semantics
so
plain
text
and
rich
text
messages,
replies
reactions,
mentions
editing
and
deleting
previously
sent
messages,
expiring
messages
for
our
previous.
Our
previous
presentation.
A
U
L
Yeah,
I
agree,
semantics
is
always
has
to
come
first,
and
the
important
thing
is
that
we,
if
we,
if
we
define
a
common
format,
we're
just
saying
these-
these
are
the
semantics
for
this
particular
syntax.
I
don't
think
that
we
want
to
that.
We
want
to
to,
for
example,
the
example
of
what
you
do
with
an
expiring
message
in.
V
So
on
the
one
hand,
I
think
this
is
a
bigger
problem,
a
bigger
challenge
than
then
one
might
get
the
impression
of
looking
at
the
documents,
but
on
the
other
hand,
I
think
we've
got
a
good
chance
of
success.
We
have,
as
you
say,
mls
here
is
a
tool
for
intent,
security
and
we've
got
some
experience
out
in
the
industry,
doing
end-to-end
security
with
in
some
real
systems,
and
I
think,
there's
a
variety
of
reasons
out
there
in
the
world
that
people
want
to
do
interop.
V
So
I
think
we've
got
those
reasons.
I
think
we
have
a
fair
chance
of
doing
an
interoperable
end-to-end,
secure
messaging
solution,
kind
of
along
the
lines
of
cpim
or
jabber
the
prior
efforts,
but
now
with
kind
of
more
modern
stuff,
more
modern
foundations,
more
modern
features.
So
all
that
said,
I
think
we
probably
need
to
do
a
buff
on
this.
I
think
we
probably
need
to
do
a
little
bit
more
community
building
and
have
some
more
you
know
more
of
those
messaging
operators
in
the
room.
V
T
V
A
L
Quick
question,
so
I
because
there
are
two
documents
here:
one
which
is
about
negotiating
content
types
and
the
other,
which
is
a
content
type.
I
think
richard
most
seems
like
he
was
mostly
speaking
about
the
content
type,
but
for
anybody
who's,
who's
speaking,
please
say
which
one
you're
speaking
about
or
or
both.
V
A
V
Q
Q
This
has
all
messaging
for
some
reason
we
seem
to
like
walled
gardens.
I
did
not
like
the
fact
that
we
started
up
mls
the
way
that
we
did
with
a
permission
given
to
walled
gardens
with
this.
Basically
we're
saying
we're
going
to
do
an
interoperable
messaging
system
without
doing
an
interoperable
messaging
system.
Q
So
I
I
can't
see
how
you
could
do
an
interrupt
unless
person
using
service
a
can
actually
interrupt
with
person
using
service
b,
and
so
this
is
kind
of
like
incoherent
to
me.
Either
you
decide
to
do
an
interoperable
messaging
system,
in
which
case
this
stuff
is
relevant,
or
you
continue
to
do
proprietary
systems
that
don't
talk
to
each
other,
in
which
case
this
isn't
something
that
we
should
spend
time
on.
A
O
So
I
think
rowan.
I
think
this
is
a
problem
that
I
would
like
to
see
us
working
on
at
some
level.
One
thing
that
I
sort
of
found
missing
in
your
presentation-
and
it's
pretty
hard
to
pick
up
from
the
drafts-
is
how
you
imagine
the
the
use
of
the
keys
that
come
out
of
mls,
one
of
the
things
that
we're
discussing
in
s
frame
with
the
mls
usage.
There
is
use
of
an
exporter.
O
I
imagine
that
you're
talking
about
the
internal
keys
for
mls
being
used,
and
I
don't
quite
understand
how
you
are
managing
diversity
of
ensuring
that
you
have
the
sequence,
numbers
correct
and
all
those
sorts
of
other
things,
so
probably
another
recommendation
off
so
that
we
can
go
through
some
of
those
how
this,
how
this
all
sort
of
fits
together,
because
with
richard
going
so
high
level.
I
have
no
idea.
L
Yeah,
so
there
there
is
the
there
is
the
content
of
the
application
data
which
just
gets
encrypted
and
sent
to
every
member
of
the
group
which
you've
got
to
do
something
with
that,
and
so
you
don't
require
an
exporter
for
that.
As
soon
as
you
start
to
do
things
with
exporters,
then
I
think
it's
even
more
important
to
have
the
exporter
name
be
standardized
and
the
semantics
of
that
be
standardized.
L
A
B
L
W
J
So,
look,
I,
I
think,
there's
a
really
good
problem.
I
I
I'm
interested
in
the
high
level
problem
here
and
I
I
want
to
speak
in
favor
of
this
to
it
to
a
certain
degree
and
try
and
think
say
what
I
think
the
problem
is
we
need
to
solve
and
in
terms
of
email
it.
Just
as
an
analogy
to
think
about
this,
I
think
we
need
to
solve.
You
know
the
smtp
problem,
how
these
various
im
services
move
the
data
between
each
other,
not
how
they
actually
get.
J
So
I
think
there's
really.
You
know
we.
I
think
you
can
use
mls
to
key
things
into
end,
but
that
means
all
of
our
current
gateway
technologies
that
have
been
used,
which
weren't,
standardized
or
just
implemented.
Don't
work
anymore.
So
I
I
really
think
that
we
do
need
to
solve
this
problem
of
how
we
can
get
these
messaging
systems
to
send
messages
to
each
other
and
with
end-to-end
and
as
soon
as
we
have
that
we
have
to
agree
on
what's
inside
the
end-to-end.
J
I
would
definitely
argue
for
you
know,
let's
do
an
interim
virtual
buff,
preferably
working
group
forming,
preferably
sometime
soon,
but
we
don't
have
to
be
gated
by
we're
going
to
do
a
buff
at
the
next
meeting
and
then
another
working
group
forming
off
at
the
meeting
after
that,
and
maybe
a
year
and
a
half
from
now
we
might
start
doing
the
work
in
a
working
group.
That's
just
not
a
good
timeline.
A
W
It's
pete
resnick,
so
I
want
to
agree
with
cullen
working
group
forming
buff
as
soon
as
possible
on
this,
and
a
working
group
forming
buff
can
decide
that
particular
pieces
might
go
over
to
mls.
Particular
pieces
might
be
in
the
new
working
group.
That's
fine!
The
question
of
you
know
the
semantics.
I
think
it's
perfectly
reasonable
to
define
some
simple-based
semantics
and
let
the
industry
take
it
on
its
way.
W
Speaking
of
the
industry
and
this
sort
of
goes
to
phil's
point,
I
think,
having
players
in
the
room
that
are
actually
working
on
the
products
is
a
fine
start
and
we
don't
need
the
users
to
be
the
only
gating
thing,
but
the
question
I've
really
got
is:
who
do
we
have?
Who,
in
the
industry,
who's
willing
to
actually
say
we
want
this?
I
saw
in
the
chat
room.
A
Thank
you
pete
nice
to
see
you
too,
okay.
So
that's
the
end
of
the
queue.
I
think
we
heard
quite
a
lot
of
strong
support
and
especially
in
jabba,
for
a
working
group
forming
both
so
we'll
take
that
forward
as
the
dispatch
outcome.
Thank
you
very
much
everyone
for
your
views
and
thank
you
rohan
for
bringing
the
work
great
to
see
you
virtually.
So
we
have
nikita
back
who
was
earlier
in
the
agenda
and
has
now
come
back
to
present
on
open
ethics,
transparency
protocol
so
hi
great.
X
X
So
here
you
could
see
the
links
which
you,
which
you
could
use
to
get
acquainted
with,
the
with
the
protocol,
the
link
to
the
draft,
the
link
to
the
project
page
and
the
github,
where
the
main
work
could
be
extended
and
where
you
could
contribute,
and
there
is
also
one
implementation
which
was
brought
by
open
ethics
label,
which
I
can
show
later
on.
If
we
would
have
some
a
bit
of
time
in
this
conversation,
let's
go
for
the
next
one.
X
So
what
is
happening
in
today
in
the
software
industries,
almost
80
percent
of
consumers,
including
industrial
consumers.
They
don't
know
what
is
happening
on
the
back
end
and
only
one
third
of
companies
say
that
they
have
instruments
to
bring
either
transparency
information
about
how
they
treat
the
data,
how
they
process
the
data.
How
would
they
transfer
data
to
different
components,
and
what
we
believe
is
that
the
regulation
is
not
the
only
way
we
could.
X
X
X
X
X
So
this
is
the
way
how
the
file
could
look
like
it's
a
simple
json
structure
and
we
aim
it
to
become
an
ethics
password
of
the
product
and
instead
of
saying
that
the
product
should
be
should
be
private
or
the
product
should
be
safe.
We
could
introduce
a
very
formal
measure
of
how
safe
or
how
private
it
could
be,
which
sort
of
information
it
should
collect,
which
sort
of
which
sort
of
validation
should
happen
at
when
the
product
operates
and
specifically
for
ai
and
machine
learning
products.
X
This
is
important
as
we
are
operating
not
on
rules
but
based
on
the
trained
data
where
it
is
very
difficult
to
understand
and
to
factorize
the
the
the
outputs
made
by
made
by
the
machine.
So
if
we
could
take
account
of
the
training
data
sets
and
bring
this
trade
bring
this
information
as
a
passport
as
a
data
password,
we
could
then
have
a
more
clear
idea
about
how
the
software
is
built
next,
one
please.
X
So
what
we
propose
here
is
that
every
every
product,
owner
or
software
developer
creates
a
disclosure
through
a
simple
process,
either
through
a
semi-automated
process
or
through
a
fully
automated
process.
Right
now
we
have
a
semi-automated
process
only
put
implemented
in
place
and
what
they
do.
They
do
the
disclosure
first
and
then
in
the
process
of
doing
the
disclosure.
The
disclosure
get
gets
that
the
cryptographic
hash
gets
issued
and
then
this
hash
could
be
compared
to
the
content
of
the
disclosure
and
generated
in
a
very
standardized
way.
X
And
then
hash
gets
published
like
very
similar
to
the
pgp
idea
of
publishing,
hashes
of
email,
pgp
signatures.
And
then
someone
who
gets
acquainted
with
the
software
can
then
take
the
disclosure
which
is
published
and
then
generate
the
pgp.
Compare
it
and
and
work
it
with
it.
And
then
we
could
raise
level
of
trust
to
this
disclosure
gradually
by
working
with
a
third
party
validation
companies
who
could
take
parts
of
the
disclosure
check
them
and
then
verify
them.
X
So
where
I
think
help
is
needed
here
are
just
seven
elements
of
the
which
I
listed
and
which
are
also
published
in
the
ie
draft,
which
are
how
to
better
manage
the
components
and
identity
of
the
components.
How
to
manage
the
identity,
validation
providers,
which
will
validate
whether
what
is
disclosed
is
true
or
not.
X
We
have
some
work
done
on
standardizing
privacy
disclosure
to
avoid
lengthy
privacy
policies.
That
says
that
say
how
we
collect
the
data,
how
we
process
the
data
very
important
right
now
in
light
of
gdpr
and
ccpa,
and
all
privacy
regulation
initiatives
and,
of
course,
enhancing
the
label
accessibility,
because,
right
now
the
label
is
only
a
visual
label,
but
we
also
need
to
take
into
account
how
this
label
could
be
also
viewed
and
processed
by
those
people
who
have
limited
visual
capacity.
X
X
I
am
thinking
that
this
work
could
be
done
through
either
ad
sponsorship
or
probably
through
a
new
working
group
right
now
the
work
is
published
on
github.
So
all
the
discussions
are
very
welcome,
as
issues
are
commenced
to
existing
issues
and
we
also
have
a
discord
channel
which
are
jet,
which,
which
is
general
channel
for
discussion,
but
there
is
also
one
for
for
otp
the
protocol
which
which
I
could
open.
If
you,
if
you
beat
me,
thank
you,
and
there
is
also
the
last
slide
with
my
email.
A
Great
thank
you
very
much
for
presenting
your
work
nikita,
especially
with
your
current
circumstances,
just
to
say
that
in
the
jabber
chat,
I
think
there's
a
lot
of
discussion
about
what
a
big
problem
this
is
and
a
lot
of
interest
as
well.
People
saying
it's
interesting,
but
probably
too
big
a
problem
for
ads
sponsorship
a
bit
too
complex
and
so
we're
just
kind
of
open
up
the
floor.
How
could
this
proceed
in
ietf?
Do
you
think
it's
an
interesting
problem
worth
working
on
and
anything
towards
the
dispatch
question?
V
Super
simple
question:
you're,
probably
aware
the
itf
makes
voluntary
standards
modulo,
that's
occasionally
getting
picked
up
by
regulators,
so
one
of
the
critical
questions
for
new
work
is
usually
who
is
interested
in
taking
this
work
up.
So,
in
addition
to
people
you
know
defining
this
stuff,
we
need
folks
to
actually
deploy
it
and
you
know
use
it
for
you
know
for
its
intended
purposes.
So
do
you
have
some
examples
of
who
you
know?
V
X
So
we
have
started
to
work
lately
last
year
with
startups
and
companies
who
were
willing
to
generate
those
labels
because
they
want
to
showcase
their
transparency.
So
mainly
these
are
small
companies
right
now,
but
as
we
planned
this
bottom-up,
we
want
more
smaller
companies
to
start
because
surface
level,
transparency
is
now
more
sufficient,
as
industry
is
getting
mature
and
big
companies
starting
to
use
apis
from
other
vendors
and
even
if
their
processes
are
transparent.
What
is
happening
in
a
third-party
api?
X
A
W
So
I
don't,
I
think,
if
this
work
goes
forward,
it
would
have
to
go
forward
as
a
buff
toward
working,
but
I
don't
think
you're
at
the
point
yet,
where
you've
pulled
apart
enough
of
the
pieces
so
that
we
can
see
as
the
ietf
what
we
would
need
to
work
on.
So
I
think
there
needs
to
be
some
sort
of
pre-work
done
to
pull
out
pieces
that
are
concrete
and
finite
engineering
problems.
The
draft
is
a
little
too
unwieldy.
I
think,
to
handle
right
now.
A
Y
Y
The
idea
of
pii
is
established
and
convened
in
the
eu
region
for
the
general
data
protection
regulations,
but
that
doesn't
necessarily
follow
suit
once
we
leave
the
eu
territory
and
the
second
and
well
second-
and
third
observation
is
that
if
we
provide
end
users
with
information
and
this
information
is
attested
or
verified
by
a
third
party,
what
what's
the
process,
if
the?
If
the
user
says?
Y
Actually
I
don't
agree
with
this
information-
I
think
there's
a
problem
here
and
who
would
pay
for
the
third
party
auditing,
but
in
general
I
think
it's
a
really
interesting
idea,
and
I
I
welcome
it.
I
think
anything
that
allows
people
to
make
informed
decisions
has
got
to
be
good.
From
from
my
point
of
view,
I
think
it's
a
question
of
how
can
we
get
like
a
very
base
minimum
that
works
kind
of
globally
and
is
effective
and
then
there's
something
that
may
be
optional?
Y
X
I
would
like
to
I
would
like
to
answer
your
comments.
I
think
you're
nailing
down
a
very
important
issue
here
and
when
you
say
about
the
unification
of
ethics,
this
is
exactly
what
we
are
trying
to
avoid,
and
this
is
what
is
exactly
what
the
regulation
is
trying
to
bring.
The
regulation
is
trying
to
say
that
certain
products
must
operate
in
a
certain
way.
X
What
we
want
to
bring
is,
instead,
the
description
of
how
products
are
operating
so
that
the
user,
with
the
particular
profile,
can
have
ease
in
selecting
those
products
that
are
closer
or
more
definite
to
to
who
they
are
or
or
what
they
want.
Those
users,
for
example,
who
are
ready
to
compromise
their
privacy
for
safety
or
the
other
way,
would
be
still
able
to
find
the
products
that
they're
that
they're
aiming
for
now.
The
second
question
is
the
validation
verification
question.
X
A
N
That's
hardly
speaking,
thank
you
very
much
for
bringing
the
work.
It's
very
interesting,
and
it's
indeed
very
broad,
and
I
think,
from
the
dispatch
point
of
view
when
I
look
at
the
work
and
and
read
through
some
of
the
aspects.
In
section
four,
for
example,
you
touch
on
storage.
You
touch
on
visual
representation.
You
touch
on
what
what
the
the
different
pieces
would
be
validated
for
by
different
people
it.
N
It
really
gives
me
an
impression
of
something:
that's
an
an
entire
ecosystem
in
in
order
for
it
to
actually
work
and
traditionally
what
those
do
are
systems,
engineering
groups
and
systems.
Engineering
groups
like
3gpp
as
an
example,
define
a
whole
release
for
how
the
whole
system
is
supposed
to
work
together
to
deliver
the
service
to
the
end
user.
N
The
itf
interacts
with
system
engineering
groups
by
taking
requirements
from
them
and
building
the
different
protocol
elements
that
relate
to
that
system,
engineering
group
and
to
other
people
who
might
build
similar
things,
and
I
think
there
are
a
bunch
of
things
that
you're
actually
dealing
with
that.
That
might
turn
out
eventually
to
be
itf
work.
You
know
your
json
application
format
or
something
like
that,
but
at
the
moment,
you're
really
at
the
level
of
building
out
the
systems.
Engineering
thing
and
so
my
honest
response
to
you
from
a
dispatch
point
of
view.
N
You
know
the
the
lego
piece
protocol
requirements
to
the
ietf
whenever
it
has
them
and
whenever
they
fall
into
our
purview
and
not
somebody
else's.
But
I
think
if
you
brought
it
to
the
ietf,
it
would
fail,
because
this
is
the
kind
of
work
that
at
the
itf
would
get
bogged
down
in
a
whole
bunch
of
let's
talk
about
the
protocol
and
not
talk
about
the
system.
So
I
think
for
this
to
succeed.
N
A
Z
I'm
just
gonna
quickly
agree
with
ted
and
then
also
suggest
that
you
go
find.
There
is
a
if
you,
google,
for
consent
receipts.
You
will
find
a
group
who
have
done
very,
very
similar
things
and
there's
a
guy
called
mark
lazar.
You
definitely
want
to
talk
to,
and
I
think
you
have
a
lot
of
in
common
with
them
and
those
are
the
kind
of
people
who
can
help
you
build
that
system.
In
fact,
they
have
a
quite
a
lot
of
traction
for
their
stuff
in
the
canadian
government.
A
A
C
All
right:
well,
we've
got
this
little
moment
as
we
switch
things
over
for
those
of
you
who
walked
in
after
the
meeting
started.
There's
a
qr
code
up
on
the
screen
here
or
if
you
log
into
the
little
light
meteco
client,
then
that
will
have
you
listed
in
the
blue
sheets
and
it's
also
the
place
that
you
can
go
if
you
want
to
speak
in
the
queue
thanks.
A
Thank
you,
yeah
and
we'll
just
summarize
the
dispatch
outcomes
at
the
end
of
the
art
area
meeting,
as
we
always
do
so.
This
is
just
a
note,
obviously
dispatches
the
art
in
the
art
area
and
we
combined
with
the
art
area
meeting.
So
there
are
three
buffs
this
week
for
you
to
be
aware
of
tuesday,
wednesday
and
thursday
at
10
a.m.
How
useful
is
that
to
remember
when
your
buffs
are,
there's
computer
aware
networking
media
over
quick
and
safnet?
A
So
I'm
not
going
to
read
that
out
and
then
because
it's
been
a
while,
since
we've
had
people
in
person
or
a
hybrid
meeting,
it's
our
first
ever
one
just
to
note
some
of
the
new
and
nearly
new
art
related
working
groups,
there,
a
couple
straight
after
this
so
sedate
and
wish
we
have
mediaman
on
wednesday
and
skim
and
oh
hey
or
oh
hi.
However,
you
say
that
yeah,
depending
on
how
you
pronounce
that.
So
that's
what
we've
got
this
week.
A
It's
really
good
to
be
back
in
person,
so
do
go
along
and
see
the
people
behind
those
groups
and
get
involved
in
person
or
virtually
if
you're
still
virtual.
So
we
move
on
to
the
art
area
part
of
the
meeting.
Now
we
just
have
one
presentation
here
on
open
event
at
open
streaming
event
streaming
open
network.
Oh
my
gosh,
I
don't
even
have
jet
lag
as
an
excuse,
so
we'll
just
hand
over
to
emiliano
to
present.
Would
you
like
me
to
drive
the
slides.
H
H
A
H
A
H
However,
when
we
consider
the
connection
of
message
flows
across
organizations,
it
is
not
easy
and
most
of
the
time
it
is
too
costly
and
the
one
of
the
main
reason
maybe
of
this
difficulty
is
because
there
is
no
way
of
referring
to
message
flows
in
the
same
way
that
we
can
refer
to,
for
instance,
an
email
address.
This
means
that
there
is
no
uri
scheme
for
message
flows
and,
on
the
other
side,
dns
records.
H
Maybe
they
are
not
enough,
also,
because
you
know
the
message
flows
and
the
message
brokers
do
not
necessarily
comply
with
the
yana
port
number
registry.
So
the
result
of
all
this
is
that
there
are
a
lot
of
private
solutions,
private
protocols
and
there
you
can
see
a
few.
Maybe
flight
radar
is
one
of
the
most
known
in
which
there
are
people
that
you
know
have
different
devices
on
their
home
scanning
the
electromagnetic
spectrum
and
publishing
to
to
just
one
company
all
of
this
information,
and
that
information
keeps
locked
inside
that
company.
H
H
All
right,
so,
if
we
drill
down
a
little
bit
on
this
on
this
issue
on
this
problem,
if
we
have
two
organizations
that
are
using
messages
are
using
message
flows
not
only
on
a
discrete
form,
you
know,
but
on
a
streaming
form
whenever
they
want
to
connect
these
flows
among
themselves.
There
are
issues.
Basically,
they
need
to
agree
on
an
interface.
H
H
So
if
we
had
an
open
network,
meaning
that
if
we
could
name
all
of
these
message,
flows
with
a
uri
in
the
in
the
way
that
you
can
see
on
this
slide
developers
and
people
using
this
kind
of
messages
would
have
a
common
framework
to
refer
to
these
message
flows.
It
would
minimize
the
offline
communication
of
developers
so
today,
when
we
want
to
send
an
email
to
somebody,
we
just
ask
for
the
email
address.
H
Obviously,
this
would
be
based
solely
on
dns,
basically
on
dns,
so
it
would
be
an
open
network
in
the
sense
that
anybody
that
can
buy
a
can
register
a
domain
and
can
get
a
an
internet
connection
could
participate
in
the
network
without
any
kind
of
discrimination.
In
the
same
way,
we
currently
do
that
for
the
world
wide
web
and
email
next
slide,
please.
H
So
if
we
look
at
a
high
level
how
this
network
would
look
like,
basically,
we
would
have
different
network
participants.
That
would
be
enabling
different
message
flows
and
these
message
flows
could
be
both
private
or
public,
so
the
messages
could
be
composed
in
the
sense
that
one
network
participant
could
use
a
source
of
message
flow
to
enrich
that
information
or
to
use
it
as
an
input
for
a
given
process
and
then
publish
that
the
result
of
that
process
for
another
network
participant
to
to
use
it.
H
Let's
see
an
example
next
slide,
so
imagine
we
have
an
airport
that
has
two
terminals
and
this
airport
publishes
on
two
different
message:
flows:
the
arrivals
of
flights,
and
this
they
will
do
it
on
a
public
manner
right.
Everybody
would
be
able
to
consume
the
messages
as
soon
as
a
plane.
How
do
you
say
arrives
to
the
airport?
H
They
would
get
a
message
saying:
okay,
this
plane
has
just
landed,
and
that
would
be
public
in
the
same
way
that
we
can
go
to
our
website
and
see
which
are
the
planes
that
have
landed.
But
we
are
thinking
about
messages
and
programmatically
connections,
so
there
could
be
a
logistics
company
that
could
use
this
information.
H
It
would
be
you
know,
updating,
according
to
the
messages
that
are
being
received
next
slide,
please.
So,
let's
drill
down
a
little
on
the
architecture
that
each
network
participant
should
use.
So
here
you
can
see
a
lot
of
boxes.
Basically,
we
have
the
core
components
of
the
of
the
network,
participant
at
the
architecture,
with
this
violet
purple
circle
and
there-
and
this
is
highly
inspired
on
the
email
architecture.
So
we
have
a
user
agent
in
the
same
way
that
in
email
we
have
a
mail
user
agent
and
we
have
an
accessing
agent.
H
That
would
be
the
server
side
between
these
two
components.
A
protocol
should
be
used
that
we
have
called
the
accessing
protocol.
Then
the
network
participant
could
use
whatever
message
broker
that
he
wants.
I
mean
they
could
use
rabitmq
mosquito
for
mqtt
server
or
even
apache
kafka,
apache
pulsar,
whatever
they
want.
H
As
long
as
the
accessing
agent,
the
server
side
is
compatible
with
that
with
that
broker,
and
then
there
will
be
a
really
high
reliance
on
dns
in
order
to
be
able
to
resolve
these
flow
uris
and
whenever
a
new
flow
is
created,
the
user
agent
would
talk
with
the
server
side
with
the
accessing
agent.
A
new
message
flow
would
be
created
on
the
flow
events
broker
and
also
published
to
dns
by
means
of
dynamic
dns.
H
So
this
is
one
part
of
the
story.
This
is
only
one
network
participant
and
if
we
look
at
the
connection
at
an
example
of
the
connection
between
two
network
participants,
imagine
we
want
to
subscribe
as
a
user.
I
want
to
subscribe
to
our
remote
flow,
so
that
would
be
a
connection
between
two
network
participants.
Can
we
go
to
the
next
slide?
H
Oh
sorry,
first
the
protocol,
the
protocol
that
the
that
the
server
implements
we
call
it
accessing
protocol
and
it's
really
basic
protocol
here.
You
can
see
the
finite
state
machine
of
this
of
this
protocol.
Basically,
it
supports
authentication
and
also
the
execution
of
commands
in
the
same
way.
Smtp
does
these
commands
would
enable
extensibility
and
and
the
case
that
I
was
mentioning
about
subscribing
to
a
remote
flow.
That
would
be
one
comment.
It
would
be
the
subscribe
comment
all
right.
So,
let's
see
the
example
next
slide,
please.
H
So
here
we
have
two
network
participants,
the
blue
network
participant
and
the
orange
network
participant.
Imagine
I'm
a
user
from
the
blue
network
participant
and
I
want
to
subscribe
to
a
remote
flow
to
a
remote
message
flow
that
would
be
flow
a
so
from
my
user
agent
on
the
blue
network
participant,
I
would
execute
a
subscribe
to
a
flow
uri.
H
The
server
side
would
recognize
that
uri
as
a
remote
flow,
so
it
would
resolve
where
the
accessing
agent
of
that
flow
is
located
and
connect
to
the
server
once
it
connects
and
authenticates
it
will
execute
this
command
subscribe
flow,
a
that
would
trigger
the
creation
of
a
flow
processor
on
the
on
the
orange
network,
participant
that
basically
would
copy
the
the
flow.
The
flow
message
right.
You
can
see
there,
it's
qeqa
it
would
generate
a
copy,
and
this
is
interesting
because,
as
a
network
participant,
I
want
to
have
control
over
my
subscriptions.
H
If
somebody
is
consuming
messages
from
my
from
my
site,
I
mean
from
from
from
one
of
my
users,
I
want
to
eventually
be
able
to
revoke
that
subscription.
So
in
that
case,
bringing
down
that
flow
processor
that
it's
copying
the
messages
would
be
enough
to
revoke
the
subscription
when
the
subscription
is
established.
The
flow
processor
is
created,
a
copy
of
the
message
flow
is
available.
Then
the
blue
network
participant
can
use
that
information
to
set
up
a
new
flow
processor
and
copy
all
those
messages.
H
So
the
the
example
that
I
mentioned
is
the
simplest
one
in
which
we
have
a
flow
processor
that
basically
it's
a
bridge
processor.
It's
basically
transcribing
messages
from
one
message
flow
to
another
one
and
that's
a
command
in
the
protocol
that
it
subscribed,
but
there
could
be
more
advanced
and
complex
situations
in
which,
for
instance,
we
want
to
collect
messages
from
several
flows.
H
So
in
that
case
we
would
execute
the
collect,
command
and
specify
the
source
message
flows
using
the
flow
uri
and
a
destination
flow
using
again
the
flow
uri.
So
basically
this
this
would
allow,
for
instance,
in
the
example
of
the
airport,
to
collect
all
the
arrivals
of
flight
and
publish
them
to
another
message
flow.
We
could
have
a
distributor
flow.
H
So,
basically,
all
of
these
flow
processors
would
cover
a
broad
range
of
use
cases.
By
now
we
have
an
initial
proof
of
concept
that
has
implemented
only
the
subscribe
method
and
we
are
looking
forward
to
continue
working
on
the
next
on
the
next
comments,
all
right,
so
we
are
going
next
slide.
Please
we
are
going
to
have
a
side
meeting
about
this
topic
on
wednesday.
H
H
A
A
A
A
So
we're
going
to
continue
discussion
on
the
dispatch
mailing
list
to
find
an
answer
to
that
updated
use
of
the
expires
message-
header
field
that
was
recommended
for
ad
sponsorship,
as
someone
noted
in
java,
just
because
it's
recommended
doesn't
mean
that
it
will
be
taken
on.
But
that
does
seem
the
the
will
of
the
community,
and
then
emmy
was
suggested
to
be
a
working
group
forming
both
and
finally,
the
open
ethics
problem
nikita
presented
has
agreed.
A
It
was
really
interesting,
work
and
a
very
good
problem,
but
a
bit
big
for
the
ietf
in
its
current
form,
and
so
with
next
steps.
There
are
to
work
out
with
the
community
or
on
the
list
to
work
out
the
itf
specific
parts
of
that
ecosystem
and
bring
that
problem
specifically
back
rather
than
the
entire
problem
space.
A
A
B
Hi
francesca,
I
just
wanted
to
mention
that
the
ecmascript
media
types
updates
document
there
was
a
dispatch
document-
has
exited
the
working
group
and
is
with
the
rfc
editor.
So
just
like
round
of
applause,
and
thank
you,
everybody
for
for
working
on
it
and
making
the
draft
good
and
progressing
it,
and
then,
regarding
the
mayo
maintenance
working
group.
That
was
mentioned
as
as
a
possibility
just
wanted
to
say
that
we
have
mentioned
it
in
with
the
isg.
B
C
C
C
So
this
is,
this
is
something
I
raised.
Yep
just
go
ahead
to
the
next
slide.
Three
things
that
have
come
up
in
the
email
space
that
I'm
aware
of
one
of
which
is
dkim
replay
attacks
are
a
big
deal
in
email
operations
right
now
and
the
second
one
is:
if
we
try
and
solve
dick
and
rep
play
attacks,
we'll
probably
break
more
of
the
indirect
mail
flows,
which
means
we
need
to
figure
out
what
we're
going
to
do
with
arc
to
fix
that.
C
So
the
problem
with
dkim
replay
is
basically
that
dkim
specifies
the
headers
inside
the
email,
but
it
doesn't
specify
anything
about
the
envelope.
So
you
get
one
spam
email
successfully
sent
from
a
trusted
provider
and
it's
dkim
signed
by
that
provider,
and
then
you
can
inject
that
into
anybody's
mailbox
by
just
changing
the
envelope
recipients
and
it
gets
delivered
to
them
with
a
fully
signed,
dkim
flow
as
if
this
was
legitimately
supposed
to
go
to
them.
C
That
mail
can
come
from
anywhere
in
the
world,
because
if
you've
got
dmacc
that
says,
trust,
spf
or
dkim
and
the
dkim
looks
correct
it
passes.
This
was
a
major
topic
at
the
morgue
meeting
a
month
ago.
It's
a
significant
operational
challenge
for
email
providers
everywhere.
So
this
is
really
something
we
do
need
to
look
at.
If
we
could
move
on
to
the
next
slide,
there
one
option
is
to
add
some
kind
of
header
that
gets
signed
by
dkim,
which
has
to
align
with
the
envelope.
C
Obviously,
this
in
the
past,
where
you
might
send
to
multiple
recipients
with
a
single
smtp
session.
You
couldn't
do
that,
but
nobody
does
that.
Anyway,
these
days
you
wind
up
resending
the
message
to
each
recipient,
possibly
because
you're
changing
the
from
address,
possibly
because
your
mail
flow
system
just
works
more
easily
that
way,
but
once
you're
doing
that,
you
could
then
sign
the
message
separately
for
each
recipient
and
have
to
align
it
that
completely
gets
rid
of
this
problem.
C
It
also
completely
breaks
all
indirect
email
flow
because
if
you
are
forwarding
through
an
intermediate
system
here,
sending
to
to
an
alias
at
your
university
or
whatever
then
goes
on
to
your
real
email
address,
the
two
address
changes.
So
you
have
to
rewrite
the
sender
which
gets
us
into
arc,
so
the
next
slide
here
is
yeah.
C
C
So
you
have
to
then
know:
can
you
rewrite
or
not,
and
without
a
way
of
knowing
if
I
supported
the
recipient,
you
have
to
rewrite
everything.
So
the
solution
for
this
is
to
have
some
way
of
knowing
whether
the
recipient
will
accept
arc,
and
so
this
was
something
I
raised
when
I
first
saw
arc
what
five
six
years
ago
in
prague,
we
still
need
to
deal
with
this
at
some
point,
so
arc
supporters
here
signal
at
the
recipient.
I
think,
is
the
correct
way
to
deal
with
this.
C
This
will
again
be
something
that
an
email
working
group
would
hopefully
deal
with
or
it
could
be
dealt
with
in
demark,
but
we
have
dmarc.
We
have
email
core.
We
have
extra
there's
a
lot
of
different
working
groups,
doing
email
related
stuff
and
similar
stuff,
which
is
is
why
I
think
that
the
a
group
that
handles
all
of
this
might
be
the
right
place.
C
There's
a
couple
more
slides,
you
could
add
it
to
the
smtp
capabilities,
but
if
the
mx
says
I
accept
arc
to
the
hello,
then
that's
very
late
to
have
to
actually
update
the
message.
So
I
believe
dns
is
probably
the
right
place
for
this,
and
the
other
question
is:
is
whether
dmacc
policies
need
to
be
extended
to
say
I
don't
accept
being
forwarded
at
all.
Sorry,
it
has.
You
have
to
give
me
the
exact
destination
address
and
that,
I
think,
was
everything
there.
C
The
final
thing
was
the
large
file
problem,
looking
at
what
we
can
do
to
to
deal
with
a
way
of
signaling.
This
is
an
attachment.
This
isn't
just
a
random
link
in
some
html
content,
so
tell
the
recipient
to
you
can
look
at
the
slides.
I
gave
it
last
dispatch
on
this
rather
than
repeating
everything,
but
the
important
part
here
is
lifetime
management
for
the
attached
message.
Right
now
I
can
look
at
an
email
from
10
years
ago.
AA
AA
AA
That's
why
we
punted
on
it
in
the
first
place-
and
we
said
the
best
thing
you
can
do-
is
reduce
the
window
by
expiring
the
the
signature
more
quickly,
but
that's
the
best.
We
could
do
so.
Good
luck
coming
up
with
something,
but
it
is
an
important
issue
and
we
could
not
figure
out
a
way
to
deal
with
it.
AA
The
other
thing
that
al
that
that's
pushing
a
lot
of
these
issues
is
the
dmarc
is
basically
the
same
thing
as
adsp
with
reporting
and
adsp
was
produced
by
the
dmarc
working
group
and
then
failed
miserably
for
exactly
the
reason
that
dmarc
is
causing
problems.
That
organizations
were
using
it
in
ways
it
wasn't
intended
to
be
used.
They
were
using
it
for
messages
that
or
for
sub
domains
that
were
intended
to
be
used
post
to
mailing
lists,
and
then
it
broke
mailing
list
stuff.
AA
The
way
dmarc
is
that's,
also
a
very
difficult
problem
to
solve,
because
dmarc
was
not
originally
intended
to
be
used
for
those
kinds
of
domains
and
certain
domains
found
that
it
solved
a
problem
they
had
and
used
it
so
trying
to
go
back,
pedal
and
figure
out
how
to
make
that
work,
as
we've
done
with
with
arc
is
as
an
attempt
and
just
some
background
and
things
to
think
about.
As
we
try
to
move
forward.
C
A
A
That
is
the
way
we
do
blue
sheets
now
to
record
your
presence
in
the
session,
you
agreed
to
do
that
when
you
registered
for
the
meeting,
thanks
to
everyone
joining
us,
virtually
and
in
person,
thank
you
for
bearing
with
us
with
the
technical
hiccups
and
thanks
to
all
of
our
presenters,
and
thank
you
to
the
community
for
giving
your
dispatch
input
until
114
and
have
a
great
itf
week.
Thank
you.
Everyone
bye.