►
From YouTube: IETF-IETF3GPP-20230712-1500
Description
IETF3GPP meeting session at IETF
2023/07/12 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
A
And
we
basically
have
two
things
on
the
agenda.
For
today
we
have
a
set
of
slides
that
just
cover
overall
ietf
pgpp
coordination
that
Lionel
will
go
through,
and
then
we
have
a
contribution
from
John
about
the
draft
that
he
and
others
are
have
worked
on
and
submitted
and
I.
Believe
it's
on
the
agenda
for
this
ITF
meeting
and
tswg
tsbwg
and
and
we'll
talk
about
that
as
well.
A
You
know
this
might
be
something
we
need
to
look
into,
have
a
little
bit
advanced
notice
and
to
share
that
with
a
broader
set
of
people
who
who
may
not
be
able
to
join
us
at
the
IHF
meeting.
So
that's
really
what
this
is
for
is
to
share
information
and
also
help
us
prep
for
things
that
we
might
want
to
dig
into
in
more
detail
at
the
actual
ATF
meeting
when
we
meet
there
and
we'll
talk
about
brought
that
a
little
bit
more
later.
A
A
A
F
G
F
A
F
H
H
C
H
A
Okay,
so
so
here's
the
overall
agenda
that
we
plan
to
go
through
in
Lionel
if
you're
able
to
hear
and
feel
free
to
jump
in
at
any
time.
But
first
of
all,
just
you
know
a
little
bit
of
a
round
table
that
was
sharing
with
what
the
overall
plan
was
here
and
then
we'll
go
through
the
some.
You
know
what's
been
going
on
between
3gp
and
ietf,
and
the
coordination
that's
been
happening
there.
A
Then
we'll
talk
about
the
status
of
some
dependencies
between
really
dependencies
that
the
gpp
specifications
have
on
ietf
documents.
Then,
just
for
information
there'll
be
a
sharing
of
the
the
plans
for
upcoming
3gpp
releases,
where
we
are
with
release
18
plans
for
19
and
and
some
very
early
discussion
and
thought
around
20.
A
A
J
Yes
about
the
trans,
sending
procedures
towards
CDP
perform
ideas,
I
mean
from
a
shares
perspective,
Etc
the
roles
I
mean
it's
what's
the
expectation
here.
Is
it
still
that
you
fill
in
the
form
and
you
touch
a
format-
the
document
with
the
actual
text,
as
you
can,
because
the
tool
sends
to
to
the
CDP
license,
but
it's
the
issue
was
I
guess
before.
Had
this
been
straightened
out
anymore,.
A
H
A
So
3gpp,
as
you
know,
I
think
we
all
know
now
they
they
expect
a
contribution
to
be
submitted
in
the
form
of
a
Word
document.
That's
formatted
a
specific
way,
just
like
other
meeting
contributions
that
come
into
the
3gpp
meeting.
That's
the
way
it
liaison
and
then
3gpp
responds
with
formal
response
back,
which
appears
very
similar,
but
it's
directed
to
ietf,
and
then
we
end
up
receiving
that
3gpp
document.
I
Yeah
I
think
Peter
speaking
here,
I
think.
The
point
is
during
this:
the
I
see
ITF
Aziz
line
statement
guy
woman
from
CBP.
If
she
receives
an
email,
she
always
looks
into
the
attachment
and
assumes
that's.
The
life
statement
is
in
the
attachment
and
if
you
have
sent
just
an
email
without
any
attachments,
then
she
does
not
know
what
to
do
with
this
one.
Then
she
do
not.
Then
she
has
no
idea.
A
H
H
A
I
H
I
J
I
A
A
So
now
we
can
use
that
as
a
space
for
sharing
information,
but
also
tracking
things
like
the
center
of
meeting.
So
so
I
think
that'll
be
a
handy
thing
for
us
to
have
also
just
like
with
regular
working
groups.
It's
an
easy
way
to
you
know
see
what
the
a
mailer
is
for
for
this
group
and
those
types
of
things
so.
D
A
A
The
other
big
thing
is
the
dependency
tracking
tool
and
we'll
talk
about
the
dependencies
that
we're
aware
of,
but
that's
kind
of
a
manual
process
that
that
fortunately
Lionel
is
pretty
Savvy
with
handling
and
identifying
these
Liaisons
and
then
but
the
tooling
that
we
have
in
place
that
basically
used
to
scan
all
three
gpp
documents
and
look
for
references
to
IHF
drafts
and
flag
those
and
highlight
them
for
us.
That's
not
working
anymore.
A
A
D
A
Think
the
important
thing
here
is
that
it's
for
people
who
are
you
know
working
across
ietf
and
3gpp.
Let's
provide
a
place
to
have
some
discussions
about
the
touch
points
between
the
two,
but
but
not
dig
into
or
duplicate
or
maybe
go
be
in
conflict
with
any
of
the
discussions
that
should
be
happening
in
3gpp
right,
so
this
work
is
still
being
done
in
3gpp,
but
just
when
there's
some
kind
of
overlap
or
touch
points
with
ietf.
J
A
D
A
A
The
liaison
statement
that
that
you
had
sent
previously
Magnus
to
sa3
telling
them
about
the
work
on
CTP
and
some
of
the
vulnerabilities
that
had
been
discovered.
You
know
within
the
IHF,
with
the
protocols
there
and
the
approach
that
was
being
taken,
and
then
that
kind
of
a
new
approach
that
the
working
group
is
looking
at
and
sa3
was.
You
know
thankful
that
that
information
has
been
provided,
thought
that
the
what
was
being
proposed
made
sense
and
just
basically
want
that
work
to
be
done.
You
know
yesterday
so.
A
A
Yeah
yeah
good
point.
We
certainly
see
that
within
3gpp
as
well.
That
there'll
be
that
reminder
that
hey,
if
you
want
to
get
something
done
in
3gp,
the
best
way
to
do
it
is,
you
know,
participate
in
3gpp
and
certainly
contribution,
and
so
similarly
make
it
clear
that
that
they're
welcome
and
it
would
be
appreciated
to
have
that
type
of
input.
Even.
H
D
D
A
A
Thank
you,
then,
the
other
one
here
this
is
I
believe
this
was
to
netmod
and
it
was
about
within
Yang
models
that
mechanisms
needed
for
handling
these
Concepts,
which
in
3gbp
have
been
termed,
as
that
is
invariant,
and
also
a
System
created.
This
just
results
in
some.
You
know
the
within
3gpp
they've
seen
a
need
to
have
some
way
of
identifying
this
to
within
the
Yang
models
to
say
that
yeah
you
have
these.
D
A
Make
that
clear
so
there's
a
a
draft.
That's
just
a
a
individual
draft
at
this
point,
it's
being
discussed
within
the
net
mod
working
group
and
trying
to
find
something
where
it
fits
nicely.
I
think
ietf
is
trying
to
find
some
a
way
where
it
fits
nicely
into
the
way
Yang
works
and
it
still
meets
the
needs
of
the
GDP
and
although
that
might
not
be
doing
exactly
what
HPP
is
doing
right
now.
So
let's
try
to
find
that
happy
medium
where,
where
it,
the
the.
H
D
A
B
H
C
So
as
you
said,
not
maybe
not
at
the
ATF
meeting,
if
it
might
not
be
needed,
but
at
least
to
be
active
on
the
mailing
list
and
I,
think
it's
a
general
feedback
that
we
should
again
and
again
provide
to
3gpp
guys
because
time
to
time,
especially
when
you
have
a
new
delegates,
the
the
forgot
about
this-
they
see
IHF
just
as
a
front
office.
When
you
can
push
some
requirements.
As
you
will
work
on
this
requirement
and
provide
the
feedback
to
3gbp.
C
I
would
say:
that's
the
same,
apply
for
ITF
guys,
so
I
think
it's
where
we
need
to
have
a
some
clear
guidelines
providing
to
both
organizations
to
ensure
that
when
something
is
requested
from
a
specific
SEO,
we
have
also
people
involved
in
this
SEO
to
be
able
to
to
to
to
to
move
forward
in
the
topic,
because
it
is
especially
within
3gpp
and
ITF.
It
is
a
contribution,
driven
or
comment
driven.
So
it's
something
that
we
need
to
to
to
remind
time
to
time
to
the
delegates
in
those
groups.
A
Yeah
yeah
definitely,
and
is
there
a
better
way
to
do
that?
No
mentioning
that
in
the
essay
plenary
is
a
good
way
to
do
it,
but
is
there
a
better
way
to
do
that
across
the
the
various
essay
groups,
or
do
you
think
we
should
have
something
to
quick
talk
with
the
chairs
and
like
an
essay
one
essay
two
essay
like
each
sh
subgroup
to
to
have
that
point
made?
Would
that
be
worthwhile.
G
A
C
A
C
No
problem
is
okay
for
everyone.
It's
fine,
okay,
so
this
one
is
just
for
information,
because
we
had
a
cross
discussion
on
this
topic
and
we
had
an
issue
with
the
later
specification.
From
top
of
the
you
can
wear.
A
lot
of
the
ionized
assignments
were
not
requested
or
requested,
but
we
had
no
clue
on
so
from
a
coordination
point
of
view
internally
into
a
gpp.
We
have
no
clue
about
what
will
be
the
output
of
this
request.
C
So
what
we
have
decided
it's
now
so
for
two
years,
I
think
we
have
decentralized
the
management
of
any
requests
into
INF
or
assignments,
and
we
have
also
a
specific
action
point
for
the
reporters
to
review
all
the
specification
to
collect
all
the
requirements
for
ini
assignment
and
to
set
it
to
to
the
icfe
as
well.
So
in
that
sense
we
are
able
to
track
any
need
for
either
assignment,
and
we
have
also
created
a
specific
registry
within
3gpp
to
list
all
the
pending
Ana
requests.
C
And
for
the
second
part,
is
that
you
know
that
we
had
a
long
discussion
regarding
the
support
number
assignment
request
coming
from
3gpp,
especially
for
internal
interfaces,
and
so
we
had
a
a
issue
of
that
and
what
we
have
defined
within
the
gbp's
alternative
to
out
assignment.
It
was
documented
in
a
specific
technical
report.
C
29941
and
one
of
the
solution
provided
in
this
report
was
to
rely
on
on
Dynamic
ports
to
be
able
to,
let's
say,
locally,
assigned
a
private
port
to
a
given
a
3gpp
interface,
so
it's
purely
intellectual
3gbp.
Obviously,
if
you
cross,
if
you
have
a
interdomain
interfaces,
this
type
of
solution
will
not
apply,
so
we
will
look
for
a
standardized
solution
like
a
gns
or
even
requested
report
number,
but
just
for
information.
C
Is
next
slide
please,
so
none
since
the
last
plenary
I
think
yeah
from
the
next
slide.
So
we
have
some
document
in
the
editor
queue
so
yeah,
just
as
a
reminder.
What
we
see
here
is
the
the
dependencies
that
we
have
some
with
semi
chip
draft.
Let's
say
that
this
draft,
our
normative
references
and
we
need
to
have
an
energy
publish
in
order
to
update
our
specification
and
the
complication
for
this
aspect
will
be
will
be
noted
as
completed.
C
So
it's
where
we
have
a
clear,
a
tech
monitoring
of
this
of
this
draft,
because
we
may
have
as
a
draft
and
I
will
have
a
talk
about
that
later.
So
we
have
the
one
from
here
on
the
error
handling.
So
this
one
is
in
the
editor
queue
so
we're
just
waiting
for
the
publication
of
the
RFC,
and
after
that
we
will
update
the
references
in
our
specification.
We
have
one
also
on
the
ace
for
the
extended
ttls
authorized.
C
Next
next
slide,
please,
after
that,
we
have
so
for
three
gpp
point
of
view.
They
are
both
at
the
same
level.
Editor
queue
or
aegfu
review
means
that's.
We
are
in
a
good
shape
and
we
are
confident
in
the
fact
that
bull
mites
are
soon
anniversity.
So
obviously,
during
AIG
review,
you
may
have
some
big
issues
and
we
will
need
to
address
them,
but
from
before
it
means
that
the
work
done
as
a
working
group
level
is
completed.
C
C
I
would
say
that
this
one
has
the
most
critic
are
most
critical
from
a
switch
PPP
point
of
view,
because
we
need
to
have
a
first
of
all
this
document
approved
as
a
working
group
document.
So
two
of
them
are
there.
We
had
a
longer
so
the
first
one
on
the
update
of
the
pvct
network.
It
was
this
graph
was
available
for
a
while,
but
it
was
block
because
in
the
working
group
they
wanted
to
so
in
support.
C
They
wanted
first
to
complete
ongoing
work
before
accepting
new
ones.
So
there
was
a
room
to
do
that
and
thanks
to
Brian
for
pushing
this
draft
forward.
So
it
was
in
a
working
group
class
school
a
couple
of
weeks
ago.
I
don't
know
if
I
changed
since
I've
checked,
but
the
draft
is
straightforward.
The
comment
received
for
this
draft
hour
straightforward
also
so
we're
quite
confident
of
the
fact
that
it
should
not
be
an
issue
to
move
it
forward
and
we
have
the
the
one
of
the
quick
multi-pass.
C
That
is
a
reference
in
some
of
our
specification,
especially
in
the
main
one
for
the
strategy
system.
So
it's
a
technical
specification.
23
23,
501
and
so
far
we
are
waiting
for
having
this
document
moving
forward
and
and
it's
where
we
need
to
have
also
action
from
the
interested
companies
within
three
gpp
to
help
also
IHF
to
move
forward
on
this
aspect.
C
C
Specification
and
we
have
a
normative
specific
enormative
reference
when
this
reference
is
added
to
a
technical
specification.
So
the
test,
let's
say,
there's
a
technical
specification-
is
the
normative
specification
and
we
have
another
type
of
a
document
called
technical
reports
in
which
we
have
some
studies
about
evolution
of
the
system
and
so
on
and
in
which
we
can
reference
also
ATF
draft.
But
this
draft
will
become
an
ITF
dependency
only
when
there
will
be
included
in
a
normative
specification.
C
C
F
B
C
C
Draft
and
when
they
are
really
intuitive
with
this
work,
and
especially
when
there
is
evidence
first
discussion
between
3gpp
and
ITF
on
this
topic
to
be
active
on
both
sides,
just
to
ensure
that
the
work
is
a
correctly
done,
entry
gpp
and
also
that
the
draft,
the
corresponding
graph
is
moved
forward
as
a
working
group
level.
First,
so
here
you
have
a
list
of
documents.
C
Next
slide.
Yes,
this
is
where
we
are
today.
So
today
we
we
are
completing
the
res
18..
So
we
are
the
protocol
level.
I
would
say
so
all
the
functional
aspects
and
so
on
our
our
Frozen
so
complete
it
from
the
3gpp
point
of
view,
and
we
are
now
working
on
the
on
the
protocol
aspects.
So
it's
where
we
need
to
have
at
the
end
of
this
period
the
work
completed,
let's
say
almost
at
the
same
time,
from
the
iets
side
so
and
so
for
release
18.
C
It
means
that
we
need
to
have
something
close
to
RFC
publication
and
for
release
19,
it's
only
the
beginning
of
the
of
the
early
industry.
We
are
currently
as
so
next
slide.
Please
for
race
19.
We
are
currently
defining
only
what
could
be
the
content
of
the
release,
so
the
the
the
main
topic
that
will
be
addressed
for
this
release,
and
so
the
content
will
be
defined
at
the
end
of
this.
C
The
rest,
so
so
for
12
months,
15
months,
we
will
work
on
on
the
on
the
on
the
functional
aspects,
and
after
that
we
will
go
through
the
through
the
protocol
aspects.
So
it
spells
that
if
anything
is
required
from
ITF
or
there
is
19,
it
means
that
we
need
to
have
something
available
about
the
March
25
June,
25
I
would
say
so
we
have
time,
but
it's
something
to
to
have
in
mind
right
now,
because
we
know
that
the
process
within
ITF
is
not
like
in
3gbp.
C
It
might
take
some
time
and
just
going
commission.
There
is
no
so
far,
no
discussion
about
the
CBD
and
if
there
is
anything
I
would
say
so,
if
that's
your
assumption,
it's
something
that
might
start
for
the
risk
20s
or
after
25,
and
to
have
something
available
for
normative
aspect
in
release
21..
So
let's
say
that
we
have
time
to
address
this
issue
in
3gbt
and
once.
A
C
But
from
from
United
point
of
view,
there
is
a
new
thing
and
it's
good
is
that
in
advance
people
trying
to
notify
what
might
be
retried
from
ITF
just
to
ensure
that
the
feature
will
be
completed
on
time.
So
it's
something
that
we
have
initiated
for
is
17
and
we
will
do
the
same
for
race,
19,
so
I
think
if
the
progress
number
to
what
we
had
in
the
past
and
I
think
we
can
conclude
here
because
after
that
it
was
just
any
other
business
and
we
have
one.
A
H
G
K
K
K
K
I
think
it
was
referenced
a
little
bit
in
what
Lionel
and
Charles
presented
on
slide
28.
For
example,
you
know
there
was
the
reference
to
one
of
the
drafts
in
3gpp,
which
has
now
become
a
standards
component
in
in
23
501,
but
I
want
to
caution
that
this
is
not
just
about
a
3gp
problem.
It's
about
a
wireless
problem
and
a
longer
term
problem
that
the
ietf
can
help
with.
K
K
What
are
possible
options
when
we
encounter
encrypted
media
which
is
not
solved
today,
I
think
in
fridge,
maybe
at
least
and
a
whole
bunch
of
solutions
that
we
can
look
at
and
why
we
need
to
look
at
that
in
the
longer
term,
with
the
media
that's
coming
up,
you
know
avatars
and
real-time
media
and
a
mix
of
that
and
how
we
handle
latency
and
bandwidth,
and
the
combination
of
all
of
that.
So
if
we
go
to
the
next
slide,
I'll
introduce
a
problem
in
a
little
more
detail.
K
Yeah
so
fundamentally,
I
think
the
challenge
that
3gbp
looked
at
in
release
18
and
has
now
standardized
for
RTP
payload,
is
how
to
handle
media.
That
requires
a
whole
bunch
of
I,
mean
a
high
bandwidth
and
also
very
low
latency
in
the
presence
of
these
transient
variations
in
link
capacity
and
the
observation
and
the
studies
that
went
on
there
also
say
that
the
random
or
tail
drops
affect
application
performance
adversely.
So
you
know
just
letting
the
wireless
network
just
drop.
K
Some
stuff
is
not
a
good
idea
and
the
decision
was
to
go
ahead
and
standardize
in
such
a
way
that
we
can
just
drop,
not
just
packets
but
a
whole
media
unit
like,
for
example,
a
p
frame
in
a
video
may
be
dropped
in
extreme
conditions,
while
an
iframe
would
not
be.
You
know,
and
that's
the
that's
the
real
issue
that's
being
interested
here
and
a
part
of
the
solution
that
3gp
we
looked
at
is
both
Alpha
rest
congestion,
I
mean
l4s,
condition,
feedback
to
react
and
also
the
selective,
dropping
and
I
think.
K
K
If
you
want
to
really
maintain
that
full
bandwidth
in
the
presence
of
very
high
transient
link
capacity,
variation
and
I
just
wanted
to
note
that
this
capacity
change
is
going
to
be
even
worse
for
millimeter
radio
accesses
because
any
obstruction
or
something
is
going
to
massively
decrease
bandwidth
and
then
then
very
next.
Many
second,
you
have
a
huge
amount
of
bandwidth
and
so
on
you
know,
and
some
of
the
things
are
what
the
scheduler
can
do,
but
some
of
the
things,
especially
from
applications
like
media.
K
So
all
of
these
are
coming
up
and
we
could
look
at
it
as
a
long-term
issue.
So
this
is
very
focused,
it's
not
for
the
large
internet,
but
it
is
for
the
access
side
and
I
just
want
to
point
out
that
this
draft
we're
not
looking
at
just
the
3gb
wireless
network.
I
think
it
would
benefit
the
Wi-Fi
and
I
hear
from
talking
to
people
offline,
maybe
even
cable
networks
and
others.
K
So
essentially
what
we
characterize
as
a
wireless
router,
that's
going
to
classify
and
then
let
the
wireless
network
do
I've
sort
of
put
it
in
this
figure.
As
you
know,
the
classifier
in
3gpp
terms,
is
more
or
less
the
UPF
which
takes
this
RTP
payload
and
looks
at
the
header
classifies.
This
separates
it
into
different
media
streams
and
so
I
mean
sorry,
qos
flows.
K
K
You
know,
we've
looked
at
a
whole
bunch
of
I
mean
there
are
probably
a
whole
bunch
of
solution,
options
that
come
up
and
I
guess
some
of
the
criteria
that
we
looked
at.
Were
you
know
the
evolving
media
encoding
I
mean
not
just
video
or
one
way,
I
mean
it
must
maybe
sensory
input
or
you
know
real
and
generated
content
with
different
delay
aspects.
How
we
handle
the
feedback
and
packet
pacing.
There
may
be
multiple
L2
Wireless
paths,
application
preferences.
K
A
second
so
I
think
dsap
is
going
to
be
very
hard
to
change.
It's
it's
fundamental
and
I.
Don't
think
it's
practically
changed,
but
it
would
have
been
ideal.
The
the
second
option
is
using
a
media.
Header
extension
I
mean,
for
example,
a
UDP
header
extensions,
that's
what
was
referred
to
in
slide,
28
that
Lionel
and
Charles
presented
as
well.
K
So
you
know,
and
you
could
send
it
in
band
or
tunnel,
and
if
the
application
can
give
some
of
those
information,
then
the
wireless
router
can
classify
and
do
all
the
things
that
it
is
doing
currently
with
unencrypted
RTP.
Another
option
would
be
also
to
use
mask
in
a
similar
way,
except
that
with
mask
I.
K
Think
one
of
the
considerations
that
doesn't
work
out
so
well
is
performance
because
every
packet
would
have
to
be
every
packet,
or
at
least
a
few
packets
or
a
class
number
of
packages
would
have
to
be
decrypted
at
the
wireless
router.
For
examination
and
classification-
and
it
may
just
defeat
the
whole
thing,
but
it's
a
similar
mechanism-
a
third
mechanism
would
be
to
look
at
congestion,
control
segments
and
I
think
this
is
complementary.
K
To
any
other
method,
I
mean
we
could
place
a
media
relay
at
the
mobile
Edge
and
I
guess:
we'd
have
to
come
up
with
even
more
optimal
condition.
Control
for
the
mobile
segments.
I
see
this
as
a
potential
longer
term
solution
and
complementary
with
the
media
header,
because
you
know
the
media
header
again
is
looking
at
sub
millisecond
kind
of
optimizations
or
in
the
order
of
milliseconds
and
the
congestion
control
mechanisms
are
looking
in
the
order
of
hundreds
of
milliseconds
others
that
have
come
up.
K
You
know
in
offline
discussions
and
in
3gpp
is
one
is
to
use
a
media
of
a
quick
relay,
but
I
think
this
will
end
up
with
complex
key
distributions.
I
mean
should
3gpp
or
Wireless
providers
or
Wi-Fi
providers
have
to
get
the
key
and
keys
for
all
of
all
the
media
level
of
handling,
and
also
it
would
not
work
for
RTP
specific,
because
it's
medievable,
quick,
a
solution
that
came
up
in
3gpp
was
to
use
gtpu
and
terminate
it
at
the
media
server.
K
But
I
think
the
discussion
was
essentially
that
media
servers
will
not
likely
write
your
socket
for
gdp2
and
give
all
those
details,
and
this
last
one
on
sharing
Keys
also
has
come
up
off,
and
on
that
you
know,
maybe
the
application
provider
can
give
the
keys
to
the
wireless
network
provider,
but
that
as
a
whole,
is
not
so
practically
either
because
it
works
breaks.
End-To-End
security,
I
think
Magnus
was
asking
for
a
comment.
I
think.
K
K
Yeah,
I,
I,
I,
I,
think
the
issue
with
the
UDP
header
extension.
If
we
don't
encrypt
it
would
be
that
it
would
have
to
be
secured
in
some
way.
If
we
use,
if
we
encrypt
it,
then
you
know
we'd
have
to
pay
a
performance
penalty
as
it
stands
currently,
because
we
we
did
look
at
I
mean
some
of
the
authors.
K
You
know
we
looked
at
what
it
would
take
to
decrypt
and
all
of
that
of
the
router,
and
it
would
be
basically
offloaded
and
handled
and
seems
to
be
a
pretty
challenging,
but
yeah
we'd
have
to
then
think
of
trust
domains
and
all
that
yeah.
That's
something
we
should
be
discussing
completely
agree.
If
we
go
to
the
next
page
and.
K
So
yeah
I
can
even
skip
this
because
this
is
just
one
solution.
I
think
the
key
point
was
in
the
previous
way.
So
if
we
go
to
the
next
page
I'll
just
summarize-
and
you
know,
this
is
just
one
solution.
What
we'd
like
to
see
is,
you
know,
I
mean
I've
outlined
the
problem
and
what
3gpp
has
done
and
that
you
know
fully
encrypted
media
needs
additional
mechanisms
so
and
the
3gp
is
going
to
look
at
it,
but
you
know
we
want
a
broader
solution
across
various
accesses
and
media
transports
and
applications.
K
D
I'm
gonna
say
thanks
and
saying:
thanks
I
see
that
there's
a
side
meeting
on
something
related
to
metadata
and
signaling
for
transport
and
the
ITF,
and
also
we
will
put
space
in
tsvwg's
agenda
to
talk
about
this
specific
draft.
So
this
is
something
that
I
in
the
ietf
group.
We
would
love
to
see.
Progress
on
quickly
like
people
would
have
to
say
if
they
want
to
do
this
work,
so
we
can
get
started
because
I
can
see
it
might
take
time
to
settle
on
one
particular
outcome.
J
Yeah
I,
so
my
headset
died
before,
but
yes,
I
am
I've,
been
in
some
discussion
with
the
authors
of
from
it
about
the
sad
CDN
proposal
and
and
where
I
mean
that
thesis
is
another
view
of
this
and
saying
in
relation
to
the
how
to
encrypt
or
how
to
establish
a
secure
Channel
between
this
endpoint
and
the
network
and
I.
Think
that's
a
crucial
part
here,
which
we
hadn't
had
when
we
discussed
before
and
dealing
with
the
kind
of
plastics.
J
Not
a
headset,
you
you
run
into
this
certain
issues
here,
so
I
think
it's
an
important
aspect
that
we
need
to
from
a
nice
Dev
perspective
have
a
generalized
technology
for
this.
It's
at
least
reaching
certain
certain
applications
and
use
cases
goals.
It's
it's.
It's
going
to
take
some
time
to
agree
on,
what's
what's
the
actual
relevant
aspects
of
it
Etc
and
how
to
make
it
performant
enough
to
do
it
in,
in
the
at
closed
line
rate,
the
housing
at
line
rates,
yeah.
D
D
D
A
Great
and
speaking
of
next
steps,
I
think
what
I'm
going
to
do
is
jump
back
to
close
this
and
and
just
to
say
further.
We
have
a
time
during
the
lunch
break
on
Monday
for
ietf
pgpp
coordination,
and
these
slides
that
we
talked
about
today.
Both
the
ones
Lionel
presented
and
this
presentation
from
John
I'll
make
sure
uploaded
in
the
the
media
materials
for
that.
But
but
the
plan
is
not
to
really
discuss
those.
It's
rather
to
talk
about
some
of
the
the
things
we
we
identified
on.
A
Oh
and
then
communication
back
into
3gpp
kind
of
to
to
talk
about
action
items
there
among
a
group
of
folks
who
might
be
able
to
help
move
those
discussions
forward,
so
I'll
be
putting
a
lot
and
all
my
we'll
put
together
an
agenda
and
work
with
Peter
on
that
as
well,
and
if
you
have
any
other
topics
that
you
that
you
want
to
add
to
that,
just
just
raise
them.
There'll
be
an
invite
out.
A
I'm,
not
sure
how
we're
going
to
do
it,
probably
to
the
same
mailer
that
this
meeting
invite
was
sent
out
to
I.
Think
we're
still
trying
to
figure
out
how
many
people
are
really
involved
in
this.
This
having
only
12
people
here
makes
me
think
it
would
be
a
pretty
manageable
group,
but
we'll
pull
in
more
more
people
from
the
iesg.
Who
will
you
know
just
be
there
and
and
from
the
IAD
to
will
want
to
join
in
so.