►
From YouTube: IETF108 ALTO 20200727 1410
Description
ALTO session at IETF108
2020/07/27 1410
A
A
A
C
A
A
A
So
good
before
we
start,
I
have
to
send
out
a
warning.
There
have
been
emails
going
on
on
the
chairs
mailing
list.
I
think
that
the
meat
echo
will
finish
sharply
on
time
and
apparently
there
is
no
buffer.
So
at
the
end
of
our
session,
whoever
is
going
to
talk
meet,
echo
is
going
to
cut
you
off,
or
maybe
me
myself
whatever.
So
whenever
our
100
minutes
are
gone,
we're
going
to
be
cut
off
just
so
that
everyone
is.
A
D
D
A
B
A
A
A
A
Vijay
is
going
to
put
up
the
slides
we
have,
but
while
he's
doing
that,
I
think
everybody
who's
been
following
the
mailing
list.
It
should
be
very
obvious
what
we're
going
to
do
today.
We
want
to
finish
the
four
remaining
documents
and
one
of
them
has
already
passed
working
group
last
call
one
isn't
working.
A
D
F
B
A
A
G
A
A
Yeah
all
right,
so
the
first
slide,
I
guess,
is
obvious.
This
is
the
auto
working
group.
This
is
itf
108.,
I'm
jan
zidorov,
I'm
co-chair
in
this
working
group
and
vijay
gurbani
is
also
here,
he's
also
a
co-chair
in
this
working
group.
So
we
can
go
to
the
next
slide
and
the
note
where
I
think
I
know
all
of
most
of
you
in
the
chat
here.
So
all
of
you
are
more
or
less
veterans,
so
you
should
know
this
and
there
are
certain
rules
that
apply
in
the
itf.
A
So
everything
we
do
here
is,
I
guess,
public
domain.
Essentially,
so
everything
is
open
to
the
public
and
very
transparent,
and
if
you
know
about
any
ipr
you're
supposed
to
mention
it
and
yeah
check
these
routes
in
detail.
If
you
want
to
there
are
certain
rfc's
listed
here.
If
you
want
to
read
this
in
detail,
but
we
assume
that
everyone
is
aware
of
these
rules
that
certainly
apply
to
this
session.
A
So
I'm
now
on
slide
number
three:
the
status
of
the
working
group.
Well,
I
said
this
already.
We
want
to
finalize
the
charter
items
and
we
are,
we
think,
we're
there.
So
vijay
myself
and
also
martin,
our
air
director
had
some
email
exchanges
and
we
think
we
can
move
all
the
remaining
documents
to
working
glass.
Core
we've
already
started
with
one
of
them
with
the
unified
properties
document.
A
A
So
a
while
ago,
I
discussed
with
vj
and
martin,
and
I
issued
actually
a
mail
on
the
mailing
list
that
we,
if
we
want
to
continue
this
working
group,
we
need
to
recharter
and
we
solicit
this
solicited
contributions
for
this
recharter
discussions
and
the
idea
was
that
we're
going
to
have
several
one
slider
presentations
and
richard's
going
to
present
this
today.
So
I
don't
want
to
say
much
about
this.
What
I'm
going
to
say
is
that
I
was
actually
very
happy
about
the
energy
that
I
saw
on
the
mailing
list.
A
I
have
been
certainly
one
that
maybe
a
while
ago
was
skeptical.
We
have
enough
energy
for
recharging
the
working
group,
but
I
have
to
I've
changed
my
mind
on
that.
So
we
saw
we
have
weekly
meetings.
Now
we
see
a
lot
of
people
working
on
new
topics,
so
I
think
the
energy
is
clearly
there
and
let's,
let's
see
the
discussion
today,
how
it
goes
and
what
I
mean
for
recharger
energy
is
one
requirement.
A
G
D
B
D
A
Yeah,
so
I
guess
we
can
go
to
slide
number
four,
which
is
the
agenda
which
is
according
to
what
I
just
said
very
straightforward.
So
we
have
four
presentations
on
the
main.
Remaining
milestones
that
we
have
again.
Two
of
cdni
has
already
passed.
Working
plus
called
unified
properties
is
in
working
plus
calls,
so
I
think
for
performance,
metrics
and
path
vector.
We
can
move
these
two
working
less
call
pretty
soon
as
well,
let's
see,
and
then
we
have
roughly
an
hour
for
the
recharge
discussion.
A
A
I
I
have
not
been
following
the
details
there,
but
I
I
assume
they're
making
progress
and
they
are,
they
will
soon
be
issued
as
rfcs
cdni
is
already
past
working
glass
core
which
is
waiting
on
this
document
because
there's
some
dependencies
with
the
other
three
remaining
docs
and
yeah,
the
other
ones
we
think,
are
ready
for
working
glass
core,
but
we're
going
to
have
presentations
on
them
today.
So
I'm
not
going
to
talk
much
more.
D
H
D
Jan
and
I
and
martin
had
a
quick
discussion
on
whether
we
want
to
do
a
working
group
last
call
for
all
of
them
or
each
one
serially,
and
at
least
we
decided
that,
let's
start
off
unified
property,
since
other
drafts
depend
on
it.
So
as
soon
as
that,
working
group
last
call
is
done.
Our
expectation
is
that
we
would
probably
start
path
vector
and
performance
metrics
right
away.
A
Right
good,
thank
you
vijay
for
this.
I
I
was
actually
yeah.
I
was
skipping
some
details
here,
you're
very,
very
right
about
this.
In
fact,
in
my
view,
all
of
these
four
remaining
documents
probably
essentially
might
be
published
all
together
in
the
end,
because
we
have
some
dependencies,
I'm
not
sure
about
performance
metrics,
but
at
least
cd
and
ipad,
vector
and
unified
properties
yeah.
They
depend
on
each
other
or
depend
on
unified
properties.
C
A
D
There
is
a
bunch
of
issues
listed
there
that
are
of
import.
The
three
that
I
mentioned
here
are
the
issues
the
recharger
will
address
clear
and
relevant
to
the
internet
community.
Are
the
goals
specific
and
reasonably
achievable
and
achievable
within
a
reasonable
time
frame,
and
is
there
enough
expertise
within
the
etf
in
the
working
groups
topic
and
are
those
people
interested
in
contributing
those
are
the
three
main
things
that
we
should
keep
in
mind
as
we
think
about
the
recharger
discussion?
D
Our
expectation
is
that
we
are
starting
off
this
recharger
discussion.
I
suspect
we
won't
reach
any
consensus
at
least
today
on
on
whether
to
reach
out
or
not,
but
I
think
starting
this
off
is
is
a
good
thing
to
do
and,
as
jan
said,
given
the
energy
things
are
looking
in
the
right
direction.
So,
let's
see
how
far
we
go.
A
D
A
C
Okay,
so
hello,
everybody.
So
this
is
the
presentation
on
the
the
latest
iteration
of
unified
property,
which
is
by
the
way
version
12
and
not
11.,
so
I
won't
go.
I
won't
go
over
the
the
general
ideas
on
this
draft.
People
can
just
read
the
slides.
The
slide
number
two
so
slide.
Number
three,
please.
C
C
Okay,
so
to
start
with
so
there
have,
there
have
been
substantial
updates
on
this
draft
large
updates
on
the
text
and
reorganization
of
the
document
and
also
design
updates,
which
does
not
actually
question
the
further
design
we
just
introduced
rather
a
definition,
so
we
defined
something
called
defining
information
resource.
I
will
go
back
to
this
later
and
then
clarification
table
of
contents
updates
and
the
status
right
now
is
that
it
is
in
working
group
last
call
until
august
7th.
C
Okay,
so
the
defining
information
resource
we
have
diff,
introduce
this
concept
for
several
purposes,
so
the
the
this
we
needed
this
concept,
especially
when
we
were
defining
resource,
dependent
entity,
domains
and
resource
dependent
property
values.
So
we
needed
to
def
to
specify
from
which
information
resource
the
entities
that
are
defined
and
accessible.
C
So
this
is
also
useful
for
resource
specific
entity
domains
constructed
from
resource
agnostic
domain
types,
a
resource
agnostic
domain
types
is
typically
ipv4
ipv6,
but
sometimes
you
want
to
define
an
entity
domain
of
local
addresses.
So
then,
of
course,
you
make
it
resource
specific
and
then
again
you
need
to
specify
this
defining
information
resource
and
last
but
not
least,
this
is
very
useful
for
alto
clients
because
ultra
clients
in
the
ird
they
see
that
the
property
map
exposes
mappings
between
entity,
domains
and
property,
which
means
you
can
query
property.
C
C
C
It
defines
the
entity
of
this
entity
domain.
It
does
not
use
another
information
resource
that
defines
this
entity,
for
example,
in
a
path
vector
you
may
say:
okay,
the
the
this
ini
appears
first
in
a
cost
map,
so
the
the
defining
resource
would
be
a
cost
map
or,
if
you,
it
expose
a
customer
between
two
pids,
for
example.
C
C
C
C
C
C
So
again,
it
is
useful
for
the
client
to
check
if
the
mapping
is
correct,
and
so
we
added
a
new
section
on
that
topic
on
defining
information
resource
for
resource-specific
property
values.
We
provided
a
couple
of
examples
and
by
the
way
the
example
of
cdni
will
be
corrected.
There
is
an
error
in
the
text
next
slide,
please.
C
D
C
C
C
Well,
some
additional
text
update
list-
and
I
just
wanted
to
say
so-
the
this
is
in
working
group
last
call
and
do
not
hesitate
to
to
send
any
feedback,
especially
regarding
text
clarification
because
everybody
knows
after
having
edited
the
text
for
a
long
time.
Yes,
some
things
that
are
clear
for
us
are
not
clear
for
the
readers.
Thank
you.
G
D
A
I
I
B
A
D
B
B
Okay,
so,
and
let's
start
with
the
first
slice-
and
please
go
to
the
second
slice
piece,
so
basically,
we
have
a
the
revision
from
version
10
version
12,
which
is
the
current
version,
is
to
address
discussions
and
comments
and
reviews
at
an
interim
meeting
in
april
2020
and
of
course,
there
are
also
a
bunch
of
issues
with
during
the
weekly
meetings
and
mostly
just
address
those
issues,
and
those
issues
essentially
can
be
recorded.
That's
also
reviewed
from
marketing
and
so
on.
So
we're
trying
to
address
all
those
issues
at
high
level.
B
The
issues
are
essentially
for
and
how
to
choose
types
of
metrics
number
two
and
what's
a
strategy
to
conform
to
rfc
6390
and
how
much
detail
to
specify
and
number
three
how
to
handle
different
statistics
of
symmetric
with
these
customers
at
all
time
and
there's
all
these
essential
meeting
minutes
and
then
number
four
and
multiple
people
raise
the
issue
how
the
common
fraction
is
of
metric
values.
So
basically
revision
essentially
to
make
clarify
as
much
as
possible
about
these
four
issues
slide.
Number
three,
please!
B
So
for
people
who
are
new
and
who
are
wondering
what
exactly
is
going
on
with
the
performance
metrics
document
basically
is
we're
trying
to
define
performance,
metrics
and
from
network
to
applications
and
very
key
decision.
What
group
decision
is
how
to
provide
guidance
and
not
measurement
framework.
There
are,
there
are
very
serious
framework
efforts
here
at
iepf
and
one
so
therefore,
we're
guidance,
we're
not
a
measurement
framework,
and
we
want
clarificate
and
number
two
is
one
clarified.
Is
there
can
be
multiple
types
of
guidance,
and
currently
the
working
group
has
chosen
four
types.
B
If,
for
example,
over
here,
you
might
have
the
sla,
which
is
one
type
of
guidance.
Measurements,
for
example,
might
be
one
type
of
measurement
guidance,
and
if
you
look
at
the
upper
right
corner,
we
want
to
be
able
to
use,
for
example,
data
from
blocking
protocol
8571,
that's
a
type
of
guidance
as
well.
So
therefore,
how
to
choose
a
type
of
guidance
next
slide,
please.
B
So,
basically,
eventually
we
chose
four
and
the
major
decision
was
okay,
an
amount
of
four
types
of
guidance,
and
how
do
you
really
choose
which
one?
So
the
eventual
decision
was
to
revise
the
text
text
as
much
as
possible
to
make
this
super
as
clear
as
possible.
For
example,
here
is
an
example,
and
also
probably
the
more
important
part
about
clarification
of
clarify
how
people
should
choose
which
type
of
guidance
your
metric
really
is
so
here,
of
course,
we
have
estimation
category
by
the
way,
using
just
copies
from
the
exact
text.
B
So
people
know
what
exactly
we're
writing
so
estimation,
of
course,
is
computer
student
estimation
process.
It's
generic
and
we
give
all
kind
of
examples,
and
the
discussion,
I
think,
also
from
the
weekly
meeting
from
feedback,
is,
isn't
it
true
that
import
is
one
type
of
estimation
you
just
import
and
do
a
very
minor,
minor,
essentially,
processing,
and
then
central
concept
comes
as
import.
And
how
do
you
do
that?
B
So
therefore,
we
clarify
a
particular
type
of
estimation,
is
direct
import,
which
indicates
that
value
of
the
metric
is
imported
directly
from
specific
document
system
and
so
on.
So
therefore,
we
essentially
address
clarified
this
one
and
then
of
course-
and
there
might
be
still
would
be
discussions
and
about
which
one
and
what,
if
do?
I
read
it
given
that
you
have
subset
and
and
superset
relationship
and
what,
if
they
overlap.
So
eventually
we
make
a
decision
that
the
third
paragraph
there
can
be
overlapping
deciding
the
cost
source
category
and
operator
of
auto
server.
B
Who
chooses
the
category
and
of
course,
we
also
want
to
be
backward
compatible
and
what,
if
a
user,
doesn't
really
include
it.
And
therefore
we
see
if
a
metric
does
not
include
a
such
essential
indicator
and
application
must
assume
essential
is
estimation
which
is
the
most
generic
one.
Okay
and
next
slides.
Please
number
five,
please.
B
So
basically
what
we
decide
is
for
every
single
metric
we
define.
We
clarify
that
we
are
going
to
make
it
very
clear
that
each
one
should
include
metric
name
if
you
read
the
document
and
metric
description
and
you
need
some
measurement
and
marion
plots
are,
of
course,
always
specific
is
specific
to
the
service.
For
example,
endpoint
service
is
between
two
endpoints
and
the
network.
B
Cost
map
is
centralized
between
two
aggregation
points
but,
on
the
other
hand,
to
be
able
to
use
core
screen
information,
for
example,
login
system,
for
example,
igp,
and
you
know,
bgpls,
which
do
not
provide
fine
green
information
such
as
method
of
measurement
or
calculation
and
timing,
and
so
on.
Oftentimes.
You
may
not
have
those
information,
we
still
want
the
ability
to
use
alcohol.
B
You
know,
for
example,
people
are
still
using
induction
protocol
to
fill
it
out
and
use
this
method.
So
therefore,
basically
is
for
those.
We
do
not
really
ask
to
follow
this
rfc
6390
sort
of
for
essential
cell
for
these
cases-
and
it's
essentially
is
recommended
that
the
metric,
the
the
essential
output
server
should
give
a
link
about
where
information
is,
but
do
not
need
to
include
it.
So,
therefore,
we're
conforming
at
the
same
time
we're
not
fully
conforming,
because
we
want
to
be
slightly
more
flexible
and
slide
number
six.
B
Oh,
I'm
almost
done
so.
Okay
and
number
six
is
relatively
easy,
and
the
question
discussion
was,
I
think,
this,
how
to
handle
a
statistic
of
symmetric
and
also
related
with
the
markings
common
that
we
might
want
to
use
as
stable
as
possible,
proper
metrics
and
so
on,
and
eventually
the
object
document.
Is
we
clarify.
B
Okay
and
last
issue.
We
addressed,
we
clarified
a
little
bit
and
that's
essentially,
we
changed
the
wording
a
little
bit.
I
think
the
discussion
working
group
during
intern
meeting
is
we're
not
going
to
add
a
new
metrics
into
essentially
about
the
timing
and
we
decide.
I
think
what
google
meeting
last
meeting
was
indicate
that
the
freshness
of
the
information
is
auto
server.
Should
return
http
last
modified
to
indicate
the
freshness
of
before
the
info.
We
did
that,
and
we
also
clarified
for
sse
and
essentially
the
timing.
B
Last
modified
should
be
time
where
you
receive
the
data
and,
of
course
I
said,
it's
really
in
the
rfc
queue
editor
queue
for
a
while.
So
therefore
we
give
a
hint
to
the
editor
to
fix
it
and
that's
pretty
much
it
so
now,
number
eight
we're
pretty
happy
and
about
the
document,
and
we
might
need
to
do
some
very
minor
ideas,
for
example,
fix
a
few
content,
lenses
and
examples,
but
I
don't
believe
that
would
be
really
an
issue
oftentimes.
B
D
B
G
I
I
Yeah
right
in
the
last
item
meeting
yeah,
I
think
we
are
agreed
that
this
dni
document
is
relatively
stable,
but
there's
some
dependency
with
the
unified
properties.
So
this
update
will
closely
work
with
the
order
of
the
uniform
properties
and
follow
this
basic
update
and
beside
it.
I've
also
made
some
small
edits
and
some
attribute
names
and
meter
types
to
make
this
ddr
interface
more
adaptive.
I
They
generalize
the
major
types
and
attribute
names
like,
for
example,
we
remove
the
fci
from
the
middle
type
of
the
new
services,
just
call
the
auto
cdi
and
also
also
make
something
in
the
attribute
names
like
between
the
cdn
fci
resorts
to
the
city
and
advertisement
business
and
some
other
edit.
We
just
want
to
treat
the
fca
as
a
special
keys
and
make
this
service
general
and
can
adapt
to
some
potential
extensions
for
other
cpi
services.
I
I
D
D
J
J
J
So
here
is
basically
for
past
vector.
We
are
mainly
focusing
on
two
problems
from
past
reviews,
so
one
problem
is
that
the
old
write-ups
seem
to
be
focused
on
a
single
use
case
and
leaves
impression.
That
is
only
for
a
single
usage
scenario
and
in
the
latest
document
we
are
actually
emphasizing
that
this,
this
extension
is
not
that's
not
only
a
applies
for
the
flow
scheduling
problem.
J
J
So,
to
give
quick
update
of
the
updates
in
the
latest
revision
and
in
the
early
part
of
the
document,
we
clarified
the
problem
and
proposed
solution.
So
a
major
change
is
that
we
add
the
or
we
conclude
the
general
additional
requirements,
but
on
top
of
the
current
auto
document-
and
we
present
how
the
extensions
fulfill
these
requirements-
and
we
also
in
the
latest
revision.
J
J
J
And
we
also
fix
some
technical
technical
issues
identified
from
past
document.
One
most
significant
one
is
that
the
usage
of
the
star
parameter
in
multi-part
messages
does
not.
It
is
not
consistent
with
the
rfc,
that's
it
with
the
multiple
rfc,
so,
basically
change.
We
fix
that
problem.
You
know
also.
We
fixed
inappropriate
and
inconsistent
letter
cases.
For
example,
some
of
the
can
and
may
and
mass
are
used
in
calculators,
which
should
follow
the
schematics
of
rc2119,
and
we
fix
that.
J
J
And
just
to
conclude,
the
latest
revision
did
a
lot
of
clarifications
to
make
the
document
easier
to
follow,
and
the
latest
document
is
also
fully
synchronized
with
the
latest
unified
property
draft.
So
it
can
be,
they
can
move
at
head
as
a
bundle,
and
I
think
after
the
unified
property
passes,
the
working
group
last
call.
We
can
issue
the
working
group,
that's
called
for
pass
vector.
D
A
A
K
D
D
B
Hello
yep,
oh
great,
so,
videos,
sorry,
I
messed
up
with
all
the
slides,
but
if
I'm
still
uploading,
unfortunately,
I
couldn't
combine
all
the
flat
I
won't
have
until
11..
So
how
about
I
just
give
the
overview
part,
and
then
you
already
have
the
first
11
which
you
can
do
and
then
I'll
continue
to
upload
into
your
data
tracker.
Is
that
okay,
sorry,
my
machine
wouldn't
allow
me
to
combine
the
single
file
pdf
server,
if
I'm
uploading
one
by
one,
but
you
already.
B
B
B
K
B
B
I
don't
want
to
claim
middle
credit
at
all,
and
this
really
really
is
a
good
effort
and
in
terms
of
over
your
slice
and
house
organization-
and
here
is
essentially
the
main
technical
part
comes
from
quite
a
few
meetings-
discussions,
email
exchanges
with
many
contributors
and
from
very
different
organizations,
channel
mobile
technology
team
about
tencent
banner
practice,
sense
project,
the
qld
cloud
project,
nokia,
ericsson
and
your
name,
so
wonderful,
wonderful
team
of
people.
So
therefore
I
I
think
I
really
should
give
all
these
people
credit.
B
B
So
therefore,
they're
new,
of
course
also,
I
think
really
very
important
for
me-
is
for
this
group
is
to
follow
the
guidance
and
from
our
ap,
and
here
it
is
very,
very
relevant
and
guidance
from
martin
and
that's
his
that's
a
quote
from
his
email.
So
I
think
vt
also
showed
some
guidance
as
well
from
beginning
and
so
that's
very
relevant
as
well.
But
here
essentially
I
want
to
review
remind
people
about
the
key
things
which
I
think
the
recharger
is
looking
for.
B
In
addition
to,
in
some
sense,
also,
we
emphasize
what
media
has
already
shown
number
one
should
be
relevance
should
be
a
real
problem
and
people
are
willing
to
implement
and
deploy
in
particular.
I
guess
deployment
is
very
important
and
we
should
really
work
more
and
with
people
to
reveal
the
document
and
also
for
the
recharger.
I
think
very
important
is
this-
is
now
the
research
I
guess
some
people
are
focusing
to
be
more
on
research,
and
the
problem
should
be
really
somehow
reasonable
solvable
already
and
should
be
relatively
well
understood.
B
I
think
those
are
the
important
part
and
also,
I
think,
vg
young
and
also
mentioned
in
the
beginning.
They
go
for
today
and
it's
not
really
have
the
the
text
of
a
rechargeable
decision
and
just
advance
some
some
kind
of
broad
consensus
on
the
kind
of
problem
to
work
on,
and
then
we
can
work
on
the
exact
text
and,
at
the
very
least
we'll
see
today
or
maybe
in
the
next
few
days
as
well,
and
what
kind
of
possibilities
we
have
next
piece.
B
That's
still
correct
and
also
high-level
goals
is
to
provide
network
information
that
application
may
not
easily
get
by
itself
and
and
provide
action.
That's
number
one!
So,
basically,
if
the
information
applicator
can
get
it
easily,
you
don't
need
the
standard.
That's
problem
out
of
scope
and
also
provide
abstractions
to
simplify
complex
networking
information
internals
and
make
it
simple
as
possible,
but
not
simpler
and,
of
course,
even
some
information
you
might
be
able
to
get.
But
you
want
somehow
simplification.
B
Maybe
networking,
auto
server
is
a
good
way
to
do
a
proxy
and
to
do
transformation
and
so
on,
but
overall
it's
typically
somehow
focusing
slightly
one
way
from
network
to
application
and
why
I
want
to
mention
this.
One
would
be
you
might
see,
discussions
about
a
bigger
context
as
a
bigger
context
about
auto
is
network
application.
Integration
called
design
and
I'm
called
sharing
is
sitcom
a
network
application
application
integration,
code,
design,
workshop
and
and
it's
gonna
be
hold
on
april
14th
from
there
you
can
see.
B
Actually
there
are
both
directions
and
information,
essentially
what
we
call
a
a
and
and
a
basic
network
aware
applications
and
application.
Networking
so
therefore
can
get
quite
quite
comprehensive,
but
here
slightly
we're
so
focusing
on
essentially
providing
information
to
build
better
network
aware
applications,
but
we'll
see
next
slides.
Please
just
set
the
stage.
B
B
For
example,
I
think
there
are
like
a
three
documents
on
nbc
and
five
or
six
on
some
other
mobile
networks,
and
quite
a
few
are
aggregations
proxies
and
quite
a
few
on
update,
auto
drives.
If
you're
interested
in
seeing
this
complete
list,
there's
google
doc,
which
we
maintain
there
are
quite
a
lot
essentially
dangling
work
from
from
auto
a
working
group
which
have
not
been
finished
and
they
are
essentially,
you
know
staged
wait
for
the
recharger
charter
items
to
be
finished
next.
Slides,
please.
B
So
here
is
a
list
of
some
current
active
ones.
There
are
quite
a
few
actually
also
not
really
active
now
and
they
expire,
but
it's
still
over
there
and
some
people
probably
even
will
talk
about
them
and
today,
but
they
were
not
really
reactivated
because
they
were
waiting
for
discussion
to
see
what
direction
and
people
should
start
to
really
react
to
and
resubmit
and
refresh.
Essentially,
all
these
documents
next.
B
Please,
okay,
so
very
quickly.
Let's
summarize
what
the
out
of
protocol
framework
is
because
recharger
should
be
on
one
hand,
it
could
be
as
aggressive
as
you
know,
from
http
to
http,
2
or
3,
and
you
can
make
some
meter
changes,
but
the
potential
possible
you're
what
they
always
want
to
recharge.
The
discussion
is,
you
should
build
the
work
on
top
of
existing
work
and
essentially
auto
has
two
things
to
offer.
One
is
a
protocol
framework
and
one
is
the
abstract.
B
Essentially,
is
the
content
with
the
carrier,
and
here
essentially
the
carrier
which
is
particle
framework.
So
basically,
what
auto
does
is
for
people
refreshing
memory
of
people
new,
and
you
divide
information
into
information
resources
to
do
modular
design
and
each
module
can
have
media
types
to
allow
flexibility.
B
Of
course,
let's
also
be
debatable,
because
no,
you
should
have
only
single
json
type
or
people
and
auto
decision
was
okay,
multiple
types
to
be
allowed
in
the
independent
modular
evolution,
somehow
philosophical,
but
this
current
design
anyway
and
then
different
information
resources
can
have
dependencies
and
how
to
introduce
mechanisms
to
enforce
some
kind
of
consistency
and
all
information
resources.
We
don't.
We
don't
enforce
universal
information
availability.
B
We
have
a
very
simple
grammar
and
to
specify
those
services
we're
not
going
to
young
model
and
so
on,
but
we
do
have
a
grammar.
So
therefore
that's
part
of
framework
as
well
and
on
top
we
allow
people
to
do
whatever
information
resources
you
have
and
we
go
from
not
only
restful
service.
We
can
do
essential,
push,
updates
and
streaming
control
and
incremental
updates,
and
you
can
do
do
all
this
essentially
streaming
control,
actually
getting
closer
closer.
If
you
make
analogy
from
http
to
gp2,
but
you
know
different,
very
specific
context.
Next
slides,
please.
B
B
So
and
the
other
function,
not
only
the
transport
framework
for
people
to
design
things
right,
use,
reusability
and
skeleton
framework
for
people
to
software
engineering
understand-
and
second
one
of
course
is.
We
should
provide
abstractions
and
auto
already-
has
provided
a
lot
quite
a
few
abstractions.
B
B
You
know
proper
metrics,
which
is
covered
today,
multicast
multi-cost
and
cost
calendar,
and
so
on
basic
analytic
properties
of
essentially
a
path
of
virtual
link
in
this
abstraction
and
so
on,
and
then,
of
course,
we
can
also
have
code
flow
and
that's
really
like
an
abstract
view
or
passive
vector
which
we're
finalizing
soon
as
well,
and
then,
of
course,
one
more
thing
is
when
we
think
not
only
network
should
have
a
basic
entities
should
also
have
functions.
So
therefore,
the
abstraction
is
called
essential
footprint
and,
of
course,
it's
specialized
in
context.
B
Basically,
and
you
have
footprints
entities
and
you
have
capabilities
and
you
link
essentially
them
together
with
keep
with
fci
capabilities
and
so
on,
and
of
course,
properties
can
be
inherited
and
information
can
be
filtered.
So
those
are,
you
can
think
about
abstractions
or
you
can
think
about
as
essentially
a
framework
next
slides.
Please.
B
So
we
can
skip
this
one,
so
basically
the
same
thing
and
you
can
basically
for
people
who
want
a
picture.
It
doesn't
like
words,
that's
essentially
what's
really
somehow
the
picture
is
you
have
essentially
nodes
nodes
can
be
grouped
grouped
and
between
nodes,
and
you
can
have
a
path
and
you
can
have
a
set
opacity
to
form
a
call
flow
in
path,
vector
and
so
on.
B
So
that's
always
some
way
to
look
at
abstractions
basic
most-based
abstraction
introduced
by
by
auto
sofa
next
slides,
please,
okay
and
for
often
now-
and
I
do
want
to
emphasize-
and
probably
that's
one
of
the
most
interesting
experience
or
humbling
as
well
as
learning
experience
is
it
takes
time
and
I
think
if
we
are
able
to
retire
to
all
we
can
recharge.
I
think
we
probably
we
learn
a
lot.
B
Hopefully
we
can
do
things
faster
and
so
on,
but
given
that
one
of
the
most
important
condition
is
deployment,
relevance-
and
here
actually
is
one
very
interesting
figure
not
from
me.
This
is
a
paper
from
paper,
cut,
steering
hyper
giant
traffic
at
skill
and
this
paper
from
bannock's
from
by
engema
and
other
people
from
bin
knox
and
telecom
and
so
on,
and
they
won
the
conex
2019
best
paper
award.
B
You
can
see
a
lot
of
effort,
bgp
listener,
idp
listener,
an
integration
pass
and
connect
igp
and
so
on.
I
I
think
they
really
really
go
full
live
in
terms
of
directory
2017,
which
is
about
three
years
ago,
but
still
you
could
look
at
from
how
it
takes
four
years.
So
it
really
takes
time
and
I
think
we
should
learn
from
it
and
as
well.
We
should
of
course,
available.
B
B
You
can
see
that
a
lot
of
complexes
look
at
listeners,
all
kind
of
listeners,
all
kind
of
processing,
past
cache
and
so
on
and
quests
are
quite
complex.
I
think,
given
that
now
we
have
the
protocol,
we
have
a
real
deployment,
lab
school
department
and,
I
believe
potentially
maybe
it
is
time
to
really
open
the
complexity.
Of
course
we
can
discuss
about
that,
and
so
far
auto
tends
to
be
really
making
abstract
as
simple
as
possible,
of
course,
underlying
layer
oftentimes.
B
So
this
is
a
real
system.
Okay,
so
recharger
and
let's
go
over
very
quickly
and
exercise
please
so
we
talked
about
essentially
three
things.
I
think
I'm
so
basically,
and
if
we
understand
one
thing
to
really
make
it
relevant
and
to
solve
real
problem-
and
here
is
really
guiding
principle
that
you
just
see
here
very
quickly.
B
We
feel
very
strongly
that
really
the
most
essential
part
of
the
charter
for
relevance,
reviewer,
quality
and
feasibility
is
collaboration,
somehow
that's
probably
really
essential
and
collaboration
with
industrial
collaborators,
for
example,
network
operators
and
vendors
application
providers
and
so
on,
and
we
really
really
should
collab
within
ietf
and
irtf,
like
mrg,
rg
and
so
on.
We'll
talk
about
sending
if
we
there's
an
interest
and
if
we
offer
discussion
today,
there's
a
strong
interest
in
in
recharger.
Maybe
we
should
get
started
to
send
emails,
get
more
people
from
mrg
and
power
to
engage
and
so
on.
B
We
should
also
engage
broadly
with
other
sdos,
for
example
at
ces
zsm
through
gpp
and
sense
and
gng
working
group
and
so
on,
and
they
can
really
drive
a
lot
of
to
make
it
relevant
because
they
essentially,
they
also
have
the
relevance
as
a
part
of
the
mandate
as
well,
and
industry
can
give
us
real
feedback,
for
example,
all
these
real
cases
from
from
the
connex
paper,
of
course,
for
recharger,
we
probably
can
have
debate
about
new
ideas.
So
therefore,
we
should
also
work
with
academia.
B
For
example,
I'm
going
to
really
make
this
one
a
big
discussion
in
the
sitcom
august
14th,
because
I
was
I'm
one
of
the
co-chairs,
I'm
I'm
also
going
with
the
culture
of
sosr,
which
is
while
the
major
conference
in
sdn.
So
I'm
also
going
to
make
this
one
like
integration,
a
big
part
of
that
conference
and
next
year
2021.
B
So
we
won't
have
all
the
kind
of
collaborations
next
slides.
Please
I'm
almost
done
okay
over.
Let
me
skip
away.
Let's
just
quickly,
basically
hear
these
people.
We
already
have
collaboration
the
network
providers,
channel
mobile
telephone
network
t-mobile
and
applications,
bannocks,
tencent
and
sense
project
and
qs
cloud
project,
and
then
there's
nokia,
eriksson
and
academia,
and
so
on.
So
I
think,
but
we
want
to
work
with
more
people
in
terms
of
collaborating
here's,
just
some
kind
of
example
about
industrial
collaborators
or
broad
collaboration
next
slides,
please.
B
B
Oops
for
the
technical
discussion,
basically,
is
that's
really
the
guidance
from
from
bg.
I
don't
need
to
repeat
and
give
out
the
video
already
mentioned.
It's
one
minute
slides.
Therefore,
that's
easy
next
slice,
and
next
one
basically
is
what
we
want
the
recharge
impossible
and
for
the
discussion
is.
B
What's
going
on,
so
the
structure
will
be
auto
client
server
and
multiple
servers
and
networking
substrate,
and
we
name
the
server
to
client
two
components.
One
is
abstraction
services
and
one
is
transport
and
second
services.
Our
content
transport
is
the
way
the
content
is
being
provided,
and
then
we
should
also
really
really
look
into,
for
example,
look
at
a
lot
of
complexes.
B
All
these
intel
issues,
and
so
on,
look
at
the
example
we
show,
and
we
should
look
at
back
in,
and
infrastructure
and
automation,
that's
the
source
bond
and
now,
of
course,
there's
a
big
part
about
auto
server
to
auto
server
communication.
That's
east
west
interface
server
to
server.
We
should
also
take
a
look
over
there
next
slides,
please
so
that's
essential
mental
structure,
and
so
here
is
the
way
we
organize
things
and
that's
how
we
really
decide
to
go
with
audio.
Like
a
one
sided
presentation.
Is
you
look
at
the
number
of
rows?
B
We
have
a
movie
which
is
central
network
ibc
and
huge
data,
automation
into
domain
and
auto
extension
as
use
cases
and
concrete
real
issues,
and
the
top
columns
are
for
con
essential
about
how
structures
and
then
we
organize
the
slides,
essentially
one
once
the
presentation
in
this
way.
Next
slide
is
please,
so
essentially
they
all
this
in
this
way,
so
we
want
to
get
to
work
touch
it.
So
here
is
a
list
of
the,
I
believe,
the
total
16
presentations
and
here's
mostly,
I
think
here
the
five
they
are
from
china.
B
Mobile
presented,
10
cent
and
and
so
on,
so
basically
most
of
our
services
want
to
provide,
and
so
on.
Okay
next
slide,
please
so
here
gay
people
rob
said
so:
people
don't
get
lost
and
here
is
also
a
lot
of
basically
abstractions
services
of
what
we
want
to
provide
and
so
on.
Next
slides,
please
and
here
is
as
well,
and
it
will
also
include,
for
example,
the
transport
which
we're
discussing
and
the
source
bound
and
automation,
which
are
very
important,
which
is
very
important
as
well.
So
therefore
they
are
including
this
way.
B
A
D
B
B
D
A
B
A
A
H
D
D
D
E
Hello,
can
you
hear
me
yeah?
Yes,
yes,
go
ahead:
okay,
okay,
hello,
everyone!
I'm
frank
li
kang
from
channel
mobile,
I'm
very
honored
to
talk
here.
This
slide
is
about
moving
information,
exposure
and
benefits,
and
proposals
are
regarding
the
problem.
Description
benefits.
I
think
the
central
network
indeed
are
getting
much
better,
but
the
network
variations
and
fluctuations
are
much
larger.
Let
me
take
4g
network
as
an
example.
E
The
4g
network,
only
several
million
beats
per
second
the
variation,
but
for
the
the
five
network,
even
the
the
gig
bits
per
second,
the
variation
is
much
larger.
On
the
other
hand,
the
application-
far
more
adaptive,
for
example,
they
adapt
to
bit
rates
mechanism,
is
widening
used
for
streaming
applications.
E
We
have
conducted
several
live
network
trials
and
it
is
proved
that
it
is
beneficial
to
expose
a
refined
granularity
of
scenery.
Information
and
such
kind
of
information
can
be
carried
while
inband
or
outband
for
application
usage.
Currently,
the
solution
is
pro
predatory
and
a
lot
of
standardized.
We
hope
atf
can
address
this
issue
and
come
up
with
a
standardized
solution.
The
following
scenario:
information
can
be
considered.
For
example,
the
ue.
E
We
have
to,
we
have
to
really
really
stick
by
the
minute.
We
are
at
a
minute
and
a
half
okay,
I'll,
be
quicker.
Okay,
I'll
be
quick,
the
ue
level
information
and
the
cell
slice
level
information
can
be
considered.
We
have
three
use
cases
to
prove
the
benefits
of
cellular
information
exposure.
The
first
use
case
is
ib
adaptive
bit
rate
for
cloud
gaming,
and
they
will
use
a
child
status
information
to
derive
the
the
predictive
bandwidth
for
the
adaptive
build
rates.
E
As
a
result,
the
liking
ratio
is
significantly
reduced
from
63
percent
to
19
percent
and
the
use
case.
2
is
a
video
qe,
a
quantity
of
experience
prediction
so
we'll
also
use
the
radio
channel
setters
and
some
user
plane
measurement
metrics
to
do
their
prediction,
and
they
we
also
use
a
user
merchandising
model
to
do
their
prediction
and
they,
the
accuracy,
is
quite
positive
and
it's
up
to
90
percent
off
the.
E
The
third
use
case
is
about
the
tcp
performance
organization,
where
you
utilize,
the
wearable,
ue
radio
bandwidth
and
then
from
base
station
and
buffer
size,
such
kind
of
information
to
adjust
the
tcp
window,
and
they,
the
throughput,
is
significantly
improved
by
30
percent
of
30
percent
off.
So
the
proposal
is
that
we
we
expect
to
extend
the
auto
to
provide
a
single
framework
to
support
the
cellular
information
explorer.
Okay,
that's
all
thanks.
D
D
L
Okay,
can
you
move
this
one?
Okay,
thank
you,
so
he
this
is
very
quick.
So,
basically,
today
there
are
multiple
computing
capabilities
being
deployed
in
in
operators
network,
and
this
is
the
aim
of
this
computing
capabilities
is
to
be
used
by
different
applications
right.
So
the
problem
is
to
identify
what
would
be
the
proper
edge
for
each
application,
because
we
need
to
differentiate
the
physical
edge.
L
D
A
B
Yeah-
and
this
actually
is
from
here
the
cloud
and
I
can
see
for
them-
I
I
think
they're
having
a
difficulty
connecting
and
joining
today.
So
basically,
what
they're
proposing
is
to
do
there's
a
draft,
and
I
think
they
should
put
link
over
there.
They
have
dropped
and
the
basic
idea
is,
and
they
want
to
deploy,
of
course,
not
only
resources,
but
they
also
want
to
deploy
functions
and
for
modern
applications.
B
Starting
point
because
provides
footprints,
but
only
for
very
specificity
and
high
cdn
capabilities,
and
here
the
proposal
is:
can
it
really
be
extended
to
include
footprints
and
capabilities
and
so
on
for
generic
functions?
I
think
it
will
talk
about
a
few
thousand
functions
under
yeah
and,
of
course,
if
successful,
they
won't
be
playing
at
particular
clock,
which
is
very
large
network
they're
trying
great
next
one.
So
this
is.
B
I
don't
know
why,
if
you
don't
mind,
I
can
I
can
speak
for
him.
Oh
I
don't
know
if
harvey
is
online
or
ching
or
okay,
probably
we
spend
more
time.
Looking
for.
Why
don't?
I
just
speak
on
their
behalf
very
quickly,
so
basically
harvey
and
human
audience
essentially
is
a
project
called
a
sense
project
which
is
a
dou
project
and
it's
a
beauty,
smart
network
to
exercise
big
discovery.
B
So
you
can
certain
and
all
this
stuff
is,
for
example,
lhc
and
other
very
large
scientific
projects
and
the
sense
project
is
intended
based
architecture,
it's
about
complex
workflows,
and
for
this
really
do
this
essential
internet
workflow
and
what
they
want
is
to
have
standardization,
because
essentially
you
want
to
auction
all
this
different
network,
because
oftentimes
they're
international
networks
and
therefore,
basically
what
they
want
is
they
put
auto-
is
good
match
but
resource
model,
but
somehow
they
do
see.
I
think,
if
you
see
over
here,
we
do
see
there.
There
are.
B
B
Binary
is
product
and
those
are
very
basic
services,
but
you
can
use
auto
as
a
base,
but
you
cannot
provide
it
so
they
won't
add
this
kind
of
new
services
apis
on
top
of
auto
and
on
top
of
it,
if
possible,
they
want
to
define
the
interaction
model,
standard
or
informational
between
the
model
and
as
well
as
lifecycle,
management
and
right
hand.
Side
is
some
very
quick
initial
design.
So,
basically
you
model
resources
as
time
series
and
you
introduce
a
language
and
language
example.
B
H
Hello,
hello,
that
works
go
ahead,
excellent,
all
right
yeah.
So
this
is
the
etsy
zsm
use
case,
so
just
going
through
quickly,
right,
etsy
is
a
framework
that
enables
automation
of
day
two
network
operations
for
5g
and
beyond,
with
minimum
zero
touch,
hence
the
zero,
the
zsm
name
so
in
this
use
case
we're
looking
at
a
domain
watching
or
managing
performance
of
an
end
to
end
voiceover
in
our
service,
for
example.
H
H
We
also
believe
we
can
support
intent
base
with
alto
with
zsm,
also
communicating
with
alto
bi-directionally
to
get
more
optimized
routes
just
kind
of
skip
ahead.
Lastly,
collaboration
with
etsy
zsm
is
probably
a
great
idea,
so
if
we
consider
a
liaison
statement
between
etsy
zsm
to
introduce
alto
and
how
zsm
could
leverage
alto
in
its
architecture.
H
L
K
Okay,
so
basic
on
the
on
the
guidance
for
potential
eating
to
be
considered
interior
charting.
We
have
the
relevance
and,
of
course
the
multi-demand
is
relevant.
It's
a
relevant
problem.
We
have
many
novel
use
case
that
or
where
the
traffic
traverses
multiple
domains
and
regarding
the
problem
stemming
and
solution.
One
very
important
starting
point
could
be
to
look
up
every
single
alto
service
to
making
multi-domain,
for
example,
the
aggregatory
square.
A
single
aggregator
would
be
able
to
represent
the
the
network
of
data
mains.
K
K
C
K
We
can
try
to
use
other
representations,
such
as
vector
representation
and
regarding
the
standard
direction.
We
have
different
personal
draft
regarding
demotivating
use
case
and
design
requirements
and
other
related
to
looking
for
alto
extension
to
to
what
is
the
the
discovery
mechanism
and
the
evaluation
mechanisms.
That's
all.
A
A
E
D
D
A
A
B
D
D
B
So
on
right,
can
I
just
show
two
very
quickly:
can
you
go
to
the
inbound,
outbound
and
also
lyles
aggregation?
I
think
those
two
actually
are
new.
They
are
not
shown
here
yet
so
they're
actually
important
because
they
are
they're
not
represented.
Some
other
ones
are
be
done
in
some
way
can
be
escaped,
skip,
skip,
go
down,
yeah,
go
down,
yeah,
go
down,
go
down
and
go
down
and
go
down.
This
is
the
last
oh,
these
are
11
slides.
D
B
Yeah
I
was
16,
so
I
do
one
okay,
but
probably
is
that
okay
for
both
and
the
twin
chain,
just
like,
maybe
to
give
like
a
30
second
very
quickly?
What?
But,
because
I
think
these
two
represent
two
very
important
directions
for
auto.
One
is
automation
which
allow,
and
one
is
transport
for
10
cent,
which
I
think
is
very
very
important-
is
that
okay,
I'm
sorry
I'm
pushing
for
this,
but
I
think
they
really
got
very
important
directions
for
autumn.
B
G
G
H
Hey
I'll
just
go
quickly.
The
slide
we
had
is
actually
an
old
id
on
alto
aggregation
actually,
rather
than
going
over
that.
What
I,
what
I
wanted
to
to
just
say
in
general,
is
it's
clear
that
there's
quite
a
few
ideas
being
submitted,
and
it's
it's
also
clear
right
that
they're
outside
of
the
existing
charter.
F
We
have
a
paper,
but
it's
missing
from
from
this
actual
workshop
description.
Now
attention
is
a
service
provider.
We
have
a
lot
of
cloud
gaming
service
and
we
during
this
stage
a
lot
of
cloud-based
applications
are
used
by
a
lot
of
people
staying
at
home,
and
we
found
that
in
the
the
current
thing
is
very
sensitive
to
the
delay
and
the
benefits.
F
F
A
A
Yeah
vijay
is
going
to
put
up
the
questions
that
normally
you
need
to
discuss
when
you
want
to
read
charter,
and
personally
I
I
want
to
reiterate
what
I
said
in
the
beginning.
I
think
we've
seen
a
lot
of
yeah.
Thank
you.
I
think
we
see
a
lot
of
use
cases
and
a
lot
of
energy,
which
I
think
is
very
good.
So
I
think
a
lot
of
people
have
interest
in
rechartering
alto
again
a
while
ago,
some
time
ago.
A
I
wasn't
so
sure
about
enough
energy,
but
I
think
that's
clearly
the
case
we
have
enough
energy.
We
have
interesting
use
cases
from
the
industry,
so
I
personally
think
rechartering
is
quite
quite
possible
would
be
very
useful
and
now
how
are
we
going
to
go
about
it?
I
think
we're
not
going
to
have
enough
time
for
discussing
it.
Yet
here
in
this
meeting,
unfortunately.
A
D
Probably
I
think
we
should
open
it
open
up
the
floor
to
anybody
if
they
want
to
say
anything
else.
Maybe
perhaps
you
know
this
discussion
out
of
necessity
was
focused
also
on
the
existing
work
items.
If
we
have
a
discussion,
if
you
have
a
meeting
next
time,
maybe
that
can
be
a
purely
recharter
discussion.
D
A
G
So
I
think,
there's
some
signals
that
would
be
useful
here
if
there's
a
strong
consensus
that
one
or
two
of
these
things
are
are
really
really
critical
for
us
to
move
forward,
then
that
would
be
quite
great.
Another
alternative,
also,
if
there's
some
sort
of
unifying
theme,
that
people
can
call
us
around
out
of
all
the
themes
that
sir
richard
proposed.
G
That
would
be
great
as
well.
We
need
to
start
creating
a
some
sort
of
framework
for
it
for
a
charter,
so
some
I
think,
discussion
on
the
list
before
we
have
a
meeting,
because
we
need
to
get
some
sense
of
where
people
are
gravitating.
We
can't
call
us
on
you
know
three
or
four
drafts
and
that's
a
problem
now
we
could
have
essentially
also
maintenance
working
group
where
they're
just
four
unrelated
things
they're
working
on.
G
A
A
B
I
I
think,
actually
I
idea
of
information
might
make
sense
right
and
the
election
is
talking
about
meetings
I
do.
Personally,
I
do
say
I
I
told
a
great
and
16
documents
and
16
directions
will
be
too
much
too
many
and
we
probably
need
to
narrow
down
to
a
few,
probably
four
or
five.
Is
that
right,
so
martin
and
obviously
you
know
typical
how
many
people
narrow
down,
I
think,
typically
my
understanding
would
be
a
lot
more
four
or
five.
Maybe
it
looks
like
right
size
work
right.
B
So
basically,
I
think
my
understanding
is,
let's
see
if
there's
a
way
we
can
agree
on
to
agree
on.
You
know
four
or
five
items
which
we
there's
some
kind
of
strong
consensus
and
therefore
we
should
all
work
together.
Of
course,
if
each
one
would
be,
you
know
relevant
and
with
expertise,
and
so
on
is
that
right
is
that?
Is
that
really
I
take
away
the
right
thing?
I
know
we
can
recharge
her
internal
making.
Oh,
I
don't
know,
what's
the
other
format,
but
that's
the
main
message
I
take
away.
B
G
D
L
So,
just
to
mention
I'm
also
in
favor
of
this
internet
meeting
in
order
to
not
take
so
long
till
the
point
on
deciding
what
could
be
those
future
lines
of
work.
So
I
agree
that
this
could
help
us
to
speed
up-
let's
say
all
the
resulting
process,
but
also
to
have
a
clear,
let's
say,
horizon,
of
what
we
could
do
here.
So
I
would
be
in
favor
of
that
interim
meeting
as
well.
D
A
Well,
let
me
phrase
it
this
way.
We
can
also
have
this
discussion
on
the
mailing
list.
Let's,
let's
try
to
have
this
discussion
in
the
mailing
list.
If
we
can
make
progress
there,
I'm
not
pushing
for
an
interim,
but
what
what
I
would
want
to
avoid
is
to
wait
to
the
next
itf
meeting
and
have
there
another
item
session
just
on
rechartering,
because
then
we
might
have
again
lots
of
presentations
and
it's
gonna
take
on
forever
right
so
yeah.
I
know
my.
A
To
have
the
rechartering,
if
there's
going
to
be
chartering,
I
would
have
would
like
to
see
it
done
before
the
next
itf
meeting.
Ideally,
we
can
make
this
progress
on
the
mailing
list
and
I
think
richard
made
some
good
comments
just
narrow,
and
there
was
some
good
advice
from
martin
just
narrow
down
the
many
directions
we
have
right
now
to
four
or
five
four
work
items
make
a
clear
proposal
and
then
we
can
go
from
there,
and
I
think
this
this
needs
to
happen
in
the
mailing
list.
D
B
D
Mean
my
sense
is
that
you
know
the
goals
have
to
be
reasonably
achievable.
So
obviously,
if
you
have
you
know
10
or
12
deliverables,
then
you
know
that'll
take
some
time.
So
let's
try
to
focus
on
what's
most
important
and
we
can
do
that
on
the
mailing
list
or
you
could
do
it
on
your
site
list
as
you've
been
doing,
but
just
circle
back
and
close
the
loop
by
posting
it
on
the
mailing
list.