►
From YouTube: TAPS WG Interim Meeting, 2020-04-17
Description
TAPS WG Interim Meeting, 2020-04-17
A
E
As
part
of
this,
we
used
to
have
some
normative
language
in
the
security,
the
security
considerations,
and
now
it
just
references
others
and
removes
its
own
normative
village.
Also,
the
section
on
talking
about
how
the
protocols
have
to
be
raced
correctly.
That
is
folded
up
into
that
earlier
section,
because
it's
a
requirement
not.
F
E
E
G
E
And
structurally,
to
go
through
the
top
level
requirements
in
here,
so
there's
the
requirements
section,
it
describes
it,
and
so
the
first
requirement
is
that
you
have
to
provide
the
common
API
is
for
the
common
features,
so
you
have
to
have
general
API.
Is
you
have
to
include
at
least
min
set?
That's
the
first
chunk
of
requirement.
E
Then
the
next
chunk
is
that
you
have
to
allow
access
to
specific
protocol
features
such
that
you
know.
People
who
need
to
be
able
to
set
like
a
TCP
specific
option
can
do
so.
If
they
have
to.
You
have
to
have
the
protocol
stacks.
Do
you
select
have
to
be
equivalent
in
what
the
application
expects,
so
you
don't
break
compatibility
with
them
and
they
have
to
have
good
security
properties
and
then,
lastly,
you
have
to
maintain
in
front
interoperability.
You
can't
have
one-sided.
You
have
to
be
able
to
have
a
one-sided
deployment.
E
D
Yeah
I'm
I'm
not
going
to
say
this
very
clearly,
but
it
seems
like
we
might
say
you
know
if
you
are
providing
a
Datagram
service
to
carry
stream
based
applications,
you
must
implement
some
framer,
but
I.
Don't
know
if
I
believe
that
I'm
just
sort
of
asking
the
question
whether
you
addressed
it
all
in
that
section.
F
D
E
D
F
E
F
F
G
F
F
G
F
I
Simple
thing
would
to
do
would
be
to
basically
say:
yes,
we're
just
going
to
state
this
as
a
normative
requirement,
because
it's
kind
of
obvious
from
the
rest
of
the
document,
because
it's
one
of
those
things
that
if
you
manage
to
implement
the
rest
of
taps
without
having
a
message,
base
interface
to
it
and
it's
actually
compliant.
Then
congratulations
pointless,
but
well
done.
Sir.
I
E
I
think
to
that
point,
a
lot
of
the
normative
language
that
we
are,
keeping
that
Corey
helped
identify
are
things
that
may
not
otherwise
be
obvious.
Like
saying
like,
oh,
you
need
to
actually
look
at
the
things
in
the
min
set
because
you
may
miss
if
you
were
just
doing
a
minute,
I'm
just
doing
your
own
overlay.
You
have
to
be
careful
about
security,
because
you
may
forget
about
that.
E
I
I
D
At
some
point
anyway,
so,
let's
let
me
just
do
a
quick
management
interrupt
so
first
for
those
folks
who
haven't
noticed
in
the
WebEx
chat
section,
there's
a
link
to
the
etherpad.
Please
go
there
and
put
your
name
down
sign
a
blue
sheet,
and
for
those
of
you
who
didn't
already
assumed
that
the
ITF
note
well
applies
to
this
meeting.
D
K
I
Essentially,
note
I
mean
if
we
go
off
on
a
tangent
that
is
not
essentially
stuff
that
ends
up
in
github.
We
should
scribe
the
stuff
that
is
the
tangent,
that
didn't
isn't
stuff
that
ends
up
in
github,
otherwise,
I
think
we
should
just
have
a
list.
The
issues
and
pull
requests
that
we
addressed
as
the
minutes.
Great
anything,
that's
an
action
item
should
end
up
in
an
issue
anyway.
Can.
G
D
E
I
I
D
I
E
I
I
M
I
J
B
J
We
did
a
lot
of
rewriting
for
the
multiple
Paskus
stuff
so
that
we
now
Adam
changed
the
multipath
communication
modes
to
have
additional
passive
mode
for
most
use
cases.
We
all
headed
the
original
documents,
so
you
can
say
I
won't,
have
bandwidth
aggregation,
but
only
if
the
other
one
opens
essentially
the
sub
flows
of
multiplicity.
J
Discussion
point
that's
left
within
this.
One
is
whether
we
want
somehow
to
address
the
interface
choice
which
interfaces
to
use
for
multipath,
and
my
recommendation
or
my
wish
would
be
to
add.
Just
at
note
the
separate
PR
that
says:
please
use
the
properties
for
interface
or
PVD
selection
to
choose
a
set.
The
multipath
is
choosing
that
from.
I
F
Issues
here,
one
is
like
I'm
I,
actually
don't
understand
these
passive
notes,
because
it's
at
the
end
right.
So
it's
like
what
the
thing
that
you
decide
locally
is:
if
you
want
to
announce
new
passes
or
not,
and
if
you
want
to
use
them,
you
cannot
impact
the
other
side
and
the
decision,
if
you
want
announce
and
use
new
passes,
actually
I
think
that
that
was
what
the
other
property
is
for.
So
I
think
this
is
mixing
up
the
two
properties
we
have
right
now
in
a
way
that's
unnecessary,
so.
J
To
be
honest,
this
was
also
my
first
thought.
While
writing
this
I
came
up
with
with
the
problem
that
it's
actually
a
little
bit
more
complicated.
So
one
is
the
choice
whether
to
is
tell
let's:
let's
talk
in
multi
pass,
TCP
terms
to
make
it
a
little
bit
easier.
The
first
choice
is
which
sub
flows
to
establish.
The
second
choice
is
packet.
Scheduler,
you
use
for
the
SAP
flows
for
the
first
choice,
which
says
you
can
actually
say,
especially
in
the
server
case.
I,
don't
want
to
establish
any
sub
flows
at
all,
but
I.
J
Let
the
client
establish
the
SAP
flows
towards
me,
probably
about
dust
interfaces,
and
the
second
choice
is
once
I.
Have
these
SAP
flows,
which
packet
scheduler,
do
I
use
to
distribute
the
packets,
the
SAP
flows
and
body
part
disappears.
No
need
that
client
and
server
choose
the
same
packet.
Scheduler
I
can
actually
do
completely
different
scheduling
of
the
packets.
So
therefore
the
passive
one
is
just
deciding
on
I.
Don't
want
to
open
any
sense
at
all,
but
the
other
one
might
and
the
address
exposure
property
is
actually
whether
I
want
to
send
this.
F
So
actually,
sir
I
think
the
two
decisions
you
just
said
a
completely
independent
right,
one
is
like
when
and
how
to
establish
surplus
and
the
other
one
is
how
to
use
them.
If
they
are
there
and
it
doesn't
matter
if
you
open
this
up
blue
or
the
other
one.
So
if
you
are,
if
you
are
an
aggregate
code,
all
the
flows,
all
the
paths
you
have
together,
no
matter
who
establish
them
so
I,
don't
think
you
need
a
passive
aggregate
because,
like
when
you
get
into
flow,
you
just
use
it.
F
There
might
be
actually
three
things
here
and
we
need
another
option
for
it.
One
is
like
how
to
use
the
different
paths.
What's
it
what's?
The
schedule
do
you
want
to
use?
Who
is
the
one?
Was
opening
the
different
paths
and
like
when
and
if
you
want
to
announce
it,
a
new
IP
address.
So
these
are
three
different
things,
which
should
have
three
different
properties
and
should
not
be
like
interconnected
nowhere.
I
have.
J
E
E
F
E
E
N
I
Say
the
way
that
it
is
right
now
reminds
me
a
whole
lot
of
what
proc
net
ipv4
TCP,
CN
and
Linux,
which
you
know
well,
leave
that
as
an
exercise
to
the
reader
to
determine
whether
that's
a
good
idea
or
not
I
think
it's
fine
I
know
this.
Echo
is
a
really
long
conversation
we
had
in
the
quick
interim
about
adding
the
sort
of
more
stuff
to
quick
and
the
outcome
of
that
was
essentially
hey.
This
is
still
kind
of
research,
so
we
don't
want
to
do
it.
I
I
would
say,
with
respect
to
taps,
I
think
hey.
This
is
kind
of
research,
so
we
should
put
an
arbitrary
stopping
point
on
it
and
and
ship
it,
because
we're
never
going
to
actually
assuming
that
the
researching
the
space
keeps
going
for
the
next
five
years
or
so,
whatever
we
publish
right
now
is
going
to
look
a
little
silly.
F
M
F
I
Okay,
actually
so
this
is
this.
This
is
good,
so
I
think
that
what
we
have
in
the
notes
right
now
or
let's
take
what
we
have
and
turn
it
into
a
more
optimal
set
of
things,
which
seems
reasonable.
I,
think
the
scheduling
strategy
stuff
is
a
separate
question
and
that
seems
like
a
protocol,
specific
property
for
now.
F
F
P
E
Q
I
J
L
J
J
I
F
J
Have
a
proposal
how
to
resolve
that,
and
this
would
be
to
explicitly
state
that
you
do.
This
is
the
interface
properties
we
already
have
and
say.
If
you
say
you
want
to
establish
multi
pass,
then
everything
that's
preferred
will
be
chosen
for
multi
pass
and
we
own
only
fallback
to
something
not
preferred,
and
if
you
say
then
it
doesn't
take
part
in
multi
pass
if
you
say
avoid
it's
only
useless,
last
resort
for
for
back
after
everything
else
fails.
F
E
L
J
E
Q
E
F
M
O
Do
a
say
in
the
interface
draft,
that
for
connections
that
are
established
additional
properties
of
the
path
and
use
as
a
thing
that
you
can
clearly.
But
it
just
it's
like
part
of
a
long
list
and
we
don't
define
an
interface
for
it.
But
we
do
say
that
you
should
be
able
to
clearly
be
a
property
that
have
in
Section
ten
managing
connection.
I
E
F
This
is
the
only
place
in
the
implementation
graph
where
we
actually
find
another
interface,
so
I'm
still
very
uncertain
about
the
split
here
I'm.
There
are
a
couple
of
things
in
the
implementation
draft,
which
probably
should
still
stay
in
the
implementation
craft,
but
I
think
it's
also
having
the
split
as
it
is
right
now.
If
you
read
the
API
draft,
it's
still
really
hard
to
understand
what
framers
are
and
having
some
of
this
interface
description
in
the
API
draft
makes
it
all
so
I
think
much
easier
to
understand
how
this
is
supposed
to
work.
F
F
You
actually,
after
the
the
transmission
or
the
connect
initiated
and
before
you
start
transmitting
any
data,
so
you
can
do
something
like
start
TLS
with
it
like
how
you
would
just
a
TLS
with
it
I
think
we
could
like
add,
actually
more
example,
text
and
implementation
draft.
But
the
fact
that
you
have
this
interaction
should
probably
noted
in
the
in
the
API
draft
or
in
general,
how
the
interaction
works
between
the
framer
and
the
energy
connection
actually
I'm
still
confused
about
it.
E
That
is
all
that
the
application
itself
should
need
to
do
the
fact
that
that
framework
gets
invoked,
while
the
connection
is
starting
up
to
participate
in
that
kind
of
like
a
layer
of
handshakes,
he
is
for
the
implementation
of
taps
to
do
not
the
application.
The
application
doesn't
need
to
go,
and
after
it's
added
the
framer,
it's
free
connection.
Okay,
again,.
C
F
F
E
C
F
Know
what
I'm
saying
is
this
is
an
interface
that
has
to
be
known
by
the
application.
If
you
want
to
mind
your
own
framer
right,
so
it
isn't
applique
and
API
to
the
application,
and
it
does
help
a
lot
if
you,
if
you
look
at
this
interface,
to
understand
what
framers
are
and
how
they're
supposed
to
work.
F
C
J
F
That,
especially
the
part
about
buffer
management
should
be
an
imitation
draft,
but
that's
really
just
very,
very
small
part
of
the
text
there.
This
interaction
between
like,
when
does
the
connection,
call
the
framer
and
how
does
the
connection
or
the
framer
call
back
the
connection?
How
do
you
keep
the
data
flow
running
and
that's
apparent
that
I'm
missing
in
the
API
document.
D
F
L
E
F
Think
like,
if
you
only
read
the
the
tip
of
the
IP
API
document,
you
don't
understand
what
framers
are
so
I
think
you
need
to
provide
more
information
about
the
data
flow
here.
This
could
be
a
diagram
or
whatever,
but
then
my
other
point
is
also
that
I
find
it
weird
that,
like
this
is
the
only
place
in
the
implementation
document
where
we
actually
defining
an
interface
right
and
why.
I
We
define
like
three
quarters
in
the
example
interface:
it's
not
a
full
interface,
and
the
problem
with
this
is
that,
like
an
efficient
implementation
of
a
message,
framer
is
going
to
be
tied
very
deeply
to
the
implementation
decisions
that
were
made
at
implementation
time,
as
well
as
probably
to
some
of
the
features
of
the
platform.
The
implementation
is
running
on
top
of
right.
I
If
you're
doing
something
in
a
kernel,
it's
gonna
look
completely
different
than
if
you're
doing
something
with
Python
async
I/o
to
you
know
pick
on
max,
which
is
gonna,
look
completely
different
if
you're
doing
it
inside
a
stub
library
that
gives
you
an
RPC
like
an
interface
to
these
things
right.
These
are
gonna,
be
completely
different,
implement
like
it's,
not
an
internal
interface,
but
it
is
an
interface
that
is
that
it
makes
no
sense
to
specify
in
a
standard
because
accidentally
and
on
purpose,
we're.
Basically
then
saying
these
technologies.
I
F
J
I
Sure
whether
it's
worth
the
effort
doing
that
I
wouldn't
I
like
if
we
in
either
of
the
documents
we
basically
say
here,
is
an
interface
that
we
know
to
be
low
performance.
Please
don't
implement
it.
People
are
not
gonna,
read
that
part
they're
gonna,
implement
it
and
then
they're
gonna
be
pissed
off.
That
taps
is
slow,
I.
F
Agree
that
everything
that
is
related
to
buffer
management,
if
you
copy
data
over
or
if
you
just
provide
a
pointer
or
whatever
right.
This
is
all
very
implementation
specific,
but
this
is
like
currently
it's
three
sentences
in
there
right,
it's
more
about
which,
in
which
point
of
the
data
processing,
do
you
actually
call
a
framer,
and
how
does
it
call
that's
a
trademark
call
the
connection
back
and
I.
Think
that's
that's
like
that's
very.
That's
actually,
I
think
what
Philip
just
said.
F
E
If
we
described
it
without
providing
like
API
calls
and
I
you
mentioned
like
have
a
diagram,
I
and
the
architecture
has
a
diagram
at
a
very
high
level,
and
it
feels
like
we're
missing,
like
he
just
says,
they're
here
what
if
we
had
the
more
detailed
diagram
about
framers
and
how
they
fit.
Logically,
in
a
new
section
in
the
interface
document,
we
don't
provide
API
calls
because
we're
not
pretending
like
you're
actually
implementing
it
here,
but
show
like
this
is
what
they
are
and
they
plug
in.
At
this
step,
I.
I
I
It's
hard
enough
to
do
that.
I'm
still
inclined
to
punt
like
we're
punting
I
mean
we're
absolutely
punting
right,
we're
absolutely
looking
at
this
and
saying
no,
we
don't
know
enough
to
actually
define
this
interface.
So
you're
on
your
own
I
mean
that's
a
pretty
trivial
interface
that
that
are
a
pretty
fertile
example
that
Philips
has
brought
up.
That
is
really
not
far-fetched,
but.
F
D
B
H
F
I
I
F
P
I
Make
a
terrible
suggestion
that
I'm
gonna
try
and
get
everybody
to
disagree
with
me
so
that
we
can
like
move
it.
The
conversation
forward
I'd
like
to
leave
framers
as
specified
as
they
are
in
the
interface
draft,
and
if
we
can
come
up
with
anything
that
is
more
specified
than
that,
then
it
should
be
in
draft
IETF,
Stapp's
framers
guys
like
there's.
Q
F
I
Watching
I'm
watching
Tommy
type
and
I
disagree
with
them.
It's
not
or
leave,
as
is
it's
and
leave,
as
is
and
do
and
do
so.
We
want
to
do
the
stuff
in
the
first
option
anyway,
I
think
so
we
write
this
says:
that's
not
cuz!
That's
that's!
That's
fine
and,
if
you're
doing
sort
of
like
the
not
so
weird
we're
gonna
like
partially
offload
taps
into
a
thing,
it's
still
between
the
rest
of
the
protocol
stack
and
the
application.
It's
just
that
it's
folded,
but
anytime
you're,
doing
off
loads
like
that
you're
folding
stuff
anyway,.
F
F
F
H
I
I
C
B
E
G
I
J
G
M
K
M
Which
is
different
from
from
from
whether
or
not
the
request
has
been
no
not
right,
because
if
I
say
avoid
that's
false,
if
it
hasn't
been
applied,
I
think
that's
a
less
contrived
feedback
and
saying:
has
it
been
honored
and
done?
If
you
see
if
I
ask
her
something
negative
has
been
it's
true,
it's
weird,
but
producing.
M
J
M
I
M
E
E
K
I
M
F
M
M
F
F
I
J
It's
not
how
it's
structured
at
the
moment,
if
you
want,
we
exercise
this
in
the
beginning,
and
I
had
a
lot
of
fighting
for
that
and
millia.
If
you
want
to
have
that
farm
rent,
you
would
have
to
my
overcomplicated
proposal
I
had
in
Montreal
for
three
years
ago,
so
I
guess.
If
we
wanted
to
keep
it
simple,
we
can't
really
solve
this
problem
with
mutating
stuff.
O
Also,
to
make
people
aware,
in
section
10
of
the
API
draft,
we
already
say
that
you
can
query
on
a
on
a
connection
that
is
established
closing
or
closed.
You
can
create
the
selection
properties
of
the
extra
protocols
that
were
selected
and
instantiated,
so
we
might
want
to
adjust
that
to
whatever
we
decided
here.
M
E
M
Will
leave
it
as
it
is
I
think
it's
easy
and
simple
right,
I
think
it
is
making
it
more
complicated
because
I
mean
yes,
most
things
become
connection
properties
like,
for
instance,
if
you,
if
you
do,
have
congestion
control,
then
you
can
have
two
conjoined
connection
property
really,
which
tells
you
what
congestion
control
it
is.
It.
J
H
M
J
Have
is
we
have
a
selection
property
and
you
can
on
a
connection.
You
can
query
whether
feature
was
enabled
or
not,
and
if
you
want
something
more
detailed
like
which
congestion
controller
was
chosen,
then
you
have
to
add
another
connection
property.
That
X
is
the
exposed
which
congestion
country
we
got.
F
It's
the
case
that
we
have
certain.
We
have
properties
right.
We
have
certain
properties
that
only
makes
sense
to
set
during
protocol
selection
or
path
selection,
whatever,
because
they
impact
this,
and
they
do
not
impact
any
other
kind
of
configuration
later
on,
and
there
are
other
properties
which
to
do
impact
the
collaboration
as
soon
as
the
selection
is
done,
but
these
are
still
our
properties
and,
like
my
understanding,
words,
that
the
notion
of
what
a
selection
property
is
this
not
like
really
relevant
anymore.
As
soon
as
you
have
created
a
connection,
because
then
everything?
J
F
M
Then
you
can
change
it,
because
all
connection
properties
are
changeable,
which
makes
it
confusing
this.
What
does
that
I
mean?
That's
there's
a
structural
thing
here
I
mean
you
could
have
a
table
of
all
the
connection
properties
that
are
attached
to
the
selection
properties
that
they
were
before
it's
just
making
it.
J
M
Mean
some
of
them
wouldn't
be
attached
to
any
any
connection
property
that
you
want
to
be
able
to
change
or
there's
a
number
to
it.
For
instance,
this
binary
things
like
notification
of
excessive
retransmits
or
I.
Simply
soft
error
messages
the
direction
of
communication.
You
know
these
things
are
just
that's
an
enumeration.
Am
I
looking
at
the
right
list
here.
M
F
I
O
F
M
F
I
F
I
I
Q
I
I
C
E
I
I
D
I
E
N
I
G
Wait
youyou.
We
can't
do
what
we
say
because
we
say
that
vendors
can
use
something-
that's
not
in
the
registry,
but
they
can't
use
ones
in
the
registry
and
the
registry
is
still
open
and
changing.
So
you
can't
just
say:
you've
got
to
use
something
different.
What's
in
the
registry
and
then
the
register
is
changeable.
J
There
interpret
the
registry,
it
doesn't
make
the
different
kind
of
differentiation
we
want
to
make
in
the
taps,
interface
and
that's
useful
for
most
implementations
but
yeah
the
interface.
The
registry
still
tracks
the
taught
types
interface,
so
you
can't,
for
example,
distinguish
between
a
Wi-Fi
and
a
wired
Ethernet
card
by
the
values
of
the
registry.
While
you
can
discover
a
lot
of
interface
types,
you
will
never
have
on
an
ant
host.
E
D
I
N
I
Well,
so
there's
this
text
here
in
five
to
ten
that
says
the
set
up
interface
type
is
expected
to
change
over
time
as
new
access
technologies
become
available,
which
basically
sort
of
screams.
Please
make
me
a
registry,
so
after
that
I
would
add
a
sentence.
It
says
the
interface
types
available
on
a
given
system
are
implementation-dependent
essentially
say
this
is
why
we're
not
doing
that
I
can
go
ahead
and
make
PR
for
that
something.
N
E
G
This
may
be
something
that
we
don't
say
much
about
at
all,
because
maybe
someone
in
the
IDF
has
great
ideas
about
how
to
do
things
in
this
space
and
create
Nitra
documents
for
this.
But
it's
not
something
we
can't.
They
have
anything
to
say
about.
So
it's
not
prescribed
something
that
says,
can't
do
this
or
shouldn't
do
this
because
me,
it
may
happen
in
time.
People
try
to
provide
something
at
the
moment.
It's
all
proprietary.
B
J
E
D
I
O
I
Do
we
actually
have
any
guidance
for
or
implementers
about
what
basic
document
yet
like
if
we,
if
we
open
that
floodgate
that's
gonna,
be
I,
think
that
goes
in
the
implementation
draft?
It's
possibly.
Here's
like
your
are
things
that
should
be
discoverable
at
your
system,
but
I
think
if
we
spent
a
little
time
thinking
about
that,
we
could
come
up
with
a
very
long
list
that
would
be
useful
and
incomplete,
but
it
would
still
be
useful
if
it's
incomplete,
so
it's
like
the
API
draft
were
not
being
able
to
solve
the
problem.
D
G
J
J
I
F
J
Think
they
will
be
changing
over
years
and
I.
Think
once
thing
that
would
make
sense
is
having
a
registry
of
the
namespaces
we
have
for
the
properties,
so
everything
that's
not
specified
in
the
document
yet
with
some
before
the
actual
property
name
and
just
have
it
for
documentation
required
and
have
some
central
point
where
you
can
link
the
actual
namespaces.
This
would
be
a
very
nice
thing.
I
guess
the.
I
F
Mean
isn't
the
namespace,
usually
you
say,
like
I,
have
met
only
the
types
of
notation
for
like
IOT,
something
and
I
have
my
namespace
I'm
IO,
T
company,
X
and
I.
Have
my
own
properties
right
and
I
only
want
to
use
it
in
my
attempts,
implementation
and
like
the
users
of
my
types
of
rotation.
They
need
to
know
about
it,
but
they
can
read
my
documentation
because
they
have
my
code.
Why
does
anybody
else
implementing
another
implementation
for.
J
E
I
think
that
falls
more
into
the
work
that
we
need
to
be
doing
on
the
implementation
side,
and
we
were
talking
about
splitting
the
implementation
document
into
the
general
guidelines
versus
the
per
protocol
and
communication
considerations
like
if
you
have
a
document
for
oh
here's,
how
maps!
Here's,
how
setp
mapped
here's,
how
these
things
map
having
a
nice
list
of
they're
in
there
of
all
the
properties
that
are
relevant
to
them.
That.
E
E
Don't
think
the
registry
is
really
like.
A
registry
is
either
about
trying
to
have
its
allocated
stuff
that
people
don't
stomp
on
each
other.
That's
not
relevant
really
here.
It's
also
about
trying
to
make
sure
that
we
are,
you
know,
compatible
in
our
two
notions
of
like
what
this
namespace
is
and
again
every
implementation.
E
J
N
Happy
to
do
that
I
mean
really
like
my
the
only
reason
I
brought
this
up
was
that
it
seems.
Like
you
know,
one
of
the
high-level
goals
for
taps
is
to
create
a
better
interface
than
than
sockets
for
for
developers,
and
one
of
the
things
that
is
helpful
to
an
interface
is
consistency
across
implementations
right,
so
I'm
just
concerned
about
I'm
concerned
about
a
free-for-all
where
a
property
means
one
thing
on
one
implementation
and
the
totally
different
thing
on
another
implementation,
and
that's
not
that's
not
apparent
to
the
developer.
N
So
if
we
could
just
avoid
that
situation,
so
it's
really
it's
really
more
about
collisions,
and
it
you
know,
because
these
things
don't
translate
directly
into
code
points.
You
don't
end
up
with
that
kind
of
Interop
problem,
but
you
might
end
up
with
with
somebody.
You
know
like
translating
code
from
one
implementation
to
another,
and
you
know
assuming
that
that
a
property
means
one
thing
in
in
the
other
implementation.
When
it
doesn't,
then
is
that's.
E
I
Experience
with
IP
fix
would
actually
try
to
use
both
a
registry
and
a
first-come,
first-serve
a
way
to
get
namespaces
in
that
registry
to
try
and
avoid
exactly
this
problem.
It
doesn't
actually
avoid
the
problem
right
like
so.
Even
if
you
have
a
registry,
you
are
still
going
to
end
up
with
implementations
that
are
trying
to
have
portable
identifiers
that
you
so
that
you
can
like
reduce
the
amount
of
work
you
have
to
do
when
you
move
from
one
to
the
other
and
they're
gonna.
I
Get
it
wrong,
so,
like
registry
doesn't
actually
help
you,
but
it
helps
you
a
little
bit,
but
it
actually
then
gives
you
the
false
sense
of
security,
of
having
things
that
have
the
same
string.
That
should
be
the
same
thing
and
they're
like
80%
the
same
thing,
but
then
it
goes
into
production
and
you
have
to
debug
stuff.
G
J
D
D
E
Is
actually
fairly
elephant
for
this,
so
on
our
end,
our
invitation
we've
been
trying
to
flesh
out
our
multicast
implementation,
and
we've
also
had
we're
thinking
about
things
that
are
similar
to
multicast
that
are
not
necessarily
IP
multicast,
but
like
sessions
that
you
would
do
for
like
sending
information
when
you're
on
some
type
of
a
group
chat
like
this,
which
has
a
very
similar
flavor
to
multicast,
but
they
just
think
about.
What's
the
right
API
shape,
so
I
was
just
looking
for
like
what
do
we
currently
have
as
our
status
quo
and
the
document.
E
What
we
say
about
multicast
in
the
API
document
is
this:
essentially
you
create
your
pre
connection,
with
only
the
local
endpoint
specified
generally,
if
you
want
to
do
for
a
specific,
you
specify
the
remote
endpoint,
so
I
assume
you
just
call
like
initiate
with
this
pre
connection,
it's
never
quite
spelled
out
and
that
calling
initiate
would
cause
you
to
join
a
multicast
group.
If
your
local
endpoint
was
multicast
and
kind
of
do
all
the
right
things.
I
recall.
E
That's
good
so
I
mean
I
think
it
works,
so
you
have
a
connection
with
only
local
endpoint,
it
kind
of
seems
like
especially
if
you
don't
specify
the
remote
endpoint.
It's
really
a
receive
only
thing:
it's
it's
at
the
sink
that
we
had
back
in
post
sockets
and
if
I
want
to
send
a
reply
to
someone
so
like
if
I'm
implementing
you
know,
we
use
multicast
for
our
end
DNS
daemon
right.
So
I'm
doing
I'm
implementing
bonjour
for
service
discovery
right
now.
E
E
E
R
E
Weird
because
you
also
like
just
initiate
your
send
twos
their
like
it's
not
only
for
replying
necessarily
and
conceptually
if
people
are
thinking
about
like
I
want
to
have
this
thing.
That's
joining
the
group,
that's
how
I've
in
my
local
IP,
multicast
group
or
some
broader
group
and
interact
with
the
people
in
the
group
as
a
whole
or
one-to-one
within
that
maybe
responders,
not
the
right
concept.
So
responder
is
useful
for
multicast
they're,
also
good
at
just
doing
generic
message.
Multiplexing
responses.
E
Is
here's
what
if
we
make
groups
I,
have
the
option
to
have
them
be
concrete
and
allows
them
to
essentially
take
on
what
responder
did
so
currently
connection
group
is
an
abstract
thing
that
you
can
clone
within
to
get
multiple
streams
between
two
unicast
influence.
That's
great
I!
Think
for
that
use
case.
It's
fine.
Sometimes,
though,
a
server
particularly
I
want
a
stronger
notion
of
that
group,
because
I
want
to
be
able
to
have
lightweight
replies
to
my
HTTP
messages
that
come
in
for
my
different
streams,
and
so
you
could
view
it
as
like.
E
Sorry,
my
computer,
to
something
weird,
you
could
essentially
just
have
this
explicit
connection
group
and
you
could
also
monitor
the
state
of
your
overall
like
quick
stream
thing
or
your
group
state,
and
similarly
for
like
a
multicast
thing,
if
I
could
have
an
explicit
connection
group
that
was,
this
is
representing
my
binding
to
this
particular
port.
Joining
this
multicast
group
and
all
of
the
things
I
can
reply
to
the
people
who
contact
me
over
multicast.
Then
I
have
one
object,
that's
very
useful
for
this.
So
that's
where
we
ended
up.
E
F
R
F
My
my
straight
absolution
for
that
problem
would
be
that
an
endpoint
in
after
multiple
IP
addresses,
which
I
think
is
something
that
might
be
useful
anyway.
If
you
want
to
assign
multiple
IP
addresses,
ipv6
addresses,
for
example,
for
to
the
same
end
point
and
like
somehow
very
eight
using
them
for
some
kind
of
thing
that
you
call
a
connection.
E
So
as
an
example,
I
should
have
given
this
on
the
slides,
though
the
way
that
I
would
use
this
for
multicast
would
be
I
would
have
essentially
a
cap
reconnection
for
a
connection.
Group
I
would
explicitly
list
multiple,
potentially
local
endpoints
of
the
groups.
I
want
to
join
and
like
the
port,
I
want
to
join,
and
this
is
like
a
special
local
endpoint
for
a
group.
I
create
my
group
to
that.
E
It
joins
that
for
me,
I'm
able
to
now
receive
messages
that
are
sent
to
me
on
this
I
can
either
reply
to
them
or
I
can
say.
Oh
I
got
this
message.
A
message
from
you:
I
want
to
kind
of
upgrade
this
into
a
full
long-lived
connection.
That
I
can
do
more
like
flow
control
on
and
have
a
longer
session
with
you,
and
it
just
picks
the
right
local
address
or
me
out
of
the
ones
I
can
send
to
you
back
on.
E
F
I'm
a
little
bit
concerned
that
we're
actually
overloading
in
Tehran,
which
should
be
separate,
because
the
whole
point
about
a
connection
group
for
me
was
that
you
can
actually
use
some
of
different
streams
on
exactly
the
same
connection
right.
It's
just
like
Oh
back
to
you.
If
it's
the
same
connection
or
not,
so
that's
why
it's
a
connection
group.
While
here
you
actually
have
to
have
kind
of
different
connection
in
some
sense,
because
you're
actually
talking
to
different
entities.
E
D
E
F
Big
difference
is
between
those
pictures
of
it.
In
one
case,
you
have
X
to
be
one
endpoint
you're
talking
to
it
might
be
different
applications
using
the
connection
or
whatever,
but
it's
always
one
endpoint.
In
the
other
case,
it's
like
it's
a
number
of
points
where
you
actually
don't
even
know
who
you're
talking
to
and
I
think
that's
a
very
big
different
that
like
I,
should
not
mix
up
and
one
should
actually
try
to
separately.
F
P
C
E
But
there's
a
that
might
no
I
P
multicast,
like
the
way
that
that's
implemented
is
that
yeah
today,
I
just
have
to
send
one
message
in
my
router
replace
it
for
me.
But
if
I'm
doing
like
kind
of
like
a
multicast
over
a
wide
area
thing
maybe
I
do
under
the
covers.
My
implementation
has
to
do
its
own
fan-out,
which
is
effectively
just
alias
for
a
group
of
connections
that
I'm
sending
the
same
thing
wrong.
Can.
I
I
It
does
exactly
what
you're
saying
here
like
there's
the
you
know
the
magical
mapping
of
the
message
and
it
figures
out
how
to
hand
that
message
back,
just
like
you'd
use
send
to
and
with
a
current
and
the
current
pattern,
the
UDP
it
figured
out
how
to
send
it
back
in
a
unicast
situation
you
this
is
still
useful
as
a
responder
group
on
a
server,
because
then
it's
like
here's
the
thing
I'm
listening
to
I,
don't
actually
give
a
about
the
connections.
You
manage.
I
The
underlying
connections
for
me
and
I
just
want
it's
like
you
gave
me
a
thing:
I
fork
the
thread.
The
thread
came
back
and
here's
the
thing
from
different,
your
particular
implementation.
A
responder
group
is
probably
a
say,
subclass
of
a
connection
group.
That
is
a
that's
a
very
common
way
to
implement
it.
But
I.
Don't
think
we
want
to
take
that
implementation
detail
and
put
it
in
the
interface,
but
I
do
think
that
I
think
the
problem
that
we
have
is
real
I
mean.
Obviously
you
ran
into
it.
I
I
think
the
way
to
do
it
right
now
in
the
interface
doc,
it's
clunky
as
hell.
It
will
actually
cause
people
to
say:
okay,
well,
I'm
gonna,
create
you
know,
a
bunch
of
connections
that
are
heavier
weight
than
I
think
they
are
to
model
this
thing.
That
would
be
very
simple
but
like
if
you're
just
implementing
this
on
top
of
sockets.
You
have
like
all
of
this
metadata
that
you
don't
need
ever
I.
F
F
F
I
F
K
J
I
C
C
E
K
C
D
Gonna
jump
in
here
we're
at
the
end
of
our
time,
and
this
seems
like
a
topic
that
would
benefit
from
more
discussion,
probably
motivated
by
some
text.
So
I
think
that
next
thing
is
for
Tommy
to
write
something,
and
then
we
can
talk
about
it.
A
little
more
detail.
I
am
I,
think
it's
a
sign
of
progress
for
the
taps,
working
group
that
we
actually
got
to
a
place
where
we
were
able
to
talk
about
multicast
at
all.
B
F
D
This
discussion,
I've,
got
I,
think
three
more
hours
of
teleconferences,
so
I've
got
to
move
on
to
my
next.
One
can
I
just
see
a
well
I
guess
not
anybody's
doing
video,
but
any
objections
to
scheduling
another
to
our
interim
at
this
time,
roughly
a
month
from
now
and
I'll
do
a
doodle
to
pick
the
problem
with
that
I
think
it's
unnecessary
I
think
it's
necessary,
I,
think
I'm,
good
progress,
I'm
really
happy
with
the
progress
of
group,
is
making
these
in
terms
have
worked
out.
I
think
they've
been
super
effective.