►
From YouTube: IETF110-INTAREA-20210312-1430
Description
INTAREA meeting session at IETF110
2021/03/12 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
Can
anyone
help
with
the
minutes?
I'm
gonna
be
taking
notes
myself,
but
it'll
be
best
if
we
have
a
backup
to
take
whatever
notes
I
could.
I
could
miss.
C
A
Thank
you
and
well
it's
the
hour
now,
so
I
guess
we
can
get
started.
A
Welcome
everyone
to
itf
110
interior
working
group.
My
name
is
juan
carlos.
A
Second,
one
here
with
the
screens,
so
the
virtual
meeting
tips
and
etiquette:
please
join
the
queue,
raise
your
hand
before
participating
so
that
we
can
handle
the
the
queue
and
make
sure
that
your
mic
is
muted.
Unless
you
are
speaking,
ideally,
we
want
to
turn
off
video
to
save
bandwidth
and
below.
You
have
the
the
details
about
the
meetings
and
mythical
for
the
node.
Well,
this
is
an
official
meeting,
you're,
probably
familiar
by
now,
but
by
participating
in
this
meeting,
you
agree
to
follow
the
ietf
process
and
policies.
A
So
please,
if
you're
aware
of
any
contribution
that
it's
covered
or
related
to
a
patent
or
patent
application,
please
disclose
it
either
to
the
list
or
to
the
chairs.
A
Also
for
your
information,
this
meeting
will
be
will
be
recorded
and
your
attendance
will
be
registered,
so
minutes
are
being
taken.
The
your
presence
again
is
locked
for
the
scribes.
I
actually
have
the
wrong
links
there,
but
it'll
be
best
if
we
can
contribute
the
the
online
minutes
to
the
to
the
kodi
md
directly.
A
As
a
reminder,
these
minutes
are
going
to
be
public
and
may
be
subject
to
discovery
in
the
event
of
any
litigation.
A
A
D
On
the
other
end
right
to
be
honest,
this
eric
here
there
is
no
real
need
anymore
to
use
jabber,
so
no
need
for
javascribe,
okay,
perfect.
A
Thanks
eric
so
moving
on
to
the
to
the
agenda
bashing,
so
we
are
going
to
start
with
the
usual
document
status
updates
from
us.
A
I'm
then
going
to
move
on
to
give
you
an
update
about
the
martinez
above
that
took
place
at
the
last
ietf
and
the
site
meeting
that
took
place
yesterday
about
mac
address
randomization.
A
Then
we
have
tommy
talking
about
perpetuation,
networking,
pascal
on
chic
or
ppp
shipping
on
apn,
and
then
we
have
e-how
on
challenging
scenarios
and
problems
in
inter
in
internet,
addressing
any
questions
or
points
about
the
agenda.
A
A
We
also
had
the
ip
fragmentation
considered
fragile,
published
as
rfc
8900
and
the
gui,
which
is
version
nine.
It's
it's
an
idea
evaluation
so
still
going
through
the
through
the
process
of
publication.
A
A
Moving
on
just
a
quick
update
on
the
on
the
martinez
status,
madina's
is
a
buff
that
took
place
at
the
ietf
109
to
look
at
mac
address
randomization,
especially
around
wi-fi,
and
the
effects
on
networking
protocols
and
infrastructure.
A
So,
basically,
is
how
to
address
the
fact
that
new
standards
and
operating
systems
are
now
randomizing
mac
address,
and
this
is
because
of
privacy
issues
that
were
held
before
regarding
the
long-lasting
identifiers
embedded
in
especially
in
ie802
protocols,
notably
the
mac
address
that
could
be
used
to
track
individuals
unwillingly
and
then
there
have
been
new
changes
to
standards
and
operating
systems
where
this
address
is
changed
now,
because
this
address
was
used
as
an
identifier
by
upper
layer
protocols,
we
are
looking
at
what
could
be
the
potential
disruptions
on
these
protocols
and
if
there
are
existing
solutions,
if
this
solution
should
be
recommended
or
if
actually,
we
need
to
work
on
some
new
solutions.
A
Of
course,
this
and
the
scope
of
ietf
meaning
protocols
like
dhcp
and
so
on.
So
there's
a
couple
of
drafts.
One
was
discussed
heavily
yesterday
on
the
problem
statement
draft
henry
medinas.
A
Then
there
is
also
the
micro
randomization
background
by
myself
and
and
a
couple
of
authors
amelia
carlos,
that
tried
to
explain
what
is
the
background
of
this
effort
and
in
the
upcoming
meetings
we
are
expecting
to
have
a
first
an
entering
meeting
in
mid-april,
and
then
we
are
for
seeing
probably
having
another
buff
at
ietf
111.
A
So
if
you
are
interested
in
this
topic,
we
encourage
you
to
join
the
mailing
list
and
you
have
the
link
there.
A
Okay,
so
that's
it
for
updates.
A
Next,
we
have
tommy.
E
Share,
do
you
have
the
slides
on
your
side.
A
A
A
A
E
Thank
you
for
sharing
this
all
right,
so
I'm
going
to
be
sharing
a
update
on
a
draft
that
we
actually
wrote
last
november.
We
didn't
have
time
to
talk
about
it.
Then
we
haven't
done
an
update
because
I
think
it's,
the
content
we
believed
was
still
relevant,
but
we'd
like
to
have
a
discussion
here
and
get
people's
input
and
see
if
it's
something
that
we
believe
that
this
group
should
work
on,
and
so
this
is
a
draft
about.
E
Perhaps
networking
considerations
and
I
have
co-authored
this
with
lorenzo
from
google,
I'm
from
the
apple
side
and
next
slide.
Please.
E
So
the
motivation
behind
this
is
we've
seen
a
lot
of
conversations
in
ietf
in
proposals
as
well
as
conversations
outside
of
iatf
in
3dgbp
and
other
venues
that
are
talking
a
lot
about
having
application
based
networking
application.
Aware
networking
having
you
know
a
tighter
integration
between
the
network
and
applications,
and
this
has
a
big
impact
on
the
architecture.
It
has
a
big
impact
on
how
we
think
of
data
going
through
the
internet
layer
and
what
we
felt
was
missing
was
a
ietf
kind
of
statement
and
position
around
the
problem
space.
E
Problem
space
description
draft
is
meant
purely
to
be
informational
to
help
kind
of
set
the
stage
and
define
the
principles
that
we
as
a
community
would
believe,
are
the
right
ones
to
approach
this
problem,
and
so
we
tried
to
write
down
what
we
thought
were
the
principles
that
we
were
coming
from
as
client
os
implementers,
but
we'd
be
very
happy
to
have
that
scope
and
authorship
be
broadened
next
slide.
Please.
E
So
I'm
just
going
to
walk
through
essentially
the
different
sections
of
the
draft
and
what
we're
saying
in
it,
if
you
haven't
read
it
so
generally.
First,
we
start
out
with
the
use
cases-
and
there
are
you
know
many
legitimate
use
cases
in
which
there
is
a
desire
to
have
more
deep
integration
between
an
application
and
a
network.
E
Some
of
the
use
cases
are,
you
can
have
a
very
dedicated
network
access.
That's
only
meant
for
specific
things.
This
is
very,
very
common
in
the
cellular
world,
in
which
I
have
a
specific
apn,
that's
only
usable
for
a
specific
application.
E
That's
doing
messaging
voice
calls
something
like
that,
but
you
also
see
this
when
you're
on
a
walled
garden
network,
and
you
can
only
access
the
media
on
the
airplane
through
this
particular
link,
and
you
want
to
be
able
to
have
a
strong
binding
between
your
media
player
and
that
particular
access-
and
this
is
very
much
related
to
the
work
that
we
already
did
in
into
area
around
provisioning
domains.
E
E
E
So
those
were
kind
of
that's
the
positive
side
of
what
you
know.
What
are
people
trying
to
achieve?
But
there
are
a
lot
of
concerns
about
how
we
approach
this
problem
and
how
we
achieve
that,
and
today,
generally
we've
kind
of
just
fallen
into
mechanisms
that
were
convenient,
because
there
was
a
lot
of
information
that
was
sent
purely
unencrypted
available
to
anyone.
So
you
could
do
a
lot
of
interception
or
deep
packet
inspection,
so
this
can
happen
by
intercepting
dns.
E
E
So
this
has
led
to
a
lot
of
these
new
proposals
that
we
are
listing
here
and
so
we're
trying
to
in
this
draft,
explore
the
implications
and
suggest
ways
of
mitigating
the
problem.
Next
slide.
Please.
E
So
you
know
some
of
the
problems,
of
course,
are
around
open
internet
or
net
neutrality,
how
traffic
is
being
treated
if
this
is
being
done
without
any
consent
of
the
user
of
the
application
that
can
lead
to
a
lot
of
problems
and
they're.
Essentially,
you
know
two
general
types
of
mitigations
you
could
have
to
this.
E
You
could
more
generalize
the
markings
you
have
for
your
traffic
to
say
that
we
need
to
focus
on
traffic
classes
and
traffic
categories
more
than
specific
application
identifiers,
and
the
other
alternative
is
to
put
more
trust
into
the
network
that,
if
you're
not
going
to
just
give
generic
markings
you're
going
to
need
to
have
user
opt-in,
application,
opt-in
and
network
opt-in
and
have
some
form
of
trust.
E
E
And,
of
course,
there
are
many
many
privacy
implications
if
you
are
blindly
putting
application
information
onto
the
network.
There
are
many
statements
that
itf
has
already
made
around
saying
that
your
network
protocols
should
not
be
exposing
information
unnecessarily
to
the
network.
It's
particularly
when
it's
privacy
sensitive
the
applications
and
the
patterns
of
usage
that
users
have
is
critically
important
to
keep
private
like
that,
is
very
much
their
data
and
can
be
abused
and
misused
in
many
many
ways.
E
So
we
need
to
be
very
serious
about
that,
and
it's
good
to
note
here
that
your
identity
can
be
exposed,
even
if
you
aren't
explicitly
saying
I'm
using
this
network.
If
we
I'm
sorry
I'm
using
this
application,
because
if
there's
a
policy
that
the
client
learns
about
to
say
that,
oh
yes,
this
provisioning
domain,
this
network
slice-
this
you
know
path-
is
only
meant
to
be
used
by
the
netflix
app
and
you
see
packets
on
that.
You
know
for
sure
that
that
user
is
using
that
application.
E
So
you
know
it's
not
quite
good
enough
to
do
that
either
and
again,
we
kind
of
realized
that
the
mitigations
that
were
obvious
here
are
either
saying
we
need
to
generalize
the
information
we're
giving
to
make
it
more
like
a
traffic
class
or
a
category,
or
we
need
to
have
more
trust
and
consent
all
the
way
through
the
path
next
slide.
Please.
E
We
talk
a
little
bit
in
the
draft
about
suggestions
for
how
you
define
categories
to
generalize
traffic.
You
know,
traditionally,
we
already
have
markings
like
dhcp
bits
and
that
can
essentially
just
give
different
buckets
of
traffic
class.
E
It
is
possible
to
say
that
you
know
we
could
have
more
specific
categories
for
categories
of
different
types
of
applications.
E
We
could
say:
maybe
you
know
this
is
a
interactive
game
as
opposed
to
an
interactive
video
call,
and
there
could
be
a
discussion
around
where
the
line
is
for
that
being:
okay
from
a
neutrality
and
privacy
standpoint
to
share,
but
we
believe
that
that
is
where
the
discussion
needs
to
happen,
and
we
also
make
a
note
that-
and
this
is
particularly
important
for
the
client
os's
when
we're
talking
about
architectures
that
could
give
information
to
the
network.
E
We
need
to
make
sure
that
we
have
bounce
on
the
types
of
apis
that
the
internet
and
transport
layer
are
offering
up
around
how
you
signal
this
information.
We
don't
want
to
see
a
world
in
which
applications
identifiers
are
automatically
scooped
up
by
an
os
and
being
marked
on
the
half
of
applications
without
their
intent.
E
We
need
to
have
some
sort
of
very
explicit
opt-in
and
a
way
that,
if
we're
going
to
go
down
the
road
of
having
more
trust
between
the
network
and
the
application
and
the
user,
we
need
to
bootstrap
that
trust
by
allowing
applications
to
select
or
indicate
what
type
of
treatment
they
allow
for
their
network
traffic.
E
This
could
tie
into
how
applications
are
aware
of
different
provisioning
domains,
but
that's
an
area
that
could
be
explored
more
next
slide.
Please.
E
So
that's
a
summary
of
the
document.
It's
pretty
short,
I
think
it's
something
that
we
would
like
to
plant
as
a
seed
and
see
how
we
can
expand
upon
and
get
more
input
from
people.
E
We
believe
that
there
is
a
need
in
this
conversation
for
a
document
about
principles
and
requirements
so
that
we
can
point
to
something
when
we're
having
discussions
within
the
ietf
as
well
as
in
other
sdos,
if
we
as
a
community
think
that
the
internet
layer
should
be
used
in
a
certain
way,
let's
explain
that
so
I'd
like
to
hear
from
people
if
there's
interest
in
exploring
this
problem
here
and
if
we
think
that
int
area
is
an
appropriate
place
for
this,
we
thought
so
given
some
of
the
previous
work
we've
done
here,
but
if
there's
a
better
venue,
we'd
love
to
hear
that
as
well.
F
F
Two
other
presentations
this
week
on
this
topic,
but
they're
in
the
solution
space,
and
so
since
you're
talking
about
the
problems
considerations,
that's
why
I
think
this
is
the
best
of
those
three
talks.
The
other
ones
were
in
dispatch
which
is
app
area
and
then
another
one
was
in
the
security
area
in
saag,
okay,
and
so
this
gets
to
your
question
about
what's
the
appropriate
place,
because
I
think
the
apps
area
is
very
much
interested
in
this
topic.
The
security
area
is
very
much
interested.
F
I
think
the
style
of
stuff
that
you're
talking
about
in
this
draft
right
now
is
most
appropriate
for
the
internet
area,
and
so
I
might
think
that
internet
area
is
the
best
place
for
it,
meaning
I
agree
with
you
on
that
one,
but
it's
gonna
want
a
review
and
input
from
both
apps
and
security,
given
that
they
are
discussing,
they
discussed
it
even
this
week
right.
So
that's
my
main
comment
on
that
one.
So,
yes,
I'm
absolutely
interested
in
it,
and
I
I
know
this
is
a
draft
zero
zero.
F
I
would
be
happy
to
help
with
this
one
if
you
want
additional
help
with
this
one.
I
see
you
got
authors
from
the
other
two
os
vendors.
If
you
want
somebody
from
microsoft,
I'd
be
happy
to
help
contribute
so.
C
Tommy,
thank
you
a
lot
for
this.
For
this
talk
I
would
say
definitely
yes
interested
in
doing
a
document
on
this
and
I'm
personally
interested
in
exploration
here.
The
one
question
I
would
ask
you
is
whether
you
think
this
is
engineering
or
research
and
I'm
not
asking
you
whether
people
are
doing
engineering
now.
I
know
the
answer
to
that.
I'm
asking
whether
you
think
it's
really
engineering
or
research
discussions
we've
had
in
the
pan.
C
Rg
research
group
over
the
past
several
years
have
really
talked
about
in-host,
trusting
network,
those
and
network
nodes,
trusting
host
as
two
of
the
really
intractable
problems
that
people
have
been
trying
to
deal
with.
We
we,
you
know
pedergy,
isn't
where
the
expertise
is
on
that,
but
we
know
a
lot.
You
know
we
know
a
lot
of
places
of
things
are
blown
up,
so
I
would
I
would
I
would
encourage
you
strongly
to
do
it
someplace.
C
I
would.
I
would
be
interested
in
helping
if
that's
helpful
and
but,
like
I
said
I
would
I
would.
I
would
like
for
people
to
be
really
crisp
on
whether
this
is
ready
for
engineering
yet
or
whether
it's
really
research.
E
Yeah,
thank
you
for
bringing
that
up.
Just
you
can
say
that
just
to
respond,
I
I
personally
think
that
there
are
actually
you
know
three
different
legs
of
what
we
can
say
in
this
area.
I
think
we
should
say
all
of
them
and
I
think,
there's
a
leg
of
this.
That
probably
belongs
in
iab.
That's
an
architectural
statement
about
how
these
things
all
work
together.
E
E
E
These
are
the
ways
that
we
think
it
is
bad
to
use
the
tools,
because
there
are
conversations
that
are
going
on
actively
in
you
know.
How
do
we
deal
with
5g
slices
and
stuff
that
our
engineering
decisions
today
in
how
we
expose
apis
to
applications
to
deal
with
slicing
that
we
need
to
make
decisions
about
at
an
engineering
level?
E
C
I
think,
and
if
that
turned
into
a
anything
like
a
gap,
analysis
for
two
additional
tools
that
we
would
need,
I
think
that
would
be
absolutely
fabulous
and
I
would
hope
I
would
hope
a
future
isg
would
be
excited
about
doing
a
buff
on
that
enjoy
your
day.
A
Thanks
so
we're
stopping
the
queue
now.
So
if
you
brief,
this
is
an
interesting
topic,
so
I
want
to
give
a
chance
to
everyone.
So
please
be
mindful
of
time
and
try
to
be
to
the
point.
B
So
here
I
would
like
to
thank
you
and
for
your
suggestions
on
the
apn,
especially
you
referred
to
it,
and
you
gave
us
some
suggestions
on
how
to
mitigate
the
privacy
issue,
and
you
know
that
the
privacy
has
been.
The
we
could
say
is
the
top
challenges
that
people
has
been
asked
on.
Apn
work,
and
so
your
suggestion
is
to
categorize
the
traffic
and
making
them
as
a
group.
But
actually
it
has
been
like
this
and
it
we
just.
B
We
didn't
explicitly
express
that
in
the
draft,
and
so
thank
you
for
your
draft
and
we
have
further
refined
our
proposal
and
but
our
focus
is
more
on
the
network
layer,
and
so
we
would
like
to
to
provide
the
network
services
within
the
operators
control
network
domain.
So
I
will
present
it
later
and.
D
B
Would
like
to
have
your
review
and
comments.
Thank
you.
E
Thank
you
and
just
to
clarify,
I
think,
some
of
the
conversation
around
apn
and
other
things
has
spurred
on
the
need
for
a
statement
here.
But
I
we
do
not
view
this
as
specifically
a
critique
on
that,
but
actually
a
critique
of
the
overall
space
and
trying
to
have
a
piece
of
work
that
can
be
used
by
apn
documents
by
other
documents
as
something
to
point
to
and
build
upon,
principles
to
use.
A
Thanks
media.
G
Yeah
hi,
so
I
I
do
agree
very
much
to
the
point
that
we
should
not
add
any
additional
personal
identifiers
to
any
of
the
protocols.
That's
really
important
and
you
add
some
some
priority
discussion
to
it,
but
I'm
not
fully
agreeing
actually
to
the
rest
of
the
accommodation
given
in
this
document.
C
G
Is
basically
yes,
I
understand
it
use
application
identifiers.
Instead,
gary
made
my
point
on
the
chat
already
a
little
bit
and
I
think,
like
whatever
information
you
signal,
is,
is
very
specific
to
what
you
want
to
achieve
in
the
network
and
it
has
to
be
tailored
exactly
to
that
point.
So,
there's
not
like
one
set
of
information
that
you
would
just
like
broadcast
in
the
network
and
then
you
hope
something
nice
is
happening.
G
I
think
this
is
a
pair
case
pair
mechanism
case
basis
to
figure
out
what
is
the
right
information
what's
minimal,
set
of
information
to
not
reveal
anything
that
you
don't
want
to
reveal,
but
also
to
make
sure
that
you
get
exactly
out
of
it.
What
you
want
to
get
right,
because
the
risk,
if
you're,
providing
like
more
information
than
needed,
is
that
the
network
actually
does
something
with
it
that
you
didn't
expect.
G
So
these
are
all
good
points
which
I
don't
think
is
like
exactly
what
you're
saying
in
the
document,
and
especially
there
has
been
a
lot
of
research
work
about
trying
to
use
application
identifiers
and
make
somehow
use
of
them,
and
it's
really
hard,
because
applications
are
not
really
classifiable,
there's
like
every
day,
a
new
application
and
they
have
all
slightly
different
requirements.
E
Okay,
I
think
I
would
appreciate,
then
you
know
we
could
have
review
or
the
specific
recommendations
can
certainly
be
changed
and
evolved
to
be
kind
of
what
this
group
and
what
the
community
wants.
But
I
think
this
is
a
place
where
we
can
start
iterating
on
that
from,
and
you
can
point
out,
you
know
what
are
the
things
that
are
can
be
refined
in
the
recommendations.
G
I
Thanks
warren
thanks,
while
I'm
asking
my
question,
can
we
go
back
to
slide
five?
I
So
dave
might
have
already
said
this
in
the
chat,
but
I
think
something
that
be
really
important
is
to
first
understand
what
bits
we
can't
currently
do
I
mean
a
lot
of
this
feels
like
dscp
or
quality
of
service
is
stuff
that
we
invented
a
long
time
back
and
was
never
deployed,
seems
like
doing
the
same
thing
again
might
not
end
well,
or
maybe
this
just
ends
up
being.
You
should
use
provisioning
domains
and
quality
of
service
done.
I
I
The
concern
is:
if
the
user
only
has
one
option
which
is
yes
and
yes,
making
them
aware,
doesn't
really
help
right.
If
the
user
ends
up
in
a
situation
where
they
don't
actually
have
a
choice,
they're
just
aware
that
whatever
they're
doing
is
subject
to
this,
it
doesn't
help
them
at
all,
and
I
think
that's
my
soapbox
run.
That's
good!
That's
a
very
good
point.
J
Hi
yeah,
thank
you.
So
I
think
the
first
thing
I'd
like
to
see
is
is
real
discussions
on
the
mailing
list.
After
you,
you
posted
this
to
interior.
I
sent
a
range
of
thoughts
about
this,
haven't
seen
any
reply
from
you
or
other
authors,
and
neither
any
other.
You
know
I
think,
good
discussion.
J
So
hopefully
we
can
have
the
discussion
because
certainly
I
think
that
topic
is
very
important
and,
quite
frankly,
you
know
I'm
beside
the
pointers
that
I
was
providing
in
that
email
of
prior
work
that
I
did
in
that
respect
and
the
responses
I
I
got
back.
J
You
know
a
couple
years
back
in
in
area
which
would
be
interesting,
I
think,
to
re
reinvestigate
with
respect
to
the
you
know,
opinions
of
the
organization
a
lot
of
the
work
where
we've
seen
come
from
the
network
equipment
vendor
industry
is
not
necessarily
only
the
open
internet
right,
but
a
lot
of
these
things
are
a
lot
more
required
and
and
requested
for
by.
J
You
know
what,
since
879
we're
calling
limit
domain
networks
right
so
and
these
limited
domain
networks
can
go
as
far
as
a
home
network
connecting
to
a
service
provider
where
the
customer
in
the
home
network
has
an
explicit
contract.
There
is
all
type
of
you
know
necessarily
security
right,
we've
done
protocols
like
pcp
and
others
for
signaling
right.
K
K
Hello
tommy.
Can
you
hear
me?
Yes,
okay,
I
I
I
agree
very
much
in
the
in
the
proposal
about
that.
The
when
the
in
order
to
mitigate
the
privacy
issue
should
not
to
indicate
the
individual
applications
in
the
to
the
network.
K
I
think
that
this
also
has
another
issue,
because
you
we
know
that
the
individual
applications
develop
very
fast.
You
will
depend
on
the
depend
on
the
individual
application.
So
that's
the
network
has
to
adapt
it
to
this
individual
application.
This
is
also
very
difficult
and
also
in
the
practice.
K
We
also
think
that
the
the
individual
application
is
very
hard
for
the
network
to
process
yeah.
So
that's
the
first
point.
The
second
point-
I'm
maybe
this
mentioned
also
mentioned
by
the
tories.
You
know
that
when
do
the
apm
work,
we
also
investigate
the
scenario,
because
you
know
there's
some
this
limited
domain.
K
You
know
that
for
somebody's
enterprise
network
or
their
carrier,
ip
network,
so
the
under
under
to
under
control
by
the
enterprise
or
the
operators,
so
that
they
hope
to
come,
identify
their
applications
and
that's
you
to
find
granularity
so
that
they
can
easily
track
to
their
service.
So
that's
in
my
point.
K
This
is
a
a
little
different
from
this,
the
internet
process,
so
I
want
to
because
here
we
wanted
to
set
up
this,
the
general
the
principles,
but
I
think
not
only
this
is
to
get
this
response
from
the
people
in
the
internet
and
also,
maybe
also
something
is
the
limited
domain.
The
requirement
should
also
be
taken
into
account
that
may.
E
Be
helpful,
yeah
yeah,
that's
a
good
point
and
just
to
respond
briefly
to
the
overall
limited
domain
usage.
I
do
think
that
does
fit
in
well
and
I
think
there
is
still
a
need
and
there's
a
gap
there
that
we
are
trying
to
highlight
by
talking
about
how
you
know
the
applications
interact
with
the
network,
how
they
select
it
oftentimes.
Today,
a
device
is
not
necessarily
aware
of
when
it's
on
a
limited
domain
or
open
internet,
what
it
should
trust
or
not,
and
kind
of
defining
those
guard
rails
around.
E
A
We'll
see
yes,
thank
you
very
much,
so
we
definitely
have
a
vivid
interest
and
then
then,
to
answer
the
question
we
are
going
to
take
it
on
offers
chairs
and
ad
to
see
the
right
venue
and
potentially
go
for
an
adoption
call.
But
thank
you
very
much
for
the
presentation.
A
So
I'm
going
to
put
up
pascal,
slides
or
or
pascal,
would
you
like
to
present
yourself.
L
Juan
carlos,
it's
easier
that
you
do,
but
if
you
want
me
to,
I
can.
L
L
It's
very
useful
to
compress
protocols
and
thinking
of
protocols
like
goose,
for
instance,
in
electric
grid,
which
is
really
time
sensitive,
but
at
the
same
time
wasting
a
lot
of
bandwidth.
So
it
could
be
cool
to
use
something
like
shake
to
compress
that.
So
the
idea
here
is
to
define
shake
over
ppp,
because
if
you
define
something
about
ppp,
then
because
you
have
pppoe,
you
can
use
it
also
over
ethernet
and
wi-fi.
So,
at
the
end
of
the
day,
chicopa
ppp
is
the
way
to
have
shake
pretty
much
everywhere.
L
Also,
it's
kind
of
classical
for
ppp
to
have
compression
mechanisms.
Crfc
5172
star,
already
two
compression
mechanisms,
sleep,
one
capture
capacitance.
So
now
we
we
are
just
defining
yet
another
one.
So
it's
not
like
something
completely
revolutionary,
but
it
could
be
dramatically
useful
next
slide.
Please.
L
Okay,
so
this
is
basically
a
packet
format
of
the
compression.
So
for
those
who
have
looked
at
ppp
and
pppoe,
this
is
exactly
the
shape
of
a
pppoe
frame
and
starting
after
the
or
57
which
signals
ipv6.
You
can
see
the
chic
rule,
so
that's
really
the
matching
table
in
the
state
for
compression
and
then
the
compression
residue.
That
is
everything
that
could
have
to
be
placed
online,
and
if
you
don't
use
fragmentation,
this
draft
adds
the
capability
to
to
add
some
original
payload.
L
That
would
not
be
comprised,
for
instance,
in
my
example
of
goose
you
could
say:
hey
all
those
long
names
can
be
compressed
and
then
the
goose
data
itself
can
be
left
in
line
next
slide.
L
The
slide
one
gasket
okay,
so
status
of
the
draft
very
stable
in
change
since
last
etf.
We
discussed
it
several
times
at
lp1
because
there's
a
lot
to
do
with
with
lp1,
but
at
the
end
of
the
day,
the
mp1
chairs
and
and
our
ad
eric,
we
all
decided
it's
mostly
ppp,
mostly
not
checks.
So
that's
why
it's
it's
presented
here
at
interior
next
slide.
Please.
L
Okay,
so
here
is
the
generic
flow
that
you
will
see
for
for
this
draft,
but
also
for
ppp
oe
in
general.
So
so
what
happens
and
which
is
kind
of
new
to
the
lp1
architecture,
is
instead
of
having
a
sensor
device,
which
is
this
low
power
battery
operated
device
and
the
gateway,
which
is
this
service
provider,
side,
translator,
the
compressor,
etc.
L
So
this
changes
the
model,
because
now
you
don't
have
a
low
power
side
and
like
a
client
on
a
server,
it's
really
peer
appear.
So
the
cool
thing
with
that
is,
they
can
actually
go
and
fetch
the
exact
same
rule
set
at
the
exact
same
place.
This
is
why,
after
we
do
the
discovery
in
the
lcp
configuration
which
is
like
the
classical
pvp
you
have
in
this
ipc,
ipv6
cp
configuration
request
with
option
two
we
have
this
request
of,
which
is
the
new
value.
L
L
So
both
sides
go
and
get
the
rules
and
and
get
it,
and
now
we
can
effectively
do
the
compression.
So
that's
the
flow,
very
simple:
it
really
depends
next
slide.
Please,
and
it
really
depends
on
the
chic
yang
model,
which
is
being
defined
right
now.
The
lp1
protocol,
so
where
are
we
drafty
stable,
has
been
discussed
several
times
at
lp1.
If
there
are
lp1
consideration,
I'm
pretty
sure
we
will
do
a
round
after
the
last
call
in
interior.
L
We'll
do
a
round
that
help
you
want
to
just
validate
that
everything
is
correct
on
the
lp1
side,
but
pretty
much
stable,
not
very
complicated.
It's
just
yet
another
compression
protocol
for
pvp,
which
already
had
two
so
the
classical
questions
I
mean.
Is
there
anybody
who
wants
from
the
interior
side
to
help
me
on
the
ppp
side
just
to
make
sure
everything
is
ppp
correct?
L
Do
we
need
more
text,
or
is
it
already
quite
complete,
like
do
people
want
an
applicability
statement
like
explain
why
we
need
it?
Usually
we
don't
do
too
much
of
that
in
a
star
track
document,
but
if
people
think
it's
necessary,
we
can
write
it
and
is
there
anything
beyond
what
is
in
this
draft,
which
could
be
added
again
open
to
suggestion
and
also
open
to
the
chairs
proposing
adoption,
because
now
the
draft
is
stable,.
A
Okay,
let
me
try
again,
I
was
saying
if
we
could
take
one
question
to
make
it
fast
and
otherwise
I
would
encourage
people
to
ask
ask
to
answer
sorry.
Pascal's
questions
on
the
list.
A
A
Okay,
so
we
have
about
six
people
that
have
read
it.
So
please
take
a
look.
I
think
that
the
the
intention
would
be
to
adopt
this
this
draft
and
for
that
we
need
to
have
more
eyes
and
more
feedback.
So,
as
pascal
said,
it's
quite
stable
and
it's
quite
simple,
but
we
do
need
a
couple
of
more
eyes
to
make
sure
that
we're
going
on
the
right
path.
A
So
now
shipping
you
have
less
time,
unfortunately,
than
previously
planned.
D
D
B
So,
first
about
the
purpose
of
this
presentation
in
here,
and
we
were
actually
suggested
by
the
iesd
and
to
present
in
the
intel
area-
and
we
have
this-
we
have
seen
discussions
on
apn
in
this
working
group
and
as
tommy
just
presented,
and
we
also
have
the
meeting
the
apm
meeting
list
and
we
have
very
active
discussions
there.
So
we
would
like
to
collect
more
feedback
where
the
discussions
here
and
to
further
address
the
concerns
raised
by
the
esd.
B
So,
first,
what
is
apn
apn
is
about
on
that
network
layer,
and
we
would
like
to
enable
the
implementation
of
the
fine-grained
user
group,
application
group
and
service
level
requirements
guarantee,
and
in
order
to
do
this,
we
will
focus
on
developing
a
framework
and
a
set
of
mechanisms
to
derive,
convey
and
use.
And
this
are
we
called
aping
attribute,
and
this
information
will
be
encapsulated
in
the
data
package
and
it
will
be
treated
as
an
object
in
the
network
and
to
this
object.
B
So
what
is
very
important
is
apn
works
within
a
limited
operator's
domain
and
generally
this
domain
is
defined
as
service
providers
limited
domain
within
this
domain,
and
the
operator
could
apply
their
technologies
and
to
provide
services,
and
we
can
see
from
this
simple
diagram
diagram
and
the
apn
algebra
attribute
is
tagged
and
removed
at
the
at
the
edge
of
the
limited
domain.
That
means,
once
this
package
leaves
this
domain
and
the
attribute
will
be
removed
and
it
won't
impact
the
rest
of
the
internet.
B
B
B
Actually,
the
network
doesn't
need
to
know
what
who
you
are
and
what
you
are
doing,
which
application
is
actually
sending
the
traffic
and
to
have
this
information,
it
will
break
the
privacy,
and
we
are
aware
of
that.
So
it's
all
about
the
policy
enforcement
in
the
network.
The
network
doesn't
need
to
know
those
information
and
it
only
needs
the
like
opaque
value
or
a
bit
string
to
do
the
policy
enforcement
on
the
various
places
I
mean
the
to
be
specific,
is
on
the
network
nodes
or
service
functions.
B
B
We
use
the
network
layer
and
apn
is
not
network
tokens
which
tags
the
tokens
from
the
host
by
the
apn
text
attribute
at
the
network
edge
device
and
at
the
end
it
is
also
the
conclusion
we
derived
from
the
said
meeting
at
ietf
108,
that
is
to
convey
the
information
at
different
layers
are
different
technologies
and
apn
uses
the
network
layer
next
slides.
Please.
A
B
So
now
why
apn
here
we
use
a
very
concrete
use
case
and
it
says
demand
and
in
the
case
of
id
sd1,
the
network
operators
can
provide
the
sra
guaranteed
one
lines
to
enable
the
enterprise
to
access
to
the
cloud.
But
when
we
map
the
one
line
into
the
network
operators
network-
and
then
usually,
you
will
find
multiple
network
paths
with
different
sr
guarantees.
B
So
in
the
mef70
we
there
are
already
a
list
of
match
items.
They
are
published
to
add
the
network
arch
nodes
and
which
could
be
used
to
steer
the
traffic
into
the
lines
and,
but
still
there
is
a
need
to
communicate
user
applications
requirements
to
the
network
to
match
to
the
capabilities
the
capabilities
of
the
one
line.
So
that
is
once
the
traffic
goes
into
the
operator's
network.
There
is
a
need
to
apply
the
various
policies
in
the
different
nodes
or
service
functions
along
the
path.
B
B
So
that
is
impossible
to
do
it
with
the
current
existing
mechanisms.
Probably
we
could
stack
the
various
policies
in
a
list
of
trv
in
the
head
of
each
packet,
but
you
can
imagine
the
big
challenges
going
to
be
imposed
on
the
hardware
precisely
and
also
when
people
do
the
policy-based
routing
along
the
network
path.
B
Normally,
the
acrval
v
tuples
is
used,
but
sometimes
it's
very
complicated
to
resolve,
for
example,
with
the
tunnel
encapsulation,
it's
very
hard
to
have
these
five
tuples,
because
the
transport
layer
is
pushed
very
down
and
with
the
ipsec
it's
impossible
to
to
obtain
the
transport
layer
and
also
with
ipv6
data
plane
with
those
in
extension,
headers
and
to
be
added
and
the
the
transport
layer
is
pushed
very
further
down.
It's
impossible
to
gather
next
slice
piece.
B
B
So
how
and
here
we
recommend
to
acquire
or
construct
this
attribute
as
the
network
edge
and
encapsulate
it
in
the
packet
and
to
treat
it
as
an
object
and
then
provide
services
to
it,
and
so
that
will
bring
a
lot
of
bad
benefits.
For
example,
now
you
only
need
to
check
one
field
in
the
ip
layer
instead
of
resolve
the
five
tuples
in
different
places
in
the
packet
header,
and
also
it
will
enable
very
flexible
policy
enforcement
and
further
so
for
the
sfc.
B
B
And
here
we
have
did
some,
we
have
done
some
gap,
analysis
and
quickly.
Go
through.
Dhcp
is
not
big
enough
and
flow
label
and
entropy
is
for
the
ecmp
and
service
id
is
only
carried
in
the
message,
but
the
apn,
the
attribute
is
decoupled
from
data
plane.
Iom
flow
id
has
a
the
dedicated
purpose
and
the
bending
state
is
bound
to
the
sr
and
flow
spec
label
is
bond
to
the
amperes,
but
apn
is
decoupled
from
the
data
plane.
B
Next,
please
here
are
some
questions.
We
would
like
to
discuss
with
you
further
about
the
security
issues
and
whether,
when
we
do
it
in
the
limited
network
domain,
whether
they
are
still
a
security
issues
and
about
privacy,
I
think
we
find
some
ways
to
mitigate
them
and
we
use
opaque
value.
And
so
what
is
most
important
is
the
network.
When
we
do
the
policy
enforcement,
we
don't
need
to
know
what
the
traffic
so
who
the
user
is,
and
what
application
is.
A
J
Actually,
my
comment
was
just:
this
is
the
second
virtual
itf
in
a
row
where
you
only
allocate
an
hour
for
in
the
area.
Could
we
please
could
we
get
a
little
bit
more
overall
for
these
discussions?
That
would
be
very
helpful.
Thank
you
very
much.
H
Yeah,
hey
hello,
hello,
everyone
for
the
time.
Today's
topic
is
about
the
challenges,
scenarios
and
progress
in
the
internet.
Addressing
next.
H
Please
next
please
thanks.
This
topic
is
about
internet
addressing
so
sorry
another
internet,
addressing
it's
all
about
the
ip
address.
So
we
know
every
id
address
is
a
carrier
for
the
for
water
to
know
how
to
routing
a
packet
and
on
the
other
hand
we
know,
there's
a
lot
of
limited
domain
networks
and
they
are
behind
the
internet.
For
this
limited
domain
networks,
the
requirements
no
behaviors,
especially
for
how
nodes
for
water
packet
and
semantics
are
totally
different
from
the
internet
address.
H
H
So
in
this
job
we
want
to
focus
on
the
questions
in
the
middle.
That
is,
should
limited
domains
purely
rely
on
ip
address
and
therefore
deal
with
the
complexity
of
translating
animatics
mismatch
themselves.
Or
should
flexibility
for
supporting
those
limited
domains
be
a
key
focus
for
involved
internet
addressing
and
generally,
this
is
asked
for
a
discussion
on
the
emerging
needs
for
involving
internet
addressing
and
the
current
objectives
and
paradise,
especially
for
the
addressing
for
ipv6,
and
we
are
not
going
to
propose
or
promote
a
solution
for
this
province.
Next.
H
Please
what
we
have
done
in
this
draft
is
that
we
first
provide
some
of
the
scenarios
in
this
scenarios
we
found
before
using
ipv
internet
protocol
in
scenarios.
We
found
some
challenges
and
problems
in
order
to
still
make
the
internet
protocol
cover
this
scenario
limited
domain
networks.
H
We
have
to
develop
some
like
some
protocols
like
6lowpan,
and
there
are
news
adaptation
technologies
must
be
developed
to
include
the
internet
protocol
to
cover
this
limited
domain
and
because
these
solutions
are
within
the
paradigm
of
the
internet,
addressing
especially
for
ipv6,
we
figured
that
there
are
issues
and
the
problems
we
are
facing
if
we're
still
using
solutions
within
the
current
paradigms
internet
addressing
so
we
have
we,
we
summarize
a
lot
of
issues
in
for
using
these
solutions,
and
this
is
what
we've
done
in
the
first
drop.
H
We
plan
to
do
in
the
pre
in
the
update
version
or
in
the
separate
document,
is
that
we
want
to
find
if
we
want
to
still
involve
the
internet
tracing.
What's
the
challenges
we
have
and
what
the
gap
we
have.
If
we
want
to
do
that,
so
this
leads
to
the
two
directions.
H
The
first
direction
is
that
we
confirm
there
are
a
lot
of
problems
or
issues
if
we
insist
as
a
if
we
insist
the
current
addressing
paradise,
and
so
the
issues
will
stay
stay
here
and
we
are
still
facing
this
issue.
If
we
insist
the
current
internet
addressing
this
is
the
first
direction.
The
second
direction
is
that
we
think
this
problems
need
to
be
solved
and
we
need
to
have
more
discussion
about
how
we
involved
the
internet
addressing
so
this
is
a
draft
call
for
a
order
discussion
for
this
direction.
A
H
Okay,
I
think
the
next
slice
is
for
the
end
of
the
topic.
So
the
question
for
here
is
that
we
want
to
talk
about
if
there's
a
really
a
need
for
emerging
emerging
needs,
for
if
we
want
to
involve
the
internet
addressing
that
is
beyond
especially
beyond
the
ipv6
internet
addressing
and
we
are
open
to
people
who
would
like
to
contribute
to
push
this
work
forward
and
I'd
like
to
end
it
up
here
and
open
four
questions.
Thanks.
A
Thank
you
very
much,
so
we
can
take
one
question.
Otherwise
we
encourage
people
to
to
get
on
the
list.
A
A
All
right,
so,
let's
take
the
discussion
then
to
the
list
thanks
everyone
for
your
participation
and
we
look
forward
to
seeing
you
online
soon
in
the
future,
so
take
care,
be
safe,
ciao.