►
From YouTube: IETF-ALTO-20230411-1400
Description
ALTO meeting session at IETF
2023/04/11 1400
https://datatracker.ietf.org/meeting//proceedings/
A
C
C
D
B
A
C
A
A
B
A
C
C
E
C
B
So
welcome
to
the
interim
meeting
this
second
interim
meeting
for
the
for
the
focus
of
this
internal
meeting
actually
is
to
discuss
the
OM
and
transport
and
the
since
we
have
already
have
a
initial
initially
working
with
last
call
for
auto,
om
and
auto
new
transport.
We
need
to
make
sure
the
the
open
issue
has
been
addressed
and
also
we
request
the
director
review
and
some
feedback
we
already
already
received.
So
we
actually
keep
check
this
kind
of
open
issue
in
each
issue
channel.
B
C
B
We
will
speak
to
the
agenda,
the
positive
Council,
Auto
om
and
then
Auto
new
transport
and
and
if
we
have
time
we
will
discuss
the
next
step
for
the
working
group
and
the
for
the
interim
meeting
and
we
already
plan
you
know
four
intermittent
so
two
intermitting
or
dedicated
to
you
know
to
resolve
all
the
open
issue,
the
other
two
intermitting
we
will,
you
know,
discuss
the
some
of
future
work.
So
these
are
the
agenda.
E
B
E
This
is
such
close
album.
It's
actually
most
awesome.
We
have
already
provided
solution
so
that
everything
to
the
so
that
at
the
first
survey,
the
different
to
recover
the
comments
by
the
young
doctor
review
so
for
the
youngcast
reveals,
it's
been
really
happily
address
them,
but
but
yeah
for
example,
so
that
they
can
be
controller
than
one
by
one.
E
They
have
to
clarify
the
testified
for
our
daily
list
case
and
the
establish
case
and
original
of
the
the
type
of
initiative
simply
use
this
screen
and
right
now,
I'll
be
able
to
touch
the
server
taxify
to
provide
the
email.
The
concrete
semantics
for
the
follow
this
case
for
the
contact
name
and
the
Medicaid
the.
E
But
the
environment
issue:
maybe
we
need
to
confirm
it-
is
recovery
that
so
right
now
the
the
building
I'm
the
first
ID,
so
they
are
not
standard
in
in
the
active.
So
that's
just
a
provided
by
this
document.
So
there's
no
standard.
We
can
become
wrapping
to
see
what's
the
format,
so
we
just
seem
like
I
use
the
foreign.
F
E
E
A
A
But
resource
ID
must
start,
for
example,
I
believe,
typically,
you
must
start
from
from
from
from
from,
for
example,
should
start
from
from
a
a
a
letter
right,
A
to
Z
and
capital
A
to
Z.
Basically,
a
resource
ID
essentially
is
a
typical
programming
language
identify,
but
here
I
presume
resource
ID
can
be
all
like
a
zero
right
and
I'm
just
kind
of
curious.
What's
the
ration,
though
the
typical
rule
of
thumb,
you
will
never
do
something
is.
A
Make
your
screen
a
bit
bigger,
it's
very
hard
to
say
from
my
side
just
a
little
bit
like
a
make
a
fast,
slightly,
bigger,
yeah,
sure,
okay,
great
yep,
for
example,
I
mean
I
I'm,
not
challenging
a
particular
way,
but
I'm
curious
why
this
particular
way
your
essential
allow.
It
can
be
all
zero
right
and
if
the
pattern
is
at
least
one
and
then
your
regular
expression
is
not
right
right.
A
A
For
example,
all
the.
If
you
look
at
RC
1785,
they
also
specify
they
are
using
a
Unicode
or
whatever
from
which
one
to
which
you
rent
and
here
you're,
just
using
essential
strings,
but
they
have
all
kinds
of
representations
right
and
then
you
really
have
ADD
sign
and
underscore
why
this
particular
choice.
E
E
A
B
E
B
A
Yeah
yeah
I,
just
posted
a
section,
10.1
I
guess
my
overall
language
suggestion
is
given
the
Yamato
and
given
that,
for
example,
in
1785,
is
you
define
PID
name
and
the
resource
ID
is
as
a
type
of
PID
name.
So
therefore,
everything
essentially
using
derived
types
instead
of
I
guess
in
computer
science?
Is
you
do
not
Define
the
same
time?
Multiple
time
you
define
a
common
type
where
you
want
the
essentially
reuse
from
it.
A
E
B
E
A
E
A
So
therefore,
and
therefore
it's
not
like
a
generic
Max
right
and
sometimes
there
are
a
lot
of
very
subtle
things
whenever
you
design
things
there
are,
there
are
thinking.
So,
of
course
you
don't
write
it
over
there.
For
example,
here
with
another
right,
a
PD
name
must
be
no
model
64..
Of
course,
underlying
thinking
was
okay
and
someone
can
just
take
PID
name
and
whatever
kubernetes
or
whatever,
and
you
you
turn
into
a
a
being
as
an
app.
So
therefore
that's
easy,
you
have
domain,
and
then
you
get
paid
name
now.
A
Therefore,
you
can
really
like
represent
PID
name
as
part
as
a
label,
and
DS
label
is
limited
to
be
a
six
base
lens
right
for
two
bits:
are
the
pointers,
zero
zeros
one
one
so
they're
all
this
kind
of
consideration?
That's
why
they're
encoding
in
that
way,
I
think
somehow,
if
I
may
make
a
quick
comment
is
somehow
they
are
missing
in
in
this
spec.
These
kind
of
constitutions
were
not
with.
You
can
either
refer
back
to
it
right
or
maybe
you
can
bring
this
hey.
You
must
really
follow
this
particular
spec.
E
B
B
B
E
C
B
E
E
E
So
right
now,
actually
we
have
to
propose
a
white,
so
we
can
use
the
binary
to
encode
the
object,
whether
you
see
fix
it
before
and
because
it
requires
the
server
side
to
do
the
validation,
because
if
you
can
see
that
another
solution
is
that,
so
we
can
use
any
data
statement
to
the
to
include
the
app
query
down
data
structures.
But
that
means
they.
We
need
to
Define
how
to
translate
the
young
perspective
to
the
business
value.
B
E
E
E
B
D
E
D
B
B
E
D
B
So
Json
for
for
this
job
that
I
think
we
still
need
to
wait
for
some.
You
know
feedback
from
other
directory
review
freedom.
Also,
director
review
Maybe,
you
may
need
to
you
know,
issue
another
revision,
but
we
we
can
quickly
address
all
the
young
doctor
review
comments
and-
and
maybe
you
have
another
iteration
for
for
some
new
new
comments.
B
B
B
A
F
E
F
Great
great
so
Abby
just
summarizing
the
working
group.
Let's
go
status
for
the
new
transport
document,
which
is
still
the
version
seven
and
we
are
already
working
on
version
eight
and
the
latest
draft
is
already
in
the
GitHub,
but
we
haven't
submitted
to
their
tracker
yet.
So
here
is
a
summary
of
the
working
group:
let's
go
status,
so
we
received
like
six
reviews
from
different
territories
and
yeah,
basically
from
different
reviewers
and
then
for
from
for
all
the
reviews.
F
We
already
have
some
responses,
but
and
or
for
some
of
the
reviews
we
already
got
confirmation
from
the
reviewer
that
their
the
comments
are
considered
as
resolved,
but
we
also
have
some
real
blockers
here,
as
basically
we'll
summarize
in
later
slides.
So
the
first
is
from
RTG
Dr,
Early
review
and
I.
Think
that
most
of
the
review
is
some
needs
about
the
document
and
actually
has
already
replied
and
explained
that,
for
example,
the
push
order
does
not
need
to
be
strict
in
the
create
order.
F
So
for
this
review
we
are
basically
waiting
for
further
feedback
and
also
for
the
SEC
security
directory
early
review.
Mostly,
the
reviews
are
some
needs
about.
The
document
and
already
fixed
in
the
current
in
the
net
in
the
next
revision
and
the
rear,
has
already
replied
that
his
comments
can
be
considered
as
resolved.
So
this
is
a
best
progress
that
we
have
right
now
and
then
for
the
Ops.
They
are
only
reviews.
F
The
the
comma
is
also
mostly
some
needs
about
document
and
luckily
has
already
submitted
proposed
changes,
but
I
think
according
to
the
reviewer,
there
might
be
one
round
of
revision.
I
think
he's
mentioning
that
some
of
the
proposed
texts
may
be
missing
some
references
and
we
will
be
adding
these
references
in
the
next
revision
and
then
get
back
to
the
reviewers,
and
also
this
is
from
Spencer
the
art
early
review,
and
basically
there
are
a
few
slightly
larger
issues.
F
The
first
is
that
for
HTTP,
2
and
hb3,
they
actually
use
different
ways
to
instrument
to
initiate
the
server
push
and
in
a
last
document
we
are
using
the
basically
the
settings
enable
push
attribute
in
the
settings
frame.
But
this
is
this:
initialization
process
has
been
removed
from
hpe3
and
it
should
be
three
is
using
a
different
way,
basically
setting
another
I
think
some
Max
push
frame,
ID
I,
think
that's
the
name
and
then
I
already
update
updated
the
document
to
address
this
comment,
and
also
so
so.
F
For
example,
there
are
some
terms
that
we
use,
for
example,
shoot
in
the
in
some
examples
and
then
basically,
Spencer
is
a
question
that
what
if
they
say,
my
understanding
is
that
he's
arguing
that
maybe
here
we
should
use
something
like
must
and
then
I
also
reply
to
his
email,
saying
that
when
there,
for
example,
there
can
be
a
case
that
the
tips
only
provide
a
thing.
One
risk
the
update
service
for
one
resource,
while
the
resource
may
also
depend
on
some
other
resources.
F
Basically,
the
dependency
is
not
closed
and
there.
Basically,
there
are
some,
for
example,
Performance
and
consistent
issues,
but
this
is
tolerated
in
the
current
document
and
basically
also
there
are
some
needs
and
I
believe
I'll
have
fixed
these
needs
and
we
also
responded
with
the
proposed
changes
and
waiting
for
the
feedback.
I
think
that's
the
status
for
the
other
early
review
and
then
for
the
last
two
reviews,
basically
the
TSB
art
and
also
the
HD
video
review.
F
We
got
some
discussions
into
technical
issues
so
for
the
tsv
art
I.
Think
here,
I've
basically
summarized
four
issues.
So
first
is
transport
requirement
is
not
expensive,
I'm,
not
explicitly
layout
and
then
also
the
second
issue
that
the
need
for
backward
compatibility
is
also
now
stated
or
justified
in
the
document.
F
Whether
it
is
possible
to,
for
example,
provide
more
updates
between
different,
basically
not
between
labor
neighboring
versions
but,
for
example,
providing
updates
from
n
to
n
plus
two
and
also
basically
other
possible
encoding
mechanisms,
and
also
the
status
for
this
review
is
I
responded
with
with
some
proposed
changes
and
specifically
for
the
first
two
issues.
Then
the
transport
requirements
are
laid
off
and
also
backward
compatibility
now,
stereo
Justified.
This
is
actually
fixed
together
with
some
of
the
issues
raised
by
the
HD
video
review.
F
F
So
so
this
review
is
probably
the
major
roadblocker
at
this
point
and
there
are
three
major
technical
issues.
The
first
is
the
use
of
HTTP
2
and
3
server
push,
and
the
second
is
whether
the
station
and
all
users
are
bounded
to
a
single
persistent
connection
and
also
in
his
latest
response.
He
argues
that
the
meta
layer,
basically
providing
the
update
graph,
might
be
too
complex
and
also
there
are
some
writing
issues,
for
example,
inconsistential
terms
and
all
and
specification
by
example,
and
we're
also
working
on
that.
F
But
maybe
today
I
would
like
to
discuss
and
get
a
feedback
from.
The
working
group
is
on
the
first
two
technical
issues.
So
the
first
issue
is
the
use
of
HTTP,
2
and
3
server.
Push
and
basically
modeling
is
on
arguing
that
first,
this
functionality
lack
of
implementation
support.
Basically,
we
do
not
have
a
working
implementation
yet
and
also
he
argued
that
this
the
server
push
in
our
document
is
not
intended.
F
The
use
of
server
push
defining
the
hb2
S3
and
so
basically
my
personal
understanding
that
we
maybe
have
two
options,
but
of
course
other
authors
or
people
from
the
working
group
may
have
some
other
opinions.
But
to
me
that
we
have
basically
two
options.
The
first
one
is:
maybe
we
can
just
spray
it
again
and
then
put
HTTP
2003
as
another
document.
F
F
For
example,
there
might
be
some
good
implementation
practice,
maybe
not
just
from
all
working
group
and
maybe
from
some
other
protocols,
but
then
I'm,
basically
I'm
wondering
whether
anyone
has
some
pointers
that
we
can
look
into,
and
this
is
the
second
technical
issue
that
in
a
current
document,
we
require
that
basically
each
each
session,
where
a
user
can
request,
for
example,
multiple
tips
and
also
get
the
incremental
updates,
is
through
a
single
persistent
connection
and
understanding
that
money
is
strongly
against
this
tight
coupling.
Basically,
he
argues
the
HTTP
based
protocols.
F
Should
be
based
on
requests
rather
than
connections
and
also
I
see
two
options.
The
first
is:
maybe
we
adjust
the
protocol
and
allow
the
same
user
to
use
multiple
connections,
but
then
we
can
also
say
that
it
is
recommended
to
use
a
single
one
for
performance
enhancements
and
also-
maybe
the
second
option
is
to
justify
the
design.
Maybe
it
waste
some
other
working
examples
from
some
other
working
groups
and
yeah,
probably
for
the
for
option
two.
We
probably
need
some
feedback
from
the
working
group,
whether
you
have
seen
such
use
cases.
F
I
think
for
the
next
step.
First,
we
haven't
really
follow
up
the
working
Google.
Let's
go
inside
of
one
group,
and
that's
probably
one
thing
we
might.
We
should
do
at
least
in
this
week
and
also
for
the
summer
reviews.
I
already
have
some
positive,
basically,
some
with
minor
issues.
We
can
basically
follow
up
and
ask
asking
the
reviewers
whether
the
proposed
changes
can
address
their
comments.
I
think
this
is
also
the
next
step
and
then
the
last
one
is.
F
B
B
A
I
I
do
and
I
think
number
one
number
I
do
want
to
give
a
shout
out
to
Kai
and
Lachlan,
and
these
two
guys
are
doing
amazing
work,
the
follow-up
and
amazing.
So
that's
how
our
start
get
started
to
see
that
second
I
do
want
to
see
that
Martin
Martin
Thompson
gave
a
wonderful,
wonderful
review
he's.
He
definitely
is
the
top
top
expert
related
field,
but
somehow
I
I.
A
From
my
point
of
view,
there
are
essentially
two
issues
right
and
we
want
to
get
feedback
from
the
working
group
and
I'm
going
to
share
a
little
bit
of
opinion,
because
I
think
Kai
and
Lachlan
and
Walt
Disney
ourself
well.
I
can't
make
the
attention
ourselves,
but
if
I
do
ideally
make
decisions
within
working
group
ourselves,
I
would
like
to
start
with
question
number
one
Kai.
A
Can
you
show
the
issue
about
server
push
right,
because
that's
a
major
roadblock
I
personally
feel
that
it
should
be
okay
right
and
maybe
one
way
out.
One
way
to
design
I
can
see
that
this
is
a
tactical
and
non-technical
right
and
because
people
can
argue,
a
silver
Porsche
is
not
very
widely
used
and
maybe
eventually
will
go
away
and
and
and
and
the
server
portrait
essentially
intended
for
the
server,
for
example,
who
has
a
computer
website
instead
of
approach
some
kind
of
part
of
image?
A
So
we
know
what's
going
on,
but
the
philosophy
wise
to
me.
It
looks
right
and
it
should
be
something
like
a
silver
push.
Okay,
right
and
I
think
those
will
be
relatively
on
one
hand,
it
can
be
technical
on
the
other
hand,
and
can
be
somehow
also
relative
subject.
Subjective
judgment
account
right
and
so
therefore,
that's
my
point
of
view.
What
I
would
like
to
say
is
the
thought
in
that
for
option
one.
A
We
already
tried
to
really
have
a
split
that
turns
out
to
have
a
lot
of
redundancy
and
that's
why
we'll
move
the
back
and
one
possibility.
Is
we
make
a
server
approach
as
optional
right?
So,
even
if
eventually
I
I,
don't
know
what
kind
of
a
concern
Market
would
have.
One
particular
concern
is
eventually.
Server
push
goes
away
from
egb4
and
then
we
have
something
which
is
funny.
So
therefore,
then
we
become
not
future
proof.
A
D
D
It
doesn't
work
to
to
to
continue
having
this
complexity
in
the
document,
so
you
can
just
remove
it,
but
if
we
it
will
Define,
there
is
something
that
is
really
I
would
say
fundamental
for
the
protocol
and
we
we
have
some
evidence
and
benefits
for
having
that.
So
we
need
to
to
call
that
explicitly
and
clearly
in
the
document.
D
A
My
argument
for
why
the
silver
push
the
main
benefit
to
me
is:
it
reduces
one
round
trip
time
of
delay.
I
could
reduce
the
Silver
Load
right,
because
server
does
not
have
to
really
send
a
updated
to
turn
into
processing
a
request
and
then
send
a
reply,
and
now
server
can
just
directly
send
a
you
know:
project
promise,
I
understand
approach.
So
therefore,
that's
the
one
I
think
that
one
is
benefit.
If
we
remove
it,
we
do
introduce
slightly
more
complexity.
For
example,
some
kind
of
clients
might
have
more
overhead
right.
A
They
need
to
really
always
keep
on
this.
They
need
to
all
calculation
to
make
sure
there's
a
pending
push
over
there
and
then
what
if,
for
example,
the
server
changes.
The
way
because
remember
the
the
current
algorithm
is
the
calculation
is
calculated
according
to
the
state
which
the
server
has
more
information.
We
can
try
to
justify
to
see
why
the
server
approach
is
beneficial
and
then
we
we
make
it
make
sure
that
this
is
optional.
Would
that
be?
Okay?
Did
I
answer
your
question
match,
so
basically,
we.
D
Make
exactly
in
that
time
two
to
review
the
greatest
changes
you
made,
but
this
is
something
that
should
be
I
would
say
early
in
the
document
so
that
the
I
would
say
readers
understand
the
rationale
for
why
we
have.
We
have
that
there,
because
it's
not
marketing
that
we
need
to
convince,
is
we
say,
the
the
the
all
the
the
process
and
also
the
the
other
reviewers
who
will
have
the
same.
The
the
same
comment.
E
B
Suggestions-
maybe
we
can,
you
know
first
to
discuss
with
Martin,
with
the
proposed
paragraph
get
his
confirmation.
Also
I
see
you
know.
Spencer
may
have
similar
comments.
We
need
to
address
this
kind
of
issue.
So
if
we
can
get
some
of
you
know
opinion
from
Spencer
for
this
issue,
and
maybe
we
can.
You
know
sync
up
with
Martin
about
this,
to
see
whether
we
can
reach
an
agreement.
A
A
B
E
B
A
A
What
or
ad
was
a
design
which
is
a
future
Pro
in
a
sense
that
a
very,
very
robust
whatever
you
change
lightly
and
the
same
would
always
stay
so
in
that
sense,
I
think
maybe
we
can
argue
with
this,
and
we
probably
can
also
very
quickly
jumped
out
Martin
Duke,
because
indeed,
if
more
and
more
people
concern
eventually,
the
silver
approach
will
be
go
away
inside
HTTP,
then
we
become
something
dangling.
We
should
verify
with
all
three
I
think
that's
a
consideration.
Luckily,
any
quick
comment
from
you.
E
A
Oh,
here's,
the
fine,
okay
great,
can
I
make
a
comment
on
number
two,
because
I
do
want
to
get
the
working
group
and
also
all
experts,
opinion.
I
do
want
to
see
some
comments
over
here.
This
is
very
tricky
right
and
this
is
again
and
you
can
see
technical
you
can
also.
This
is
a
code
called
philosopher
code
right
or
a
relative
subjective.
A
A
So
therefore,
conceptually
you
open
multiple
connections
and
those
connections
would
serve
as
bundles
right
and
actually
like.
For
example,
you
do
a
bundle
or
even
like,
for
example,
you
have
two
ports
eating
together
a
connection
service
bundles
inside
inside
each
connection
you
can
have
set
of
sessions.
I
think
that's.
The
philosophy
here
should
be
based
on
requests
based
on
connections
but
somehow
they're
also
designed,
for
example,
one
important
design
is
Zookeeper.
Zookeeper
actually
is
a
session
based
protocol
right.
A
The
important
part
of
the
session
is
there's
a
connection
and
you
are
using
a
connection
and
connection
Service
as
an
envelope
anytime,
you
lose
the
connection,
then
you
lose
all
the
other
sub
things.
So,
therefore,
you
don't
do
a
boundary
clearly
a
problem
here.
The
discussion
is,
we
were
thinking
that
if
you
have
a
connection
just
based
like
a
one
important
part
of
people
who
follow
those
zookeeper
design
is
a
lot
of
things
are
empire
real
and
basically
it's
temporary
and
you
maintain
a
connection
the
moment.
A
The
connection
is
disconnected
the
the
the
thing
just
disappeared.
So
therefore,
that's
actually
what
have
oftentimes
very,
very
good,
robust
for
for
tolerance
and
basically
coverage
collection
properties.
That's
why
it's
really
designed
and
I
can
see
that
Martin
Thompson
has
this
philosopher,
which
clearly
is.
If
you
don't
really
have
a
concept
of
connections.
Therefore
you,
don't
you
don't
bundle
the
connection
with
the
state?
That's
all
can
benefit,
but
then
there's
also
error
correction,
which
is
something
right.
A
We
clearly
use
the
session
based
and
motivation
by
zookeeper
Motivation
by
really
ryw
right
for
people
who
follow
consistency,
design,
industry
systems,
but
this
one
also
is
that
Martin
Thompson
clearly
has
a
slightly
a
different
view.
It
is
from
the
review
I,
don't
know
what
other
people's
reaction
would
be
and
Kai
gave
two
options.
I
think
we'll
be
more
than
happy
to
hear
about
feedback
or
people
will
be
strong,
strong
views
and
we
can
discuss.
B
Yeah
I
feel
you
know,
you
know
session
bound
to
the
single
connection
Maybe
it's
too,
irrespective
maybe
we
should
also
allow
you
know
onto
the
multiple
connection
and
in
net
account.
Maybe
they
also
have
a
similar
seminar
work.
Actually
you
know
they.
Maybe
we
can
reference
summer
worker
in
in
that
accountable.
You
know
because
they
did
a
discount.
You
know
bound
into
the
single
connection,
also
maybe
bounded
to
the
multiple
connection.
A
So,
for
example,
I'm
not
filming
that,
but
I'll
be
Monahan.
For
example,
one
benefit
of
abunding
state
to
connection
is,
for
example,
their
typical.
Even
for
example,
keeper
is,
you
have
a
they
want
to
say:
availability,
for
example,
if
a
server
is
available
and
if
it
was
a
connection,
This
Server
should
automatically
move.
So,
therefore,
you
don't
have
a
steel
State
automatically.
A
You
also
would
automatically
essentially
Implement,
for
example,
unlock
right.
You
put
a
lock
over
there
and
oftentimes
one
meter,
prime
people
just
disconnected,
and
then
you've
got
a
dangling
unlock
over
there,
which
is
very
hard
to
remove
and
and
just
paste
it
like,
for
example,
with
submit
to
a
irfc
the
draft
and
you
send
one.
They
send
you
a
confirmation,
email
and
you
lost
that
email
and
suddenly
you
cannot
submit
that
version
again,
because
that
version
is
lost,
and
so
here,
if
connection
is
disconnected
automatically
off
stage,
is
cleared
right.
A
Those
are
very,
very
good
benefit,
potentially
essentially,
basically
I.
Guess
people
like
how,
essentially
this
like
a
try
and
unlock
a
program
structure
right,
so
here
more
and
more
we're
feeding
on
to
where,
like
session
based
right,
for
example,
if
you
disconnect
your
state
will
be
removed
so
therefore
make
the
server
to
be
a
very
clean.
A
Then,
of
course
not
really
traditional
design
like
like
a
Kafka
and
those
are
a
central
message,
queue
system,
you
lose
connection,
you
don't
lose
this
kind
of
state,
but
actually
for
ours.
We
prefer
that
I
think
maybe
a
net
account
for
Me
Maybe
has
similar
use
case
or
maybe
not
right,
so
I
think
that's
why
I
wanna
I
wanna
make
it
very
very
clear.
It
does
have
a
lot
of
benefits.