►
From YouTube: IETF113-HACKATHON-20220320-1300
Description
HACKATHON meeting session at IETF113
2022/03/20 1300
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
C
A
B
A
A
D
A
A
E
E
E
Techo
as
I
am
here,
but
in
any
case
we
should
be
able
to
share
all
the
presentations
using
some
of
the
functionality
we
have,
and
you
know
we'll
work
with
you
to
get
you
set
up,
but
the
idea
is
make
sure
you're
logged
in
to
me
techo
if
you're
going
to
be
presenting
and
when
you
present
you'll
just
be
sharing
from
basically
your
laptop
and
driving
from
your
laptop
so
bring
it
up.
You
can
stick
it
here.
E
E
E
E
I
just
have
a
few
slides.
We
covered
the
notewell
yesterday.
That
still
applies.
That's
where
we're
at.
I
was
just
telling
you
about
the
five
minutes,
and
I
think
we
covered
that
too,
and
here's
something
if
you're
just
logging
into
the
me
techo
and
you're,
trying
to
find
out
how
to
do
it.
If
you
go
to
the
agenda,
you
should
see
a
little
a
little
camera
icon
there.
If
you
click
on
the
camera,
icon
that'll
bring
you
into
the
the
meet
techo
session.
E
The
way
to
do
that
is
using
these
two
icons.
The
one
on
the
left
is
to
share
pre-loaded
slides
the
one
on
the
right
is
to
share
your
screen
so
depending
on
which
functionality
you
need
to
use
to
share
your
presentation.
You
can
choose
one
or
the
other.
In
some
cases,
the
preloaded
slides
will
work
in
all
cases,
if
you're
just
more
comfortable
sharing
from
your
screen,
you
can
always
do
that,
but
again
just
request
to
share
when
it's
your
turn
to
present
come
up
with
your
laptop
and
you'll
present
from
here.
E
What
I'm
going
to
do-
and
I
don't
quite
know
how
to
prepare
for
this,
otherwise,
is
I'm
just
going
to
start
at
the
top
and
work
through
so
the
first
one
I
see
is
dance
is
whoever
is
from
here.
It
looks
like
it
could
be
a
remote
presentation
over
here.
Okay,
perfect
great,
so
you
can
just
share
that
as
pre-loaded
slides.
If
you
want
do
you
have
it
in
your
laptop
already.
E
E
C
That
works
that
works
so
hello,
everyone
I'm
going
to
quickly
present
you
the
work
we've
done
on
dance!
Oh
sorry,
oh
that's!
Better!
Okay!
So
I'm
going
to
present
the
work
we've
done
on
dance,
so
we've
implemented
the
two
drafts
that
are
here
so
the
first
one
is
a
tls
extension
to
other,
dane
client
id
in
tls,
and
the
second
one
is
to
do
the
intent
authentication
so
for
the
intent
authentication
we
based
on
war
or
work
on
the
dane
the
tsa
authentication
library
that
has
been
written
by
schumann.
C
C
So
so
this
is
the
architecture
that
we
had
before
with
a
single
root
ca
that
is
shared
among
all
the
peers,
and
this
is
what
we
have
now,
so
we
are
basically
authenticating
all
peers
using
dance
so
then,
and
with
the
client
id
extension.
So
that's
that
and
that
is
working
well.
So
we're
kind
of
happy
of
that
about
that.
Thank
you.
C
C
F
F
So
gnapp
is
a
delegation
protocol,
a
lot
like
oauth
and,
in
fact,
it's
based
on
a
lot
of
the
things
that
we've
learned
about
over
the
last
decade
of
deploying
oauth
in
lots
of
different
circumstances
and
situations
and
trying
to
kind
of
do
that
type
of
protocol
newer
and
better
we'll
get
into
the
details
of
exactly
what
it
is.
It's
an
ongoing
working
group.
F
F
We
wanted
to
be
able
to
get
tokens
from
those
requests
usable
tokens
and
make
sure
that
we
could
actually
launch
off
different
kinds
of
user
interaction,
because
the
whole
point
of
a
delegation
protocol
is
letting
a
user
delegate
some
set
of
rights
that
they
have
to
a
piece
of
software.
All
right.
We
built
a
bunch
of
new
code.
F
We
now
have
four
different
functional
clients,
systems
on
different
platforms,
php
on
both
cli
and
web.
We
built
an
spa
client
completely
in
javascript,
and
we
had.
We
made
significant
updates
to
some
existing
code
that
we
had
for
a
java
based
web
client
and
the
java
authorization
server.
We
leveraged
as
much
existing
code
as
we
could,
especially
for
supporting
standards
like
http
signatures,
structured
fields
and,
of
course,
native
crypto
primitives.
F
We
weren't
writing
our
own
crypto
libraries
to
make
all
this
stuff
work
and
we've
got
a
list
of
the
stuff
that
we
used
and
other
things
that
are
available
that
we
collected
in
the
lead.
Up
to
this
on
the
working
group
wiki,
we
learned
that
http
signatures
is
pretty
complex
to
do
from
scratch,
but
it's
the
kind
of
protocol.
F
It's
the
kind
of
system
that,
once
you
have
it
done
in
your
platform
in
a
library,
then
you
can
sign
any
http
message.
So
it's
kind
of
like
once
you
have
a
library
on
whatever
you're
building.
Then
then
you're
pretty
much
good
to
go
to
use
it
whatever.
We
both
saw
that
same
kind
of
hump
that
once
we
got
that
piece
going,
the
rest
of
the
protocol,
the
rest
of
the
gnat
protocol
actually
kind
of
fell
into
place
pretty
easily.
F
We
were
surprised
by
some
of
the
fiddly
bits
in
terms
of
like
parameter
order
and
stuff
like
that
which,
if
you've
worked
with
any
security
protocol,
you'd
know
that
that's
kind
of
stuff
that
happens
and
we
found
that
it
is
actually
very
possible
to
implement
several
graph
clients
from
scratch
in
relatively
short
order.
Once
you
get
over
the
humps
of
the
basic
dependencies,
and
I
learned
that
after
all
these
years,
I
still
really
hate
javascript.
F
So
in
in
the
course
of
this,
we
took
a
lot
of
notes
about
different
ways.
We
can
improve
the
spec.
This
is
we
wrote
this
down
mostly
for
our
own
benefits,
so
that
we
can
take
this
back.
I'm
not
gonna
go
through
everything
here,
but
we
found
a
lot
of
places
where,
like
oh,
this
is
a
little
ambiguous
or
aaron
implemented
something
in
some
way.
F
So
this
is
the
web-based
java
client
a
bunch
of
different
configuration
parameters
for
using
the
app
protocol
and
all
the
signature
stuff
that
creates
a
pending
grant
request,
which
you
can
then
approve
at
the
authorization
server.
These
are
two
different
pieces
of
software
talking
to
each
other,
like
most
security
protocols,
it's
really
boring
when
it
works
because
stuff
just
happens
and
it
works,
but
there's
a
lot
of
stuff
going
on
in
the
background
here.
I
promise
so
this
is
this:
was
our
debug
console
showing
some
of
the
messages?
F
We
also
had,
like
I
said,
an
sba
client
that
we
wrote
pretty
much
from
scratch
during
this
weekend.
This
is
entirely
in
browser.
Even
the
key
generation
is
using
web
crypto
api.
So
this
all
runs
completely
in
browser.
Same
kind
of
thing
goes
back
to
the
same
server
and
gets
back
the
same
set
of
information,
and
this
is
a
hackathon,
not
a
production-a-thon,
so
that
css
is
all
screwed
up,
ignore
that.
G
I
was
working
on
the
php
side
of
things,
so
I
have
a
both
a
web
server
based
on
command
line.
I
did
not
use
css.
This
is
just
html
in
the
browser.
You
know
you
go.
You
click
log
in
it's,
it's
showing
you
the
response.
It
gets
as
I
was
debugging.
This
go
approve
the
request
of
the
authorization
server
get
bounced
back
and
surprise.
Surprise
you
are
signed
in
because
you
have
an
access
token.
G
The
on
the
command
line
looks
a
little
bit
different.
You
start
the
request
on
the
command
line.
You
can
open
a
url
in
your
browser
or
scan
a
qr
code
on
your
phone,
which
then
opens
up
that
now
familiar
looking
authorization
server
approval
screen
which,
since
you're
now
on
two
different
devices,
the
phone
is
just
like,
go
back
to
the
command
line
and
finish
there.
G
E
E
H
All
right,
very
good,
I'm
david
oliver!
This
is
hans,
christoph
steiner
over
here
we're
with
the
guardian
project.
We
do
civil
society
work
and
for
this
project
we
hear
we
dusted
off
initial
implementation
of
http
transport
off
the
draft
ideas
here
and
unfortunately,
we
had
a
student
work
on
this
during
the
coveted
time
who
had
some
real
personal
challenges
being
apart
from
his
family,
etc.
So
this
unfortunately
went
dormant
for
a
while.
We
decided
to
pick
it
up
and
and
get
it
working
in
conscript,
so
we
could
over.
H
We
have
a
case
where
we
want
to
authenticate
traffic
that
isn't
just
request
response,
and
so
we
want
something
that
runs
alongside
normal
web
services
and
can
authenticate
a
tls
session
without
leaking
information
in
the
client
hello.
So
this
is
a
a
technique
for
pulling
information
out
of
the
tls
connection
common
to
the
client
and
the
server
and
using
that
to
encrypt
credentials
in
a
way
that
flows
with
the
http
connect
flow
on
success.
H
You
get
ht,
200
connection
established
and
on
failure
you
get
400
405
method
not
allowed,
so
we
were
able
to
get
this
working
in
conscript
quite
a
quite
a
pile
of
stuff
to
get
working
for
just
a
very
thin
shim,
and
so
that
was
great.
We
also
mapped
out
how
this
could
be
implemented
in
python
and
chronet.
H
We
aren't
aware
of
anyone
else
doing
this
work,
so
we're
sort
of
looking
for
an
inter
partner.
We
don't
have
a
full
proxy
flow.
We
were
not
trying
to
rebuild
some
proxy
service
on
the
server
side,
so
we're
possibly
waiting
to
get
our
python
work
done
before
we
start
doing
that.
The
github
repo
is
here.
We
were
curious
about
this
keying
materials
export
function
in
in
the
tls
layer,
and
we
did
discover
that
the
languages
that
implement
openssl
or
boring
ssl
generally
make
this
available.
H
Python
currently
only
gets
it
via
pi
openssl,
a
secondary
library
rather
than
native,
but
there's
an
open
issue
for
the
language.
Go
exports
a
function
for
this
rust,
microsoft
and
mozilla.
So
we
felt
really
good
about
places
other
methods,
other
language
systems.
We
could
use
to
implement
a
function
here,
so
here
we
are
david
and
hans
from
guardian
project,
there's
our
url
and
pointer
to
the
draft
and
our
repo.
E
E
I
kind
of
forgot
that
we
usually
let
people
ask
questions
too,
which
I
guess
we
could.
We
could
try
to
do
as
well.
Although
I
don't
know
if
the
muteco
light
client
is
available,
so
for
people
in
the
room,
if
you
have
a
question,
maybe
just
raise
your
hand,
people
online.
If
you
throw
something
into
the
chat
we
can
transfer,
we
can
you
know,
have
you
ask
questions
that
way?
E
E
C
J
K
K
J
K
J
J
K
K
K
J
Lastly,
we
introduced
the
application
interface
to
enable
automatic
policy
feedback,
so
we
can
provide
the
problem
information
to
security
controller,
to
help
identify
the
legion
of
the
security
attack
or
system
of
road.
Something
like
that.
So
this
is
so
we
previous
or
complicated
compilation
into
the
more
simplified
version.
This
time
also
previously
multiple
event:
notification
constantly,
you
know
consolidated,
which
means
merged
into
one
single
modification.
J
K
C
E
J
J
From
poison
national
university,
so
this
is
the
ipwa
hackathon
project.
The
basically
we
used
wave
protocol
left-hand
side
is
the
tcpip.
Over
previously
we
used
the
i2p
wave,
and
now
we
used
5gb
2x.
So
also
we
implemented
the
context
of
aware
navigation
protocol
among
vehicles.
Also,
this
time
we
enabled
the
communication
between
drones.
Okay,
so
we
have
two
parts.
First
part
is
the
simulation
context
aware
on
navigator
protocol
cmp
for
trunks,
so
previous
site,
itf,
102
hackathon
case.
We
implemented
the
context
of
a
navigator
or
protocol
for
vehicles.
J
J
K
H
J
D
J
J
O
K
K
J
J
J
J
J
J
K
D
K
E
J
E
E
E
E
E
S
N
R
J
R
C
N
U
Nice
yeah
so
yeah.
Thank
you
very
much,
I'm
jordy
rogerald
and,
on
behalf
of
the
alto
working
group
and
yeah,
I'm
going
to
present
our
hackathon
using
alto
cars
maps
to
optimize
data
set
transfer
for
lhc,
the
large
hadron
collider
yeah,
just
starting
with
a
very
big.
Thank
you
note
to
all
the
people
who
actually
participate
in
this
hackathon
from
the
alto
working
group
working
endless
hours,
managing
three
different
time
zones
for
the
last
two
weeks.
Actually,
so
thank
you
very
much
yeah.
So
actually
this
is
this.
U
Hackathon
is
for
us
sort
of
like
a
kickoff,
because
we
are
starting
an
initiative
within
the
alta
working
group
to
to
create
what
we
call
the
alto
code
based
project,
basically
which
aims
at
providing
a
parallel
track
to
the
working
groups.
Standardization
effort
towards
implementing
the
the
features
introduced
in
the
latest
rfcs.
U
Basically,
so
the
hacker
and
the
hackathons
will
be
used
as
three
checkpoints
a
year
to
test
interpret
interoperability
and
the
latest
capabilities
implemented
from
the
protocol,
basically
to
collect
feedback
and
sort
of
socialize
some
of
the
latest
ideas
as
well
so
yeah.
So
we
you
know,
we,
the
goal
of
this
effort
basically
is
to
actually
deploy
alto
and
develop
the
the
codebase
closely
connected
with
production
applications
and
in
this
hackathon.
U
U
So
you
know
we
welcome
people
to
actually
join
us
and-
and
we're
gonna,
be
you
know,
between
the
hackathons,
we'll
be
creating
teams
epics
using
a
scrum
and
coding,
basically
to
kept
to
get
the
the
code
running
basically
yeah,
so
the
goals
for
this
hackathon
yeah.
So
the
goal
is
to
use
autocause
maps
to
optimize
dataset
transfers
for
russio.
Russia
is
the
the
application,
like
I
mentioned,
used
by
scientists
to
share
large-scale
data.
U
Sets
the
the
focus
is
on
integration
of
the
alto
northbound
interface
with
ruthie,
to
provide
better
visibility
to
application
to
make
better
decisions,
so
alto
basically
provides
the
the
state
of
the
network
provides
bandwidth,
availability
or
latency
from
the
network
depending
on
the
sort
of
the
dynamics
of
the
network
and
then
provides
that
information
to
the
application.
So
you
can
make
better
decisions
on
how
to
you
know,
upload
or
download.
These
large
data
sets
basically
yeah,
so
the
rfc
is
involved
in
this
hackathon
are
in
this
slide,
what
got
done
so?
U
U
So
that's
going
to
extend
that
with
the
capability
to
actually
be
able
to
choose
the
algorithm
upon
which
you
may
make
those
decisions
on
where
you
download
the
replica
from
based
on
network
conditions.
Basically,
we
we
work
on
feed
demos.
Basically,
then,
I'm
gonna
just
touch
on
them
a
little
bit
and
then
also
extensions
on
southbound
alpha
integration
with
the
as
with
asean
controllers,
with
mininet
and
open
daylight,
you
have
a
scrum
dashboard.
U
U
You
know,
if
you
look
at
the
this.
I
draft,
which
provides
a
table
of
all
the
metrics
that
we
focus
on
for
this
hackathon
on
the
round-trip
delay
and
available
bandwidth
demo.
One.
The
goal
here
is
to
be
able
to
make
smart
decisions
on.
Where
do
I
get
my
data
from
suppose
you
are
a
scientist
and
you're
trying
to
get
like
a
huge
data
set
that
needs
to
be
globally
transferred
and
you
have
different
replicas
you
can
choose
from
so
you
just
want
to
know
what
you
are
right
now.
U
What's
the
best
choice
I
can
do,
and
so
alto
is
an
abstraction
layer
that
provides
that
kind
of
information.
In
this
case,
what
you
see
is
step
one
look
up
the
host
by
finding
the
longest
practice
practice
match
step
two
bandwidth
between
hosts
as
the
alter
host
cost.
So,
although
you
query
the
alto
and
you
get
the
sort
of
the
bandwidth
cost
map
for
each
range
of
the
endpoints,
you
can
choose
from
step
three.
You
get
the
replicas
back
from
the
alto
service
order
by
the
bandwidth
availability.
U
U
Yes,
this
is
actually
some
of
the
results
from
the
demo.
You
can
see
that
if
you,
if
you
use
sort
of
what
the
scientists
do
today,
which
is
sort
of
like
a
an
agnostic
decision
without
knowing
what's
going
on
in
the
network,
you
would
get
certain
performance.
But
if
you
are
aware
of
you
know
what
are
the
link
capacities
and
what's
the
the
path
that
you're
gonna
be
choosing?
What
are
the
network
conditions,
then
you
can
make
that
you
can
do
better.
U
So
here
you
see
four
to
five
x
speed
up
in
the
simulations
that
we
run
over
the
weekend.
Basically,
this
is
running
on
mininet,
basically
so
simplified
environment
and
the
same
thing
can
be
done.
You
know
based
on
latency,
so
I'm
not
going
to
go
into
it.
Just
like
some
experience
experience
where
you
choose
based
on
latency
and
then
I
have
two
more
demos.
We
actually
put
an
auto
estimator,
a
multi-flow
throughput
bandwidth
prediction
and
demo
three
and
auto
scheduler,
which
allows
you
to
do
sla,
constrain,
multiflow,
node
selection.
U
So
suppose
you
have
certain
requirements
to
guarantee
say
I
want
to
get
my
data
transfer
by
5.
Am
tomorrow
because
I
need
to
work
so,
please
give
me
sort
of
you
know
there
are
the
replicas
that
I
should
select
and
from
you
know
so
that
I
can
meet
my
my
requirements
say
so
this
demo,
the
demo
number
three
is
half
baked,
but
we're
almost
close
to
actually
finished
yeah,
so
yeah.
Thank
you
very
much.
So
you
know
welcome
anyone
who
actually
wants
to
participate
in
the
in
the
project.
U
C
C
E
I
I
I
I
Our
more
recent
work
has
looked
at
the
its
social
graph,
so
who
makes
up
the
itf
and
what
are
their
participation
trends
for
this
hackathon,
though
I've
been
looking
at
analyzing
rc
errata
to
sort
of
motivate
why
you
might
want
to
look
at
rsc
errata.
Previously,
we've
seen
that
rcs
can
take
a
really
long
time
to
get
published.
So
this
plot
here
shows
the
number
of
days
from
the
first
draft
to
publication
of
the
rfc
itself,
and
we
can
see
that
you
know.
I
Despite
this
really
long
drafting
and
editing
process,
we
also
see
that
there
are
still
arata
being
filed
against
rfcs,
so
the
trend
over
the
last
decade,
or
so
has
been
around
about
300
errata
being
filed
each
year,
and
so
our
question
then
becomes
in
spite
of
this
multi-month
or
multi-year
editing
and
drafting
process.
Why
do
a
rapid
still
occur
and
what
can
we
learn
from
those
errata
that
might
inform
our
learning
about
rfc
authorship
and
the
process
behind
it?
I
So
thinking
about
the
kinds
of
rfcs
that
contain
mostarata,
this
plot
shows
errata
filings,
broken
down
by
area.
We
can
see
a
couple
of
outliers,
the
former
application
group
area
rather
and
the
security
area
both
have
most
errata
pair
rc
across
all
the
areas.
Now,
ultimately,
we
don't
know
why.
Yet
you
could
conjecture
that
security
rfcs
contain
certificate,
algorithms
and
pseudocode,
and
that
lends
itself
to
containing
more
errors,
but
we
need
to
explore
further
think
about
how
long
it
takes
to
identify
errata.
I
I
I
I
I
Is
that
mistake
in
the
diagram,
etc,
etc?
And
so
I'm
going
to
finish
with
a
pitch
for
people
to
visit
our
website
user
tooling,
you
can
break
their
rata
filings
down
into
working
groups.
So
if
you
go
along
and
find
the
working
groups
that
you're
active
within
you
can
look
at
the
rata
filings
within
those
groups
and
if
you
can
help
us
out
by
adding
more
descriptive
labels
for
what
those
errata
filings
are
saying.
I
I
I
L
O
O
O
This
is
a
new
id
driver
and
dns
set.
It
allows
you
to
try
out
dns
before
going
live
with
it,
because
that's
a
bit
scary
for
many
people
and
rightfully
so,
and
it
does
this
it's.
The
idea
is
to
have
a
new
delegation
signer
algorithm,
which
just
wraps
existing
delegations,
china,
algorithm
and
just
signals.
O
O
If
there
are
other
situations,
you
fall
back
to
secure,
probably,
but
that's
where
you
can
try
out
like
algorithm,
draw
overs
and
all
sorts
of
dnsx
situations,
so
this
has
to
be
backwards
compatible.
So
we
we,
what
we
did
was
run
ripe
atlas
measurements
with
the
new
delegation.
Signer,
unfortunately,
ripe
atlas
had
some
issues,
so
there
are
no
actual
numbers
in
these
fender
grooms
yet,
but
hopefully
they
will
be
there
when
a
dinosaur
is
happening.
O
Catalog
zones,
we
did
interoperability,
testing,
there's
a
new
binder
implementation
for
the
version
in
the
draft
and
we
created
a
table
on
the
hackathon
wiki
to
coordinate
which
catalogs
were
served
by
which
implementations
and
which
other
implementations
consumed
them.
So
there
was
a
good
progress
there,
yep
and
then
indeed.
Finally,
there
was
the.
O
Well,
that's
not
completely
correct,
I
think,
oh,
that
was
a
dynamic
update
over
encrypted
transport.
Unfortunately,
this
is
not.
The
slide
is
not
correct,
but
this
doesn't
really
matter.
I
can
tell
about
it,
so
queries
can
go
now
over
encrypted
transport
and
recently
also
transport
over
tls
in
dns,
and
this
is
our
id
to
also
do
dynamic,
updates
over
encrypted
transports
and
there's
a
server
implementation
for
this
now
and
several
client
implementations.
O
Online,
so
not
in
person
and
they
booked
a
great
success
here.
You
can
see
benjamin
frye
reporting
success
on
the
dns
of
a
tls,
dynamic
updates,
implemented
in
rust,
and
then
tony
finch
started
recently
working
for
ic
but
decided
to
do
some
improvements
for
a
an
illness
implementation.
So
that's
really
great.
O
O
C
M
M
M
We
were
just
having
discussions
on
whether
to
have
authentication
authorization
and
how
do
we
do
it
so
the
plan
solutions
were
so
so
far.
Of
course,
we
need
an
authentication
to
share
this
information,
so
we
rely
on
the
standard
established
protocols,
tls
mls,
for
authentication,
and
then
we
have
an
allow
list
which
can
have
ip
prefixes
our
client
identities,
which
are
derived
from
authentication.
M
We
did
have
conversations
on
how
the
primary
primary
key
encapsulation
mechanism
should
happen.
We
are
using
hpk
for
our
encryption
and
the
registration
phase
basically
performs
the
key
encapsulation
mechanism
tomorrow,
we'll
be
showing
a
demo.
You
have
a
side
meeting
scheduled
in
green
room.
1
8
am
what
we
learned.
So
pdmv2
is
a
new
concept
and
we
would
like
to
get
a
poc
which
works
and
which
covers
our
complete
idea
and
registration
for
the
registration
protocol.
M
T
Q
Hi
everyone,
that's
a
one
person
project.
I
was
this
time
previously.
We
were
a
bunch
of
folks,
but
due
to
travel
restrictions
and
so
on.
Just
me
here
I
was
working
on
firmware
encryption,
which
is
related
to
the
suit
working
group
and
uses
specifically
working
courses
of
new
work,
and
the
plan
was
to
implement
the
cosy
hp.
Q
I
got
the
encrypt
and
decrypt
functionality
done
with
this:
the
decocy
internal
abstraction
layer
that
library
offers
the
possibility
to
swap
out
different
crypto
implementations.
Currently,
there
are
two
one
based
on
psa
crypto
api
and
the
other
one
based
on
openssl,
so
it's
quite
convenient
to
actually
do
that.
Q
I'm
happy
to
be
here
to
see
some
of
the
familiar
faces
again
sitting
next
to
lawrence,
which
was
obviously
a
a
big
benefit
being
next
to
the
main
dana
one
of
the
big
benefits
of
having
a
face-to-face
event,
rather
than
a
virtual
one
made
some
good
progress.
But
of
course
I'm
not
done
yet.
Just
cozy
is
not
a
terribly
complicated
specification,
but
still
complicated
enough
for
this
purpose.
So
the
content
will
be
uploaded
to
this
repository
and
yeah.
That
was
it.
Two
links
to
the
specifications
that
are
relevant.
C
Q
E
A
S
And
server
implementation
already
existed
from
the
masters
project
at
the
university
of
brim,
where
I'm
currently
in
what
I
actually
did
or
get
done,
is
to
have
a
first
functioning
code
for
each
noob,
but
not
completely
mainly
just
the
json
and
message
parsing
and
checking
for
the
correct
format.
It's
not
yet
completely
functional
the
key
handling
and
the
cryptography
parts
are
completely
missing,
mostly
because
I
had
to
figure
out
how
esp-idf
is
handling
the
eep
stack
as
a
side,
project
or
site
work.
S
S
I
E
E
V
V
So
polka
is
a
new
source,
routing
or
forwarding
paradigm
that
will
be
presented
here
on
thursday
by
two
colleagues
from
our
team
from
brazil.
Actually
that
has
been
implemented
in
free
router,
including
the
p4
data,
plane,
implementation,
exciting
work
and
another
example
of
these
special
uses
is
also
represented
here
by
carmen,
from
cern
where
some
physicists
reminded
me
of
the
alto
talk
try
to
solve
some
other
problems
of
their
very
large
data
transfer
needs
by
marking
flows
using
the
ipv6
flow
label
and
doing
traffic
engineering.
V
V
V
So
the
plan
was
mainly
to
bring
our
community
together
because
the
people
who
joined
the
project
over
the
past
years,
we
never
met
in
person
for
various
reasons,
well-known
reasons
and
we
so
we
prepared
a
large
list
of
potential
projects,
most
of
which
we
can
still
move
forward
to
future
hackathons,
because
we
worked
on
some
completely
different
stuff
and
of
course
the
images
didn't
make
it.
So
maybe
I
should
have
shared
my
phone,
but
it's
well.
V
V
E
V
Okay,
you
really
want
to
share
yes,
I
hope
it
lets
me.
Oh
no.
I
think
I
I
think
I
missed
a
okay
yeah
with
me
just
a
second
okay
that
looks
looks
a
bit
better
okay,
so
so
these
were
the
the
things
we
we
did.
The
most
important
thing
is
probably
the
the
last
the
image,
because
we
did
manage
to
bring
the
at
least
a
part
of
the
community
together
and
and
provide
like
the
the
social
basis
for
a
good
collaboration
in
the
future.
V
Unfortunately,
not
all
of
us
could
make
it
here,
some
had
like
covet
or
family
reasons
to
stay
at
home,
okay,
so
so
this
unicast
rpf
feature.
It
was
very
interesting
to
us
because
it
touches
all
the
all
the
components
of
this
three
router
system,
including
data
planes.
First
of
all
the
configuration
here,
you
see
the
typical
way
it's
configured
on
an
interface
you
you
ask
for
this
verify
source,
that's
compatible
with
industry,
standard
routers,
a
couple
of
variants
that
are
described
in
different
rfcs
and
is
actually
ongoing,
work
to
refine
this
some
more.
V
So
this
also
lays
the
basis
for
implementations
of
new
itf
standards.
That
may
come
up,
but
the
the
tricky
part
is
actually
the
mapping
to
the
high
speed
forwarding
plane.
So,
as
I
said,
basically,
you
just
do
a
look
up
in
the
normal
forwarding
table,
but
based
on
the
source
address
rather
than
the
destination
address.
V
Only
the
the
folding
hardware
does
not
permit
you
to
do
two
lookups
with
different
keys
in
the
same
table.
So
what
we
actually
had
to
do
is
to
create
new
tables
which
are
basically
a
copy
of
the
normal
forwarding
table
just
for
this
rpf
lookup.
I
think
some
some
people
are
dealing
with
some
high-speed
routers
know
this
issue,
a
typical
feature
that
cuts
your
routing
table
capacity
in
half.
V
V
So
all
of
us
got
a
good
glimpse
into
the
the
development
process
for
free
router.
So
we
know
now
what's
what's
involved
in
adding
new
features,
especially
ones
that
have
data
plane
impact,
so
it's
a
good
basis
to
implement
more
protocols
that
you
folks
may
be
creating
one.
Other
thing
we
noticed
is
that
the
ipv4
implementation
of
this
urpf
check
worked
kind
of
right
away,
naive
implementation,
but
for
ipv6
it
took
quite
a
bit
longer
and
the
fundamental
reason
was
that
people
25
years
ago
they
just
decided
it's
more.
V
It
should
be
simpler
to
fold
the
neighbor
discovery
protocol
into
the
ip
protocol,
whereas
in
ipv4
it's
a
separate
protocol.
This
is
our
protocol
and
it
turns
out
it
looks
like
a
nice
idea,
but
actually
makes
all
these.
It
creates
a
bunch
of
exceptions
that
you
have
to
deal
with.
So
maybe
this
is
a
useful
conclusion.
It's
not
always
like
worth
saving
the
number
of
different
protocols.
Maybe
it's
sometimes
better
to
have
an
additional
protocol.
That
does
one
thing
well,
anyway:
water
under
the
bridge.
V
V
V
If,
if
you're,
looking
for
like
a
second
implementation
of
your
exotic
protocol,
talk
to
us
talk
to
java
the
free
router
main
developer,
sometimes
we
can
implement
new
protocols
and
new
features
very
quickly,
because
it's
a
relatively
compact
code
base
and
yeah
thanks
a
lot
for
your
attention.
Thanks
for
the
the
nice
work
doing
the
hackathon.
E
E
Q
X
X
X
X
X
And
it
was
a
bit
different,
so
it
was
fun
we
we
made
this
ancient
hp
relay
actuator
with
young
and
netconf
by
adding
a
raspberry
pi
and
a
hat
that
controls
the
gbp
interface
and
we
we
could
have
not
done
that,
but
it
was
fun.
So
we
we
wanted
to
to
use
only
again
to
manage
all
the
aspects
of
the
automation
of
the
test.
K
So
our
proposal
is
to
install
the
adaptive
subscription
policy,
which
is
built
on
top
of
the
young
push
mechanism
and
allow
the
server
to
switch
to
different
period
intervals
based
on
the
network
condition
chains
and
our
focused
text
scenario
is
the
awareness
network
performance
monitoring.
The
objective
is
to
monitor
kpi
changes.
K
To
collect
data
from
access
points,
the
network
devices
in
our
campus,
and
we
have
evaluated
the
following
data
collection
methods,
a
high
frequency
periodic
telemetry,
a
low
frequency
periodic
telemetry
and
adaptive
frequency
parametric,
and
also
for
each
data
collection
method.
We
have
evaluated
two
cases,
one
is
to
report
the
rssi
values
so
as
to
detect
the
real
time
with
a
roaming
across
different
aps,
and
the
other
is
to
stream
the
bytes
from
the
ap
uplink,
so
as
to
detect
the
potential
link
congestion,
and
we
also
use
the
elk
to
collect
analyze
and
visualize
the
data.
K
Q
N
D
K
Is
to
evaluate
the
condition
and
make
the
decision
of
adjusting
the
period
at
the
subscriber's
side,
and
the
other
is
at
the
server
side,
and
the
results
show
that
for
the
first
way,
it
prevents
the
subscriber
from
capturing
roaming
events
which
lasts
only
two
to
four
seconds
which
is
incomplete.
Actually,
while
the
second
way
the
server
will
evaluate
the
condition
at
the
end
of
each
high.
A
K
D
Q
K
E
R
R
So
see
what
we
have
done
so
far
in
previous
high
cotton,
so
this
is
a
networking
model
and
the
performance
impact
that
I
mentioned
about
so
in
previous
has
gotten.
We
have
already
made
them
asking
about
the
kernel
spray
in
this
way
and
spanning,
and
we
have
done
a
performance
impact
about
cpu
isolation
and
luma
aluminum.
R
R
So
this
is
a
band
marking
scenario,
so
we
use
a
srov
combined
with
the
vpp
sr
fire
we
will
use
for
noise,
traffic
and
vp
will
be
used
for
eastward
traffic
and
we
test
in
two
scenarios.
The
first
one
is
single
node
and
the
second
one
is
the
monty
nose
and
inside
signal
node
one.
We
will
increase
the
number
of
parts
from
true
board
for
both
sig
board
to
test
the
impact
of
the
number
of
vmfs
on
the
three
function.
Chaining.
V
R
Two
underlay
to
connect
within
two
nodes:
this
is
the
tempest
of
our
our
topology
database.
This
is
the
configuration
of
our
testbed
and
this
is
the
result.
So
what
we
learned
in
this
hackathon
is
the
based
on
the
result.
We
see
the
sr
iov
and
vp
combine
model.
We
have
signific
significantly
better
performance
using
vp
only
because
vp
traffic
need
to
go
to
the
v6
in
our
srv
download
in
combine
model,
and
the
second
thing
is
the
impact
of
the
number
of
vmf.
R
R
R
R
A
W
Okay,
so
I
will
talk
about
what
we
have
done
on
with
chic.
So
chic
is
a
protocol
to
compress
ipedia
to
put
ip
in
very
constrained
networks
such
as
lorawan,
sick,
fox
or
5g
narrowband
iot,
and
so
we
we
have
this
rfc
that
describes
chic
and
we
use
openshift
to
develop
the
standard,
but
it
has
been
done
by
several
developers
and
now
our
effort
is
to
put
all
the
things
together
to
have
something
that
works
well
with
all
the
feature
together.
W
That
is
well
documented
to
help
people
to
to
use
it.
So
that's
what
we
we
did-
and
we
saw
also
work
on
the
young
version
of
the
description
of
the
rules
to
allow
interoperability
between
different
implementation,
and
we
also
work
on
a
new
feature
that
is
called
component
act.
That
is
used,
for
example,
for
sig
fox
technology.
W
So
what
we
have
done
so
we
we
implement
the
platform.
We
also
have
some
documentation,
effort
to
understand
what
is
chic
and
how
to
use
it
with
open
chick.
We
have
to
push
the
core
com
version
of
the
young
mod,
the
disc
young
description
model
into
the
the
github,
and
we
have
also
saw
this
version
of
sheep.
W
So
what
we
have
learned
so
that
first
core
conf
is
quite
nice,
so
we
have
a
very,
very
compact
representation
of
the
rule.
If
we
compare
to
the
division
version,
we
divide
by
six
the
size
of
of
the
rule.
So
that's
quite
interesting,
especially
in
compressed
network,
but
we
have
discovered
some
funny
things
with
core
confidence
that
you
classify
all
the
entry
by
alphabe
alphabetical
order
and
we
have
in
each
row
we
have
the
rule
id
and
the
rule
id
is
30
value
after
the
reference
value.
W
So
it
means
that
in
c
bar
we
need
two
bytes
instead
of
one
byte.
So
this
is
not
that
bad,
but
we
can
try
to
improve
the
compression
by
changing
the
seed,
the
seed
order,
and
we
will
have
to
discuss
about
that
in
the
working
room
and
for
the
members.
So
we
have
people
that
were
here.
Like
me,
we
have
dominique
bartel
sergio
aguiar
on
cedric
engine.
W
R
E
E
E
So
after
we
finish
with
this
presentation,
that
will
be
it
for
the
the
hackathon,
but
we
do
still
have
hack
demo
happy
hour
and
I'm
really
happy
about
this,
because
this
is
one
thing
that
you
know
we
we
didn't
even
attempt
to
do
in
an
online
only
event,
but-
and
you
know
so-
we'll
have
hackdemo
happy
hour
for
any
of
you
that
want
to
have
post
some.
You
know
deeper
discussions
about
your
project.
E
If
you
want
to
stick
around
and
you
know,
you'll
have
a
table
and
people
can
come
up
and
you
can
do
demos
or
talk
about
your
work,
and
so
it
it's
an
hour
and
a
half.
As
you
can
see
here
it's
from
1700
to
1830
tomorrow
and
you
can
register
now.
You
can
register
up
until
noon
tomorrow.
If
you
want
to
participate
and
then
we'll
have
some
space
there
it'll
be
in
this
room.
E
I
don't
know
if
it's
on
this
side
or
this
side,
but
you
can
come,
you
can
set
up
whatever
you
want
and
just
have
a
more
in-depth
conversation
with
people,
whether
they
participate
in
the
hackathon
or
not.
They
can
come,
find
you
and
learn
more
about
your
project.
So
if
you're
interested
in
doing
that,
I
think
it'd
be
great.
Please
just
make
sure
you
register
and
then
we'll
we'll
work
with
you
to
get
the
space
up,
and
you
know
the
logistics
and
that
okay
to
see
it
are
there.
E
Is
there
anyone
here
who's
planning
on
presenting
their
project
tomorrow
at
hackdemo
happy
hour
great
so,
and
hopefully
we
get
a
few
more
okay,
wonderful
and
for
people
who
are
remote
you
can
you
can
participate
as
well.
We
will
have.
I
don't
know
if
we'll
use
me
techo,
but
we'll
we'll
talk
with
you
about
how
we're
gonna
do
that
we'll
have
some
type
of
video
conferencing
set
up
for
you.
E
The
other
thing
is,
this:
room
will
stay
available,
so
you
can
come
here
and
this
will
be
the
the
ietf
lounge,
but
a
part
of
it
will
be
designated
as
the
code
lounge.
So
if
you
want
to
continue
to
work
on
your
projects
throughout
the
the
week
of
the
ietf
you're
welcome
to
come
and
you
can
register
for
that
as
well.
You
don't
have
to,
but
just
to
help
you
arrange
your
schedules
with
other
people.
E
E
Y
Hello,
everyone,
sorry
for
keeping
you.
So
we
are
the
participants
at
the
table
h
together
with
a
couple
of
newcomers,
david
and
loic,
who
are
very
welcome,
who
have
been
very
welcome
to
join
us
for
this
hackathon.
So
we
are
the
participants
in
the
lake
working
group
where
we
standardize
the
lightweight
authenticated.
Key
exchange.
Protocol
for
constrained
environments
and
constrained
means
embedded
systems
in
most
in
most
cases,
and
we
have
nine
implementations
of
of
the
lake
protocol
that
are
available.
Y
Y
So
our
goal
is
to
produce
an
implementation
that
is
probably
secure
and
what
does
what?
That
means
is
that
we
can
prove
correctness
on
the
implementation
correctness
in
respect
to
a
given
model
to
prove
memory,
safety
of
the
implementation
and
the
proved
side
channel
resistance
against
such
an
all
attacks.
Y
So
what
you
see
here,
I
won't
go
into
details
I'll
go
right
quickly,
because
this
is
the
last
presentation.
This
is
the
methodology
essentially
in
practice.
What
it
turns
out
to
is
that
you
need
to
implement
some
code
in
rust
in
a
subset
of
rust,
called
hackspec,
and
once
you
get
to
that,
you
kind
of
this
is
your
kind
of
model
that
later
you
turn
into
that
you
compile
into
this
language
called
f-star
that
they
use
to
generate
and
formally
prove
properties
on
the
implementation.
Y
Y
The
first
step
is,
I
said,
is
to
implement
and
implement
this
model
in
rust,
hackspec
to
generate
this
f-star
model,
which
is
automatic
through
their
through
their
tools,
and
then
there
is
a
third
step
to
like
write
and
verify
another
in
another
mathematically,
abstracted
language
called
low
star
against
this
f-star
implementation
and,
finally,
to
generate
some
formally
verifiable
code,
which
can
be
either
rust
or
c
again.
So
you
start
from
rust
and
you
end
up
with
trust
or
c,
which
is
formally
very
file,
and
this
is
available
on
github.
Y
So
the
implementation
goals,
we
want
verifiable
code,
but
that
can
exit
be
executed
on
microcontrollers.
We
want
a
minimal
implementation,
so
we
are
not
aiming
for
something.
Generic.
A
minimal
implementation
in
our
case
means
static,
static,
difficulty,
authentication
with
initiator
mode
only
in
the
initiator
mode.
We
don't
want
any
dependencies,
so
basically,
what
we've
done
is
purely
on
pure
rust,
without
dependency
on
the
standard
library.
So
I'm
talking
no
memory
copy
implementing
memory
copy
with
force
with
for
loops.
We
don't
rely.
Y
Passing
the
test
vectors
from
that
are
published
in
the
draft
in
lake,
we
came
with
a
full
crypto
support
for
on
on
on
on
power
on
non-constrained
devices
with
hux
pack,
and
we
came
with
hardware
abstraction
layers
for
two
platforms,
cc2538
and
another
50
to
840..
So
this
was
our
starting
point.
What
we
got
to
implement
is
that
we
extended
the
api.
We
implemented
the
api.
We
implemented
the
protocol
state
machine
with
hackspec,
so
it's
important
to
understand.
Y
I
mean
I
was
talking
about
formally
provable
code,
so
this
model
that
you
write
in
russ.
This
is
executable
code.
This
is
an
implementation,
just
as
any
other
that
can
interoperate,
and
we
prove
that
during
the
hackathon
we
interrupt
with
california,
with
java
based
implementation,
california,
madhok
and
yes
here
you
can
see
some
screenshots
from
the
implementation.
Essentially
the
protocol
deriving
the
same
the
same
shared
secret
after
the
run
of
static,
static,
difficult
authentication
and
yes,
the
code
is
open
source
under
bsd
license
available
on
github
under
this
link.
Y
E
Okay,
I
think
that's
it
any
other
presentations.
We
got
them
all
all
right.
Well,
fantastic
thanks!
Everyone
for
participating
in
the
hackathon,
it's
super
exciting,
to
have
the
opportunity
to
be
here
in
person
again
and
thanks
for
sticking
around
for
all
the
presentations.
I
do
hope
you
to
see
you
tomorrow.