►
From YouTube: IETF97-TRILL-20161116-1110
Description
TRILL meeting session at IETF97
2016/11/16 1110
A
B
C
C
D
C
C
E
C
A
It's
typed
it
a
little
bit
so,
but
if
you
list
see
you
is
getting
that
part,
so
we
got
the
agenda
till
you
got
my
kinky
thing
and
there's
the
Charter
thing
to
check
your
name
on
it.
Then.
D
Put
well
actually
I
want
to
see
the
routine,
so
we'll
do
that.
I
just
have
to
go
sit
where
they
tell
me
how
I
here
is
not
doing
a
good
job.
So.
A
B
A
D
Did
you
take
care?
I
have.
A
Hdmi
Elsa,
okay,.
C
A
B
F
C
B
Thanks
mine
sure.
A
B
B
C
D
D
A
B
F
D
There
behind
behind
ok,
if
I
short,
don't
go
too
well,
that's
right.
This
has
a
problem.
A
Want
to
do
that
I'm
sure
yeah
hi
there.
This
is
the
troll
working
room,
we're
gonna
get
underway,
so
I've,
got
least
late
from
huawei,
and
so
there's
a
real
Zeldin.
It's
my
love,
I'm,
the
secretary
John
Hudson,
the
other
co-chair
with
sue
is
not
here.
This
meeting
we're
using
other
machine
so
and
leah
is
our
80,
but
I
guess
she
trusts
us
CLE
she's,
not
here
nah,
that's
okay!
So
note
well,
I!
A
Think
we've
seen
this
before
anything,
you
present
or
basically
input
into
the
working
group
processes,
set
it
to
IPR
disclosure
rules
and
so
forth.
Study
that
the
quality
of
the
documents
we
produce,
which
is
really
the
output
of
the
IETF,
depends
on
review.
So,
if
you
want
people
to
review
your
document,
you
should
review
other
people's
documents
and
then
everybody's
documents
will
be
better
most
likely.
A
So
I
guess
I'll
give
news
on
what's
happened
since
our
last
meeting
we've
had
four
RSC's
published,
which
are
listed
here,
distributed
latex-free
gateway,
a
RFC
on
the
interface
addresses
app
subtly,
which
is
a
data
format
for
use
in
the
directory
stuff.
You
said
a
labels
for
tree
selection
and
a
are
which
channel
header
extension
orbitals
are
control
messages
between
trill
switches
and
this
ietter
extension
provides
for
various
payload
types
and
also
adds
security.
The
thing
a
couple
drafts
have
passed
working
group
last
call
and
centralized
replication
and
obviously
entry's.
A
There
are
now
three
drafts
in
last
call
ARP,
optimization,
which
was
sent
back
for
the
iesg
and
has
been
actually
modified
and
is
now
in
working
with
last
call
again
with
the
modified
version.
Smart
n
nodes
is
I
posted
a
review
and
I
think
it
needs
to
be
modified,
take
that
into
account
and
then
trill
over
IP.
It's.
Finally,
in
working
group
last
call
and
we've
adopted
the
ecn
support
draft
so-
and
here
is
just
a
couple
slides
in
this
slide
deck
showing
all
the
RFC's.
A
D
A
D
A
Next
slide,
please
so
I'm
Donnelly's
it
with
Huawei,
so
trill
has
some
communications
protocols
that
it
standardizes
and
in
particular,
there's
the
loud
I
get
to
the
middle
bit
rate
them
in
a
second.
But
for
these
communications
protocols
you
don't
really
know
in
general
whether
the
troll
switches
are
locally
in
a
controlled
environment
or
maybe
they're
far
apart
and
you
have
in
secure
communication.
So
you,
you
really
want
to
have
some
way
of
securing
that
and
there's
sort
of
two
aspects.
Securing
one
is
like
the
format's
of
the
packets
and
the
encryption.
A
Algorithm
is
all
kind
of
stuff,
but
the
other
thing
is
keying,
because
it
doesn't
really
matter
how
good
the
other
stuff
is.
If
you
can't
get
good,
secure,
secret
keys
to
the
end
points
or
insights
you
to
use
by
those
algorithms,
then
you
still
key.
Don't
have
security
and
modern
criterion,
which
is
us
I
was
going
to
say
in
for
so
don't
like
strongly
encouraged
by
the
IETF
security
area
requires
key
negotiation
so
that
you
don't
keep
using
the
same
key.
You
don't
just
have
manual
configuration.
A
A
So
two
particular
areas
where
trill
has
some
keying
is
Arbor
channel
messages
which
I
mentioned
briefly
earlier,
which
are
typed
to
control
messages
between
drill
switches
and
we
also
just
getting
the
trill
over
IP
through
so
trill
supports
IP
encapsulation
of
the
traffic
between
trill
switches,
both
the
trill
control
traffic
and
the
data
traffic.
There
are
other
kinds
of
links
besides
IP
the
trill
sports.
Of
course,
you've
got
Ethernet,
but
Ethernet
already
has
its
own
kind
of
security
stuff.
So
it's
really
mostly
worried
about
the
communications
channels
that
trill
has
specified.
A
So
unicast
is
pretty
easy,
so
you
just
have
to
get
the
session
key
to
the
endpoints,
and
typically
people
have
already
figured
out
how
to
do
that
kind
of
so
the
existing
RFC
on
Arbor
channel's,
the
extension
79
78,
adding
security
just
says
it's
used.
Dtls
DTLS
has
all
kinds
of
really
modern
key
negotiation
is
great
and
similarly
IP
draft
says
use
Ike
v2.
It
has
all
the
modern
stuff,
but
this
is
really
just
point
to
point
next
slide.
A
So
a
multicast
or
broadcasting's
can
be
more
efficient
because
it
decreases
link
utilization
and
decreases
port
utilization.
It
has
advantages,
but
it's
trickier
for
security,
so
arbic
channel
facility
is
ways
designed
automatically
supports
multi
caster.
Basically
you
with
to
all
the
trill
switches
that
have
advertised
interest
in
a
particular
VLAN
or
fine
grained
label.
So
it's
already
has
that
built
into
it.
I
p,
of
course,
has
multi
has
defined
it's
not
always
supported,
but
there
are
certainly
especially
local
networks
which
support
native
IP
multicast.
A
So
in
those
cases
you'd
like
to
be
able
to
use
those
facilities,
you
like
to
be
able
to
use
them
securely
next
slide.
So
there's
like
different
ways:
you
can
try
to
do
multicast
security.
Well,
first
is
not
really
multicast
security.
It's
just
you
send
multiple
copies
to
everybody.
Thats
Sarah
unicast.
To
is
where
you
distribute
a
secret
key
to
all
the
members
of
the
group.
They
can
use
that
to
encrypt
multicast
or
broadcast
and
that's
can
be
secure,
but
the
more
people
that
know
the
key.
A
You
know
this
slightly
less
secure
and
you
no
longer
have
any
way
of
telling
cryptographically
securing
which
of
the
group
members
originated
a
message
so
they're
all
using
the
same
key
in
the
group.
You
can
tell
it
came
from
somebody
in
the
group,
but
you
can't
tell
which
so
the
question
then
is
which
for
to
whether
the
added
efficiency
of
multicast
is
worth
the
small
reduction
in
security,
whether
that's
a
small
reduction
I
guess
depends
on
your
security
environment.
A
Next
slide,
there's
also
possible
to
use
other
kinds
of
security
like
public
key
security
or
everybody
has
a
different
key.
You
use
public
key
and
everything.
The
problem
with
that
is
it's
more.
It's
computationally,
less
efficient
I
mean,
like
many
orders
of
magnitude,
could
be
10,000
times
as
inefficient.
So
may
not
be
practical
and
there
are
other
kind
of
more
complicated
exotic
ways
of
doing
things
which
are
not
really
to
pride
too
widely
deployed.
A
Some
of
them
are
standardized,
but
it's
not
widely
deployed
next
slide.
So
so
the
idea
is
for
trill,
which
you
obviously
do.
If
you
have
point-to-point
security,
you
can
obviously
do
the
serial
unicast
is
to
extend
it
to
type
2.
So
if
you
have
a
network
where
the
slight
reduction
in
security,
where
you
can't
tell
who
originated
a
message
is
a
problem,
then
you
can
always
fall
back
to
Syria
unicast,
which
will
be
secure
until
next
one.
A
So
the
draft
he's
like
troll
group
keying,
specifies
a
way
to
do
to
securely
distribute
a
key
from
one
group
member
to
the
other
group
members.
So
they
all
have
the
same.
Key
can
use
it
and
there
be
ideas
that
be
a
companion
graft
to
would
define
the
details
of
how
to
use
that
for
Trillo
over
IP
and
the
details
of
how
to
use
that
for
our
channels
and
it's
for
the
facility.
The
group
king
facility
is
designed,
so
you
could
tailor
it
for
other
things
too.
A
So
it's
sort
of
a
generic
way
to
do
things
next
slide,
so
it
uses
it
assumes.
You
already
have
pairwise
keying
set
up.
If
you
can
be
doing
broadcasts
or
multicasts,
you
almost
always
have
unicast
traffic
between
at
least
some
airs
anyway.
So
if
you
set
up
point-to-point
security,
you
now
have
a
secure
way
to
communicate
and
you
can
use
that
for
distributing
the
key.
So
in
fact
the
group
key
is
effectively
serially
unicast
to
the
members
of
the
group.
This
is
actually
very
similar
to
the
way
why
fire
802
11
does
security.
A
So
I
already
have
covered
the
last
note
there
next
slide.
I
don't
want
to
take
too
much
time
because
we
started
a
bit
late,
so
this
is
kind
of
very
generally.
What
these
messages
in
this
group
keating
look
like.
They
have
an
inner
container
so
to
speak,
which
uses
the
AES
key
rabbi
probably
should
have
put
the
RFC
here.
Aes
key
rap
is
up
there's
an
RC
which
specifies
it
is
actually
really
specified
by
nist
in
u.s.
A
government,
but
it's
a
way
of
a
multiple
encryption
using
AES,
and
then
you
put
as
much
as
you
can
in
there
because
that's
the
sort
of
the
strongest
protection
and
then
you
have
an
outer
container
and
you
put
a
minimal
amount
in
the
outer
part.
So
you
can
recognize
what
this
message
is
about.
What's
going
on
and
that's
secured
using
this
point
to
point
security,
you
already
have
set
up
okay,
this
leverages
existing
point-to-point
security.
So
that's
sort
of
this
orange
container
on
the
outside.
A
So
this
is
just
a
five-member
group,
so
you
have
one
designated
node
elected
to
determine
in
some
way
and
it
basically
sends
Keys
generates
a
key
and
sends
it
to
everybody
and
then
all
these
five,
each
of
them
could
originate
a
message
either
to
all
the
members
of
the
group
or
some
multicast
subset
or
whatever.
So
that's
it
any
questions.
A
When
remember,
the
group
leaves
in
general
what
you
should
do
is
rekey
the
remaining
members,
because
this
person
is
no
longer
remember
the
group,
and
you
know
the
draft
bait
since
its
kind
of
intended
to
be
a
general
draft.
It
says
that
you
should
do
that,
but
sometimes
if
you
have
a
highly
dynamic
group
with
members
entering
and
leaving
all
the.
E
A
E
D
And
actually
for
this
draft,
if
you
get
a
chance
guys,
it
would
be
useful
to
take
a
look
at
it.
I'll
try
to
take
a
look
at
it
this
next
week.
Donald
annum
go
through
it.
Keep
rekeying
is
important
because,
when
they're
in
the
middle
of
the
data
center
stuff
or
when
you're
in
the
middle
of
deployments,
having
the
group
key,
secure
and
Donald's
process
is
pretty
effective.
So
because
a
lot
of
data
center
trafficked
or
a
lot
of
land
traffic
can
get
attacked,
and
this
will
will
provide
quick,
Ricky,
yeah.
A
D
D
Today,
if
so,
I'm
gonna
go
through
the
Charter
changes,
our
focus
has
been
from
the
ad
to
try
to
get
things
that
make
trill
deployed.
What's
missing,
so
remember:
that's
what
happened
so
we
done
current
Charter
and
thanks
to
Donald
and
and
John,
and
all
of
you
were
making
really
good
progress
on
it.
I
think
I'm
always
impressed
with
this
working
group.
D
Is
we
click
through
things
fairly
quickly
and
people
respond
in
the
mail
with
with
good
reviews,
so
we're
sort
of
down
to
the
ARP
reduction
draft
which
we've
gone
through
twice
and
the
directory
mechanisms
are
about
there,
so
we're
in
a
lot
of
review
process
and
we're
doing
this
drill,
Suter
wires
and
we've
gone
to
the
multi-level
and
multi
topology.
So
a
lot
of
our
initial
work
is
done,
but
standardization
for
interoperability
is
getting
the
reviews
all
the
way.
Through
now
the
intercampus
control
plane
stuff
is
pending
and
we've
been
doing
the
security
analysis.
D
Interoperability
has
been
requested
by
80s
to
move
to
web,
so
we'll
try
to
keep
getting
stuff.
So
the
question
that
we're
sort
of
looking
is
we've
been
adding
ecn,
support
and
transparent
mode
to
provide
better
input
inside
of
the
data.
Centers
it'd
be
good
to
see
if
this
really
matters,
two
deployments
you're
working
with
and
so
we'd
like
some
feedback,
because
we
will
do
a
final
call
within
a
couple
weeks
for
the
charter
change
and
then
what
we've
got
as
to
be
specific,
is
we've
added.
D
The
and
then
we'll
specify
to
support
other
payloads
such
as
IP,
so
please
look
at
it
and
we'll
change
the
name.
Please
look
at
it
will
post
this
new
charter
in
a
couple
weeks
we're
trying
to
get
through
all
of
our
other
reviews.
So
we
can
just
clear
our
docket
some
of
its
stuck
with
the
ad,
but
she
sort
of
overloaded
for
a
little
bit
while
she
was
ill
so
I
think
that's
it.
D
A
Oh
one
other
question:
do
we
have
a
jabber
straw
here?
Actually
we
should
have
done
that
earlier.
C
A
C
A
B
D
A
A
So
it's
here
well
anyway,
you
should
figure
that
up.
B
Type:
ok.
A
A
Okay,
there,
you
are
excellent.
F
Ok,
so
I
guess
I
can
get
started
basically
this
this
drug
deals
with
you
know
the
default
whole
tree.
Construction
rules
can
create
situations
where,
for
a
particular
node,
the
parent
node
might
shift
in
certain
situations.
So
it
tries
to
offer
two
solutions
for
that
and
basically
we
can
go
through
those.
My
name
is
Ram
Kumar
and
I
work
for
Birkett
communications
next
slide.
Please.
F
These
are
right,
so
so
then,
the
subsequent
slides
will
basically
give
a
picture
which
explains
what
the
problem
is,
but
basic.
The
truths
tree
construction
rules
can
create
situations
where
you
know
the
parent
node
for
a
particular
child
node
will
shift
during
Reconstruction,
even
if
there
is
no
apparent
change
in
the
pit,
the
the
links
or
the
availability
of
the
parent.
F
So
this
draft
has
a
it
proposes
two
different
solutions
to
address
that
and
we
can
go
through
the
logic
of
each
of
those,
and
so
the
motivation
for
this
was
that
you
know
I
was
aware
of
situations
where
people
where
customers
were
impacted
by
this
and
we're
looking
for
ways
to
solve
it.
So
to
that
extent
I
mean
basically
if
if
this
is
important
enough,
then
this
weekend
on
request
adoption
of
this
draft
next
slide.
Please.
F
So
actually
we
could
skip
to
the
next
slide.
That's
fine!
Well
yeah,
so
it
so.
The
problem
basically
comes
down
to
this
this
paragraph
and
this
text
in
the
draw
in
the
draft
and
with
the
correction
in
7780.
So
if
you
have
it
can
a
node
when
you're
pulling
the
node
into
the
SPF
tree.
If
the
node
has
lesser
p
parents
and
you're
constructing
three
number
j,
then
the
the
rule
basically
mandates
that
your
parents
election
will
be
j,
minus
1,
mod
p.
F
F
So
this
one,
this
log
explains
that
situation.
So
if
you
see
look
at
this,
my
new
flow
network
on
the
top
right
of
the
slide
considered
32
and
assume
that
node
a
is
the
is
a
root
of
the
tree,
so
at
the
uni
at
the
outset.
Basically,
when
a
starts
pulling
in
nodes
into
the
network,
it
will
immediately
pull
in
1
2,
&
3,
so
1
2
&
3
do
not
have
a
choice
of
parent.
F
They
will
be
pulled
in
by
a,
but
when
it
comes
to
B
and
C,
they
can
be
so
I
think
the
links
on
a
slide
or
not,
which
is
showing
in
the
right
color
I
guess,
but
they
all
the
nodes
are
connected
to
each
other.
And
it's
a
it's.
It's
it's
basically
a
spine
leaf
network
in
the
traditional
article
at
apology.
So,
but
when
it
comes
to
B
and
C,
you
have
a
choice.
F
Basically,
they
can
be
pulled
into
the
SPF
tree
from
node
1,
from
load
to
or
from
node
3,
and
for
the
purpose
of
this
discussion
assume
that
all
the
links
have
the
same
cost.
So
the
you
know
be,
for
example,
will
be
reachable
at
a
cumulative.
Hop
count
of
to
see
will
also
be
reachable
either
hop
count
up
to,
regardless
of
which
parent
it
is
selected,
whether
it's
one,
two
or
three
next
slide,
please
so
so
that
is
fine.
F
You
could
initially
start
off
with
the
trill
rule
and
application
on
the
previous
slide
explained
how
r
2
node
two
were
selected
as
the
parent
and
that's
basically,
because
if
you
are,
if
you
could,
if
you
look
at
one
two
and
three
order
them
in
assume,
they
are
already
inserted
ascending
order
of
seven
bike:
octet
ID
the
index
that
will
be
used
for
3
to
4,
B
and
C.
They
have
three
possible
parents,
and
this
is
treat
2,
so
2,
minus
1,
mod
3
is
is
1.
F
Mod
3
is
1,
so
the
index
of
the
selected
parent
will
be
to
now
and
that's
what
to
as
a
parent
for
B
and
C
in
the
previous
slide,
I
hope
that
was
clear
from
the
links
now
now
consider
what
happens
if
node
one
goes
down.
So
when
node
one
goes
down
the
parent,
the
picture
of
the
parent
selection
changes
so
now,
B
and
C
don't
have
three
possible
parents.
They
have
two
possible
parents
which
are
node
2
and
node
3.
They
are
in
ascending
order.
F
They
are
arranged
as
node
to
common
node,
3,
node
2
at
index
0
and
note
3
our
index
1.
Now
you're.
In
now
you
run
your
transparent
selection
rule
which
says
3-1
mod
number
of
parents,
so
that
is
2-1
mod
2
in
this
case.
So
that's
one
mod
2,
that's
1,
but
now
the
node
at
index
1
is
no
longer
mode
to
its
node
3,
so
be
and
cease
parents
shift
from
node
2
to
node
3.
This
is
a
this
is
unnecessary
because
in
vowed
to
never
went
away,
it's
it's
healthy.
F
Its
links
to
B
and
C
are
healthy,
so
there
is
no
reason
for
B
and
C
to
change
its
parent,
so
so
the
and
this
can
cause
some
amount
of
disruption
in
the
network
depending
on
you
know
how
you'll
strike
your
vlans,
and
not
only
from
there.
You
know
just
not
only
just
from
the
links
themselves
changing
they
can
be
other
other
ways
in
which
it
more
disruption
is
possible.
So
next
slide,
please.
F
So
the
first
approach
that
the
draft
takes
it
gives
two
different
solutions.
The
first
solution
is
that
you
can
use
affinity,
sub
tlv,
to
sell
this,
so
I
mean
innocent
stated
simply
basically,
the
node
that
wants
to
maintain
the
current
bindings
sends
out
an
affinity,
sub
tlv
naming
the
children
and
that
it
wants
to
hold
on
across
the
network
change
event.
They
are.
So
if
you
go
back
to
the
previous
slide,
the
mode.
Actually,
you
can
go
to
the
next
slide.
That's
fine,
if
you
know
actually
skip
to
the
diagram
the
following
slide
yeah.
F
So
in
this
case,
what
happens
is
in
the
same
situation
before
node
one
goes
down.
Node
two
sends
out
an
affinity.
Sub
tlv
ought
to
all
the
nodes
in
the
network
as
part
of
its
router
capability
or
multi
to
felicity
router
capability
LVS,
and
everybody
knows
that
too
wants
to
bind
to
B
and
C.
So
the
way
this
is
framed
in
the
draft
is
that
you
must
have
a
CLI
option
on
node
2,
stating
that
the
operator
wants
this
node
to
be
sticky
for
its
children.
So
the
way
I
at
least
ionisation
written.
F
The
draft
is
that
you
have
a
loose
loosely
stated
stickiness
in
the
sense
that
you
don't
say
no
to
has
to
have
these
children
as
its
sticky
children.
You
just
say
that
note
too
sticky
so
and,
as
so
note
to
initially
starts
off
the
publishing
the
affinity,
tlv
and
I
mean
I.
Think
the
graph
talks
about
the
first
tree
construction
using
default
drill
rules
and
then
subsequent
ones
using
the
affinity
tle.
F
But
you
are,
you
could
directly
start
with
the
affinity
early
too,
but
if
the
laws
banning
the
the
way
it
works
is
that
node
2
doesn't
like
try
to
hold
on
to
B
and
C
under
all
possible
cases
it
just
it
disregards
the
to
rule.
It
also
disregards
affinity
oggy
and
tries
to
see
whether
it
can
potentially
retain
the
children
that
it
had
entirely
trations
as
part
of
natural
tree
formation.
So
links
may
come
up,
links
make
around
nodes
may
come
up.
Let
me
go
down.
F
The
situation
in
the
topology
can
change,
but
if
two
remains
in
contention
for
the
same
setup,
children,
it
tries
to
hold
on
to
them
by
say
continuing
to
send
out
the
affinity
tlv.
If
it
reaches
a
situation
where
it
cannot
send
it,
it
can
no
longer
be
the
parent
for
those
children
or
if
the
parent-child
relationship
in
words,
because
some
links
went
down
and
b
and
c
are
now
pulling
two
into
the
tree
as
a
child
them.
In
that
case,
it
will
retract
it.
F
F
So
the
second
approach
deals
with
this
little
funky
I
mean
it
uses
a
modified
version
of
the
SPF
algorithms,
where
you
are,
if
you
can
pull
out
multiple
when
you're
pulling
nodes
in
from
into
the
network
into
there
is
SPF
tree.
If
you
can
pull
multiple
nodes,
if
a
node
can
be
pulled
by
multiple
parents
at
the
same
cost
done
it,
it
allows
you
to
insert
a
policy
filter
which
allows
you
to
choose
the
node.
F
F
So
in
this
case
you
everybody
starts
out
with
chills
default
recomputation
with
the
truth
default
rules
that
were
arrested
previously
and
as
you
move
into
successive
as
the
tree
gets
recalculated
due
to
network
events,
you
try
to
latch
your
policy
filter
to
the
previous
choice
of
parent
that
you
had
for
this
to
the
same
child
nodes.
So
in
this
case
next
slide,
please
I
think
you
can
go
to
that
picture.
F
Take
the
same
situation
with
this
approach
to
so
the
initial
click
construction
happens.
You
have
initial
tree,
construction
happens
with
default
mode
or
rules.
Then
later
in
subsequent
calculations,
when
note
goes
down,
everybody
has
access
to
what
the
two
looked
like
when
no
one
was
up
now.
They'll
use
that
and
feed
that
into
their
policy
filter
and
now,
with
the
modified
SPF
algorithm
when
they
construct
the
new
tree,
the
BNC
will
automatically
get
pulled
in
through
poo
because
they
were
in
the
previous
snapshot,
because
in
the
previous
lecture
they
were
pulled
in
through
two.
F
F
So
between
the
trapezes
I
think
approach
is
more
preferable
because
it's
much
more
predictable
affinity
set
tlv
is
well
understood,
and
you
know
I
mean
it's
it's
known
to
work,
the
only
consideration
being
that
if
up,
if
somebody
else
has
a
patent
on
approach
a
then
we
need
to
think
about
it.
The
nature
of
these
approaches
has
any
as
any
IP
are
at
brocade.
E
A
Alright,
so
this
is
a
important
problem,
the
I
guess.
The
only
question
I
have
really
understand
the
least
approach.
A
4gb
seems
a
little
dependent.
What
kind
of
policies
you'd
want
to
set
up
in
things,
but
there
is
another
draft
actually
which
is
called
resilient
trees,
which
is
aimed
at
a
slightly
different
problem,
not
so
much
the
stability,
but
rather
rapid
establishment
of
a
tree
after
a
failure,
and
it's
actually
fairly
long.
A
F
A
F
Gone
through
it,
my
dear
so
I
believe
to
use
a
different
key.
I
holding
all
together
and
you
come
out
with
two
trees
right.
F
A
So
well,
at
least
we'll
be
good
to
be
sure
that
let's
say
we
adopt
approach
a
for
solution
of
the
problem
that
you're
talking
about
be
good
to
make
sure
there
was
no
conflict
between
that
and
the
thing
and
resilient
trees,
or
if
there
were,
then
you
need
to
comment
to
say
something
about
that
how
to
hula.
Maybe
you
can
only
use
one
of
them.
Okay,
I'll,
take
a
look
at.
B
A
A
We
do
want
to
just
I'm
just
going
to
very
briefly
go
over
the
milestone
situation.
We
have
achieved
more
milestones
they're
coming
along,
but
we
have
an
increased
number
that
are
overdue.
So
there's
some
idea
that
perhaps
we
should
update
the
milestones
at
the
same
time
as
the
Charter.
Admittedly,
the
milestones
aren't
considered
that
way,
T
or
binding
a
thing
most
ITF
working
groups,
but
it
would
be
good
to
get
these
milestones
set
to
something
that's
plausible.