►
From YouTube: IETF101-EMU-20180319-1550
Description
EMU meeting session at IETF101
2018/03/19 1550
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
B
C
A
Right
we'll
get
started
with
some
of
the
formalities
here,
so
welcome
to
emu
at
IETF,
101,
I'm
sure
you're
all
familiar
with
Nowell,
and
this
is
probably
a
little
bit
of
an
eye
chart,
but
you
might
actually
be
able
to
read
it
in
this
room
if
you're
not
familiar
with
it.
I
suggest
you
familiarize
yourself
with
the
rules
of
participation
here.
D
A
D
A
A
Okay,
so
we
have,
we
have
a
full
agenda
and
we'll
get
started
with
that.
Just
in
just
a
minute,
I
did
want
to
quickly
go
through
just.
There
are
particular
items
on
the
Charter
and
I
believe
we
have
presentations
that
cover
all
of
these,
which
is
an
awesome
start
to
the
working
group.
So
we
have
clarifications
of
ETLs
and
its
use
with
TLS
1.3,
and
also
some
discussion
on
how
you
know
improving
the
handling
of
large
certificate
chains.
A
There
are
some
inconsistencies
or
gaps
in
those
definitions.
We
go
back.
Somehow
I
can
go
back
on
this
thing.
We
also
have
Elliott,
leer
I,
don't
know,
I
do
see
Elliott
here
and
he
was
gonna.
You
know
pose
some
questions
to
the
group
coming
from
the
perspective
of
brewski
and
enrollments
and
that
that
sort
of
thing
and
how
deep
or
teep
might
be
involved
in
that.
A
F
G
This
means
that
significant
part
of
the
old,
a
pls
part
specification
are
no
longer
applicable,
and
that
means
built
high
level
from
how
the
message
fuse
all,
but
also
to
low
level
details
which
mess
contents.
You
have
in
the
different
messages,
but
I
think
people
definitely
want
to
use
TLS
103.
It
provides
significantly
improved
security
privacy
and
reduced
latency,
so
tillis
dropped.
Not
some
epls
update,
still
drop
was
discussions
on
the
list.
We're
not
thanks
to
Ellen
and
then
out.
Yeah,
put
many
comments
and
also
Jim
I.
Think
the
dog.
G
What
is
changed
so
here
is
an
EPT,
less
hand,
message
flow
when
you're
using
TLS
1,
let's
say
0
1
at
101
or
two.
They
all
look
the
same,
and
if
you
look
at,
if
TLS,
when
you
use
TLS
103,
it
looks
quite
different,
and
what
has
changed
is
that
you
have,
for
example,
here
in
the
client
what
the
kind
sense
you
have
different
messages.
G
G
Typically,
if
you
have
a
ticket
and
it's
valid,
you
should
do
resumption.
Typically,
if
the
ticket
is
valid,
the
server
should
accept
resumption
and
I.
Think
next
slide.
We
can
see
example
on
how
these
loops,
so
basically
here
is
the
ordinary
handshake
and
then,
after
the
client
authentication,
the
server
sends
TLS
new
session
tickle
ticket
to
the
clients.
You
get
one
additional
round-trip
there
and
then,
when
you
do
a
resumption,
it's
a
simple
TLS,
103
handshake,
but
with
PSK.
So
this
new
certificate
authentication
the
reception
questions.
G
Next
privacy
is
another
thing
that
handles
can
be
handled
very
differently.
Tls
103
increases
and
simplifies
the
privacy
by
encrypting.
A
large
part
of
the
TLS
handshake
in
earlier
versions
of
TLS
large
part
of
the
handshake
who
not
encrypted,
for
example,
is
just
certificate,
was
selling
clear
text
which
meant
that
to
use
TLS
with
privacy,
the
client
sent
an
empty
certificate
list,
and
then
you
redid
their
handshake
basically
twice
in
t
Lester's,
no
need
to
do
that.
Everything
here
in
yellow
are
always
encrypted,
including
both
the
servers
and
the
clients
certificates.
H
Bernard
Abell
from
maxsa.
The
problem,
though,
is,
if
you
don't
know
right,
and
you
start
that
then
you're
gonna
fail.
So
it's
it's
kind
of
weird
like
and
the
problem
is
yeah,
so
you're
starting
off
you
don't
really
know
whether
the
other
guy
does
you
can't.
You
can't
really
include
it.
Then
you've
kind
of
leaked,
your
identity,
and
even
if
you
come
back
right,
people
can
so
anyway,
yeah
I'm,
not
sure
how
you
solved
that,
but
that's
that's
kind
of
it.
There's
there's
a
got
you
in
there
yeah
there's
a
this.
I
Not
that
this
is
le
lire.
Sorry,
not
that
this
is
an
objection
at
this
point,
but
just
a
note
of
you
know
an
observation
which
is
if
people
are
doing
radius
proxy
functionality
and
they
need
the
information
that
are
in
the
certificates
they're
going
to
lose
that
in
1.3.
So
some
people
who
I
think
will
view
that
as
a
feature
and
some
people,
some
people
may
view
the
as
a
problem
depending
on
one's
perspective
and
I.
Just
want
to
note
that
that's
an
issue
there.
J
That's
right
just
just
to
clarify
that
I'm,
not
aware
how
you
can
do
half
the
eat
conversation
and
then
proxy
it
so
the
issues
speaking
from
this
sorry,
this
is
Alan
decock
from
radius.
The
issue
is
that,
once
you
start
the
eat
conversation
you
either
do
all
of
it
or
you
proxy.
All
of
it.
If
he
is
so
I'm
saying
is,
is
in
the
radius
layer,
you
proxy,
based
on
the
identity,
and
that
happens
no
matter
what
happens
inside,
eat
and
sort
of
looking
at
the
certificate
and
then
deciding
whether
or
not
to
proxy.
F
Yeah
yeah
I'm
also
trying
to
understand
what
the
case
actually
here
is,
and
maybe
you
guys
we're
just
speaking
past
each
other.
Are
you
idiot
suggesting
that
there's
a
like
a
EA,
Pecos
end-to-end
and
then
that's
one
of
the
proxies
in
in
path?
It's
looking
at
the
EAP
traffic,
even
inside
the
EAP
TLS
and
looking
at
the
certs.
Is
that
the
case
that
you're
thinking.
I
I'm
aware
one
use
case
where
we're
considering
doing
exactly
that,
we're
going
to
split,
essentially
different
functionality
out
and
we
don't
have
to
respond
directly,
but
if
we
have
the,
if
we
have
the
certificate
information,
we
have
enough
information
with
which
to
to
make
decisions.
That
would
then
that
might
otherwise
be
made
directly
by
the
radius
server
and
so,
and
so
there
are
a
couple
of
it's
a
fairly
involved
use
case.
I
But
having
that
information
hidden
is
going
to
close
off
some
of
those
use
cases
we
can
again,
as
I
said
it
could
be
considered
a
benefit
or
negative,
and
I
can
flesh
that
out
a
little
bit
more
over
time.
But
this
is
this
is
something
that
that
we
have
to
I.
Think
understand
a
little
bit
more
in
the
EP
use
case
is.
F
J
Just
to
try
and
close
that
out,
I
think
watching
the
traffic
and
then
proxying
or
not,
based
on
peeking
inside
of
EEP,
but
not
actually
terminating
it.
That's
I
would
say
that's
a
hard.
No,
if
you
want
to
terminate
EEP
and
then
after
you've
decided
to
authenticate
the
user,
somehow
ask
someone
else
whether
or
not
they
really
should
be
authenticated,
that's
more
possible,
but
I
would
say
that's
largely
outside
the
scope
of
EEP
and
it
can
be
possible
and
people
do
this
today.
J
G
So
the
key
hierarchies
changed
TLS
103
replaces
this
set.
A
random
function
used
in
earlier
versions
are
slightly
different
in
OneNote
one
and
one
not
to
vanity
completely,
replaces
it
with
HK
DF
and
also
completely
changes.
How
keys
are
derived
era.
Pinkas
specification
is
needed
to
avoid
normally
interoperable
implementations.
G
This
year
in
this
draft
is
to
use
the
TLS
exporter,
which
is
what
the
function
TLS
103
has
made
exactly
for
this
use
case.
This
is
what
quick
is
using
and
it's
very
simple
and
then
all
the
other.
These
are
basically
three
things
you
need,
none,
all
the
other.
Each
specific
things
can
be
derived
exactly
as
in
ETS
rc5,
t16,.
G
J
Two
tenses
that
could
probably
be
split
out
into
a
separate
document.
Cuz,
we
probably
do
want
recommendations
for
earlier
versions
of
TLS
and,
as
my
message
on
the
mailing
list
said
right,
I
mean
you
can
bloat
certificates
at
with
names,
addresses
groups,
Oh
IDs
and
that's
completely
independent
of
any
of
this,
but
there
should
be
recommendations
separate
from
1.2
and
earlier
from
1.3.
G
Of
these
I
think
so,
let's
go
through
them.
I
think
what
one
thing
is
to
use
mechanism
to
get
the
certs
all
certificates
changed
as
small
as
possible.
You
can
use
ECC
you
can,
of
course
you
can
use
less
less
number
of
CAS
and
subsea,
as
per
that
probably
have
a
architecture
that
you
want
to
use.
You
can
one
number
that
takes
quite
a
lot
in
song
certificate.
It's
subjective
alternative
names.
G
G
One
thing
that
you
can
do
in
here
less
is
to
meet
certificates,
that
you
know
that
other
end
point
a
knows
about,
or
has
access
to
and
see
less
one
or
two
and
earlier
you
can
only
omit
omit
the
top
self
signed
root
CA
in
TLS
103.
You
can
omit
any
trust
anchor,
basically
everything
except
the
service
own
certificate,
so
that
still
s103
specific.
Then
you
can
should
use
the
cached
information
extension,
that's
for
all
version
of
TLS,
and
then
you
can
use
extensions
to
reducing
the
size
of
certificates
with
compression
there's.
G
G
The
UCSB
information
is
and
inside
the
certificates
Status
Messages.
Instead,
this
means
that
you
can
send
UCSB
information
for
all
certificates
in
the
same
TLS
strengthens
confidentiality,
change,
trains
and
cryptographic
key
negotiation.
So
I
made
some
slight
updates
to
the
security
claim
section
that
applies
when
you
use
TLS
103
and
the
Cypress
suits
are
different.
Today
must
and
shoot
in.
The
earlier
versions
does
not
apply.
G
Basically,
these
services
are
not
available
so
for
this
draft,
as
they,
the
current
drought
states
that
when
you
use
TLS,
1
or
3,
you
follow
the
recommendations,
a
must
in
TLS
wanna
trick
without
changing
anything
and
for
our
version.
Of
course,
it's
or
C
2
5
2,
1
6-
that
applies
next,
so
I.
Think
of
the
discussion
on
the
list.
I
think
this
draft
is
in
a
pretty
good
shape,
would
like
even
more
feedback
and
then,
of
course,
implementations
I.
G
A
A
Ok,
so
we'll
we'll
take
it
to
the
list,
but
I
think
we'll
will
do
that,
and
certainly
we
have
a
fair
amount
of
people
reading
the
draft,
but
getting
more
reviewers
would
always
be
good
and
we
can
also
discuss
I.
Think
splitting
it
out
I
I
think.
Does
anybody
feel
we
have
to
resolve
the
splitting
out
issue
beforehand?
I
think
that's
something
we
can
do
in
the
working
group
displaying
out
the
certificate
handling
or
the
fragmentation.
F
Okay,
so
I'm
gonna
talk
about
two
drafts.
One
is
sort
of
a
bug
fix
and
you
know
I
accommodate
some
new
situations
that
existing
methods
need
to
deal
with.
Another
one
is
a
real
new
piece
of
functionality
as
well
small
piece
of
functionality
to
to
enhance
something
next
slide
and
I
mean
just
as
a
background.
F
Many
of
you
are
probably
aware
of
this
I'll
just
briefly
covered
that,
but
we
obviously
had
lots
of
work
on
EAP
in
you
know,
back
in
the
early
2000s
or
so,
and
since
then
not
much
has
happened
in
terms
of
specifications,
but
there's
been
lots
of
deployment,
and
you
know
some
of
the
users
I
think
the
implementations
of
some
of
these
technologies
are
in
the
billions
in
terms
of
you,
know
existing
smartphone
clients
and
such
uses
usage.
You
know-
maybe
not
is
at
that
quite
at
that
level,
but
but
fairly
large.
F
Nevertheless,
and
the
thing
that
you
know
in
the
in
the
past
how
these
things
were
used
for
the
EAP
seem
an
EAP,
aka
type
of
indication.
The
idea
was
that
you
could
use
operator
authentication
infrastructure,
but
you
would
still
come
in
through
like
it
when
you
would
connect
through
Wireless
land
and
then
he
would
use
EAP
and
authenticate
the
same
or
EAP
aka.
And
then,
if
you
came
through
for
G,
for
instance,
you
would
authenticate
with-
and
you
know
native
mechanisms
in
in
the
4G,
you
interface
protocol
and
that's
not
EA
P,
but
in
5g.
F
This
is
going
to
change,
so
they
will
or
they
plan
to
allow
both
EAP
and
and
this
or
older.
You
know
direct
plane
type
of
SIM
card
out
indication
on
on
the
ue
interface.
So
when
you're
coming
into
5g
network,
you
could
authenticate
directly
with
EAP
and
obviously
to
support
the
APA
ké
prime,
which
is
that
default
mechanism
there,
but
also
potentially
other
other
things
like
EAP,
TLS
and
and
so
forth,
so
that
that's
kind
of
the
motivation
of
like
what
you
know.
Why
are
we
talking
about
this?
F
So
this
first
draft,
the
RFC
54
for
a
Biss,
is
an
update
to
EAP
aka
prime,
and,
if
you
recall
so
APA
ké
was
was
the
treaty
application
protocol
and
it
was
enhanced
with
this.
In
this
prime
version
in
54,
48
2008
I
think
he
came
out
and
basically
the
the
idea
there
was
that
this
provides
better
binding
to
some
of
the
parameters
of
the
conduct
that
the
authentication
is
happening
in
and
and
and
the
draft
that
I
have
written
with
my
colleagues.
It's
a
small
update
of
of
this
APA
ké
Prime.
F
They
are
boxing
the
current
specification
things
that
we
missed
at
the
ITF
at
the
time,
or
specifying
some
behavior
for
situations
that
were
not
covered
by
by
the
old
old
specs
and
and
this
a
0-0
version
that
was
briefly
mentioned,
represented
in
in
in
the
previous
ITF,
the
zero
one
version
where
we
as
we've
worked
through.
You
know
this
in.
In
the
you
know,
in
various
places,
at
the
3gpp
and
an
ITF
and
and
elsewhere,
we
realized
that
there's
a
couple
of
other
issues.
F
Also,
then,
then,
the
one
that
was
in
zero,
zero
zero
instance
also
only
about
the
binding,
but
this
other
stuff
too
and-
and
the
idea
here
is
don't
add,
any
functionality
tests
make
sure
that
it
actually
works.
You
know,
as
the
method
has
has
been
defined
in
that,
requires
a
couple
of
tweaks
or
bug
bug
fixes,
but
we
could
obviously
update
like
security
considerations
when
we
learn
and
we've
certainly
learned
of
attacks
in
the
in
the
space
of
pervasive
surveillance,
for
instance,
that
we
could
probably
document
here.
But
but
security
conscious
is
fair
game.
F
Adding
new
new
features,
I
I
thought
would
be
bad
for
this.
This
particular
draft
next
slide.
So
the
three
updates
that
are
currently
there
and
and
since
we
have
discovered
a
few,
it
might
be
possible
that
you
know
that
the
list
of
three
grows
a
little
bit
to
four
or
five
or
something
and
I
want
to
work
with
you
guys
to
make
sure
that
we
got
got
everything
so
the
the
first
is
series
this
binding
issue,
so
the
APA
ké
binds
the
application
to
to
the
produced
keys
so
that
you
have
some
context.
F
Information
like
weird
we're
doing
this
out
indication
for
in
a
purpose
blah,
and
then
this
purpose
blah
is
defined
through
a
reference
that
the
old
RFC
points,
the
3gpp
spec.
That
has
a
table
that
you
know
if
you
were
doing
wireless
LAN
out
in
the
case
and
then
do
this
and
if
you're
doing
something
else,
didn't
then
do
that
and
so
forth
and
now
they're,
adding
essentially
a
new
new
entry
into
the
table
like
5g,
then
do
this
and
you
know
on
its
own.
F
This
is
like
we're
pointing
to
a
particular
verse
and
RFC
points,
a
particular
version
of
the
3gpp
spec
and
now
a
future
version
of
that
same
in
3gpp
spec.
It's
gonna
say
something
something
different,
so
you
could
you
know.
Perhaps
if
this
was
the
only
thing
we
could
perhaps
let
it
slide
and
not
not
update,
but
I
think
it's
actually
a
good
practice
to
like
if
we
have
an
actual
interoperability
issue.
This
would
result
in
an
interoperability
issue
that
people
do
can't
talk
to
each
other
if
they
don't
get
the
keys
right.
F
So
it's
good
to
update
specs
when
when
something
like
that
happens,
even
if
it's
in
a
reference,
because
it's
so
important
piece
here,
the
other
thing
is
kind
of
like
a
5g
3gpp
development
that
they
used
to
have
particular
types
of
identifiers.
And
now
in
the
new
architects
they
have
added
some
new
types.
So
they
have
these
temporary
identifiers
x'
and
they
have
more
permanent
identifies
and
they
play
a
different
role
than
an
identifier
has
previously
did
in
in
older
systems
or
generations
and
and
it's
important,
the
identifiers
also
goes
into
the
key
calculation.
F
So
if
they
identify
one
side,
thinks
that
the
identifier
is
a
and
the
other
side
think
it's
B,
then
that
would
be
bad
again.
So
so
we
want
to
be
absolutely
clear
that
you
shall
use
this
ideas
as
the
ID
and
there's
a
couple
of
different
answers.
It
could
be
the
actual
ID
that
you
send
on
the
EAP
communications
or
it
could
be
the
corresponding
permanent
identity
and
this
arguments
either
way.
I
F
F
So
I
would
like
to
get
get
moving
with
this
particular
graph
and-
and
the
final
thing
is
this
session
identifies
which
we've
discussed
on
the
on
the
list.
That
actually
applies
to
multiple
multiple
methods,
EAP
seaman,
a
K
and
a
K
Prime.
So
this
particular
draft
actually
fixes
that
for
EAP,
a
K
prime
as
well
yeah.
G
F
That
that's
an
excellent
question
and
we
should
we
should
figure
that
I
mean
I,
think
there
are
ways
I
mean
we
can
refer
to
the
spec
or
its
future
versions
or
whatever
you
know
suitable
language.
But
but
the
question
is:
what
do
we
want
like
then,
then?
A
future
change
of
this
nature
that
the
table,
changes
and
keys
will
be
different
and
and
nothing
in
the
RFC
indicates
that.
So,
if
that's
what
we
want,
we
can
make
that
happen,
but
it
might
not
be
I'm
not
saying
what
the
right
answer
here
is.
L
F
I
think
that's
that's
also
probably
reasonable.
It
still
doesn't
get
us
away
from,
like
somebody
has
to
update
like
not
normally
when
something
like
a
new
situation
comes
along.
Somebody
can
send
an
attribute
and
we
can
just
ignore
it,
but
this
is
very
different
because
it
actually
goes
into
key
calculation,
so
we
can't
really
ignore
it.
We
have
to
understand
it,
and
now
somebody
needs
to
signal
us
that
oh,
this
is
a
new
thing.
J
Very
soon
this
is
Alan
again
just
one
question
about
0.3
from
a
strictly
time
this
perspective.
It
may
also
be
interesting
to
just
duplicate
all
those
session
identifiers
in
the
session
identifier
document,
because
that's
really
five
paragraphs
of
text
and
implementations
are
depending
on
it
now
I
mean
it
doesn't
hurt
to
update
the
session
identifier
for
aka
Prime
in
two
places.
If
one
goes
out
in
three
months,
the
other
goes
out
in
a
you
know,
year
and
a
half,
it
might
be
easier
for
implementers
yeah.
F
F
L
Margaret
colony
and
it's
been
I,
don't
know
15
years
since
I
read
a
KA,
so
I,
don't
remember
what
the
security
considerations
say,
but
I
think
whatever
we
end
up
in
this
document
should
be
accurate.
Based
on
the
current
way.
We
assess
these
sort
of
things,
so
I
think
you
should
update
the
security
consideration
section.
F
L
A
F
The
issue
is
that
there's
been
reported
cases
of
intelligence
agencies,
stealing
large
amounts
of
you
know,
potentially
like
him
or
all
the
keys
from
a
sim
card
manufacturer
and
then,
if
they
have
those
keys
and
there's
no
perfect
forward
secrecy
that
essentially
at
any
time
they
can
look
at
the
traffic
later
and
since
this
was
discovered,
there's
been
obviously
lots
of
concern
about
it,
and
people
have
done
stuff.
They've,
taken
care
of
security
between
the
manufacturer
and
the
operator
better
they've
improved
their
processes
in
manufacturing
plans.
F
They,
you
know,
tightened
up
everything
possible,
but
still
I
mean
the
opportunity,
for
this
remains
I
mean
at
the
end
of
the
day.
You
can
you
know
hand
somebody
a
National,
Security,
Letter
or
something
and
and
they'll
have
to
comply.
So
if
we
had
some
technical
means
of
of
dealing
with
this
problem,
you'll
begin
next
slide
and.
F
F
F
It
can
probably
be
done
in
multiple
different
ways.
There's
been
some
discussion
in
3gpp
about
this
I
mean
also
about
this
doing
it
in
EAP,
but
also
some
other
other
approaches.
We
think
this
is
a
reasonable
approach,
given
that
you
know,
if
you
cover
TLS
and
PFS
and
cover
EAP
I
can
DFS
you
pretty
much
covered.
F
F
So
I'm
gonna
argue
here
that
it's
important
that
we
actually
enhance
our
protocol
to
respond
to
this
massive
attacks
by
various
organizations,
and
there
seems
to
be
demand
for
this
in
the
mobile
industry.
So
that's
good
an
opportunity
to
do
do
things
right
so
I,
because
we
like
to
argue
this
thing
to
come
to
the
working
group,
maybe
a
little
with
a
little
bit
less
urgency
than
the
previous
one
that
that
one
I
really
need
done
soon
and
and
the
coordination
thing
again
is
important
and
and
ongoing.
That's
it.
E
Hey
Aaron,
kebab
l3
radius
same
as
our
own,
so
there's
a
long-standing
issue
in
EPA
and
EPA
and
the
rest
and
that
the
department
IDs
are
revealed
the
first
time
this
up
can
authenticates
Mayfair's
appetite
for
sort
of
thing,
perfect
forward
secrecy
and
really
sort
of
stopping
state
actors
find
out
information
about
you
mean.
Is
there
any
appetite
in
fixing
that
I'm.
F
Sorry
I
completely
hear
or
understand
that
they
said
what
are
revealed
in
the
ethnic
is.
The
IMSI
number
of
the
SIM
card
is
okay,
yeah
yeah.
There
is
and
that
that's
the
thing
that
I
was
on
the
previous
presentation
talking
about
that
they
have
this
temporary
ID
and
then
then,
the
more
permanent
ID
and
now
they're
fixing
that.
C
G
F
G
A
F
Think
the
Phase
two
is
gonna
finish
a
year
from
now:
okay
I'm,
getting
that
right,
but
I
mean
I.
I
I
mean
that's
a
general
approach.
I,
don't
think
we
get
the
IETF
should,
like
necessarily
I
mean
we
should
respect
people's
timelines,
but
we
should
do
our
own
homework
that
we
have
a
protocol.
Are
we
gonna
fix
it
for
these?
In
these
reasons,
and
then
it's
available
for
people
to
use
if
they.
A
A
A
A
J
J
It
says
they
must
define
these
things
and
people
like
to
ignore
musts.
So
if
we
go
to
the
next
one,
each
session
ID
has
not
been
defined
for
fast
reification
for
sim
and
aka,
and
no
session
ID
derivation
was
defined
for
a
K,
Prime
or
peep.
The
Charter
could
probably
be
updated
to
add
a
peep.
If
we
care
I've
gone
through
a
bunch
of
the
other
eat
RFC's,
they
all
look
okay,
but
it
wouldn't
hurt
to
double-check
that
the
next
slide,
the
TLS
based
eat
methods.
J
Don't
have
this
problem,
the
cache,
the
TLS
information
you
can
always
derive
the
session
IDs
for
reification
non
TLS,
eat
methods
require
different
things,
so
this
is
I
suspect
why
it
was
missed.
I
wouldn't
be
surprised
if
a
lot
of
the
vendor
specific
eat
methods
have
similar
problems,
but
is
there
their
issue
to
fix?
Specifically,
this
is
needed
for
ERP
and
fills
for
I
Triple
E
802
11
AI
next
slide.
J
H
Are
not
about
one
way
that
you
might
consider
fixing
this
in
the
future
was
if
there
was
an
Ayane
registry,
then
basically
Ayane
would
have
checked
all
these
documents
for
the
allocations
and
made
sure
they
didn't
miss
them,
so
that
so
that
might
be
something
to
consider
as
having
this
document
establish
a
registry
populated
with
all
that
stuff
and
then
the
good
folks
at
Ayana
will
check
you
know
going
forward.
So
you
not
to
do
this
again
like
in
for
another
five
years.
Oh
they.
J
Next
slide,
so
specifically,
this
will
update
fifty
to
forty,
seven
four
and
eight
six,
four,
nine,
eight
seven,
five,
four
four
five,
two
four
seven
I
suspect
based
on
my
earlier
comment
for
a
KA
prime.
It
doesn't
hurt
to
put
the
text
in
this
document
and
I
think
it
published.
At
the
same
time,
we
can
just
delete
it
from
this
document
and
if
they
ke
Prime,
starts
being
contentious,
then
next
leg
any
questions,
hopefully
barring
Ayana
registry
updates.
This
thing
really
should
be
a
couple
of
pages.
J
I
didn't
have
time
to
get
it
done
before
ITF,
but
I'll
get
it
done
next
week
and
if
there's
no
IANA
registry
updates,
it
could
be
published
effective
immediately
so
long
as
people
review
it
and
like
it.
If
there
are
ini,
update
registries
or
an
registry
updates
that
will
take
a
little
longer,
I
suspect.
A
I
Hi
I'm,
not
as
tall
as
that,
okay,
so
I'm
Eliot,
leer
I've
been
working
on
onboarding
of
little
things.
Some
sometimes
big
things
with
a
bunch
of
people
who
are
in
the
room,
and
so
we've
been
most
of
our
stuff.
We've
been
focusing
on
in
either
ops
area
working
group
or
in
the
animal
working
group,
and
it's
all
about
a
lot
of
us
about
trusted,
introduction
and
figuring
out
what
this
thing
is
and
how
are
supposed
to
protected
from
the
network
perspective
next
likely
so
I'm
sort
of
new
to
EEP.
I
Okay,
that's
to
say
I'll,
admit
it.
I
know
very
little,
so
I
figured
I'd
come
to
the
experts
as
we
begin
to
sort
out
some
more
problems
and
there's
not
even
a
draft
yet,
for
you
know
in
terms
of
a
specification
but
we're
beginning
to
sort
ourselves
in
terms
trying
to
figure
out
not
only
the
problems
face
book
closer
to
the
solution.
Space
next
slide.
So
that's
my
way
of
saying
be
gentle.
I
So
we
have
this
fundamental
problem.
We've
actually
done
fair
amount
of
work
for
Wired
and
can
onboard
devices
that
there's
a
person
who's
not
in
a
room.
Actually
of
Michael
Richardson
who's
been
leading
a
lot
of
work
in
the
animal
working
group
to
basically
do
a
trusted
introduction
between
a
device
and
a
local
deployment
where
the
device
or
what
you
might
call
to
eat
peer
has
a
very
limited
ability
to
retain
things
like
a
certificate
store,
a
trust
root
store.
I
Maybe
they
have
one
or
two
or
three,
sir
space,
one
or
two
or
three
sorts
at
most.
They
certainly
don't
have
anything
like
what
you'd
find
in
a
browser.
Okay,
they
just
don't
have
the
space
for
that
and
to
give
you
an
idea
about
arguments
with
people
over.
You
know
using
five
to
eighty
bytes,
you
know
and
on
processor
capabilities
that
that
range
all
the
way
down
to
an
eighty,
eighty,
six
or
a
z80.
I
So
you
threw
out
that
z80
book
already
right,
guess
what
it's
all
back,
so
we
sort
of
sorted
us
as
I
mentioned
for
wireless,
but
for
for
wired,
but
for
wireless
we
have
a
couple
of
problems,
only
some
of
which
are
this
organization's
issue,
and
it's
really
goes
like
this.
We've
divined,
this
wonderful
flow.
That
says
you
know.
I
Let's
do
this
little
dance
with
nice,
little
restful
interface
between
the
device
and
the
local
deployment,
which
we
call
a
registrar
here
and
the
local
deployment
and
the
manufacturer,
which
isn't
a
somewhat
optional
step
to
say:
let's
let
that
manufacturer
do
a
trust
and
introduction
for
the
device
and
then
the
local
deployment,
this
really
nice
and,
of
course,
to
do
that.
Little
dance
you
sort
of
have
to
have
some
connectivity
to
the
device.
I
But
if
you're
on
a
wireless
network
within
802
11
network,
you
have
a
very
limited
connectivity
and
probably
no
IP
connectivity
until
you
have
credentials.
So
it's
a
little
bit
of
a
chicken
and
egg
problem
and
so
we're
trying
to
sort
out
to
break
out
from
the
chicken
and
egg
problem.
And
there
are
a
couple
different
ways
to
do
this-
that
we're
sort
of
exploring
and
there's
a
draft
and
I'll
point
get
it
later
so
just
mentioned.
You
know
what
the
problem
space
looks
like
and
so
802
11.
I
You
know
in
terms
of
doing
network
identifications
the
82
to
11
AQ,
we're
not
entirely
thrilled
with
that
either,
as
it
turns
out
the
we're
pondering
using
t
p--
to
do
this,
which
is
why
I'm
here
and
just
to
get
at
least
to
get
the
to
identify
the
right
network,
we're
thinking
of
doing
something
with
device
provisioning
protocol
which
is
work
being
done
on
Wi-Fi
Alliance.
Again,
that's
not
something
we
have
to
worry
about
here
and
we.
I
We
are
pondering
the
use
case
where
you
know
you
have
an
ETL
s
based
mechanism,
and
maybe
you
have
other
eep
methods
as
well
and
we're
not
really
far
along
with
other
methods,
but
we
started
with
an
ETL
s.
Use
case
next
slide,
please
so
here's
my
understanding
of
teef.
You
have
sort
of
an
outer
TLS
communication.
This
work
that
many
that
was
probably
done
in
this
working
group.
You
have
an
outer
TLS,
which
you
can
defer
the
authentication
endpoints
until
until
just
before
your
you're
ready
to
send
back
and
each
success.
I
You
have
something
of
an
inner
and
you
can
use
all
these
lovely
methods
inside
that
that
nice
wrapping,
which
we
like
you,
have
an
est
like
enrollment
mechanism
and
you
have
a
ability
to
get
back
trusted
server
routes.
This
is
all
good
stuff.
One
thing
you
just
lack
is
this
trust
instruction,
so
we
want
to
do
an
extension
for
it,
for
the
trust
interaction
next
slide,
please
so
now
anima
is
that
trusted
instruction.
I
think
I've
probably
covered
everything
in
this
in
this
latter
right.
I
So
the
basic
idea
is,
you
want
to
end
up
in
an
in-state
at
an
end
state
where
the
client
has
at
least
one
trusted
element
in
a
local
deployment
that
it
can
retrieve
more
information
from
where
had
had
no
contact
with
the
truck
with
the
initial
deployment
already-
and
you
know,
don't
think
laptop-
think
lightbulb
when
you're
when
you're
pondering
this
problem.
Okay,
there's
no
user
interface
on
the
device
at
all
next
slide,
please
so
in
in
exploring
T
right.
Some
of
the
things
that
we've
been
looking
at
is
actually
t.
I
P--
says
you
can
roll
in
eat
methods
underneath
there's
a
nice
little
TLB
defined
for
that
this
is
nice,
because
it's
very
clear
how
you
do
an
intermediate
or
an
intermediate
result
in
fact,
there's
a
example
given
in
RFC
7170
of
exactly
how
to
do
that.
Well,
goody
I
could
just
do
that.
On
the
other
hand,
if
you
create
a
new
eat
method,
that
means
it's.
I
You
know
some
of
you
might
get
this
misguided
idea
that
you
should
do
the
new
eat
method
without
the
outer
layer
protection
that
tea
provides,
and
then
they
have
a
choice.
They
can
either
do
an
additional
outer
later
layer
for
themselves
or
worse.
They
don't
do
anything
and
you
end
up
with
some
weird
exposure
in
a
vendor
method
that
poses
some
small
problems.
On
the
other
hand,
we
can
create
new
TLDs
and
this
guarantees
that
the
things
only
used
with
teeth
right.
I
So
you
get
the
outer
layer
protection,
but
there's
a
little
bit
of
confusion
that
we
have.
Maybe
it's
not
in
the
draft.
Maybe
it's
Justin
Eliot's
head
and
other
people's
heads
as
to
how
to
do
the
intermediate
results
with
with
a
method
next
slide,
please.
So
to
give
you
an
idea
of
sort
of
the
sample
flow,
and
this
is
just
a
sample
and
it's
incomplete
that
we're
thinking
about
right
and
yeah.
This
is
an
eye
chart.
You
know
you
go
through.
You
do
your
nice
little
hollows,
and
so
at
some
point
right.
I
I
We
have
really
good
technical
people
in
this
room
and
we
want
to
start
here,
but
the
overall
solution
probably
has
to
deal
with
a
pre
broad
base
of
characters
like
the
people
who
make
the
light
bulbs
or
the
people
who
do
these
little
devices
here
that
look
like
the
the
smoke
detectors
or
things
like
that
or
the
monitor.
So
it's
a
pretty
broad
problem
that
we
have
to
think
about
from
an
industry
perspective,
and
so
we
want
to
take
a
you
know,
reasonably,
deliver
it
and
and
try
and
figure
out
the
right
thing.
I
One
question
we
have
is
whether
teep
is
actually
a
useful
tool.
Here
it
looks
nice,
okay,
the
document,
the
mechanisms
that
are
provided,
look
really
good.
The
problem
is,
there's
not
a
lot
of
adoption
and,
as
Alan
pointed
out
in
the
ops
area,
working
group,
and
that
does
concern
us,
and
just
so
you
know,
Alan,
like
I,
did
these
slides
before
you
said
that
okay
and
so
we're
concerned
about
that
yeah.
J
There's
this
this
is
Alan.
My
two
senses,
EEP
is
probably
the
right
mechanism.
As
you're
saying
5g
is
moving
to
EEP
and
said:
don't
invent
your
own
thing.
Some
TLS
based
method
is
probably
the
right
thing.
Inventing
your
own
crypto
is
is
evil
and
wrong.
Right
I
would
probably
argue
that
it's
better
to
do
it
with
teep
and
just
sort
of
push
people
to
use
that
than
to
try
to
patch
one
of
the
other
eaton
methods.
H
Bro
I
think
the
thing
to
think
about
is
kind
of
all
the
dependencies
for
all
the
use
cases,
and
you
know
the
environments
you
think
of
this
using
it
will
like
a
VAP
or
they
not
or
is
it
like
a
consumer
light,
bulb
you're
selling
to
somebody
a
grandmother
or
something.
So
that's,
probably
the
more
pertinent
question
to
just
figure
out
what
you're
likely
to
have
in
your
kind
of
environment,
yeah.
I
I
The
e
territory,
but
as
I
mentioned
in
the
beginning
right
we
also
want
to.
We
also
want
to
have
answers
for
the
of
the
other
use
cases.
But
maybe
that's
not
me
right
that
you
know
if
you
look
at
a
light,
bulb
on
the
way
things
happen
or
like
the
ring
doorbells
a
perfect
example
right:
they
create
their
own
APs
and
such
and
and
then
you
you
can
just
on
board
in
a
consumer
way
like
that.
I
J
This
is
Alan
again,
not
having
you
know,
manufactured
lightbulbs
or
anything
but
doing
security.
My
my
to
sentence
would
be
suck
it
up
right.
This
is
how
we
know
to
do
it
right.
Anything
else
is
very
likely
to
be
wrong
and
if
they
don't
have
enough
CPU,
you
probably
shouldn't
be
on
the
net
right.
If
you
can't,
if
you
can't
do
this
kind
of
stuff
securely,
unless
someone's
going
to
come
up
with
a
zero
CPU
TLS,
you
know
encryption
whatever
TLS
method,
then
we
don't
know
how
to
do
it
right
other
than
this.
So.
I
Just
just
to
give
you
a
little
flavor
for
their
constraints
when
I
talk
to
partners
about
this,
what
they
say
what
they're
aiming
for
is
they
don't
they
want
to
minimize
the
amount
of
code
that
they
can't
reuse,
so
they
are
they're
looking
at
DTLS,
for
instance,
and
so
there's
a
TLS
stack,
that's
they're,
probably
aiming
at
so
we
can
probably
do
something
in
that
space.
The
more
heavy
the
heavier
it
is,
the
heavier
the
anima
part
is
the
heavier.
M
Nancy
Kim
wins
it
so
so
just
to
add
on
so
fully
agree,
which
is
why
Elliott
is
mentioning
tea,
so
I'm
also
Francisco
been
working
with
Elliott
on
this,
so
I
was
just
going
to
add
the
motivation
for
why
EAP
is
as
we're
onboarding
this.
It's
not
just
the
enterprise
but
trying
to
leverage
the
fact
that
we're
onboarding
on
a
wireless
medium
that
being
Wi-Fi.
So
it
became
natural
that,
if
we're
gonna
do
Wi-Fi,
there's
already
the
definition
of
using
Dominic's
and
therefore
EAP.
M
The
addition
that
we
have
in
here
I
just
wanted
to
add
to
what
Elliott
is
mentioning,
is
when
you
look
at
brewski.
The
thing
that
brewski
is
adding
is
that
voucher,
request
response,
ergo
EAP
has
a
request
response,
so
a
natural
place,
and
that's
the
question
mark
for
the
group
is.
We
could
add
in
to
keep
the
specification
for
doing
that
voucher
request
and
we
may
in
turn
it
on.
Is
it
a
separate,
EAP
method
likely
not
if
we
can
do
it
with
an
EAP?
M
The
other
question
is,
when
being
an
author
of
t
p--
right,
the
messages
that
we
put
in
there
for
the
certificate
enrollment
is
just
for
that.
Where,
as
EST
is
broader
ergo,
the
question
of
when
we
do
the
full
and
and
encourage
you
to
look
at
the
brewski
is
whether
we
need
to
extend
the
t
p--
to
do
what
EST
really
does
or
just
reference
EST,
which
then
gets
to
the
question
of
channel
blending.
L
:
again,
I
I
actually
have
a
couple
questions:
I,
didn't
author
teeth
or
run
the
eat,
working
group
or
implement
free
radius.
So
you
know
and
trouble
understanding
a
picture.
Why?
Don't
you
go
back
to
the
picture
because
I'm
wondering
you
get
this
thing
and
you
go,
we
might
say
yes
from
here
or
we
might
go
to
the
master
server
now.
Is
that
an
inner
method?
That's
gonna,
do
some
sort
of
communication
with
the
master
server.
I
I
I'm
not
going
to
again
I'm,
not
I'm,
not
the
expert
on
teep
either,
which
is
why
I
came
to
you
guys
so
I'm
gonna
give
you
my
best
interpretation,
everybody
you
know
can
get
up
and
say:
oh
that's
wrong,
but
and
I'll
happily
take
that
right.
So
we
start
out,
we
do
the
normal
eat
dance
with
ETLs
that
this
is
there.
I
should
say,
teep
dance
here
right.
This
is
where
we're
starting
in
this
discussion.
So
you
have
a
client,
hello,
a
server
hello,
and
so
there's
a
decision
point
actually
up
here.
I
It's
not
it
should
be
down
here
should
be
up
here
if
the
client
and
the
and
I
think
these
might
actually
be
reversed.
If
I'm
looking
at
this
correctly,
if
the
client
and
server
know
each
other,
then
in
your
code
path,
the
server's,
the
server
has
the
ability
I
think
at
that
point
to
just
send
back
each
successive
life
is
good
all
right,
and
then
you
can
just
bypass
all
this
other
stuff.
If
the
server
has
some
reason
to
not
send
a
neat
success
to
each
success,
there
could
be
two
reasons
for
that.
I
One
is
that
it
doesn't
recognize
anything
from
the
client,
then
it
could.
It
could
then
say:
okay
continue
down
the
flow
and
it
could
also
it
could
do,
and
it
does
this
with
essentially
the
record
each
request
frames,
and
so
that's
our
our
understanding
of
logic
behind
that,
and
so
that's,
where
you
get
branching
in
this
context,
does
that
explain
things
a
little.
L
L
The
part
where
the
request
goes
to
the
master
server
right,
so
you've
got
a
triple-a
server
and
the
d'herblay
server
is
talking
to
you
right,
but
it
this
point
is
the
triple
a
server
are
going
to
do.
Some
like
on
the
inner
tunnel.
Gonna
do
a
request.
The
master
server
that
the
triple
a
server
gets
an
answer
to
and
then
answers
you
based
on
it
or
is
the
request
forward
in
some
way
where
the
massive
server
now
talks
to
the
client
yeah.
I
You're,
oh
you're,
always
talking
to
the
authentication
server.
Okay,
the
authentication
server
is
going
to
forward
a
request
on
your
behalf
to
this
thing
called
a
massive
server
and
then
it's
going
to
respond
and
that
request
itself
is
signed
by
the
massive
server
in
such
a
way
that
the
peer
will
recognize
the
signature
for
authorization
and
authentication
for
this
purpose.
So.
L
L
N
C
N
Around
the
broader
context
of
autonomic
networking,
so
those
kind
of
network
devices
and
how
they
would
be
set
up
and
worked
together,
the
ACE
working
group
is
taking
that
and
moving
it
into
constrained
space.
So
they're
doing
some
of
the
definitions
to
move
a
voucher.
The
the
blob
that
we're
talking
about
that's
signed.
N
They
asked
me,
got
from
the
master
server
they're
doing
work
to
convert
that
into
a
format,
that's
better
for
constrained
environments,
which
would
also
work
a
little
bit
better
because
it's
a
cozy,
based,
etc
would
be
a
little
bit
better
for
within
the
flows,
maybe
as
opposed
to
the
the
broader
CMS
message
signing
mechanism.
So
what
we're
really
addressing
here
is
just
the
use
cases
of
where
you
have
eat
in
network
access
control,
which
is
the
wireless
and
other
space
82.
I
I
Come
back
to
sort
of
the
questions
right,
you
know
we
don't
I,
think
Alan
answered
in
you
know
relatively
assertive
way:
yeah
eat
it
and
do
teep,
and
that's
where
my
head
is
because
if,
if
you
don't
do
that,
we're
gonna
recreate
something
that
looks
an
awful
lot
like
teeth
is
my
concern,
though,
perhaps
with
a
little
bit
of
you
know.
If
we
create
a
method,
it
could
be
a
little
bit
of
Jose
Jose
glue.
I
I
You
might
not
want
to
wait
for
an
e
p--
transactions
to
each
transaction.
To
do
you
read
almond
and
the
Registrar
is
supposed
to
be
available
for
this
purpose,
but
you
might
not
know
the
IP
address
of
the
registrar,
because
this
would
would
abstract
that
out
from
you,
whereas
it's
available,
it's
discovered
in
the
animal
use
case
in
other
ways.
I
So
that's
some
thinking
that
that
needs
to
be
done
in
terms
of
in
terms
of
that-
and
there
are
other
aspects
here
too,
which
is
that
we
have
constantly
thought
about
ways
in
the
animal
working
group
to
me
where
you
might
want
to
piggyback
additional
information
back
to
that.
What
we
call
here,
the
pier
such
as
a
good
example
in
in
the
constraining
space,
is
that
people
are
looking
for
a
co-op
resource
directory.
How
would
happen
we
passed
back?
I
You
know
one
or
two
bits
of
information
that
might
be
useful
to
the
client
in
this
context,
and
this
relates
also
just
because
you
know
I
I
think
broadly
they're,
not
necessarily
deeply
on
these
things.
We're
also
looking
at
the
work
being
done
in
the
THC
working
group,
which
is
looking
to
do
yang
models
for
all
of
the
DHCP
options
and
some
of
those
we
might
want
to
pass
back
as
well
in
this
process.
I
There's
limitations
to
that,
because
some
of
that
information
is
very,
very
localized
to
a
particular
network
that
a
triple-a
server
might
not
even
have
it
access
to.
So
we
have
to
be
particular
about
that,
but
these
are
the
some
of
the
some
of
the
things
that
were
pondering,
and
so
that
leads
to
the
next
question
as
we're
going
through
all
this,
a
particularly
mysterious
thing
to
me
is
channel
binding
and
so
we're
I
just
heard
I
heard
that
I'm
gonna
repeat
what
Jim
said:
that's
gonna
be
a
pain.
I
L
L
They
plop
up
their
server,
they
run
their
devices
and
they
don't
have
to
get
the
e
p--
infrastructure
all
of
the
access
points
and
access
controllers
and
stuff
updated,
and
if
you
don't
do
it
that
way,
then
you
have
the
problem
that
you've
either
got
to
run
other
wireless
access
points
in
order
to
do
incremental
deployment,
which
most
employers
would
not
be
pleased
by
or
you've
got
to
somehow
get
your
your
corporation
to
update
the
infrastructure
before
you
can
use
this
and
I
wonder
what
you
thought
about
that.
Yes,.
I
So
I
won't
speak
for
other
vendors.
Cisco
has
a
notion
which
I'm
sure
others
do
called
Mac
authenticated
bypass,
which
essentially
allows
for
these
sorts
of
incremental
deployment.
So
you
have
devices
that
maybe
don't
understand
eeep,
maybe
that
you,
maybe
you
have
to
learn
them
in
other
ways,
learn
about
them
in
other
ways,
and
that's
just
one
example
where
yeah
you
might
end
up
getting
sandboxed
initially
and
then
you
do
have
to
deal
with
these
things
and
Max
is
going
to
I'm
sure
going
to
talk
that.
L
Wasn't
actually
what
my
point?
My
point
was
that
you're
gonna
make
these
devices
and
they
do
understand
it,
but
you're
gonna
expect
these
EEP
extensions
in
order
to
get
onto
the
network
and
if
I
just
walked
into
a
Cisco
office.
Today,
these
things
not
being
defined
those
wireless
access
points
don't
have
those
EEP
extensions,
so
I
could
get
do
the
beginnings
of
eat,
but
then
I
couldn't
actually
get
on
the
network.
Okay,.
C
L
I
L
N
Max
per
token,
continuing
that
conversation
I
wonder
about
the
if
we
put
it
on
to
a
quarantine
VLAN,
how
does
the
device
know
that
it's
in
the
wrong
spot
and
no
to
try
other
SS,
IDs
and
roll
forward
and
maybe
a
more
structure
around
whether
or
not
the
method
succeeds
or
fails,
because
it
got
the
right
stuff
or
didn't
or
didn't?
Have
the
right
extensions
might
make
it
that
process
failover
faster
to
find
the
right
spot?
It's
supposed
to
be
yet
so.
I
Just
so
that
we're
clear
right,
my
understanding
of
eath
is
that
one
of
the
nice
things
about
it
is
you
have
a
way
to
send
a
soft
fail
in
the
protocol
and
where
the
server
can
then
try.
Other
things
and
I
suspect
we'll
see
some
of
that
at
work
here,
but
we
might
I'm
not
and
I,
don't
know
how
far
we'll
have
to
go
in
a
specification
on
that
front.
F
F
One
comment
that
I
would
provide
is
that,
at
least
in
my
experience
it's
it's
often
useful
to
keep
sort
of
the
EAP
to
do
the
thing
that
it
was
originally
designed
to
do
to
authenticate
in
various
different
ways
and
then
use
other
other
mechanisms
for
delivering
configuration.
Information
and
now
I
mean
that
that's
my
experience
and
that's
that
would
be
my
advice.
I
realized
that
people
don't
always
listen
to
my
advice
and
then
this
soon
we
are
people
who've
done
not.
You
know
not
followed
this
particular
advice
so
and
they're
like
right
now.
I
I
think
there's
thank
you.
Re
I,
the
the
key
thing
I
just
want
to
bring
out
they're.
That
use
case
is
really
really
it's
hitting
us
hard
in
a
couple
of
different
deployments
where
the
you
don't
have
DNS
in
some
of
these
spaces
you,
yet
you
do
have
a
little
bit
of
efis
business
as
it
were,
and
so
that
people
are
looking
and
what
they're,
using
instead
of
DNS
for
planning
use
instead
of
DNS,
is
really
the
coop
resource
directory
and
to
locate
various
devices
until
they
need
one
little
hook.
I
And
but
of
course,
once
you
say
one
little
hook,
everybody
has
their
own
one
little
hook
they
want
to
find,
and
so
we
this
could
grow
into
a
monster,
and
that
would
be
the
thing
that
I
would
be
concerned
about
and
when
I
mentioned
DHCP,
that's
just
the
monster.
You
were
thinking
about
I'm
sure
there.
L
F
Yah
react
so
yeah
there's
some
tons
of
ways
of
discovering
stuff.
You
know
multicast
address,
saying
and
you
know
I've
done
some
work
on
co-op
resource
directories
and
and
that's
not
I,
don't
think.
That's
a
intractable
problem,
also
in
other
other
ways,
okay
and
and
and
and
the
the
other
comment
I
would
make.
Is
that
like
this?
We
see
this
a
lot
like
you
know
we
can't
have
DNS,
we
can't
have
this
or
that,
but
then
we
also
do
certificates
and
and
certificate
chains,
and
it's
it's
a
little
funny,
because
people
think.
I
L
I
think
the
other
thing
you
might
want
is
to
have
all
that
other
stuff
work
on
a
network
that
isn't
a
neat
network
and
that's
you
know,
so
that's
the
other
thing
you
want
to
take
into
account
night
I'm
interested
in
this
and
I
at
least
like
to
follow
it.
Regarding
your
question
of
work
and
would
review
stuff,
I,
don't
have
resources
to
implement
or
anything
well.
I
I
The
advice
well,
I
want
to
just
close
with
is
just
to
point
out
that
my
co-conspirator
is
sitting
there
in
the
back
Owen
field,
who's
right
behind
Alan
and
right
in
front
of
Alan
is
Brian
Weiss,
who
gets
suckered
into
implementing
a
bunch
of
this
stuff
too,
and
of
course,
Nancy.
So
we're
all
trying
to
all
of
us
are
trying
to
figure
this
out
working
with
different
partners,
and
this
will
have
to
be
an
industry
solution.
I
It
can't
be
a
and
a
broad
industry
solution
be
going
beyond
the
IETF,
so
there's
a
fair
amount
of
uphill
lifting
here.
If
we
take
this
approach,
whatever
approach,
we
take
there'll,
be
uphill
lifting
for
all
of
this,
and
we
have
to
also
work
with
I
think,
probably
the
I
Triple
E
in
this
space
to
figure
out
the
other
problem,
which
is
how
do
I
choose
what
network
to
join
in
a
NATO
loop,
802,
11
cents,
I,
don't
think
they're
quite
done,
they're
quite
frankly
and
I'll
just
point
out.
Also.
O
Dorothy
Stanley
Hewlett
Packard
Enterprise
to
your
less
comment:
Eliot
about
the
work
in
dot
11,
not
being
quite
done
from
a
discovery,
point
of
view,
I
would
be
and
I
I
think
the
dead
11
working
group
would
be
delighted
to
hear
your
comments
in
that
regard,
and
I
would
encourage
you
to
put
together
a
presentation
and
bring
that
to
down
11
to
describe
the
use
cases
that
you're
looking
at
that
are
not
completely
addressed.
I'm.
O
I
I
I
A
Okay,
so
yeah
I
think
you
know
that
there
sounds
like
there's
some
interesting
discussion
that
could
happen.
I
think
certainly
paring
down
or
compartmentalizing.
What
you
want
to
do
like
perhaps
working
on
enrollment
or
improving
their
enrollment
in
there
would
be
a
good
thing,
but
I
think
you
guys
need
to.
We
need
to
kind
of
figure
out.
What's
the
right
direction
here,
for
this
sort
of
thing,
so.
I
Take
having
taken
this
input,
it's
now
up
to
us
to
actually
put
out
a
draft,
because
otherwise
we
will
continue
to
speak
in
generalities
and
and
who
likes
that.
So,
if
you're
interested
in
taking
part
of
that
effort
drop
one
or
me
an
email
and
we're
particularly
you
know,
additional
advice
on
channel
binding
always
welcome
because,
as
Jim
said
before,
he
left
it's
a
pain
where
it's
going
to
be
a
pain.