►
From YouTube: IETF-TAPS-20210922-1500
Description
TAPS meeting session at IETF
2021/09/22 1500
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
B
B
C
A
C
D
A
A
F
G
G
K
B
B
L
D
A
A
Of
a
sort
of
a
linear
agenda
presentations
at
the
meeting-
and
so
the
kind
of
the
way
we've
been
using
webex
for
the
interims
is
a
little
bit
different.
It's
cool,
although
it
doesn't.
Oh,
I
see
the
names
you
have
to
hover
to
see
the
names
for
the
pictures.
That's
I
think
the
video
quality
is
really
good.
I'm
impressed
now,
of
course,
we're
going
to
push
to
do
this
all
and
gather
right.
So
we
got
to
make
our
avatars
and
you
know
everybody
get
their
exit
skills
going.
L
C
B
H
M
K
K
So,
let's
see
probably
the
best
way
to
show
you
is
just
to
this
is
a
this
is
a
sample
program.
I
wrote
this
is
just
an
an
echo
server,
so
you
you
know
you
telling
it
into
it
and
you
you
type
stuff,
and
it
sends
it
back
to
you.
It's
a
very
common
toy
program.
Of
course,
just
give
you
a
sense
of
what
a
program
would
look
like
using
this
interface.
K
So
that's
what
you
see
here,
so
here's
the
one
when
you
get
a
new
connection
from
a
listener.
It
then
you
know,
initiates
a
receive
and
then
the
other
one
interesting
is
see.
When
we
receive
some
data
it
will,
then
you
can
see
there
in
line
119.
It
sends
that
and
then
it
starts
receiving
it
again.
So
you
guys
obviously
remember
the
interface,
that's
what
it
looks
like
and
then
the
main
program
is
here:
it
initializes
an
endpoint.
K
It
sets
some
transport
properties
and
then,
let's
see,
then
it
frees
all
the
preconnection
stuff.
It
doesn't
need
it
anymore
and
then
just
sits
around
and
waits
until
you
terminate
the
program
like
most
listeners,
so
I've
already
compiled
that,
and
so,
if
you
just
run
the
program,
there's
a
ton
of
debugging
here,
which
you
guys
might
find
somewhat
interesting.
K
And
so
now,
if
I
do
stuff,
it
echoes
it
and
I'm
putting
in
a
ton
of
so
you
can
see
sort
of
the
bugging
stack
here,
see
what
you
can
see
and
this
kind
of
ties
into
transport
discovery
stuff,
there's
a
this
is
sort
of
the
protocol
level
and
then
there's
a
tax
level,
and
I
don't
actually
print
out
function,
traces
for
the
oh
there.
It
is
no.
I
do
actually
my
mistake
so
then,
of
course,
there's
the
the
application
level.
K
K
K
Okay,
so
now
the
on
the
transport
discovery
side,
what
I've
done
is
essentially
written
a
wrapper
for
tcp
sockets,
and
you
can
think
of
that
as
a
prototype
for
how
anywhere
these
wrappers
would
work.
You
could
also
have
a
native
protocol
implementation.
It
did
the
tap
stuff,
but
in
the
near
term,
we'll
probably
be
doing
these
wrappers
and
part
of
what
this
thing
does.
Is
it's
got,
and
then,
if
there
was
an
installer
would
create
a
yaml
file
that
that
looks
exactly
like
this.
K
The
udp
code
doesn't
actually
exist
yet
so
so,
if
you
ask
those
properties,
things
will
go
very
badly,
but
essentially
it's
describing.
What
is
the
protocol?
What
property
does
it
provide,
and
where
can
I
find
the
dynamic
library
for
this,
this
library
for
that
protocol
and
so
taps
will
then
read
that
in
and
then.
K
And
then
this
is
the
actual
implement.
This
is
the
actual
wrapper
of
tcp
sockets
that
that
handles
all
that.
So
you
know,
I
would
say
the
only
thing
I'd
say
about
this
implementation.
It
doesn't
make
an
effort
to
be
portable
and
scalable
like
it
does
use
lib
event,
which
is
I
understand
it
if
I'm
not
an
expert
on
a
live
event,
but
it's
a
relatively
portable
means
of
eventing.
K
If
you
want
to
use
them,
for
you
know
zero
copy,
and
that
kind
of
thing,
so
it
there's
a
lot
of
stubs.
There's
a
lot
there's
a
lot.
It
hasn't
been
done
for
sure
on
both
ends,
in
particular
the
one
piece,
the
architecture
that
is
really
missing
is
there
should
be
a
taps
d
that
is
reading
these
yaml
files
and
loading
all
the
protocol,
information
into
shared
memory,
and
but
right
now,
I'm
doing
it
on
the
pre-connection,
which
is
probably
not
the
best
thing
to
do.
K
Computationally,
that's
probably
the
biggest
architectural
piece
that
is
missing,
but
other
than
that.
All
of
all
the
pieces
are
here,
really
needs
to
be
enriched.
So
certainly
I
would
welcome
really
anything
at
this
point
from
like
you
know,
your
your
syntax
is
all
wrong
and
you
should
use
a
different
different
thing
there
to
to
like
code
contributions
or
or
feature
ads
or
bug
fixes,
etc.
So
that's
that
I'm
happy
to
take
any
questions
about
this.
A
K
K
So
I
I
I
stubbed
that
I
kind
of
commented
out
a
lot
of
that
just
built
the
listener
just
so
there
would
be
something
so
right
now.
It
is
actually
it's
going
through
the
list
of
protocols
which
is
pretty
small,
but
all
the
stuff
exists
to
like
look
at
the
properties
that
are
requested,
look
to
the
properties
that
are
presented
and
then
kind
of
take
a
score
for
that,
and
then
it's
ignoring
that
score
and
just
picking
the
first
one
right
now,
but
there's
some
stuff
there.
K
I
think,
ultimately,
this
this
taps
d
thing.
One
reason
it
should
be
a
damon
is
that's
where
all
the
security
stuff
would
live
to
verify
that
these
things
work,
you
could
even
sort
of
test
the
library
output
at
a
maximum
and
like
verify
the
claims
of
the
protocol.
That
would
be
a
useful
thing
that
I've
not
even
started
to
think
about
coding,
but
it
would
be
a
neat
thing
to
do.
Does
that
answer
your
question.
K
So
there
are
some
hooks
for
racing.
It
does
not
currently
race.
The
thing
that
is
most
developed
in
this
code
is
an
effort
to
sort
of
score.
The
various
implementations
against
the
requested
properties.
A
lot
of
that
machinery
is
there
it's
currently
being
ignored,
but
that
is
there
and
yeah
I
mean
the
intent
is
eventually
implement
racing,
but
it's
it's
not.
That
doesn't
really
exist
right
now.
N
K
G
K
So
it
is
not
so
much
that
we
are
pushing
a
particular
application
as
just
the
the
idea
that
this
would
be
present
that
if
this
was
attractive
enough
to
exist
on
most
linux
boxes,
that
would
be
good
for
us.
I
could
look
at
something
like
engine
x,
but
that
is
very
complicated
and
I
don't
I
don't
think
we're
ready
at
this
point
to
to
to
go
there,
but
that
that
actually
good
advice,
and
once
this
is
in
a
little
bit
more
a
little
bit
less
a
rickety.
C
G
Because
quickly,
just
like
hands
out
the
socket,
so
if
you
can
deal
with
like
the
tap
side
of
things,
so
you
could.
You
could
probably
look
at
some
of
the
quick
implementations
and
see
I
mean
there's
like
five
or
six.
You
could
probably
do
a
quick
survey
and
figure
out
which
one
is
the
thinnest,
but
you
need
to
implement
the
udp
stuff.
First.
L
A
K
K
Steering
directions
are
welcome
and
I
think,
there's
a
longer
term
term
goal.
Tom's
suggestion
of
having
a
target
application
real
application
is,
is
quite
attractive.
Regarding
quick
implementations,
I'm
not
really
100
sure
if
people
are
suggesting
that
we
run
the
quick
application
on
top
of
this
or
we
put
it
underneath
we
built
a
wrapper
for
it
to
be
a
a
like.
An
available
protocol.
K
K
A
K
Yeah,
so
actually
you
raised
that
ua
is
kind
of
like
the
third
thing
that
was
out
of
this
was
kind
of
an
effort
to
implement
the
docs
as
they
are
from
from
scratch.
I
mostly
use
the
api
draft,
the
the
interface
draft,
that
was
by
far
the
most
useful
to
me.
The
implementation
draft
was
most
useful
for
trying
to
figure
out
all
the
pre-connection
and
racing
stuff,
at
least
that's
where
I
went
to
try
to
figure
out
how
to
do
it.
K
K
N
K
I
didn't
appreciate
that
until
I
read
the
thing
really
carefully,
it
kind
of
worked
out
the
problem
code
so
that
yeah
there
were
a
couple
of
issues
filed
in
that
in
that
space,
that
was
kind
of
the
main
thing
and
I've
been
I've
been
still.
I've
actually
still
wrestled
a
little
bit
with
like
the
notion
of
adapting
tcp
to
this
notion
of
the
like
the
message
construct
in
in
taps
and
there's
not
like.
K
K
Although
I
haven't
completely
implemented
a
lot
of
eom
stuff
and
all
that,
because
it's
not
really
necessary
for
what
I
have,
but
it's
not
like
100
clear
how
those
things
map
and-
and
I
think
I
understand
now
where
like
there's
a
message-
context
which
is
constant
but
that
the
like
the
actual
buffer,
the
message
data
changes,
each
receive
partial,
that's
still
very
kind
of
not
clean
and-
and
I'm
not
100
sure
how
I'm
going
to
do
that
properly.
Once
once,
the
machinery
exists.
C
K
Yeah
so
like
there
are
many
reasons
for
doing
it.
In
c
I
you
know,
our
data
plane
is
in
c,
and
so
I'm
used
to
trying
to
pound
object,
oriented
pegs
into
into
into
non-objective
holes,
but
I
mean
yeah
so
like
obviously
it's
kind
of
like
the
the
base
thing
to
have
it's
sort
of
like
the
most
fundamental
thing
to
do.
It
allows
you
know,
there's
some
performance
advantages.
Of
course
you
can
always
build
stuff,
on
top
of
it,
that's
a
little
less,
a
little
more
user-friendly
and
then.
A
K
Yeah
well,
like
I
mean
there's
some
issues,
there's
some
obvious
things
to
do
like
there's
some.
I
would
like
to
have
well
right
now
it
like
you
can
actually
break
it
pretty
easily
by
like
it'll
pick
udp
and
he's
not
there
and
stuff
like
that.
So
I
want
to
make
it
like
not
break
like
eliminate
those
sorts
of
rough
edges.
Fill
in
like
allow
you
a
lot.
You
know
let
people
initiate
connections
that
kind
of
basic
thing,
and
you
know,
there's
there's
a
lot
of
directions.
K
K
A
A
B
B
C
Yeah
I
was
I
was
I
looked
at
the
review
and
there's
very
little
of
that-
that
I
don't
think
we
have
to
address
with
basically
actually
either
texting
the
document
to
clarify
things
or
going
back
and
thinking
about
stuff.
So
it
will
be
like
it's
kind
of
annoying,
because
it's
a
lot
of
work.
We're
about
to
hit
issue
number
one
thousand
on
these
on
these
documents.
C
So
I'm
not
sure
what
the
the
most
productive
way
to
do.
This
is
because
I
have
also
like
beyond
looking
at
the
thing
and
going
that's
a
long
email,
and
then
you
know
just
skimming
it
to
see
what
you
know
if
there
was
actually
going
to
be
work
out
of
this,
I
have
not
had
a
chance
to
really
do
anything
since
the
last
interim
you'll
see.
I
still
have
a
few
things
that
are
assigned
to
me
that
have
that
I
haven't
done
yet.
Oh
wait.
C
I
do
have
at
least
well
back
in
february.
I
do
have
at
least
one
pr,
so
I
would
say,
let's
probably
go
to
the
pr's
first
get
those
merged
and
then
spend
a
little
bit
of
time.
Signing
tommy
up
to
do
all
of
the
changes
that
robert
asked
for,
or
at
least
figure
out
who's
the
right
person
to
do
some
of
these
things
right.
J
J
L
C
Think
that's
good
cool
by
the
way.
This
is
awesome.
You
can
actually
tell
meat
echo
just
to
share
a
window,
so
this
is
like
yet
another
vote
for
continuing
in
meet
echo.
I
think
kyle's
855
were
probably
going.
You
know
increasing
consistency
of
formatting
spelling.
I
think
that
one
is
going
to
go
into
merge
conflict
hell
soon.
We
should
possibly
restart
that
one.
Let's
look
multicast
example
code
corey
looked
at
it,
tommy
fixed
it.
C
D
L
L
J
J
C
There
are
a
few
non-editorial
issues
on
architecture,
and
it
seems
like
at
least
one
of
these
or
the
separation
of
architecture
and
interface
documents.
One
is,
it
seems
like
we
should
have
the
opinion
as
a
working
group,
so
I
would
say
we
start
with
the
art
art
review
architecture
like
everything
up
to
this
already
has
someone
assigned
to
it.
At
least
I
would
maybe
start
with
8.79
the
ones
that
are
not
marked
editorial
and
start
either
discussion
or
triage
out
to
people.
Does
that
sound
like
a
good
way
to
go.
N
O
C
Right
like
so,
I
I
think,
that's
that's
the
ask
is
go
through
here
and
say:
okay,
the
normative
thing
is
the
api
and
architecture.
Just
basically
gives
you
an
introduction
to
the
concepts
to
understand
how
the
api
works,
which
is
not
what
we
set
out
to
do,
but
I
think
that
one
of
the
reasons
that
it
wasn't
what
we
set
up,
I
think
there
are
two
reasons
that
surprise
and
whatever
are
our
weapons.
C
The
architecture
might
have
independent
in
a
world
where
we
didn't
get
all
the
way
to
finishing
the
api
dock,
which
is
not
the
world
we
live
in.
The
architecture
might
have
had
independent
utility
right
in
terms
of
like
influencing
people
to
shape
their
apis.
Like
this,
because
I
mean
the
charter
basically
said
hey,
we
can
do
some
api
work
in
order
to
to
experiment
with
these
concepts,
but
not
necessarily,
you
know
to
define
the
future
interface
to
the
transport
layer.
I
think
we
got
farther
than
that
right.
C
The
second
reason
to
do
that
is
that
we
wanted
to
finish
the
architecture
document
first
and
say
these
are
the
things
that
we
agree
with
and
basically,
if
we
end
up
making
changes
to
the
api
dock
that
don't
fit
into
that
architecture.
Well,
we
shouldn't
do
that
and
that's
not
actually
how
we've
ended
up
working.
The
way
that
we've
ended
up
working
is
we've
now
gotten
to
the
point
where
most
of
the
concepts
are
being
built
in
the
api
dock
first
and
then
back
ported
to
architecture.
C
If
architecture
is
disagrees
with
it
right,
it's
like
it's,
okay!
Well,
if
the
api
says
this,
the
api
is
what
we
want.
Therefore,
the
architecture
should
bend
to
the
api.
We
haven't
done
much
of
this,
but
like
a
little
bit
like
the
last
one,
was
connection
grouping,
we
had
to
go
back
and
rephrase
connection
grouping
in
the
architecture,
so
I
can
absolutely
see
why
you
know
robert
coming
to
this.
C
With
you
know
a
background
and
a
whole
lot
of
you
know
the
internet,
but
coming
to
this
document
for
the
first
time
might
think
that
this
looks
weird
right
because,
like
this
separation
between
architecture
and
api,
is
I'm
going
to
say
obsolete,
but
it's
certainly
historical.
It
certainly
reflects
the
state
of
these
documents
a
long
time
ago.
C
L
C
L
L
A
A
J
J
C
C
C
M
Okay,
then,
I
turn
up
the
level
a
little
bit
better.
Yes,
that
helps
so,
I
think
for
two:
we
can't
move
into
the
implementation,
because
it's
really
the
background
on
how
we
think
about
racing
and
how
we
look
at
in
into
the
general
concept,
how
everything
falls
together
so
about
for
one
moving
to
api.
This
could
be
done,
but
then
I
think.
J
F
M
C
He's
right
that
this
document
is
basically
is
the
way
that
it
is
because
of
the
process
that
we
use
to
get
to
it.
But
if
we
take
a
pretty
hard
edit
pass
at
arch
and
say,
okay,
we're
going
to
make
this
an
overview
introduction
in
principles
right
like
so,
and
you
can
even
keep
the
you
know
the
short
name
of
the
document
and
call
it
sorry.
F
C
J
J
J
D
D
C
F
D
Now
I
mean,
I
think
I
I'm
thinking
like
this,
I
mean.
Obviously
we
are
pretty
expert
on
doing
things
and
taps
right
now,
but
I
mean
these
documents
should
also
tell
us
more
about.
Like
I
mean
it
does
tell
us
about
the
how
taps
works
and
how
things
are
expected
and
things.
Obviously
it
puts
some
requirements
on
the
rest
of
the
things
that
we
do,
but
it
is
a
good
intro
so
to
say
not
yet
aim
for
it,
but
it
does
keep
some.
K
K
C
Lean
into
this
document
being
published
as
the
hey,
you
would
like
to
understand
enough
about
taps
to
write
slider
about
it
right,
which
is
actually
an
important
thing,
for
you
know
early
adoption
of
an
effort
to
implement
something
like
this.
We
turn
that
into
this
document,
and
then
it's
basically,
you
know
we
rename
it
to
an
introduction
to
the
transport
services
architecture.
C
C
There's
a
this
is
less
work
way
to
to
address
this
right,
which
fixes
my
I
don't
want
a
problem
where
we
basically
then
do
a
pass
over
this
document
and
say:
okay,
we're
gonna,
we're
gonna,
make
sure
this
document
is
useful
as
an
introduction
to
the
architecture.
Does
that
seem
reason
a
reasonable
thing
to
put
time
into.
O
D
A
D
M
M
B
C
B
C
A
A
I
C
C
O
A
J
J
L
C
So
one
way
to
fix
this
in
the
api
would
be
to
to
get
rid
of
all
of
our
types
right,
which
I
think
yeah,
which
would
cause
implementers
to
have
exactly
the
look
that
martin
has
on
his
face
right
now.
So
we
probably
shouldn't
do
that.
I
don't
know
I
I
don't
know
if
you're
following
him,
a
look
came
across
your
face
was
like
get
rid
of
types
you're
like,
so
we
probably
shouldn't
do
that.
The.
I
J
I
mean
there
were
a
couple
of
cases
where
I
probably
had
something
like
minus
one.
There's
an
error.
A
card
rightly
complained
that
this
is
very
c
yeah,
and
so
we
said:
okay,
there
are
these
special
defined
error
values
because
still
it's
an
integer
otherwise,
so
that
is
ugly,
I
mean
well
special
yeah,
I
mean
I.
I
J
C
A
C
J
B
J
J
L
C
J
L
We
can
do
it
like
that
or
we
can
do
the
the
way
you
do
it
in
a
typed
language
and
say
actually
it's
it's
an
enumeration
of
this
type
or
this
type
and
put
a
note
in
the
introduction
that
says
we
use
this
type
and
if,
if
you're
implementing
it
in
c,
it
probably
turns
into
a
magic
error
code,
but
you
wanna
name.
It.
C
I
would
use
the
I
would
use
a
type
enumeration
instead,
it's
ugly
but
like
there
would
then
be
maybe
guidance
in
implementation
that
hey,
if
you're
doing
this
in
a
language
that
doesn't
use
type
enumerations,
then
do
something
like
from
a
type
theoretic
standpoint.
This
is
actually
a
type
of
numeration.
J
M
J
I
C
M
C
C
All
these
blue
cycles
yeah,
but
it's
going
to
be
like
one
pr,
that's
going
to
close
yeah
five
issues,
so
it's
gonna,
be
it's
gonna,
be
super
satisfying
to
land
that
one
that
is
wrong.
It's
going
to
remove
many
small
things,
transport
property
names
in
4.1.
I
think
you
need
to
be
more
specific
than
alphanumeric.
I
don't.
J
N
M
C
I
mean
we
do
specify
already
in
the
api
dock
that,
like
hey,
you
should
make
this
look
like
you
know.
You
know
you
should
make
this
look
like
your
language,
because
otherwise
people
are
going
to
be
like.
Oh,
this
is
some
weird
java
stuff.
I
don't
want
that
or
this
is
some
weird
python
stuff.
I
don't
want
that.
L
C
L
L
J
So
I
I
I
like
having
the
same
names
for
things
actually,
so
I'm
not
such
a
fan
of
honda
spy
on
the
specifying,
because
then
you
know
I
imagine
to
two
implementers
talking
to
each
other
and
they
can
talk
about
things
like
the
capacity
profile
and
the
parameter
called
something
and
property
called
something
it's
the
same
name,
so
I
think
I
mean
without
having
to
go
into
capitalization
or
underscore
or
whatever,
but
at
least
having
the
same
names
for
things
I
mean
that
right.
You
know,
that
is
that
that
has
value.
C
Right
all
of
these,
and
each
of
these
translation
things
even
in
a
world
where
people
are
not
being
100
consistent.
These
are
these
are
regular
expressions
that
will
parse
down
into
a
finite
state
automaton
that
can
fit
into
a
tiny
amount
of
silicon
right
like
so.
It's
like
right,
using
reg
x's
to
bash
from
one
one
context
into
another,
is
like
maybe
not
super
pretty,
but
it's
I'd
hazard,
a
guess
that
it's
been
at
least
15
of
everyone's
job
in
this
room.
At
some
point,
it's
computers.
C
What
we
do
I'm
a
fan
of
underspecifying
here,
but
I
understand
that,
like
that,
like
underspecifying,
makes
certain
people
twitchy,
including
probably
robert,
actually
our
art,
art
reviewer.
But
I
say
I
would
leave
this
up
to
michael
as
a
as
a
how
much
time
he
wants
to
spend
on
it.
Executive
decision.
C
C
F
C
It
could
be,
there
might
be
some
application
level
semantics
that
you
know
when
you're
setting
up
all
of
these
these
remote
endpoints.
You
know
that
they're
the
same
there
might
be
multiple
front
ends
like
transport
front
ends
that
will
go
to
the
same
application
back
end
right
right.
The
point
we
want
to
make
here
is
like
you,
shouldn't
have
two
remote
endpoints,
one
of
which
is
a
web
server
and
one
of
which
is
a
mail
server,
because
then
you're
going
to
have
a
bad
day,
yeah.
O
C
M
L
L
I
J
B
O
C
Well,
I
mean
the
point
is
the
point
that
robert
is
making
here:
is
that
it's
inconsistent
right
like
if
you
can
have
a
name
and
an
ip
address?
Well,
what
do
you
do
with
that?
If
the
name
resolves
to
something
other
than
the
ip
address
right,
and
I
think
this
is
one
of
those
things
where
underspecified
ambiguity
is
probably
okay
and
like.
Given
that
there's
not
much
clarity
on
this
sentence,
we
can
just
delete
it.
I
think
that's
the
right
thing
to
do
so.
C
L
C
J
M
M
So
if
you're
implementing
stuff
like
link
local
or
multicast,
you
really
have
to
specify
the
interface
as
especially
firefighter
with
system
local.
You
need
that
yeah!
Well,
you
can
do
that
as
a
property
on
the
pre-connection
right.
It's
just
a
syntactical
thing,
but
that's
weird
having
having
a
linked
local
address
on
the
on
the
end
point
and
then
specify
the
interface
on
a
pre-connection
is
weird.
H
C
K
C
C
You
might
want
to
have
in
your
application
a
different
user
interface
for
the
endpoint
specification,
as
opposed
to
the
user
interface
for
the
for
the
transport
property
specification.
You
might
not
even
bubble
up
the
transport
property
specification
to
the
user,
whereas
the
the
endpoint
you
would
bubble
up
to
the
user
right.
C
K
C
K
C
M
C
M
C
Well,
so
there's
there's
a
there's
like
martin
raises
a
really
good
issue.
Let's
say
that
your
transport
properties,
which
have
not
bubbled
up
the
ui,
have
even
just
a
non-uh
enumerated
list
of
interface
identifiers.
They
just
have
like
so
some
interface
properties
and
then
you
hand
a
local
specifier
to
the
same
free
connection
that
has
a
set
of
interfaces
that
do
not
meet
those
properties
boom.
You
can't
connect
yeah
right.
C
K
I
mean
like
when
you
do
this
you're
going
to
have
you're
going
to
create
an
endpoint
you're,
going
to
create
transport,
transport
properties
and
you're
going
to
build
all
that
stuff.
I
mean
you
could
almost
have
it
be
one
giant
blob
in
principle,
although
yeah
I
mean
I,
I
really.
I
really
feel
strongly.
There
should
be
one,
and
I
don't
have
a
strong
opinion
about
the
like,
which
one
it
is
did
the
only
real
like
practical
difference
is
with
the
pre-connection.
K
C
C
N
B
C
J
L
D
C
L
C
L
C
I
J
C
B
B
C
D
D
I
I
wanted
to
disgrace
this
question
because
we
have.
We
have
some
issues
with
this
github
review
process
and
I
was
one
of
the
thing
like
when
I
was
really
reviewing
giving
comments
to
http
documents.
They
actually
discussed
it,
they
closed
this
one
and
then
I
was
in
a
position
not
to
get
engaged.
So
the
question
here
is
basically
I'm
asking:
if
you're
taking
these
issues
or
from
the
review
command
is
creating
issues,
will
you
be
are?
Are
we
going
to
involve
the
reviewer
in
that
process?
D
Saying
like
saying
like
you
can
come
and
chat
with
us
at
github
many
author
reviewer
might
not
do
that
or
might
do
that,
but
at
least
we
need
to
update
them.
With
this
information
like
here,
I
have
created
issues
and
here
you
can
engage
and
if
that
doesn't
engage
then
basically
you
will
resolve
these
things
and
basically
send
another
note
like
here
what
we
have
done
so.
J
A
A
A
L
J
J
A
If
teresa
is
going
to
send
a
if
teresa
is
going
to
send
a
message
to
him
thanking
him,
we
can
just
add
a
note
onto
the
message
that
says
you
know
we
welcome
your
involvement
in
the
resolution
of
these
they're
all
logged
in
our
issue.
Tracker,
and
you
know
you
can
be
as
involved
as
you
want
to
be
in
subsequent
discussion,
and
you
know
I
think
that
that's
you
know
we,
I
I
it's
a
good
point.
A
D
A
D
E
B
Yeah,
so
I
I
have
done
a
couple
of
reviews
on
documents
where
people
have
added
me
as
a
reviewer
to
the
pr
that
is
supposed
to
resolve
that
issue,
and
then
I
can
give
feedback
on
the
github
or
I
can
just
reply
through
the
email
saying
yeah.
It
looks
good
and
I
really
I
thought
that
was
really
useful,
especially
for
a
long
and
sort
of
documents
with
a
lot
of.
B
C
D
That
would
be
great,
I
mean
also
like
going
forward
when
you
will
have
this
sort
of
like
itf
review
or
icdb.
We
can
follow
the
same
procedure.
Basically,
this
problem
here
is
like
some
time
we
do.
We
have
some
reviews
and
I
don't
I
don't
use
github
and
then
basically
there's
a
different
thing,
but
if
you
have
we
have
a
reviewer
on
the
github,
I
mean
that's
a
very
good
way
of
engaging
them.