►
From YouTube: IETF106-TAPS-20191119-1520
Description
TAPS meeting session at IETF106
2019/11/19 1520
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
C
C
You
have
some
links
there,
you
can
click
Anakin.
You
can
read
on
Emily's
a
time.
So
this
is
this
the
agenda,
so
we
have
some
issues,
review
I,
think
we'll
go
through
the
github
and
then
we
have.
We
have
like
Brian
talk,
tech
talking
about
Tufts
architecture
and
interfaces,
and
then
Tommy
will
be
an
implementation
so
that
way
updates.
C
Then
we
have
one
IT,
a
plastic
off.
We
got
some
comments
that
we
would
like
to
converse
to
some
conclusion.
What
to
do?
I
think
where
our
Aires
has
also
like
try
to
sale,
resolve
the,
how
try
to
come
up
with
a
solution
like
arteries
of
the
issues
and
then
we'll
have
some
discussion
on
the
mile,
because
we
have
a
couple
of
attention
to
you
and
we
have
some
plans
for
that.
C
One
document
status
as
I
said
there
was
like
one
document
on
the
IPO
plus
last
call,
so
we
have
been
on
80,
follow
up
stays
and
we
have
Phillip
doing
the
shepherding
thanks
for
doing
it
and
you
have
I
think
you
have
a
quite
a
good
experience
looks
like.
Is
this
a
fast
shepherding
of
document?
Okay?
So
that's
a
good
experience
and
then
there
was
a
fan
interim,
but
we
cancelled
it
because
we
didn't
find
a
much
of
things
to
discuss.
C
B
B
Hold
on
a
second,
you
know
what
we'll
come
back
to
this
at
the
end.
Basically,
I
have
I
drafted
a
schedule
to
get
us
from
here
to
March,
with
getting
working
group
last
call
for
the
three
drafts
with
some
notional
weeks
for
calls
in
timeframes
for
doing
working
group
last
calls,
and
so
ideally,
I
wanted
people
that
the
authors
and
such
to
look
at
their
calendars
and
see
if
they
could
support
the
schedule,
get
a
commitment
from
folks
and.
D
E
B
E
B
Okay,
so
here
it
is
it's
a
it's
kind
of
aggressive.
Basically,
the
basic
structure
is
we
try
to
do.
Working
group
last
call
for
a
different
document
each
month,
starting
with
the
most
mature
right,
so
we
go
arch,
then
interface
and
implementation.
Then,
in
the
subsequent
month
we
figure
that
there's
going
to
be
stuff
that
comes
out
of
the
last
call.
We
have
to
do
a
Rev
right
and
so
when
in
December
we
work
in
group
last
call
arch.
Then
in
January
we
rev
it
and
January.
B
B
D
G
I
am
I'm
I'm
gonna,
disagree,
Nagori
I'm
strongly
in
favor
of
you
know
in
call
I
think
this
is
the
right
number
of
them.
I
think
we
probably
need
to
do
to
all
this,
because
January
13th
is
not
great
for
me
in
February,
10th
I'm
not
gonna,
show
up
at
because
this
is
not
as
interesting
as
the
mountains
are
I
haven't,
checked,
March,
23rd
yet,
but
I
think
it's
okay,
wait!
When
when
do
we
actually
know.
B
I
J
D
Not
I
just
wondered
whether
there
actually
won't
I
just
think
whether
if
we
do
architecture
working
group
last
call
and
with
then
we
we
try
and
revise
it,
and
we
try
and
get
good
text.
We
probably
have
it
ready
for
about
January
the
13th
or
so,
and
if
we
do
implementation,
we
do
working
great
last
call
in
February,
then
so.
D
Again,
Julie
so
I
think
the
first
okay
I
may
be
thinking
exactly
the
same
as
Tommy,
but
I'm,
just
not
going
in
my
head
yet,
but
I
think
the
the
architecture
call
needs
to
be
in
January
after
we
do
working
grit
last
call
we
get
some
feedback,
we've
done
a
detailed
read
through
with
our
brains,
Rhys,
inked
and,
and
it's
kind
of
almost
there
a
book.
We
just
need
to
get
it
there
and
on
the
next
one.
D
D
B
D
B
Me
makers,
I,
don't
understand
if
you
have
an
objection,
yet
let
me
try
to
explain
my
thinking.
The
thinking
is
that
the
interim
calls
are
not
just
to
discuss
last
call
comments,
but
they're
discussed
open
issues
for
documents
that
have
not
yet
gone
into
last
call.
The
idea
is
to
have
a
more
frequent
cadence
than
IETF
meetings
for
us
to
talk
about
things
that
are
unresolved
right.
It
doesn't
have
to
be
to
respond
to
less
call
Clemens.
G
Let
me,
let
me
be
a
little
bit
more
blunt.
I
think
that
the
January
13th
beating
is,
for
the
last
call.
The
February
10th
beating
is
for
the
called
the
December
16th
feeding
is
a
forcing
function
to
make
sure
that
we
like
actually
get
off
our
butts
and
do
the
work,
because
we're
gonna
assign
a
bunch
of
issues
today
and
we
need
an
intake,
we're
gonna
make
them
do
for
that.
G
B
G
B
B
J
B
E
G
E
G
Make
the
February
call
it
the
can't
recall
I
could
make
either
of
those
two
weeks,
but
that
also
gives
us
the
ability
for
those
of
us
in
you
know
who
live
in
countries
with
like
reasonable
holiday
schedules
who
actually
do
take
time
off
over
Christmas
like
a
lot
of
us,
don't
come
back
until
the
sixth
right,
like
we
disappear
on
the
20
mumbles,
and
we
come
back
on
the
sixth
means.
B
B
B
B
L
B
M
B
U.S.
west
coast
any
other
loud
gripes
about
this
schedule
here,
so
we
can
move
on.
This
is
one
of
these
things,
where
it's
much
easier
to
do
it
face
to
face
than
to
try
to
do
it
online.
Alright,
then,
okay,
gory,
these
are
these,
are
weeks
and
we're
gonna
do,
except
for
we'll
do
the
time
for
the
last
one,
but
we're
gonna
do
a
doodle
for
the
day
on
the
mailing
list.
D
So
I
guess
what
the
minutes
only
need
to
say
we're
going
to
doodle
for
them
really:
okay,
going
first
and
I,
really
like
the
idea
of
the
schedule
of
pushing
and
getting
the
arch
done,
cushion
going.
The
interface
done,
I'm
slightly
hesitant
that
implementation
will
arrive
in
February
from
previous
experience,
just
nothing
to
do
with
maturity
of
it,
but
to
do
with
the
type
of
month
ages.
I've
always
had
problems
with
February.
Personally,
it's
been
slightly
shorter
than
I
expected
and
people
stick
one
thing
in
the
middle
and
the
whole
thing's
gone
I
understand.
N
B
Big
ones,
I
would,
for
all
these
things.
I
would
prioritize
completion
over
moving
on,
because
I
want
to
get
the
completion,
and
unless
we've
got
like
some
interlocking
thing
where
we
want
to
get
the
implementation
experience
and
feed
it
back
in
I
would
definitely
agree
that
that
would
be
the
way
to
go.
Alright.
B
B
J
O
B
Mean
at
some
point
our
students
are
going
to
graduate
and
disappear,
among
other
things,
and
also
we've
been
we've
been
sort
of
working
on
these
documents
for
a
couple
years
now,
so
we
should
finish
them.
Yeah
I
mean
we.
Let
me
put
it
this
way,
we're
making
up
for
some
lack
of
aggressiveness
over
the
past
couple
years,
yeah.
H
B
G
Aggressiveness
on
arm
like
as
a
weight
I
forget
I'm,
an
editor
of
which
of
these
architecture
and
interface
right,
yeah,
both
cool
okay.
So,
with
my
editor
hat
on
for
those
two
documents,
I
intend
sort
of
generation
of
text
to
working
group
last
call
for
architecture
to
be,
if
there's
an
open
issue
on
architecture
that
we
can't
find
somebody
to
put
text
in
today.
It's
closed
about.
It's
closed
on
results.
It's
like
multics.
Nobody
cares
enough
to
do
it.
I'm
gonna!
Do
it
for
interface.
G
If
we
can't
find
people
kind
of
by
that,
December
16th
call
it
we're
willing
to
commit
we're
gonna
type
text
over
Christmas,
then
it's
like
hey.
It
was
a
neat
idea.
It
was
cool.
We
probably
should
have
done
something
about
it,
but
we
gotta
move
on
great
like
so.
The
perfect
is
the
enemy
of
the
good
and
your
anything
oh
yeah
yeah
see
we
can
actually
see
what's
going
on
yeah,
so
yeah
I
mean
that's,
that's
how
I
intend
to
run
this
with
my
editor
hat
on
is
we're
closing
stuff.
G
Q
B
B
L
L
L
N
Hi
guys
max
rank
it
from
tio,
Berlin
and
I'm,
just
going
to
talk
about
our
pipes,
implementation
and
mostly
what
we
did
at
the
heck
of
fun
and
so
since
Brock,
basically,
what
we
added
our
protocol
and
remote
endpoint
racing
and
frameless,
there
are
the
big
things
that
have
been
added
interface.
Election
is
almost
done,
I
think
and
mr.
hopefully
going
to
it
quick
at
some
point,
and
so
the
framers
did
in
our
implementation.
Now
are
a
bit
different
from
the
ones
that
I
specified
not
specified
at
an
example
in
interface
implementation.
N
Sorry,
not
interface
and
main
difference
is
that
data
frame
message
when
they
arrive
instead
of
when
the
application
calls
received.
That,
for
us,
was
just
a
choice
to
make,
but
it's
or
not
that
interesting
and
it
can
do
much
more
than
just
transform
messages.
Obviously,
and
so
thanks
to
Jake,
we
also
have
multicast
support
interrupts,
so
we
can
receive
muriatic,
receive
SM,
multicast
streams,
so
until
Saturday
or
until
today.
N
Actually,
we
thought
we
wouldn't
need
a
anything
API,
no
Michael
had
we
had
discussion
on
the
open
floor
case
that
we
might
actually
do
something
and
need
something
in
APA,
but
yeah.
There's
an
open
plea
request
by
Jake
about
how
to
do
multicast
for
now
and
the
way
we
do
it
is
that
the
local
endpoint,
if
it
is
a
group,
address
on
the
local
endpoint
and
we
just
assume
it's
multicast,
and
then
we
require
the
application
to
specify
in
the
transport
properties
that
it
is
a
unicast
receive
a
unidirectional
receive.
N
D
C
D
R
Yes,
so
the
proposed
text,
regardless
of
whether
there's
one
source
or
not,
you
would
be
joining
the
the
group
using
an
ASM
join
and
therefore,
if,
if
the
packets
do
get
routed
somehow
to
you,
then
they
would
be
so.
If
somebody
else
sends
to
that
ASM
group,
you
would
receive
it
if
you
are,
if
you
join
with
an
ASM
this
this.
It
may
be
that
this,
inter
that
this
couples
two
things
together,
that
should
not
be
coupled
together.
N
R
R
P
L
N
R
Far
as
I'm
aware,
I've
never
heard,
I
did
ask
around
I've
never
heard
of
anybody
using
it.
It's
like
theoretically
possible
in
the
specs
I
I
would
be
shocked
if
it
works,
but
generally
like
okay,
so
on
the
endpoints
today,
if
you
try
to
do
an
a
normal
socket
and
an
issue,
the
the
sock
up
that
you
set
your
options
are
to
do
an
SSM
join
or
to
do
an
ASM
join,
and
you
do
it
by
setting
a
sock,
opt
and
providing
the
EM
rec
or
the
the
would
see
their
own
code.
That
and
Marcus.
R
P
N
Okay,
so
that
was
the
multicast
only
part
of
it.
What
we
introduced
in
plumeria
order,
hackathon
explai,
we
did
Jake-
has
a
protocol
right
now,
a
draft
for
protocol
code
ambi,
which
is
a
way
to
check
the
integrity
of
multicast
packets,
which
creates
an
out-of-band
TLS
connection
along
the
multicast
receive.
So
we
implemented
it
as
a
framer,
and
what
we're
doing
is
that
under
start
initialization
of
the
multicast
connection
object,
the
framer
also
creates
a
TLS
connection.
N
So
there's
two
connections:
one
is
inside
the
frame
and
one
is
the
connection
exposed
to
the
application
and
then
anytime,
a
packet
arrives.
The
multicast
packet
arrives,
the
framer
gets
many
failed
by
the
framer,
gets,
manifests
all
the
time
from
the
MB
generator
from
mu,
manifest
generator,
and
then
it
checks
if
the
hash.
For
that
specific
multicast
packet
is
in
the
manifests
and
if
it
is,
it
just
returns
the
message
itself
like
the
multicast
message.
It
doesn't
do
anything
to
the
message.
N
So
the
question
kinda
is:
is
this
a
legitimate
use
of
a
framer,
because,
right
now
the
text
mostly
says
encapsulation,
encoding
and
message
transformation,
but
it
doesn't
do
any
of
that.
It
takes
the
message
as
it
comes
in
and
puts
the
same
message
out,
so
if
it
should
be
a
legitimate
framer,
maybe
at
something
to
takes
like
also
analyze
or
just
change,
something
about
the
text
to
make
it
clear
that
this
is
a
legitimate
use
and
if
it
isn't
I'm
not
sure
why
it
shouldn't
be.
Basically.
I
Tommy
Polly
Apple,
so
I
mean
I'm,
not
sure
how
we
gauge
legitimate,
having
framers
in
our
implementation.
I
have
definitely
done
essentially
the
same
thing.
It
is
a
like
once
you
have
that
shape
of
thing.
It's
very
easy
to
do,
and
it's
very
natural
to
do
that
so
yeah,
I
I
think
it
is
a
natural
outcome
and
I
don't
think
we
should
prohibit
I,
don't
know
if
we
do
we
need.
Is
it?
Are
you
proposing
text
for
that
use
case?
We're
just
gonna?
Let
it
kind
of
happen
right.
I
N
Right
and
that's
oh
right,
that's
not
it
and
we
also
like
fun
about
right
now
in
the
API.
It
says,
like
the
frame.
Object
gets
created
once
on
the
pre
connection,
and
it's
really
editor
on
the
pre
connection.
But
it's
not
right
clear
what
happens
if
you
call
isn't
it
because,
then
you
only
have
one
frame
object,
but
the
listen
can
spawn
many
connections
and
there
would
like
the
listener,
wouldn't
really
have
an
option
to
create
new
frame
objects
itself
right
because
it
doesn't
necessarily
know
how
to
create
them
right.
N
P
High
competence,
I
I,
wonder
that
we
don't
have
different,
very
different
views
of
what
framers
are.
I
Tell
me
Akali
so
I
think
if
you
look
at
what
the
architecture
does
say
for
framer,
it
is
certainly
smaller
and
a
tighter
definition
of
it
and
we
have
moved
all
the
implementation
details
to
the
implementation
documents
or
even
the
interface
is
the
the
thing.
I
think
that
Colin
is
thinking
of
the
simpler
version
to
your
point.
When
you
are
playing
with
these,
you
realize
you
can
do
more
with
it
and
it's
it's
an
expansion
point.
I
So
I
think
once
you
start
using
it
that
way,
it
potentially
goes
beyond
the
notion
that
we
have
in
the
architecture
of
a
primary,
so
I
I
would
prefer
to
leave
the
definition
constrained,
because
that's
all
you
need
to
do
and
I
think
these
other
use
cases
end
up
being,
maybe
some
other
doctrine
of
how
to
describe
you
using
them
from,
but
it's
not
really
part
of
its.
It
is
it's
an
outcome
of
the
way
we
build
them
more
than
a
fundamental
property.
G
So
yeah
mostly
that
I'll,
you
know
I'll
answer
the
first
question
up
here.
Is
this
a
legitimate
use
of
framers
with
it
doesn't
matter
all
right
like
so,
the
architectural
document
is
designed
to
be
sort
of
a
framework
for
understanding
the
interface.
The
interface
document
is
designed
to
be
as
abstract
as
possible.
G
The
fact
that
framers
are
kind
of
the
only
real
bit
of
implementer,
accessible
extensibility
that
we've
put
into
the
architecture
because
we
need
it,
but
because
of
you
know
how
framing
and
D
framing
works
with
a
message
based
thing
on
top
of
street
based
protocols.
You
can't
get
away
from
it.
It's
going
to
be
where
all
of
the
I
don't
wanna
say:
abuse
happens,
but
they've
creative
use,
innovation,
yeah,
abuse,
ennovation
same
same,
it's
gonna,
be
where
OB
innovation
happens
so
like?
Is
it
a
legitimate
use
of
framers?
Who
cares?
G
Are
you
I
mean
thank
you
for
asking
the
question,
but
you're
also
the
one
with
your
hands
on
the
keyboard
so
like
right,
running
code,
Trump's
rough
consensus,
every
time,
cool
thanks.
H
B
K
K
Good,
because
this
is
actually
something
I
noticed
also
when
I
read
it
the
last
time
that
maybe,
if
anything,
maybe
we
have
a
few
too
much
details
in
there,
because
we
whenever
something
you
feature
got
added,
there
was
a
tendency.
We
want
to
mention
it
in
the
architecture
draft,
but
maybe
that
is
not
not
necessary.
So
yes
good,
but
then
we
all
agreed.
Okay,.
B
H
B
H
So
I'm,
just
being
here
at
the
shepherd
of
the
document
and
in
the
last
month's
we
had
a
working
group
last
call
we
did
I.
Did
the
Shepherd
ride
ride
up
the
idea
review
was
done.
We
got
rivers
from
Canada
and
sectors
that
saying
the
document
is
ready.
We
get
an
e
Anna
review,
okay
and
then
we
got
it
should
not
be
published
in
its
current
form
from
to
in
or
should
not
be
published.
H
Its
cursory
should
not
be
published
in
its
current
form,
sorry
by
ekr
and
christian
Bettina,
and
this
is
the
reason
why
we're
discussing
this
here.
Let's
wrap
up
what
the
criticism
roughly
was
so
first
its
it
started
with
this
general
skepticism
against
the
tap
side
here
so
too.
Ambitious
pushes
against
implementations.
H
G
On
this
point,
I
would
have
a
I
would
buy
that
argument.
A
whole
lot
more,
if,
like
quick,
wasn't
actually
turning
a
LPN
into
a
protocol
stack
identifier
so
like
I
think
we
can
like
I,
mean
too
ambitious
task.
Yeah
we
had
a
couple
of
boss
about
this.
The
first
one
was
harder
than
the
second
one.
It's
working
group
so.
G
Agree
basically,
Kyle
rose
Akamai.
The
I
think
the
the
the
criticism
against
against
an
API
that
some
people
might
not
want
to
use
is
it's
something
that
will
be
solved
by
whether
people
use
it
or
not
right
the
when
it
comes
to
when
it
comes
to
security
or
safety.
I
think
those
criticisms
are
warranted
and
I
guess
I'm
guessing
that's
what
criticism
too
is
and
I
think
that's
where
we
should
focus
our
effort.
I
There
yah
sorry
Magnus
so
just
to
cut
to
the
chase
a
little
bit
for
people
in
the
room.
We
have
published
a
new
Rev,
I'm
sure
you're
about
to
get
to
this
I
think
potentially,
as
we
go
through
these
things,
I
want
to
validate
that
this
revision
that
we
have
done
a
the
group
thinks
is
a
good
idea,
but
also
that
we
think
it
addresses
some
of
these
things.
So,
just
to
kind
of
briefly
quote
from
that.
Well,
we've
clarified
now
in
like
an
on
goal.
I
Section
is
to
say
it
is
not
a
goal
to
allow
software
implementations
to
automatically
switch
between
different
security
protocols,
essentially
say
the
scope
of
our
tapsa
fication
of
racing.
Things
is
not
applying
to
the
security
aspects
and
I.
You
know.
Hopefully
this
does
address
this
concerned.
It's
saying
we're
not
touching
your
stuff.
Q
Okay,
Magnus,
thank
you.
Yes,
I
just
want
to
I
mean
make
clear
I
mean
for
my
as
an
ad
here
in
this
protective
I.
Just
think
that
you
need
to
it's.
I
mean
it's
fine,
to
push
back
against
criticisms,
wait
and
with
argument
saying.
Yes,
this
is
our
task.
What
we
do,
what
we
have
to
be
sure
to
do
with
cetera
and,
of
course,
these
people
who
haven't
been
involved
or
maybe
was
at
the
boss
and
didn't
like
the
outcome
with
the
Citroen,
that's
I
mean
that's,
not
nothing.
Position
discusses
as
Tom
Thomas.
Q
H
So,
moving
on
to
the
second
criticism,
first,
security
protocols
are
special
and
saying
security-
probably
not,
but
must
be
integrated
deeply
into
the
application
and
must
not
be
automated
or
raised
in
sepsis
and
I.
Think
with
your
revision,
you
already
address
the
second
point.
My
personal
opinion
is.
You
could
also
have
argued
that
there
are
use
cases
for
that,
but
that's
the
choice
of
the
authors
and
I
can
definitely
say
it's
available
choice
and
said
transferring
network
security
a
fundamentally
different
yeah.
H
Somehow
they
have
to
be
integrated
somewhere
and
which
steps
we
are
acknowledging
that
they're
part
of
the
stack
and
that
they're
not
always
somewhere
outside
the
stack
and
some
special
at
ons.
Historically,
they
have
been,
but
I
think
the
time
that
we
can
go
without
is
over
and
therefore
taps
has
to
integrate.
That
and
I
think
at
least
for
my
reread
of
your
changes.
G
Kyle
Rosa
Akamai,
so
the
I
don't
know
how
many
people
read
the
new
draft,
but
we
added
a
goals
and
non
goals
section
at
the
beginning
and
the
non
or
I
don't
know
if
it
was
the
non
goal.
But
a
non
goal
was
to
race,
different
security
protocols
or
assume
that
that
a
security
protocol,
any
security
protocol
that
a
tap
system
might
choose
would
provide
some
magic.
You
know
fairy
dust
or
whatnot
that
would
make
your
application
magically
secure,
we're
instead
making
it
clear
that
we
need
the.
G
We
need
implementations
applications
rather
to
explicitly
choose
a
security
protocol
that
you
know
that
fulfills
their
requirements
as
far
as
security
goes
right.
So
it's
it
we're
making
it
much
clearer
than
I.
Think
the
doc
was
before
that
we're
not
trying
to
erase
the
security
protocols
against
each
other.
H
H
So
the
other
criticism
is
its
security
work
outside
this
sec
area.
I
can
definitely
say:
yes,
it
is
somehow,
but
what
other
choices
do
we
have
so
asking
another
area
to
just?
Do
the
work
for
us?
It's
just
difficult
and
therefore
I
think
we
have
enough
expertise
and
it
makes
sense
to
say.
Okay,
we
did
this
in
the
other
scope.
J
He
chose
to
basically
delete
this
from
the
from
the
draft,
because
it
was
giving
the
impression
that
we
are
trying
to
give
like
a
comprehensive
security
analysis
of
these
protocols,
and
we
chose
that
we
will
not
attempt
to
make
this
comprehensive
analysis,
but
instead,
applications
that
choose
a
protocol
have
to
go
back
and
treat
like
the
original,
RC
or
whatever
documentation
of
the
security
protocol
and
then
make
a
conscious
choice
of
what
the
security
properties
are
and
be
aware
of.
Limitations.
J
Q
So
but
yeah
I
I,
don't
see
a
problem.
I
mean
working
groups
outside
of
security,
obviously
need
to
work
on
security
related
to
the
protocols
etc.
So
it's
it's
I,
don't
take
that
first
or
anything,
I
think
and
I
think
Teresa's
comments.
Maybe
it's
more
spot-on
for
what
what
issue
was
singer
so
and
I
I
haven't
read
the
new
version
yet
so
I
haven't
figured
out
if,
if
you
removed
too
much
or
not,
but
but
let's
see.
F
Dawkins
and
what
Teresa
said
about
pulling
out
their
detailed
descriptions
is
brilliant
because
it
was
not
super
easy
for
the
transport
people
to
agree
on
the
transport
trade-offs
back
and,
for
you
know,
characterizations
and
trans
in
and
in
trade-offs,
and
things
like
that
back
in
the
day
when
taps
was
starting.
So
that's
the
right
answer.
Having
said
that,
former
area
directors
can
be
blunt.
This
is
chartered
work
and
it
was
discussed
within
the
isg
when
I
chartered
it
period
Thank.
T
E
H
So
for
mean
set,
this
was
a
split
of
documents.
Now
it's
one
document,
I
think.
If
we
get
more
criticism
on
that,
we
might
want
to
change
or
we
might
want
to
decide
to
split
the
document
again,
but
as
now
for
the
rework
most
of
the
security
and
security
analysis
or
security
feature,
spotting
has
been
removed.
I
don't
see
the
reason
for
that
anymore.
H
B
A
quick
chair
interrupt
here,
so
one
of
the
roles
of
the
Shepherd
is
to
work
with
commenters
to
get
feedback
on
the
resolution
of
their
comments,
so
I
think
a
typical
next
step
would
be
for
you
to
summarize,
or
maybe
the
with,
in
collaboration
with
the
authors.
To
summarize,
the
changes
send
a
pointer
to
the
new
diet
meant
to
Christian
and
Ecker,
allow
them
to
respond
to
the
changes,
and
then
we
work
with
our
area
director
on
making
a
decision
on
how
to
proceed.
After
that,
these
are
informative
comments.
We've
responded
to
it.
Q
I
So
I
wanted
to
ask:
the
chairs
is
due
to
this
change,
since
we
did
go
through
working
group
last
call:
are
we
okay?
Do
we
need
to
go
through
that
again
or
are
we
okay
essentially
asking
the
whole
working
group
to
please
review
it
as
we
are
going
forward
with
it
and
have
specific
people
look
at
it?
Yeah
I
think.
I
B
Is
you
know
my
sort
of
opinion
as
chair
and
odd
can
Wayne?
If
he
wants?
Is
we
didn't
know
working
group
last
call
it
got
that
feedback
we've
done.
Itf
last
call
we've
gotten
that
feedback.
It's
like
each
time.
You
incorporate
feedback,
you
don't
have
to
start
back
from
square
zero,
so
I
think
we're
in
a
process
of
continuous
refinement.
I
think
it.
You
know
we
should
make
sure
the
the
working
group
gets
notice
like
a
summary
of
what
the
changes
are
and
it
can
encourage
them
to
give
another
look
at
it.
C
T
Yeah
that
sounds
Chris.
What
that
sounds
great.
If
this
were
just
the
reduction
in
content,
I
wish
we
could
just
move
it
forward,
but
because
there's
this
new
bit
about
what
the
interface
is
to
applications
which
is
sort
of
different
from
what
we
had
before
it's
like
rephrased,
a
little
bit
differently.
Having
folks
like
Brian
and
particulars
that
were
working
on
the
implementation
or
the
API
Draft
would
be
really
great
and
having
those
reviews
before
we
move
forward
with.
You
know
for
some
definition,
move
forward.
Q
T
P
Q
M
Q
From
my
perspective,
you're
gonna
have
basically
two
weeks
to
comment
review.
These
changes
and
and
I
mean
I'm,
hoping
that
you
also
that
you
manage
to
get
feedback
from
a
Korean
and
a
Christian
in
that
time
frame,
because
that's
roughly,
where
I
mean
I,
don't
think
we're
gonna
have
an
ISDN
call
within
the
next
two
weeks
and
everything
it's
two
weeks
until
it
so
I
will
see
how
it
looks
next
week
and
then
see
the
side
of
mine
scheduling
for
dynasty.
B
Q
This
is,
I
flossed
cole
comments
and
we
need
I
need
two
story
for
say:
I
need
to
know
that
we
have
addressed
or
these
consider
those
comments,
etc,
and-
and
that's
what
we're
doing
now
and
that's
why
I
got
it.
We
need
you
at
least.
I
would
like
to
see
some
feedback
from
occurring
christian
on
this,
because
they
were
the
main
main
people.
Q
B
F
V
D
P
D
People
in
this
room
have
a
look
at
it
quickly
to
see
whether
it
really
is
the
same
thing
that
we
wanted.
I
think
he
probably
is
but
he'd
be
nice
to
have
told
the
working
group
such
I
think
he
says
the
same
stuff
I'm
not
complaining,
but
I'm.
Just
saying:
there's
a
lot
of
text
change.
We
should
look
at
it
and
give
encouragement
to
the
chair
that
we.
G
B
G
So
we
have
number
45
we're
gonna
were
the
oldest
one.
First
Wow
one
digit
issues
just
came
from
quick,
so
this
is
you
do
digit
issues
still
Tommy
I'm
making
you
feel
guilty
enough
to
just
go
write.
The
text
for
this
like
I,
mean
like
I,
think
we
know
what
you're
clicking
it
and
I
call.
You
see
what
we
great.
We
had
a
pretty
long
discussion
about
this.
G
I
I
G
Together
we'll
sit
down
and
do
it
wordsmith
it
can
you
can
you
assign
me
to
this
one
as
well,
go
up
to
the
top.
G
G
G
E
W
V
B
G
Wow
looks
like
a
Chromebook
all
right,
so
architecture,
privacy
and
security
considerations,
ready
for
tax.
T
T
Are
we
should
just
sit
down
this
week
and
do
it
yeah
so
yeah
on
Friday?
Let's
do
it
all
right,
I'm
Friday,
correct
great.
It
will
happen
on
Friday,
excellent.
L
G
G
I
I
V
G
L
G
Interface,
we
probably
need
to
put
a
line
of
text
in
there
right.
It's
like
you're,
not
really
racing
anything
you're,
just
listening
on
multiple
things
and
like
whether
or
not
one
of
those
two
things
like
injects
delay
for
some
reason
is
up
to
that.
I.
Don't
think
we
should
suggest
to
people
that
they
do
that
right.
So
there's
a
line
of
text
in
each
doc
and
it's
a
sign
to
Tommy
and
callin
and
callin
is
confused.
P
P
G
G
G
G
X
G
G
And
what
I
would
say
is
that
start
TLS
is
an
application.
Sorry
and
WebSockets
is
an
application
right.
It's
a
the
application.
Modifies
a
stack
and
that's
a
problem,
but
taps
is
more
taps,
is
more
important
doing
stock
selection
at
connection
time
than
it
is
at
mutation
time
and
you
could
possibly
have
an
implementation
specific
thing.
This
is
by
the
way,
this
stack
is
mutated.
All
to
this
other
stack,
which
is
actually
kind
of
implicit
right.
G
G
I
So
tell
me
Paul
here,
probably
Singapore
it
to
the
point
like
this
issue.
Right
now
is
labeled
with
arc
and
API
and
I
certainly
don't
think
we
need
text
in
the
architecture
for
this
and
with
regards
to
the
API.
What
we
did
with
the
framework
essentially
modify
the
taxes
that
we
pushed
the
details
of
how
you
do
dynamic
modification
into
the
implementation,
yeah
and
I
think
what
is
there
is
sufficient
to
do
it.
I
The
only
caveat
there
is
that
the
implementation,
unlike
the
other
ones,
is
informational,
and
so
it
doesn't
have
any
normative
text
saying
that
your
taps
implementation
must
give
these
hooks
to.
Let
people
do
start,
TLS,
I
think
in
practice
they
will,
but
that
would
I
almost
argue.
It's
a
follow-on
document
that
maybe
we
should
start
looking
at
standardizing
implementations
of
protocol
stacks
and
having
like
interoperable
ones
that
we
have
defined
with
yang
models
as
secondary
activity.
G
I
I
Y
Ok,
this
was
me,
I
mean
this
was
connected
to
another
comment,
because
it
was
sometimes
a
little
bit
hard
to
understand
this
term,
these
terms
when
they
show
up
the
first
time
because
they
were
not
well
defined,
but
now
we
have
a
little
bit
more,
this
overview
section
so
I
think
that
actually
fulfills
the
same
class
time.
Ok,
it
was
just
like
closing
it.
D
G
G
J
Already
architecture
document
before
coming
to
this
meeting
and
I
was
kind
of
confused.
What
we
actually
consider
equivalent
I
think
we
talked
about
this
before,
but
in
the
architecture
text
is
not
really
clear.
So
one
interpretation
is
that
if
our
application
doesn't
space,
if
I,
what
it
needs
like
it
says,
reliable,
ignore
like
I,
don't
care
if
it's
reliable
or
not,
then
TCP
and
UDP
can
be
equivalent,
and
then
the
architecture
says
this
is
fine
and
it
says
it's
not
fine,
like
there's
two
different
places
where
we
talk
about
this
looks
like
phil.
G
G
N
H
So
the
basic
case
was
saying
that,
if
something
matches
that
criteria
selection
properties
specified
by
the
application
it's
considered
equivalent,
so
if
you--if,
if
it's
not
so
TCP
and
UDP,
can
be
equivalent
if
the
application
does
doesn't
care
about
any
properties
of
the
transport.
But
this.
But
this
is
clearly
not
a
problem
of
taps,
but
a
problem
of
an
application
just
not
specifying
what
it
wants.
Ready.
G
So
the
real
question
is:
is
if
the
if
the
application
specifies
something
stupid,
that's
not
our
problem
right!
It
is
up
to
the
implementation.
The
implementer
is
to
decide
whether
or
not
they
want
to
be
permissive
or
restrictive.
On
that
yeah
right
yeah,
there's
defaults
as
well
right
like
so,
and
pretty
much
everyone
is
going
to
have
their
default
be
yeah.
Here
you
get
TCP,
because
that's
probably
what
you
meant.
J
G
Needs
you
assigned
yeah
and
actually
because
and
I
would
say
so.
Please
add
that
note
on
security
in
the
issue
and
I'd
say
since
you
have
a
lot
more
context
on
security
than
I.
Do
that
it's
it's
probably.
Actually
that
was
that
was
almost
a
joke
assigning
you
when
you
said
someone
should
be
assigned,
but
I
think
you're,
actually
the
right
person
to
do
it
so
there
so.
X
X
I
Looking
through
this
again,
I
think
Phillips
point
that
it's
mainly
point
one
that
needs
clarification
of
text
is
absolutely
correct,
because
the
other
points
are
much
clearer
in
saying
that,
like
you,
both
things
must
offer
the
transport
services,
as
required
by
the
application
yeah,
and
so
essentially,
you
must
also
have
the
same
application
features
such
as
multiplexing
as
required
by
the
application.
If
you
don't
require
them,
the
fact
that
h2
has
multiplexing,
you
don't
care
about,
doesn't
matter
so.
H
G
Yeah,
so
this
is
basically
the
architecture
talks
about
events,
but
then
the
interface
talks
about
events
and
callbacks
and
it
uses
events
for
things
that
happen
asynchronously
and
callbacks
for
things
that
happen,
because
the
security
Association
event
happened
great
and
the
the
should.
We
explicitly
specify
this.
So
it's
not
confusing
and
I
think
we
should
actually
have
both,
because
a
callback
is
different
than
an
event.
G
A
callback
is
a
hey
I,
yeah,
yes
right
yeah
an
event
is
something
that
doesn't
have
a
context
that
you
pass
to
it
and
a
callback
is,
and
callbacks
are
very
common
sort
of
in
the
like
api's
that
provide
security
that
we're
going
to
be
building
on
top
of
yeah.
There's
a
lot
of
yes,
there's
a
yeah
I
think
we
just
I,
think
I
put
a
ready
for
text
tag
on
this
and
I
think
I
was
right.
Oh
no,
I
did
not,
but
let's
do
that
now
and
I'll
assign
myself
since.
T
P
G
G
B
G
Gonna
skip
the
ready
for
text
because
well,
Tommy
I,
know
you're
gonna
rate
text
and
then
Jake
is
gonna
rate
acts
a
geek.
You
actually
have
written
some
text
for
that
you
have
a
pending,
PR
and
grace
is
gonna,
write,
text
and
write.
Okay,
we've
already
got.
We
already
talked
about
that
one
property
for
address
privacy
telling
me!
Oh,
do
you
want
to
talk
about
this?
One
Tommy?
P
G
G
G
I
A
minor
yeah,
clearly
implementations
may
find
better,
like
interoperability
across
applications
using
different
systems.
If
they
do
have
it
failed
later,
as
we've
said
here,
because
you
could
imagine
that
something
that
on
one
platform
is
unsatisfiable,
condition
is
satisfiable
on
other
platforms,
and
so
it's
kind
of
a
weird
assumption
to
make.
But
it
doesn't
matter.
G
Well
so
one
thing
one
thing
that
might
happen
there:
two
things
that
could
happen
right.
You
could
end
up
with
a
path
that
you
can
use
a
transport
protocol
on
the
stack
on
that
you
couldn't
before,
or
you
could
install
a
loadable
kernel
module
that
gives
us
CTP,
support
and
I
think
that
we
probably
want
the
implementation
to
handle
the
first
one
gracefully
and
you
get
extra
credit
points
if
you
handle
a
second
one
gracefully,
but
we
don't
expect
it
and
in
either
case
I
think
this
is
like
this
is
not
a.
G
This
is
not
something
that
we
need
to
specify
at
the
API
level
right
like
so
when
the
thing
fails
doesn't
need
to
be
part
of
the
contract.
The
API
does
currently
specify
that
there
were
two
ways
it
can
fail.
It
can
either
you
know,
return
an
error
when
you
try
to
instantiate
the
thing
right,
I
would
like
unreliable
UDP
or
no,
but
that
works
I
would
like
unreliable
TCP
right
that
works
too.
But
it's
a
hack
right,
I
know.
G
But
we
have
to
wait
for
the
install
the
loadable
kernel
module
event
to
happen
right
yeah,
so
yeah
we're
moving
on
clarification
on
queued,
receives.
G
You
Tommy,
you
were
nominated
to
write
this
by
Michael
because
you
probably
already
have
a
solution
for
this,
because
if
you
don't,
then
people
are
complaining
to
you
because
it
happens
quite
a
while,
so
so
in
volts
will
assign
himself
and
then
unassigned
himself,
which
is
like
some
like
hey.
Let's
do
this
together.
W
W
M
W
M
D
G
G
There's
text
here
that
basically
makes
a
generalization.
This
will
improve
performance,
achieving
greater
throughput,
which
is
not
supported
by
the
research.
It's
not
supported
by
the
research
in
situations
where
they
were
trying
to
actually
make
it
work
on
unfavorable
pounds,
and
it's
certainly
not
supported
by
the
research
when
one
of
your
paths
that
you're
going
to
get
your
axe
across
is
actually
a
tin
can
so
I
think
this
is
default.
Ignore
does
anyone
disagree?
Okay,.
T
G
J
G
I
So
recent
changes
we
updated
the
terminology
for
our
API
mappings.
This
is
mainly
thanks
to
Michael
for
going
through
and
using
kind
of
the
official
names
that
we
came
up
with,
for
what
are
the
transport
features
and
actually
saying
hey
by
the
way.
Remember
these
other
documents
we
did
so
all
of
this
taps
API
actually
uses
those
mappings
and
defines
those
so
I
think
that
was
a
really
strengthening
thing.
It
shows
that
we
actually
learned
something
so
whoo.
We
also
added
text
for
defining
our
mappings
for
SCTP.
I
I
So
we
also
got
some
error
reasons
appendix
that
was
I.
Think
for
max.
So
thank
you
for
doing
that.
I
moved
the
message
framer
over
from
API
into
implementation.
So
that's
where
we
stuff
our
start:
TLS
hacks!
So
that's
good.
We
have
I
think
it
was
from
Phillip.
We
got
some
text
around
pooled
connections
and
then
we
have
a
start
on
referencing.
Existing
implementations.
I
I
think
we
want
to
fill
that
a
little
bit
more
but
essentially
say
this
is
where
we
got
this
background
from
I,
think
that
is
appropriate
for
this
document
and
it
will
just
want
so.
Essentially
anyone
who
has
been
working
on
this
I
know
we
have
PI
taps.
We
have
our
implementation.
We
have
the
work
that
was
done
in
neat
exactly
and
I.
Don't
know
if
there's
other
work
that
we
want
to
highlight
from
the
post,
sockets
efforts
when
Brian
and
you're
doing
with
students,
but
anything
there
that
we
want
to
add
in.
I
I
Fill
out
that
blog
that'd
be
great.
Thank
you.
So
I
wanted
to
just
kind
of
get
a
slide
out
here
and
you
can.
You
know
we
can
go
offline
and
do
this,
but
just
when
you
zoom
out
to
just
the
kind
of
outline
of
the
document
of
what
we're
doing,
the
goal
is
to
be
very
parallel
to
the
lists
of
things
that
we
have
in
architecture
and
an
API
and
just
saying:
here's
how
you
implement
these
things
and
let's
get
into
the
nitty-gritty
of
it.
So
we
have
you
know
what
are
these
objects?
I
How
do
we
do
connection
establishment?
I
think
this
is
the
biggest
section
with
all
the
racing
work.
We
have
sending/receiving
data
that
includes
frame
we're
now
connection
management,
connection,
termination,
caching
and
then
that
last
section
is
the
specific
transport
protocols,
and
this
is
where
we
go
and
we
use
the
formal
mappings
that
we've
defined
previously
in
taps
say
and
here's
how
these
things
all
play
out.
I
We
just
we
discuss
different
ways
of
doing
it,
of
scattering
those
mappings
throughout
the
document
or
having
them
all
aggregated
in
one
place,
and
what
we
ended
up
with
is
deciding
that
we
want
them
in
one
place
so
that
if
someone
is
going
and
implementing
TCP
in
their
taps
implementation,
they
can
see
I
here's,
how
I
do
that
one
they
can
focus
on
that
protocol.
If
you
have
other
opinions,
please
write
an
issue
speak
up.
X
I
D
U
M
X
I
mean
I
sort
of
disagree,
because
I
mean
the
fact
that
you
know
clone
on
TCP
means
open
a
new
connection
or
as
clone
on
messy
tv-channel
means
a
new
channel
and
not
a
new
connection
is
kind
of
fundamental.
You
know
that
if
you
disagree
on
what
those
things
mean
then
they're
you
know
not
doing
this
they're
not
doing
the
same
thing
and
as
an
implementer
I
need
to
know
what
happens
when
I
call
these
KPIs
or
otherwise
they're.
Just
you
know,
don't
mean.
G
So
I
kind
of
like
the
fact
that
the
implementation
draft
is
informational
I
do
too
like
I,
like
it
a
lot
and
I
think
that
what
we've
bubbled
up
here
is
something
that
needs
to
come
back.
We
did
such
a
good
job
of
closing
all
the
API
issues,
but
I
think
this
might
be
an
API
issue
that
we
essentially
say:
hey,
look
certain
transport
protocol
stacks.
Have
this
feature,
and
this
clone
thing
I
think
we
need
to
kind
of
bind
it
a
little
bit
more
tightly
because
because
Jonathan's
right,
but.
I
G
G
I
N
I
Y
I
I
think
that
we
should
have
this
discussion
all
the
lists.
There's
more
time
doing
yours,
yeah,
so
I
just
wanted
to
highlight
what
we
do
have
is
issues
right
now.
Some
of
these
are
cross
listed,
so
we
already
have
the
PO
crest
for
multicast
stuff.
That's
great!
This
is
the
issue
just
to
finish
filling
out
the
implementations
where
I
talked
about
that.
So
please
do
that.
This
is
going
to
require
all
of
us
to
help
structure
is
essentially
what
we
just
discussed
and
I
think
this
is
the
kind
of
the
one
niggly
bit.
I
V
I
L
I
So
he'd
been
assigned
to
help
look
at
some
stuff
about.
We
essentially
do
have
text
about
what
you
do
with
proxies.
We
don't
have
any
text
about
what
you
would
do
with
tor,
but
I
think
we
can
leave
that
out.
Okay,
great,
so,
let's
close
that
that's
the
one
I
wanted
to
get
confirmation.
We
can
close
boom
done
all
right,
so
I
think
the
main
thing
out
of
this
is:
we
should
have
a
good
discussion
on
the
list
about
the
concrete
mappings.
L
Y
G
G
G
The
problem
the
problem
is,
is
that
a
LPN
is
a
stock
identifier,
that
the
stewards
of
LPN
do
not
understand
is
a
stock
identifier
and
will
probably
violently
resist
I'm,
just
you're
the
closest
thing.
We
have
a
security
guy
right.
So
it's
your
fault
and
I
get
the
sense.
They
will
violently
resist
being
told
that,
even
though
it's
true
so
that's
a
bigger
Longer
uglier
discussion,
we
can
file
an
issue
on
our
issue.