►
From YouTube: IETF96-RADEXT-20160721-1830
Description
RADEXT meeting session at IETF96
2016/07/21 1830
B
To
move
on
just
about
to
get
sucks,
okay
good
evening,
thank
you
for
coming
in
such
masses,
hello.
B
B
So
we
should
get
started
first
with
you
know,
dwell.
Please
note
well
denote
well,
and
then
let's
see
it
together
at
the
agenda
for
the
addenda
bashing,
we
spend
five
minutes
on
the
prisoners.
As
usual,
there
is
a
document
status
update
where
we
see
how
far
our
documents
have
come.
We
have
two
active
working
group
drafts,
in
which
I
get
five
minutes,
each
for
very
small
small
recap
on
the
current
status.
B
Then
we
have
actually
for
individual
drafts
to
discuss
actually
three
drafts
and
a
draft
to
be
so
act.
They
have
plenty
of
new
work
which
could
be
in
coming
into
this
working
group
and
then,
after
the
wrap
up,
we
still
have
five
minutes
of
leeway.
So
while
we
might
actually
spend
a
bit
more
time
on
one
topic,
let's
see
how
it
goes
so,
first
of
all
for
the
blimp
preliminaries,
we
need
a
minute
taker
and
age
scribe.
Surprisingly,
I
didn't
get
any
upfront
notices
that
somebody
is
volunteering.
So
now
is
the
time.
C
B
Is
here
so
he's
usually
electronic
Java
guest?
Okay?
So
then,
let's
start
with,
we
have
not
published
now
see
in
the
meantime,
but
we
do
have
one
document
in
the
IRC
editor
q,
that
is
the
larger
packets
over
radios
for
ages
over
TCP
from
Sam
hot
men.
This
is
actually
in
all
48,
so
this
should
be
out
the
door
any
time
now
and
I'm,
hoping
that
this
is
kind
of
next
week
or
so
so
we
have
an
almost
our
see
at
this
point.
B
B
This
is
publication
requested
and
is
g
is
doing
its
magic
on
it,
and
then
we
have
data
types
in
the
radios,
our
work
of
another,
and
there
is
one
ad
review
from
cathy
moriarty
with
two,
dare
I
say,
fairly
minor
comments,
so
I
think
we
can
push
this
forward.
Yeah.
D
E
So
this
is
alan.
I
actually
put
in
a
couple
of
comments
and
pushed
out
a
new
doc
earlier
today.
So
I
think
that
should
be
all
right.
I
should
sorry
I
yes,
these
mics
have
that
issue.
I
put
in
the
minor
comments
earlier
today
and
issued
a
document
so
I
believe.
E
B
B
Now
in
terms
of
active
working
with
documents
which
are
still
in
the
working
group
stage,
I
think
I've
completed
all
my
shepherd
write-ups
and
just
as
well
as
leonel,
so
well,
there's
nothing
in
that
queue.
We
have
a
document
which
has
completed,
welcome
to
blast
call
at
least
once
and
that's
the
CUA
proxy.
B
There
is
another
working
last
call
ending
next
week
on.
This
is
basically
only
to
give
Peter
Deacon
a
chance
to
revise
his
comments,
which
he
had
a
long
time
ago.
So
with
this
newest
Rev.
If
there
is
no
incoming
comment,
basically
we
should
be
done
with
that,
and
we
should
be
proceeding
to
the
right
up
at
this
point.
So
everybody
who
wants
to
comment
on
this
document
to
do
it
really
soon
now.
B
Another
document
we
have
in
the
hue
is
my
only
considerations
regarding
the
correct
use
of
ypres
sponsored
entity,
discuss
the
new
version
just
before
the
cutoff
and
have
a
small
slide
deck
really
with
just
one
issue.
On
my
side
that
should
be
remaining
and
I
hope
we
can
put
this
forward
at
some
point
soon
now
for
the
new
work
which
would
be
coming
in.
This
is
actually
quite
a
lot
on
our
plate
and
we
have
to
decide
at
some
point
which
of
those
we
want
to
adopt
this
working
group
drafts.
B
B
So
jim
has
kindly
volunteered
to
edit
that
document
to
be
the
editor,
and
so
let's
discuss
it
today
and
at
some
point
see
draft
about
it.
Then
there
is
laura1
authentication
in
radius
lower
one
is
this
low-power
radio
wide
area
network
and
they
have
their
very
unique
authentication
needs,
and
there
is
graphed
a
one
also
submitted
just
before
the
cutoff,
which
describes
how
to
authenticate
with
lower
one
and
at
some
point
from
looking
at
the
document.
B
B
B
B
Then
there
is
a
as
a
last
document
the
extended
packet
header
for
radius,
which
is
fairly
new,
so
this
is
no
submitted
also
just
before
the
deadline
and
yeah.
So
let's
see
what
this
is
about.
E
Based
on
discussions
with
Jim
and
Bernard
and
Stefan
this
week,
I
suspect
there
may
be
another
document
which
would
be
useful,
which
would
be
radius
proxy
considerations,
which
is
really
a
bit
different
than
the
TCP
or
TLS
document.
And
it's
what
do
you
do
when
you
cross
protocol
boundaries?
Or
you
know?
What
do
you
do
when
you're,
when
you
have
layers
of
proxy
chains
to
just
again
expanding
things
which
are
not
documented
now
are
poorly
implemented,
are
unknown
yeah.
B
E
Just
go
through
the
slides:
there
really
isn't
much
changed
from
the
last
IETF
proxy
spoofing
can
always
be
done.
You
know
the
proxies
can
do
anything
they
want.
Peter
Deacon
had
some
comments,
I'm
not
entirely
sure
what
he
meant
by
them,
and
I
did
not
get
clarification.
So,
barring
clarification,
we
can
go
with
the
document,
as
is
go
ahead,
so
there
were
updated
text.
So
the
main
issue
is
that
the
coa
server,
which
is
really
the
Nazz,
must
treat
all
attributes
as
mandatory.
E
If
it
doesn't
understand
it,
it
sends
a
co,
a
knack
with
an
error
cause
of
unsupported
attributes.
The
issue
is
their
attributes
added
by
proxies
on
the
outbound
path,
which
really
should
also
be
sent
on
the
inbound
path,
but
you
want
to
delete
those
attributes
before
they
get
to
the
NAS,
because
their
proxy
signaling
attributes
not
nazz
attributes,
and
so
the
discussion
here
is
trying
to
come
up
with
text
which
says
bar
by
and
large
anything
proxies,
add
outbound.
They
delete
going
back.
E
So
when
the
packet
gets
to
the
nez,
it
knows
nothing
about
any
kind
of
proxy
stuff.
What
I've
seen
in
in
practice
is
the
proxy
state
attribute
going
from
a
co,
a
client
to
the
nas,
and
then
the
nazgûl
I,
don't
understand
proxy
state
and
sending
a
co
a
knack
back,
which
is
dumb,
but
you
could
argue
it
sort
of
makes
sense
from
reading
50
176.
So
this
is
meant
to
be
future
proof
too
simple,
hopefully,
hopefully
understandable.
E
So
all
attributes
added
by
a
radius
proxy
when
sending
packets
from
the
visited
network
to
the
whole
network,
must
be
removed
by
the
corresponding
CEO.
A
package
from
proud
proxy
from
packets
would
travel
the
reverse
path
so
then,
as
only
ever
sees
attributes
that
its
end
up
stream
or
that
the
upstream
is
intending
to
send
to
it
to
do
see.
Oh.
B
E
The
the
document
of
some
other
text
about
you
know
we
sort
of
assume
that
there's
mostly
a
one-to-one
mapping
between
the
upstream
and
the
reverse
path,
and
that
the
upstream
proxy
can
talk
to
the
CEO,
a
proxy
which
sends
things
backwards
right
if
the
pads
are
completely
different
than
who
knows
what
the
hell
goes
on
right,
it's
almost
impossible
to
know
some
of
Peter
deacons
comments
were
that
the
CEO,
a
proxy
did
not
talk
to
the
radius
proxy
and
was
incapable
of
talking
to
the
radius
proxy
I.
Think
the
answer
to
that
was
well.
F
E
E
G
E
B
B
B
If
you
do
look
at
the
burners
like
a
slight
lag,
there
are
six
issues
which
came
up
on
the
rainiest
and
which
we
talked
about
extensively
I've,
basically
fixed
all
of
those.
In
addition
to
that
I
promised
in
the
winners
iOS
meeting
I
would
do
some
SC
art
to
describe
the
use
case
behind
this
a
bit
better.
Actually,
I
didn't
do
that
yet
so
there
will
be
another
ref
with
just
the
SQ
out,
basically
because
I
hate
it
and
I
have
to
find
the
will
power
to
actually
do
them.
B
B
The
texts
has
done
some
acknowledgment
of
the
identity
selection
hints
in
the
e.r
SC,
on
which
some
thought
could
our
fix
the
problem
in
a
more
easy
way.
The
more
I
look
at
this
I
believe
the
identity
selection.
Well,
it's
actually
rather
implemented
pretty
much
anywhere
and
if
it
were,
it
only
has
256
bytes
to
transmit
identity
information,
which
is
way
too
few
to
be
useful.
But
even
if
it
were
sufficient,
it
still
doesn't
solve
the
problem.
B
So
I
think
the
text
about
identity
selection
hints
can
basically
just
go
away
because
it
doesn't
contribute
to
the
problem
solving
or
explicitly
say
it
doesn't
help
now.
The
reason
why
I
think
that
is
on
this
next
slide-
and
this
is
here
this
wonderful
s
yard.
So
when
the
use
case
basically
came
in
prominently
with
the
new
Wi-Fi
line
specification
on
past
point
or
also
hotspot
to
point,
though,
depending
on
how
you
want
to
call
it,
both
names
exist.
B
So,
let's
assume
the
user
has
a
device
with
a
sim
card
in
it,
and
the
operator
has
pre-configured
the
device
so
that
authenticates
with
the
sim
card
to
cellular
networks
just
like
as
usual,
but
also
that
it
is
allowed
to
use
all
Wi-Fi
access
points
which
have
passed
point
enabled
and
indicate
in
their
beacons
support
for
this
specific
MNC.
Mcc
combination,
that's
just
a
config
item
in
itself
and
there's
nothing
wrong
with
that.
B
B
So
should
I
send
the
EAP
requests
to
the
observer
at
the
cellular
network
to
an
ebay
k,
prime,
or
should
I
send
it
to
the
radio
server
theorem
consortium
doing
EP
GLS,
nothing
wrong
with
that
so
on
the
trouble
starts
when
the
authenticator
next
slide
actually
is
an
access
point
which
has
both
criteria
enabled.
So
let's
say
this
is
a
Wi-Fi
access
point
with
an
SSID
that
is
fubar,
so
it's
not
relevant
here
that
it
indicates.
B
You
are
allowed
to
connect
to
me
if
you
have
a
sim
card
with
this
specific
mcmc
combination
and
you're
also
allowed
to
connect
to
me,
and
that
will
authenticate
you
if
you
have
a
credential
with
this
past
point
consortium
end
in
fire.
Now
the
device
looks
up
its
local
config
and
realizes
gosh.
Actually,
I
have
a
credential
and
I
can
use
it
because
I
have
this
cell
phone
provider.
B
My
list
and
I
also
have
a
TLS,
credential
and
I
can
use
it,
because
I
have
this
consult
some
identify
and
my
list
so
the
client
configuration
simply
knows
it
has
the
choice
to
use
both
at
some
point.
It
has
to
try
one
if
that
doesn't
work
at
twice
the
other.
The
important
thing
is
and
that's
what
the
document
is
all
about
when
you
try
both
always
use
the
realm
identifier,
which
matches
your
actual
user
identifier.
B
So
then
just
magically
assume
that
you
can
send
one
realm
identifier
and
it
will
try
both
methods
in
a
row.
It
just
can't
do
that,
because
the
routing,
depending
on
the
realm
identifier,
might
add
that
might
put
you
into
a
place
where
only
one
of
those
will
work
and
the
other
one
will
never
be
tried.
B
The
problem
with
the
identity
selection
hints
is,
if
you
are
put
into
the
authenticator
into
the
Wi-Fi
access
point,
the
identity
selection
hints,
it
simply
does
not
help,
because
the
Wi-Fi
access
point
would
send
in
the
EEP
request
identity,
but
you
can
use
this
or
that
and
the
choice
for
the
client
is
not
narrowed
down
because
well
they're,
both
usable,
so
they
can
both
be
indicated
in
this
message.
So
it
just
doesn't
contribute
to
the
problem
that
the
identity
selections
exist
in
principle.
B
So
since
they
don't
help,
I
would
prefer
to
reject
them
out
and
just
saying
okay,
that's
it,
and
that
is
actually
the
one
issue.
I
have
so
I
wonder
what
people
think
of
that.
I
would
like
to
push
out
a
new
ref
with
ascii
art,
and
then
I
hope
that
the
document
has
gotten
enough
meeting
that
we
can
actually
move
forward
to
a
working
group.
Last
call.
E
B
This
is
a
bigger
question
than
just
the
supplicant
side.
What
I
can
say
is
that
the
mention
of
Wi-Fi
access
point
manufacturers
do
implement
pass
point
these
days,
so
you
can
just
buy
new
cisco
gear
and
or
any
other
window,
and
it
will
have
a
config
option
to
do
that.
The
implementation
quality,
as
always
varies.
B
We
have
seen
that
all
the
major
all
vendors
on
the
client
side
also
indicate
support
for
past
point,
so
you
have
Microsoft
Windows
10.
There
is
also
X
iOS
and
even
Android
in
its
newest
version.
Has
the
API
is
to
configure
a
pass
point
and
react
upon
beacons
with
pass
point,
so
in
principle
the
infrastructure
is
there
actual
deployment?
I
don't
know
we
are
looking
at
this
and
at
your
own,
especially
on
the
client-side
implementations,
also
vary
in
quality
on
the
lower
end
of
the
scale.
B
My
ebay
k,
credential
first
and
I
will
always
use
the
realm
identifier
from
3gpp
Network,
the
Lord,
so
we
actually
had
customers
in
at
your
own
who
said
I've
configured
my
mobile
phone
with
the
right
credentials.
I
know
my
password
is
correct,
but
for
some
reason
it
never
actually
authenticates,
and
that
is
because
the
routing
of
the
request
always
consistently
failed.
Luckily,
that
manufacturer
has
moved
to
android.
Meanwhile,
so
their
own
implementation
is
gone.
B
C
And
this
is
you
know
in
another
way,
is
it
is
it?
Will
it
be
simpler
to
say
that
it
is
assumed
that
the
user
name,
the
identity
used
in
the
as
a
username
will
be
relevant
enough
to
figure
out
which
we
are
to
address,
and
how
how
to
do
that?
It's
not
so
relevant
for
this
document.
It's
something
that
Nick,
you
can
put
rising
simple
text
to
say
that
it
is
something
to
take
into
account,
but
we
have
the
same
issue
with
diameter
anyway,
yeah.
B
So
the
document
already
says
it's
up
to
local
configuration:
how
to
split
the
web
Ram
identifier,
which
is
the
equal
sponsored
entity
and
the
actual
user
identifier,
which
is
whatever
the
method
uses
as
an
identifier.
How
you
do
that
you
I
how
you
ask
the
user
I
can't
because
this
stuff
yeah.
C
H
Shim
shot
okay,
so
I
understand
how
to
deal
with
issued
to
you
and
I
understand
how
to
shoot.
Number
three
in
your
next
steps.
Having
a
bit
of
problem
with
one
you've
described
a
problem
and
I
will
admit:
I'm
tired,
so
I
may
have
dozed
off
and
missed
exactly
what
the
options
are
for
the
solution
so
that
we
can
converge
on
the
solution
at
this
point,
I'm
kind
of
at
this
every
time
I
hear
this
is
like
we
have
a
problem,
it'd
be
nice
and
client.
H
B
It's
not
actually
something
that
needs
fixing
in
you
I
the
UI's
I
know
actually
allow
you
with
your
method
to
select
which
I'll
true
identity.
You
use.
What
we
call
realm
identify
I
mean
what
so
the
UI
why's
everything
is
fine.
The
problem
is
much
more
with
the
state
machine
and
if
you
have
locally
configured
more
than
one
realm
identifier,
well,
you
have
to
restart
the
new
state
machine
after
you
failed
with
one
credential
and
you
just
don't
run
one
state
machine
for
both
eep
types.
That's
not
enough!
B
You
have
one
if
state
machine
for
one
eep
type,
if
it
doesn't
work,
and
you
want
to
try
the
other
one
start
fresh
start
fresh
with
the
new
realm
identifier
that
matches
the
other
reap
type
and
then
use
that.
So
it's
pretty
much
yeah
back-end
code
in
the
supplicants,
it's
nothing
to
with
you
I
or
changing
configs.
The
only
conflict
ends
you
might
want
to
have
is
for
privacy
considerations.
I
Brian
wise
Cisco
I'm
a
little
confused
on
the
privacy
situation.
So
first
comment
is
that
graph
says
you
know:
identifiers
will
be
revealed
and
then
it
says
when
privacy
is
aching,
important
and
actually
we're
in
an
age
where
one
way
developing
protocols,
privacy
is
always
important.
So
that's
not
a
very
good
statement.
I
Actually,
we
should
be
designing
otherwise,
but
now
the
question
is
in
this
example,
for
example,
that
you're
showing
will
the
client
device
try
to
use
both
of
his
credentials
all
the
time
or
just
when
he
sees
certain
pass
points
or
other
indicators
from
the
network.
You'll
only
use
ones
that
match
which
one
is
it
yeah.
B
B
I
That's
not
so
bad,
I
mean
least
he's
only
responding
when
he's
getting
some
kind
of
indication.
Of
course,
the
network
good
or
an
attacker
could
lie
about
that,
but
it's
a
little
better
than,
for
example,
when
we
cycle
through
all
the
SSID
our
device,
but
I
would
just
suggest
maybe
making
the
privacy
statement.
Obviously
staying
a
little
bit
stronger
in
that
section
and
explaining
maybe
you
know
where
there's
better
protection
or
not.
I
B
I'm,
all
for
making
the
privacy
statements
or
rigid
no
problem
so
basically
for
many
eep
types
which
are
in
use
today,
like
ttls,
peep
and
so
on.
These
private
sex
engines
do
work.
We
have
some
bleep
labs
where
they
don't
so
a
PWD
on
the
Dragonfly
thing
from
from
that,
hearkens
basically
has
no
possibility
to
hide
the
reuse
identifier.
So
that's
why
the
draft
said
rats
s.
So
if
you
have
these
e
types,
try
those
lasts
because
you
know.
J
B
H
H
So
then
I,
of
course,
reread
the
documents
with
an
eye
towards
actually
editing
them
and
said:
oh
well,
there's
a
couple
of
issues
that
I'm
not
exactly
too
sure
how
to
progress
and
there's
a
couple
of
issues
where
I'm
not
too
sure
which
documents
to
progress
so
I'll
cover
these
things.
We
can
give
some
guidance.
We
can
figure
out
which
documents
we
actually
want
to
to
rev
whether
we
want
to
combine
some
documents
together
while
we're
doing
the
revving
and
see
what
happens
so.
H
There's
a
couple
of
nice,
simple
top-level
topics
that
I
need
to
be
covered.
How
do
you
trust
things?
What
does
your
tickets
look
like?
How
do
we
want
to
actually
say
you
should
use
tickets,
whether
you
must
use
ticket
support
tickets,
there's
some
real
advantages
in
doing
so.
There's
some
interesting
questions
about
transport
layers
and
how
things
work
or
don't
work
in
terms
of
who
does
things
what
things
do
which
transport
layers
we
want
to
run
over
and
then
there's
some
some
really
fast.
H
Tls
option
questions
that
we
may
want
to
think
about
documenting
as
we
go
forward
next,
so
trust
months,
basically
there's
to
trust
modes
that
are
essentially
laid
out
in
the
current
document.
The
first
is
to
say:
oh
yeah,
well
using
CA
infrastructure,
they're
relatively
cheap,
but
they're
kind
of
hard
depending
upon
what
sort
of
system
you're
setting
up
to
get
everybody
to
buy
in
the
same
infrastructure
is,
of
course,
the
pre-shared
key,
which
is
basically
how
radius
is
instead
of
today.
You
could
continue
to
do
that.
H
But,
of
course,
that's
you
know,
manual
configuration
and
gets
to.
You
know
a
real
mess
in
terms
of
trying
to
configure
it
going
forward
this
upon
Billy
of
using
Dane,
and
maybe
doing
some
some
lookups
in
terms
of
trying
to
establish
is
just
the
right
cert
to
be
used,
but
that
still
doesn't
actually
solve
the
problem
of
do
I
trust
the
entity
that
is
the
subject
of
the
syrup.
So
it's
like
yeah.
This
is
a
certificate
that's
associated
with
you
know.
Food
on
example
for
the
domain,
but
I
still
need
to
make
a
decision.
H
I
actually
briefly
thought
about
the
whole
question
of
should
we
include
the
DNS
lookup
stuff
in
terms
of
was
in
75,
85
and
personally
I'd,
actually
just
rather
bury
that
in
the
sand
and
let
someone
else
deal
with
it
then
put
it
into
this
document,
so
I
mean
if
it
obviously
we
need
to
document
the
first
two
in
terms
of
how
to
do
things.
H
I,
don't
know
how
much
we
want
a
document
dane
or
not
document
Dane
in
terms
of
establishing
trust
in
certificates,
since
it
doesn't
actually
really
solve
the
problem,
it
may
merely
kind
of
says.
Yes,
you
have
a
certificate,
that's
real,
but
it
doesn't
say
anything
about
whether
you
should
trust
the
entity
at
the
other
end.
H
Okay,
next,
a
certificate
profile,
we
should
probably
actually
talk
about
with
certificates.
What
should
be
in
a
certificate
that
is
used
for
radius,
and
a
lot
of
that
is
pretty
simple?
We
don't
currently
have
one
arm
policy.
Os
is
certainly
one
way
of
establishing
whether
or
not
you
think
they
that
a
particular
trick
of
it
is
useful.
Another
thing
is
extended.
Key
usages,
often
the
times
used,
there's
a
few
other
things
we
need
to
talk
about,
which
is
things
like,
so
what
sort
of
naming
do
we
need
to
put
insert?
H
If
it's
do
we
put
in
DNS
naming?
Do
we
put
in
IP
naming?
Do
we
put
in
something
else
that
is
URL
based
or
in
realm,
based
in
AI,
something
or
other,
which
would
just
be
kind
of?
Please,
no
spare
me
arm
so
most
of
that
stuff.
I've
got
some
ideas
in
terms
of
how
to
go
forward
in
push
so
so
I'm,
not
immediately
too
worried
about
these
things.
Next
oops
sorry
I
should
have
talked
about
that
already
ticket.
H
Tls
1.3
is
making
tickets
and
a
whole
lot
more
useful
I
mean
they
exist
in
the
current
systems,
but
with
1.3
they
just
become
extremely
useful.
So,
basically,
what
you
can
do
is
you
can
go
through
the
full
validation
process
now
send
a
certificate
generate
diffie-hellman
keys.
Do
your
client
verified,
be
your
certificate,
verify
and
say?
Oh
and
now
that
I've
sent
you.
The
first
message
give
me
back
a
set
of
tickets.
What
that
means
is
the
second
time
you
hook
up.
H
You
say:
here's
the
ticket
from
when
you
validated
me
last
time
and
here's
the
pre-shared
key
that
we
used
on
this,
and
we
don't
have
to
do
anything
about
sending
certificates
around,
because
we
already
know
the
answers
to
all
those
questions,
so
basically
you're
really
reducing
Rica
next
time
or
setting
up
a
second
channel.
If
we
basically
say
yeah,
you
have
to
support
tickets
and
that's
potentially
a
huge
win
just
because
you
save
the
cost
on
certificate.
Validations
on
both
ends.
H
Next,
so
this
is
basically
a
real
fast
look
at
some
of
the
advantages
you
get
with
us
1.3.
In
terms
of
handshakes,
this
is
kind
of
a
really
scaled-back
version
of
what
things
look
like,
so
that,
if
you
do
pre
care
to
see
pre-shared
key
that
the
application
can
actually
send
encrypted
data
along
with
that
message.
H
So
this
says
that
not
only
when
I,
if
I
use
tickets-
and
you
reconnect
do
I
not
have
to
go
through
all
the
certificate
stuff,
I'm
actually
going
to
send
my
request
up
on
that
first
message:
whatever
that
first
set
of
a
great
whatever
that,
first
rate
hike,
it
is
so
I'm
really
reducing
the
number
of
messages
I'm
sending
between
the
server
and
the
client
and
radius.
By
doing
this,
this
pre
shared
secret
ticket
resumption,
because
I'm
sending
that
message
up
the
first
time,
I'm
still
actually
saving
things
in
terms
of.
H
If
you
look
at
the
difference
between
1.2
and
one
and
1.3
and
TLS,
because
in
1.3,
even
if
you
go
through
that
full
certificate
validation,
you
can
send
encrypted
data
up
on
your
second
message,
whereas
in
1.2
is
basically
it's
the
third
message
that
this
client
sends
out
that
they
can
finally
send
encrypted
data
so
in
any
event,
you're
saving
one
round
trip
and
you're,
potentially,
basically
not
having
any
round
trips
on
your
encrypted
data
with
with
with
the
ticket
resumption.
If
you
set
up
parallel,
dls
ports.
H
H
This
is
where
I
started
getting
into
the
funds
of
switch,
exactly
documents
that
my
air
being
revved
and
who
needs
to
read
them.
So
if
you
look
at
it
there,
the
the
TLS
over
TCP
actually
came
as
jus
documents
the
first
described,
but
to
do
with
TLS
the
second
described,
what
to
do
with
TCP
all
the
TVs
piece.
E
H
Trey
one
did
one
one
to
the
other
and
if
you
look
at
it
radius
/
/
DTLS.
That
was
another
document,
so
both
of
those
documents
are
experimental
documents
as
well,
so
at
a
minimum.
If
we
want
to
do
the
TCP
at
over
TLS
over
tcp,
we
probably
need
to
rev
the
the
TCP
document
is
unclear
at
this
point,
how
many
people
care
about
doing
DTLS,
but
as
possible?
We
want
to
read
that
document
as
well
to
get
it
upped
it
up
from
experimental
the
standards
track.
E
H
Well,
maybe
we
should
look
at
this
as
a
transport
layer
going
forward
because
it
has
some
interesting
characteristics
that
might
actually
be
useful
in
terms
of
avoiding
some
of
the
things
like
headline
blocking
on
not
TCP
the
other
thing
that
I
immediately
started
running
into
problems
as
I
read.
These
documents
was
trying
to
figure
out
exactly
what
was
supposed
to
happen.
As
you
went
between
boundaries
of
these
things
and
who
was
doing
recentiy
was
not
doing
reasons.
Why
were
people
who
are
doing
reasons
so
the
the
TCP
document
says
hey?
H
H
H
The
other
thing
the
other
world
would
be
even
as
spurs
on
UDP,
and
it
goes
to
a
proxy
which
converts
between
UDP
and
TCP.
The
man's
is
going
to
start
potentially
hammering
that
that
reliable
TCP
channel
with
retransmits,
because
things
are
timing,
that
somewhere
down
the
line,
maybe
because
nobody
wants
to
talk
to
him
but
there's
additional
traffic
on
the
TCP
channel.
H
F
H
This
isn't
all
that
interesting,
there's
a
whole
slew
possible
set
of
things
that
be
done
next
also
question
is
which
documents
need
to
be
done
and
revved
and
am
I
going
to
wrap
all
of
them
or
some
other
people
going
to
wrote
them
at
a
minimum.
I
think
we
need
to
biz
that's
easy,
p
document
or
else
wrap
that
into
the
TLS
document.
B
G
Hyuna
maroon
I'm
one
of
the
author
of
this
draft,
and
this
is
0-1
version
of
the
draft
and
we
got
some
comments
for
the
00
version.
So
the
main
motivation
of
the
draft
is
to
include
the
existing
to
play
infrastructure
into
the
laura1
infrastructure
for
authentication.
So
next
slide.
So
this
is
about
the
laura1,
a
long-range,
wide
area
networks
and
we
have
some
impressive
numbers.
It's
taken
from
the
LP
1
buff.
G
Here
we
have
the
N
do
in
device,
and
this
is
the
mass
our
network
server
in
this
case
and
the
N
device
communicates
to
the
network
server
through
the
radio
gateway,
and
this
is
actually
the
picture
from
the
buff,
but
actually
available.
Laura1
specification
doesn't
have
the
joint
server,
so
all
the
authentication
is
taken
place
from
the
network
server
point
of
view.
G
So
and
initially
we
have
a
pre-shared
key
between
the
end
device
and
the
network
server
and
after
the
joint
procedure,
we
have
arrived
at
the
session
Keys
so
which
are
used
to
decrypt
and
encrypt
the
communication
between
the
end
device
on
the
network
or
the
in
device
on
the
application
server
next
slide.
So
our
motivation
is
to
replace
this
joint
server,
which
was
actually
not
in
the
current
specification,
but
to
replace
it
with
to
play
server
and
the
network
server
communicates
with
the
to
play.
G
G
Next,
so
now,
I'm
going
to
take
you
over
the
current
procedure,
which
is
used
in
the
lower
line.
So
we
have
the
commissioning,
which
means
that
app
au
app
key,
which
is
the
pre-shared
key
between
the
end
device
on
the
network
server,
and
also
we
have
that
DVD
y,
which
is
unique
to
each
of
the
device
next
slide.
So
first,
the
device
sends
a
joint
request
with
some
kind
of
unknowns,
along
with
Debbie
you
I,
along
with
the
WI
and
a
pu
y
to
the
network
server,
and
then
it
talks
hour
after
verifying
the
credentials.
G
That
means
app
app
key,
so
it
sends
back
the
joint
request
already
joined
except
and
this
device
can
be
able
to
derive
the
session
case
later
on
next
slides.
So
this
would
be
the
contents
of
the
request
and
the
response.
The
main
fields
to
note
note
here
is
the
app
eyw
I
unknowns.
A
py
is
more
specific
for
the
application
provider
and
every.
Why
is
specific
for
each
of
the
device
and
the
nonce
is
created
by
the
device
itself
and
in
the
response?
G
Apt
nonce
is
generated
by
the
network's
server
and
net
ID,
and
the
dev
address
are
also
generated
from
the
network
server.
So
here
the
request
is
sent
without
the
encryption,
but
attached
with
the
mick,
that
is
message,
integrity
code
and
but
the
response
is
always
encrypted
from
the
network
server.
So
the
n
device
can
decrypt
the
response
with
the
help
of
the
app
app
key.
G
G
So
these
are
the
keys
which
are
involved
in
authentication
part.
The
up
key
is
a
pre-shared
between
the
device
on
the
network,
server
and
the
network
session.
Key
is
used
or
is
derived,
and
it's
used
to
encrypt
or
decrypt
the
commands
or
my
commands
between
the
network
network
server
and
the
in
device
and
the
app
session
key
is
used
for
the
application
specific
data.
For
now
it's
what
the
keys
are
reside
residing
within
the
network
server.
G
So
I
can
you
cook
como
slice,
so
our
proposition
would
be
to
include
the
radius
server
which,
which
I
mean
in
which
actually
does
all
the
jobs
of
the
network
server
and
we
exchange
the
keys
through
the
radius
attributes
so
and
yeah.
So
in
this
case,
the
network,
the
app
session
key,
we
have
put
two
stars,
which
means
you
can
decide
to
send
to
back
to
the
network.
Server
are
you
reading
and
you
can
share
it
with
another
application.
G
So
we
need
so
basically
when
the
network,
server
or
network
access
server
gets
this
request,
it
has
to
check
the
realm
of
the
application
owner
and
use
a
dns
a
query
or
something
like
that
to
send
it
to
the
appropriate
radius
server.
So
one
such
solution,
which
we
found
was
some
0
for
3,
but
we
need
to
do
the
inverse
of
this
thing.
G
B
Okay,
well,
then,
I
have
fun.
Basically,
this
slaw
here
says
you.
The
Nexus
request
that
you
hack
the
entire
join
requests
with
pipe
it
into
a
single
radius
attribute.
The
content
looks
like
this
and
that's
pretty
much
structured
data,
so
we
have
motor
subfields
in
one
radius
attribute.
We
don't
usually
like
how
attributes
that
way.
We.
G
E
B
G
B
E
Yes
or
no
I
mean
my
two
cents
is
an
implementer
in
some
respects
would
be
easy
if
this
easier
for
this
was
all
just
radius
attributes.
On
the
other
hand,
I
do
have
a
low
thing
for
re-implementing
things
multiple
times.
If
there's
some
kind
of
library,
which
already
does
all
of
this
and
I,
can
just
link
to
it
and
pass
it
a
blob,
then
I'm
happy
right
and
it's
it's
much
easier.
The
more
complicated
issue
is
what
policies
do
people
want
based
on
this?
E
E
So
it's
a
matter
of
what
the
use
case
is
if
your
Express,
if
you
expect
this
to
be
transported
as
is
and
not
really
examined
by
anyone
other
than
a
little
bit
of
crypto
dedicated
to
this
protocol,
it's
probably
okay
to
transport.
It,
as
is
if
the
radius
server
needs
to
do
things
based
on
the
contents.
You
probably
need
to
break
it
out.
C
So
yeah
as
a
chair
ne
ne
ne,
so
we're
not
responsible
for
defining
the
functional
solution
so
from
from
the
lower
point
of
view,
is
there
any
expectation
to
have
such
kind
of
a
solution
based
on
radius
or
it
is
a
you?
Are
you
are
trying
to
proposing
some
things
that
could
be
after
afterward
accepted
by
a
zero,
a
community?
How
do
you?
How
do
you
see
the
the
rest
of
this
work,
assuming
that
this
work
is
a
grid
here
in
this
working
group.
C
Usually
in
this
in
this
working
group
right
now,
so
we
are
we're
responsible
for
the
definition
of
the
protocol,
but
not
how
this
protocol
is
used
by
others,
so
it
could
be
other
working
group
inside
the
ATF
are
in
a
service
do
so
actually
we
will
work
on
this
on
the
actor
if
there
is
an
existing
requirements.
So
I
was
wondering
what
is
the
current
expectation
from
the
lower
community
on
that.
G
K
L
C
Because
I
think
that
the
most
important
part
for
us
from
red
X
perspective
HS
past,
exhibit
to
ensure
that
there
is
a
supports
and
some
requirements
from
this
community
to
be
able
to
develop
that
whatever
I
think
that,
from
a
technical
point
of
view,
we
can
discuss
and
especially
the
link
between
what's
come
from
the
Alara
and
what
you
want
to
export
to
a
radio
server.
But
I
think
that
from
from
a
protocol
it
could
be
straightforward.
We
just
need
to
to
agree
on
the
set
of
attributes.
C
I
may
have
some
concern
about
that
and
the
way
the
attributes
are
defined,
but
the
most
important
part
is
to
ensure
that
this
work
reserve
the
lower
community.
If
not,
we
will
not
be
able
to
say,
oh
from
the
hf
point
of
view,
are
seeking
that
this
is
a
best
solution
and-
and
I
think
what
would
be
at
least
we
tried,
from
a
problem
statement,
point
of
view
it's
to
to
consider
the
different
cases
yet
that
you
may
have
regarding
the
location
of
the
triple
a
server.
C
If
it
is
expected
to
have
multiple
multiple
players,
if
it
is
the
same
kind
of
during
the
both
on
LP
one,
there
were
some
discussion
about
roaming,
for
instance,
but
I
don't
really
know.
What's
what
is
the
the
current
requirements
regarding
is
rooming,
so
I
think
that
this
kind
of
stuff
could
first
of
all
good
first
of
all,
militates
or
I,
don't
even
know
if
it
is
English,
but
actually
a
promote
the
use
of
a
triple
a
beta,
a
triple
a
basic
infrastructure
and
obviously
24
red
you
server.
In
that
case,.
B
G
C
B
C
M
No
competitor,
I,
yeah
I
have
made
the
presentation
last
time
yeah
the
content
of
the
drug
dealer
since
then,
and
all
what
I'd
like
to
see
that
the
content
is
stable.
It
adairs
to
the
recommendation
from
this
working
group
and
it's
fulfilled
on
the
data
type
guidelines
and
so
on.
So
it's
just
a
request
to
consider
this
as
a
new
shelter
item
of
this
working
group.
B
M
Depends
what
we,
what
we
call
standard
it?
The
sundial
in
fact,
which
exists
with,
but
it
is
not
as
wonder
about,
is
an
experimental
track
which
is
in
ptc
psf,
which
the
the
protocol
that
defines
the
communication
between
the
two
and
that
that
support
in
participe,
but
you
skillet,
we
are
targeting,
is
involves
the
cpe
and
another
element
which
located
in
the
network,
which
is
an
another
NP
disappear
and
proxy,
which
is
located
in
the
concentrator.
And
these
two
entities
are
not
songs
are
so
far.
M
As
you
know
here
in
ATF,
it
is
difficult
to
so
not
the
TCP
proxy
staff,
even
for
TCP
existing
networks,
but
there
is
nothing
which
is
which
is
which
is
on
the
rise.
So
there
is
some
magic
there,
which
is
this
MPD
CP
proxies
will
glue
multiple
paths,
the
first
that
we
ought
to
come
from
the
wireless
network
and
the
other
one
that
we've
come
from
the
wire
land
and
then
it
will
glue
this
multiple
paths
in
order
to
increase
the
bandwidth
which
is
exposed
to
the
cast
and
red
cell.
M
There's.
Another
deployment
in
in
Turkey
based
on
in
participate
proxy
another
one
in
belgium
in
proximus,
which
is
based
on
another
input,
CP
proxy,
but
each
time
the
dairy,
implementing,
specific
and
proprietary
solution
to
authorize
the
customer
who
subscribes
to
the
offer
to
make
use
of
this
one.
So
what
we
are
coming
with
the
strategy
specification
is
to
provide
something
which
is
under
eyes
to
auto
l-222
at
well
for
this
kind
of
service
providers
to
deliver
the
service
to
this
customer,
so
MP
DCP
proxies
in
the
network.
M
C
Maybe,
based
on
this
on
this
comment
regarding
the
use
of
MC
p.m.
MTG,
Sofia
will
be
pass.
Maybe
you
can
you
can
try
to
convince
people
that
it
is
a
good
solution
and
to
at
least
express
the
interest
for
that
on
the
mailing
list?
I
think
it
was
the
basic
question
from
from
Stefan
things
that
I
think
that
from
Zoe
as
I
said
for
the
previous
document
from
a
protocol
point
of
view,
it's
fine
and
actually
you
are
following
the
last
recommendation.
M
Particularly
that
don't
figure
to
two
questions
and
the
first
ones
you
interested
in
participating,
fighting
kids
if
there's
a
interesting
participate
if
it
would
be
another
working
group
which
this
talk
about,
that
I
can
invite
people,
but
I
won't
do
that,
because
this
is
the
purpose.
Why
aren't
coming
here?
Because
there
is
expertise
about
the
radius
extension,
so
I
think
that's
for
me.
The
core
point
is
to
two
12-volt
defines
something
which,
which
is
completely
this
aligned.
M
What
you
want
to
see
in
in
erotic
specification,
so
it
will
be
hard
to
convince
the
community
in
the
radix
working
group
that
impede
ecp
is
good.
It's
it
right.
It
good
if
I
have
that,
but
I
am
NOT
happy
to
see
that
and
they
want.
I
want
fight
to
to
see
that,
because
there
is
no
point
there
to
do
that.
E
C
It's
it's
partly
true,
because
it's
always
possible
to
define,
for
instance,
under
specific
AV
pieces.
The
question
is
that
when,
when
even
if
we
have
a
lot
of
room
now,
the
from
from
a
working
group
point
of
view,
you
need
to
ensure
that
it's
21
swear
to
request,
but
not
only
to
someone
but
to
two
people
that
will
implement
this
yeah.
So
in
it
was
not
something
against
you.
C
E
C
And
I
think
it
was
just
to
be
able
to
figure
out
what
will
be
a
as
a
way
forward
for
these
documents.
So
sorry
we
are,
we
are
light.
We
will
not
skip
the
other
one.
We
just
to
say
that
we
will
so
we'd
be
late,
so
the
next
one.
Maybe
we
can
try
to
shorter,
maybe
the
presentation
but
and
between
at
just
time,
for
some
comments.
So
please
I.
J
Ronnie
yeah
a
and
0
this
okay
I'm
anchor
chain
from
cisco
systems.
This
is
a
joint
work
with
my
colleague
lay
machine
from
Cisco.
So
this
is
a
okay
I'm.
We
are
trying
to
finish
environment,
so
this
is
the
problem
statement.
I
think
this
is
where
no
into
the
to
the
to
folks
in
this
room
and
to
the
working
group.
So
this
is
body.
Why
add
1
by
to
identify
field
which
basically
allows
only
256
requests
in
flux?
J
J
So
the
issue
we
are
facing
and
at
the
vendor
actually
as
a
reference,
so
a
suspect
that
the
problem
is
not
unique.
So
currently
we
have
actually
deployment.
We
have
an
implementation
and
he
pointed
at
used
to
hundreds
of
UT
positions
in
the
indicates:
a
wireless
wireless
LAN
controller,
but
it's
the
rental
Hendricks
and
for
the
next
generation
product.
The
requirements
basically
increase,
increase
this
performance
by
10
X.
Ok,
you
can
imagine
now
it
goes
two
sovereigns
of
sessions,
that's
case,
I
think
very
difficult.
It's
just
so
this.
J
So
this
is
a
problem
that
I
mean
the
ones.
A
scale
goes
to
surveillance
of
sessions.
Basically
you
have
you
have
a
number
of
issues
right.
You
have
a
resource
utilization,
a
memory
you
have
cpu,
you
have
the
local
port,
local
bodies
limited
right
and
you
have
efficiency
issues
and
you
get
a
TCP
I
mean
it
puts
a
lot
of
load
on
your
own
or
you're,
basically
on
the
client
as
words
on
the
summer.
Harmonization
can
summer
support.
J
If
these
wine,
a
client
actually
connects
generate
thousands
of
station
right
the
operational,
this
implementation
at
the
operational
complexity,
next
page,
please
so
here
we
basically
we
look
at
this,
which
is
basically
it
seems,
there's
opportunity
really
for
us
to
actually
address
this.
It
looks
you
know.
I
I
really
am
new
to
this.
To
to
this
radius
working
group,
I
have
construed.
An
upper
document
looks
like
this.
J
The
issue
has
been
postponed,
but
VI
I
believe
we
have
a
time
that
we
are
at
points
and
these
need
to
be
addressed
in
the
protocol
instead
of
doing
work
run.
So
this
is
a
that's.
What
it
is
extension
is
about.
Basically,
we
we
propose
a
extended
packet
header,
but
basically
to
enlarge
the
identifier
field.
While
we
are
doing
that,
we
also
it
looks
like
reasonable
to
also
a
large
the
code
field
ecotype,
because
that
is,
that
is
a
one-bite
I
think
we
currently
use
about
fifty-fifty
son.
J
So
if
we
have
a
quarter,
then
we
will
basically
to
be
future
proof.
Let's
do
the
Cabbage
advice
and
be
done
with
it
right.
So
there's
a
then
the
way
to
hear
the
key
for
this
you
know
proposal
is
to
basically
reserved
to
allocate
a
packet.
We
cope.
I
are
thinking
in
this
group
because
you
really
become
message
type
here.
We
call
package
type
code
and
so
as
a
carrier
to
in
pain
to
actual
the
real
you
know
packet
inside
then
we
use
a
capability
basically
to
discover
their
way.
That
is,
the
server
is
supporting.
J
It,
so
suppose
is
functionally
next
one
please
right.
This
is
the
this
is
the
extremely
package
a
that
we
are
proposing
so
the
first.
If
you
look
at
a
in
the
in
the
current
standard
here,
we
have
the
the
first
batch.
Is
that
it's
a
package
code,
so
we
had
to
be
used
the
allocated
my
special
one
and
the
next
one.
We
is
a
reserve
field.
The
ninth
is
the
same.
J
Authentication
is
the
same,
become
another
reserved
view
that
in
the
code,
if
you
look
at
code
is
shifted,
it's
like
a
two
bites
named
identify
four
bytes,
so
the
somatic
should
be
made
the
same.
So
these
the
why
we
have
this
resolved
field.
It's
basically
the
concise.
The
bias
is
for
the
existing
protocol.
Analyzers
right.
J
If
we
with
this
format,
we
can
at
least
pass
it
and
syntactical
right,
yeah,
that's
a
bit
if,
if
the,
if
you
focusing,
is
working
group
view
that
is
not
necessary,
of
course,
then
we
can
reduce
it
right
that
we
don't
feel
that
leaves
the
ID
other
two
by
Scotty.
Certainly
we
got
a
can
be
reduced.
All
right
makes
my
face
so
the.
How
would
this
work?
Basically,
you
use
you.
The
client
initiated
this
stutters
stutters
server
message
right
with
a
new
attribute
you
basically
to
do
the
discovery
of
capability
on.
J
J
You
here
interim
implementation,
so
we
recommend
in
the
draft
attached,
we
reserve
the
existing
0
to
255
the
numbers
face
and
for
the
standard
head,
because,
if
I
discover
or
whatever
right
and
is
it
for
the
upper
for
the
larger
numbers,
you
use
that
as
a
as
I
identified
fill
for
the
extent
of
it
yeah
buzzer
is
this
cover
you
can
now.
You
can
basically,
each
year
to
the
packaging
imposed
for
match
in
the
standard
header
or
extended
head
I.
Think
that's
it.
J
So
what
you,
because
this
so
whatever
we
like
to
do
exist,
we
want
to
solicited
feedback
from
this
working
group
and
the
respect
to
address
our
concerns
and
also
basically
2k
some
operational
implementation,
fear,
certainly
from
the
cisco
iOS
implementation
and
also
with
the
open
source,
probably
Baku,
visa-free
radius.
Hopefully
by
next
IDF.
We
have
more,
basically
implementation
curing
disease,
so
we
like
basically
address
the
concerns
and
spin
the
drafter
one
more
time
and,
of
course,
be
onesies.
We
would
like
to
see
the
bath
we
adopted
at
that
good.
B
Could
I
first
make
note
that
with
my
chair
head
on
so
this
is
actually
a
substantial
modification
to
the
protocol.
We
had
a
similar
one
just
last
week,
basically,
which
is
the
a
larger
packets
for
radius
of
a
tcp,
but
that
was
experimental.
It
was
over
a
new
transport
anyway,
so
these
were
all
fresh
implementations.
What
you
have
here
basically
requires
all
of
the
industry
to
update
all
their
their
equipment
and
that's
a
whole
different
story.
So
here.
J
He
is
yeah,
actually
I
read
the
number
of
drafts
I.
Also
we
have
you
thinking.
We
saw
the
part
of
this.
It
looks
like
actually
the
church
is,
although
conceptually
yeah,
it
is
a
fundamental
I
agree,
but
the
church
is
in
really
limit
to
the
header,
the
encoding
and
decoding.
So
my
I
have
a
look
at
some
other
some
code.
It's
look
at
my
sense
at
this
point
is
probably
a
few
hundred
lines
of
code
Shh
because
it's
really
limited
in
in
the
infection
of
encoding
at
you,
Cody
yeah
living
so
but.
E
This
is
Alan
yeah,
something
like
this
has
been
needed
for
10
years
doing.
It
is
a
whole
other
nightmare.
As
a
point
of
information.
There
is
at
least
one
commercial
radius
server,
which
extends
the
identifier
space
via
of
VSA.
They
simply
put
a
VSA
into
every
packet
and
the
client
and
the
server
have
a
configuration
flag,
saying.
F
E
This
vsause,
this
VSA
there's
no
negotiation,
no,
nothing!
It's
a
hundred
percent
compatible
with
existing
radius
that
might
be
simpler
and
and
would
work
without
changing
anything.
This
changing
the
header.
If
you're
going
to
throw
out
the
header,
you
might
as
well
throw
everything
out
and
start
over
from
scratch,
which
sounds
sounds
familiar.
I
think
we
did
that,
but.
J
C
E
C
Ginell
as
a
individual,
I
think
it's
a
perfect
use
case
for
diameter,
which
saying,
if
the?
If,
if
the
idea
is
to
change
the
error,
if
you
can
rely,
I
didn't
investigate
any
any
any
solution
for
that.
But
if
you
can
rely
on
a
tribute,
it's
okay,
I
think
that
if
the
real
goal
is
to
enable
to
add
will
keep
more
than
250
556
concurrent
operations,
it's
the
it's
it's
because
you
have
a
clean
it
or
something
more
and
more.
In
that
case
is
diameter.
J
But
is
this
really?
I
stand
the
principle.
This
really
does
not
a
violent
that
pretty
simple
right,
so
it's
basically
negotiation
basis
based
yeah
right.
So
here
it
is
just
a
very,
very
practical,
a
challenge
we
have
today.
I've
advocate
with
that.
The
data
point
you
know
implemented.
We
have
hundreds.
Now
we
are
going
to
south
I
mean
that's
just
that
this
is
just
I
mean
to
people
who
have
not
been
associated
with
the
radius
who
have
not
work.
It
sounds
really
the
first
time
we
talked
about
this
sound
really
silly.
C
One
small
additional
comment
and
I
and
after
that
I
will
let
the
floor
and
we
will
flow
the
meeting.
But
the
point
is
that
for
so,
for
instance,
for
diameter,
it
is
said
that
it
is
used
in
mobile
network
and
join
it's
fine.
It's
it's
it's
expensive
and
so
on
and-
and
the
fact
is
that
everything
based
on
reduce
as
it
is
today
is
fine
for
the
current
deployment
and
even
future
functionalities.
C
Now,
if
we
think
that
the
protocol
is
not
so
fine
and
we
need
also
to
modify
the
protocol
itself,
not
only
at
a
adding
attribute
to
be
able
to
support
this
kind,
that
is
a
key
issue
for
you.
As
you
see
a
thing,
I
think
it's.
Oh
it's
always
time
to
think
about
how
to
redefine
also
how
the
triple-a
infrastructure
using
such
kind
of
an
environment.
H
N
My
name
is
my
mission
from
Cisco,
so
so
I
was
thinking
this
so-called
a
fundamental
change
is
still.
If
you
don't
support
it,
you
don't
support
it
right
from
our
a
company
point
of
view.
If
we
have
such
a
use
case-
and
we
also
have
the
suicide
of
the
supports-
and
it's
nice
to
do,
although
I
agree
to
go
to
things
like
a
diameter
is
a
simpler,
but
this
is
a
protocol
needs
to
move
forward
right.
If
we
keep
delaying
this
thing,
this
issue
is
a
real
issue,
are
navigate
the
soft
right.
J
As
another,
at
the
reference,
so
for
folks
who
actually
who
do
know
me,
I
have
been
involved
in
the
routing
protocol
area
for
a
number
years,
so
weary
tradition,
I,
don't
know:
do
you
guys
pay
attention?
We
transition
the
global
internet
from
25
years
into
four
bodies
in
DDP.
That
is
the
sole
fundamental
right,
but
buddy,
what's
done
is
done
really
nicely
now
the
tradition
where
you
were
you
paid
piece
by
piece
spaces
and
the
backward
compatible
and
the
whole
world
has
tradition
this.
J
This
shall
be
some
fundamental,
but
it
seems
to
me
is
really
the
big
here
in
st.
so
full
of
of
the
concept
atacan
concept
from
they
were
not
to
know
myself.
My
feeling
is
that
as
a
as
a
product
designer
and
also
at
the
at
the
coder,
my
sense
is
that
this
this
is
really
a
few
hundred
lines.
Cultures
are
we
get
more
tea
than
later
next,
one,
okay,
yeah.
B
So
I'm
trying
to
find
some
nice
closing
words,
but
so
I
think
we
honor
I
think
what
agree
that
this
is
a
problem
worth
solving
and
it's
hitting
the
streets.
So
that's
no
doubt
about
that.
Now
you
have
a
solution
here,
which
is
a
bit
more
heavy
weight
than
what
I
told
us
about
with
the
VSA
and
I
think
we
should
all
go
home
and
think
about.
How
do
we
best
solve
this
problem?
B
Is
it
sufficient
to
well
not
have
to
be
as
I
but
standardized
an
attribute
for
the
extended
header
or
something
extended
identifier
or
you
do
do
this
rather
big
change,
so
I
think
our
options
are:
do
we
apply
the
band-aid
on
one
place
or
another,
and
is
it
a
small
piece
of
n
tight
or
a
big
piece
of
band-aid?
The
truth
is
radius
is
pretty
much
as
its
limits
here
and
we
can't
do
without
band-aid.
So
we
have
to
less
than
perfect
options
on
the
table,
I
think
and
yeah.