►
From YouTube: IRTF Open session at IETF 106
Description
The Internet Research Task Force (IRTF) Open session at IETF 106 was held 7:50-9:50 UTC on 18 November 2019. The session included Applied Network Research Prize (ANRP) presentation by Weiteng Chen for his work on wireless network security: Weiteng Chen and Zhiyun Qian Off-path TCP exploit: how wireless routers can jeopardize your secrets, Proceedings of the USENIX Security Symposium, Baltimore, MD, USA, August 2018.
A
A
A
Also
I'd
like
to
remind
you
that
this
is
an
IRT,
F
and
internet
research
task
force
session
and
I
remind
that.
The
IRT
F
is
focused
on
longer
term
research
issues
and
will
discuss
more
of
this
later
in
this
session.
But,
unlike
the
ITF
sessions
which
are
happening
this
week,
this
is
a
research
group.
A
A
A
So
yeah
IRT
F
is
comprised
of
a
number
of
research
groups.
We
have
14
research
groups
in
the
IRT
F
of
which
13
of
them
are
meeting
this
week
that
the
den
RG
group
is
not
meeting
the
decentralized
infrastructure
group,
but
all
the
rest.
A
meeting
of
these
two
of
them,
the
computation
in
the
network
group
and
the
quantum
Internet's
group
proposed
research
groups.
A
New
groups
get
a
year
to
act
as
acts
as
if
they
are
a
research
group
and
then
we
they
go
for
a
review
and
we
we
decide
if
they
should
be
made
permanent
for
research
groups.
The
the
competition
in
the
network
group
will
be
having
that
that
that
review
this
week.
The
quantum
internet
group
will
be
doing
that
at
the
next
meeting.
All
the
rest
for
full
research
groups
and
the
majority
of
them
have
still
to
meet
so
look
out
for
them
on
the
agenda
and
please
do
consider
participating.
A
In
addition
to
the
research
groups,
we
run
to
other
activities
in
the
IRT
F.
Those
of
you
who
were
at
the
meeting
in
Montreal
earlier
in
the
year
would
have
seen
the
applied
networking
research
workshop
for
2019
running
in
parallel
with
the
meeting
in
Montreal
I'm
pleased
to
announce
that
the
2020
applied
networking
research
workshop
will
collocate
with
the
ITF
in
Madrid
next
summer.
A
That
workshop
will
be
chaired
by
Maria
and
Roland,
who
many
of
you
will
know,
look
out
for
the
call
for
papers
for
that
in
the
next
couple
of
weeks,
I
expect
with
paper
submission
deadlines
will
be
in
the
sort
of
March
April
timeframe
and
the
proceedings
will
be
published
in
the
ACM
digital
library.
This
is
all
done
in
conjunction
with
ACM
sitcom.
A
The
other
activity
we
we
have
is
the
applied
networking
research
price.
This
is
a
price
awarded
for
recent
results
in
a
play.
Networking
research
which
may
be
relevant
to
transitioning
into
internet
products,
related
standards
and
the
IRT
F,
and
the
IETF
we've
got
one
a
NRP
prize-winning
talk
which
will
be
happening
just
just
after
I
finish.
These
introductory
remarks
by
weighting,
Chang
who'd,
be
talking
about
TCP
exploits
and
how
wireless
wireless
routers
can
jeopardize
your
secrets.
A
We
also
have
the
nominations
for
the
20/20
applied
networking
research
prizes,
which
are
now
open.
If
you
go
to
the
ITF
tog
/a
NRP
website,
if
you've
read
any
good
papers
on
a
played
networking
research,
anything
which
you
think
would
be
deserving
of
a
prize
to
bring
the
off
bring
the
offer
to
the
IRT
F
and
the
ITF
for
a
week,
then
please
consider
nominating
that
work.
The
deadline
for
nominations
is
at
the
end
of
this
week,.
A
A
A
So
that's
about
all
I
have
to
say
the
agenda
for
today.
The
first
thing
we
have
up
is
waiting
with
his
AARP
prize-winning
talk.
Tcp
exploits
following
that.
We've
got
a
brief
update
on
the
computation
in
the
network
research
group
which,
as
I
say,
is
finishing
its
third
meeting
and
will
be
up
for
transitioning
from
proposed
research
group
to
full
research
group
after
this
this
week,
and
then
we've
got
some
discussion.
A
We've
got
a
little
bit
of
discussion
from
Melinda
will
be
leading
talking
about
the
relation
between
the
IRT
F
and
the
IETF
Erin
and
Lawrence
will
be
leading
some
discussion
about
moving
work
from
the
research
world
into
the
standards
world
I'll
be
finishing
up
with
some
discussion
about
how
the
IETF
can
help.
So
we
have
the
IRT.
F,
sorry
excuse
the
Tokyo.
There
can
help
academia
and
vice-versa.
B
Okay
good
afternoon,
thanks
for
the
introduction-
and
thank
you
for
coming
for
my
talk.
B
Okay
sure-
is
that
better,
so
today,
I'm
going
to
share
a
new
side
channel,
we
discovered
in
all
generations
our
various
technology
and
how
we
can
export
it
to
perform
of
past
history
injection
attacks.
This
is
basically
a
cross
layer
attack
in
which
a
design
choice.
Our
various
protocol
can
actually
compromise
the
security
and
application
layer.
B
B
Since
these
two
connections
are
on
our
control,
we
can
send
arbitrary
numbers
of
requests
to
the
target
server
so
that
the
connection
between
the
client
and
the
server
can
be
kept
alive
for
a
long
time.
As
long
as
we
keep
sending
requests
to
the
server
as
opposed
to
man
in
the
middle
attacks,
where
the
attacker
can
intercept
the
response
and
temper
the
content.
Mallory
is
completely
off
pass
and
can
no
is
job
any
of
these
traffic
mallory,
however,
consent
spoofed
packets
with
server's
IP,
address
to
pretend
to
be
the
server.
B
Because
of
the
secret
is
really
difficult
for
the
attacker
for
the
office
attacker
to
sense
both
packets
with
the
correct
secret,
if
we
just
do
random
guess,
therefore,
the
transcript
roni
on
the
kind
of
machine
is
also
for
the
purpose
of
sending
some
feedback
informing
the
attacker.
Whether
his
guessing
is
correct
or
not,
since
the
just
crib
has
no
privilege
it
can
not
appear
into
the
victim
connection
and
the
steal
the
secret.
B
Instead,
we
rely
on
such
a
node
to
infer
to
behave
yourself
how
the
client
response
to
those
spoofed
packets
and
then
based
on
the
feedbacks
the
attacker
can
guess,
multiple
rooms
and
finally
figure
out.
What's
the
correct
secret,
you
may
wonder
was
the
impact
of
this
red
model,
because,
even
though
we
can
inject
spoof
data
into
the
richting
connection,
the
whole
procedure
is
performed
on
the
malicious
website
and
the
attacker
can
already
control
the
whole
page.
Why
would
we
bother
to
do
this?
B
Well?
The
trick
here
is
that,
once
the
spoof
data
is
accepted
by
the
client,
it
will
be
cached
in
the
browser
for
long
time.
So
you
can
imagine
that
next
time,
when
the
user,
when
the
richting
tries
to
access
the
same
server,
the
browser
will
actually
reload
this
injection
page
rather
than
sending
a
new
request
to
the
server
and
even
worse.
If
the
user
does
not
clear
the
cache
manually,
it
can
be
cached
in
your
browser
for
years
here
supposed
to
be
a
video
demo,
but
unfortunately
we
can
not
do
that.
B
B
In
this
case
it's
dosia
news
web
site
and
the
other
one
connects
to
D
of
past
attacker
launching
the
real
attack
once
the
are
once
the
attacks
exceed
the
injected
page
will
be
cached
in
the
browser
and
when
the
user
tries
to
access
the
home
page
of
the
news,
he
or
she
will
actually
see
this
page
showing
up
as
we
can
see,
there
is
an
injected
login
component
at
the
top.
This
is
only
this
is
a
one
version
of
the
attack
we
performed
for
Windows.
There
is
actually
another
version
for
Mac
OS.
B
So
what's
the
secret
I'm
talking
about
in
order
to
successfully
inject
spoof
daytime
to
the
recuiting
connection,
we
need
to
know
how
to
speech
tag
validates
an
incoming
packet.
Here's
the
simplified
TCP
specification,
the
secret
I'm
talking
about
it's
actually
Street
Apple,
including
put
numbers
sequence,
number
and
old
acknowledgement
number.
So,
let's
take
a
close
look
at
a
sequence
number
check,
as
we
can
see
here
when
the
peghead
contempts,
then
out
of
windows
sequence
number,
the
client
will
actually
send
a
reasonable
eye
response
back
to
the
server.
B
In
the
other
case
where
the
sequence
number
is
in
bingo,
but
the
acknowledgement
number
is
out
homing
though
the
packet
will
be
Santa
chopped.
So
we
can
see
here
there
is.
The
client
will
actually
behave
differently
depending
on
whether
the
sequence
number
is
England
or
not.
Right.
I
actually
have
a
question
about
this
and
I
got
this
question
a
lot.
But
I
don't
have
a
perfect
answer
for
this.
So
basically
the
question
is
that
why
the
client
should
send
a
response
back
to
the
package,
even
if
the
package
contains
an
auto
Windows
sequence
number.
B
Yeah,
that's
a
question
we
can
discuss
later.
Let's
move
on
so
there
actually
are
several
tongue
side
channels
against
the
TCP
connections.
I
am
NOT
going
to
dig
into
the
details,
but
I
won't
I
just
want
to
summarize
there
first
to
say
that
such
channels
have
been
fixed
already.
The
third
one
requires
a
malware
running
on
the
kind
of
machine
to
monitor
the
system.
In
our
work
we
discovered
a
new
side
channel
that
is
inherent
in
all
generations
of
various
technology
and
the
alphas
attack.
B
We
we
present
in
our
work
only
requires
a
transcript
running
on
the
can
machine,
and
all
three
major
operating
systems
are
affected
by
the
attack.
It's
also
worth
noting
that
our
tech
is
the
only
working
one
without
any
mitigation
in
place,
and
it's
practically
infeasible
to
fix
it.
So
from
a
hell
of
a
view
of
the
side,
channel
attacks
against
TCP
connection
that
are
discovered
in
prior
work
or
often
manifests
themselves
through
the
following
control
flow
bulk.
There
are
actually
two
essential
building
blocks.
B
B
So
what's
the
shared
resource,
we
discovering
a
router
well,
the
insight
is
that
the
half
duplex
nature
of
Wireless
creates
a
shared
resource
between
uplink
and
downlink
traffic.
Half
duplex
is,
in
contrast
to
folk
duplex
photo
blocks,
means
that
both
opening
and
darling
traffic
can
transmit
at
the
same
time.
B
Well,
for
a
half-duplex
only
allows
one
direction
to
transmit
at
a
time
for
wireless
networks,
it
makes
perfect
sense
to
use
half
duplex
because
if
both
ends
try
to
just
mate
at
the
same
frequency
and
at
the
same
time,
it's
likely
to
cause
interference
back
half
and
then
retransmission
since
half
duplex
is
a
fundamental
design
choice
of
well.
This
protocol
is
really
difficult
to
change.
B
Let's
considered
following
two
scenarios
in
wellies:
let's
consider
assume
that
the
client
has
established.
Two
connections
went
to
the
Tagus
server
and
the
DIA
went
to
the
opposite
hacker.
In
this
case,
the
opposite
hacker
can
send
both
legitimate
and
spoofed
packets
to
the
client,
because,
because
we're
lease
is
half
duplex,
when
both
uplink
and
downlink
traffic
are
transmitting
at
the
same
time,
it's
likely
to
cause
interference
which
enforces
either
or
both
ends
to
back
off
and
then
retransmit
suppose
the
client
gets
the
chance
to
transmit.
B
B
Let's
consider
a
similar
scenario
compared
to
their
previous.
One
is
almost
the
same,
except
that
now
the
spoofed
packet
can
trigger
a
response
recall
that
when
the
packet
contains
an
outer
window
sequence
number,
the
current
should
send
a
resource
back
right,
but
the
issue
here
is
that
the
packet
is
sent
back
to
the
server.
So
how
did?
How
does
the
attacker
can
see?
This
can
see
the
difference
well
because
of
this
additional
response
triggered
by
the
spoof
to
package,
the
third
the
packet.
Now
the
post
pop
carry
now
experience
more
contention.
B
B
However,
you
may
wonder
that
does
the
timing
difference
resulted
from
these
additional
response
is
too
small
to
be
measurable?
Well,
that's
true,
but
what
if
we
can
amplify
the
signal?
So
in
this
figure
we
also
illustrate
the
amplified
nature
of
the
side
channel.
In
this
case,
the
attacker
can
stand
two
probing
spoof
two
packets
to
the
client
causing
more
contention
which
delays
the
third
post
pop
carry
you
have
even
further,
which
means
the
mole
probing
packets.
We
sent
the
more
contention
we
experienced
and
therefore
we
can
observe
larger
round
shaped
hands.
B
So
far
we
only
discuss
conceptually
discussed
timing
such
channel
and
its
effect
now
I
want
to
show
some
empirical
test
results
to
understand
the
real
world
implication.
We
created
a
total
of
16
different
setups
to
make
sure
that
the
timing
difference
the
time
inside
China
exists
in
various
products.
We
used
four
different
routers
noters
and
two
different
versions
of
as
the
client.
We
also
varied
the
frequency
of
each
daughter's.
B
So
follow
the
same
probing
strategy
I
mentioned
earlier.
We
measure
the
round
shape
times
of
the
post
pop
carry
with
100
runs.
We
pick
3
representative
test
results
here,
as
we
can
see,
the
timing
difference
is
clear
and
measurable,
on
average
is
about
2,
milliseconds
and
also
the
timing.
Difference
grows
as
we
increment
the
number
of
popping
packets
we
send
per
test.
B
Let's
start
with
the
pod
number
inference,
since
the
client
will
behave
differently
depending
on
whether
the
sequence
number,
whether
the
poll
number
is
correct
or
not,
the
attacker
can
actually
send
multiple
spoof
probing
packets
with
a
guest
saw
spot
number
to
the
client
and
then
determine
whether
his
guessing
is
correct
or
not.
By
simply
exploiting
the
timing.
Side,
Channel.
B
Now
that
we
know
the
PO
number,
we
can
further
infer
the
sequence
number
compared
to
this
PO
number
inference
is
a
monster
sim.
We
can
still
apply
the
guess,
then
checks
King
chewing
for
the
sequence
number.
However,
the
issue
here
is
that
it's
unclear
whether
all
the
operating
systems
will
behave
the
same
as
we
illustrated
here.
So
we
await
the
late
latest
Linux
and
Mac
OS
by
inspecting
their
kernel
source
code
and
develop
it.
It
has
a
program
to
measure
the
behaviors
of
Windows.
B
This
table
shows
the
behaviors
of
different
operating
systems
when
processing
10
identical
packets.
As
we
can
see
here,
the
3
operating
system
behaves
instantly
on
sequence
number
check,
which
means
that
we
can
always
apply
the
gas
in
checks,
King
to
infer
the
sequence.
Number
there's
one
interesting
fact
of
about
the
behaviors
of
windows
in
it.
I
didn't
show
the
show
the
numbers
in
this
table.
You
can
find
the
complete
table.
B
If
the
connection
is
idle,
then
it
only
accept
sequence
number
that
exactly
equal
to
the
next
expected
sequence
number,
and
this
behavior
is
never
I,
guess
never
specified
in
any
RFC
Stander's.
So
I
don't
know
why
windows
have
implemented
in
this
way.
So
if
anyone
from
Microsoft
knowing
the
answer
for
this-
and
we
appreciate-
answer
okay,
let's
continue
the
implementation
for
acknowledgement.
Number
check
actually
varies
significantly
from
one
device
to
another,
so
we
propose
customized
strategies
for
each
operating
system
by
exploiting
the
HTTP
specification
and
the
behaviors
of
browsers.
B
Remember
that
our
ultimate
goal
is
to
perform
of
plasticity
injection
attacks.
We
don't
actually
need
to
know
the
exact
egg
number
to
perform
the
attack.
Therefore,
we
can
just
brute
force
every
possible
act
number
and
even
though
we
can
still
exploit
the
time
inside
channel
to
infer
the
egg
number,
the
brute
forcing
strategy
is
more
efficient,
only
taking
a
couple
seconds
as
there
is
no
oh,
no
waiting
for
check,
so
we
implemented
a
complete
attack
for
each
operating
system.
That
has
results,
as
shown
in
the
up
table
regarding
the
success
rate
and
average
tank
host.
B
B
So
how
serious
is
the
Tammy
side
Channel
after
we
discovered
this
issue?
We
reached
out
to
discuss
this
vulnerability
with
HFO
yield
to
the
11
working
group,
but
unfortunately
we
all
agreed
that
this
is
almost
impossible
to
be
fixed
at
physical
and
Mac
layers.
That
being
said,
we
still
need
to
discuss
some
possible
defenses
and
mitigations.
B
B
Since
our
check
also
exploited
TCP
specification,
making
TCP
stack
behave
consistently,
regardless
of
the
sequence
and
acknowledgement
number
would
be.
A
good
defense
when
possible
strategy
to
consider
is
to
really
meet
responses
for
incoming
packets
with
out
of
windows.
Sequence
number,
so
that
the
attacker
can
no
longer
amplify
the
signal
by
simply
sending
multiple
spoofed
probing
packets.
B
Well,
representative
example
is:
does
the
a
news
website
I
showed
earlier
in
the
demo?
You
can
see
that
CN
news
website
does
use
HTTPS,
but
we
can
still
make
the
attack
succeed
right.
The
theme
here
is
that
when
the
user
tries
to
access
the
homepage
of
CN
news
website,
the
initial
request
was
submitted
over
HTTP
and
then,
if
the
server
that
subsequently
redirect
the
browser
to
its
HTTP
set.
Therefore,
the
attacker
can
simply
inject
a
spoofed
page
inject,
a
fake
page
for
the
initial
request.
B
We
also
showed
that
the
time
inside
China
affects
Windows,
Mac,
OS
and
Linux
by
studying
their
TCP
stack
implementation
and
conducting
your
own
world
attacks
against
them.
We
also
stressed
some
possible
differences
to
alleviate
this
issue.
The
source
code
of
the
attack
is
publicly
available
online.
So,
if
you're
interested,
you
should
check
it
out.
A
C
Daniel
con
Gilmore
from
the
ACLU.
Thank
you
for
this
work.
This
is
really
great
stuff
and
it's
a
good
reminder
to
all
of
us
that
timing
side
channels
can
be
stepping
stones
towards
towards
other
problems.
So
I
really
appreciate
the
way
that
you've
connected
all
the
dots
here
and
showing
that
this
can
be
done.
I
was
curious
about
your
proposed
mitigations.
C
Whether
you've
had
a
chance
to
test
any
of
them
in
the
same
environments
that
you
tested
the
exploit
itself,
so
in
particular,
I'm
thinking
about
the
mitigations
that
can
be
done
at
the
TCP
layer
itself
right,
the
the
middle
mitigation
that
you
described
there.
If
you
had
a
chance
to
test
like
modifying
the
kernel
or
something
like
that
to
see
whether
it
would
affect
the
results
that
you
that
you
got
for
the
other
attack,
yeah.
B
So
if
you
look
at
the
source
code
for
linux
kernel,
it
actually
have
implemented
some
mechanism,
that
is
to
really
make
responses
for
incoming
packets,
but
we
found
that
it's
actually
only
really
made
for
for
the
income
tax
that
has
no
payload,
so
I'm,
not
sure
why
they
doing
this.
But
so
you
can
see
that
you
can
actually
bypass
this
check.
You
just
need
to
add
one
bad
payload
to
the
packet
and
then
it
can.
It
doesn't
check
the
limit
for
the
responses.
So
that's
another
questions.
B
B
D
E
D
A
very
old
protocol,
but
I
think
those
would
be
very
good
discussions
to
have
in
a
TCP
working
group
as
well
as
the
minute
you've
talked
about
and
and
also
check
on
whether
the
new
transport
protocols
are,
you
know,
making
some
of
the
I
think
there
might
be
less
mistake
being
made
now,
but
I
had
a
quick
question
about
your
evaluation.
Where
you
talked
about
the
average
time,
cost
was
slide
30.
If
I
was
wondering
what
that
meant.
What
does
average
time
cost
mean?
B
That's
actually
is
feasible
if
you
I'm
sorry
so
I
talked
about
this
earlier,
so
these
two
connections
are
created
by
the
transcript,
which
is
on
the
over
control
right.
So
we
can
send
up
three
numbers
of
requests
to
the
server
so
that
the
connection
between
the
client
and
the
server
will
be
kept
alive
for
long
time.
As
long
as
you
keep
sending
requests,
then
the
the
connection
will
be
alive.
D
B
A
B
As
I
mentioned
earlier,
this
is
a
fundamental
design
choice
of
various
protocols,
so
it's
and-
and
it
it
of
course
makes
perfect
sense
to
use
half
duplex
is
there's
nothing
wrong
with
half
duplex
interval.
This
has
to
deal
with
it,
so
so
that
so
we
so
we
discussed
this
issue
with
our
table.
You
know
to
the
working
group
and
yeah
they,
although
they
acknowledge
this
ball
bility,
but
we
can
do
nothing.
Toyatte
do.
A
A
B
B
F
B
That's
a
typical
mitigation,
but
yours
you
need
to
think
about
the
implication,
because
the
delay
can
cause
I.
Guess
if
you
want.
If
it
will
slow
down
the
hoc
network,
then
it
will
be
a
another
problem
right,
so
I'm,
not
sure
yeah,
of
course,
that
you
can
delay.
You
can
add
more
randomization
here
there,
but
I'm
not
sure
how
we
can
implement
it
without
minimal
cost.
B
A
G
Good
afternoon
everyone
I'm
Murray
I'm,
presenting
in
the
name
of
our
tree
co-chairs
Jeffery,
even
I,
andwe're
coin
computing
in
a
network
and
before
I
start
for
the
IAB
people
who
heard
us
this
morning.
This
is
going
to
be
old
stuff,
but
at
the
same
time,
I
would
like
to
thank
you
for
your
comments
this
morning
and
to
have
actually
highlighted
new
things
that
we
should
do
in
our
group.
G
G
We
want
to
improve
the
performance
for
the
network's
themselves
and
for
the
application,
especially
the
emerging
applications
in
machine
learning,
in
industrial
networks
and
in
autonomous
systems
where
our
focus
is
architectures,
I'm,
actually
an
architect
so
I'm
interested
in
that
protocols.
We
have
a
lot
of
people
in
our
group
who,
like
developing
protocols
and
also
because
we
also
have
the
link
to
industrial
R&D
in
the
group.
A
lot
of
people
are
looking
at
real
world
use
cases,
applications
and
a
lot
of
work
in
progress.
We
are
a
research
group.
G
We
are
not
producing
products,
we're
not
even
looking
at
doing
products
but
we're
looking
at
new
ways
of
using
products,
new
ways
of
doing
research
with
them
and
even
fundamental
ways
of
changing.
Maybe
the
way
that
we
look
at
how,
when
we
move
information
from
place
to
another,
what
can
we
do
to
that
info
to
make
the
whole
thing
work
better?.
G
So
how
did
we
get
there?
There
was
some
active
networking
in
the
90s
which
was
more
or
less
successful,
but
got
people
thinking
that
when
packets
go
through
the
network,
maybe
there's
some
functions
that
can
actually
carry
that
go
with
them.
There
was
work,
I
would
say
in
the
past,
maybe
five
years
in
data
centers
and
especially
orchestration
of
data
center
elements
with
the
famous
paxos
protocol
and
I
have
to
keep
this
an
impression.
It's
hitting
me.
G
There
was
a
development
by
barefoot
networks,
amongst
others
of
the
Tofino
switches
and
who
are
programmable
with
the
p4
language.
Barefoot
was
purchased
by
Intel,
which
gave
you
know
the
whole
thing
a
new
way,
maybe
of
looking
at
this
computer
architecture
edge
computing
for
a
lot
of
us
was
or
made
mainly
art
or
careers,
had
a
lot
of
heritage
from
what
people
did
in
information.
Centric
networking
name
function,
networking
distributed
network
there's.
G
Actually
another
group,
a
research
group
and
distributed
networking
that
we
plan
really
to
collaborate
with
a
lot
of
our
collaborators,
are
working
and
worked
on
something.
That's
called
compute
first
networking
which
actually
had
two
very
successful
workshop.
Even
before
that,
we
were
even
thought
about
as
a
potential
research
group,
I
talked
about
the
embedded,
AI
and
ml
and
also,
if
you
think
about
it,
up
to
now,
a
lot
of
people
were
thinking
of
applications.
G
There
were
edge
applications,
they
were
cloud
applications,
maybe
more
and
more
just
cloud
and
there's
a
lot
of
applications
that
are
poorly
served.
If
you
only
do
cloud
in
terms
of
delays
in
terms
of
intermittent
connectivity
and
a
lot
of
things
that
maybe
you
want
to
do
in
between
the
two
edges,
so
our
history,
we
first
met
in
in
Montreal
close
now
18
months
ago.
It's
not
infocom,
it's
a
calm.
G
We
had
a
lot
of
meetings
there.
We
met
people
at
USENIX.
This
year
we
met
in
Bangkok,
we
met
in
Prague,
we
met
in
Montreal
during
the
summer
we're
meeting
here
we
had
two
web-based
interims
and
we
had
to
occur
tones
on
p4
and
data
filtering
in
Montreal
and
actually
over
that
weekend,
we're
meeting
this
week
on
Friday.
So
please
come
we're
very
lucky
that
we
have
a
bunch
of
collaborators
around
the
world.
G
So
our
this
is
a
work
matrix.
This
ID
that
there's
the
cloud
there's
the
address
everything
in
between
and
how
can
we
distribute
the
computation
inside
the
network
to
essentially
make
things
better
and
make
things
better?
It's
not
a
single
thing
and
it's
not
a
single
set
of
requirements,
and
it's
not
a
single
set
of
performance
indicators.
It
actually
depends
on
what
the
application
and
what
the
service
needs.
G
I
don't
have
a
lot
of
time.
So
I'm
gonna
go
fast
over
this,
but
this
is
all
part
of
the
discussions
that
we've
been
having
for
the
past
year.
Where
do
we
want
to
put
these
things?
Obviously,
not
all
boxes
will
perform
network
related
functions.
There
was
actually
a
comment
this
morning
about
the
fact
that
there's
encrypted
transports-
and
some
of
these
things
will
not
be
compatible.
G
What
does
it
mean
to
do
packet
processing?
To
which
level
do
we
want
to
act
on
the
packets?
Do
we
just
want
to
filter
them,
so
we
can
do
something
once
the
information,
the
filter,
with
the
residual
error
which
actually
or
the
residual
packets,
which
would
be
something
that
is
very
much
related
to
AI.
G
Maybe
we
just
don't
want
just
to
do
compute,
but
also
storage.
I
said:
if
we
do
packet
filtering,
we
may
want
to
store
these
things.
Where
do
we
want
to
store
these
things?
How
do
we
deal
with
discovering
where
they
could
be
stored?
How
do
we
deal
with
the
security
of
that
data,
the
privacy?
So
it's
all
part
of
that.
G
Obviously,
if
I'm
a
developer,
I
don't
want
to
specify
where
my
computing
is,
but
I
may
want
to
know
how
there's
a
discovery
mechanism
to
allow
me
to
find
where
this
computing
and
this
caching,
if
necessary,
will
be
done
in
the
best
way
and
obviously
more
and
more
in
big
data
applications.
There's
an
awful
lot
of
data
at
the
edge,
and
we
may
want
to
do
some
computing
to
reduce
this
information
and
manage
this
data.
Implosion.
I
come
from
Canada
in
the
northern
regions
of
Canada.
There
is
not.
G
We
had
comments
from
the
beginning,
and
people
who
are
here
will
recognize
themselves
we're
saying
well:
are
there
any
common
principles
or
their
common
abstractions
or
their
ways
that
we
could
do
that
in
common,
or
this
will
be
completely
a
dislocated
type
of
set
of
things
that
really
don't
work
together?
I
think
we
find
this
may
not
be
completely
true,
but
there
are
common
things:
we're
thinking
of
common
data
layers
right
now
and
at
least
common
computing
architectures.
G
We
want
to
know
what
are
the
best
practices
we
want
again
to
look
at
if
there
are
non
forwarding
functions.
Obviously,
not
all
nodes
or
forwarding
and
not
nodes,
all
nodes
will
be
computing
and
actually,
what
are
the
incentives
to
add
this
stuff
in
the
network
so
that
new
services
and
implementers
know
that
it
exists.
G
So,
what's
the
commonality
I
said
we
looked
at
it,
so
we
want
to
select
a
programming
paradigm.
We
want
to
marshal
the
resources.
Obviously,
we'll
need
to
meet
requirements.
Constraint
and
policies
have
been
working
a
lot
in
IOT
and
sensor
networks
recently
and
there's
a
lot
of
constraints
there.
We
want
to
be
adapt
to
changing
condition,
leverage
telemetry
and
again.
This
was
very
much
highlighted
this
morning.
These
ideas
of
the
security,
the
privacy
and
the
trust
guarantees.
G
We
have
to
be
able
to
trust
the
elements
that
do
the
computing
we've
been
very
lucky,
we've
been
there
for
one
year
and
we
have
tons
of
people
who
contributed
rafts
to
the
group
and
it
covers.
If
you
look
at
this,
accept
security,
which
somebody
again
highlighted
this
morning.
All
these
drafts
cover
a
lot
of
what
we're
interested
in
augmented
reality.
Data
discovery,
managed
networks,
app,
centers,
industrial
use
cases,
which
is
also
one
of
my
big
thing
requirements,
which
is
interests
and
the
transport
issues.
G
How
are
things
when
you
look
at
end
to
end
with
encryption
or
even
end-to-end
principles,
and
you
want
to
start
thinking
computing
element
in
between?
How
do
you
deal
with
that
and
that's
actually
a
big
question
that
we
have
so
this
is
I
would
like
you
to
join
us.
A
Friday
and
I
think
we're
all
very
passionate
about
this.
We
think
there's
really
cool
stuff
that
we
can
do
and
we
hope
you
can
join
us
in
our
sandbox.
Thank
you
very
much.
G
A
All
right,
so
what
we'd
like
to
do
for
the
rest
of
this
meeting
is
spend
a
little
bit
of
time.
Thinking
about
the
relationship
between
the
IRT
F
and
the
IETF,
and
discussing
some
of
the
the
ways
in
which
the
two
organizations
can
interact
and
move
work
between
the
two
organizations
and
so
on.
I
think
we
have
a
Melinda
first
about
the
relationship
between
the
two
I.
Don't
have
any
slides.
Is
that
right.
A
H
And
actually
the
more
I
thought
about
this.
Recently,
the
the
softer
my
opinions
became
or
squishier.
They
became
right,
so
no
slides
and
I
apologize
for
that,
but
only
a
little
bit
yeah.
So
last
August
there
was
a
workshop
on
advanced
cryptography
standardization
and
we
had
lobby
I,
don't
know
if
he's
here
or
not
gave
a
talk
need
to
stand
closer.
Okay,
we
have
lobby
gave
a
very
good
talk
on
work
being
done
in
the
CFR,
G
and
yeah.
H
It
was
definitely
worth
listening
to
if
you're
curious
about
how
to
how
to
write
crypto
algorithm
specifications,
but
anyway
he
was,
he
was
sort
of.
He
was
sort
of
confused
about
what
the
see
if
RG
does
in
relationship
to
standards
and
what
the
RTF
does
and
us
understands
and
he's
someone
who
was
active
at
it.
H
So
when
thinking
about
it,
you
know,
I
think
that
the
way
I
RTF
research
groups
are
increasingly
functioning
is
blurring
the
lines
between
the
IRT
F
in
the
IETF.
They
the
way
that
meetings
happen
and
the
way
the
documents
are
handled
are
signaling
that
what's
going
on
in
IRT
F
research
groups
is
actually
standard
related
and
that
it
is
IETF
related.
H
H
So
basically
you
know
I.
The
question
is,
as
this
increasingly
happens,
we
I
you
know
my
feeling
is
that
we
need
sort
of
need
to
accept
things
as
they
happen,
but
I
also
think
that
we
need
to
be
careful
to
preserve
what
we
care
about
in
the
IR,
keya,
the
research
orientation
and
and
and
continue
our
focus
on
producing
sort,
ideas
and
enlightenment
rather
than
specifications
and
engineering.
This
is
showing
up
in
research
group
proposed
charters
as
well
in
particular,
and
this
is
an
area
that
I
think
could
use
a
lot
more
focus.
H
H
A
I
I
I
I
K
L
Brian
Trammell
I
was
looking
at
the
list
of
for
the
big
all
of
the
research
groups
we
have
known,
and
it's
cool
that
we're
almost
all
meeting
and
I
think
dinner.
D
was
also
scheduled
and
then
ended
up
getting
be
scheduled.
So
we
almost
had
all
of
the
meeting
here
and
one
of
the
things
that
struck
me
about
the
Scopes
of
those.
Is
that
they're?
L
They
don't
really
overlap,
but
there
are
a
lot
of
places
where
you
know
there's
kind
of
grey
areas,
maybe
between
coin
and
some
of
the
stuff
that
might
come
out
of
pan
RG
eventually
and
between
coin
and
energy-
and
you
know
all
of
these
in
T
to
T
and
part
of
like
they're,
all
kind
of
looking
at
the
same
sort
of
problem
space,
which
is
what's
next
for
the
internet,
with
an
internet
focus
but
from
different
perspectives.
That
would
not
work
at
all.
L
In
the
IETF
like
having
two
working
groups
working
on
exactly
the
same
thing
is
an
excellent
way
to
annoy
the
IES
g.v
I
hear
a
couple
of
XE
area
directors
laughing
the
the
idea
of
the
IRT
F
is
sort
of
a
lab
for
the
IETF
I
think
you
actually
do
see
it
in
the
set
of
research
groups
that
we
have
right
now,
I,
really
like
Derk
suggestion
very
like
so
it
actually
was
I'm
really
jet,
like
one
of
the
two
of
you
just
said
this
about,
like
hey
we
have
to.
L
We
have
to
be
a
little
bit
bolder
about
allowing
things
to
fail
right
like
so
or
like.
You
know,
let's
spin
it
up
and
let's
have
a
look
at
it
and
the
the
idea
that
the
success
is
something's
going
to
come
out
of
this.
It's
gonna
go
into
standardisation,
shouldn't
be
the
goal,
and
maybe
I'm
just
saying
that,
because
I'm
a
co-chair
of
panner
G,
which
has
like
a
very
very,
very
long
time,
scale
for
anything
that
might
ever
I'm
out
of
that
and
be
standards
right.
L
So
yeah
I
think
the
the
let's
keep
throwing
things
at
the
wall
and
see
what
sticks
model
works
pretty
well,
I
think
we've
done
a
pretty
good
job
of
avoiding
an
anti-pattern
that
that
may
have
showed
up
at
the
past.
That
was,
you
know
the
an
a
research
group
as
your
consolation
prize
for
a
failed
ball,
I
think
continuing
to
push
back
on
that
ante
pattern
as
a
good
and
I
also
say
that
as
a
co-chair
of
energy,
the
the
I
think
pushing
back
on
my
ninety
pattern
is
a
good
many
continue
doing
so.
M
Launched
a
value
I
think
this
is
a
very
important
question
to
for
the
I
re,
f
and
I
each
you
have
to
discuss.
Maybe
we
can
also
consider
not
necessarily
already
two
stage
where
there
is
a
research
group
being
proposed,
but
more.
There
is
a
research
question
or
a
research
topic
and
how
and
where
it
could
be
addressed.
I
mean
maybe
I
rgf,
an
IETF
of
some
ways
of
seeing
the
world
or
approach
problems,
but
they
may
be
also
wider
scope
if
we
think
itu-t
HC,
other
groups
or
even
I
mean
other
organization.
M
Not
the
silly
standards
related
may
also
be
other
opportunities
to
the
stage
of
the
lifecycle
of
a
research
idea
or
research
report,
or
you
can
go
to
four
different
groups
and
be
marshal
at
some
stage
and
then
may
be
brought
up
to
the
IHF
and
maybe
go
somewhere
else.
So
I
will
consider
very
important,
ISAF
IETF,
but
maybe
also
try
to
widen
a
bit
of
scope
because
there
may
be
other
groups
or
stakeholders.
I
could
have
good
views
or
good
competency
in
progressing
a
research
idea
in
the
whole
ecosystem.
A
Yeah
I
mean
certainly
a
lot
of
the
research
groups
have
historically
had
pretty
close
links
to
academic
conferences
in
the
area.
I
guess
the
network
management
group
would
be
one
of
them,
but
it's
certainly
not
the
only
one.
The
the
quantum
internet
group
I
think,
has
recently
closed
interactions
with
some
other
conferences
in
that
space
too.
N
Hi
Steven
Farrell,
so
I
think
one
of
the
does
I
think
there's
lots
of
good
aspects
of
the
IOT
I've
been
close
to
the
IETF.
One
of
the
less
good
aspects,
I
think,
is
that
research
group
chairs
find
it
hard
to
deal
with
a
lack
of
consensus
in
the
IETF
we're
looking
for
rough
consensus,
I.
Don't
that
doesn't
need
to
be
the
case
in
research
groups,
but
I
think
more
and
more.
N
It
seems
like
there's
a
tendency
to
try
and
you
know,
reach
the
same
bar
of
rough
consensus,
whereas
I
think
research
groups
would
sometimes
be
better
publishing
something
that's
whether
it's
a
draft
or
an
RC.
It
means
this.
Is
this
person's
opinion?
Lots
of
people
don't
agree
with
it,
but
it's
still
an
opinion.
I
think
it
would
be
good
if
research
groups
are
more
encouraged
to
allow
that
kind
of
lack
of
consensus.
N
A
I
think
that's
a
very
good
point.
You
do
not
need
research
group
consensus
to
publish
an
RFC.
You
need
to
have
an
interesting
document
which
the
group
thinks
is
worth
publishing
and
the
the
IRS
G
agrees,
and
as
long
as
it's
clear
that
this
is
an
opinion
piece
rather
than
a
consensus
piece.
That's
just
fine.
P
P
P
But
our
goal
in
ICC
RG
is
to
publish
documents
that
are
interesting.
That
might
be
relevant
and
it's
not
so
much
to
try
and
come
up
with
one
right
answer
for
various
things.
So
I
I
want
to
just
take
a
moment
to
say
that
it's
very
useful
I
think
for
the
IRT
F
to
be
associated
with
the
IETF,
because
it
gives
relevance.
It
gives
a
space
where
we
can
understand
problems
from
a
practical
point
of
view
from
what
matters
to
the
standards
point
of
view.
P
At
the
same
time,
I
think
it's
also
useful
for
the
IRT
have
to
be
slightly
independent
of
the
IDF
and
to
think
of
itself
as
independent
from
the
ITF.
It
doesn't
need
to
be
driven
by
ITF.
It
doesn't
need
to
be
driven
by
things
that
will
go
back
into
the
IETF
or
problems
that
are
necessarily
coming
out
of
the
IDF.
So
it
is
an
interesting
space
and
in
that
I
will
just
say
one
last
thing,
which
is
it
provides
a
venue.
It's
not
just
the
work,
that's
happening
in
the
research
groups.
P
I
see
increasingly
I
see
crg
as
a
venue
as
a
community
where
we
are
able
to
bring
people
in
from
from
academia
from
the
industry
from
standards
areas.
I
have
people
who
come
only
for
IC
crg
from
the
industry,
and
they
also
happen
to
be
in
the
IETF.
But
that's
that's.
What
I
want
to
foster
I
want
to
have
that
community
be
built
and
the
community
to
be
available
so
that
when
we
actually
have
problems
in
the
IETF
that
needs
this
community,
we
have
the
community
available
on
hand
I.
H
You
know:
we've
talked
about
the
IRT
F,
not
being
a
forum
for
advanced
engineering
within
the
IETF
context,
but
there
does
seem
to
be
demand
for
that
activity
to
take
place
somewhere.
That
IETF
working
groups
are
very,
very
narrowly
scoped.
They
have
very
specific
deliverables,
but
often
people
people
want
to
talk
about
engineering
problems
more
broadly
and
because
there
is
not
any
place
for
that
within
the
IETF.
I
think
that
tends
to
push
that
into
the
IRC
up
a
bit,
and
it's
really
not
within
the
irt
of
purview
to
deal
with
that.
A
K
Language
I
wanted
to
say
the
same
thing
and
we
can
take
an
example
of
the
network
management
research
group
and
the
net
mod
Netcom.
You
know
where
one
is
very
detailed
in
there
down
to
the
bits
and
pieces
and
the
other
one
is
very
blue
sky
and
sometimes
challenging
some
of
the
thinking
about
in
a
new
framework,
new
architecture.
How
to
do
things
that
are
being
done
in
the
ITF.
K
A
Q
This
is
Eve
Schuler
from
Intel,
so
I
like
this
discussion,
a
lot
so
thank
you
for
bringing
it
up
I.
It
points
out
to
me
at
least
that
in
some
ways
this
discussion
around
relationships
with
the
ITF,
is
around.
What's
our
metric
for
success
in
the
IRT
F,
and
maybe
one
of
the
predominant
ones
is,
you
know
in
forming
the
IETF
but
I?
It
also
raises
the
question,
or
you
know
what
are
these
other
ones
and
some
of
the
relationships
that
are
spawning
now
among
some
of
these
other
groups?
Q
A
Is
that
it's
there
to
understand
the
problem?
Space
is
learnt
there
to
have
to
explore
some
ideas,
produce
some
new
knowledge,
and
occasionally
that
is
that
leads
to
that
leads
the
group
to
a
place
where
another
effort
can
be
spun
up
in
the
IETF
to
then
standardize
something
based
on
that
outcome.
But
that's
that's
not
necessarily
the
metric
for
success,
although
it's
a
a
metric
for
success
and
yeah,
just
just
understanding
a
problem
better
producing
a
bunch
of
papers
producing
a
bunch
of
PhDs,
it's
a
perfectly
reasonable
successful
outcome
for
a
research
group.
A
So
I
think
the
points
I
I
would
like
to
highlight.
Don't,
as
a
research
group,
don't
feel
that
you
have
to
follow
the
ITF
process,
don't
feel
you
have
to
have
consensus,
it's
often
convenient
to
meet
here
and
there's
good
reasons
to
meet
co-located
with
the
IETF,
because
it
gives
nice
discussions
and
interactions
with
the
standards
community
and
with
the
people
building
products,
but
meeting
other
places
you
meet
with
conferences
me
to
have
workshops,
do
whatever
helps
advance.
A
Your
research
I'm
sure
Allison
will
remember
that
some
years
ago
seem
to
remember
the
reliable
multicast
group
meeting
on
the
beach
Inc
and
next
to
the
sitcom
conference.
So
we
can
meet
it,
we
can
meet
in
all
sorts
of
places.
It
doesn't
just
have
to
be
in
a
windowless
meeting
room
next
to
an
ITF
meeting.
J
Mark
I
think
actually
that's
very
interesting
remark,
because
this
also
promotes
the
IETF
in
those
other
places.
So
we
talked
a
lot
about
how
the
IR
gf
maybe
can
contribute
to
the
IETF.
But
let's
not
forget
that
there's
also
another
way
around,
so
that
there's
that
that
this
is
an
opportunity
to
maybe
get
new
people
interested
in
what
we
are
doing
within
the
ITF
as
well.
So
thank
you
for
the
you
remark.
Yes,.
K
E
Ansem,
okay,
hi
I'm,
Aaron,
Falk,
whoops,
slides
going
I
can't
talk
without
the
notes,
so
before
Collin
was
I,
RTF
chair
and
before
Allison
was
I
RTF
cheering
before
Lars
was
I
RTF
chair
for
about
six
years,
I
was
AI.
Rtf,
chair
and
Colin
asked
me
to
and
Laurent
to
work
together
to
prompt
some
discussion
on
examples
of
IRT
F,
ITF
collaboration,
and
so
this
is
mostly
one
person's
opinion.
E
Maybe
folks
will
disagree
with
some
of
these,
but
I
think
there's
a
lot
of
different
models
that
are
represented
on
this
slide
of
things
that
I
think
work
well
and
some
things
I
think,
are
anti
patterns
and
some
which
might
or
might
not
be
good
patterns.
Some
of
you
know
probably
more
some
cases,
I'm
unsure
in
some
cases,
I
just
don't
know
enough,
but
so
let
me
just
walk
through
a
few
of
these
and
maybe
folks
can
add
to
them
or
come
up
with
some
other
examples.
E
I
think
that
the
more
that
we
can
share
best
practices
of
how
I
RT
F
ITF
collaboration
works.
Well,
the
better
it's
going
to
be,
and
you'll
notice
and
the
arrows
don't
always
point
in
one
direction,
so
I
think
a
good
recent
example
is
the
ICC
NRG,
the
congestion
control
I
think
I
have
an
extra
later
yeah
the
congestion
control
research
group.
I
got
it
wrong,
but
the
congestion
control
research
group
has
performed
a
valuable
role
in
vetting
congestion
control
proposals.
E
Then
I,
guess
it's
more
down
there
now,
but
also
that
there
wasn't
really
the
there's
a
lot
of
questions
in
terms
of
how
things
are
going
to
work
in
the
real
world
before
you
start
to
take
a
position
as
to
whether
it's
something
that
you
want
to
roll
that
into
the
internet
and
so
that
this
research
group
was
created
and
one
of
the
valuable
functions
that
they
did
was
to
bring
together.
Researchers
who
are
familiar
with
congestion,
control
and
research.
E
E
This
was
a
fairly
large
research
project,
multi-institution
research
project
who
wanted
to
see
the
protocols
become
standardized,
but
there
are
a
bunch
of
open
issues,
and
so
a
research
group
was
created
to
to
come
up
with
a
good
kind
of
sort
through
what
the
research
community
had
done
and
implemented,
and
and
out
of
that
came,
some
proposals
for
standardization
and
working
a
working
group
was
spun
up
to
standardize
that
so
that
was
I.
Guess
that's
a
little
bit
more
of
a
one-way
or
I
guess
maybe
Stephen
was
there.
E
E
This
was
the
proposals
through
there
became
part
of
the
anima
working
group
and
the
IETF
see
if
RG
I
think
we've
already
talked
about
a
little
bit
that
it
prefers
to
gather
a
bunch
of
folks
from
the
crypto
community,
who
aren't
naturally
participants
in
the
ITF
process,
who
evaluate
cryptographic,
proposals
and
make
some
recommendations
that
the
ITF
can
then
use
to
to
evaluate
protocols.
And
so
the
I
guess
the
way
that
I
understand
the
security
area
works.
E
Is
they
there's
sort
of
a
deference
to
the
CFR
g2
to
give
like
a
thumbs
up
or
thumbs
down
on
crypto
proposals?
And
so
that's
that's
sort
of
a
you
bringing
in
in
an
area
of
expertise
that
isn't
really
president
the
ITF.
But
the
ITF
relies
on
quality
in
that
area,
and
so
that's
a
sort
of
a
a
little
bit
like
the
the
congestion
control
idea.
A.
A
E
I
think
it's
a
it's
a,
maybe
a
little
more
nuanced
than
that
that
in
some
cases,
if
they're
coming
up
with
ideas,
I
think
in
this
case
like
see,
if
Archie,
is
there
evaluating
proposals
that
come
from
outside.
So
if
you
so
there's
a
vetting
process
that
requires
expertise
that
isn't
present
in
the
IETF
yeah.
A
E
Reliable
multicast
is
a
fairly
old
or
long-lived
activity
in
the
ITF
and
I.
Think
that's
a
that's
an
example
of
research
that
turned
into
some
standardization
didn't
solve
all
the
problems,
but
there's
some
protocol
work
that
came
out
of
it
there.
The
peer
to
peer
research
group
was
kind
of
had
a
whole
burst
of
energy.
I
think
that
came
out
of
some
issues
in
industry
and
then
the
research
group
was
trying
to
come
up
with
metrics
for
evaluating
aspects
of
peer-to-peer
protocols
and
then
the
alto
working
group
came
out
of
that.
E
So
these
are
I
think
these
are
different
kinds
of
success.
Some,
let
me
go
to
the
anti-patterns
and
then
I'll
come
back
to
the
uncertain
ones,
and
maybe
that
that'll
be
the
start
of
some
discussions.
So
the
nameservers
research
group
was
kind
of
winding
down
when
I
came
into
the
IRT
F,
but
for
a
long
time
I
had
heard
like
that.
E
You
know,
that's
like
we've
said
in
the
last
session:
that's
not
always
the
objective
of
a
research
group
but
I
think
and
I
think
there.
There
was
a
bunch
of
proposals
that
went
into
the
ITF
and
then
we
redirected
into
this
research
group
and
then
nothing
came
back
so
I
think
that
that
probably
was
a
little
bit
of
a
swing
and
a
miss
for
the
organization.
E
E
E
If
we
think
that
they're
focused
and
they're
gonna,
you
know,
have
narrow
goals
and
accomplish
those
goals
in
a
in
a
reasonable
amount
of
time,
and
so
then
they
became
a
research
group
and
I
think
that
it
there's
been
some
people
implementation,
but
I,
don't
think
it
had
the
deployment
that
they
had
hoped
for.
Do
you
want
to
comment
now
Allison
or
we
yeah.
D
E
So
my
feeling
is
that
this
is
a
that
this
characterization
is
I'm
uncertain
about
it.
To
me,
it
is
isn't,
is
not
obviously
a
good
example
or
a
bad
example
of
IRT
F,
ITF
collaboration
and
so
I
think
it's
a
little
bit
of
a
mixed
bag,
so
I
feel
like
hip.
I,
don't
think,
is
a
clear
example
of
like
it
working
really
well
and.
E
E
Great,
so
the
routing
research
group
is
this
is
a
when
I
came
in
to
the
IRT.
If
they
were,
our
own
research
group
had
been
around
for
a
long
time
and
I
think
that
it
was
not
a
good
example
of
collaboration
in
that
what
I
saw
of
it
was
that
proposals
that
the
ITF
didn't
want
to
deal
with
were
redirected
to
the
routing
research
group
oftentimes
that
they
would
just
not
come
to
the
ITF.
E
The
end
end
research,
group
and
I
think
is
I.
Oh
so
I
put
this
in
the
worked
well
column,
based
on
your
comments
and
I
think
that
Colin
didn't
get
my
updated
slides.
So
let
me
let
me
speak
as
if
it
was
in
the
worked
well
column,
because
your
comment,
I,
was
persuaded
by
your
earlier
comment.
Ellison
that
it
was.
It
was
an
example
of
a
bunch
of
research
activity
that
found
its
way
into
the
IETF
in
I,
think
a
less.
E
It
was
a
much
longer
lived,
research
activity
and
so
is
less
sort
of
not
the
same
kind,
of
example,
of
something
that
was
focused
like
DTN,
but
something
where
there
was
a
you
knows
a
lot
of
research
that
happened
over
time.
It
was
a
close
research
group,
and
so
it
was
kind
of
indirect
and
how
things
came
out
of
the
research
group
and
into
the
ITF.
E
E
Measured
in
decades
and
so
qrg
I
put
in
here
because
it's
new,
it's
uncertain
but
I-
think
that
it's
a
so
I
don't
want
to
say
yet
that
it's.
It
is
a
great
example
of
of
IRT
F
IETF
collaboration,
because
there's
really
been
very
little
IETF
activity,
except
for
the
fact
that
there
was
a
QA
RG
tutorial,
which
was
very
popular.
E
And
so,
if
you
want
to
look
for
a
different
kind
of
pattern
of
ITF
IRT
of
collaboration,
a
sort
of
an
education
approach
of
like
here's,
an
interesting
research
area
that
is
related
to
networking
and
and
may
have
eventually
activities
in
the
IETF.
But
in
the
in
the
near
term,
is
a
source
of
information
and
educating
and
sort
of
raising
the
clew
level
and
ITF
participants.
Then
I
think
Qi.
Rg
is
sort
of
an
interesting
example
of
that.
So
at
this
point
the.
D
E
D
It
first
started
out
and
for
like
20
years,
but
to
be
clear:
the
people
who
might
not
know
it
incubated
our
entire
media.
You
know
if
the
internet
media
protocols
it
incubated,
diffserv
and
incubated
ecn
all
kinds
of
stuff
that
we
wouldn't
have
without
it.
So
what
kind
of
thing
could
be
like
that
in
future?
I'm?
Not
sure,
maybe
nothing,
but
it
was
actually
very
high
impact
on
the
ITF,
just
quite
different
from
the
research
groups.
We
have
yep.
R
S
E
Two
of
the
groups
on
here
the
only
two
that
I
know
of
a
closed
groups
are
on
this
list.
So
the
name
nameservers
research
group,
NS
RG
I,
can't
remember
if
nameservers
is
the
credit,
correct
expansion,
but
the
names
research
group
was
closed
and
then
also
end
end
research
group
was
closed
and
so
I
think
we've
got
both
sort
of
a
positive
and
a
negative
example.
So
I
don't
think
we
can
draw
conclusions
also
that
this
is
pretty
far
back.
I.
E
Don't
think
that
there
have
been
any
closed
research
groups
in
recent
memory,
everybody's
shaking
their
head
so
but
I
think
Christian.
You
raised
a
point
that
I
wanted
to
make
earlier
on
in
the
in
the
discussion
on
the
last
section,
which
is
there's
an
enormity
F
is
very
canary
constrained
process
because
we
want
to
be
open,
transparent
and
standards
organization.
E
Making
a
group
closed
is
one
aspect
of
that,
but
there
but
meeting
in
other
locations
is
another
piece
of
that
and
I
don't
know
if
it's
still
the
case,
but
but
it
was
for
a
while.
The
only
requirement
was
that
you
should
meet
once
a
year
at
an
ITF
meeting
to
promote
some
collaboration
and
cross
fertilization
of
ideas,
but
other
than
that
you
can
pretty
much
do
what
you
want.
I
think
that's
a
great
thing.
A
T
I
was
gonna
comment
on
a
couple
of
things.
First,
end
to
end
as
a
closed
research
group
is
gonna
leave
people
with
the
wrong
impression.
It
was
closed
in
that
membership
and
participation
was
by
invitation
only,
but
the
chairs
were
incredibly
crucial
in
figuring
out
who
to
invite
and
reach
out
to
and
move
forward.
T
E
T
Your
next
slide,
I
think
the
different
forms
of
transfer
is
really
insightful
because
what
happened
you're
the
first
bullet.
There
basically
is
an
incubation,
it's
pre
standards
and
the
goal
is
to
spawn
standards,
activity
and
a
group
that
started
that
way
needs
to
have
the
courage
to
say:
we've
done
the
job
we're
getting
out
of
business.
U
But
the
NMR
G
was
also
actually
the
route
for
net
coffin
yang
and
it
was
a
short-term
model
that
you
know
certainly
heavily
affected
the
ATF
today,
and
you
know
it
started
as
sort
of
a
fairly
short
project
of
two
to
three
years
that
it
was
too
long
to
do
in
the
IETF
and
and
the
research
you
know,
is
the
right
place
for
it
to
start,
and
then
it
certainly
transformed
a
lot
since
then.
But
it's
a
great
tech
transition
story
thanks.
E
V
There
are
a
few
of
the
things
here
where
we
also
want
to
look
at
our
failure
models,
as
well
as
our
success
models
and
I
can
think
of
at
least
a
few
research
groups,
which
I
will
not
name
that
were
that
wound
up
getting
chartered,
and
then
we
discovered
that
there
actually
weren't
any
interesting
research
problems
and
they
bounced
around
for
a
while
and
they
were
they
couldn't
produce
a
standard
because
they
weren't
in
the
ITF.
And
yet
we
discovered
that
what
was
happening
in
those
research
groups
wasn't
research.
V
So
one
of
the
things
I
think
we
do
need
to
sort
of
guard
against
is
allowing
groups
to
keep
going
on
and
on
and
on
with
not
understanding
what
the
boundary
is,
and
there
actually
aren't
any
interesting
research
problems
in
that
domain.
That
could
drive
a
research
agenda.
So
just
the
word
of
caution.
There.
V
Some
of
the
groups,
which
will
go
unnamed
in
facts,
were
chartered
because
there
were
things
that
were
believed
to
be
needed
in
the
research
community.
There
weren't
ready
for
the
IETF
to
deal
with
and
that
kind
of
collaboration
with
the
thought
that
things
might
transition
in
the
IETF
were
motivations
for
forming
those
groups.
So
let
me
just
reiterate
my
point:
there
have
to
be
interesting
research
problems,
independent
of
whether
the
output
is
something
that
winds
up
in
the
IETF
or
not
wait.
A
E
F
is
okay,
but
that's
different
from
so
I
think
that
there's
a
lot
of
different
kinds
of
things
that
can
grow
in
the
AI,
RTF
and
I
think
that
I
don't
see
a
benefit
to
creating
another
organization
to
hold
those
things,
because
sometimes
it
takes
people
with.
You
know
it's
that
research
in
an
implementation,
collaboration
that
yeah
this
or
the
joint
expertise
that
it
takes
to
sort
of
get
them
over
the
line
so
that
they
can
be
baked
here.
Something
I
don't
disagree
with
Dave.
You
know
they
don't
always
succeed.
A
Of
course,
because
I
think
we
need
to
be
clear
that
there
is
that
we
believe
there
are
research
issues
before
we
transfer
group
and
you
you're
the
boss,
yeah
yeah.
My
view
tends
to
be
that
if
it's
just
that
it
could
be
engineering,
it's
just
a
longer
term
focus
than
a
typical
IETF
group
to
me
that
that
should
be
a
perhaps
a
different
type
of
atf
activity.
I.
E
W
W
W
The
chair
of
the
IRT
F
was
dealing
with
the,
and
it
seems
like
to
me
that,
because
we
don't
have
the
same
research
groups
now
and
we
don't
have
the
same
ITF
and
we
don't
have
the
same
IRT
of
chair,
it
seems
like
the
problems
that
the
IRT
have
chair
is
facing.
Now
is
more
the
you
know,
getting
things
slotted
in
the
right
place
in
the
first.
W
You
know
the
first
balance
so
that
it's
not
the
fail,
buff
consolation
prize
that
people
tried
to
make
it
and
and
and
how
you
know
just
documenting
what
the
models
are.
You
know
DT,
NRG,
basically
kind
of
picked
up
stakes
and
move
to
the
ietf.
You
know
that's
a
model.
Other
people
have
bottles
like
ICC
RG,
which
is
a
completely
different
model.
I
would
I
would
caution
against
trying
to
make
this
very
precise,
because
the
research
groups
are
really
this.
W
You
know
the
scopes
are
big,
whether
the
we
research
groups
are
big
or
not,
and
they're
really
different.
You
know,
and
we
don't
have
a
lot
of
them
to
basement
to
base.
Quite
you
know,
criteria
on,
but
just
even
right
down.
You
know
what
is
what
happened
in
the
past
and
how
it
turned
out,
which
is
oddly,
the
paint
RG
draft
on
what
not
to
do.
U
Did
you
say
ten
minutes
a
couple
of
minutes?
Okay,
all
right
I
can
go
on
for
ten
minutes,
so
you
know
I,
think
looking
at
both
the
last
two
talks
right
there
they're
very
informative,
and
how
do
we
think
about
the
IRT
F
over
the
over
the
longer
term
and
especially
working
groups
and
and
when
they're
successful
and
there's
a
real,
a
challenge
there,
because
there's
a
width
issue
right,
IRT
F
groups
need
to
span
from
you
know,
far-reaching
research
that
you
know
it
looking
out
in
far
distant
future
to
stuff
that
needs
to
transition.
U
You
know
fairly
quickly
and
actually
specifically
transition
to
application
and
real
interoperability,
and
so
you
know
you
can
look
at
results.
As
you
know,
we
look
to
we
measured
this
really
cool
thing.
We
found
out
that
nothing
needs
to
change.
That's
still
a
success
right,
we've
looked
at
a
problem
space
and
we
found
that
there
is
a
problem,
we're
creating
new
work
or
a
new
working
group
out
of
it
that's
great
and
we
have
improvements
and
suggestions
and
that
got
transferred
into
you
know
into
protocol
changes.
U
You
know
on
the
wire,
so
that's
the
easy
thing,
but
the
thing
is:
is
the
success.
Possibilities
for
a
research
group
are
so
wide
that
it
might
actually
be
easier
to
look
at.
What
do
we
not
want,
and
so
I
have
a
couple
of
examples
of
that
of
which,
in
you
know,
research
groups
that
that
fail
might
include
research
groups
to
produce
new
documents.
U
I
think
you
had
an
example
of
that
research
groups
that
looked
at
a
problem
space
found
a
solvable
problem,
but
failed
to
find
an
audience
right
where
it
just
sort
of
fell
on
deaf
ears,
and
then
that
would
be
a
problem.
And
similarly,
you
know
deaf
ears
when
you
discover
protocol
deficiencies
in
existing
stuff
based
on
research
that
failed
to
actually
transition
to
fixes
and
like
actually
they're
present.
The
winner
presentation
from
today
is
a
good
example
of
that.
E
Would
say
the
most
insidious
example
of
something
that
doesn't
belong
in
the
IRT
F
is
a
you
know,
a
particular
company
proposal
that
is
trying
to
create
something
that
looks
like
an
open
forum
but
doesn't
have
a
constituency
that
I
saw
several
examples
of
that
when
I
was
I,
our
TF
chair
and
I
think
that
was
the
that
it's
like.
Okay,
maybe
there's
interesting
work
here,
but
it's
just
like
your
little
narrow
thing.
E
F
Not
mine,
so
listening
to
you
guys,
debating
on
stage
sort
of
the
boundary
between
research
and
advanced
development,
I
mean
I
think
that
there
is
this
other
space
where
waters
the
idft
versus
the
IRT
F.
When
there's
some
new
work
coming
in,
and
people
sort
of
have
some
vague
notion
that
there
might
be
something
here,
but
the
proponents
don't
seem
to
be
able
to
describe
it
very
well
or
sort
of
you
know
it's
is
it
because
they
don't
understand
the
problem
space.
F
The
solution,
space,
the
constituents,
but
but
it's
rather
vague,
right
and
those
things
get
tossed
around
and
sometimes
might
depend
on.
An
IRF
chair
is
someone
that
might
have
landed
in
the
Iron
Chef
other
times.
The
ADEs
have
worked
with
these
people
for
some
times
for
many
ITF
meetings
to
try
to
sort
of
distill
something
out
of
it.
Sometimes
the
IAB
or
an
IB
member
gets
appointed
as
a
shepherd
to
try
to
help
them,
and
maybe
CID
leads
to
barf
or
something,
but
that's
one
of
the
challenging
spaces
work.
F
X
On
the
bottom
to
sub-bullets,
I
think
it's
always
good
to
like
write
things
down,
but
want
to
be
careful
to
make
sure
that
it
doesn't
become
a
requirement
that
all
research
must
successfully
transfer
and
the
learnings
I
think
if
written
from
the
ice,
see
if
our
G
side
versus
re
from
the
research
side
versus
the
ietf
side,
they
might
be
very
different,
which
would
also
be
interesting.
Yeah.
E
A
You
everybody
yep,
so
thank
you
Erin
and
yes,
to
be
clear
that
there
is
absolutely
no
requirement
that
anything
transitions
in
standardization.
You
know
we
as
a
research
group
you,
you
know,
the
idea
is
to
develop
some
ideas.
Some
technology,
a
group
of
people,
may
look
at
the
outcome
of
a
research
group
and
say
this
is
appropriate
for
standardizing.
They
may
not,
and
it's
a
successful
way
as
long
as
we
learned
something.
K
G
G
So
this
started
I
mentioned
when
I
did
the
coin
presentation
that
we
had
to
interims,
and
this
discussion
actually
started
that
our
last
interim
in
October
and
we
figured
out
that
it
was
a
topic
that
was
much
bigger
than
a
research
group.
It
was
something
that
was
for
the
whole
IRT
F.
So
I
would
like
to
thank
everybody
and
the
coin.
Community
Jana
talked
about
communities.
Well,
that's
one
of
them
and
especially
Lars,
who
sent
us
a
set
of
very
interesting,
slides
and
actually
I
borrowed
one.
G
G
The
other
inputs
one
of
them
was
from
Colin
was
that
well
there's
more
than
drafts.
The
drafts
is
the
IETF
way
of
moving
forward,
but
maybe
there's
something
else,
and
maybe
the
typical
draft
format
is
ill-suited
for
for
research
discussions
and
also
the
typical
draft
presentation
format
at
a
lot
of
IRT
F
meeting.
We
would
like
to
know
the
progress
of
the
research
or
the
new
IDs
in
research,
not
just
a
delta,
from
the
last
version
of
the
of
the
draft.
G
G
So
the
top
concerns
was
again
that
these
draft
and
standardization
in
general,
but
we
were
IRT
F,
we
don't
do
a
standardization,
but
that
drafts
are
poorly
considered
in
academic
circles.
Well,
probably
because
people
don't
know
what
they
are.
The
other
point
was
that
we
needed
to
have
more
dissemination
of
the
research
group
activities.
A
lot
of
people.
Don't
know
we
exist
or
have
a
very
they
know.
Maybe
one
research
group
exists,
but
they
don't
see
how
it
fits.
G
Well,
it's
well
I'll
go
back
actually
because
the
first
thing
that
I
think
was
very
easy
to
to
resolve
on
the
even
on
the
call
was
was
the
travel
because
you
know
more
and
more
there's
people
who
are
participating
remotely
to
this,
and
if
it's
not
for
the
13
hours
ahead
or
the
16
hours
ahead
or
waking
up
at
2:00
in
the
morning
to
attend
a
meeting
you
can
participate
remotely
and
that
won't
cost
you
anything.
So
that
was
for
me
was
mote.
The
other
ones
were
much
more
important.
G
So
writing
a
draft
is
not
necessary
to
participate
in
the
orgy
meeting.
You
know
we
don't
put
like
if
you
don't
have
a
draft
on
command.
It's
not
the
case.
We've
had
a
number
of
academic
presentations
and
I
know
a
you
know.
A
lot
of
other
research
group
have
had
that
I
think
the
networking
prices
and
the
workshops
are
exactly
the
right
type
of
example,
of
research
that
was
done
somewhere
else.
G
That
is
actually
now
brought
to
this
community
and
we
really
welcome
grad
student
postdoc
and
again
I
mentioned
in
our
presentation
that
we
participate
in
the
hackathon
and
I
will
be
honest
with
you.
When
we
participated
in
the
hackathon
in
Montreal
was
actually
to
to
have
a
lot
of
the
local
grad
students
being
able
to
come
and
see
how
it
was
going
as
a
whole,
because
in
the
hackathon
you
have
all
the
groups
are
there,
and
it
was
actually
to
enhance
this
participation
from
the
local
universities.
G
And
another
thing
is
again:
I
mentioned
this
draft
perception
kind
of
uneven.
But
if
you
think
about
it,
mindsets
are
hard
to
change,
and
some
suggestions
were
that.
Maybe
we
should
state
better
their
research
challenges,
I
think
a
lot
of
times
on
our
wikis
on
the
github
and
even
on
the
Charter
were
very,
very
focused
on
something
we
would
like
the
group
to
achieve,
but
maybe
not
how
it
fits
in
the
greater
world
of
the
research
challenges
for
this
field.
G
We
could
invite
participation
of
people
actually
I
thank
Dave
last
time
in
Montreal.
He
had
suggested
a
researcher
in
Chicago
who
had
a
fantastic
presentation
and
was
essentially
had
been
invited
for
this
co-locate.
Actually,
people
mentioned
this
and
co-locate
enter
a
meetings
or
even
meetings
during
conference
that
are
related
to
the
field
and
organize
workshop
and
there's
actually
a
great
present
from
lorries
on
bridging
the
gap
between
internet
standardization
and
networking
that
he
presented
in
Brazil.
Other
ideas.
G
Maybe
create
and
then
share
specific
use
cases
and
data
on
the
wiki
and
and
basically
create
leverage,
not
just
for
one
research
group,
but
maybe
link
to
what
other
research
group
are
also
doing
so
that
people
can
start
navigating.
Through
it
add
some
research
group
topics
in
academic
seminars
and
presentation.
I
will
try
that
we're
doing
ICN
2020
in
Montreal,
and
we
want
to
add
some
presentations,
some
seminars
and
workshops
that
go
across
a
number
of
things
and
see
how
we
can
actually
disseminate.
G
E
One
idea
that
I've
seen
that
is
not
on
here
is
something
the
nm
RG
implemented,
which
is
that
they
did
pre-publication
reviews
of
papers
and
I
think
they
needed
some
confidentiality
to
be
able
to
do
that.
But
there
was
a
my
understanding.
Is
that
folks
perceived
that
as
being
a
real
benefit
and
the
papers
improved
good
idea.
U
I,
don't
want
to
prevent
you
finishing
so
quickly.
Antidote
right,
I
actually
was
told
recently
in
a
year
that
I
had
zero
academic
papers
and
a
couple
of
RFC's
that
you
know
that
wasn't
good
enough
and
so
I
get
that
that
particular
issue.
And
then
this
year
I
actually
have
two
really
good
academic
papers
and
zero
RFC's,
because
the
RFC's
are
taking
that
much
longer
than
that.
Much
harder
to
get
through
the
system
and
I'm.
Now
going
on,
like
working
group
last
call
number
three,
because
people
really
care,
and
so.
E
U
U
A
D
Also
make
I'm
inspired
by
your
bullet
about
vision
or
blue
sky
papers,
and
it
struck
me
from
some
of
my
past
time,
like
at
NSF
that
fields
have
like
10
year
horizon
planning
that
they
do
a
little
bit
formally,
but
that
is
very
valuable
for
those
fields
in
terms
of
getting
funding,
and
maybe
that's
another
way
you
could
do.
This
is,
is
have
kind
of
informal
review
here
and
RG
is
free,
but
lending
itself
to
that
kind
of
consensus
about
what
big
open
directions
are
that
could
be
helpful
for
the
community
academic
community.
Thank.
G
K
Dan
Bogdanovich
so
I'm
looking
at
this
sec,
you
know
idea
invite
participation
in
research
groups
and
IDs
from
leading
academics.
Let's
have
a
regular
ITF
participant
contributor.
How
can
you
know
who
are
the
leading?
You
know
participants,
usually
how
we
know
people
come
and
volunteer
this
we
find
out
who
is
interested
in
the
area
that
you
know
that
we
are
doing
some
work
yeah.
G
I
think
I'll
sound
like
a
social
media
guru
here
or
some
kind
of
influencer,
but
we
all
are
at
the
center
of
especially
in
this
research
world,
we're
all
at
the
center
of
a
large
number
of
connections,
and
we
know
who
are
the
leaders
in
our
group
in
a
world
and
we
can
actually
reach
out
to
them
and
if
they
cannot
come
because
you
know
for
a
reason,
they
can
a
lot
of
times.
People
are
really
nice
and
they're
going
to
suggest
somebody
else,
so
I
think
we
should.
G
We
should
not
think
that
the
world
is
limited
to
this
room.
You
know
the
world
is,
is
all
around
and
connected
in
a
hundred
ways,
so
I
actually
strongly
believe
that
you
know
if
we
invite
you
know
every
time
I've
invited
somebody
in
this
environment
even
when
they
couldn't
come,
they
actually
suggested
someone
else.
Q
Yes
is
yours:
it's
because
I
keep
seeing
that
conferences
increasingly
are
including
vision
and
blue
sky
papers,
and
they
are
often
invited
papers.
So
you
know
it's
in
some
ways
like
a
free
pass
into
a
conference
and
it's
super
fun.
But
I
wanted
to
go
back
to
the
point
about
how
do
we
get
the
academic
community
to
change
their
perception
that
the
RFC's
aren't,
as
are
more
important?
You.
E
Q
Least,
we
want
equal
grounding
right
or
we
want
people
to
be
rewarded
for
it,
and
I
wondered
whether,
in
the
same
way
that
vision
and
blue
sky
papers
are
around
fostering
looking
further
ahead
and
that's
what
the
IRT
F
does,
whether
we
can
reach
out
to
some
of
the
communities
like
and
I'm
from
the
US.
So
this
is
a
us-centric
idea,
but
it
translates
to
other
gos.
If
we
go
to
places,
we
have
organizations
like
the
NSF
and
like
DARPA,
and
you
know
the
Army
has
some.
Q
G
S
Christian
with
Amma
about
the
OFC
and
evaluation,
the
offset
Ito
pushed
a
change
in
the
AVI
format.
Couple
of
years
ago,
Donna
was
a
you
noticed
to
have
an
oid
reference
on
every
RFC,
which
was
precisely
to
facilitate
citations
of
RFC's
in
journals,
and
you
can
actually
very
easily
count
two
citations
of
a
given
RFC
on
values.
Libraries
and
I
think
that
if
we
are
concerned
with
that-
and
you
can
use
these
citations
as
a
way
to
give
weight
to
publications.
Y
I
Just
quickly
I'm
thinking
that
this
presentation,
and
also
whether
discussion
is
suffering
a
little
bit
from
what
we
actually
criticized
earlier,
so
projecting
so
known,
methods
of
working
from
the
IETF
to
IRT,
f,
research
and
then
wondering
oh,
why
doesn't
this
work
for
academics?
So
I
think
you
even
mentioned
standardization
on
an
earlier
slide.
I
I
mean
this,
isn't
really
not
what
this
is
about,
and
so
our
C's
I
mean
that's
an
issue
that
so
we
know
that
then
that's
like
our
C
takes
some
time,
but
that's
not
what
we
are
doing
in
the
energy
f
and
so
I
think
what
Dave
mentioned
earlier.
That's
really
important
that
so
there
are
at
least
two
criteria
to
be
aware
of
so
say
some
useful
output
for
the
IDF
and
in
some
way,
but
also
I
mean
doing
really
good,
relevant
quality
research.
I
And
and
for
that
I
think
it
could
be
interesting
to
discuss
a
certain
indicators
or
say
models
that
seem
to
work
well
and
also
maybe
ask
the
question:
I
mean:
what's
the
point
of
writing
a
draft
or
our
C
I
mean
there
must
be
some.
You
know
some
utility
to
that,
and
so
what
I
think
is
really
useful
is
see
this
as
a
means
to
enable
experimentation.
I
E
I
G
P
Jana
anger,
I'll,
be
quick,
I
agree
that
traps
have
a
use,
but
you
point
out
that
IRT
of
draft
perception
in
the
academic
world
is
uneven
at
best.
I
would
argue
that
any
draft
perception
in
all
worlds
is
uneven
at
best
just
to
not
a
belabor
the
point,
but
even
I
ITF
drafts
are
all
over
the
place.
You
can
have
an
independent
submission.
You
can
have
an
informational
RFC.
You
can
have
RFC's
that
have
had
review
that
I
haven't
have
as
much
review
as
we
believe
and
the
IDF
is
completely.
P
You
know
it's
it's
much
more,
there's
much
more
variance
in
I
already
after
have
certain
errors
in
the
IDF
drafts
and
in
that
sense,
as
an
academic
who's
tried
to
who's
gotten
tenure
based
on
on
publications,
I
couldn't
rely
on
on
RFC's
and
that's
just
a
fact
of
life.
It's
it's
not
I.
Don't
think
it's
reasonable
to
expect
academics
to
to
do
for
us
to
change
the
perception,
because
not
a
perception
issue.
It.
P
G
P
P
P
E
P
They'll
keep
coming
back
and
doing
stuff,
they
don't
use
us
as
a
publication
venue.
We,
as
a
research
group,
aren't
publishing
one
thing,
but
we
are
engaging
with
various
entities.
Various
groups,
students,
industry
groups
that
are
publishing
on
their
own,
but
we
are
creating
an
environment
where
they
all
come
talk
and
we
have
a
forum
for
that
to
happen.
P
V
All
right,
David
I,
want
to
go
beyond
and
emphasize
I
think
even
more
strongly.
What
John
it
was
was
getting
at
I
mean
I.
Do
research
I
run
an
an
orgy
I
participate
in
RG.
If
I
have
some
super
great
idea,
I'm
not
going
to
take
it
to
an
orgy
I'm,
going
to
write
a
paper
and
I'm
going
to
get
it
through
a
double-blind
program
committee
and
convince
people
that
this
is.
This
is
super
novel
and
something
that's
going
to
change
the
world.
V
What
are
G's
are
I
think
going
to
be
most
successful.
Doing
is
this
collaboration
function
right,
which
is
because
academics
I
got
to
tell
you
they
don't
collaborate
very
well
with
each
other,
they're
forced
they're
forced
to
buy
their
funding
agencies
and,
if
they
weren't
forced
to
they
wouldn't
do
it.
V
They,
you
know
so
I
Eve's
here
and
she
she
may
want
to
comment
on
this.
We
have
a
really
good
joint
project
between
NSF
and
Intel
that
talks
about
Wireless
edge
computing
and
ICM.
We
have
been
I
think
we
have
a
absolutely
perfect
zero
record
of
getting
anybody
who
was
doing
research
under
that
project
to
come
and
present
it
at
either
ICN
RG
or
any
of
the
wireless
oriented
research
groups,
and
the
reason
for
that
is
that
it's
it's
an
extra.
It's
extra
work
for
no
particular
benefit
in
those
contexts.
V
G
G
Okay,
okay,
so
I
switched
a
few
things.
I
skipped
a
few
things
so
I
can
I
can
see
that.
Obviously
we
can
do
better.
I,
really
like
the
idea,
the
fostering
I,
really
like
the
idea
of
the
community
communities
and
actually
I'm
going
to
conclude
with
something
that
I
said
this
morning
with
my
first
presentation
at
7:30.
What
we
want
to
create
an
is
Agora
for
people
to
come
and
share,
and
you
know
essentially
have
the
rest
of
the
community
understand
what
they're
doing,
why
they're
doing
it
and
how
we
can
create
even
more
research.
A
Right,
thank
you
very
much.
Thank
you
again
to
waiting
for
the
NRP
presentation.
Thank
you
to
everybody
who
spoke
later.
I
think
that's
been
a
really
interesting
discussion.
Hopefully
we
can
continue
this
discussion
throughout
the
rest
of
the
week.
Thank
you.
Everybody.
If
you
have
the
blue
sheets,
please
pass
them
to
the
front.