►
From YouTube: MASQUE WG Interim Meeting, 2021-01-12
Description
MASQUE WG Interim Meeting, 2021-01-12
B
B
A
A
B
B
It's
just
a
note.
Well,
as
per
usual,
I
assume
you're
all
familiar
with
it,
but
if
not,
please
take
it.
Take
a
second
to
familiarize
yourself
with
it.
Just
a
you
know
reminder
to
at
least
be
respectful
and
courteous
when
speaking
and
when
discussing
things-
and
hopefully
this
can
be
a
super
productive
meeting
next
slide.
Please.
B
Here's
some
helpful
links
to
to
get
going
and
then
to
help
you
engage
during
the
meeting.
If
you
pull
open,
oh
shoot,
that
is
not
the
right
notes
link.
Actually
I
dropped
it
in
the
chat
here,
though.
So,
if
you
pop
in
over,
there
drop
your
name
on
the
list
or
if
there
is
a
spot
for
that,
I
made
a
spot
at
the
end.
Thank
you,
ecker
that'd
be
super
helpful.
B
B
B
Everyone
given
changes
that
have
happened
in
the
past
couple
of
months
and
we're
gonna
get
into
some
presentations
on
the
main
working
group
documents
and
some
auxiliary
documents
as
well
and
then
stuff
that
carried
over
from
idf
109
that
we
didn't
have
time
to
get
to
is
at
the
end,
and
if
we
have
time
to
get
to
them
this
time
we
will
otherwise
we
will.
We
will
punt
them
like
we
did
prior.
Does
anyone
have
any
adjustments
they'd
like
to
make
to
this
before
we
move
forward.
B
Then
right
so
just
a
quick
update
on
how
we're
using
github
and
how
documents
are
progressing
so
there's
been
like
a
flurry
of
activity
on
both
the
ipu
proxy
requirements
document
as
well
as
connect
udp.
So
thank
you
to
all
the
first
of
all
the
editors
as
well
as
all
the
participants
who
have
been
you
know,
checking
in
on
github
commenting
helping
move
these
forward
and
improve
them.
We've
observed
some
sort
of
misalignment
with
how
it's
the
tool
is
being
used.
B
B
H
All
right
yes,
so
this
was
clearly
directed
at
me,
which
is
totally
fair.
So
I
want
to
apologize
to
folks
here.
The
the
issue
here
was
only
a
matter
of
timing
where
the
chairs
asked
me
to
get
these
updates
the
documents
out
early
enough
that
folks
had
time
to
review
them
before
this
interim,
and
so
I
cut
quite
a
bit
of
corners
to
get
that
done
in
time.
So
I
don't
plan
on
doing
that.
Moving
forward.
I
will
like
be
better
about
using
pr's
and,
like
writing
resolution.
H
B
Yeah
that'd
be
clear,
I
don't
think
anyone's
pointing
fingers
and,
in
fact,
like
the
the
work
that
you
put
in
dig,
it
has
new
drafts
to
review
during
this
particular
meeting.
So
thank
you
for
the
time
that
you
did
spend
on
this
stuff.
Hopefully
like
this,
doesn't
come
off
as
like
adversarial
in
any
particular
way,
all
right
miriah.
I
guess.
G
Yes,
definitely
thanks
david.
I
I
wanted
to
say
that
one
problem
was
that
it
was
not
clear
how
issues
were
addressed
and
having
pull
requests
would
make
that
definitely
more
visible.
So
that's
really
good
the
other
problem
or
not
problem,
but
the
other
thing
is
also
that
I
think
we
shouldn't
just
like
close
an
issue
without
having
consensus,
so
it
has
to
be
more
than
one
person
who
agrees
that
the
issue
is
resolved
before
we
close
it.
I
think
that's
the
more
important
part.
G
So,
even
if
you
update
the
document
and
submit
put
the
prs
in
or
merge
the
pr's
and
then
submit
the
document,
please
keep
the
the
issues
open
until
there's
some
agreement.
I
think
that's
important
for
it
and
another
comment
I
wanted
to
make
is
also
that
currently
we
have
a
lot
of
issues
on
github
and
we
have
like
some
discussion
there.
It's
usually
only
like
a
small
set
of
people,
but
I
think
that
we're
at
an
early
stage
where
we
need
for
some
of
the
issues.
G
We
need
really
broader
discussion
in
the
working
group,
so
everything
that's
more
on
and
not
like
specific
protocol
or
editing.
The
document
basis,
but
more
an
architecture,
general
decision.
I
think
it
would
still
be
good
to
have
an
issue
but
then
also
bring
discussion
to
the
mailing
list
and
see
if
there's
further
feedback,
so
we
can
actually
reach
consensus.
G
Actually
give
me
an
exit,
and
let
me
give
you
an
example:
I
think
the
discussion
we
had
about
extendability
you
brought
to
the
list
as
it
shares
that
was
really
good,
because
that
was
a
really
like
high
level
design
issue
right.
It's
not
a
concrete
thing
where,
like
I
can
say,
you
know,
I
have
to
change
this
in
the
document
and
we're
still
at
this
stage
right.
E
Mike
yeah,
so
two
things
I
wanted
to
highlight.
First
off,
I've
kind
of
kind
of
feel,
like
closing
issues
when
the
prs
are
emerged,
is
probably
a
reasonable
thing
to
do,
because
we
shouldn't
be
emerging
prs
that
we
haven't
reached
some
level
of
agreement
on
and
discussion
on
the
issue,
but
for
people
who
want
to
see
what
has
happened
and
potentially
disagree
with
it.
After
the
fact,
I
think
it
would
be
useful
if
we
started
putting
a
change
log
in
the
document,
at
least
when
we
drop
new
versions
undo
the
tracker.
B
Yeah
I
mean
I
again,
I
guess
I'll
leave
it
to
the
editors
to
decide
whether
or
not
they
want
to
include
a
change
log.
Certainly
you
couldn't
hurt
on
who
can
on
closing
issues
in
response
to
you
know,
prs
being
merged
shares.
We
think
that's
a
reasonable
thing
to
do
if,
if
based
on
the
the
content
in
the
pr
we
we
feel
that
or
the
editors
feel
that
it
adequately
addresses
the
issue.
B
And,
of
course,
if
there
are,
you
know
if
there
are
people
who
are
following
the
issue
who
feel
it's
not
been
resolved,
they
can
comment
on
that
and
the
chairs
will
assess
and
see.
If
whether
or
not
we
need
to
reopen
the
issue,
that's
the
beauty
of
github.
We
can
open
and
close
issues
that
will,
although
we
don't
want
to
revisit
things
that
we
have
consensus
on,
I
I
don't
want
to
have
them
linger.
I
guess
for
too
long
mark.
I
think
if
your
hdbiz
mark
or
tommy,
I
don't.
I
Know
I
am
well
exactly
you
don't
know
who
you're
talking
to
do
you
I.
I
would
just
suggest
that
maybe
we
not
spend
too
much
time
talking
about
this
sort
of
process
things
in
the
meeting,
but
that
whatever
process
the
chairs
come
up
with
that
they
want
to
get
in
for
the
working
group
document.
It
write
it
down
by
convention,
most
working
groups.
I
see
use
contributing.md
for
that
and
I
will
paste
into
jabber
what
http
uses,
which
might
be
a
good
starting
point,
because
it's
more
lightweight
than
what
quick
uses.
H
F
I
tried
to
include
an
explicit
reference
to
the
github
issue
that
we
were
addressing
and
what
I
hope
was
visible
to
folks,
because
I
double
checked
this
in
the
github
ui
is
that
it
should
be.
I've
shown
each
of
the
issues
that
was
referenced.
Sorry,
each
of
the
commits
that
was
referencing
the
issues,
so
at
least
for
those
where
we
did
not
have
where
we
did
have
a
clear
commit
addressing
the
issue.
There
should
be
evidence
in
github
of
what
we
intended
to
resolve.
F
The
issue
was
one
thing
that
we
did
not
do,
because
david
primarily
chose
to
review
this
as
one
large
pr
is.
We
did
not
use
the
closest
tag
for
the
bulk
of
the
edits,
so
david
later
on,
went
and
closed
the
issues
by
hand.
So
I
apologize
if
that
caused
any
confusion
about
why
things
were
being
closed
on
the
ipoxy
requirements
side.
F
That
said,
I
also
want
to
bring
up
something
based
on
what
myriad
just
suggested
mira
just
like.
I
said
that
at
least
two
people
should
agree
that
the
issue
should
be
closed
under
that
metric
david,
and
I
agreed
that
the
issue
should
be
closed.
Is
that
something
that
we
want
to
have
it
be
acceptable
because
that
does
not
seem
like
it
would
end
up
addressing
mario's
concern.
As
I
understand.
B
B
G
Yeah,
the
point
was
not
about
two
people
to
have
a
number
here.
The
point
was
about
those
people
who
were
actually
involved
in
the
discussion
and
like
when
I
opened
an
issue.
I
didn't
have
any
chance
to
comment
on
the
on
the
resolution
that
or
what
you
thought
was
a
resolution,
because
I
didn't
see
it
before
you
closed
the
issue.
I
think
that's
a
problem
we
had
here.
A
A
G
Yeah,
so
I
don't
want
to
make
this
heavy
process
or
anything
but
like.
I
also
want
to
make
sure
that
we
just
don't
close
issues
and
then
like
lose
something
or
whatever
and,
like
everybody
suggested,
we
should
trust
the
editors.
I
think
that's
good.
In
this
case,
I
would
really
like
to
see
editors
added
to
the
documents
that
are
from
a
different
angle,
from
a
different
company
of
having
different
use
case
in
mind.
So
we
have
more
diversity
on
the
editors
for
both
of
the
documents.
A
J
J
J
J
We
I'll
give
a
recap
of
kind
of
what
was
covered
in
109
and
where
we're
at
today,
just
in
case
people
forgot
or
were
confused
by
the
the
kind
of
crossover
between
http
3
datagrams
and
connect
udp,
but
yeah
the
I'll
just
come
aboard
to
kind
of
help,
give
some
review
and
an
assistance.
Five
presentations
like
this.
So
next
slide,
please.
J
J
And
so
that's
that's
part
of
the
framing,
but
we
wanted
to
be
able
to
actually
have
a
concrete
use
case
for
how
to
use
those
logical
flow
identifiers
for
something.
So
in
this
case
the
concrete
use
cases
connect
udp
that
we
will
handle
different
tunnel
connections
to
some
different
target
server
that
are
identified
by,
in
this
case,
the
authority.
J
J
We
had
the
datagram
frame
at
the
transport
layer,
and
so
part
of
the
discussion
that
we
had
was
to
allow
us
to
find
a
home
for
h3
datagram.
Where
did
it
fit?
It
could
have
gone
into
any
of
the
working
groups,
but
the
the
outcome
of
the
discussion,
as
I
understand
last
time,
is
that
we
believe
mac
is,
is
the
most
appropriate
home.
It's
possibly
not
the
only
place
it
could
go
in,
but
that
we
we
think
that
mask
is
the
correct
place
to
adopt
the
new
document
that
we
have.
J
So
if
you
go
to
the
next
slide,
please
in
order
to
get
a
clearer
separation
of
concerns,
just
focus
on
the
red
box
here.
This
is
again
a
a
capture
of
the
image
that
david
had
in
the
previous
set
of
slides,
because
I'm
lazy,
but
if
we
focus
on
the
red
box,
what
we
have
now
in
the
new
updated
scenario
mask
h3.
J
K
J
So
I'm
confused
to
get
technical
there
is
there,
isn't
a
http
3
layer
frame
that
would
be
sent
on
a
stream,
so
in
hp3
all
all
frames
of
effectively
are
sent
on
streams.
So
this
is
when,
when
you're
using
the
lpn
h3
is
highlighted
there
kindly
that
when
you
receive
a
datagram
on
the
transport
layer
that
you
should
effectively
parse
the
first
variant
length,
integer
or
62
bits,
I
can't
quite
remember
which
one
as
as
a
flow
id.
K
J
J
J
J
Yes,
so
this
is
the
supporting
of
the
extendability
or
multiplicity
of
different
datagram
flows.
So
previously
we
had
a
singular
integer,
which
is
fine
for
the
simple
connect
case
that
we
kind
of
started
mask
with,
but
it
wasn't
easily
extendable.
Yes,
anyone
familiar
with
structured
fields
will
know
that
you
can
have
parameters
on
them
and
that
might
be
a
way
to
be
abused.
J
To
do
some
of
the
things
that
people
said,
they
would
like
to
do
with
say
adding
a
ecn
extension,
but
there's
many
ways
to
write
headers
that
we're
familiar
with
so
some
of
the
discussion,
some
of
the
more
advanced
use
cases
kind
of
led
us
down
the
path
of
redefining
this
header
to
be
a
structured
field.
So
if
you're
only
doing
a
single
datagram,
it's
no
different
to
be
honest,
but
if
you're
doing
more,
if
you're
going
to
the
next
slide,
I
can
give
you
an
example.
J
Oh,
my
images
have
changed,
but
anyway
yeah
it.
We
kind
of
came
up
with
this
new
definition
of
a
name.
I
don't
want
to
get
too
much
into
it,
really
because
all
in
the
document-
and
this
probably
makes
it
sound
more
complicated
than
it
is,
but
we
have
this
concept
of
list
members
that
are
flow
id
or
flow
identifier,
elements
that
can
be
named
or
unnamed.
J
You
might
need
a
name
if
you've
got
more
than
one,
because
it
makes
it
easier
to
reference
which,
which
remember
you're
kind
of
talking
about
it's
just
a
handle.
For
what,
and
if
you
didn't
have
names,
then
things
get
difficult
and
so
there's
some
specific
rules
here
that
you
know
names
must
not
appear
more
than
once
in
a
list,
because
you
know
they're
overlapping,
different
ids,
different
names,
that's
sad,
and
so
how
enforceable
these
rules
are?
J
These
aren't
part
of
structured
fields,
they're
effectively
additional
rules
on
the
top
of
them,
but
I
mean
from
an
implementer's
hat
on
it's
fairly
straightforward,
to
kind
of
apply
additional
validation
to
this.
In
my
opinion,
maybe
we
haven't
got
everything
quite
right,
but
I
think
what
we
have
in
there
is
is
pretty
okay.
L
So
lucas,
I
think
I
might
have
been
the
one
to
suggest
this
particular
structure,
but
I
don't
remember
ever
discussing
the
name
thing
if
the
name
is
just
an
arbitrary
parameter
type
on
on
each
structured
field,
integer.
How
does
that
turn
into
something
that
can
be
used
by
someone?
And
how
does
that
not
conflict
with
potential
concrete
extensions?
So
one
of
the
things
that
I
imagined
we
would
have
here
is
okay,
so
you've
got
a
datagram
flow
id
for
this
connect.
L
If
that's
the
way
that
you
wanted
to
spell
that,
for
instance,
and
if
you
just
allow
people
to
have
arbitrary
labels
here
with
names,
that's
going
to
conflict
potentially
with
like
the
names
that
they
can
choose,
can
overlap
with
the
labels
that
you
want
to
use
for
real
parameters.
That
mean
something.
How
do
you
reconcile
that.
H
So
can
I
jump
in
to
answer
this?
Perhaps
thanks
so
the
the
idea
there
was
to
have
a
way
to
let's
say
if
you
have
two
separate
extensions
that
want
to
both
have
their
own
flow
id.
You
want
a
way
to
differentiate,
which
is
which
so
having
a
name
solve
solves
that
what
we
did
in
the
draft
is
we
have
an
iana
registry
for
any
and
all
parameters
to
datagram
flow
id.
H
L
H
H
Yeah,
or
or
maybe
let
me
try
to
explain,
the
advantage
of
this
over
parameters
is
that
it
means
that
this
can
be
understood
like
you,
you
you
will
receive
like
looking
at
this
header.
You
will
understand
that
there
are
like
four
different
flow
ideas
going
around,
even
if
you've
never
heard
of
this
name
or
never
heard
of
this
extension.
So
it
gives
you
some
like
cleaner
semantics
in
that
way,.
H
I
So,
martin,
so
my
suggestion,
which
was
to
just
create
a
name
parameter,
but
I
don't
think
it's
a
bike
shed.
The
current
design
is
pretty
byzantine
in
that.
What
you're
basically
saying
is,
is
that
any
parameter
on
these
is
a
name
unless
it's
in
this
registry
over
here,
in
which
case
it's
a
parameter
and
you
with
implementation,
have
to
keep
up
to
date
with
the
registry
to
make
sure
you
don't
collide.
H
J
Yeah,
I
I
think
I'd
be
happy
with
that
too,
because
it
means
we
can
cut
like
that
third
bullet
point
there.
We
can
reduce
the
complexity
of
that
down
and
avoid
future
questions
asking
why
we
have
this
byzantine
scheme,
so
either
me
or
david
can
create
an
issue
to
track
this
and
and
get
some
resolution
going
forward.
Thanks
next
slide,.
M
That's
fine,
hey!
I
don't
really
understand
why
you
need
this
restriction
that
each
name
can
only
be
used
once
it
doesn't
seem
to
be
necessary.
I
mean
I
don't.
It
doesn't
seem
to
be
useful
to
to
repeat
the
same
name
which
in
mask
it
would
result
in
multiple
flows
with
the
same
properties,
but
that
also
doesn't
seem
like
a
problem.
H
For
at
least
for
some
of
the
the
uses,
let's
say
like
the
ecn
connect
udp
extension
as
currently
written.
It
wouldn't
make
sense
to
have
multiple
of
the
same
name,
but
we
could,
in
this
document
not
say
anything
about
repeating
names
and
then
in
the
definition
of
each
individual
name.
That
definition
can
state
whether
it
can
be
repeated
or
not,
because
in
some
cases
then
it's
right.
Maybe
you
might.
That
might
be
a
useful
feature.
M
B
N
Yeah,
I'm
not
sure
how
I
feel
about
some
names,
repeatable
and
some
names
being
not.
That
seems
like
terrifying,
and
it
seems
very
hard
to
enforce
at
this
like
things
that
are
hard
to
enforce.
This
layer
seems
sad
so,
like
probably
either
they
should
all
be
repeatable,
or
none
of
your
people,
at
least
at
this
layer
of
attack.
C
Just
a
quick
comment
on
that.
I
think
the
problem
about
repeatability
probably
will
go
away
if
we
rewrite
this
to
be
a
truly
parameterized
and,
for
example,
in
okay
martin,
I
was
about
to
say
that
that
for
ecn
you
should
just
have
an
ecm
parameter
in
which
you
say:
okay,
these
particular
flags
fold
into
this
datagram
flow,
and
maybe
that
one
of
my
datagram
flow
ids
has
ecn
with
ce
marked
and
another
one
also
has
ce
marked,
but
also
with
another
parameter.
J
To
respond
quickly,
I
think
part
part
of
this
was
to
allow
us
to
have
effectively
named
extension
points
that
could
have
parameters
applied
to
them,
specifically
that
those
parameters
might
overlap
in
some
way.
There
might
be
a
q
value
or
something,
and
we
wanted
to
be
able
to
allow
parsers
to
to
be
able
to
disambiguate
those
things
cleanly.
But
that
said,
I
think
there
are
very
many
variations
on
this
design
that
are.
G
Yes,
this
proposal
assumes
assumes
a
certain
design
for
extendability,
which
is
that
we
overload
the
flow
id
to
use
it
to
signal
different
things
right.
We
could
also
just
like
have
the
flow
id
as
a
flow
identifier
and
then
have
the
ability
to
add
another
field
or
additional
fields
after
the
flow
id,
which
would
would
you
know,
need
some
more
bytes,
but
it
might
be
from
a
design
point
more
clear.
G
M
On
the
datagram
flow
ids,
like
ecn,
is
potentially
a
layering
violation
here
and
could
create
some
real
complexity
in
the
registry
structure,
because
datagram
flow
id
has
nothing
to
do
with
connect.
Udp
datagram
flow
id
is
a
generic
http
3
mechanism,
so
I
don't
know
who
gets
to
decide
whether
ecn
is
an
allowed
parameter
to
have
in
in
a
datagram
flow
id,
but
it
might
end
up
mixing
layers
or
requiring
all
of
the
different
users
of
datagram
flow
id
to
share
a
namespace
or
something
so
anyway.
H
M
So
that's
possible,
it
does
create
weirdness
right
now.
You
have
like
hypothetically,
you
have
web
transport
and
mask,
and
whoever
else
all
putting
you
know,
parameters
that
don't
that
have
nothing
to
do
with
each
other
that
are
like
applicable
in
totally
different
contexts
having
to
register
them
in
a
in
a
single
registry.
H
M
J
Okay
next
slide,
which
goes
through
some
ecn
examples.
I
I
I
think
we
don't
need
to
beat
around
the
bush
with
this
one,
like
some
people
like
that,
some
people
hate
it
that's.
The
only
thing
I
think
we
want
to
establish
is
that
having
one
more
than
one
datagram
flow
id
is
going
to
be
usable.
I
haven't
heard
anything
like
counted
to
that
so
far,
so
ignore
the
format
but
keep
the
capability
and
and
we'll
continue
to
work
on
this.
J
J
It's
confusing,
but
yeah,
the
I
think
getting
to
grips
with
structured
fields
and
future
extendability
is
something
that
maybe,
as
a
community,
we'll
we'll
get
some
experience
with
too,
and
ideally
try
not
to
reinvent
the
wheel
too
much
on
that
and
go
for
a
comment
strategy
is
what
I'd
like,
but
the
other
changes
in
this
draft.
The
second
point:
there,
the
possibility
of
retiring,
a
flow
id
and
reusing
it
has
been
added
into
the
draft.
J
I
don't
know
if
you
want
to
speak
any
more
to
that
david,
but
if
not,
we
have
some
minor
things
like
changing
an
error
code
which
shouldn't
really
change
anything
but
some
more
guidance
on
use
with
the
intermediaries.
So
I
don't
want
to
go
into
too
much
of
that
today.
The
rfc
diffs
in
the
in
the
thing
reviews
are
going
to
be
good.
There
I
see
a
question
from
ekka.
I
could
take
that
now.
K
N
H
J
L
J
So
I
think
the
main
question
here,
what
I'm
seeing
is
still
some
interest,
and
so
the
main
question
is:
should
the
mask
working
group
adopt
this
document?
That's
not
the
question
that
I
can
ask
it's
for
the
chairs
to
do
it,
but
you
know
the
the
background
in
the
history
here
is
that
h3
datagram's
a
normative
dependency
of
connect
udp,
but
it's
a
document.
That's
still
david's
individual
draft
effectively.
So
as
authors,
we
believe
that
the
document
captured
changes
that
reflected
the
discussion.
B
Yeah
thanks
lucas,
and
thanks
for
tabling
this
up.
Indeed
now
we
want,
to
you
know,
present
a
question
to
the
group
as
to
whether
or
not
we
think
it's
appropriate
to
adopt
this
document
in
its
current
state
as
a
you
know,
to
go
to
work
alongside
connect
udp,
obviously,
under
the
the
condition
that
all
the
contents
are,
you
know,
subject
to
change
the
formats
of
the
headers
whatever,
but
before
we
ask
the
question
just
strain:
the
queue
real,
quick
martin.
L
Whatever
that,
however,
you
want
to
think
about
that
when
you
make
the
request,
you
say
all
right,
I'm
going
to
set
this
thing
up
and
then
the
request,
the
the
header
fields
will
determine
which
flow
ids
you
have,
and
that
doesn't
really
fit
very
well
with
my
understanding
of
how
these
flow
ids
are
going
to
be
used.
In
this
context,
I'm
sort
of
wondering
whether
there's
a
possibility
of
having
frames
for
that
as
in
using
the
chunk
types
that
david's
defined
to
to
signal.
L
Well,
I'm
going
to
now
use
this
datagram
to
mean
of
this
datagram
flow
idea
to
mean
x.
The
problem
with
that
is,
it
makes
the
flow
id
relationship
to
those
requests
not
visible
to
intermediaries.
So
I'm
not
sure
that
that's
necessarily
a
good
idea.
I
wanted
to
float
the
idea
here
because
it
changes
the
scope
of
this
document.
J
Just
to
to
respond
to
that,
I
I
think
you're,
asking
kind
of
for
a
capability-
that's
similar
to
proxy
quick,
aware
proxy.
What
will
get
presented
later
in
a
sense
that
you
want
to,
or
people
might
like
to
be
able
to
decorate
an
active
stream
with
some
additional
metadata,
and
so
you
know
a
way
to
do
that
is
effectively
like
a
a
patch
of
the
headers
with
some
extra
headers.
You
could
do
that
with
frames
for
sure
or
maybe
a
another
request
method
which
hp
purists
might
hate.
L
O
B
Some,
I
guess,
background
chairs
of
the
http,
quick
and
mask
working
group.
We
all
sort
of
convened
and
chatted
about
where
this
might
go
and
concluded
that
here
was
sort
of
the
best
place
for
it.
I
mean
I
take
your
comment
that
things
are
changing,
perhaps
not
in
the
direction
you
would
like,
but
hopefully,
if
and
when
this
is
adopted,
we
can,
you
know,
get
a
better
handle
on
that
and
and
then
make
it
maximally
useful
for
all
intended
use
cases.
H
So,
victor
just
to
respond
really
quickly.
Apologies
for
you
feeling
that
you
were
out
of
the
loop.
I
think
a
big
difference
is
that
this
document
right
now
is
an
individual
draft,
so
I
was
just
updating
it
anytime.
I
had
an
idea.
I
would
do
that
and
I
apologize
for
not
chatting
with
you
more.
However,
adopting
this
here
in
https
will
mean
that
you
know
changes
will
now
require
you
know
consensus
and
we
are
going
to
establish
a
github,
very
specific
github
process
for
mask
as
well.
H
I
A
A
A
G
Yeah
ian
just
asked
which,
which
changes
particular,
I
think,
the
the
naming
part
where
we
had
some
discussion
about
it.
I
think
it's
just
easier
if
we
remove
those
parts
where
we
have
like
a
lot
of
disagreement
or
uncertainty
about
and
then
take
that
as
a
starting
point
than
having
stuff
a
in
a
document
and
then
start
the
discussion
afterwards.
K
B
A
K
P
P
G
Yeah,
sorry,
I'm
still
not
sure
what
I
should
put
in
the
poll
here,
because
I
I
think
eric
you
said
earlier.
The
the
editors
are
committed
to
do
some
changes
based
on
the
discussion
we
had
today.
So
all
I'm
asking
for
is
to
see
those
changes
first
and
then
have
the
adoption
call.
I
think
that
totally
makes
sense.
It's
just
one
more
revision,
I'm
looking
for
not
like.
H
As
editor
of
the
document
I'll
say
that
if
today's
adoption
call
is
successful,
I
I
will
make
changes
before
we
uploading
that
we've
discussed
here.
That's
totally
fine,
but
I
would
really
prefer
we
not
delay
this
like
if
there's
anything
in
the
dash
zero
zero
that
you
don't
like,
we
will
change
that.
That's
perfectly
reasonable,
like
we
don't
need
the
document
to
be
finished
before
we
adopt.
A
It
all
right
before
we
drain
the
rest
of
the
queue
I'm
about
to
close
the
poll.
So
if
you
haven't
clicked
buttons
that
you
are
planning
on
clicking-
or
you
are
part
way
through
clicking
the
buttons,
because
I
made
you
answer
two
questions
instead
of
just
one,
please
do
so
now,
I'm
about
to
close
it.
A
N
Well,
not
a
question,
but
I
mean
so
so
I
mean
miriam's
request
to
make.
The
changes
before
this
is
adopted
is
in
order,
but
I
think
wrong,
namely
that
I
don't
think
the
changes
are
that
major
speaking
of
someone
who
found
one
those
things
annoying.
I
hope
that
changes
that
major
and
I
trust
the
the
editors
to
make
them
or
that
or
or
me
to
complain
about
them
later,
if
I
don't
think
they
have.
G
B
J
Yeah
just
one
final
comment:
as
a
author
editor
here,
it's
just:
it's
probably
going
to
be
easier
for
us
to
migrate
the
document
into
a
mask
working
group
repo
and
then
create
the
issues
there
for
traceability
and
to
make
sure
everyone's
in
the
loop
should.
Should
we
decide
as
a
group
to
adopt
this
document
that.
H
B
H
Please
all
right
connect
udp
is
like
connect,
but
for
udp,
as
you
noticed
this
summary
of
what
it
does
is
getting
shorter
and
shorter,
but
really,
let's
just
try
to
keep
this
protocol
simple,
and
the
one
notable
thing
is
that
it
can
use
quick
datagram
frames
to
allow
not
retransmitting
your
udp.
So
next
slide,
please.
H
H
H
All
right,
so
this
is
one
of
the
things
that
we
resolved,
but
in
particular
I
got
moved
to
the
datagram
draft,
but
I
wanted
to
highlight
it
a
little
bit,
because
that
is
an
issue
that
might
in
some
for
some
folks
want
more
discussion
in
the
current
design.
The
for
the
datagrab
flow
id
header
allows
one-to-one
one-to-many
and
many-to-one
mappings
between
a
request
and
a
flow
id.
So
first
off
we
need
a
mapping
between
a
request
and
a
flow
id
for
lifetimes.
H
So
you
can,
when
you
create
your
connect
qdp,
you
know
how
long
that
flow
id
will
be
valid
and
then
on
the
server.
You
know
that
tells
you
when
you
get
the
udp
payload
for
that
flow
id
which
target
server
you
want
to
send
it
to
the
feature
of
doing
one
to
many
is
an
extension
point
that
allows,
in
some
cases
to
on
one
request,
open
up
multiple
flow
ids
in
order
to
save
bytes.
H
So,
let's
take
ecn,
for
example,
ecn
you
could
implement
by
having
an
extension
that
says
well
the
right
before
the
udp
payload.
We
just
add
one
byte
that
contains
the
cn
bits
that
would
totally
work.
Another
way
would
be
to
allocate
multiple
flow
ids
one
for
each
ecn
state
one
of
the
four
and
then
you
kind
of
save
that
bite.
I
think
for
ecn.
It
really
doesn't
make
much
of
a
difference,
but
there
are
some
other
extensions
where
this
could
be
particularly
really
useful.
H
Let's
say,
if
you
want
to
do
you
know
other
kinds
of
compression
or
things,
so
I
think
that
would
be.
That
would
be
useful
and
the
many-to-one
is
the
case
where
you
want
to
have
multiple
connect,
udp
requests
that
end
up
sharing
a
flow
id,
and
this
is
used
in
the
quick
proxy
extension
that
tommy
will
be
presenting
later
so
just
wanted
to
kind
of
highlight
that
having
this
list
in
the
in
the
datagram
flow
id
enables
this
but
yeah.
So
that
was
issue
16.
just
jump
in
the
queue.
L
H
So
in
fact,
you're
totally
right
that
there's
a
concern
there.
The
document
states
that
yeah,
if
you
use
this
many
to
one,
you
need
to
ensure
that,
like
the
intermediary
needs
to
ensure
that
it
lands
on
the
same
back
end,
I
would
rather,
we
didn't
like
focus
on
intermediaries
because,
like
we
want
them
to
work
absolutely
but
like.
I
think
that
most
deployments
of
this
will
not
be
using
intermediaries,
and
so
I
would
be
sad
to
lose
a
feature
that
an
extension
is
using
just
because
it
makes
implementing
an
intermediary
harder.
L
H
H
L
F
I
wanted
to
echo
some
confusion,
slash
concern
about
the
many
to
one
case.
Having
done
some
sort
of
similar
implementation
work,
when
we
were
building
rvpn
on
top
of
quick,
we
actually
found
that
the
many
to
one
thing
kind
of
breaks
horribly
in
ways
that
you
don't
expect
and
while
I
can
definitely
see
a
justification
for
the
one
to
one-on-one
to
many
use
cases.
I
am
nervous
about
the
many
to
one
and
look
forward
to
lucas's
presentation
later
on
to
see
how
it's
used.
H
H
H
However,
scheme
is
required
according
to
the
http
semantics
documents,
and
the
exception
for
connect
does
not
apply
to
any
new
methods,
so
we
don't
get
that
that
exception
for
connect
udp.
Unfortunately,
that
said
the
the
scheme,
even
though
it
needs
to
be
carried,
really
doesn't
provide
us
with
any
useful
information.
I
I
Mark,
I
I
think
it's
possible.
I
mean
the
mental
model
that
I'm
using
is
that
yes,
in
theory,
people
have
occasionally
used
https
uris
as
a
means
of
proxy
configuration
to
connect.
You
know
for
normal
connect,
but
that
hasn't
been
very
uniform
practice.
I
think
some
clients
expect
to
host
port
pair
other
ones
want
a
uri.
I
C
H
Think
having
a
uri
for
proxy
configuration
might
be
useful,
but
it's
not
the
same
thing
as
what
we
send
over
the
wire
in
order
to
talk
through
a
proxy
to
create
a
kinect
qdp
tunnel.
And
what
I
mean
by
that
is,
you
could
have
your
let's
say:
proxy
colon,
slash,
slash
or
connect.
Slash
were
right.
After
that
second
slash,
you
would
put
the
host
name
of
your
proxy,
whereas
in
this
case
here
we're
not
configuring
a
proxy
we're
just
the
host
name.
There
is
the
host
name
of
the
target
server
yeah.
I
I
I
was
thinking
that,
if
you
wanted
to
note
that
that
you
really
wanted
to
have
you
know
the
datagram
extension
and
to
use
connect
udp
in
that
interaction,
that
would
be
useful,
but
that
information
is
kind
of
already
present
to
some
degree
in
the
method.
So
yeah,
I
think
https
is
actually
fine
on
the
wire
yeah
I'll
retract
that.
Thank
you.
H
H
N
C
D
D
Yes,
so
magnus
westland
here
I
I
don't
know
about
this
semantics.
I
I
brought
up
the
question
and
I
think
the
reasons
maybe
to
have
is
that
separate
external
reference
casing
use
this
masks
proxy
to
do
something
and,
and
that's
positive,
separate
document.
The
other
aspect
I
was
carrying
a
bit
about
here
is
the
relation
between
the
different
semantics
and
and
if
we
would
define
a
schema,
because
we
need
to
think
about
okay,
we
have
udp,
we
have.
We
are
thinking
about
ip.
D
L
I
think
in
this
case,
a
new
euro
scheme
scheme
is
actually
a
little
harder
than
mark
implied,
because
I
think
we
have
to
ask
questions
like
what
magnus
was
getting
at
here
in
terms
of
what
information
the
uri
expresses
and
how
we
manage
extensibility
and
all
those
sorts
of
questions.
Having
looked
at
the
existing
udp
uri
schemes,
they
differ
in
some
of
the
things
that
they
do
and
so
that's
problematic.
H
H
C
Thank
you
so
https,
I
think,
is
generally
going
to
be
the
right
thing
to
do
definitely
more
than
having
a
new
ui
scheme.
However,
I,
I
think,
there's
a
crazy
proposal
of
saying
you
know
we
don't
need
to
define
one
scheme
here
like
why
can't
we
just
essentially
use
the
scheme
of
what
the
actual
request
is
trying
to
access.
So
generally,
I
think
we're
thinking
about
how
am
I
proxying
quick?
C
That's
happening
on
the
proxy
and
you
know
it's
going
to
issue
a
quad,
a
queries.
Maybe
it's
going
to
issue
some
svcb
queries
and
actually
knowing
what
scheme
it
has
the
thing
it's
trying
to
request
is
potentially
useful
and
so
like.
We
can
just
say
yes
do
https
in
general,
but
it
doesn't
have
to
be
only
https
like
let
the
scheme
field
actually
be
somewhat
useful
in
case
someone
wants
to
use
it
later
in
the
connected
udp.
H
So,
just
to
clarify
what
you're
saying
tommy,
would
you
be
okay
with
saying
the
the
document
says,
you
must
use
https
and
you
must
ignore
on
receipt
and
then
later
someone
can
have
other
semantics,
because
there
are
a
lot
of
use,
uses
that
don't
have
a
scheme
right.
If
I
have
my
custom
busco
protocol
over
udp,
it
probably
doesn't
have
a
uri
scheme.
C
Sure
I,
I
guess-
and
I
see
martin's
comment
like
yeah-
you
don't
want
to
tell
the
proxy
what
you're
planning
to
do.
That's
fine,
you
don't
have
to
do
it
just
do
https
by
default.
I
just
I
think
we
could
get
away
with
saying
you
should
send
https,
but
it
doesn't
need
to
be
a
must
like
we
can
say
that
by
default
you
ignore
it
on
receipt,
but
I
don't
see
why
we
need
to
mandate
it
as
a
must.
J
Sorry
but
sorry
to
bend
here,
I
missed
the
original
thing
and
we
had
a
bit
of
a
race
condition.
Go
on
so
I'll.
Keep
it
quick
ben,
said
ben
schwartz
said
using
https
would
require
updating
the
definition
of
the
https
uri
scheme
since
the
destination
does
not
support.
Https
using
udp
seems
much
better
to
me.
Another
option
might
be
null
if
it
can't
be
empty
and
isn't
meaningful
and
by
null
that
means
the
string
null
for
the
scheme,
not
just
empathy.
H
B
H
H
So
that's
what
it
is
right
now,
it's
a
sequence
of
tlvs,
where
type
0
is
the
only
one
that's
registered
in
the
document,
and
it
means
here
is
a
udp
payload
and
we
can
like
have
a
an
eye
on
a
registry
and
extensions
can
use
these
like
define
new
new
types
of
chunks,
to
clarify
how
this
is
sent
in
http
3.
The
stream
is
sent
over
data
frames.
Similarly,
in
http
2,
this
is
sent
over
data
frames
and
in
http
one
one,
it's
directly
over
tls
or
tcp.
H
So
that's
the
for
that
one,
the
apologies
for
when
the
first
time
I
wrote
it.
I
did
an
absolutely
terrible
job
and
it
was
very
confusing.
I
hope
that
it's
more
readable
now,
though,
I
saw
an
error,
an
issue
from
martin
that
made
me
think
that
maybe
I
need
to
clarify
the
text
even
further,
but
does
this
sound
reasonable
to
folks.
N
N
So
I
think
it
sounds
reasonable,
but
I
guess
I'm
now
a
little
puzzled
by
the
previous
discussion
about
flow
ids
and
ecns,
as
this
seems
like
a
relatively
natural
way
to
convey
ecn
information
as
well
in
that
one
could
simply
be
like
type
of
one
is
like
udp
build
up
with
ecn
or
some
some
such
thing
right
or
you
see
you.
People
have
metadata
so
like
like.
I
guess
I
do
agree.
It's
like
not
like
super
helpful
to
like.
Have
you
know?
H
There
are
two
things,
so
the
ecn
extension
actually
does
this,
so
it
defines
three
new
three
new
types,
but
we
for
connect
udp
with
ecn
over
http
3.
You
want
to
be
able
to
send
your
ecn
over
datagrams
or
over
streams.
I
mean
first
gp3
over
streams,
isn't
particularly
useful,
but
that
is
more
useful
for
http
2.
and
so
no
matter
what
you're
going
to
need
two
ways
of
encoding,
this
data,
one
over
the
stream
and
one
over
the
datagram,
and
then
you
both
of
these
need
to
be
extensible.
H
N
D
Yes,
I
think
this
last
comment
really
changed.
My
views
a
bit
here
because
I
thought
I
mean
I
think
this
type
of
mechanism
is
needed
not
only
for
the
reliable
strings
but
also
for
the
datagram,
because
that
hack
on
the
flow
ids,
I
don't
think
work
particularly
well
when
we
get
past
a
few
bytes
of
additional
data
that
we
need
to
transfer,
and
I
think
we
are
in
some
of
these
extensions
gonna
have
a
bit
more
than
one
by
two.
That's
the
thing
goes
in
a
reasonable
amount
and
combinatorial
nicely
into
flow
ids.
H
So
for
for
the
data
datagrams,
I'm
not
saying
that
all
extensions
must
use
multiple
flow
ids
like
I.
I
personally
believe
that
that
would
be
a
useful
feature,
but
for
some
extensions
like
I
was
saying
in
that
email,
if,
for
example,
you
want
to
record
like
the
timestamp
of
when
that
udp
packet
got
received
by
the
proxy,
you
could
have
a
flow
id.
That
means
timestamp,
followed
by
udp
payload,
and
I
totally
agree
with
you.
D
That
type
is
fine.
I
think
okay
encoding,
the
stream
shank
type
into
the
flow
id.
That's
that's
one
thing
and
to
shorten
its
format.
I
think
it's
the
need
for
having
multiple
different
types
and
that
that
types
definitions
need
to
be
the
same
in
both
places.
That's
really
needed,
so
I
think
you're
in
the
right
direction.
Here
at
least.
K
C
I'd
actually
like
to
go
kind
of
the
opposite
direction.
I
mean
still
in
the
effort
to
simplify,
but
I
think
we
could
probably
do
without
having
a
chunk
type
registry
here.
You
know
if
we
want
to,
for
things
like
ecn,
have
the
type
not
be
included
as
different
flow
ids,
but
instead
being
coded
as
a
field
that
always
comes
directly
after
that's
fine,
but
I
mean.
C
Could
we
not
essentially
just
have
the
datagram
flow
id
number
space
be
the
same
as
these
chunk
types
here
and
essentially
yeah
you're,
potentially
encoding
a
flow
id
on
this
particular
stream?
That
is
over
specific
in
a
number,
but
it
still
matches
the
number
like
in
your
connect,
udp
request
header.
So.
H
C
No,
no,
the
other
way
to
replace
the
type
with
the
flow
id
like
when
you
need
to
fall
back
to
running
this
over
a
stream.
If
you
already
have
a
mechanism
in
the
headers
to
define
flow,
ids
just
use
those
floaties
such
that
if
you
want
to
have
two
different
flow
ids
for
this
one
connect.
Udp
request
just
use
those
ids
as
the
identifiers
of
your
chunks
and
don't
have.
H
H
A
lot
of
this
has
been
like
resolved
by
moving
text
to
the
http
3
datagram
conceptually
datagram
flow
id
is
a
per
hop
or
a
hub
by
hop
rather
header.
But
what
it
means
here
is
that
you
just
require
a
setting,
and
each
intermediary
must
parse
this
properly
and
every
usage
of
this
flow
id.
Oh
sorry
of
this
datagram
flow
id
header
needs
to
specify
how
an
intermediary
processes
it.
H
L
H
Yes,
that's
a
better
way
to
phrase
it
I'll
update
the
text
to
say
like
that,
but
that
was
the
intent.
Okay,
all
right!
Thank
you
next
slide,
so
we
added
a
performance
considerations
section
which
added
some
so
nothing,
no
musts,
but
or
actually
maybe
a
couple,
but
mainly
advice
on
what
to
do
about
congestion,
control,
loss,
recovery
and
pacing,
and
all
that.
H
H
Yes,
so
we
discussed
this
at
109.,
so
connect
has
this
property
where
it
waits
for
the
synack
from
the
target
server
before
it
proxies
anything.
We
can't
do
that
with
udp
in
practice.
Do
we
actually
care,
because
no
one's
gonna
dos
your
website
on
port
81
they're,
going
to
dos
you
on
port
80,
so
you're
going
to
send
us
a
knack?
H
K
E
H
The
water
working
here,
so
it's
so
it's
not
technically
a
hub
by
hop
header
like
come
by
hop
headers,
exist
in
http
one
and
they
were
removed,
http
2
and
later,
where
they're
they
specifically,
you
exchange
a
setting
using
http
203
to
do
this
and
that's
what
this
document
does.
So,
I
think
we're
very
much
in
line
with
what
you're
supposed
to
do.
H
Okay,
thanks
I'll
reread
the
and
document
provide
more
comments
later
cool
thanks,
because
you're
right
initially,
I
had
said
hop
by
hop
and
people
pointed
out
that
that's
not
how
it
works
between
later.
So
I
think
that's
been
addressed
and
fixed
all
right
thanks
everyone
for
your
time
and
I'll
hand
it
over
to
alex.
F
Hello,
everyone:
I
will
try
to
go
quickly
to
leave
time
for
the
as
time
permits
presentations
so
as
a
result,
we're
not
going
to
do
a
lot
of
review.
So
I
hope
you
remember
what
we
discussed
in
109.
We're
mostly
going
to
be
talking
about
the
updates
and
github
issue
discussion
that
we
had
for
the
ib
proxy
requirements
next
slide.
F
F
This
seems
to
have
been
some
confused
text
which
has
been
removed,
and
it
has
been
clarified
that
the
server
may
do
so
if,
for
some
reason,
the
server
needs
this
capability,
the
client
might
decline
to
do
so.
An
example
use
case
for
this
is
if
the
client
wanted
to
make
some
resource
available
to
the
server
and
the
sole
reason,
but
it
was
connected
to
the
server
was
to
make
that
exposure
rather
than
sort
of
the
other
way
around.
F
In
our
general
terminology,
clients
and
servers
can
potentially
have
equal
privilege.
The
only
difference
between
them
is
really
who
initiates
the
connection
versus
who
actually
receives
it.
So
just
because
you
are
the
client
does
not
necessarily
mean
you
are
less
privileged
on
the
server
you
might
be
able
to
provide
access
to
your
own
network
next
slide.
Please.
G
F
I
feel
like
that
question
doesn't
make
sense
to
me
because
asking
why
ip
addressing
is
a
cannot
be
an
extension
implies
that
the
entire
ip
addressing
section
of
this
document
would
have
to
be
an
extension.
If
I'm
understanding
correctly-
which
I
I
feel
like,
would
basically
gut
this
document
substantially.
F
Fundamentally,
if
we,
if
we
look
at
this
at
a
high
level,
we're
saying
that
the
protocol
needs
to
provide
some
mechanisms,
which
can
also
be
further
extended
in
some
ways
to
provide
information
between
the
client
and
the
server
around
which
ips
are
usable
and
reachable
for
both
ends.
Of
this
connection.
G
F
F
Next
slide,
please
load
balancing.
So
actually,
I
think
these
slides
are
no
longer
correct,
because
we've
made
some
changes,
since
these
slides
were
put
together.
My
apologies
for
the
slides
being
out
of
date
previously
that
we
had
moved
the
load
balancing
section
into
extensions,
but
later
on,
as
I
was
discussing
with
davis
kenazi,
we
actually
realized
that
the
entire
load
balancing
requirement
is
actually
the
wrong
thing
that
we
wanted
to
convey.
F
We
actually
believe
that
it
can
be
purely
implemented
as
an
extension
and
as
a
result,
doesn't
need
to
be
in
the
core
document,
but
rather
we
did
introduce
a
new
requirement
that
we
think
actually
more
appropriately
conveys
what
we
wanted
to
share,
which
is.
Rather,
we
would
like
to
encourage
the
core
mask
protocol
and
ip
proxy
in
particular,
to
be
as
stateless
as
possible.
It
should
be.
F
F
G
Yes,
once
again,
yeah
thank
you,
for,
I
think
that's
that's.
The
grammar
is
on
a
better
level
there
now,
but
I'm
also
want
to
discuss
further.
If
we
actually
want
this
requirement,
I
think
it's
a
general,
it's
a
good
design
to
have
as
little
state
as
possible,
but
I
don't
think
I
don't
know
if
that's
an
important
requirement
compared
to
other
requirements
which
actually
enable
certain
functionalities.
So
I
think
more
discussion
is
needed
here.
I.
F
F
G
Sorry,
yes,
I
keep.
I
keep
coming
back,
I'm
still
not
sure
if
I,
if
I
fully
agree
right
so
I
I'm,
we
might
well
end
up
with
a
solution
where
we
have
a
possibility
to
modify
it
to
forward
unmodified
packets,
but
we
might
well,
you
know,
have
like
a
simple
thing
where
like,
for
example,
the
proxy
already
knows
the
ap
address
of
the
target
server.
So
that's
a
field
that
you
could
just
easily
remove
without
any
additional
singing
whatever.
So,
if
you
want
to
do
that,
we
can
just
do
that.
F
But
that's
a
very
different
thing
than
what
the
text
currently
says.
So
so
what
you're
basically
saying
is
it
is
possible
for
some
related
information
to
be
removed
in
cases
where
you
have
an
individual
ip
as
a
target
which
I
agree
with
and
and
that
I
think
canon
should
be
implemented
as
an
extension.
However,
since
the
protocol
we
do
explicitly
want
to
be
able
to
transport
more
than
just
individual
ip
addresses.
F
G
F
I
think
that
going
in
the
direction
of
one
ip
too
many
ips
as
an
extension,
is
trying
to
add
additional
capability
into
a
lacking
extension
point,
rather
than
the
other
way
around
merely
right.
Now
the
requirement
is
that
the
data
transport
be
capable
of
doing
so.
It
does
not
say
that
packets
must
be
so
I'm
sort
of
sort
of
wondering
what
you
feel
about
this
requirement.
That's
precluding
you
from
being
able
to
implement
the
the
use
case
that
you're
describing.
H
That
start
compressing
and
then
react
the
data,
because
a
lot
of
compression
techniques
will
you
know
if
you
get
handed
a
packet
that
you
didn't
really
expect
you
will
fail
to
compress,
and
so
we,
I
really
think
that
we'll
have
a
better,
more
robust
design
if
we
say
that
by
default
you
just
send
things
like
that,
and
then
extensions
will
be
critical
to
make
this
performant
in
practice,
but
they
can.
They
can
be
just
that.
G
So
the
point
is
that
I'm
just
coming
from
the
other
direction,
I'm
looking
at
connect
udp,
and
I
think
the
thing
that
we
need
to
add
an
addition
to
connect
udp
is
very
minor
to
actually
make
ip
proxying
work
right,
and
at
that
point
you
kind
of
come
from
something
where
you
don't
have
an
ip
head
at
all,
and
you
just
adds
a
few
information,
and
all
I'm
saying
here
is
not
that
we
have
to
decide
on
the
solution
right
now.
It's
just
like.
G
F
Could
you
help
me
understand
why
you
think
that?
Because,
as
I
understand
qdp
today,
I
could
put
an
entire
ip
frame
into
connect,
udp
and
like
it
will
get
delivered
correctly,
because
people
don't
know
what
to
do
with
it,
like,
I
feel
like
a
a
hypothetical
connect.
Udp
implementation
would
actually
satisfy
this
requirement,
but
the
data
transport
there,
which
is
datagram
frames,
is
capable
of
forwarding
on
modified
packets.
A
Let's
move
to
the
to
the
next
in
the
queue
it
sounds
like.
The
change
that
has
been
made
takes
a
strict
requirement
and
makes
it
a
little
bit
looser
and
if
I
understand
mary
you're
arguing
that
it
should
be
even
looser
than
that.
So,
let's,
let's
take
that
on
on
to
the
issue
and
and
go
back
and
forth
until
we
figure
out
where
to
dial
that
in,
but
I'd
like
to
get
through
the
rest
of
the
queue
which
would
be
magnus
next.
D
D
F
D
F
Able
to
do
so
and
having
that
be
the
operating
mode
which
is
in
use
are,
are
different
things.
I
do
not
expect
everyone
to
use
that
particular
operating
mode.
This
is
intended
to
be
a
requirement
on
the
capability
of
the
data
transport,
not
not
a
statement
as
to
whether
or
not
that
is
how
all
implementers
will
use
the
system.
D
F
N
Great
nice
presentation,
so
I
mostly,
I
think,
joined
to
say
what
what
minus
said
I
mean
so
like
literally
speaking,
this
like
is
like
impossible,
because
we're
encrypting
the
data
and
so
like.
Obviously,
it
cannot
be
like
past,
like,
like
the
data
that
you
receive,
cannot
be
the
unmodified
data
that
you
transmit.
N
The
other
end
so
like
now,
we're
just
like
arguing
about
like
exactly
what
transformations
are
like
happen
like
between,
like
the
the
in
ingress
and
egress,
and
it
seems
to
me
that
the
requirement
here,
as
magnus
said,
is
that
the
the
the
system
has
to
deliver.
You
like
an
ingress
point
that
allows
you
to
shove
an
ipa
in,
and
that
comes
at
the
other
end
of
the
edgarest
point,
and
that
happens
in
some
unspecified
fashion.
That,
with
this
document,
has
nothing
to
say
about,
and
so
I
think
that's
the,
I
think
so.
N
F
N
Oh
okay,
but
I
guess
my
point
is,
I
don't
think
like
I
don't
think
compression
is
an
extension.
I
think
impression
it
might
be
an
extension,
but
it
might
not
be
right.
I
mean
like
it's
like
like
like
we
were
like
how
would
another
protocol
and
say?
Actually
we
should
like
add
light
compression
in
here
and
like
why?
Why,
if
this
document
is
trying
to
rule
out,
I
don't
think
we
don't
think
we
should
do
that
by
the
way,
but
this
document
trying
to
rule
that
out.
F
F
Terminology
miriam
pointed
out
that
there
was
one
use
of
the
term
id
proxying
session.
We
removed
that
use.
It
was
not
intended
next
slide.
Is
there
anything
else
right,
open
issues
next
slide,
please.
There
are
two
issues
that
we
did
not
touch
on
and
we
do
not
have
text
for.
One
is
issue
number
12
around
whether
or
not
nat
is
part
of
the
core
protocol
or
as
an
extension,
we
do
not
have
consensus
on
that
next
slide.
Please.
F
F
B
C
C
C
C
So
it's
essentially
using
fewer
local
ports
on
that
and
then
also,
if
you
want
to
you,
can
reduce
some
of
the
overhead
of
the
proxy
by
being
able
to
forward
the
quick
packets
without
doing
double
encapsulation
and
double
encryption
there.
This
is
not
always
what
you
would
want
to
do,
certainly,
but
in
certain
use
cases,
especially
if
you
are
doing
kind
of
multiple
hops
of
proxying,
it
can
cut
down
on
a
lot
of
packaging
overhead
next
slide.
C
So
with
this
extension,
if
you
are
communicating
the
quick
connection,
ids
that
you're
using
it
then
becomes
possible
to
use
a
single
udp
socket
between
the
mask
proxy
and
http
3
server
next
slide,
and
then
you
can
also
in
a
forwarded
mode.
Once
you
have
done
your
handshakes,
you
could
also
end
up
sending
a
packet
directly
from
the
client
to
the
proxy
that
gets
forwarded
along
that
same
socket
without
having
to
be
re-encrypted
or
recapitulated.
C
Also,
one
thing
that
we
specify
in
here,
which
probably
could
just
fold
into
the
main
connect
udp
document,
is
the
fact
that
talking
about
how
you
can
send
your
datagram
frames
kind
of
along
with
your
first
request,
to
make
sure
that
it's
very
fast
on
opening
and
then
for
the
forwarding
mode.
You
also
need
to
define
a
server
connection
id
that
that
is
once
you've
learned
the
connection
id
that
the
other
side
is
going
to
be
receiving
packets.
On
that
you
also
inform
the
proxy
of
that.
C
This
is
a
use
case
for
having
one
datagram
flow
id
that
is
referenced
by
multiple
connect.
Udp
requests,
since
you
can
have
one
datagram
flow
id
from
the
client
to
the
proxy
that
can
define
multiple
connection
id
mappings.
Of
course,
we
could
decide
to
use
multiple
flow
ids
if
that
was
what
people
wanted
to
do
next
slide.
C
Yeah
and
as
this
is
defined,
the
mappings
are
all
defined
based
on
a
client
request
and
the
server
the
proxy
server
can
reject
any
of
them
if
it
doesn't
want
to
handle
that
type
of
mapping
and
both
both
the
client
and
the
proxy
independently,
have
the
option
not
to
do
the
forwarding
mode
not
to
do
any
of
these
modes.
It's
very
much
negotiated
next
slide.
C
So
I
can
kind
of
bounce
through
these
very
quickly,
but
you
can
see
them
for
future
reference.
This
is
just
kind
of
describing
the
different
pieces
of
state.
You
need
to
be
able
to
have
on
the
proxy
if
you
so
already
kind
of
by
default.
Connect.
Udp
proxy
needs
to
be
able
to
map
the
client
to
proxy
quick
connection,
plus
a
datagram
flow
id
into
the
server
facing
socket
that
it
needs
to
send
out
on
that's
already
existing
state.
C
G
That's
fine,
I
mean
we
can
even
take
a
few
minutes
if
people
have
urgent
questions
to
tell
me
that
would
be
fine
for
me,
but
it
didn't
seem
to
be
the
case,
so
I
actually
only
wanted
to,
and
this
is
a
little
bit
outdated
now,
because
we
had
a
lot
of
discussion
about
this
just
now.
I
just
wanted
to
show
the
next
slide
this
one
because,
like
when
I
reviewed
the
first
time
the
requirements
document.
G
It
was
very
obvious
to
me
that
the
solution
the
authors
had
on
their
mind
is
is
the
right
one
in
this
picture,
where
you
have
in
the
quick
payload,
you
have
like
the
full
ip
packet
with
the
ip
header.
While
when
I
started
working
on
this,
I
rather
had
a
solution
like
the
one
on
the
left
side.
In
my
mind,
where
you
only
take
the
payload
of
the
ap
header
and
then
the
proxy
has
to
reconstruct
the
ap
header.
G
G
So
I
don't
want
to
have
a
discussion
about
what's
the
right
solution
and
there
might
be
hybrid
solution
where
you
didn't
like
at
some
fields
and
whatever
I
just
wanted
to
to
show
the
slide
to
make
sure
that,
like
we
came
from
two
different
sites-
and
I
think
we
already
agreed
in
the
previous
discussion
that
we
should
not
put
anything
in
the
primary
document
that
precludes
one
of
the
solutions
here
and
those
might
be
valid
and
there
might
be
prone
concept.
We
can
discuss
at
a
later
point
of
time.
G
I
also
would
like
to
make
one
more
comment.
So
we
have
only
a
few
requirements
in
the
requirement
draft
that
are
really
specific
to
ip
proxy
and
a
lot
of
requirements
are
more
generic
to
proxying
and
mask,
and
could
you
know
I
might
also
develop
for
for
udp
proxying?
Basically,
so
I
think
it
would
be
good
to
separate
this
and
to
make
sure
that
we
also
have
all
the
requirements
which
are
more
general
correct.
The
address
in
our
connect
utp
solution.
So
that
might
give
us
some
insights
for
things.
G
B
G
G
B
F
C
G
B
Cool
all
right
that
about
wraps
it
up.
Thank
you
all
for
coming
a
special
thanks
to
to
mike
and
lucas
for
taking
notes
for
everything.
Next
steps
are
eric
and
myself
we
will
send
out
a
consensus,
call
for
the
hp3
datagrams
document
to
see
if
that,
if
there's
interest
in
adopting
that
as
discussed,
the
issues
and
topics
that
were
discussed
during
david's
connect,
udp
draft
either
continue
being
discussed
on
the
github
issues
or
we'll
file
new
issues.