►
From YouTube: IETF114 MADINAS 20220728 2000
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Not
well,
I
guess
you
are
all
familiar
with
the
noteworld.
In
any
case
you,
if
you
are
not
familiar
with
the
idea
procedures,
please
check
the
relevant
documents,
how
we
should
deal
with
ipr
and
how
we
should
deal
with
any
other
things
or
other
things
in
regarding
the
the
way
we
work
at
atf.
B
Regarding
itf,
this
meeting
some
tips,
you
need
to
join
the
mythical
client,
either
from
your
computer
or
from
your
mobile
to
record
your
presence.
So
the
blue
sheets
are
automatically
filled
with
your
when
you
log
into
the
into
the
mythical
you
have
to
use
also
the
mythical
to
join
the
queue.
Even
if
you
are
here
locally
in
philadelphia
and,
of
course,
if
you
are
using
a
mythical
site,
you
have
to
keep
the
audio
and
video
off
while
using
the
outside
version.
B
B
B
A
few
reminders
minutes
are
taken.
Thank
you,
michael
for,
for
taking
some
notes.
I
will
appreciate
if
more
people
can
join
the
the
note
taking
tool.
I
think
it's
easier
if
more
people
are
there
to
to
ensure
that
we
collect
appropriately
all
the
actions
and
agreements
a
reminder.
This
meeting
is
being
recorded.
B
C
B
B
Then
I
will
briefly
update
also
on
the
status
of
the
mac
address
randomization
current
state
of
the
first
draft,
then
we'll
switch
to
jerome
for
an
update
on
the
use
cases
and
problem
statement
draft.
These
are
the
two
working
group
guide
group
items
that
we
have
at
this
at
this
point,
then
we
will
have
some
short
updates
or
or
news
on
a
roaming
experiment,
open
roaming
experiments
that
is
planned
that
has
been
explored
with
the
wba,
then
some
next
steps
and
time
per
million.
Hopefully
there
will
be
time
for
that.
B
B
If
not,
let
me
just
quickly
do
a
well.
I
we
already
sent
an
email
about
this.
We
are
starting
to
use
github,
so
we
have
the
github
organization
created
according
to
the
rfsc,
so
we
have
one
now
for
the
madinas
you
can
get
to
that
into
the
madina's
data
tracker
information
page
there
is
there
a
link
for
the
additional
resources
and
there
is
the
the
github
organization
there
and
if
you
go
there,
you'll
see
that
there
are
a
couple
of
repositories.
B
One
per
working
group
document
that
we
will
be
using
as
nfc
88
74
recommends
so
basically
we'll
use
that
to
keep
the
documents
and
manage
the
the
issues
and
editorial
recommendations
from
the
working
group.
B
This
is
a
learning
process.
I
mean
I
I
have
been
using
github,
but
I'm
not
an
expert.
I
I
not
expect
all
the
people
in
the
working
hood
to
be
experts
on
how
to
use
github,
but
I
think
it's
a
good
tool
to
keep
track
of
the
the
text,
suggestions
and
recommendations,
but
it's
also
important
that
we
will
be
using
or
keep
using
the
mailing
list
for
the
actual
discussion.
So
we
are
not
moving
the
discussion
to
the
github.
It's
not
the
purpose.
B
The
github
is
an
additional
tool
to
facilitate
keeping
track
of
some
editorial
issues
and
and
providing
text
in
a
way
that
is
easier
for
the
editors
to
to
manage,
but
it
should
be
a
tool
to
facilitate
things,
not
too
complicated,
of
course,
and
the
discussion
should
be
keep
kept
on
the
on
the
mainly
list.
Any
comments,
any.
B
B
D
So
this
is
an
update
from
the
ie80211
meeting
that
I
was
able
to
attend
a
couple
of
weeks
ago
in
montreal,
and
I
think
it
was
important
to
to
remind
people
and
give
an
update
about
the
the
work
in
w
and
11
bh
and
bi,
especially
bh.
D
So
11bh
has
is
discussing
some
use
cases
where
they
may
need
some
identifiers.
Some
new
identifiers
now
that
they
cannot
rely
on
on
random
mac,
addresses
any
longer
and
they
are
mainly
going
around.
I
t
support
and
captive
portal
type
of
use
cases.
D
So,
as
you
remember
remind
me,
sorry,
as
you
remember
from
the
last
discussion,
the
the
group's
still
discussing
the
three
general
directions.
D
The
first
one
is
when
an
sta
or
a
station,
a
mobile
in
this
case,
generates
a
layer,
2
id
and
passes
it
on
to
the
ap
after
association
through
secure
tunnel
and
then
for
tell
the
for
tells
ap
if,
if
the
id
is
changing
in
the
future,
the
second
approach
is
for
the
ap
to
generate
this
id
or
the
network
to
generate
the
id
and
pass
it
to
the
to
the
station
after
association.
D
And
then
the
sda
will
signal
whenever
there's
a
new
association
so
that
the
ap
can
generate
a
new
one,
and
the
third
approach
is
to
exchange
keys,
allowing
common
computation
of
this
id
so
that
both
know
who
they
are
talking
to.
And
the
group
still
discussing
these
three
approaches.
There
is,
of
course,
pros
and
cons
and
different
points
of
view
regarding
these
three
approaches,
but
but
anyway,
I
think
this
is
something
that
we
need
to
keep
in
mind
in
our
future
discussions.
D
D
This
group
is
not
looking
at
new
identifiers,
but
rather
examining
what
elements
may
have
an
impact
on
privacy
and
how
can
they
be
better
protected
in
in
this
case
they
are
talking
about
obsoleting,
key
identifiers
in
resolutions,
reducing
the
fingerprint
exposure
because
of
multiple
options
in
pro
messages
and
ies,
etc.
D
So
it's
it's
interesting,
but
not,
I
think,
as
impactful
as
11bh.
Something
that
we
may
want
to
keep
in
mind
is
to
to
continue
this
discussion.
So
far,
we've
been
having
these
updates
here
about
what's
going
on
in
11,
but
they
are
less
aware
of
what
we
plan
to
do
in
madinas
or
what
we
are
looking
at
in
martinez
and
the
relationships
that
we
are
establishing
and
having
with
wba,
etc
wfa.
C
E
Looks
like
michael
beat
me
to
the
queue.
Why
don't
you
go
ahead.
E
My
question
was,
I
think,
if
you
go
back
one
slide,
it
said
after
association
was:
was
there
any
have
people
given
up
on
what
you
do
about
mac
addresses
randomization
during
scanning?
Maybe
just
accepting
that
it's
going
to
be
random
when
they
scan
or
is,
is
eight
or
two
eleven
worried
about.
D
I
I'll,
I
think
I
can
well
I'll,
take
a
start
and
then
maybe
jerome.
I
think
sean
lankan
can
help
me
out
here,
but
I
believe
yeah.
The
group
is,
it's
mainly
concentrating
on
on
ones
you
have
already
associated
and
for
the
for
the
scanning
part.
We
assume
that
that
it's
going
to
be
a
random
address,
but
I
don't
know
jerome.
Can
you
give
more
info.
F
Yes,
so
yeah
absolutely
so
there
are
two
two
elements
right.
There
is
the
scanning
part
and
there
is
the
pre-association
part
and
they
they
make
the
difference
during
scanning.
You
know
you're
just
discovering
the
environment,
so
they
are
not
looking
at
trying
to
give
an.
F
To
somebody
who's
just
discovering,
so
that
is
going
to
stay,
at
least
in
the
intent
of
the
group,
completely
private
and
therefore
randomized.
However,
they
are
heavily
debating
right
now,
what
they
call
pre-association,
steering
where,
for
example,
you
want
to
have
an
iot
device
go
to
2.4
and
your
your
arvr
stuff
go
to
6
gigahertz,
which
means
that
the
ap
needs
to
be
somehow
able
to
identify
what
kind
of
devices
discovery
network
to
direct
this
device
accordingly
and
for
now
there
are.
F
There
are
two
plans,
you
know
those
that
say:
it's
pre-association,
you
don't
touch
it
and
those
who
say
you
need
to
provide
a
better
experience.
Therefore,
you
need
to
direct
correctly
there's.
You
need
to
know
something
they
are
in
the
middle
of
that
conversation.
It's
been
going
on
for
about
two
and
a
half
months.
Now
I
expect
a
few
more
months
of
a
heavy
battle.
E
That
makes
sense.
Thank
you
very
much.
C
A
Michael
richardson,
on
the
same
slide.
A
This
just
sounds
an
absolutely
terrible
idea.
I
guess
someone
at
the
ieee
thinks
that
access
points
run
captive
portals
because
that's
usually
not
the
case.
They're,
usually
the
captive
portal
in
the
layer,
two
architecture
behind
a
whole
bunch
of
access
points,
so
mostly
the
ieee
doesn't
own
the
protocol
behind
that
it's
mostly
proprietary
and
the
ietf
owns
the
captive
portal
api.
A
So
I
don't
think
this
is
a
good
place
or
good
group
to
do
this
kind
of
work
at
the
ieee.
I
think
that's
again
the
ieee
believing
that
there
are
protocols
other
than
ip,
which
there
aren't
anymore.
A
If
someone's
running
decknet
over
wi-fi,
then
maybe
this
applies,
but
I
mean
I
just
I
just
don't
see
them.
This
is
just
a
whole
bunch
of
work
to
me
that
I
don't.
I
don't
know
why
this
thing,
I
don't
know
how
to
how
to
express
the
fact,
the
frustration
of
of
this
kind
of
direction
to
me.
Okay,
this
is
not
useful.
A
So
anyway,
I
don't
know
how
to
get
this
eric,
some
more
clear
liaison
going
on,
because
I
think
this
is
a
disaster.
I
think
it's
undeployable.
It's
an
undeployable
disaster
and
the
people
that
aren't
going
to
be
able
to
deploy
it
don't
go
to
the
iti
ieee
to
speak
up
to
say
that
this
is
undeployable.
D
Okay,
thanks
for
the
for
the
comment
yeah
indeed
I
I
think
that,
at
least
from
my
point
of
view,
they
are
missing
some
information
about
what's
going
on
here
and
it
wouldn't
hurt
to
to
open
up
the
channel
and
again
jerome.
I
don't
know
if
you
want
to
add
something
since
you've
been
more
active
in
v8.
F
Yeah
I
mean
I,
I
fully
agree
with
all
the
comments
that
were
made,
but
just
for
clarity,
what
what
bh
par,
also
goal
or
or
framework
is,
is
what
was
working
before
that
is
broken.
Now
that
rcm
is
in
place,
you
know
randomizing
choosing,
mac
addresses
and
things
they
have
noticed
that
are
broken.
Is
you
go
back
to
your
room
in
the
hotel
and
you
have
to
be
authenticated
all
the
time?
F
So
that's
because
of
that
this
on
their
charter,
it
does
not
necessarily
mean
that
they
are
going
to
produce
a
solution
clear
too,
and
you
know
the
more
liaison
we
can
send
to
them
say
well.
There
is
a
hope
that
itf
can
fix
that,
because
in
keport
for
example,
it's
not
necessarily
the
mac
address,
but
the
mac
address
is
one
of
the
items
that
can
be
used
to
identify
a
station.
So
the
more
reason
we
can
bring
to
them
to
tell
them
the
solution
will
be
will
be
brought.
F
E
Eric
lanigan,
I
I
just
wanted
to
sort
of
respond
to
michael.
I
did
not
take
from
this
slide
that
they
were
assuming
a
capture
portal
was
going
to
be
inside
of
an
ap,
but
simply
that
the
the
and,
if
and
if
carlos,
if
you
said
that,
then
I
missed
it.
But
I
took
from
this
slide
that
capture
portal
is
an
application
and
they
consider
it.
They
consider
a
repeatable
stable
mac
to
be
a
requirement
for
a
captive
portal.
H
A
Okay,
if
you
don't
also
build
a
protocol
that
spreads
that
all
to
the
control
mechanism,
the
captive
portal
enforcement
point,
which
may
be
beyond
that
and
all
the
other
access
points
that
need
to
know
that,
then
the
problem
is,
is
that
well,
you
tell
captive
access
point
one,
your
new
intended
information,
and
then
you
walk
to
the
other
room
and
then
the
other
access
point
doesn't
know
who
you
are.
So
it's
not
enough
to
do
a
protocol
between
a
station
and
an
access
point
right.
A
A
G
Eric
link,
michael,
you
know
for
sure
that
there
is
an
articley,
ietf
coordination,
mailing
recent
group
that
you
are
meeting
sometimes,
if
not
mistaken,
you
are
part
of
it.
Even
so
there's
something
to
be.
Maybe
I
want
to
say
escalated
and
it'd,
be
too
strong
a
world,
but
at
least
mentioned.
B
B
So
well
again,
just
a
quick
recap
on
the
on
the
introduction
on
goals.
So
well
we
know
how
madina's
or
why
madinah
was
chartered,
and
the
goal
of
this
draft
is
basically
to
document
what
are
the
different
efforts
and
activities
that
are
being
done
on
itf
ieee
mobile
os
vendors
of
aba
regarding
the
bank
address
randomization.
B
This
is
the
table
of
contents.
It's
the
same
that
that
we
had
in
the
in
the
previous
version
and
I'm
I'm
highlighting
their
section,
seven,
which
is
basically
documenting
what
the
mainstream
or
operating
systems
are
doing
regarding
random
address
micro,
random
mac
address
and
how
they
use
them,
and
we
discussed
this
in
the
previous
meeting.
B
So
let's
try
how
it
works,
and
I
would
appreciate
if
you
detect
any
content
that
is
not
accurate.
We
already
have
some
comments
in
the
previous
version,
pointing
at
pointing
us
to
some
things
that
we
need
to
modify
since
this
is
live.
If
you
see
anything,
you
can
either
contact
us
mainly
list
get
pull
requests,
whatever
you
think,
to
keep
the
document
updated
and
as
complete
as
we
think
is
needed,
then
just
a
quick
summary
of
the
different
parts
of
the
document.
We
have
one
part
regarding
the
activities
of
the
at
the
itf.
B
B
C
This
is
daniel
gilmore.
Sorry,
I
didn't
press
the
button.
I
I
my
link
is
not
great,
so
I'm
not
sure
that
I
understand
the
goal
of
moving
the
section
all
the
way
to
the
to
github
instead
of
having
a
point
in
time
and
a
link
to
github
is
the
idea
that,
when
this
is
published,
is
the
intent
to
publish
this
as
an
rfc.
C
B
The
idea
is
that,
as
we
can
publish
that
at
some
point
in
the
time
and
things
may
evolve,
we
have
some
part
of
the
document
or
some
part
linked
to
the
document
that
can
evolve
so.
C
G
G
A
Michael
richardson,
so
what
I
would
like
to
see-
and
I
propose
to
pull
a
request
against
this
github-
the
document
in
the
github
is
that
we
come
up
with
a
set
of
standardized
terminology,
a
taxonomy
of
the
different
mechanisms
I
don't
want
to
describe.
You
know
the
thing
that
android
does
in
2019.
A
I
want
to
give
it
a
name:
okay
and
then
it
simply
becomes
a
question
of
of
you
know:
labeling
each
thing
and
you
know
version
whatever
blah
blah
blah.
You
know
and
and
that's
it
and
we
should
have.
We
should
have
you
know
that,
should
you
know
get
home,
people
can
do
an
update
and
we
might
revise
the
document
at
some
point
and
pull
in
another
snapshot
or
something
like
that.
A
But
to
me
we
should
be
arguing
about
the
taxonomy
and
we
should
be
figuring
out
whether
there's
something
we've
missed
something
that
someone's
thinking
of
doing
but
thought
was
a
bad
idea
or
something
even
something
that
someone
tried
and
turned
out
to
be
a
bad
idea
right.
So
we
can
give
it
a
name
and
actually
say:
okay,
don't
do
that
or
only
do
it
in
this
environment.
A
F
Thank
you,
hello,
everyone,
so
this
is
updates
on
the.
C
F
Document
that
we've
been
working
on,
which
is
the
use
case
document
and
as
you
you
may
remember,
by
the
way,
this
is
the
link
to
the
document
as
it
is
posted
now.
F
What
this
document
was
about
is
to
try
to
create
a
framework
around
the
conversations
exactly
to
michael's
point
a
second
ago
about
putting
names
on
different
concepts,
we're
manipulating
and
looking
at
the
landscape
of
what's
happening
around
this
rcm
and
identification,
and
it's
of
course,
as
you,
you
may
remember,
a
little
bit
complicated
because
there
are
multiple
type
of
devices
type
of
actors.
You
know
from
those
who
observe
those
who
act,
the
network,
operators
etc
and
also
different
types
of
environment
from
home
to
enterprise,
to
public
venues,
etc.
F
So
what
this
document
does
is
to
list
these
different
elements
that
act
together
and
try
to
define
some
use
cases
where
rcm
is
encountered
and
to
do
so.
We
also
try
to
establish
a
trust
variable,
which
is,
you
know,
typically
never
set
to
full
trust,
but
has
a
range
of
distrust
now
depending
on
environment
and
who
may
be
observing
the
other
communications.
F
So
we've
been
I'm
very
short
on
this
because
we've
been
discussing
this
document
for
for
a
while.
Now
we
stopped
last
time
at
v1
when
we
moved
that
document
from
a
contribution
into
a
document
that
the
group
has
adopted
and
in
v2.
What
we
wanted
to
do
when
that
document
is
posted
now
is
to
look
at
some
solutions
that
we
may
see
in
the
industry
to
address
use
cases
around
rcm
and
identification.
F
F
I've
put
them
here,
so
you
can
go
back
to
them
and
read
them
as
you
prepare
questions
or
as
you
review
this
presentation,
and
there
were
eight
of
them
primarily
and
as
we
look
into
this
document
and
we
started
looking
into
the
state
of
the
industry,
we
realized
that
some
of
these
requirements
probably
cannot
be
met
today,
for
example,
there
is
this
idea
of.
F
Let
me
go
back
to
slides
ago
on
this
first
requirement
that
says,
network
should
not
make
any
assumption
about
the
client
mac
address
persistence,
which
means
that
the
change
that
mac
address
can
change
at
any
time
today,
for
example,
in
the
802.11
structure,
this
is
not
allowed.
You
cannot
change
your
mac
address
and
maintain
a
session.
That's
going
to
go
away.
F
However,
we
know
that
one
of
the
two
groups
that
juan
carlos
mentioned
a27bi
is
looking
at
this
idea
of
session
continuity,
while
the
mac
address
is
changing
so
that
type
of
requirement
might
you
know,
get
onto
a
new
life.
As
you
know,
progress
is
made
in
that
group.
However,
some
other
of
the
requirements
we
think
have
already
been
thought
about,
or
or
looked
into
by
some
elements
of
the
market.
You
may
recall
that
in
the
previous
meeting
we
had
wba
liaison
telling
us
about
a
white
paper.
F
They
wrote
about
some
scenarios
where
identification
would
be
possible
needed
or
not
wanted
in
particular
one
one
thing
they
were
addressing,
that
we
thought
would
be
a
very
useful.
Is
this
idea
that
you
could
have
an
association
that
could
protect
the
identity
of
the
user
during
which
you
know
the
mac
address
will
not
play
any
important
role
anymore
now,
you
know
not
abstain.
You
know
even
bi,
of
course,
and
that
would
be
simply
because
it
would
be
protected.
You
know
the
connection
would
be
protected
by
identification
of
the
user.
F
Not
you
know
necessarily
the
device
itself
and
the
link
to
the
access
point
would
be
protected
and
encrypted.
One
such
protocol
is,
of
course,
you
know
something.
We
know
it's
1x
or
pa2.pa
3.,
but
they
were
also
mentioning
an
interesting
standard
that
they
have
been
pushing
for
a
couple
of
years
now,
which
is
called
open
roaming,
by
which
a
a
user
can
connect
to
a
network
stay
anonymous
to
that
network,
while
still
being
authenticated
to
a
third-party
authentication
authority
which
merely
returns
to
the
local
menu.
F
This
user
is
valid,
although
you
don't
know
his
data
is
detailed,
so
this
user
is
valid,
allowing
those
you
know
the
user
to
be
connecting,
while,
still
being
you
know,
private
to
the
visa
video.
F
In
that
scenario,
of
course,
there
is
a
sort
of
a
possibility
of
traceability
when
need
be
because
we
know
who
is
the
authentication
authority,
but
the
user
identity
itself
will
not
be
exposed,
the
mac
address
itself
becomes
irrelevant
and
therefore
the
rotation
would
become
possible.
You
know
either
through
disconnection
or
reconnection,
which
is
what
would
happen
today
or
you
know
if
11bi
concludes
on
its
work
with
a
continuity
of
of
session.
So
that's
a
one
element
that
we
thought
could
be
useful
to
our
use
cases.
F
So,
in
the
new
version
v02
of
this
document,
we
have
a
little
section
that
describes
the
solution
and
you
know
how
we
couldn't
tell
in
the
different
scenarios
that
we
were
exploring
the
document.
This
is,
of
course,
just
one.
You
know.
We
think
that
there
are
plenty
of
other
standards
that
could
be
useful
for
us
plenty
of
rfcs.
F
That
could
be
useful
for
us
to
explore,
in
particular
in
the
world
of
dhep,
eep
reduce
and
some
others
where
it
may
be,
that
some
identifiers
are
sent,
and
these
identifiers
may
be
identifiers
of
the
station
or
the
user.
It
could
be
interesting
to
look
a
little
bit
deeper
into
how
these
intersect
with
these
requirements
that
we
have
at
the
end
of
the
document.
So
I
would
like
you
know
to
encourage
you
to
to
look
at
this
document
again,
especially
the
last
section
as
it's.
What
is
new?
F
We
also
corrected
a
couple
of
typos,
but
the
main
thing
is
the
this
new
section,
and
you
know,
provide
feedback
here
on
the
list
or
or
to
us,
the
authors
so
that
we
can
continue
making
progress
in
looking
into
the
landscape
and
and
looking
at
what
solutions
are
available.
B
H
D
So
open
roaming,
as
you
may
know,
is
this
technology
that
is
based
on
passport
that
allows
wi-fi
to
connect
to
a
to
a
new
network
without
necessarily
providing
the
for
the
user,
providing
the
the
the
the
password
every
time
or
or
or
requesting
credentials,
etc,
but
rather
that
the
the
authentication
authorization
is
done
through
passpoint,
just
like,
like
eduroam,
would
work,
for
instance,
or
other
scenarios
where
you
know
the
user
beforehand.
D
So
in
this
case
the
wba
is
putting
in
place
this
federation
that
allows
multiple
identity
providers
to
use
different
network
providers,
and
then
the
users
can
connect
to
two
new
networks
by
just
having
an
authenticated
exchange
with
the
with
the
identity
provider.
D
So
this
is,
of
course,
something
relevant
to
to
us
because
it
does
not
rely
on
the
mac
address
randomization
and
it
uses
both
ieee
802
and
itf
standards
already.
D
So
this
is
something
that
we
would
like
to
explore
to
see.
First
of
all,
how
how
robust
it
is
and
then
how
much
we
can
rely
on
it
for
for
the
use
cases
that
we're
discussing
so
seems
relevant
to
to
have
something
to
try
at
at
an
ietf
meeting
hands-on,
and
for
that
reason
we
were
discussing
the
possibility
of
running
it
at
an
upcoming
meeting
that
could
be
london
or
some
other
meeting
to
give
you
an
idea.
D
This
is
the
the
slide
that
they
they
provided
were
where
you
have
on
the
on
the
left
hand,
side
the
open
roaming,
identity
providers,
which
could
be,
of
course,
a
service
provider,
but
could
also
be
a
you
know,
a
mobile
operator,
a
cable
operator,
an
isp
or
some
other
cloud
provider,
for
instance,
or
even
a
goods
provider.
D
You
know,
so
it
could
be
your
car,
your
best,
your
preferred
coffee
shop
or
you
could
be
the
one
that
is
hosting
your
your
information
in
the
cloud
and
on
the
right
hand,
side
is
the
network
providers,
which
are
the
ones
deploying
the
actual
access
points.
So
in
the
middle
we
have
this
open
roaming
infrastructure
that
allows
to
exchange
these
credentials
with
1x
and
then
be
authenticated.
D
So
for
the
experiment,
what
we
would
like
to
do
is,
of
course,
use
the
idf
network
on
one
hand
and
perhaps
rely
on
idf
as
an
identity
provider,
besides
of
course
existing
ones.
But
for
that,
because
ietf
is
aware
and
well
known
for
for
the
usage
of
of
the
network,
the
access
network,
and
also
we
already
have
some
infrastructure
in
place
through
data
tracker,
for
instance,
to
identify
users
sounds
like
this
could
be
an
interesting
experiment
to
run
so
anyway.
D
Just
to
give
you
a
heads
up
that
this
discussion
is
going
on
and
we
still
have
to
boil
a
few
details
before
we
can
call
a
goal
but
better
to
to
give
you
a
heads
up
of
this
discussion.
Michael.
A
Michael
richards,
on
the
mic,
so
I
think
I
remember
once
we
tried
to
do
something
different,
but
similar
concepts
in
the
ietf
network
and
one
of
the
things
that
quite
reasonably
someone
said
is:
did
you
pass
it?
Did
you
get
an
ethics
committee
and
did
you
get
consent
and
and
people
said
oh
and
then
we
did
it
again
the
next
year,
the
next
iets
so
just
to
mention
that's
actually
something
that
we
probably
actually
have
to
do
and
in
some
jurisdictions
it's
not
not
not
optional,
really,
not
optional.
A
So,
just
something
not
to
forget
that
yeah,
we
think
we
can
do
experiments
on
ourselves,
but
we
still
need
to
ask
for
consent
and
we
need
may
need
to
actually,
particularly
for
pii.
We
may
actually
need
to
have
a
real,
clear
plan
of
what
we're
doing
with
that
thanks.
So
I'm
really
excited
to
do
it,
though,.
D
Yes,
thanks
and
indeed
part
of
the
the
discussion
was
okay:
let's
open
up
the
ietf
network
to
these
providers,
but
then,
of
course,
people
may
not
trust
the
existing
providers.
So
that's
why
we
we
started
exploring
having
ietf
itself
as
an
identity
provider
for
people
that
don't
necessarily
have
a
relationship
or
want
to
have
a
relationship
with
the
other
providers.
D
I
I
Here
is
the
outline
of
my
presentation.
First,
let's
go
to
the
background.
I
The
goal
of
study
is
to
ensure
the
hosts
attached
to
the
scene.
That
link
cannot
prove
each
other's
idea,
justice,
without
disrupting
the
city's
legitimate
traffic
to
enable
network
operators
to
deploy
fine,
green
ipos,
address
validation
without
dependency,
supportive
functionality
or
hosts
the
service
method
was
designed
to
purely
network
perception
instance.
Enforcers
helps
the
use
of
legitimate
ips
software
address
according
to
the
following
three
step
model.
I
First,
the
first
step
is
to
identify
which
ips,
what
also
suggests
addresses
are
made
for
a
host
based
on
monitoring
package
exchanged
by
user
hosts.
The
second
one
is
to
blind:
let's
buying
a
let's
make
I
adjust
to
the
link
layer.
Property
of
the
host
network
attachment
this
property
is
called
ending.
Anchor
must
be
verifiable
in
every
package,
that
is
the
whole
system
and
harder
tools
than
the
host
ip,
so
suggested
efl
thursday.
The
third
step
is
to
enforce
that
ips
address
in
package
the
and
the
anchors
to
which
they
were
bound.
I
And
this
is
a
high-level
overview
of
the
study
for
wireless
lan.
The
bending
anchor
in
savvy
blue
land
is
mac
address,
which
should
be
secured
by
dot,
11i
and
or
other
mechanisms
when
the
user
configures
an
ip
address.
The
access
point
and
the
access
controller
perform
address
assignment
smoking
for
you,
for
example,
through
duplicate
class
detection
or
the
dhcp
procedure,
then
the
access
point,
synchronizes
nav
mac
and
ip
addresses
through
cap
web
extension
with
access
controller
and
the
access
controller
confirms
the
legitimacy
of
demanding
entries
when
receiving
packages
from
the
user
device.
I
I
There
are
two
data
structures
used
in
wlan,
the
first
one
is
mac
mapping
table
and
this
table
maps
ip
addresses
to
their
corresponding
mac
addresses
and
it
is
used
in
the
control
process
and
ipl
address
can
have
only
one
corresponding
mega
address.
Different
ip
addresses
can
be
mapped
to
the
same
mac
address
the
second
one
is
map
mac,
mapping
table
it
maps,
add
mac
addresses
to
the
corresponding
ip
addresses
it
is
used
for
filtering.
I
I
I
I
The
staffing
instances
instance
or
devices
snoop
the
on
the
dsdp
adjuster's
name
and
process
between
the
attached
host
and
this
server.
The
second,
the
third
one
is
slack
savvy
devices,
snoops
smoking,
duplicate,
adjust,
detection
procedure
or
adjust
resolution
procedure
between
attached,
hosts
and
neighbors.
I
There
are
three
types
of
situations
for
funding
clearing
the
first
one
is
a
host
leaves
explicitly
in
this
access
point
and
in
this
case,
all
entries
in
the
mac
ip
mapping
table
essentially
associated
with
this
mac
address
must
be
cleared.
The
second
one
is
a
dscp
release
messages
received
from
the
owner
of
the
corresponding
ip
address.
This
ip
entry
in
the
mapping
table
and
the
corresponding
entries
in
the
mac
ip
mapping
table
must
be
cleared.
The
third
one
is
a
mr
message
of
the
essays
access
controllers.
I
I
Sorry,
so
the
core
of
the
suspect,
validation
in
wireless
lan
is
to
look
up
two
tables
on
mac,
ip
mapping
table
and
ip
mac
mapping
table
to
check
whether
the
corresponding
entry
exists.
I
There
are
two
deploying
scenarios:
the
first
one
is
centralized
wireless
lan,
which
consists
of
access
points
and
access
controllers.
In
this
case,
there
are
two
types
of
filtering
cases.
The
first
one
is
ap,
perform
access
point
of
performance
filtering
in
this
case,
access
controllers
maintain
an
ip
mac
mapping
table
well
access
point,
maintains
hack
ip
mapping
table
and
perform
address
smoking.
I
I
This
slide
presents
a
mobility
solution
when
a
user
moves
to
another
access
point.
The
following
access
point
point
will
first
request
the
ip
address
corresponding
to
the
mac
address.
Of
course,
there
may
be
a
synchronization
between
access
controllers.
I
I
So
how
will
mac
address
randomization
affect
savvywm?
The
invalid
slab
randomness
addresses
are
mainly
used
for
discovering
various
networks
accessing
networks
and
communicating.
I
We
are
wondering
so
where
to
promote
this
work,
maybe
there
we
can
promote
this
work
in
madness
or
interrum
working
group,
and
we
solicit
comments
under
the
next
step.
Is
we
we
will
solid
statement,
comments
and
refine
the
draft.
I
H
H
So
again,
I'm
trying
to
understand
right,
where
exactly
is
the
validation?
That's
happening?
So
if
I
understand
correctly
you're
using
cap
extension
to
carry
something
which
says
that
okay
first
thing
you're
snooping
the
dhcp
transactions
or
dad
packets.
Based
on
that,
you
are
forming
a
relationship
between
the
ip
address
and
the
mac
address,
and
that
information
you
are
pushing
it
to
the
access
point
or
kappa.
Is
that
my
understanding,
correct.
H
I
We
can
enforce
it
in
that
access
point
the
second,
but
you
can
also
impose
it
in
access
controller
in
the
autonomous
autonomous
wireless
lan.
You
can
enforce
it
in
that
access
point.
H
E
E
E
I
So
so
you
mean
any
cash
addresses
cannot
be
supported
here.
So
your
question
is
how
savvy
double
land
supported
the
support
the
and
the
ending
has
ipv6
addresses.
E
Yeah,
I
was
wondering
because
you
can
have
the
same
ip
v6
address,
have
multiple
mac
addresses
if
the.
If
the
override
flag
is
zero.
I
So
this
is
a
quick
question.
E
E
A
I
A
C
D
D
Of
course,
the
the
it
is
relevant
to
to
the
discussions
we've
been
having,
but
because
we
are
right
now
more
at
the
at
the
survey
stage
and
gap
analysis.
I
don't
think
that
we
can
dig
into
into
this
space
this
option
space
right
now
so
now
I
would
rather
hear
a
discussion
going
to
the
mailing
list
before
we
we
derailed
too
much
the
the
scope
that
we
have
right
now.
G
Eric
think
and
sorry
for
joining
the
queue
once
it's
closed,
but
indeed
I
do
not
see
this
draft
as
becoming
or
fitting
the
charter
of
malinas.
So
the
default
thing
mostly
would
be
interior
or
perhaps
a
dispatch.
B
Next
steps,
so
I
would
like
to
in
this
two
minutes
that
we
have
for
three
minutes.
I
would
like
to
get
some
volunteers
for
reviewing
the
the
traps
that
we,
the
working
group
drafts
that
we
have.
I
already
volunteer
for
reviewing
the
use
cases
and
requirements
I
think,
in
order
to
move
along,
it
would
be
good
to
get
one
or
two
reviews
per
document.
A
A
I'd
like
to
suggest
the
chairs,
we
have
a
virtual
interim
before
london
and
that
yeah
we
need
to
do
reviews
on
the
mailing
list.
We
made
progress.
We
haven't
really
done
anything
since
the
last
itf.
So
I
think
that's
a
really
good
solution.
A
I've
read
them
all
and
I
would
like
to.
I
would
like
to
have
a
bigger
conversation
about.
What's
in
them,
there.
B
Okay
thanks:
we
we
take
note
of
that
and
we
will
discuss
with
the
idea
and
see
next
step,
but
that's
good
feedback
and
jerome
and
you
are
in
line.
I
think
one
thing
we
can
do,
meanwhile,
is
that
if
you
can
review
the
the
other
charter
item
well,
I
reviewed
yours.
I
think
we
can
benefit
from
some
cross
reviews
in
the
meantime,
if
you
don't
mind,
and
do
you
see
any
any
additional
comments
before
we
go
in
these
two
minutes.
F
D
So
so
maybe
the
the
very
last
comment,
I
think
in
michael's
point
about
an
interim-
is
a
very
good
one.
I'm
just
wondering
after
the
vacation
summer,
vacation
period
september
october,
early
october,
probably
is
a
good
time
for
me,
but
we
can
discuss.