►
From YouTube: IETF114 MASQUE 20220727 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
B
B
A
A
E
D
A
A
F
A
All
right
with
that,
out
of
the
way,
let's
get
started,
welcome
to
mask
at
ietf
114.
This
is
the
first
in
person-ish
meeting
of
the
mask
working
group.
We
had
one
in
vienna,
that's
the
ish
part.
Diving
right
in
this
session
is
being
recorded.
It
will
be
on
youtube.
Anything
you
say
will
be
visible
and
audible
to
everyone
else
in
the
world,
make
sure
that
you
have
already
joined
via
the
on-site
tool,
if
you're
here
in
person,
if
you're
here
remotely
via
the
video
stream,
you
already
know
where
that
link
leads.
A
A
This
is
the
iutf
notewell.
You've
already
seen
it
by
this
point
in
the
week,
but
please
take
a
moment
to
make
sure
that
you
are
familiar
with
what
we
do
make
sure
that
you're
familiar
with
the
note.
Well,
this,
these
are
the
terms
under
which
we
participate
in
the
itf
pay
extra
attention
to
the
parts
about
the
code
of
contact
and
how
we
treat
ourselves
and
others.
A
A
G
G
G
So
get
excited
everyone.
But
before
that
we
do
have
some
updates
on
testings
and
implementations.
So
there
was
a
connect
ip
table
at
the
hackathon.
I
myself
was
not
there
because
I
was
on
an
airplane,
but
I
was
dutifully
hacking
on
connect
ip
on
the
airplane,
so
connect
ip
implementations
were
being
made
in
several
places
on
several
different
code
bases.
I
don't
think
we've
done
cross
implementation
interop
yet,
but
a
lot
of
work
was
going
on
and
we've
learned
things
from
trying
to
implement
dave.
D
Oh
sorry,
I
forgot
to
join
the
queue
dude,
it's
cozy,
just
to
add
from
the
hackathon
folks
we
were
very
darn
close
to,
but
everyone
was
realizing.
The
oh
implementing
the
mask
bit
is
easy.
Implementing
the
please
kernel,
take
this
packet
and
put
it
where
it's
supposed
to
go
is
way
less
easy,
so
mask
magnus
did
a
good
summary
at
the
end
of
the
hackathon
and
kind
of
what
we
said
is
we're
gonna
finish
this
and
reach
interop
in
the
coming
weeks
and
for
the
next
hackathon
in
london.
G
G
All
right
so,
first,
just
to
summarize
some
of
the
recent
changes
in
the
latest
version
of
the
published
draft,
we
had
done
work
to
try
to
improve
text
around
how
you
handle
the
uri
templates.
A
lot
of
this
is
lifted
from
connect
udp
as
connect
udp
finalized.
So
we
want
to
make
sure
we
had
parity
there.
G
We
had
issues
with
how
address
assign
worked.
When
is
that
required
or
not,
and
so
we
tried
to
clarify
that.
We
talked
about
the
fact
that
icmp
is
a
good
way
to
communicate
errors,
and
we
also
talked
about
how
to
make
sure
you
had
enough
mtu
for
your
ipv6
traffic.
So
these
are
all
good
changes,
but,
as
you
will
see
a
lot
of
the
issues
that
we
currently
have
open
that
we're
trying
to
resolve
our
follow-ons
to
these.
G
G
I
have
kind
of
all
the
content
here
to
talk
about
in
slides,
but
feel
free
to
also
look
at
the
github
issues,
and
if
we
want
to
get
really
in-depth,
maybe
we
can
switch
over
at
some
point
right.
So
the
oldest
issue
we
have
is
one
just
talking
about
you
know:
do
we
need
a
default
uri
template
kind
of
this
was
raised
by
the
fact
that
connect
udp
has
one
it
defined.
G
G
G
G
H
E
H
H
Yeah
that
provides
a
really
useful
way
of
distinguishing
this
from
the
other
things
you
might
put
in
in
configuration,
because
you
have
domain
names
in
some
cases
and
what
appears
to
be
something
like
a
uri
in
in
those
other
cases
yeah.
So
I
tend
to
think
that
essentially
requiring
people
to
use
the
full
template
configuration
is
a
better
choice.
G
G
D
Nice,
so
I'm
realizing
that
the
chairs
forgot
a
slight
update,
which
is
since
the
last
ietf,
http,
datagrams
and
connectudp
were
went
through.
Itf
last
call
were
approved
by
the
iesg
and
are
now
in
the
rfc
editor's
queue,
which
means
that
those
documents
are
pretty
much
done.
It
also
means
that
we
can't
change
them,
which
is
great,
but
I
mean
all
48.
D
A
I
I
E
I
I
G
I
I
understand
that
I'm
just
saying
you're
no
longer
actually
following
the
uri
template
engine
rules,
because
the
ui
template
engine
rules
say
that
the
target
variable
can
be
unspecified
in
the
inputs
to
your
template,
in
which
case
the
rendering
engine
will
do
something.
And
in
this
case
what
it
will
do
is
give
you
a
pair
of
slashes
back
to
back
right.
But
but
so.
G
It
will
not
like
the
update
to
the
text.
Right
is
that
in
general,
regardless
of
actually
the
well-known
or
not
if
your
uri
template
puts
these
parameters
within
the
path
segment
and
not
the
query
segment
of
parameters,
because
there
are
the
two
flavors
you
can
do
there
right
that
are
allowed
for
this.
If
they're
in
the
path
one,
then
you
must
not,
have
it
be
empty,
you
must
have
it
be
a
star.
So
that's.
I
Even
worse,
because
that
means
that
now
I
have
to
introspect
inside
this,
like
as
a
client,
I
get
a
uri
template
back,
and
I
have
my
variables
that
I
want
to
substitute
into
it.
I
can't
just
take
my
uri
template
and
my
variables
and
hand
them
to
a
uri
template
engine.
I
actually
have
to
go
disassemble
the
template
and
figure
out
which
which
template
structure
is
being
used
here
in
order
to
figure
out
whether
I
need
to.
I
I
G
I
H
G
H
H
Make
the
path
component
optional?
At
that
point
I
see
so
you
don't
need
double
slashes,
so
you
wouldn't
end
up
with
double
slashes
or
stars
or
any
other
sort
of
weird.
Probably
in
there
you
just
if
you
have
a
target,
then
then
that
component
is
added.
If
you
have
a
a
protocol,
then
that's
added
the
only
problem.
There
is
that.
G
G
H
D
David's
ganazzi,
like
I,
I
did
a
bunch
of
reading
and
please
correct
me
if
I
misread
to
figure
out
if
like
slash,
slash,
was
allowed
or
a
star
was
allowed
and
what
it
came
down
to
is
slash
inside
the
path
is
allowed,
but
there's
a
bunch
of
software
that
normalizes
it
and
then
it's
going
to
remove
one
slash
and
then
you're
going
to
have
a
sad
day.
So
we
should
avoid
slash
and
star
seemed
fine.
D
What
the
reason
I'm
okay
with
the
text
as
it
currently
is
because
ben
has
a
valid
concern
that
you
don't
want.
The
implementation
of
this.
That's
using
a
generic
uri
template
library
to
have
to
figure
out
if
they're,
in
the
path
or
not.
But
in
that
case
you
just
always
put
a
star
like
you're,
going
to
have
this
variable
or.
G
D
G
How
about
so?
What
I
would
propose
here
is
this,
like.
I
think
this
particular
issue
we
have
agreed
like
you
know,
we
don't
love
the
well-known,
but
like
it's
consistent,
so
like
we
kind
of
we
came
to
agreement
on
that
this
other
issue
that
ben
brought
up,
I
think,
is
a
separate,
a
separate
issue
of
like
having
the
stuff
in
the
path
component
and
being
ambiguous
about.
G
G
Or
maybe
yeah
we
decide
that
like,
like
the
other
way
you
do
is
like
if
you
recognize
like
it's
always
technically
star
but
like.
If
you
recognize
in
the
query,
string
that
you're
about
to
put
something
equal
star,
you
can
just
drop
it
on
the
floor.
If
you
don't
want
to
spend
the
bytes
on
it
actually.
D
G
D
G
G
G
G
You
should
do
some
icmp
through
this
to
make
sure
that
you
have
sufficient
path.
Mtu
intermediaries
are
messy
and
gross,
and
so,
as
we
were
talking,
we
were
like.
Let's
try
to
just
like.
Maybe
let's
just
ditch
the
text
that
says.
Oh,
maybe
you
could
coordinate
with
your
intermediary,
so
we
just
say:
either
you
guarantee
from
end
to
end
that
you
have
a
big
enough,
quick
connection
to
hold
your
minimum
size
or
you
do
pathetic
discovery
through
the
tunnel
and
that's
it.
D
To
to
answer
gory's
question
david
snazzy
here:
it's
let's
say
you
have
an
end
to
end
quick
connection
and
you
start
with
adding
quick
initials
to
13
whatever
the
number
is
in
there.
You'll
be
fine,
but
if
you
implement
dynamic
pmtud
inside
quick
and
your
quick
mtu
goes
down
to
something
below
that,
then
you
need
to
nuke
the
connect
ip
stream.
Maybe
we
just
need
to
add
a
sentence
for
that,
because
our
implementation
doesn't
do
dynamic
pmtud.
D
G
J
E
G
G
C
D
G
C
I
It
this
sounds
like
a
must,
but
we
know
you
won't
like
in
like
the
reality
is
that
98
of
flows
are
going
to
tolerate
this
just
fine
and
therefore,
as
a
as
a
client
implementer.
I
think
it
would
be
very
hard
to
convince
yourself,
like
yeah,
I'm
just
gonna
shut
everything
down
and
brick
the
user's
device
because,
like
you
know,
I'm
not
technically
in
compliance
with
ipv6
anymore,
as
opposed
to
like
well,
you
know
what
I
know.
I
know
I'm
not
in
compliance
anymore.
I
E
I
V4
technically
has
the
same
problem.
If
you're
you
know
at
576
or
something,
but
my
my
point
is
to
me
the
thing
that
makes
the
most
sense
to
to
just
try
to
be
as
like
limited
as
possible.
Here
is
to
say
like,
but
you
should
do
pmtud
over
the
tunnel
to
find
out
the
mtu.
If
the
mtu
falls
below
1280,
you
are
no
longer
a
compliant
ipv6
implementation
and
and
what
you
do
with
that
information
is
up
to
you.
G
We
could
make
it
a
non-normative
statement
of
essentially
saying
like
if
you
detect
that
you
are
not
able
to
provide
valid
ipv6
over
this.
You
can
abort
the
stream
and
just
say
like
you
can
and
if
you
have
something
else,
you
want
to
do
like
be
out
of
compliance
or
tunnel
them
over
reliable
datagrams
knock
yourself
out.
D
G
E
E
L
We
don't
have
any
loopholes
in
this
so
to
say,
and
then,
if
you
think
it
should
without
having
that,
should
very
hard
specific
what
it
means
you
would
end
up
in
another
problem
so
but
yeah
if
you're,
actually
having
that
saying.
Okay
and
the
problem
really
is
the
http
intermediaries
here,
because
even
if
you're
paddling
and
you
and
you
uncertain,
if
you
have
an
hp
media,
you
would
run
into
this
problem.
So
that's
why
the
master
is
supposed
to
be
there
to
cover
that
situation.
G
D
Have
a
proposal
that
I
think
everyone
might
be
okay
with,
which
is
you
know
our?
What
we
do
here?
Never
something
that
everyone
loves
is
to
say
if
you
detect
that
the
path
mtu
goes
below
the
limit
and
you
like
sorry,
let
me
rephrase
if
you
are
sending
your
ip
packets
over
datagram
and
the
path
you
detect,
that
the
path
mtu
is
no
longer
sufficient.
D
D
D
G
Okay,
thank
you
for
everyone's
input.
So
far,
next
one
all
right,
this
one,
I
think,
should
be
easier.
Previously
we
mentioned
you
can
do
icmp
when
you
have
errors
like
you
know,
let's
say
you
negotiated
a
full
tunnel
at
the
other
side
and
then
you
told
them.
Here's
your
source
address
with
an
address
assigned.
You
say
here
are
the
routes
you
can
send
to
with
the
route
advertisement
and
then
the
other
side
just
starts
sending
garbage.
That's
not
in
that
that
violates
your
acls
and
they're
being
bad.
G
That
may
be
intermixed
with
good
traffic.
You
don't
need
to
tear
down
your
entire
connection
or
your
entire
stream
to
them.
How
do
you
let
them
know
they
were
sending
bad
things
and
you
could
invent
a
bunch
of
capsules,
but
we
think
that
just
sending
icmp
errors
back
is
the
right
thing
to
do,
because
that's
they
have
the
correct
error
codes
and
that's
the
right
thing
for
this
layer.
G
It
was
kind
of
non-specific,
so
the
changes
we
did
is.
We
gave
specific
examples
of
like
hey,
probably
if
you're
trying
to
send
something.
You
don't
have
a
route
for
you
should
send
destination
unreachable
with
the
error
code
of
like
you
can't
reach.
That
thing
I
forget
which
it's
like
number
five
and
same
thing,
for
if
you
send
a
bad
source
and
if
you
send
a
packet,
that's
too
large
or
then
you
get
the
correct
error
for
that.
G
So
just
do
the
obvious
thing
for
those
and
then
the
only
other
part
of
this,
that's,
I
think,
a
bit
more
interesting.
Is
it
essentially
says
that
you
should,
if
you
were
giving
routes
about
advertisements
to
the
peer
which
not
everyone
does
but
like
in
a
peer-to-peer
vpn
case,
both
sides
give
it
to
each
other
in
the
client
to
proxy
case.
Just
the
proxy
gives
it
to
the
client
that
should
include
in
the
protocols
that
are
listed
as
allowed
icmp.
G
But
then,
essentially,
if
you
are
not
giving
routes
aside
like
the
client,
does
not
give
routes
to
the
server,
it
essentially
says
that
it
is
always
assuming
that
you
essentially
always
need
to
be
prepared
to
receive
icmp
packets.
So,
even
if
you
are
just
creating
a
ip
tunnel
for
esp,
you
need
to
handle
icmp
over
this
thing,
because
that's
how
you
get
your
errors,
any
issues
with
that.
K
G
G
G
K
G
K
N
Hi
alex
stranowski
google.
I
just
wanted
to
clarify
that
the
text
that
tommy
has
on
the
slides
here
about
the
language
is
not
the
language
which
is
in
the
pr.
I
don't
think
so.
I
think
the
commodore
and
wordsworth
thing
is
more
about
the
slide.
Please
look
at
the
pr
if
you
think
that
sure
text
needs
more
wordsmithing.
I
G
I
Black
hole,
we
could
say,
like
you,
should
not
black
hole,
icmp
that
that
might
be
nice,
but
but
the
the
important
thing
is
like
I
can
functionally.
I
can
send
icmp
yes,
including,
and
I
can
receive
icmp
replies
from
from
source
ips
that
aren't
the
target
right,
because
traceroute
in
traceroute,
the
the
source
ips
are.
O
G
There's
no
compression
here,
okay,
you
know
you
would
absolutely
get
it.
I
would
like
to
hear
other
other
authors
opinions
on
this,
because
I
don't
care
I
can
either
say
like
either.
You
say
you
only
allow
it
by
default
from
your
peer.
Otherwise
you
say
you
just
allow
all
icmp
and
just
do
with
what
you
will.
D
I'm
noticing
nerius
ghost
is
in
the
kill,
if
I'm
not
funny
so
to
answer
ben's
question
I
I
agree.
I
think
we
should
just
say
just
add
a
note
that
the
source
address
can
come
from
somewhere
else
yeah
in
terms
of
black
calling.
We
already
say
that,
like
connect,
a
pn
points,
operators
routers.
So
if
someone
wants
to
knock
themselves
out
and
read
the
hundreds
of
pages
of
rc
that
have
been
written
on
what
a
router
is
supposed
to
do,
you
should,
but
one
of
them
is
don't
blackhole
icmp.
G
D
C
G
G
G
L
So
so
mine
was
first
yeah.
I
mean
from
the
discussion
we
had
why
I
brought
this
up.
It
said
that
was
really
to
ensure
that
you
first,
the
endpoint
can
sound
nice
and
be
back
to
the
client
if
it
sends
something
bad,
yes,
and
to
also
get
the
feedback
from
beyond
the
proxy
when
it,
if
it,
for
example,
reach
port
unreachable
or
something
like
that,
the
packet
to
be
they
should
be
returned
back
if
the
the
proxy
can
actually
map
it.
Back
to
this
request,
so
cool.
C
L
C
G
N
So
hi
alex
again,
this
is
actually
an
area
which
I
tried
to
push
back
on
two
ietfs
ago
when
we
started
adding
iproto
originally
because
of
the
complexities
around
this.
I
think
that
the
only
way
we
can
resolve
this
is
that
you
can't
actually
allow
sharing
the
same
ip
address
with
different
ip
protos.
N
If
you
want
to
support
these
sort
of
hard
to
distinguish
icmp
messages
and
align
them
up
with
the
different
tenants
on
the
same
ip
so
like,
I
think
one
thing
which
is
very
clear
is
that
having
the
proxy
and
the
client
be
able
to
have
over
their
direct
point-to-point
link
exchange
icmp
about
that
is
very
easy
to
do.
But
the
moment
you
start
saying,
oh,
I
have
an
ip
proto
restriction
that
says
I
can
only
do
dcb
over
the
tunnel
and
also
want
to
get
icmp
messages
from
the
far
end.
G
That
is
a
good
point,
because
right
these
error
cases
are
such
that
the
proxy
can
recognize.
Oh,
that
icmp
was
in
response
to
this
packet
that
I
sent,
and
that
came
from
this
tunnel
right
and
essentially
it's
like.
I
think
the
proxy
should
have
the
choice
to
only
forward
those
or
if
it
thinks
you
have
full
control
over
this
ip
address
forward.
You
also
icmp
right,
so
I
think
the.
N
So
I
think
the
minimum
behavior
that
we
need
to
guarantee
is.
You
will
always
get
icmp
error,
reporting
on
the
point-to-point
link,
regardless
of
what
ip
proto
that
you
you
have
requested.
If
you
want
to
guarantee
that
you
also
get
all
icmp
messages
for
this
ip,
you
must
also
request
icmp
for
this
iproto.
G
A
E
One
last
comment:
hi,
I'm
new
to
this
mask
thing,
but
I
know
the
esp
and
ipsec
world
rfc
4301
as
a
text.
What
kind
of
icmps
you
should
allow
and
that's
basically
looking
in
the
payload,
because
icmprs
should
have
a
payload
part
of
the
packet
which
you
send
forward
and
you
look
at
that
payload
and
then
you
decide
was
it
allowed
by
the
mask.
E
C
G
Yeah,
but
I
think
it's
good
advice,
though,
because
this
is
a
that's
a
well-behaved
proxy,
that's
acting
as
a
very
nice
tunnel,
all
right
so
back
to
address
requests.
Previously
we
tried
to
fix,
address,
assign,
and
I
think
we
did
a
good
job
there.
Long
just
raised
some
good
issues
explaining
how
address
request
had
semantic
ambiguity
problems.
G
It
is
more
of
a
problem
if
you
are
kind
of
like
client
to
proxy
opening
something
out,
because
previously
the
address
request
was
just
like
an
optional
thing
that
you
send.
If
you
want
a
particular
address
and
if
you
don't
want
a
particular
address,
you
don't
send
it.
Yes,
obviously
the
the
proxy
would
never
send
that
to
the
client,
because
the
client
can't
assign
addresses,
but
the
sensible
place,
if
you
do
care
about
your
address,
is
to
send
the
capsule
for
address
request
at
the
beginning.
G
Right
after
your
actual
request,
the
server
has
no
idea,
if
you're
going
to
send
that
or
not,
and
so
it
will
receive
the
request,
maybe
give
you
200,
but
like
it's,
how
long
is
it
going
to
wait
before
it
checks?
If
you
have
an
address
request,
capsule
or
not
before
it
gives
you
an
address
to
sign
like
it
was
completely
ambiguous
and
you
could
come
up
with
some.
You
know
rule
of
like.
Oh
you
just
negotiate
out
of
band
whether
or
not
you
do
that,
but
that
was
gross.
G
There
was
discussions
about
okay,
you
can
add
a
header
to
say
I'm
going
to
send
this
capsule,
but
that
also
is
problematic.
The
proposal
here
is
just
to
say:
you
always
send
an
address
request
if
you
want
an
address
assigned,
so
there
are
different
models
of
connect.
Ip,
not
everyone
needs
an
address
assigned
because
like,
for
example,
like
the
proxy
server,
never
receives
an
address
assigned
from
a
client,
so
it
doesn't
send
an
address
request.
But
if
the
client
wants
an
address
to
sign,
it
needs
to
send
an
address
request.
G
G
G
B
G
That
works
pretty
nicely
one
other
tweak
here,
just
to
make
sure
that
if
you're
asking
for
v4
and
v6
or
if
you're
being
assigned
v4
and
v6
you
had
it
all
at
the
same
time
was
that
just
like
we
did
for
the
route
advertising
capsule,
where
we
just
had
the
capsule,
be
a
array
of
repeating
route
structures
that
have
the
different
protocol
of
families.
The
address,
requests
and
addresses
sign
capsules
can
contain
multiple
addresses,
so
you
know
the
first
one
just
says:
oh,
this
is
a
v6
address
and.
I
D
D
So
if,
if
you're
wondering
what
the
hell
tommy's
talking
about,
don't
worry
that's
normal,
but
at
least
all
of
the
editors
thought
about
it
and
thought
that
was
a
nice
solution.
That
was
really
both
simple
and
like
avoided.
A
lot
of
the
caveats
that
we
were
running
into
so
just
wanted
to
say
like
we're
we're
on
the
same
page,
I
think
this
is
a
good
way
forward.
Yeah.
I.
G
D
G
G
L
L
G
G
H
M
G
So
by
default
you
request
an
address.
If
you
want
to
be
able
to
descend
yeah
it,
it
leaves
it
open
such
that
if
you
had
some
extremely
specialized
deployment
where
you
were
like
completely
out
of
bed,
you
you
just
know,
you
always
have
this.
It's
a
static.
I
don't
know
what
it
is
like
or
potentially,
even
if
you
have
an
extension
in
the
future,
where
you
say
I
don't
actually
put
in
source
ips,
I
let
the
proxy
write
my
source
ip.
For
me.
I
know
I
don't
need
to
actually
write
anything
here.
G
G
C
D
The
the
idea
there
is
say,
if
think
of
it,
kind
of
like
dhcp.
If
you
don't
ask
the
dhcp
for
an
address,
you're
not
going
to
get
one
and
you're,
probably
not
going
to
get,
you
might
not
necessarily
get
the
one
you
ask
for
if
someone
else
has
taken
it.
So
the
idea
is,
if
you're
expecting
it
to
assign
you
an
address,
you
send
that,
but
let's
say
you're
a
vpn
and
in
your
via
config
file,
you
put
a
static
ip
address,
you're
not
going
to
send
dhcp
over
the
vpn.
G
C
I
G
G
Connect
ip
already
has
an
issue
with
knowing
what
source
ip
to
send
from
in
general.
So
actually
in
some
ways,
this
makes
it
better.
So
if
I'm
thinking
of
like
full
tunnel
vpn
or
whatever
I
don't
know
but
like
if
I'm
requesting
a
specific
address,
because
let's
say
I
knew
a
specific
address,
I
had
received
on
another
stream
previously,
I
could
you
know
optimistically
say:
please
give
me
that
same
address.
I
will
send
my
initial
packets
from
it.
You
may
drop
them.
G
I
H
I
G
G
I
G
I
D
G
E
I
G
L
F
G
I
don't
think
so.
So
we've
talked
about
error
handling
in
general.
I
I
think
it's
certainly
plausible
that
some
future
extension
that
wants
more
complex
semantics
for
different
types
of
assignments
could
add
some.
Oh,
I
didn't.
I
rejected
this
capsule.
I
rejected
that,
but
I
think,
if
you
do
something
like
try
to
assign
your
server
address,
it
just
decides
if
it
either
ignores
it
or
says
you're
a
misbehaving,
client
and
closes
on
you.
H
E
C
So,
just
because
you
send
an
address
assigned,
it
doesn't
mean
that
you
get
the
address
or
sign.
So
if
you
receive
an
address
assigned,
you
just
should
send
a
request.
No
sorry,
the
other
way
around,
if
you
get
a
request,
doesn't
mean
that
you
actually
get
that
ip
address
right.
So
if
you,
if
you
get
a
request,
you
should
just
send
in
a
sign
with
the
ap
address
that
you
assigned
yes.
G
And
vice
versa,
like
if,
if
the
client
sends
a
proxy
like
I've
assigned
you
this
address,
what
you're
telling
proxy
is
hey,
I'm
a
client
and
I
will
accept
if
you
send
packets
to
me
from
that
address
like
proxy's
like
okay,
I
don't
really
care,
I'm
not
going
to
send
anything
to
you
anyway
from
that
address.
But
thanks
for
letting
me
know,
it's
like
you
can
give
out
your
phone
number
to
whoever
you
want,
but
it
doesn't
mean
they'll
call
you.
H
F
H
H
Expect
to
see
some
sort
of
indication
that
that
when
you
ask
for
something
the
the
server
has
acknowledged
that,
because
there's
this
particular
arrangement
has
this
weird
property,
whereby
in
a
lot
of
cases,
the
server
is
just
going
to
go
here
have
a
bunch
of
addresses
as
soon
as
the
connection
is
established,
and
it
doesn't
really
depend
on
seeing
a
a
request
in
that.
In
that
case,.
E
G
G
Both
an
assign
and
a
route
advertisement,
and
so
on
the
client
you
can
wait
around
for
those
and
essentially
like
I
don't
know
if
I
don't
get
it
immediately,
if
it's
because
you're
taking
a
while
to
actually
figure
out
what
address
I
have
I'll
have
to
have
some
time
out
there.
I
know
it's
a
reliable
stream,
so
I
know
you
received
the
thing,
so
we
can
say,
like
the
server
must
eventually
reply
once
it
can
actually
assign
it.
Otherwise
it
should
close
the
stream
to
be
nice.
N
So
I
think
this
is
a
bug
of
something
that
we
accidentally
glazed
over
when
we
were
talking
about
this
okay,
I
think
when
we
made
it
such
that
every
ad,
I
think
in
the
previous
version
of
a
draft
address,
request,
always
got
an
address
assigned
response,
but
now
that
we've
made
it
repeated
and
fallible,
I
think
we
need
to
define
that
if
you
get
a
request
that
cannot
be
satisfied
because
we
want
to
give
you
no
addresses
back
whatsoever.
We
still
need
to
indicate.
G
O
H
So
I
I
think,
there's
that
that
helps.
I
don't
think
it
completely
addresses
the
the
suite
of
problems
that
are
now
possible.
So,
in
the
case
that
you
ask
for
say,
you
ask
for
one
address
or
two
addresses
and
the
server
says:
no,
you
can't
have
either
of
them.
I
think
it's
reasonable
to
have
either
an
error
message
coming
back
or
even
just
address
a
sign
empty
yeah,
yes,
which
that's.
H
B
G
So
if
we
have
it
be
cumulative
which
I
think
we
probably
need
to
clarify,
then
it
is
unambiguous
that
when
you
receive
it,
this
is
this
is
all
of
the
addresses
you
have,
and
so
it
doesn't
really
matter
at
that
point
like
if
there
was
a
race,
like
maybe
I'll,
end
up
getting
two
of
them
that
are
duplicates.
If
you
want
to
generate
an
extra
one
in
response
to
me,
but
they
are
fully
describing.
H
G
H
L
Thank
you.
I
want
to
try
to
respond
to
ben
ask
about
the
crt
cases.
Initially,
I
don't
think
they
work.
Currently,
I
don't
think
you
can
do.
I
think
we
need
some
type
of
extension
saying
that
hey
I'm
going
to
send
your
pack
of
resource
address.
Please
rewrite.
I
think
this
actually
ends
up
being
something
you
need
to
signal
explicit,
because
otherwise
you
end
up
in
or
use
the
zero
zero
or
something
you
need
to.
We
need
to
specify
something
for
we
can't
leave
it
as
it
now
so
I
well.
I.
G
G
L
I
think
when
you
responded
to
them
before
it
sounded
much
much
wider,
that
basic
anything
would
work
and
I
think
that's
wrong.
You
need
to
have
some
really
high
probability
that
you
know
what
the
address
is
going
to
be
to
make
this
work
or
we
need
to
have
something
either
specified
behavior
or
an
extension.
G
Which
is
the
case
with
all
remote
access
vpns
today,
yes
anyway,
but
you
know
if
this
is
a
large
enough
tunnel
that
this
is
like
this.
Is
I'm
going
to
be
able
to
send
my
entire
device's
ip
traffic
over
this?
That
one
rtt
is,
I
think,
okay
and
if
I'm
doing
very
specific
flows,
I
probably
have
a
previous
address.
I
can
request.
I
I
G
No,
if
I
have
a
previous
address
so
let's
say
I
have
one
quick
tunnel
to
my
connect.
Ip
server
and
I've
previously
opened
other
streams.
I've
already
opened.
I
see
a
an
sctp
stream
to
that
host
and
I've
opened
an
sctp
stream
to
this
other
host.
I
can
just
say
give
me
another
smp
stream
from
the
same
address.
G
I
O
K
I
G
I
G
A
N
So
I
wanted
to
reply
to
ben
and
actually
try
to
clarify
some
of
the
things
which
I
think
there's
some
confusion
here.
So
there's
a
couple
different
modes
of
using
connect
ip,
I
think,
broadly
speaking,
the
dynamically
assigned
openvpn
case.
Zero
rtt
is
almost
never
going
to
work
because
you're
going
to
be
assigning
these
ip
addresses
to
a
virtual
network
device
on
the
host
os
anyway.
So
I
personally
consider
their
zero
rtt
to
not
be
a
priority
or
a
goal.
I
N
N
Else
yeah,
but
the
other
thing
I
wanted
to
mention
here
is
that
you
never
have
a
guarantee
a
packet
delivery
here
if
it
went
over
a
datagram
so
like
even
to
your
earlier
comment
of
like
I'd
like
to
get
back
on
icmp
earth,
it
was
lost
somewhere
on
path,
you're
not
going
to
get
it.
So
all
of
those
things
around
the
other
commentary
around
like.
Is
it
going
to
be
written
with
an
extension?
N
If
we
have
that
in
the
future,
like
you
could
imagine
having
an
extension
of
like,
please
go
be
right
to
my
target
ip,
why?
I
might
send
you
garbage
source
bits
and
if
that
gets
sent
before
the
package
is
processed,
then
yes,
you
should
expect,
but
that
would
work,
but
that's
not
currently
defined
in
the
base.
H
O
C
D
So
actually,
this
is
relevant
to
what
I
wanted
to
ask.
I
think
part
of
the
earlier
discussion.
We
changed
something
that's
not
currently
in
the
pr,
but
I
think
is
a
good
change,
which
is
to
say
that
now
address
assign
is
cumulative.
Yes,
and
I
know
again
I'm
going
to
write
it
and
that
solves
some
of
these
problems.
So
let's
say
you
know
if
you
I'm
only
assigning
you
one
instead
of
two
like
you
can
see
that
so
that's
nice,
I
just
want
yeah,
I
guess
so.
Yeah.
D
G
Right
and
like
I
think
it
should
still
be
permissible
to
assign
only
zero
addresses,
because
potentially
in
a
side-to-side
vpn
case,
there
may
be
a
moment
when
all
connectivity
is
lost
and
then
they
bring
it
back
online
and
you
don't
necessarily
need
to
tear
down
your
quick
streams.
Yeah,
like
I
mean
I
don't
think
it
should
be
forbidden.
D
To
do
that
yeah,
I
don't
think
we
need
to
say
anything.
Let's
say:
yeah
cool,
okay!
No!
I
just
wanted
to
make
sure,
because
I
was
kind
of
a
non-trivial
change
to
the
pr
that
we
had
the
editors
had
agreed
to.
I
just
want
to
make
sure
that
no
one
objects
to
that,
but
it
does
seem
to
solve
quite
a
few
things
nicely
and
on
top
of
that
it
becomes
fully
consistent
with
route
advertisement,
which
is
just
next
exactly.
G
A
I
A
I
So
I
think
that
it's
reasonably
likely
that
you'll
have
connect
udp
and
connect
ip
and
doe
all
offered,
essentially
as
a
package
meaning
tied
to
the
same
user
accounts
intended
to
be
used
together
as
a
as
service.
I
think
it's
reasonably
likely
that
you
could
have
a
doe
resolver
this
associated
with
an
old-fashioned
connect,
tcp
proxy.
I
Next,
and
so
the
realization
for
me
is
that,
although
that
we
have,
I
think,
all
these
different
potential
use
cases.
They
actually
are
all
instances
of
a
of
a
single,
pretty
simple,
general
problem.
We
need
a
machine
that
takes
as
an
input
a
url
or
an
origin,
or
you
know,
could
be
just
kind
of
a
string
and
its
output
has
one
or
more
of
these
different
kinds
of
services
that
we've
begun
to
define
both
here
in
mask
and
in
ojai
and
potentially
anything
else.
I
I
This
proxy
has
a
doe
server,
a
connect,
udp
endpoint,
a
connect,
ip
endpoint
and
an
ohio
relay,
and
so
like,
rather
than
saying,
oh
client,
you
know
your
user
interface
has
like
four
different
text:
entry
fields
and
you're
supposed
to
go
in
and
paste
one
after
another,
all
of
the
different
all
the
different
uri
templates.
For
all
of
these
different
services,
we
can
say,
look
we're
standardizing
a
format,
and
so
your
your
user
interface
has
a
single
input
field,
and
that
is
maybe
a
url
hosting
a
file
like
this.
I
Maybe
you
know,
maybe
even
literally
a
file
picker,
and
this
thing
is
if
this
thing
is
actually
a
file,
that's
being
passed
around
next.
Here's
another
example.
This
is
how
oblivious
doe
would
be
represented
in
this.
So
again,
we're
we're
tying
a
doe
service
to
some
other
kinds
of
access
services,
in
this
case,
a
gateway
which
helps
you
get
to
that.
Doe
endpoint
and
again
it's
just
a
very
simple
json
format.
F
I
So
the
idea
for
this
draft
is
that
probably
access
services,
all
these
different
sort
of
composite
services
that
I've
been
talking
about,
are
generally
identified
by
a
url,
and
that
is
the
url
of
an
access
service
description.
It's
a
url
that
you
send
a
get
request
to,
and
it
sends
you
back
a
json
object,
except
there
are
some
cases
where
that
doesn't
work
where
for
a
legacy
reason
or
for
interoperability
with
some
other
system,
the
only
identifier
we
have
is
an
origin
or
a
host
name.
We
don't.
I
I
Okay,
so
like
we
can
solve
any
problem
by
introducing
an
extra
level
of
indirection,
and
so
this
is
just
a
level
of
indirection.
Instead
of
passing
connect,
udp
uri
templates
around
we
pass
around
a
file
containing
well
a
url
of
a
file
containing
connect,
udp
templates-
and
I
think,
there's
a
bunch
of
useful
stuff
that
this
enables
like
you
can.
I
If
you
want
to
do
fast,
http,
3
bootstrap,
you
need
in
well
you
you
arguably
need
a
https
records.
You
need
to
be
able
to
query
https
records
out
of
the
dns,
but
you
can't
do
that
unless
you
actually
have
a
dns
server
that
you
can
use,
know
the
proxy
can't
do
a
connect.
Udp
proxy
can't
do
that
for
you.
So
you
want
a
dose
server
associated
with
your
connect
udp
proxy,
because
the
whole
point
of
connect
udp
is
to
be
able
to
use
http
3..
I
So
you
know
we
can
enable
that
we
can
enable
encrypted
client
hello
through
a
proxy,
and
we
can
make
that
work
even
for
these
sort
of
legacy.
Cases
like
the
ones
that
we
were
talking
about
just
an
hour
ago,
where
our
bootstrap
input
is
a
hostname,
because
we're
we're
stuck
in
the
in
the
legacy
world,
where
we're
we're
configuring
old-fashioned,
proxies
that
aren't
a
full.
F
I
There's
some
growing
interest,
seemingly
in
client-side,
dns
validation.
That's
another
case
where
the
client
needs
direct
dns
access
that
a
proxy
like
connect2udp
doesn't
offer.
I
also
think
there's
another
sort
of
category
of
interesting
ways
that
this
can
be
useful
and
that
is
helping
the
client
to
learn
more
about
the
capabilities
of
the
access
service.
So,
for
example,
you
know
we're
about
to
talk
about
connect
udp
in
listener
mode.
I
I
One
request
right,
so
you've
got
it
in
http
500,
but
you
don't
know
that
you're
always
going
to
get
a
500
talking
to
that,
and
even
if,
even
if
you
sort
of
are
willing
to
buy
that
that
you
can
sort
of
probe
for
the
capability
to
find
out
if
it
exists,
it's,
it
certainly
seems
like
more
work
than
just
being
told
at
startup.
Like
here's,
the
capabilities
of
this
thing,
you
can
evolve
the
capabilities
of
your
service
right.
I
I
So,
oh
and
finally,
this
format
is
a
is
sort
of
a
perfect
fit
for
key
consistency,
double
check,
which
I
was
talking
about
yesterday
in
in
ojai,
because
again
that's
a
case
where
we
need
to
grab
something
like
an
oblivious
doe
configuration
as
a
you
know,
and
and
and
essentially
treat
it
as
an
atomic
unit.
And
so
here
we
have
a
format
for
representing
those
as
an
atomic
unit.
So
I
think
this
is
a
useful
thing.
It's
dead,
simple
and
I
think,
mask
would
be
a
good
place
to
work
on.
A
K
Quickly,
google,
thank
you
for
thinking
this
through.
Thank
you
for
bringing
it
to
the
working
group
in
our
infinite
wisdom.
We
specifically
excluded
proxy
discovery
from
the
charter,
doesn't
mean
we
can't
recharge
it.
Of
course,
I'd
be
interested
in
the
communities
to
use.
If
mask
is
the
right
venue
for
this
or
many
or
one
of
the
many
other
working
groups
that
this
would
touch
thanks.
G
All
right,
tommy
polly,
so
thanks
for
bringing
this
up,
I
think
it's
a
very
important
conversation
to
have
in
general.
I
feel
like.
I
should
like
this
direction
and,
like
you
know,
certainly
in
the
deployment
we
have
of
mask,
we
have
config
files.
That
say
this
is
a
thing
that
is
a
ohtp
relay
and
a
connect
proxy
and
a
connected
udp
proxy.
It's
like
it.
It
feels
similar,
however,
like
I'm
not
convinced
about
this
particular
shape
for
it.
G
I
think
it's
combining
more
than
we
need
to
particularly
about
like
locations
and
keys
and
capabilities,
trying
to
all
be
in
one
json
thing:
it's
like
both
too
much
information,
that's
available
to
everyone
in
one
flat
way.
That
may
not
be
specific
enough,
but
there's
also
not
enough
information
to
actually
be
fully
useful
for
each
of
these
use
cases.
G
I
think
also,
you
know
a
lot
of
people
aren't
going
to
be
opening
running
fully
open
proxies
like
it's
one
thing
to
say:
I'm
a
proxy,
but
even
today,
like
on
the
internet
like
you're,
not
going
to
have
a
proxy
that
you
don't
have
authentication
to
that.
Just
lets
you
do
like
here.
I
just
have
connect
udp
connect,
oh
http,
just
like
the
whole
world.
I
think
anything
around.
G
This
would
need
a
lot
of
like
acls
of
like
I
allow
ohtp
relays
to
these
gateways
or
like
a
lot
more
specificity,
which
feels
like
they
need
to
be
separate,
configs
for
those
different
protocols
and
also
be
related
to
an
authentication
source
like
if
I'm,
a
client
who
has
authentication
to
use
this
particular
proxy
in
this
manner.
I
have
access
to
these
services,
but
people
who
are
just
random
people
who
typed
in
a
string
into
their
browser
should
not
have
the
full
capability.
F
Jonathan
yeah,
I
think
my
my
theory
was
sort
of
similarly
but
more
narrowly
I'm
since
this
is
configuring.
Things
from,
I
think
I
think
at
least
four
different
working
groups
and
possibly
five
I'm
dubious
whether
you
could
do
them
all
in
one,
as
opposed
to
each
working
group
defining
its
own
configuration.
Maybe
like
you'd,
have
some
here's
the
bucket
to
put
things
in
and
then
each
working
group
would
do
it's
how
you
configure
its
protocol,
but
I'm
dubious
about
you
know,
defining
things
for
ojai
or
deep
deep
in
this
work
group.
D
I
Sure
so
the
the
the
easiest
example
for
me
is
that
this
this
the
use
case,
I'm
principally
targeting
here,
is
exactly
the
the
use
case
that
we
were
just
talking
about
with
the
dot
well
known,
uri
temp,
the
fix
dot
well
known,
template
for
for
connect
ip.
So,
like
that's
a
simple
case
where
you
are
you
you've
provisioned
a
bunch
of
devices
and
they
have
authorization
to
use
an
http
connect
tcp
proxy,
and
you
want
to
augment
that
with
a
bunch
of
extra
services.
And
so
the
way
we've
started
to
try
to
do.
I
My
view
is
that
those
are
not
good
solutions,
as
I
mentioned
earlier,
they
have
a
bunch
of
problems.
For
example,
they
break
the
http
model
of
of
requests,
because,
if
I
make
a
request
to
if
I
populate
that
uri
template
in
order
to
issue
a
request-
and
I
get
back
a
404
or
something
like
all-
that
says-
is
that
that
one
particular
uri
doesn't
exist.
I
It
doesn't
tell
me
that
whether
the
uri
template
itself
is
valid
or
whether
there's
some
other
set
of
inputs
that
I
could
put
in
that
would
actually
work
that
also.
It
means
that
I
need
to
to
find
out
the
capabilities
of
this
thing.
I
need
to
send
a
bunch
of
different
probes.
I
need
to
separately
probe
all
the
different
capabilities
that
I'm
interested
in.
I
can't
just
ask
what
are
the
capabilities
associated
with
my
local
proxy,
so
that
to
me
is
like
a
very
simple
use
case
and
you
know
moving
forward.
I
It
has
tcp
udp
ip
ohi
and
do
all
in
it
and
any
of
those
can
change
later,
and
you
know
the
there's
a
standard,
so
my
my
phone
knows
and
for
authentication,
probably
you
know,
there's
some
kind
of
like
oauth
authentication
flow,
it's
a
unified
authentication
for
all
of
those
services.
So
I
I
o
auth
once
and
that
that
you
know
those
credentials
then
are
used
across
all
of
these
services.
So
I
don't
have
to
re-authenticate
to
all
of
them.
D
I
I
mean
I
am
interested
in
implementing
this
on
android,
for
example.
I
would
like
this
to
be
an
android
system
settings
that
I
can
drop
into
android
and
say
like
under
my
vpn
settings,
I'd
like
to
have
a
mask
vpn
setting
where
I
can
drop
in
essentially
one
of
these
one
of
these
urls
and
then
not
just
get
connect
ip
but
get
the
whole
suite
of
associ
of
access
services
associated
with
one
of
these
complex
services.
D
Okay,
that
sounds
interesting
then,
to
your
to
the
second
question:
I
because
this
touches
on
dough
on
oh
hi,
on
dns
sec.
I
don't
think
that
mask
is
necessarily
the
right
place.
I
think
that
the
the
the
layer
that
this
operates
over
http
you're
describing
all
the
things
that
you
can
do
with
http,
though
dns
sec
sticks
out
on
the
side,
but.
D
I
O
Sorry
sure
so,
mike
bishop
I'll
be
very
brief,
respectfully
disagreeing
that
this
is
not
actually
discovery
of
the
proxy.
This
is
discovery
of
the
proxy's
abilities
once
you've
been
configured
with
a
proxy,
so
I
think
there
is
a
lot
of
value,
because
no
typical
user
is
going
to
know.
Oh
this
supports
udp,
but
it
doesn't
support
ip
and
it
does
support
oblivious
hd.
Who
even
knows
what
these
things
are
outside
of
this
building.
O
You
give
it
a
host
name,
it
lights
up,
interesting
privacy
services.
I
think
this
is
useful.
I
think
the
the
question
of
crossing
groups
is
easily
solved
by
it
has
niar
registry
each
group
can
register
their
own
config
thing,
and
it's
just
a
list
of
supported
services
at
this
at
this
host
name
now.
Does
it
belong
here?
Does
it
long
and
dispatch?
I
don't
know
all
of
these
are
reasonable.
Somebody
needs
to
define
it
and
everybody
else
needs
to
register.
N
G
A
D
Right
did
I
have
eight
minutes.
Yes,
indeed,
cool
everyone,
I'm
david
scanasi,
and
so
this
is
a
draft
that
came
out
of
a
conversation
with
tommy,
where
we
were
talking
mainly
about
connect
ip
and
forever.
I
don't
even
remember
what
specifically
we
were
arguing
about
doesn't
matter,
but
tommy
mentioned.
Oh,
I'm
gonna
run
webrtc
over
connect
ip,
and
I
thought
that
sounds
wrong
and
tommy
was
like
well.
No,
it's
super
easy.
I
inject
my
user
space
ip
stack
right.
Underneath
my
user
space
udp
stack
underneath
my
stuff
and
boom
it
just
works.
D
D
So
that's
what
this
draft
is,
but
at
the
end
of
the
day,
like
the
question
that
I'm
asking
the
working
group,
the
most
is
which
direction
do
we
want
to
take
for
browsers,
doing
webrtc
over
mask?
Do
we
want
an
extension,
connector
dp
or
do
we
want
to
use
connect
ip?
That's
the
real
question
for
the
working
group.
I'm
going
to
quickly
run
you
through
next
slide.
Please.
D
D
So,
let's
see
how
this
works
so
the
way
it
works
today
alice
talks
to
the
stunt
server.
The
stun
server
is
also
talking
to
bob.
It
tells
bob
alice's
address
and
then
alice
and
bob
could
talk
directly.
Of
course,
there's
a
lot
more
positive
complication,
but
for
the
purpose
of
this,
that's
what
matters
next
slide
please
and
they
can
have
their
very
interesting
voice.
Call
next
slide.
D
So
now,
if
we
have
a
proxy
in
the
mix
that
we
want
to
do
mask
with
alice
is
going
through
the
proxy
for
everything.
The
proxy
talks
to
the
stun
server.
The
stun
server
tells
bob
the
address
of
the
proxy
bob
talks.
The
proxy
next
slide
please,
and
they
can
have
this
time.
Their
very
interesting
voice
call
again
next
slide.
D
D
D
We
should
like
shut
this
name,
but
not
today,
and
then,
instead
of
just
sending
udp
payload,
oh
yeah,
this
registers
a
context
id
which
was
the
extensibility
mechanism
built
into
connect
udp,
and
then
you
use
that
context
id
and
when
that's
present
you
send
your
ip
address
and
udp
port
with
each
datagram.
So
when
you're
sending
from
the
client
that
gives
you
the
target
from
the
when
the
proxy
gets
it,
it
sends
it
to
that
target
when
it
gets
something
from
a
target.
D
It
puts
those
fields
in
there
when
it
sends
it
to
the
client.
So
it
knows
what
the
source
was
dirt
simple
and
that
allows
you
to
build
stuff
on
top
of
it
and,
as
usual,
it's
turtles
all
the
way
down
next
slide
and
so
discuss.
I
I
mainly
want
to
hear
about
the
this
versus
connect
ip,
but
any
other
questions
on
this.
Do
we
think
this
is
reasonable?
Where
do
we
go
from
here?
F
J
O
D
F
G
So
looking
at
this,
I
think
this
is
simple
and
straightforward,
and
the
problem
with
the
connect
ip
variant
of
it
is
that
you
don't
really
have
a
port
allocation
service,
and
so,
like
you,
get
too
much
on
this,
so
I
think
this
is
cleaner
for
that
regard.
So
I
think
we
should
just
adopt
it
and
do
it
and
I
think
it's
a
very
nice
extension
and
it's
actually
the
most
compelling
extension.
I've
seen
to
actually
use
a
context
id
and.
I
I
This
thing
is
basically
turned,
and,
and
so
we
should
take
a
good
look
at
turn.
One
of
the
things
that
turn,
I
believe
does
is
make
some
recommendations
about
the
kinds
of
nat
policy
that
that
servers
ought
to
offer.
It
basically
says
that
you
should
do
address
restricted.
Not
I
think
you
know
we
don't
need
to
make
a
strong
recommendation,
but
we
should
remind
people
to
think
about
now.
D
D
If
we
wanted
to
and
then
the
way
I
think
about
it,
it's
a
I
think,
full
code
nat,
I
never
remember
to
which,
which
kind
of
mad
is
which
all
right
anyway,
at
the
end
of
the
day,
it's
an
app
where
you're
sending
stuff
to
your
mask
proxy
and
it's
coming
out
with
another
address,
and
then
it's
doing
that
mapping
so-
and
you
have
just
one
not
biting
in
this
case,
but
it's
such
a
way
that
multiple
people
can
respond.
Martin.
K
K
And
I
have
to
agree
all
right
that
that's
a
reasonable
like
to
me
it's
more
ambiguous
than
that,
but
nonetheless,
like
I
think,
that's
a
valid
interpretation.
If,
like
this,
is
better
than
connect.
Ips
like
we
can,
we
can
fix
it,
but
I
think
we'll
have
to
consider
that
a
little
bit
and
see
if
anyone.
M
Okay,
I
I
think
this
extension
is
neat
in
the
sense
that
you
know
it's
it's
a
fairly
small
extension
on
top
of
something
we
already
have.
That's
already
been
running
in
production
services
for
a
while
and
enable
something
that
is
useful.
While
we
work
on
connect
udp,
it's
complementary,
yeah,
there's
some
technical
stuff.
We
need
to
sort
out,
but
I
I
would
support
this
doing
this
work
if
it
doesn't
quite
fit
the
charter
as
written.
I
think
that's
a
great
thing
to
to
think
about
for
the
charter
considerations.
D
C
It
could
have
been.
It
does
feel
like
a
nice
hack
to
me
and
then
so,
but
like
I'm
wondering
why
like,
if
this
is
a
hack,
then
the
right
solution
would
be
connect
ip
and
like.
If
you
want
port
numbers,
then
have
an
extension
to
get
port
numbers
on
connect.
Ap
like
why
doesn't
connect
ip
give
you
what
you
want.
D
L
D
That's
a
good
point,
and
actually
that's
a
policy
thing
that
we
could
totally
say
in
the
spec.
It
wouldn't
change
any
of
the
encoding,
but
that's
a
good
point.
We
should
think
about
that
and
you
have
more
expertise
than
I
do
unturned
stuff.
So
I
agree
all
right.
That's
that's
it
for
me
on
this
one
back
to
you
eric.
A
Thank
you,
david
all
right,
we've
come
to
the
fun
part
of
things.
So,
as
david
noted
earlier,
both
http
datagrams
and
connect2udp
are
now
in
the
rfc.
Editor
queue.
So
a
huge
massive
thanks
to
everybody
here
and
remote
for
all
of
the
discussion
and
really
good
engagement
and
reviews
of
those
documents.
A
They
underwent
significant
evolution
from
their
inception
to
where
they
are
now
and
that's
awesome.
So
thank
you
all
for
that.
You
should
be
super
proud
of
that
connect.
Ip
is
our
last
remaining
item
there
and
we're
making
some
pretty
good
progress
on
that.
We've
made
good
progress
so
far
in
our
last
two
hours
right
here,
so
we're
gonna
keep
iterating
on
that
trying
to
achieve
interop
close
out
as
many
of
the
issues
as
we
can
and
once
we've
got
some
good
interop
and
the
issues
are
drained.
A
A
So
that
means
that
there
are
places
where
we
might
extend
functionality
within
quick
or
within
http,
and
there
are
long-lived
working
groups
to
handle
long-term
maintenance
of
some
of
those
things
and
we're
trying
to
talk
about
right
now
kind
of
what
is
the
boundary.
Where
do
we
say?
We've
done
the
initial
set
of
things
that
we
need
for
mask
and
anything
for
maintenance
beyond.
This
can
be
deferred
to
one
of
the
kind
of
more
broadly
scoped
groups.
A
So
we've
had
a
lot
of
discussions
so
far
in
the
initial
kind
of
generic
underpinnings
of
mask,
as
we
define
them
and
in
as
part
of
those
discussions
we've
had
a
number
of
different
people
propose
things
that
we
say.
Oh
yes,
this
can
be
done
as
an
extension
and
we
want
to
make
sure
that
there
is
a
time
and
a
space
to
talk
about
those
things,
and
so
that's
kind
of
what
we're
proposing
the
next
phase
of
rechartering
for
mask
looks
like
as
part
of
that.
A
A
Do
we
want
to
instead
offer
some
criteria
for
extensions
and
say
we
want
to
do
extensions
of
this
type?
Do
we
want
to
be
completely
open-ended
and
say
we
think
that
there's
a
small
list
of
extensions
that
people
actually
need
and
are
planning
to
deploy
and
that
that's
going
to
kind
of
run
itself
down
once
we
get
to
a
place
where
most
people
are.
You
know
happy
that
we
have
a
deployable
thing
and
then
we'll
close
things
down.
A
So
that's
something
that
we'd
really
really
like
some
feedback
on
the
core
underlying
principle
that
I
think
we're
proposing
and
that
I'd
love
to
discuss
right
now.
In
addition
to
what
kind
of
criteria
we
should
lay
out,
but
the
the
core
principle
that
I
think
we're
currently
going
for
is
we
want
to
include
things
in
this
charter
that
are
needed
to
make
mask
actually
work
for
real
in
the
real
world
with
real
people.
A
A
If
it's
not
making
mask
work,
it's
not
for
real
people
or
it's
not
in
the
real
world.
The
current
proposal
is
that
we
keep
that
out
of
the
next
charter
that
has
one
big
asterisk
next
to
it,
which
is
around
discovery
and
proxy
discovery,
because
people
do
kind
of
need
to
do
some
form
of
that.
Sometimes
that
means
there's
a
text
field
you
type
something
into,
and
so
we
can
talk
about
that.
So
I
see
we
have
two
people
in
the
queue
we're
going
to
open
it
up
for
hop
in
the
queue
now.
A
This
is
the
happy
moment
to
express
your
opinions,
but
the
things
we're
most
interested
in
focusing
on
are
first,
what
kind
of
criteria
should
we
have
for
what
we
want
to
include?
What
is
in
scope
for
our
next
set
of
work
and
out
of
scope?
Two:
are
there
specific
things
that
we
need
in
order
to
make
mass
work
in
the
real
world
that
we
haven't
thought
about,
and
three
is
there
anything
from
this
list
that
we're
missing
david
you're?
First.
D
I
would
say
quickly,
but
you
know
I
guess
two
years
as
quickly
so
we
had
a
great
charter.
However,
now
that
we're
done
with
those
branching
like
deciding
what
we
want
to
work
on
next
to
me
should
be
a
matter
of
who
wants
to
do
the
work
who
wants
to
write
documents.
We
want
to
implement
this
who's
going
to
use
this,
and
I
don't
think
that
we
need,
like
the
help
of
the
charter,
to
scope
us
down
that
like
if
we
tighten
it
too
much,
it
would
get
in
our
way.
D
So
I
would
recommend
to
be
very
open
in
terms
of
extensions
to
connect,
udp
or
connect.
Ip
are
all
on
the
table.
Things
like
discovery
is
on
the
table.
The
the
other
things
you
phrased,
as
how
do
I
make
this
work
is
on
the
table.
Maybe
if
someone
wants
to
write
an
ops
document
of
how
do
you
run
a
fleet
of
mask
proxies
that
could
be
on
the
table
and
then
our
gate
for
whether
we
work
on
something
or
not?
Is
the
adoption
call?
G
G
It
may
be
worth
mentioning
in
the
charter,
like
other
than
just
like
open-ended
extensions
of
all
types
like
suggested
areas,
and
it's
like
some
of
the
things
that
just
came
to
mind
are
like
one
thing:
we
want
to
make
sure
we
have
enough
extensions
to
use
the
extensibility
points.
We've
created
like
context
ids
the
udp
list.
One
uses
that
but
like
making
sure
we
exercise
the
mechanisms
we've
defined
is
a
good
goal,
adding
extensions
to
do
like
obvious
functional
proxying
things
like
udp.
G
Listen
like
this
is
a
new
functional
capability
of
a
proxy
that
was
missing.
I
think
that's
a
very
obvious
category
and
then
also
things
that
make
this
proxy
more
efficient.
I
think
that
includes
compression,
or
we
have
our
stuff
for
forwarding,
but
there's
like
things
to
make
this
stuff
work
faster
or
make
sure
you
can
do
the
zero
rtt
requests.
G
I
think
that's
another
category
of
good
benefit
since
it's
open-ended
and
we
don't
want
this
to
be
a
forever
working
group.
Maybe
one
suggestion
would
be
to
have
like
a
time
box
to
re-evaluate
to
say,
like
we
will
operate
in
this
mode
for
two
years
or
three
isu
can
decide
for
how
long
and
then
we
will
reevaluate
how
those
extensions
are
going
and
decide
to
say.
G
Yes,
this
is
active
or
like
no,
these
have
become
this
trailing
edge
and
we
need
to
stop
but
give
ourselves
a
box
with
regards
to
discovery,
I'm
okay,
leaving
it
out
for
now,
because
I
think
that
is
a
much
broader
discussion
than
we
need
for
this
group,
but
I
could
be
convinced.
Otherwise,
if
people
are
very
passionate
about
that
belonging
here,
but
I
think
it's
good
to
have
a
place
where
we
can
talk
about
the
protocol
bits.
B
Well,
spencer,
dawkins
gosh,
you
all
are
good
at
generating
questions
before
I
get
to
the
mic.
I
want
to
make
sure
I
understood
you
correctly
when
you
were
saying
you
said
two
things
back
to
back
and
you
were
talking
about
maintenance
going
to
other
working
groups
like
like
https
or
or
wherever
with.
A
E
A
B
I
understand
that
that's
a
mass
thing
for
mass,
but
if
I'm
understanding
the
conversation
correctly,
it
was
also
a
mock
thing
for
mock
this
morning
and
if
I'm
remembering
correctly,
we've
gone
through
a
couple
of
rounds
of
chartering
working
groups
where
you
know
discovery
was
out,
you
know
was
without
a
scope
and
I
feel,
like
somebody's
gonna
have
to
be
able
to
discover
something.
Somehow,
eventually,
you
know
at
some
point
so
whether
that
happens
here
or
somewhere
else
or
in
the
right
place.
B
I
Let's
go,
I
don't
think
anybody
knows
what
discovery
means
to
the,
and
I
think
that
that's
probably
because
it
doesn't
actually
make
sense
in
the
context
of
mask
you
don't
discover
a
mask
server.
I
think
configuration
is
important
unsurprisingly
and
should
be
in
scope.
I
think
client
authorization
is
as
we've
just
been
discussing
is
important
and
should
be
in
scope.
L
A
K
30
seconds,
I
promise
I'm
inclined
to
recharter.
I
do
not
have
strong
convictions
about
the
technical
content
of
that
recharger,
except
they
were
not
as
people
said,
we're
not
chartering
mask
m,
and
I
I
think
the
the
key
thing
here
is
figuring
out
like
I
think
there
will
be
extension
poles
forever
and
I
think
we
have
to
figure
out
what
is
the
the
off-ramp
to
hand
those
extension
proposals
to
the
other
steward
working
groups
here
and
I'd
be
interested.