►
From YouTube: IETF115-INTAREA-20221109-1300
Description
INTAREA meeting session at IETF115
2022/11/09 1300
https://datatracker.ietf.org/meeting/115/proceedings/
B
So
let
me
repeat
right:
we
cannot
start
the
meeting
without
an
official
minute
taker.
You
don't
need
to
take
minutes
of
the
slides
they
are
recorded,
but
it's
more
about
taking
the
questions.
The
name
of
the
guy
asking
the
questions
and
the
answer.
A
summary
is
enough:
anyone
can
help
us.
Thank
you.
Reggie.
A
Okay,
so
with
that
I
think
we
are
one
minute
pass.
So
let's
get
started.
Welcome
everyone
to
the
interior
meeting
at
ietf,
115
Juan,
Carlos,
Zuniga
myself,.
A
So
the
usual
not
well.
This
is
an
ietf
official
meeting
and
therefore
we
abide
by
the
ietf
rules,
procedures,
processes
and
policies.
So
if
you
have,
if
you're
aware
of
any
ITF
contribution
that
is
covered
by
patents
or
patent
applications,
you
must
disclose
that
fact
or
not
participate
in
the
discussion
and
of
course,
you
acknowledge
that
all
Communications
will
read
an
audio
video
and
photographics
may
be
made
public.
A
A
A
So
please,
you
have
a
QR
code
for
you
to
to
log
in
your
presence
to
the
meeting
instead
of
the
blue
sheets,
so
make
sure
that
you
sign
into
the
session
using
this
mythical
from
the
data
tracker
and
use,
please
the
meter
code
to
join
the
queue.
That's
what
we
will
use
here
as
chairs
to
to
handle
the
the
discussion.
A
Please
keep
your
audio
and
video
off
if
you
are
using
the
outside
and
wear
masks
unless
actively
speaking
at
the
microphone
so
for
the
remote
participants,
make
sure
that
your
audio
and
video
are
off
on
unless
you
are
talking
and
well,
a
headset
is
I
think
useful.
At
this
time
we
have
a
link
to
the
agenda
me
to
go
and
other
information,
and
if
you
have
any
technical
assistance
needs.
Please
go
to
that
page.
A
So
one
last
reminder
minutes
are
taking
the
meeting
is
recorded.
Your
presence
is
locked,
so
please
do
lock
your
presence
Luigi.
Thank
you
very
much
for
accepting
and
if
anyone
can
help,
of
course,
this
is
a
collaborative
tool.
So
if
you
make
a
comment-
and
you
want
to
correct
any
any
point-
please
do
so
by
using
the
the
tool,
the
node
site
etf2
for
the
chat
room,
you
can
use
the
zulit
link.
A
So
this
is
our
agenda.
For
today
we're
going
to
start
with
the
usual
bashing
and
document
status
updates
from
the
chairs.
Then
we're
going
to
have
a
presentation
by
Don
his
link.
A
Who's
just
perfect.
Okay,
that
just
arrived
in
the
meeting
and
I'm
going
to
continue
with
a
presentation
about
some
IEEE
initiatives
related
to
Don's
draft.
A
Then
we're
gonna
have
Bob
presenting
the
Internet
Protocol
number
for
chic,
then
IP
Parcels
from
Fred
and
on
E
BPF
update
from
dates
that
were.
Are
there
any
questions
or
discussion
on
the
agenda.
A
F
G
F
Find
anything
worthy
of
comment
next
slide,
so
it's
basically
a
part
of
a
series
of
BCP
rfcs,
each
one
oscillating,
the
previous
that
have
covered
the
allocation
of
parameters
under
the
Iana
oui.
Basically,
Mac
addresses
and
things
of
that
sort,
and
it
also
touches
on
the
allocation
of
other,
typically
802
code
points
that
are
from
blocks
that
IEEE
has
allocated
to
Iana
and
mentions
a
few
other
related
pieces
of
information.
So
much
more
thorough
presentation
was
given
at
the
last
ietf
and
you
can
go
look
at
the
slides
at
that.
Url.
F
If
you
want
to
see
those-
and
it
has
been
adopted
by
the
working
group,
Next
slide
so
I
think
it's
in
good
shape
for
a
working
group.
Last
call.
There
is,
however,
a
couple
questions
related
to
the
Iana
web
pages
and
the
provisions
there
there's
currently
two
Iana
web
pages,
one
of
which
is
called
ethernet
numbers
for
numbers
assigned
under
the
Yana
oui
and
the
other
is
called
IEEE
802
numbers.
F
So
the
ethernet
number
is
one
because
Iana
controls
them
is
it
really
authoritative
and
the
IEEE
802
numbers
page
is
really
an
informational
page
which
has
stuff
that's
under
the
control
of
the
IEEE
registration
Authority.
F
So
this
draft
also
renames
the
ethernet
numbers
page
to
be
the
Yana
ethernet
number
page
to
be
more
consistent
to
make
it
clearer.
The
distinction
between
the
two
there
was
a
I
guess:
I
probably
should
have
put
the
RFC
number
on
here.
There
was
a
registry
created
for
Ayanna
link,
local
Discovery
protocol,
Tov,
subtypes
and
one
that
was
created.
F
It
was
stuck
on
the
IEEE
802
page
when
it
really
shouldn't
have
been
because
it's
not
allocated
by
the
IEEE
registration
Authority,
it's
allocated
under
the
Yana
oui
that
should
have
been
on
the
Anna
page,
so
this
RFC
7042
biss
moves
it
there
and
I've
checked
with
the
authors
of
the
RFC
and
the
and
so
on
and
so
forth.
So
if
everybody's
okay
with
that
move
next
slide,
this
is
I.
Think
the
last
slide,
the
substance
so
most
of
the
activity
on
the
IEEE
802
numbers
page.
F
That's
the
informational
one
is
relates
to
Ether
types.
Basically,
Andreas
read
the
types
there
are
updated
or
added
to
when
directed
by
the
experts
for
the
registry
and
it's
easier
to
access
information
there
and
to
update
it
than
it
is
through
the
IEEE,
authoritative
listing
also
in
that
page
is
a
short
list
of
LLC
sap
numbers,
which
is
hasn't
changed
much
and
the
third
thing,
which
will
would
still
be
there
after
this
draft.
If
its
draft
issues
is
a
list
of
OU
of
early
oui
assignments,
that's
not
really
something.
F
Most
people
find
interesting.
I
guess
it
used
to
be
useful
that
you
could
figure
out
who
had
manufactured
a
NIC
card
or
something
by
looking
at
the
MAC
address
and
looking
up
there.
That's
that's
still
true,
but
that
is
not
really
getting
updated.
So
if
people
have
an
opinion
as
to
whether
or
not
that
part
of
an
oui
assignments
should
still
be
retained
on
this
informational
Yana
web
page
I'd
be
interested
in
that.
So
there
is
some
conversation
between
the
ETF
and
the
IEEE
about
ether,
types
and
I
guess.
A
Thanks
Don
so
I'm
going
to
present
next
and
then
we'll
take
q
a
because
the
next
presentation
is
related.
A
So
hi
here
in
interior-
and
this
is
to
give
you
an
update
about
certain
discussions-
we've
been
having
between
IEEE
and
ITF
regarding
this
Registries
and
how
we
can
make
better
use
of
them.
Please
thanks
foreign.
A
So,
to
give
you
a
background,
don't
just
give
an
update
about
draft
ietf
interior
RFC
7402
bits
which
is
trying
to
update
that
document.
That
is
outdated
and
indeed
we
can
provide
better
information.
That's
a
summary.
Much
of
the
Clause
2
covers
the
IEEE
Mac
addresses
and
address
policies,
as
stated
on
the
I
truly
side,
much
of
classes.
Three
and
four
covers
the
III
protocol
identifiers,
including
ether,
type
and
policies.
A
Now,
on
the
IEEE
side,
there
are
standards,
policies
and
registration
of
these
parameters
that
are
handled
by
that
triple
E,
and
there
are
multiple
of
these
instances.
But
here
there
are
three
examples
that
will
give
you
an
idea
of
what
we're
talking
about.
So
first
we
have
the
IEEE
standards,
Association
registration,
Authority
committee
or
Iraq-
that
is
responsible
for
the
assignment
of
numbers
such
as
ether,
types
and
ouis.
A
So
this
Mac
addresses,
as
we
commonly
use
him
but
uniquely
assigned
then
the
IEEE
sa
registration,
Authority
publishes
policies
regarding
the
use
of
these
parameters
such
as
ether,
types
and
Mac
addresses,
and
we
also
have
a
standards
like
highee
802
overall,
like
the
umbrella
of
802,
11,
15
3,
and
all
that
that
is
in
this
case,
managed
by
the
IEEE
or
2.1
working
group,
which
specifies
policies
regarding
the
use
of
these
parameters
like
ether,
types
and
Mac
addresses.
A
Now
what
happens
is
that
there
are
current
developments
to
amend,
for
instance,
the
use
of
these
parameters,
in
this
case
802f
the
young
model
for
ether
types
and
in
in
fact
IEEE
standard
saver2
as
a
whole,
is
currently
on
the
rearration.
So
next
slide
please.
A
So
we
can
anticipate
the
following,
because
the
draft
here
references
and
talks
about
the
description
of
these
living
moving
Targets
in
on
the
IEEE
side.
We
can
anticipate
that
the
IEEE
registration
Authority
should
review
the
the
draft
to
ensure
that
there's
alignment
with
respect
to
the
registration
of
this
policies
and
assignments
and
also
82.1
working
group
working
on
this
specification
should
review
the
draft
to
ensure
that
there's
alignment
with
respect
to
what
they
are
planning
to
do
on
this
revisions.
A
So
what
the
discussions
we
are
having
on
the
background,
we
think
that
we
should
encourage
them
to
review
and
provide
some
answers
before
we
publish
to
ensure
there's
consistency
with
this
IEEE
communication.
A
First
point:
of
course
we
should
take
into
account
their
views
and
even
as
a
stretch
goal
there
are
some
efforts
to
harmonize
the
Registries,
because,
as
Donald
explained,
there
are
the
Registries
on
the
Israel
police
are
very
specific
to
let's
say
legal
terms
when
someone
acquires
one
of
these
numbers
and
assignments,
so
it
will
mention
who
is
the
assignee
of
a
number
that
requested
it.
But
here,
in
the
Ayana
side,
we
have
extra
information.
That
is
super
useful
for
implementers,
like
what
is
this
number
being
used
for
PPP
ether
type?
A
It
is
that
information
is
missing
on
left
hand,
side,
they
are
the
owners.
We
have
useful
information
on
the
right
hand,
side
and
we
need
to
somehow
keep
track
of
each
other
and
I've
heard
at
least
more
than
well
a
few
people
complaining
and
which
one
is
the
one.
The
official
one
which
one
should
I
refer
to
so
I
think
it's.
This
is
a
good
opportunity.
The
fact
that,
on
the
one
hand,
we
have
Donald's
draft
explaining
to
ETF
people
what
these
are
and
how
they
should
be
used.
A
On
the
other
hand,
we
have
common
discussion
or
constant
discussions
with
IEEE
about
how
they
are
going
to
evolve
these
specifications
and
why
not
I
would
say
take
advantage
of
the
fact
that
this
thing
happening
to
proper
will
probably
harmonize
the
registry
so
that
we
have
one
single
registry
most
likely
IEEE,
stating,
for
instance,
the
usage
of
these
protocols,
also
from
the
insi
and
I
think
that
is
my
last
life.
A
So
I
don't
know
if
there
are
any
questions
regarding
the
status.
Basically,
what
I'm
saying
here
is
that
Donald's
draft
right
now
should
be
from
the
if
the
IDF
site
pretty
much
ready
for
publication,
but
because
there's
all
these
things
happening
outside,
we
think
it's
worth
holding
on
a
bit
before
calling
for
publication
so
that
we
hear
from
the
IEEE
side
their
views.
F
Yeah,
it's
not
least
like
from
future
way
again.
I
just
want
to
mention.
There
is
a
joint
iet5ee
leadership,
mailing
list
that
notice
about
this
draft
has
been
posted
and
though
this
was
posted
again
when
it
was
adopted
by
the
Indiana
area,
working
group
and
so
forth,
and
along
with
the
request
that
people
in
IEEE
look
at
it
and
no
comments
have
been
received
so
far,
so
I'm
not
quite
sure
exactly
what
the
path
forward
is
I
mean.
Are
you
sure
they
should
look
at
it
and
comment
some?
F
That
would
be
useful,
but
are
we
going
to
do
a
little
formal
liaison
I
mean
there's
a
lot
of
common
members.
That
already
seems
necessary.
I,
don't
know.
A
I
would
maybe
let
I
don't
know
Paul.
Do
you
want
to
take
that.
B
H
Hi
yeah:
this
is
Paul
Congdon
to
lock
networks,
I'm,
also
a
task
group
chair
in
802.1
and
as
you
mentioned
as
as
we
are
meeting
next
week
and
my
task
group
has
specifically
been
chartered
to
do
a
review
of
the
70
70
42
bits
we'll
be
providing
a
response.
H
The
whole
point
of
the
IEEE
802
coordination
thing
is
to
often
avoid
those
official
Liaisons.
If
we
don't
need
to,
but
it
you
know,
sometimes
it's
still
very
important
to
have
them
just
from
raising
the
awareness
and
whatnot.
So
it's
likely
that
we'll
be
chartered
with
or
I'll
be
chartered
with
Drafting
and
a
liaison
that
indicates
we're
doing
this
review.
We
would
like
you
guys
to
wait
a
little
longer
for
your
last
call
until
we've
done
that,
but
understand
the
urgency
so.
E
So
this
comment
is
for
like
don,
so
so
one
of
the
things
that
happened,
probably
five
six
years
ago
on
the
iesg,
is
like
we
needed
a
ether
type
and
the
like.
7042
didn't
have
anything
I
I
looked
at
the
biz
draft
quickly
as
well
and
I.
Think,
like
some
kind
of
guidance
on
like
how
to
get
I,
know
like
it's
not
like.
E
F
This
is
Donnelly's
like
again
yeah,
so
there's
an
isg
statement
which
is
up
in
the
IHG
statements,
is
also
included
in
the
draft
I.
Don't
know
if
it's
good
or
bad
that
it's
in
two
places
and
basically
it
says
that
you
need
to
get
iesg
clearance
before
you
do
that.
Previously
any
working
group
chair
or
No
Good
Reason,
whatever
could
go
through
the
obvious
paperwork.
You
just
go
to
the
Triple
A
registration,
Authority
site,
ask
for
an
ether
type,
and
you
know.
F
Basically
you
say
it's
for
standards
use
and
you
you
check
the
I'll
pay
the
fee
by
wire.
It's
like
twenty
five
hundred
dollars,
but
in
fact,
because
the
standards
use
they
never
bill,
you
and
it
all
goes
through
for
free.
It's
very
simple.
It
used
to
be
that
way.
So
last
time
this
happened,
there
was
this
funny
stuff
where
somehow
I
mean
I
I.
F
My
thought
was
that
once
the
isg
has
approved
this,
then
this
you,
the
working
group
chair,
can
still
apply
for
it
right
I
mean
since
I'm
the
the
primary
expert
on
these
Registries
I
could
do
it
for
for
people
it
doesn't
happen
very
often,
maybe
once
or
twice
a
year
at
most
I
mean
something
like
that
so
yeah
six
years
ago
was
the
last
time
it
happened.
So,
okay.
D
F
E
Yeah,
thank
you
so
I
think,
like
so
Suresh
again
sorry
to
like
get
back
Rob
and
I
had
a
few
but
I
think
that
was
a
fine,
so,
like
I
found
this
page
by
Google
search
to
go
where
to
apply
for
the
stita
type,
even
though
I
already
got
the
ASG
approval
right,
so
I
said
hey
go
to
this
page
and
and
don't
do
the
payment
that
kind
of
thing.
So
it
said
like
it
was
1500
back
then
I
think
but
like
yeah
same
thing
right,
you
just
didn't
know
what
to
do
so.
E
G
I
As
well
as
the
A's
and
Alias,
we
have
a
meeting
with
them
once
I
really
think
it's
four
months,
it's
like
once
before
each
meeting,
if
you
were
to
email,
Russ
and
Dorothy,
and
ask
them
just
to
track
this
as
an
issue.
A
Yeah
I
think
so
indeed
it's
it's,
it's
tracked
and
and
also
Donald
mentioned,
but
I
just
want
to
stress
so
so
there's
a
2X
expert
been
referenced
in
the
Ayana
pages
and
it's
Donald
and
me.
So
if
you
want
to
to
ask
questions
and
we
should
be
able
to
help,
but
more
than
that,
the
idea
is
to
make
it
easier
in
the
future,
and
you
don't
have
to
ask
questions.
The
information
should
be
available
and
also
more
coherent,
all
right.
So
with
that.
D
J
Many
of
these
slides
are
pretty
much
what
I
had
my
last
presentation
back
in
July
with
some
slight
modification,
so
this
is
requesting
that
for
the
lp
Wan
State
stateful
context,
header
compressions
chic,
to
be
having
a
a
protocol
number
assigned,
so
we
can
do
Chic
at
the
VIP
level
instead
of
having
to
do
it
higher
next
slide,
please!
J
So
why-
and
this
is
reviewed-
the
slide
I
had
last
time.
Networks
are
complex
and
what,
if
the
constrained
link
is
within
the
link
in
in
the
path
that
the
that
is
the
endpoints
node
of
the
constraint
but
have
no
control
over
it?
J
All
IV
contact
is
within
a
non-compress
or
all
of
economies
in
a
non-compressed
security
wrapper
example,
dot,
ESP
or
dtls.
So
we
have
these
cases
we're
looking
at
and
particularly
in
in
my
area
in
aviation,
that
it
may
be
avionic
system
inside
the
plane,
which
has
no
understanding
this.
It
knows,
there's
a
constrained
link
there,
but
has
no
control
over
it.
It
just
has
an
Ethernet
connection
to
the
planes
Network
and
going
out
from
there.
J
So
how
can
the
the
the
application
inside
that
avionic
system
talking
to
some
Ground
Control
Systems,
somewhere
again
on
an
Ethernet
Network,
be
able
to
compress
so
doing
this
at
at
the
IP
network
layer?
Instead
of
what
Sheikh
has
been
doing,
others
would
be
highly
effective
in
consuming
a
very
scarce
resource
of
that
RF
link
to
the
aircraft
next
slide,
please.
J
So
if,
if
the
IPv6
next
header
were
Chic,
the
rules
can
be
compressed
for
transporting
on
up
to
the
security
envelope
so
like
in
many
cases,
UDP
will
compress
to
zero
bytes,
because
everything
you
need
for
UDP
is
really
in
TC
in
dtls,
and
if
you
only
have
the
one
application
running,
what
do
you
UDP
for
so
and,
and
so
that
helps,
and
you
can
even
indicate
what
rules
for
within
the
security
envelope,
so
you
may
say
able
to
say
like
for
what's
in
the
envelope,
here's
I'm
going
to
compress
that,
so
we
get
a
significant
gain
by
doing
this
next
slide,
we
can
effectively
it
effectively
comes
a
transport
when
Chic
becomes
the
next
header
that
effectively
becomes
transport.
J
That
then
processes,
whatever
transport,
is
within
it
and
still
transport.
The
original
transport
layer
compressed
example,
have
UDP
CRC
when
ESP
and
dtls
has
better.
They
have
Macs.
So
why,
with
the
CRC
and
provide
new,
valuable
transport
functions,
so
one
of
the
things
we're
discussing
right
now
in
the
chart
retirement
lpwan
is
to
include
FEC
directly
as
a
Chic
option.
J
So
we
can
be
doing
the
Forward
Air
correction
and
again
making
more
effective
use
of
our
of
our
scarce
on
wireless
service
or
raise
take
a
low,
reliable
spectrum
and
make
it
highly
reliable
by
by
including
FEC.
So
we
can
then
have
that
at
this
point
next
slide
and
just
a
quick
review
about
about
the
seek
payload
it
has
the
the
rule
and
whatever
compression
and
residue
for
that,
and
then
the
payload,
it's
very,
very
Squishy.
J
In
each
case,
you
have
something
different
going
on
it's
very
hard
to
Define,
it's
literally
by
case-by-case
basis
there
there's
no
protocol
numbers
we
could
use
for
this.
We
do
need
something
new
next
slide.
J
But
there's
a
question:
can
we
really
introduce
the
new
protocol
number
in
the
next
header?
Will
it
just
work
or
will
the
routers
drop
this
and
and
and
there's
our
ADC?
That's
not
a
problem,
and
what
about
IP
fragmentation
well
will
result
in
this
well
seek
has
its
own
fragmentation,
so
we
can
potentially
pre-fragment
knowing
again
what
we
may
be
up
against,
so
we
could
be
potentially
using
the
Chic
fragmentation
and
not
having
to
then
use
IP
fragmentation.
Next
oops.
J
J
There
are
secret
cases,
use
cases
where
that
that
doesn't
concern
me.
But
Pascal
has
these
cases
in
industrial
uses.
So
you
can
talk
about
General
case
for
all
of
you
answers.
Instead,
all
the
LPN
specific
cases.
We
can
talk
about,
generalizing
it
and
obvious,
and
then
you
can
do
an
IPv6
header
compression
on
some
802
media.
So
though,
the
draft
right
now
only
has
requesting
the
IB
protocol
number,
the
lpuan
community
says
while
we're
at
it.
J
While
we
got
this
Pandora's
Box
open,
maybe
we
should
request
all
three
not
just
requests
an
IP
protocol
number
but
also
request
an
ether
type
and
when
you
got
a
firewall
in
the
way
and
you
want
to
punch
a
hole
through
it,
you're
probably
also
going
to
have
to
do
Chic
even
at
the
UDP
level.
My
fault,
so
you
know
because
I'm,
the
author
of
RC,
1918
and
and
next
and
all
the
rest
of
that
that
nonsense
and
it's
kato.bv6.
J
So
right
now
the
draft
is
only
asking
for
for
the
IP
protocol
number
and
there's
been
a
general
acceptance
on
the
list
that
this
is
something
worth
worth
doing
so
there's
a
question
to
the
work
group.
Can
I
expand
this
to
also
add
in
a
quest
for
ether,
type
and
request
for
for
UDP
port
number,
or
do
you
want
that
as
a
separate
effort?
So
that's
like
an
open
question
to
the
group
of.
Do
we
just
simply
take
my
draft.
J
It
is
right
now
and
do
Last
Call
on
it,
for
the
for
the
port
number
or
you
say
yes,
Bob
go
back,
add
in
for
The,
Ether
type
and
add
in
for
the
UDP
port
and
let's
get
all
three
at
one
time.
So
that's
a
question
for
the
work
group
what
I'm
going
to
do
and
and
if
it's-
and
it
is
just
the
port
number-
please,
let's
get
last
call
and
let's
wrap
this
up.
Otherwise,
I
will
rev
the
document
in
the
next
two
weeks.
B
Yeah,
it
was
everything
Cisco
first,
without
any
hat
about
my
reaction
about
a
people
to
call
number
do
you
don't
need
router
updates
on
that
right.
We
made
some
tests
in
these
excerpts
for
extension,
headers,
which
are
much
more
complex
in
the
protocol
number.
So
specifically,
in
the
case
you
mentioned
Aviation,
the
network
will
be
there.
I
said
limited
domain,
but
at
least
under
a
single
operating
system
operator,
so
I'm
pretty
sure
that
they
make
the
device
allowing
this
API
protocol
number.
B
J
K
Babe
David
black,
responding
to
Eric's
comment
that
it's
not
interior,
so
I'm
in
the
transport
area
and
I'm
here
to
help
you
Bob
get
them
all
at
once,
and
for
for
just
just
just
for
everybody's
sanity.
That
way,
when
somebody's
trying
to
do
Chic
and
figuring
out
how
to
identify
it
and
all
the
weird
things
that
got
to
put
it
through
everything
they
need
to
do.
J
So
we
can
do
at
home
and
so
forth,
but
if,
if
the
consensus
is
that
we
got
to
pull
it
back
and
I
got
to
add
this
in
I
will
add
it
in
pull
it
back
and
bring
it
back
then,
for
work
group
adoption
on
that
I
think
I
have
one
more
side,
which
is
just
basically
wrapping
it
up.
J
J
Is
that
has
that
been
the
consensus
here
and,
of
course,
I'll
take
it
to
the
list
as
we
are
required
to
do,
but
I
would
like
to
get
the
feel
for
the
Community
here.
Bob.
A
So
sorry
we
have
two
people
before
you.
J
A
So
yeah,
no,
so
sorry
I'll
just
take
it
first,
because
I
I
have
some
something
to
say
so.
A
Perhaps
we'll
hear
more
details
about
this,
but
it
sounds
to
me
that
that
we
need
to
coordinate
this
between
interior
and
transporter,
so
so
the
calls
ideally
us
David
and
Eric
voiced
I
I
agree.
It's
it's
important.
It's
probably
easier
to
do
it
all
at
once
and
it's
clear
for
people
understanding,
but
we
do
need
to
involve
transport
to
be
before
publishing
and.
C
L
I'll
just
disagree
that
you
need
to
do
another
adoption
call
for
this.
I
mean
it's.
The
adoption
call
was
that
the
working
group
wanted
to
work
on
this
part
of
that
discussion
is
there's
two
other
things
to
add
to
the
document.
I
think
that's
fine!
It's
still
eventually
going
to
go
through
a
working
group
last
call
and
then
then
there's
the
consensus,
so
I
don't
think
we
need
to
do
another
adoption
call
to
add
these
two
things.
L
E
Just
a
quick
question
like
it's
not
for
this
group,
but
like
something
for
you
to
take
back,
did
lp1
have
some
kind
of
proof
of
concept.
Implementation
of
how
this
like
ether
type
thing,
would
work
because
I
think
there
might
be
like.
So
if,
if
I
go
back
like
what
is
the
V6
header
compression,
is
it
going
to
be
like
six
low
pan
had
a
compression
or
what
is
it
going
to
be,
or
is
it
going
to
be
Chic
all
the
way
do
you
know.
J
J
J
K
David
black
and
do
the
same
thing
for
you
to
be
UDP
Port
request
right
right,
the
paragraph
for
why
you
need
it:
fire
firewall,
firewall,
pinhole
poke.
If
there's
particularly
you've
got
to
do
you
gotta
report,
for
it
just
just
write
that
up
I
mean
my
my
gut
reaction
to
all
this
is
that
Sheik
is,
is
efficiently
interesting,
new
protocol
that
a
UDP
Port
request,
if
it
went
just
straight
straight
into
Ian
I,
would
probably
would
probably
get
Grand
anyhow
so
might
as
well.
K
J
Thank
you.
Thank
you.
I
will
do
it
and
I'll
work
with
with
my
colleagues
in
lpwan,
get
the
strap
around
and
and
and
submit
it
as
quickly
as
I
can.
So
we
can
keep
keep
moving
this
forward
and
I.
Thank
you
for
your
time
and
I
look
at
doing
some
very
interesting
things
for
wide
area
Wireless
from
from
aircraft,
both
man
and
unmanned,
being
able
to
use
this
and
be
much
more
smart
in
how
we
use
that
very
small
budgeted
networks.
Thank
you
for
your
time.
Thank
you.
Thanks.
A
Can
you
see
here
yes
now
we
can
hear
it.
Okay,.
G
G
G
G
G
G
B
If
you
wonder
why
we
still
have
this
presentation,
even
if
the
code
for
adoption
was
closed
in
the
sense
that
not
adopted,
we
gave
simply
a
last
chance
to
this
effort,
run
thread
to
get
some
energy
and
enthusiasm
on
this.
So
cool
for
adoption
is
close.
It
will
stay
close,
except
if
I
see
some
other
people
ask
oh
I've
seen
this
each
I
changed
my
mind.
B
Okay
and
I
want
to
do
it
and
close
it
end
of
this
week.
So
by
seeing
this
and
the
explanation
of
thread,
I'm
pretty
sure
that
Fred
is
still
available
online
later,
you
think
it's
fantastic
work.
I
want
to
review.
I
want
to
get
this
adopted,
do
it
until
the
end
of
this
week,
and
then
we
will
reopen
the
code
for
adoption
and
official
one
okay.
Until
now
it's
closed
you
stay
close.
B
A
M
Stepped
out
of
cheering
the
meeting
next
door
to
come
over
here
all
right,
so
the
purpose
of
this
is
to
advertise
a
side
meeting
that
is
tomorrow.
Ebpf.
If
you
don't
know,
evpf
I
will
give
you
a
quick
intro
in
about
two
minutes
and
then
we'll
talk
about
what
the
actual
purpose
of
the
side
meeting
is,
because
it's
a
really
non-technical
side
meeting,
it's
more
of
a
process
side
meeting
so
next
slide
by
the
way.
I
am
doing
this
presentation
wearing
a
couple
of
hats.
M
My
other
hat
is
within
the
evpf
foundation,
which
was
recently
created
to
sponsor
open
source
projects.
The
UDF
Foundation
has
a
technical
committee,
and
I
am
one
of
the
members
of
the
ebpf
foundation's
technical
committee.
All
right.
So,
if
you
don't
know
ebpf,
some
of
you
do,
some
of
you
may
be
may
not.
M
This
is
a
definition.
Ebpf
is
a
cross-platform
technology
that
can
run
sandbox
programs
to
extend
a
privileged
system
component.
So,
if
you
ask
me
what
does
ebpf
stand
for
the
answer?
Is
it
doesn't
stand
for
anything
BPF
stood
for
something
ebpf
does
not
next
slide,
so
the
best
analogy
that
I
could
give
and
I'm
going
to
stretch
it
just
a
little
bit
here
is
that
JavaScript
is
to
the
browser.
M
What
ebpf
is
to
an
OS
kernel,
so,
for
example,
JavaScript
isn't
just
for
browsers:
evpf
isn't
just
for
OS
kernels,
but
that's
the
dominant
case,
and
so
what
JavaScript
to
the
browser
is.
It
said
you
are
not
beholden
to,
however,
the
browser
shipped
whatever
that
functionality
was,
because
you
can
extend
it
with
things
that
you
can
download
and,
and
it
allowed
the
browser
to
be
programmable.
M
Os
kernel
is
the
same
thing:
do
I
have
to
wait
for
a
new
version
of
an
OS
kernel?
Ebpf
allows
extensibility
without
waiting
for
new
version,
just
like
JavaScript
did
for
the
browser?
Okay,
so
that's
the
rough
analogy.
Don't
want
to
carry
it
too
far,
but
that's
next
slide.
There
are
multiple
implementations.
The
most
dominant
one
by
far
is
in
the
Linux
kernel.
This
is
showing
how
components
are
organized
in
the
Linux
kernel.
Implementation,
adpf
is
also
in
say,
offload
cards.
M
If
I
want
to
extend
a
hardware
card,
then
those
that
support
ebpf,
you
can
download
a
program
into
a
card
and
run
things
there,
but
in
the
Linux
example,
the
red
lines
consider
what
is
untrusted
okay,
and
so
you
start
off
by
writing
a
program
in
your
language
of
choice.
C
rust
go
whatever.
It
gets,
compiled
into
ebpf
program,
byte
code
and
then
a
any
application
can
use
a
library
to
load
that
byte
code
into
the
privileged
context
by
sending
it
to
a
verifier
that
verifiers
a
static
verifier.
M
That
runs
a
proof
if
it
can
prove
that
that
code
is
actually
safe,
meaning
it
only
touches
safe
memory,
it
it
actually
halts,
meaning
it
doesn't
now
have
an
infinite,
Loop
or
whatever.
If
it
can
actually
prove
that,
then
it
can
continue
to
pass.
Then
it's
considered
green
at
that
point.
M
Okay,
if
it
can't
prove
if
it's
indeterminate,
it's
rejected,
okay,
and
so
once
it's
provably
safe
according
to
the
definitions
of
the
verifier,
then
it
can
be
jit
compiled
and
run
natively
and
interact
with
the
component
like
the
TCP
stack,
and
it
can
expose
shared
memory
that
things
can
interact
with,
according
to
whatever
the
actuals
are
on
that
shared
memory.
Okay,
that's
what
evpf
is
it's
a
way
of
extending
stuff
with
the
the
key
security
aspect
is
how
the
verifier
works.
Okay,
so
that's
what
ebpf
is
all
right
and
again
this
is
the
Linux
kernel.
M
Other
implementations
have
different
Assemblies
of.
Is
there
a
user
space,
a
kernel
space
or
whatever,
because
it's
extending
a
privileged
system
context?
This
is
showing
the
kernel
could
be.
A
network
card
could
be
a
user
mode
demon,
that's
privileged
whatever
it
is.
Okay,
so
next
slide.
So
I'm,
not
you
know
roughly
what
ebpf
is.
There
is
a
desire
to
standardize
some
of
those
things
as
you
get
more
cross-platform
and
implementation,
more
network
cards,
and
so
on.
M
These
are
a
number
of
areas
that
are
expected
to
be
desirable
to
standardize.
We
have
other
organizations
like
nvme
that
need
a
referenceable
spec
because
they
want
to
take
a
dependency
on
some
of
the
ebpf.
You
know
definitions
and
functionality,
and
so,
if
nvma,
nvme
and
other
sdos
want
to
point
to
us
back,
what
is
the
right
place
to
have
a
spec
to
do,
and
so
here
are
seven
different
categories
of
things
that
that
are
different
boxes
or
arrows
in
the
previous
slide.
M
That
makes
sense
to
standardize
some
cross-platform
things
for
it:
okay,
so
next
Slide,
the
purpose
of
the
side
meeting
is
to
decide
what,
if
any
of
those
things
might
be
on
scope
for
the
ietf.
Does
it
make
sense
to
actually
have
a
buff
here,
or
is
it
better
to
take
them
elsewhere?
Okay,
that's
the
purpose
of
the
side
beating,
so
we're
not
going
to
get
into
the
technical
discussion.
It's
going
to
be
about
those
seven
categories
that
says
yeah.
You
have
actually
an
appropriate
place
or
not
right.
M
It's
a
hybrid
meeting,
which
means
we'll
have
a
bunch
of
the
evpf
community.
The
Linux
kernel
people
will
be
typically
remote.
Yeah,
you
have,
people
will
be
local
and
we
can
have
the
discussion
between
communities.
There
are
a
couple
of
people
that
are
actually
in
the
overlap
I'm.
One
of
them
I
mean
couple
that
are
actually
here
all
right,
so
they
want
to
take
a
normal
dependency.
So
the
ebpf
foundation
is
an
open
source
organization,
but
it
could
publish
You,
Know,
PBS,
PDFs
or
whatever
of
specs
right.
M
Some
small
seos
publish
things
themselves
and
then
take
it
to
ISO
to
say.
Give
me
an
ISO
number,
that's
very
popular
among
the
number
of
small
sdos.
We
could
go
independent
stream
RFC
and
we
could
do
ietf
RFC,
which
some
people
have
suggested
and
that's
kind
of
the
purpose.
The
side
meeting
is
to
say,
does
d,
make
any
sense
or
is
D
not
appropriate
for
given
the
constraints
here?
M
Okay,
so
if
you
have
opinions
on
where
this
might
be
possible
to
go,
okay,
please
come
to
the
side
meeting,
even
if
you
think
that
IDF
is
not
the
right
place.
That's
the
purpose
of
why
it's
not
a
buff.
Okay,
it's
a
side
being
to
say
what
is
the
right,
sdo,
okay,
and
so,
if
you're
expecting
to
see
lots
of
technical
discussion,
that's
probably
not
going
to
be
their
side
meeting.
If
you
want
to
have
here,
ietf
is
a
good
place
to
do
it.
Ietf
is
the
wrong
place
to
do
it.
L
M
E
So
I
think
Dave
I
do
like
the
D
thing,
but
I
think
we
need
to
check
with
somebody
who
who
owns
this
I.
Don't
know
EB
pay,
Foundation
or
somebody
if
they're
willing
to
see
Change
Control
right
if
it
goes
through
an
ITF
RFC.
That's
the
only
thing
that
came
to
my
head.
M
That
exactly
that
is
exactly
one
of
the
discussions,
and
so
we
had
a
pre-meeting
with
the
area,
directors
myself
and
two
of
the
folks
from
the
evpf
community.
I
mean
people
that
actually
have
the
things,
and
that
was
actually
one
of
the
topics,
and
so
the
the
change
control
issue
is
less
of
the.
That
is
an
issue,
but
not
a
big
issue.
The
bigger
issue
is,
what
is,
how
fast
can
ebpf
evolve
and
is
ietf
process
able
to
accommodate
that,
and
so
those
are
the
types
of
questions
that
they
actually
have.
M
Much
more
than
say,
you
know,
is
exceeding
change
control,
because
the
the
risk
is,
of
course
the
ietf
might
do
something
that
I've
purchased
from
what
the
implementers
do
and
I
said.
Well,
actually,
the
IHF
coacher
is
that
iitf
tends
to
do
what
the
implementers
do
right.
M
If
you
don't
actually
have
the
implementations,
ATF
will
say
we
don't
even
want
it
here
if
we
can't
get
enough
people
from
the
community
right,
so
the
risk
of
that
is
I,
think
low,
but
I'm
personally,
not
sure
that
ietf
is
the
right
place,
but
I'm
willing
to
moderate
it
and
give
a
fair
shake.
So,
okay.
M
Is
on
the
side
meetings
page
the
itf1.
If
you
do
a
search
for
iotf,
115
side
meetings,
you'll
find
it
there
tomorrow,
mezzanine
12,
6
p.m,
and
if
it
would
help
I
can
send
a
mail
to
the
interior
list
here
and
by
the
way
I
give
exactly
the
same
presentation
in
the
art
area.
Meeting
too,
since
evpf
is
not
just
for
networking.
Okay
I
presented
an
art
area
because
there
may
be
people
from
that
community
so
anyway,
I
can
send
a
message
to
both
lists
as
a
reminder.
So
thanks.
A
So
they
say
thank
you,
and
so
thanks
everyone
with
this.
It's
the
end
of
the
meeting,
so
I
guess
we'll
give
you
back
a
few
more
minutes
to
relax
and
take
some
coffee
thanks.
Everyone
for
attending.
C
C
C
D
C
It's
your
brother
is
a
doctor
right,
so
it's
called.