►
From YouTube: IETF93-RADEXT-20150720-1850
Description
RADEXT meeting session at IETF93
2015/07/20 1850
A
Hello
and
thanks
for
coming
this
is
the
radix
meeting
at
ITF,
93
Chaz,
our
second
key
owner.
More
so
I
see
that
the
audio
is
apparently
working.
I,
hear
me
pretty
well
and
so
I
guess
we
can
start
right
well
by
the
way
with
the
preliminaries
arm.
So
first
thing
I
have
to
show
you
is
denote.
Well,
you
can
see
three
much
everywhere.
The
IDF
now
also
on
screen
note
well.
A
B
A
A
Thank
you,
okay,
so
we
have
one
note
taker.
We
would
ideally
also
have
a
Java
scrub
same
question
again.
Okay,
thank
you!
So
we're
both,
which
means
we
can
start
to
bash
the
agenda.
The
agenda
is
up
on
screen.
So
do
you
have
any
new
items
you
forgot
to
mention
on
the
mailing
list
or
otherwise,
if
you
don't
like
here
wonderful,
then
I
guess
we
can
start
with
the
overall
slide
deck
if
I've
find
it
someplace.
A
So
this
is
Tina
well
again
the
agenda.
First
of
all,
we
have
a
couple
of
drafts
which
are
in
the
working
group
stage,
so
there
is
a
dynamic
discovery.
15
there
are
two
active
working
group
drafts:
IP,
port
radios,
extensions
and
bigger
packets,
followed
by
some
new
work,
which
we
are
going
to
talk
about
for
a
bit
which
is
now
in
the
new
charter.
We
have
been
reach
other,
so
data
data
types,
eep,
responds
identity,
handling
and
cui
proxying.
A
Then
there
is
a
item
which
is
also
now
in
our
charter,
because
we
said
we
will
take
care
of
this.
It's
advancing
some
documents
to
a
different
track,
most
notably
RC
6614
was
mentioned.
Let's
discuss
this
for
a
few
moments
and
then,
in
the
end
we
have
one
individual
drafts.
You
were
coming
up
draft
clamor,
reset
radix,
very
common
BSA's,
which
the
authors
are
going
to
present
near
the
end
of
the
meeting.
A
So
let
me
first
show
you
the
document
status.
So,
since
the
idea
of
92,
we
have
published
two
RFC's,
the
network
access
identifier,
editor
senator,
is
now
our
c75
42.
We
also
have
support
of
fragmentation
of
radius
packets.
A
beto
perez
min
this
RC
7499,
which
are
now
both
out
in
the
wild.
We
have
one
document
which
made
it
into
the
RFC
edit
of
Q.
A
That's
my
own
document
nai,
based
on
having
p
discovery
for
radios,
TLS
introduced
dtls,
so
this
wasn't
all
48
but
I
bounced
it
back,
but
still
it's
in
the
RC
edit
of
you
explain
in
a
few
moments.
What's
up
with
this
one,
we
have
nothing
in
our
ITF
last
call
nothing
nice
you're
processing,
but
we
have
two
documents
waiting
for
a
shepherd
right
up.
That's
radios,
extensions
for
IP
port
configuration
in
reporting.
There
is
a
virginal
five,
which
was
published
recently
removed
last
call
for
free
was
completed
and
only
minor
changes.
Still.
A
The
authors
are
here
to
refresh
our
minds.
The
write-up
will
be
done
by
email,
so
I
think
we
are
pretty
much
good
to
go
for
for
publication
here.
The
other
document,
which
is
a
wedding
Shepherd
right
up,
is
the
larger
packets
for
radios
over
TCP
from
Sam.
It's
basically
nothing
holding
this
back
for
publication,
except
that
I
have
to
write
the
right
up.
So
this
document
used
to
have
a
shepherd's
unicorn
in
the
previous
chair.
A
He
basically
greets
like
24
hours
ago
to
transfer
this
over
to
me,
so
I
will
now
be
doing
the
write
up.
I
think
we
have
nothing
to
run
good
last
call
and
nothing
really
in
progress
of
working
group,
I
music,
we
already
discussing
so
here's
the
three
documents
we
have
in
terms
of
new
work
for
the
new
charter.
Mm-Hmm
dynamic
authorization
proxying
in
radios
from
the
under
this
had
some
extensive
discussion
of
the
mailing
lists.
I
we
have
a
slide
deck
on
this
later
on.
A
We
have
data
types
and
radios
also
from
another
which
got
its
fair
share
of
meeting
before
it
was
adopted.
So
it
is
I
think
pretty
much
McHugh
at
this
point,
and
it's
now
meanwhile
adopted
so
we
can
adopt
an
adoption
call
before
we
reach
our
that
which
was
maybe
bit
early,
but
still
anybody.
Everybody
agreed
that
we
should
have
this
one
in
the
working
group.
So
now
that
we
are
each
other's
I,
don't
think
it
makes
sense
to
call
for
adoption
again.
A
Everybody
just
wants
to
have
it
so
on
this
draft
can
be
reissued
as
an
idea
of
working
group
document.
Finally,
we
have
the
populating
Eve
identity
document
from
myself.
Again,
this
was
held
by
the
new
charter
and
there
was
some
doubts
if
radix
this
really
the
right
case
to
go
with
a
new
charter.
We
are
supposed
to
work
on
this
right
now,
so
I
don't
want
to
advance
my
own
draft.
That's
cheesy,
so
I'm
waiting
for
you
Nell
to
determine.
A
A
Minutes
so
that's
document
status
according
to
the
agenda,
we'll
just
like
to
go
through
all
the
drafts
one
by
one
on
starting
with
the
dynamic
discovery
15.
So
the
issue
with
it
well
very
small
issue
with
it
is
that
it
has
an
awful
number
of
our
see
references
and
it
has
one
internet-draft
reference
in
its
informative
section
and
I
just
realized
that
the
informative
reference
is
going
to
do
is
go
to
the
iesg.
A
It
is
on
the
tender
chatter
I
joined
us,
so
I
just
told
the
associated
or
please
hold
back
the
publication
until
all
my
references
are
RFC's
which
basically
made
it
bounced
out
of
all
48
are
back
into
the
generic
you
with
any
miss
ref.
The
draft
is
the
draft
younger
ITF
at
your
own
and
according
to
the
RC
edit.
All
this
means
another
three
weeks
or
so
after
the
terror.
A
Chats
approval
to
get
things
done
so
I
would
be
extremely
surprised
if
this
draft
is
still
a
draft
when
we
meet
again
at
ITF
94,
that's
about
all
I
have
to
say
about
this
draft.
It's
really
pretty
much
done
so.
The
next
thing
we
have
is
the
IP
port
radius
extensions
with
the
Shepherd's
work
done
by
noon.
L
and
now
I
would
like
to
call
the
office
for
their
slide
deck
I,
hope
they're.
Actually,
here.
A
D
B
A
B
A
Ok,
yeah
for
radix
pick
up.
I
could
sell
three.
Actually
I
didn't
get
any
slight
like
I.
Don't
think
it's
tactic
is
really
necessary.
There
were
no
comments
on
the
many
lists
on
the
substance
of
this
draft.
So
basically
it's
all
waiting
on
me
now
on.
Unless
somebody
has
any
comments
on
the
bigger
packets
draft.
Oh.
B
Long
as
in
rural
and
I
have
one
so
we're
giving
this
document
liking,
I
have
one
a
specific
question.
Actually
twice:
is
that
so
I'm,
okay
with
the
principal
possibly
get
packets,
but
along
this
one?
So
the
purpose
of
this
draft
is
to
become
when
experimental,
draft
RFC
and
along
this,
the
document
you
have
the
definition
of
the
protocol
error
code
and,
from
my
point
of
view,
it's
not
so
tied
to
this.
B
So
you
need
this
one
to
be
able
to
I
like
the
fact
that
there
is
an
error,
other
protocol,
liver
and
for
this
case
it's
it's
a
two
large
pockets.
But
I
was
wondering
if
the
protocol
error
code
could
be
put
out
of
this
draft
and
be
used
as
a
generic
error
code
at
the
reduced,
because
this
requirements
to
have
something
more
to
have
a
finer
granularity
in
the
error
code
from
the
irresistible
was
raised
several
times.
B
E
So
I
wanted
to
answer
the
question,
so
we
did
actually
discuss
that
on
the
list
and
the
the
answer
is
that
oh,
my
an
experimental
document
can
register
a
protocol
error
code
and
the
and-
and
it
requires
iesg
approval,
we're
going
to
need
to
call
out
in
the
eye
adept.
F
E
Call
on
to
get
to
to
get
enough
review,
since
this
is
an
experimental
document,
oh,
that
the
good
point
can
be
registered.
There
was
there
was
discussion
about
whether
we
should
pull
it
out
and
basically
there's
nothing
that
stops
you
from
using
it
as
a
generic
error
code.
Even
if
it's
in
this
document,
you
would
have
to
do
one
of
two
things
you
would
have
to
do
a
normative
down
reference,
but
I
think
you
could
explain.
E
They
wanted
to
use
it
and
just
update
the
the
registration
in
the
eye
on
a
consideration
section,
and
that
would
be
fine
too,
and
basically,
my
feeling
was
that
it
wasn't
worth
delaying
this
document
and
to
split
it
out
into
a
one-page
document
to
finding
a
protocol
error
code
just
for
process
simplicity,
particularly
given
that
we're
hoping,
hopefully
moving
a
lot
of
this
stuff
from
experimental
to
standards
track
in
the
near
future.
Anyway,
I
don't
like.
E
G
B
Time
yeah,
the
point
is
that
the
visible
so
first
of
all,
I,
don't
want
to
delay
any
decision
on
so
the
process
for
publication
of
the
exponent
of
drafts
for
the
bigger
packets
is.
The
only
point
is
that
really
it
was
an
open
question.
Things
that
this
new
error
could
be
used
could
be
using
a
name
could
be
used
for
other
purposes
and
not
related
to
the
bigger
package.
Exactly.
G
And
that's
that's
the
also
the
scary
thing
with
this
is
ok,
you
define
it
in
the
context
of
this
document.
What
does
it
mean?
It
should
be
standards
track
fairly
soon,
I'm,
not
sure
it's
one
page.
I
would
like
it
to
be
one
page.
I
think.
As
soon
as
you
define
it,
you
could
probably
find
five
or
ten
uses
for
it,
in
which
case
what
you
do
from.
E
Why
I
don't
want
to
do
this
is
because
you
we
have
now
demonstrated
that
what
you
know
could
be
a
city.
What
is
this
simple
registration
is
now
going
to
turn
into
like
we've
already,
you
know
added
more
steps
to
it,
and
so
my
argument
is,
you
know
this
was
already
discussed
on
the
list.
I,
don't
think,
there's
new
information
arm
I
would
prefer
not
to.
G
B
E
H
Kathleen
Moriarty
ad,
so
yeah
I,
agree
with
Sam
I.
Don't
see
why
this
would
hold
up
things.
I
haven't
heard
anything
that
solid
enough
of
what
why
it
can't
be
used
and
maybe
there's
some
context,
I'm
missing,
but
just
on
the
face
of
it,
I
don't
see
why
an
experimental
draft
right.
So
that's
the
purpose.
You
put
an
experimental
drop
out.
You
see
if
it
gets
enough
uptake
and
then
you
turn
to
standards
track
and
if
you
start
using
it
in
places,
then
we
change
it.
Okay,
thank.
H
A
B
A
Okay,
so
then,
let's
move
on
to
the
new
work
we
are
now
doing
at
the
new
charter,
the
first
one
of
which
is
data
types
which
I
can
only
say
what
really
really
broad
consensus
to
adopt
this
in
the
working
group.
Now
that
we're
we
can
do
it.
I've
already
asked
ln
to
resubmit
the
document
as
a
working
group
document
now,
but
she
also
has
a
slight
EXO
will
appear,
bring
up
the
slack
tech.
G
G
B
B
G
Ucla
is
principal
and
opaque.
Binary
data
is
not
ready,
so
that's
really
the
choice
there
so
I
heard.
For
example,
there's
the
chap
has
weird
attributes
their
username
is
utf-8.
That's
really
the
distinction
new
GF
favorite
bar
I'm
Joe
navigator
type
in
there
for
other
complex
structure.
Right,
you
could
say
well
chat.
Password
is
binary,
but
in
this
other
case
of
some
of
the
geo
print
actors,
they're
actually
hack
data
structures
from
somewhere
else
might
want
to
call
those
separate
orders.
G
A
Also
have
one
question
as
an
individual,
so
you
basically
said
you
have
now
rewritten
history
of
all
are
seized
up
to
date
and
update
everything
what
happens
with
every
RFC,
which
is
issued
in
the
future,
which
might
have
been
crazy
data
types.
Are
you
planning
to
reissue
this
document
every
now
and
then
dance.
G
Future
rfcs
should
refer
to
the
data
type
stuff
on
here.
One
of
the
reasons
for
the
data
types
draft
is
the
extended
attributes
space
which
has
a
couple
of
different
formats,
depending
on
what
we're
doing
so.
Suddenly,
all
you're
asking
art
becomes
useless
until
I,
nslc
group
space,
you
use
so
the
answer
there
is
ignore
the
ascii
art-
and
you
say
this
happen.
Route
is
type
integer,
which
is
four
bytes
and
all
the
rest
of
it
is
whatever
is
as
it
comes
from
and
is
document
has
asked
the
art
for
the
extended
attribute
or
not.
G
Need
you
to
find
in
pain
of
heights?
You
wish
you
an
update
to
the
data
text
document
or
you
explicitly
call
it
in
your
standard
you're,
adding
a
new
data
type,
and
there
is
an
INF
registry
for
game
of
things.
This
all
came
about.
It
is
2865,
defines
five
dated
and
then
there
were
actually
uses
the
talking
really
as
asked
the
era's
look
like
the
same
video
3162,
which
uses
address
to
define
ipv6
address.
Even
though
2865
assists
addresses
like
for
caring
parents,
you
have
no
idea
wouldn't
estate.
A
Okay,
so
when
I
set
the
data
types
document
head
really
broad
consensus
to
adopt
the
next
document,
the
correct
use
of
ypres
sponsored
empty
head
consensus
to
adopt.
It
wasn't
quite
at
that
same
level,
but
I
do
have
a
slight
leg,
very
hot
one
from
myself.
Talking
about
that.
So
actually
nothing
new
has
happened
since
the
last
ITF.
So
basically,
I
can
only
recap
what
we
did
at
ITF
91
in
wonderful
honolulu,
so
we're
at
reply.
A
Doctors
meeting
and
the
idea
was
to
make
this
a
bcp
documents,
which
kind
of
updates
the
expect
itself
saying
how
you
should
actually
go
about
user
name
and
what
you
can
go
route.
But
what
can
go
wrong?
What
you
should
do
right
and
what
happens
if
you
don't
right,
so
nothing
has
changed
here.
So
my
only
update
is
regarding
next
steps,
I'm
wondering
if
we
need
a
new
call
for
adoption,
because
during
the
adoption
whole
the
significant
significant
point
of
friction
was.
A
Should
we
really
do
this
in
red
X
and
there
were
some
significant
out
by
some
now
that
the
highest
he
has
actually
proved
the
new
charter,
which
very
explicitly
calls
out
this
work.
I'm
thinking
this
is
now
gone
and
we
can
just
adopt
it.
But
I
want
to
make
this
up
to
you
now,
because
its
own
draft,
so
at
some
point,
if
it
gets
adopted,
I,
would
republish
this
as
a
working
group
document
and
the
changes
from
the
trouble.
A
doctors
are
not
in
my
current
working
copy,
yet
so
on
our
published
net.
G
This
is
alan
again,
so
the
main
point
of
contention
here
is
I
think
Bernard
has
jumped
in
with
both
feet.
I
had
a
chat
with
him
earlier
today
and
talked
of
it
with
Sam
about
this.
There
are
a
couple
issues
here.
The
most
bizarre
one
is
4284
which
I
hadn't
really
paid
attention
to
and
Bernard
mentions
anyone
know
what
that
is.
Guesses,
I
look.
G
I
think
what
needs
to
be
very,
very
clear
in
this
I
think
this
is
a
good
problem
to
solve,
but
when
you
need
to
be
very
clear
is
which
identity
we're
talking
about
we're
on,
because
that
matters
right
generally
for
something
like
TTL
srp,
there's
an
outer
identity,
there's
an
inner
identity
and
then
there's
an
inner
method,
identity
and
they
all
can
be
completely
different
and
the
inner
method
identity
is
a
random
character.
Sets
got
no
idea
what
it
is.
G
It's
completely
different
than
anything
else,
and
most
of
the
user
interfaces
do
not
actually
let
you
set
the
method,
identity
right.
They
let
you
set
the
EP
identity.
Sometimes
the
outer
one,
sometimes
separately,
the
inner
one
windows
will
magically
set
the
inner
method
identity
to
something
and
most
everything
else
will
use
the
inner
identity
in
deep
identity
as
the
inner
method
identity.
But
yes,
all
this
needs
to
be
documented,
because
people
are
doing
some
surprising
things
with
us.
E
So
I
I
definitely
think
that
there
are
some
issues
and
then
now
that
I
have
that
I
want
to
thank
everyone
who
helped
me
understand
what
Bernard
was
saying:
I
really
wasn't
trying
to
be
armed
confrontation.
Other
thing
I,
just
honestly,
didn't
understand
it
and
tell
like
five
messages
into
the
discussion.
Oh
I
think
we
should
adopt
this
document.
I
think
it
is
fine
to
adopt
this
document
in
its
current.
I
E
But
I
think
that
Bernards
it
it
has
raised
an
issue
that
needs
to
be
resolved
and
we
should
continue
to
discuss
on
the
list.
I
don't
think
4284
is
relevant,
even
if
people
use
it
because
this
document
talks
about
eep
response,
/
identity,
not
eat,
request,
/,
identity
and
I.
Think
we
should
just
make
it
really
clear
that
we're
not
talking
about
you
request
/
identity
in
this
document,
I.
B
I
think
that
so
you
know,
I
think
that
we
are
so
about
the
adoption
of
this
document
as
working
good
document
does.
It
means
that's
one
hundred
percent,
so
the
content
of
this
document
would
be
what
we
will
have
at
the
end
as
it
may
or
may
not.
But
at
least
it
could
be
this
case
at
the
working
group,
liver
and
we
can,
we
can
can
reduce.
B
It
recommends
correct
what
needs
to
be
corrected
inside
and
from
my
point
of
view,
according
to
the
discussion
that
we
had
during
the
code
for
adoption
period,
there
is
a
false
reports
for
this
document.
The
only
issue
where
the
remaining
issue
was
about.
If
it
is
that
it's
this
work
should
be
done
in
red,
X
or
some
somewhere
else,
and
the
conclusion,
according
to
the
new
charter,
is
that
this
work
should
be
done
in
in
red
X.
B
So
from
my
point
of
view,
as
a
chair,
I
would
say
that
there
is
no
need
for
corruption,
so
I
think
that
I
will
confirm
this
on
the
mailing
list.
If
someone
disagree,
we
can
still
will
discuss
this
point,
so
it
could
be.
The
first
point
about
the
second
points:
we
know
that
there
is
some
ambiguity
in
the
EAP
implementation
and
how
the
identity
are
used.
B
After
that
we
could
provide
also
some
clarification
on
how
it
should
be
used
in
EP
implementation,
but
I
think
that
the
normative
work
and
the
recommendation
should
remain
on
how
to
use
an
identity
provided
using
EAP
response
and
and
how
to
use
this
identity
in
user
name
is
Aaron
radius
or
diameter.
Everything
else
could
be
good
point
rise
for
EAP
implementers,
for
instance,
but
I
think
that
we
should
limit
the
work
on
on
this.
So
to
focus
on
this
on
this
aspects
and
I
think
that
everyone
would
be
okay.
B
I
think
that
bird
was
ok
also
with
the
principal,
and
I
think
we
can
find
all
circumstances
here
and
on
the
magnum
is
on
this
on
these
points.
So
removing
the
document
based
on
parent
comments,
its
issues
that
there
is
some
morning
to
glorify
and
how
everything
related
to
metod,
specific
identity
and
so
on,
but
ISIL
that
undo
principal.
We
agree
on
that.
There
is
something
to
cry
fine
and
we
can
work
all
together
on
how
to
clarify
the
use
of
this
identity
either
in
the
brisbane
or
over-reduced
message
or
diameter
message
would
be.
A
Okay,
so
thanks
for
those
comments
on
so
we're
confirm
mother
Elias
and
see
how
it
goes.
The
last
new
document
we
have
this
time,
I've
put
up
consensus
to
adopt
with
a
question
mark,
wasn't
quite
as
explicit
as
the
Odyssey
you
I
proxying
and
again
we
have
a
slide
deck
from
Ellen
coming
up
in
a
few
seconds.
G
G
All
right,
Mike
works
out,
that's
better
operator
round
by
mistake,
so
the
idea
is
the
the
visited.
Network
adds
the
operator
named
outbound
the
home
server
records
it
along
with
all
the
other
user
accounting
information
when
there's
a
coa,
it
sends
it
back
and
all
the
coa
proxies
will
proxy
on
operator
name
instead
of
user
name,
because
that's
the
visited
network
that
you're
trying
to
get
the
packet
to
once
you
get
into
the
visited
network,
you
have
to
get
it
to
them
as
everyone
mangles,
Nazz
IP
address
and
has
identifiers.
G
J
G
The
limitation
has
discussed
on
the
list.
This
is
only
defined
for
user
names
and
realms
if
you're,
using
some
other
method
of
proxying
all
bets
are
off
it's
outside
this
spec.
How
you
get
those
coa
packets
back
I
have
no
idea.
No
one
knows
anything
about
this,
given
that
the
overwhelming
majority
of
radius
proxying
is
based
on
user
name
and
realm
I
think
we're
okay.
Here,
the
larger
issue
is:
how
do
you
prevent
one
realm
from
kicking
someone
else's
users
off
right
if
you're
the
visited
network
and
you
get
a
packet
saying,
kickoff
user?
G
How
do
you
know
it
came
from
the
correct
source?
I?
Think
if
you
go
to
the
next
slide,
there's
some
text
on
this
I
won't
read
this
initially
51
76
does
say
you
do
a
reverse
path
check.
So,
if
you
get
if
the
visited
network
gets
this
packet,
it
takes
the
user
name
and
looks
it
up
to
see
if
it
would
forward
the
user
name
to
that
realm.
Now
the
key
thing
there
is:
it's
not
an
actual
forwarding
check,
because
the
co,
a
proxy
and
the
home
server
can
be
different.
G
G
This
is
this
is
a
bit
of
a
problem,
because
it's
not
really
that
secure.
Coming
to
this
slide,
there
are
no
provisions
in
radius
for
end-to-end
and
cryptographic,
authentication
of
the
data
being
transport.
All
the
proxies
can
do
anything
they
want
to
the
packets.
All
the
security
is
hop-by-hop.
The
entire
system
is
trusted.
Intermediate
hops
are
free
to
add
change
or
delete
the
data
they
have
access
to.
G
G
Probably
the
best
thing
to
do
is
have
operator
nas
identifier
as
a
large
opaque
token.
So
you
have
a
large
space
that
this
token
can
come
from
and
a
small
number
of
users.
So
if
someone
forges
this
and
injects
it
into
the
proxy
chain,
the
proxies
don't
keep
state.
They
have
no
idea
what's
going
on,
but
it
will
come
to
the
home
server
and
then
there's
a
visited
network.
G
Sorry
and
then
there's
a
small
chance
that
this
will
be
accepted
as
a
valid
packet
and
the
visited
network
will
go
whoa
that
that
operator
naza
identifier,
is
not
something
I
recognize
and
will
reject
it.
This
is
only
for
people
outside
the
proxies.
The
proxies
that
are
involved
will
see
this
and
we'll
be
able
to
replay
it,
but
but
nothing
you
can
do
about
that.
This
is
radius
in
the
end.
What
you're
talking
about
is,
you
know
pick
two
companies
Microsoft
wants
to
kick
all
of
IBM's
users
offline.
G
They
don't
have
access
to
this
data
because
they're
not
proxying
IBM's
users.
The
next
hop
is,
they
may
be
able
to
do
it,
but,
oh
well,
that's
radius
next
slide
on.
So
this
is
just
what
I
was
saying.
Any
proxy
can
replay
it.
We
can
minimize
the
number
of
proxies
which
see
the
token
and
end-to-end
encryption
of
the
data
is
outside
the
scope
of
radius.
G
This
is
the
larger
problem.
51
76
says
that
the
NAS
must
treat
all
attributes
as
mandatory
and
operationally
I
filed
an
errata
for
this
some
NASA's
complaint.
If
you
send
them
proxy
state,
they
don't
know
what
to
do
with
proxy
state.
51
76
as
the
visited
radius
server
is
a
proxy
and
must
add
proxy
state
when
it
sends
it
to
the
NAS.
The
nass
goes.
This
isn't
a
session
identification
attribute
and
bars
if
dumb,
but
you
have
to
read
three
or
four
things
in
51
76
to
realize
that
this
is
actually
allowed.
G
What
about
the
other
attributes?
What
about
operator
name?
What
about
as
identifier?
What
about
future
things?
So
if
you
go
to
the
next
slide,
we
probably
shouldn't
be
sending
operator
name
and
operator
nazz
identified
to
the
nads
right.
There's,
no
reason
and
again
you
have
the
issue
of
future
attribute.
So
if
you
go
to
the
next
slide,
we
need
some
text
like
this,
which
is
the
CEO.
A
proxy
must
not
send
them
as
an
attribute
in
a
co,
a
packet
unless
than
that
sent
that
attribute
in
an
access
request
or
counting
request
packet.
G
Basically,
the
radius
server,
the
co,
a
proxy
right
next
to
the
nass.
That
knows,
the
next
hop
is
an
actual
mass
and
not
another.
Radius
server
has
to
strip
out
all
the
proxy
stuff
or
all
server
attributes
must
be
removed
by
the
final
proxy
before
being
sent
to
than
as
includes
was
not
limited
to
proxy
state
operator
named
operator
in
a
site
operator
and
as
identified
there
there.
G
B
G
Ok
back
to
the
other
slide
3176
has.
All
attributes
must
be
treated
as
mandatory,
so
if
I
send
them
as
a
new
attribute,
RFC
8006
now
is
doesn't
understand
that
now,
as
bounces
the
packet
with
air
cause
unsupported
attribute
so
largely
unless
than
that
sends
you
as
the
proxy
here
an
attribute.
You
should
never
send
that
out
route
back
to
the
nest,
because
you
have
no
guarantee
that
the
nast
ever
understands
it.
K
That's
what
the
record
Diego
is
y
está
de
sudden
I
mean
these
are
choices
that
are
exclusive
right.
Oh
well,.
G
G
E
Really
really
dislike
the
first
approach
subtly,
it's
not
so
the
issue.
Isn't
it
I
think
it
would
be
very
common
that
you
might
have
related
attributes
we're
receiving
one.
An
access
request.
I'm
indicates
support
for
another
set
of
attributes
and
an
access
or
in
a
request,
so
I
would
prefer
text
it.
Basically,
the
proxy
must
not
send
an
attribute
to
the
nozzle.
E
The
attribute,
as
not
as
unless
analysis
known
to
support
the
attribute
and
NASA's
are
known
to
support
any
attribute
that
they
have
sent
to
the
in
an
access
request,
and
this
allows
us
to
in
a
future
specification,
come
along
and
say
if
you
send
the
fubar
reports
of
you
know,
you
know,
if
you
send
the
the
laser
intensity
attribute,
then
then
you
must
accept
laser
duration
in
your
co
requests.
Actually
I
guess
that
would
probably
be
an
extreme
disconnect
requests.
Sure
largely.
G
F
E
Final
yeah
I'm,
fine
with
that
I,
don't
know
from
the
second
text
I'm
talking
about
the
first
test
is
more
what
we
actually
want
to
say.
I
just
have
the
nitpick
about
sure
about.
Actually
there
are
other
ways
you
could
know
that
the
nasa
so
going
to
support
an
attribute
other
amenities
sent
that
specific
answer
it
so.
G
A
So
for
what
it's
worth,
I
also
support
the
second
approach.
More
because,
first
of
all
this
year
a
proxy
was
not
necessary
in
the
path
of
seeing
the
access
request
because
it
might
have
gone
elsewhere.
So
it
doesn't
know
what
it
has
to
figure
out
and
also
I'm
wondering
what
the
actual
originating
co
a
server
tries
to
send
an
attribute,
and
the
proxy
didn't
see
this
in
the
request.
How
could
it
and
then
it
is
false
to
take
it
away
from
right,
so.
G
E
Stefan
has
just
sold
me
on
the
second
approach
and
here's
why
the
first
approach
is
effectively
when,
in
my
mind,
what
the
first
approach
is
saying
is
51
76
was
wrong,
we're
going
to
try
and
patch
it
up
in
the
proxies.
We
actually
really
wish
these
attributes
weren't
mandatory
and
we're
going
to
let
the
proxies
patch
it
up
and-
and
you
know,
basically
go
remove
the
attributes
so
that
the
Nats
will
never
see
anything
that
will
confuse.
It
usually
support
a
little
gnat.
E
The
problem
I
have
with
this
is
that
you
know
if
51
76
is
wrong.
This
is
all
experimental
back
fix
it
and
say
you
know.
Nasa's
in
the
future
should
ignore
unknown
attributes.
E
Understand
that
there
are
a
lot
of
Nessus
out
that
they
don't
do
that
yet,
but
I
actually
not
sure,
but
if
you
176
is
being
reasonable,
then
the
first
approach
here
actually
denies
criticality
I
mean
basically
the
point
of
having
critical
attributes
is
so
that
you
don't
have
a
request
acted
on
if
they
can't
be
understood
and
basically
what
you're
trying
to
do
is
you're
changing
that
around.
In
a
case
where
there's
proxies
basically
and
you're
you're
making
the
protocol
have
different
behavior
in
the
proxy
keys
in
the
non-toxic,
but
not
not.
G
G
Shouldn't
strip
it
either.
Well
that
that's
the
thing
right,
we
definitely
need
some
text
to
say
that
that
all
of
the
intermediate
proxies
have
no
idea
what
the
nasm
plement
and
should
be
forwarding
back.
No.
G
E
G
G
A
A
Okay,
we
should
be
hurrying
a
bit
service
is
a
50-second
announcement.
Also,
we
had
plans
to
update
our
6014
6614
from
experimenting
standards
track.
That
is,
radio
server
dns
it's
my
document.
It
also
needs
text
updates,
so
somebody
has
to
edit
it.
Of
course
I
could
do
that,
but
being
a
chair
ideally
chest,
don't
do
too
much
work
on
their
own.
A
A
A
So
why
the
presenter
is
coming
up,
I
would
just
like
to
tell
you
that
we
have
a
decent
statement
from
the
broadband
forum.
Basically,
they
say
they're
very
interested
in
this
work.
They
want
to
reference
it
at
some
point,
so
it
should
exist
at
some
point.
M
M
Thank
you.
So
the
working
text
on
that
is
listing
all
the
attributes,
Rogers
attributes
that
are
useful
or
needed
in
the
context
of
the
BBF
architectures.
Some
of
them
are
standouts.
Although
the
VA
sees
gsl
forum
basis,
part
of
RFC
4629,
I
think,
and
others
are
in
many
dictionaries
or
many
or
few
dictionaries.
M
M
Yeah
eternal
max
session
specify
the
maximum
number
of
sessions
for
the
given
tunnel,
the
tunnel
profile
name
for
the
profile
to
be
applying
for
vista
forgiven
subscriber
the
tunnel
terminate
which
specifies
the
disconnect
code
when
of
the
tunnel
is
disconnected
for
services
service,
name
on
the
activates
of
this
name
for
activating
or
deactivating
services
on
service
accounting,
to
specify
whether
accounting
for
a
given
service
as
to
be
unable
or
not,
could
go
on.
Thank
you.
M
So
now
we
posted
on
in
early
July
revision
00,
it's
not
very.
It
has
to
be
completed,
or
at
least
enhanced,
so
force
you
to
do
this.
You
know
revision
01
on
renal
will
be
happy
to
have
the
help
of
radix
22
to
make
a
revision
to
which
would
be
ready
for
adoption
as
working
group
document.
This
is
what
we
would
like
to.
A
M
A
A
With
all
the
VSS
I
mean,
we've
been
burnt
and
radios
with
the
MSM
PPE
encryption
attributes
which
are
vs
ice
from
Microsoft
used
by
everybody
boo'd
as
Wi-Fi,
and
it
would
be
pretty
much
insane
to
say.
Okay,
we
stopped
using
vs
is
now
we
define
a
new
IDF
style
attribute.
This
just
doesn't
work
so
do
we
have
a
migration
strategy?
And
what
do
you
want
to
achieve.
M
G
There
is
precedent
for
something
like
this:
46
79
is
a
dsl
forum
vendor
specific
attributes,
it's
informational.
I
am
in
great
favor
of
something
like
that.
I
do
not
think
it
should
be
a
radix
working
group
document,
but
I
would
be
very
happy
to
work
with
the
vendors
to
do
reviews
whatever
and
publish
it
as
an
informational
standard.
Our
informational
document
and
I
believe
that
would
be
very
positive
for
everyone
involved,
but
they
are
VSA
is.
M
I
Not
above
my
except
I
mean,
if
you
want
to
publish
them,
publish
it
like
46
79
is
another
informational
document
document
it
and
just
if
people
want
to
use
them,
they
use
them.
Standardizing
implies
changing
them,
which
is
not
going
to
help
interoperability.
So
you
know
it
I,
don't
see
any
value
in
creating
a
standard
just
documented
and
have
an
informational
document.
Radix
can
review
it
be
done.
E
Sam,
let's
see
where's
the
Oh
Sam
harbin
yeah
I
mean
like
if
the
BBF
or
anyone
wants
to
say.
If
anyone
who
has
control
these
attributes
wants
to
try
and
let
people
know
about
them
more
widely,
so
that
they
can
be
used
more
widely.
That's
great.
All
right
that
can
be
done
in
an
informational
document.
I
am
all
in
favor
of
documenting
I
am
against
assigning
a
new
attribute
to
replace
a
VSA
where
the
VSA
is
doing
a
fine
job
of
what
it
needs
to
do
and
the
reason
I'm
against.
E
A
But
to
be
fair,
I
did
create
the
document,
and
the
issue
with
the
BSA's
was
described
as
they
exist
in
several
variants:
they're
different
syntaxes,
different
semantics,
so
that's
bad,
but
then
again,
I
also
don't
see
how
defining
a
another
IDF
attribute
with
no
syntax
and
semantics
helps
in
that
respect.
No.
G
I
mean
if
you,
if
you
look
through
the
various
vendor
dictionaries,
you
see
the
same
stuff
appear
over
and
over
and
over
again
it
work.
It
would
be
very
good
to
have
a
neutral
body
whatever
that
is
not
the
ITF.
But
someone
going
look.
Here's
this
list
of
attributes
which
multiple
people
can
use.
They
have
to
be
V
SAS
other
than
all
the
vendors
can
just
go
in
I
believe
it
would
be
a
step
ahead.
B
So
so,
but
to
define
this
VA
say:
I
think
that
what
BBF
is
looking
for
is
a
kind
of
review
to
see
if
the
definition
so
to
define
that
they
say
if
we're
following
the
new
rules,
to
define
VSA
according
to
the
radio
space.
So
is
it
something
that
should
be
done
so
it
could
be
done
in
VBF.
But
if
BBF
is
willing
to
have
some
review
from
radix
to
help
them
to
define
them,
is
the
right
place
to
do
that
so
we're.
G
Addicts
would
be
the
people
to
review
radius
documents,
and
I
would
greatly
hope
that
other
people
doing
radius
things
would
come
to
Radek
stand,
get
reviews,
unlike
the
wimax
forum,
which
didn't
include
some
things
which
are
rather
inventive
but
obvious,
no
longer
there
anymore.
So
that's
a
separate
issue.
Okay,.
J
B
At
least
for
the
timing,
so
we
could
say
that
so
people
we
may
review
the
documents.
One
possible
output
of
the
review,
and
so
on
is
to
see
value
to
define
this
document
as
an
informational
RFC.
That
could
be
used
as
a
reference
in
BBFS
specification
and
and
to
to
have
a
review
on
points
tons
of
data
type
that
could
be
used
or
clarified
and
so
on,
and
this
can
be
done
by
a
red
x,
working
group.
A
B
F
Yeah
hi
dave
allen.
I
also
co-chair
the
architecture
committee
at
the
broadband
forum,
which
is
one
of
the
reasons
you're
seeing
me
here
today,
but
you
have
probably
have
never
seen
me
before
so
just
to
clarify
if
it
is
to
go
an
informational
RFC
with
the
suggestion
be
to
use
the
BBF.
Oh
you
I
for
the
registry
for
these
vs
a's
I,
don't
know.
I
just
want
to
be
clear
on
that:
yeah,
okay,
cool.
A
B
Just
have
one
question
for
my
so
personal
questions
that
so
I
will
raise
my
question
on
the
manganese,
but
I
think
that
it
was
the
same
issue
at
the
beginning.
With
the
wireless
LAN
attributes,
lots
of
va,
ça
attributes
were
created
and
I
was
wondering
why
this
kind
of
why
the
conclusion
was
to
have
this
as
standard
one,
for
instance,
the
SSID
essid
are
so
every
single
82,
not
not
everything,
but
a
lot
of
the
not
a
lot.
Some
of
the
attributes
defined
for
where
your
salon
was
already
defined
eyes.
Vs,
a
no
okay.
F
I
A
Okay:
this
was
the
last
item
on
the
agenda
and
oh
yeah.
I
don't
want
the
tubes,
that's
all
time
a
bit
more.
Yes,.
G
Who,
who
weren't
aware
I
mean
Lionel,
had
sent
a
message
to
the
radix
list
about
the
ops
area
working
group
had
a
request
to
add
tack
acts
as
a
tech
x
plus
as
a
standard
protocol.
I've
gone
down
to
the
ops
area.
The
previous
meeting
and
the
feedback
from
the
people
involved
were
multiple
people
have
implemented,
tak
acts
completely
differently
and
not
interoperable
II.
Therefore
we
need
a
standard
and
tactics
does
command
authorization
and
radius.
Dozen.
G
Therefore,
we
need
another
protocol
and
the
feedback
that
the
vendors
were
refusing
to
implement
command
authorization
and
radius,
that
the
response
was
officially
la
lalala
lalala.
So
if
anyone
has
opinions
on
that,
I
would
suggest
joining
ops
area
and
telling
me
very
politely
what
your
opinion.
Sorry.
I
know
I
know
what
mine
are.
I
was
very
polite.
My
I
was
very
polite
I,
you
know
if
they
want
to
publish
an
informational
draft,
knock
yourself
out.
I
have
no
idea
why
it
needs
to
be
standardized
firmly
Thank
You
Diego,
for
that
exactly
okay,.
B
So
this
week,
so
this
will
be
discussed
on
the
ops
area
where
are
well
oops
working
with
language,
so
please
be
active
on
this
area,
especially
regarding
the
way
forward
for
tactics
please.
So
this
is
the
end
of
this
session,
sorry
to
be
late,
but
I
guess
it
was
a
good
one
thanks
a
lot
and
hope
to
see
a
lot
of
email
exchange
in
the
red
X
mailing
list.
Thank
you.