►
From YouTube: BIER WG Interim Meeting 2020-04-14
Description
BIER WG Interim Meeting 2020-04-14
A
But
I
see
my
screen:
okay,
great
so
just
I
wanted
to
update
on
e,
and
hopefully
we
can
get
during
the
meeting
to
some
conclusion
on
actually
move
it
over
to
is
G.
So
we
had
our
CH.
Oh
five
working
group
last
call
at
idea,
106
and
I
think
we
had
all
the
active
working
group
members
chime
into
the
last
call.
Finally,
you
know
successfully
finish
the
last
call
and
then
Lou
chimed
in
to
the
discussion
and
raised
concerns
about
not
including
the
full
traffic
engineering
components
or
description.
A
So
I
worked
off
o
six,
where
I
added
section
1.2
explaining
the
relationship
to
traffic
engineering
architecture
changed
the
name
to
ear
path,
engineering
to
distinguish
it
from
overall
traffic
engineering
and
then
also
the
inter
long
overdue
vacation
just
called
the
controller
PID
controller.
But
then
there
was
the
concern
that
path.
Engineering
would
be
neuter
that
that
Lou
race
and
then
he
also
suggested
to
bring
in
text
about
traffic
engineering.
Debra
was
concerned
about
consistency
of
terminology,
so
we've
got
some
abbreviations
and
that
doesn't
seem
to
be
well
maintained.
A
A
So
then
you
know
because
it
seems
like
we
couldn't
simply
come
up
with
a
name
that
would
make
everybody
happy.
We
initiated.
You
know
it's
a
choice
for
for
the
name's
Greg
supposed
to
propose
to
call
it
beer
tree
engineering.
We,
you
know
almost
everybody
in
the
working
group
signed
him
and
supported
I.
Didn't
really
do
it
because
it
also
says
te
but
I
really
think
hectically,
it's
the
best
term,
because
that's
effectively
what
this
protocol
does,
it
does
do
engineer,
trees.
It
doesn't
itself,
you
know
care
for
the
resource
allocation
along
the
tree.
A
Just
you
know
does
this
during
for
a
tree.
So
that's
now
in
the
current
arch,
no
seven
that
was
submitted
before
the
IETF
deadline,
I
removed
the
section
one
or
two
according
to
to
Lew.
He
didn't
like
that.
I
explained
I,
just
added
an
exponentially
section
for
readers,
explaining
the
choice
of
the
name
and
I
removed.
You
know
path,
engineering
or
other
terms
from
the
explanatory
text
and
just
use
the
you
know,
replication
steering,
which
were
the
terms
that
Lou
was
suggesting
to
stay
in
line
with
their.
A
You
know
similar
explanations,
I
guess
in
segments
route
into
which
I
think
this
is
very
easily
comparable.
So
until
I
guess
thirty
minutes
ago
there
was
no
text
from
Lou
was
just
starting
to
read
through
it.
Thank
you
very
much
Lou
so
and
I
guess
hopefully
do
is
still
on
the
call.
He
said
he's
double-booked,
but
I
wanted
to
quickly
finish
this
up
with
the
traffic
engineering
view
from
my
understanding
right.
So
I
didn't
really
find,
in
definition
and
at
the
chart
or
any
of
the
documents
from
what
the
folks
I
asked.
A
They
say
it
was
that
it
was
pretty
much
derived
from
you
know
what
RSVP
T
is
practically
doing,
and
that
is
really
Express
setup
and
bandwidth
reservations,
maybe
a
for
our
mechanisms,
but
so
far,
for
example,
there
hasn't
seemingly
been
in
T's
or
in
PCE
something
about
the
real
latency
buffer
reservation
that
would
be
required
for
that
night.
So
you
know
something
like
a
very
crisp
definition
of
what
we
really
call
traffic
engineering
what's
optional.
What's
mandatory
would
really
help
me
a
lot.
Why
do
I
think
this
is?
A
I
think
you
know
from
the
last
20
years
of
multicast,
we've
got
a
little
bit
of
a
different
in
experience
of
how
customers
really
have
done
traffic
engineering
to
the
extent
you
know
that
I'm
still
not
numbers
I'm
sure
I'm
using
traffic
engineering
percent
correctly,
but
because
we
never
had
explicit
steering
of
traffic
in
multicast
before,
let's
say,
rsvp-te
point-to-multipoint,
which
has
very
rarely
been
used.
But
customers
still
try
to
you
know
with
management.
A
There
has
been
a
lot
of
user,
for
example,
multi
topologies
in
I
gps
or
just
you
know,
hop-by-hop
route
steering
with
with
standard
multicast
in
the
same
way,
if
that's
an
acceptable
mechanism-
and
today
we
have-
you-
know,
I
think,
a
very
good
framework
for
it.
These
multi
topologies
called
the
flex
topologies,
then,
in
the
same
way,
I
would
say
for
an
overall
beer
traffic
engineering
architecture.
A
You
know
not
only
beer
te
could
be
used,
which
I
think
obviously
is
the
best
option,
but
also
simply
beer
combined
with
Flex
topologies,
and
so
that
was
kind
of
a
little
bit
of
the
goal
of
the
t's
framework
document
for
traffic
engineering.
With
with
beer
that
we
would
lay
out.
You
know
both
of
the
beer
options
explaining
how
they
differ,
for
you
know
how
well
they
can
support
traffic
engineering
and
then
also
the
other
components
like
you
know
what
the
controller
would
need
to
do.
A
What,
for
example,
if
you
want
to
guarantee
latency
some
orthogonal
mechanism
like
well,
the
large-scale
deterministic
network
mechanisms
we
proposed
in
debt
net
would
need
to
do
right.
So
traffic
engineering
is
combining
beer
tree
engineering
together
with
other
mechanisms,
and
so
there
was
a
little
bit
my
best
understand,
but
hopefully
Lou
can
chime
in
here.
So
right,
what
what?
What
can
we
do
now
or
what
should
we
do
now?
A
I'm,
not
sure
what
the
working
group
here
could
do
further
right,
I
think
we
haven't
really
changed
technical
aspects
of
your
team
in
the
last
two
years,
we've
I
think
exhausted.
Now
all
the
great
feedback
to
help
him
with
the
text
quality.
Thank
you
very
much
for
everybody,
and
so
you
know
I
just
like
to
pass
the
draft
seen
to
to
the
ISG
490th
a
nice
year
review.
So
that's
what
I
had
written
all
right.
So
now
again,
Lou
has
added
head
proposed
text
Lou's
here:
I'd
love
him
to
chime
in.
A
B
Not
sure
see
you
know
you're,
my
muted,
my
mom
needed
can
hear
me
beauty,
you
good,
so
I'm
trying
to
I'm
taking
notes
as
well
as
trying
to
follow
along.
Are
you
suggesting
that
we
write
a
framework
document
that
then
defines
all
this
stuff
within
our
group
that
then
conforms
with
whatever
redefinitions
and
history
writings
taking
place
elsewhere?
No.
A
Ad
was
basically
as
part
of
the
second
charter
round
and
to
bring
sanity
into
you
know
what
beer
should
focus
on
and
what
should
be
done
rather
in
this
in
the
specialized
working
groups,
for
it,
like
you,
know,
I
remember
correctly.
Further
extensions
in
iGPS
should
be
done,
and
eleazar
and
traffic
engineering
architecture
that
go
beyond
the
actual
tree
building
should
be
done
in
tees.
A
So
already,
two
years
ago,
I
put
an
initial
version
of
that
framework
into
T's
educated,
the
working
group
to
the
to
it,
so
that,
if
they're
interested
to
discuss
the
actual
tree
building,
they
could
in
beer,
but
the
follow-up
work
for
the
whole
framework,
or
so
would
logically
be
in
T's
because
it
doesn't
the
tree
building
anymore.
It
would
be
queuing
mechanisms,
it
would
be
controller
mechanisms,
whatever
else
it
is,
and.
C
B
B
Agree
I
agree
completely.
The
question
isn't
technical
questions,
procedural
right,
stand
on
it
and
say:
they're,
not
gonna,
let
it
fly
unless
it
syncs
with
their
read
definitions
of
terms,
we're
gonna
be
stuck,
but
let's
it's
in
the
queue
right
now.
I
think
you've
done
a
great
job,
clarifying
all
that
just
in
full
disclosure.
My
suggestion
of
te
meaning
tree
engineering,
which
I
thought
made
a
lot
of
sense,
ruffled
lots
of
feathers
over
there,
apparently
I
wasn't
playing
nice
I
don't
get
it.
I
was
just
following
technical
terms
and
it
makes
a
shitload
of
sense.
B
A
Think
Lou
raised
the
concern
right
so
and
I
was
trying
to
explain
through
the
text
that
he
didn't
like
that,
I
withdrew.
How?
Basically
you
know.
Ultimately
it
makes
a
lot
of
sense
to
say
there
is
a
veer
tree
engineering.
That's
the
term
that
the
working
group
has
come
up.
It
stands
on
it
own.
It
can
be
used.
A
A
B
C
The
issue
that
I
raised
was
that
the
RAF
just
called
te
traffic
engineering
without
defining
anything
related
to
traffic
engineering
and
I,
stated
a
personal
preference
in
my
initial
mail,
saying
that
I
sorry,
the
initial
mail
to
the
public
mail,
that
I
would
love
for
it
to
include
that
text,
but
that's
a
personal
statement
as
the
co-chair
of
T's.
You
know
if
you're
gonna
use
the
te
term,
you
have
to
use
the
te
term
properly.
C
That
was
my
complaint.
I'll
also
note
that
it
is
in
your
charter
to
define
your
traffic
engineering,
not
some
other
term,
but
that's
what's
in
the
Charter,
so
you
know
from
my
perspective,
I
think
you
should
define
beer
traffic
engineering
and
what
it
is,
and
the
forwarding
mechanism
for
I
mean
that's.
What's
in
the
Charter,
you
should
follow
through
with
it
with
your
Charter
I
suggested
that
it
wouldn't
be
that
hard
to
take
the
current
document
and
do
that
and
in
fact
it
add
some
text.
C
Yes,
it's
I'd
say
it's
probably
a
month
later
than
I
said:
I
would
get
it
out,
but
you
know
I
think
everyone
can
understand
that
these
are
not
normal
times.
So
from
from
my
standpoint,
I
think
you
should
fall
through
without
seeing
your
Charter
define
the
forwarding
plane
mechanisms
for
beer
traffic
engineering.
If
you
don't
want
to
do
that,
that's
between
you
and
your
ad
I
don't
think
you
should
call
something
beer
te.
Unless
it
does
that
you
know.
Other
working
groups
like
spring
have
defined
similar
mechanisms
and
we've
had
similar
conversation.
C
They
came
up
with
an
their
turn.
If
you
don't
want
to
define
traffic
engineering,
I'd
say,
don't
introduce
a
new
term
use
that
use
the
term
that
they're
using
path
steering
is
old.
Policy-Based
routing
is
a
older
term
they've
chosen
to
use
that
older
term
I
think
it.
You
know
the
some
of
the
original
internet
RFC's.
You
can
even
find
the
term
policy
based
routing
or
policy
routing.
So
you
know,
if
you
don't
want
to
define
te
in
this
group.
B
This
is
Greg
as
an
individual
contributor.
The
the
Charter
was
written
back
when
traffic
when
beer
te
was
beer
traffic
engineering,
so
the
Charter
reflects
the
terms
of
the
time
the
push
back
came
externally
and
we
had
to
change
the
terms.
So
logically,
it
sounds
like
that
would
possibly
change
the
Charter
too,
if
he
followed
through
with
that
process,
so
either
way
could
be
taken
and
in
terms
of
policy
routing.
This
is
not
routing
at
all.
This
is
just
simply
forty.
B
D
C
Is
an
RFC
young
on
the
term
and
the
principles
it's
RFC
3272.
There
is
a
this
document
going
on
because
there
have
been
other
complaints
that
it's
not
well-defined
enough.
So
this
that
we're
trying
to
improve
the
definition
in
terms
of
term
squatting.
You
know
every
s
has
its
own
terms
that
it
tries
to
use
consistently.
You
know,
MPLS
is
one
I
GP
is
one.
Ip
is
another
one.
You
know,
I
think
s
do
is
tend
to
be
pretty
sensitive
to
redefinition
of
their
own
terms.
We're
within
the
ATF.
C
You
know,
T's
is
an
IETF
working
group.
You
know
if
you
also
change
your
charter,
move
away
from
traffic
engineering,
I
think
that's
a
fine
discussion
at
the
iesg
level.
I,
don't
really
want
to
participate
in
that
there's
an
ad
on
the
line.
You
can
comment
on
that.
I
really,
don't
think
we're
talking
a
whole
lot
of
text
to
get
you
there
and
I've
sent
I've
sent
some
suggestions
for
this
document.
C
A
I
think,
given
how
the
the
beer
you
know,
free
engineering
that
that
were
defining
here
was
the
intent
of
what
the
working
group
wanted
to
do
and
not
staff
beyond
it,
and
at
that
point
in
time
it
was
called
traffic
engineering
I
would
agree
with
Greg
that
you
know
were
very
much
right
now
within
our
charter
scope.
That
was
just
a
renaming.
I
think
the
renaming
helps
to
distinguish
you
know
what
we're
doing
here
from
a
full
traffic
engineering
solution
and
I
think
that
distinction
should
be
made
very
clear
and
I.
A
Think
that
we're
you
know
if
or
where
a
full
traffic
engineering
would
be
done
subject
to,
as
you
said,
where
our
T's
likes
it
or
whether
beer
likes
it.
That's
a
separate
discussion
that
should
go
through
that
framework
document.
The
text
that
you're
suggesting
here
you
know
I've
tried
to
read
it
here
in
parallel.
A
The
main
issue
really
is
that,
like
in
segment
routing,
the
whole
idea
is
to
be
lightweight
in
the
forwarding
plane,
and
so
these
traditional
mechanisms
that
you're
referring
to
to
have
four
every
flow
for
every
hop,
let's
say
a
separate
queue,
or
you
know
internally
regulator
or
these
things
right.
Those
are
actually
open
research
issues.
You
know
what
we've
proposed
into
debt
net
to
reduce
the
overhead
at
card,
so
that
would
clearly
be
something
which
you
know
if
we
wanted
to
stick
to.
C
A
Know
I
wrote
similar
I
felt,
I
wrote
fairly
similar
texts
in
one
or
two
in
version,
all
six
which
you
rejected,
but
without
you
know
going
into
details
of
explanation
and
I
was
especially
you
know,
referring
to
mechanisms
to
do
it.
Stateless
Lee,
you
know
it's
an
informational,
stuff
and
I
would
have
loved
to
see
more
specific
opinion
from
you,
because
you
know
if,
if
such
a
text
is
added
here,
I
think
it
would
be
lovely
to
to
also
include
suggestions
of
the
options
that
maintain
the
stateless
nature
right.
So
that's
that's.
C
D
It's
okay.
We
have
done,
but
here's
here's
a
rough
framework
that
I
see
that
you,
gentlemen,
have
to
agree
on
I'm,
getting
loose
point,
I'm,
getting
perlis
point
and
I'm
getting
also
Gregg's
point.
You
know
that
the
terms
then
were
when
the
Charter
was
defined
were
slung
around
slightly
loosely,
so
I
think.
The
first
question
is
whether
the
3272
is
a
binding
definition
of
traffic
engineering.
It's
an
informational
draft!
It's
fairly
comprehensive
I,
see
loose
coin.
That,
if
you
want
to.
D
If
this
is
the
binding
definition-
and
you
want
to
call
this
thing
traffic
engineering,
then
you
have
to
at
least
explain
which
parts
of
that
concept
you
address,
or
you
don't
address
right
so
that
that
needs
text.
You
can
just
slice,
take
a
small
slice
and
colleague
traffic
engineering,
so
that
I
think
is
what
has
to
be
agreed
on
at
the
meta
level.
If
they're
people
72
is
not
binding,
there
is
basically
no
definition
of
term
traffic
engineering,
thereby
so
you
can
call
anything
traffic,
engineering,
I.
A
My
proposal
would
be
to
basically
include
the
text
that
Lou
has
done
with,
hopefully
minimal.
You
know
extension
that
is
basically
the
traffic
engineer.
That's
basically
what
I
had
in
1.1,
but
basically
keep
this
document
called
tree
engineering
and
make
it
clear
through
the
text
that
you
know
this
beard.
Free
engineering
is
a
possible
part
in
an
overall,
be
your
traffic
engineering
solution
and
I.
Think
you
know.
A
D
That's
a
pretty
productive
suggestion.
Lou
you
think
that
is
a
path
we
should
progress
along
so
basically
take
the
3270
to
which
you
suggest
seams
with
the
text
as
the
binding
definition
and
then
have
in
there.
Three
engineering
drama:
explain
which
slice
of
the
traffic
traffic
engineering
that
addresses
and
what
are
the
restrictions
in
you
know,
in
a
full
traffic
engineering
framework,
I.
C
C
I
think
I'll
defer
to
the
iesg
of
whether
they
want
to
allow
a
redefinition
of
something
that's
a
pretty
old
and
understood
term.
In
understood,
expansion
of
the
letters
T
E
in
the
IETF,
you
know
I
I
think
personally,
I
think
it
would
be
pretty
obvious
that
I
think
having
that
redefinition
is
a
very
bad
idea.
Just
like
renaming,
IP
or
MPLS
or
om
would
be
a
very
bad
idea.
C
A
C
Discussion
we
had
exactly
the
same
discussion
with
srte
and
you
know
through
the
iesg
we
ended
up
saying
you
know
you
can't
call
it
unless
you're
doing
traffic
engineering,
you
can't
call
it
t.
We
did
the
same
thing
at
the
same
argument
and
discussion
with
with
with
with
sr
I.
Would
I
really
wasn't
involved
in
that
discussion?
Very
much
so
I
would
expect
that
the
discussion
ended
up
the
same
way,
but
you
know
that's,
for
you
guys
to
go
fight,
I!
A
A
A
Then,
no
because
I
went
through
the
process
of
asking
the
working
group.
We
have
made
a
working
group
choice
on
that.
So
I
don't
think
that
on
the
naming
it
makes
sense
to
regurgitate
multiple
times
right.
So
if,
if
the
iesg
wants
to
force
something
on
us
on
the
naming,
let's
have
them
do
it
at
that
point
in
time,
I
think
the
working
group
has
made
a
choice
and
I
don't
really
care
about
naming
by.
C
A
Fine,
if
we,
if
we
finish
the
last
call
after
we've,
you
know
agreed
on
you
know
your
section
that
I'm
going
to
you
know
adopt,
and
hopefully
you
can
try
to
get
feedback
a
little
bit
faster.
Now
on
that
one
so,
and
then
we
basically
pass
the
Oh
a
to
the
to
the
IDF
right.
Is
they
they
can?
You
know:
go
over
the
naming
as
long
as
they
want
I.
Don't
care.
C
C
A
Again,
right
now
here
is
just
abbreviation,
which
is
overloaded.
25%
of
official
IP
abbreviations
are
overloaded.
Sr
means
sender
report,
not
source
relative,
knock
segment,
routing
right,
it's
an
overloaded
abbreviation,
and
we
call
like
three
engineering.
It's
a
great
term
for
this
type
of
tree
building.
The
fact
that
the
abbreviation
te
is
overloaded
has
nothing
to
do
with
is
claiming
to
be
a
traffic
engineering.
E
E
I
think
that
you
have
to
do
probably
with
the
overloading.
So
one
thing
that
I
need
to
obviously
do
is
since
Deborah
had
was
the
one
who
brought
up
the
one
was
a
shoes
as
well.
Right
was
concern
about
this
and
she's,
not
in
the
line
to
say
something:
I
want
to
talk
to
her
and
talk
to
Martin
who's
the
spring
so
that
we
can
have
a
consistent
I
saw
the
beginning
right.
We
need
to
be
consistent
in
terminology
and
everything
else.
I.
E
Understand
the
point
that
Greg
made
and
others
made
around
the
intent
or
what
may
have
been
intended-
I,
of
course,
wasn't
the
ad
of
beer
that
time
either
of
what
may
have
been
intended
in
the
Charter
to
talk
about.
So
we
can
figure
that
out.
We
can
I,
don't
know,
look
at
the
history
refresh
it
whatever
and
figure
that
out,
but
the
most
important
person
would
be
the
consistency.
I
don't
hear-
and
this
is
not
a
call
for
me
to
make.
But
I
don't
hear
a
lot
of
enthusiasm.
E
A
As
far
as
term
thank
y'all,
bro
I
mean
as
far
as
the
term
consistency
is
concerned.
It's
would
just
be
lovely
if
there
was,
you
know,
equal
treatment
right
and
given
how
many
you
know
terms
are
overloaded
that
SR
isn't
even
listed
in
in
the
list
of
official
ITF
abbreviations,
I.
Think
we're
doing
a
lot
of
brouhaha
here,
which
you
know
I
haven't
seen
on
any
other
place
in
the
idea.
C
A
A
B
Acoustic,
aha:
this
is
great
again
as
an
individual.
What
we're
trying
to
do
is
number
one,
create
a
document,
that's
clear
and
consistent
and
can
be
used
for
implementation.
B
B
We
are
literally
engineering
a
tree
in
the
header
of
a
packet
based
on
nothing,
that's
routing,
nothing.
Unicast
related.
As
Torres
pointed
out.
This
is
multicast.
It's
multi-point
we've
had
decades
of
trying
to
shove
our
terms
or
borrow
term
from
unicast
that
never
made
sense
and
we've
got.
We
got
shitty
technologies
that
are
built
on
these
previous
expectations.
We're
starting
clean
here,
completely
clean,
and
it's
a
three
that
we've
engineered.
It
just
makes
sense.
We
call
it
trees.
What
are
we
doing
with
the
trees?
D
Okay,
gentlemen:
I
think
we
have
to
slowly
cut
off
the
stuff.
Sorry
to
be
the
grown-up.
We
are
like
five
minutes
before
the
hour
on
the
ten
minute
presentation.
I
think
the
action
items
here
would
be
that
result
in
ad
is
G
level
I'm
sympathetic
to
lose
point.
You
know
he
would
start
to
talk
about.
We
saw
the
reservation
right
all
of
a
sudden.
We
took
the
te
right
and
what
do
we
do
then?
On
the
other
hand,
yes,
the
tree
engineering
seems
to
be
completely
consistent.
D
D
D
Process
is
that
the
ones
we
signed
the
stuff
is
working
group.
Do
we
bounce
you
off
to
the
IHC
reviews
and
then
the
discussion
happens
in
their
context,
which
is
wider
right,
I
think
that
loose
that
says
a
lot
of
value,
just
as
you
know
outlining
how
that
relates
and
which
piece
of
the
overall
traffic
engineering
architecture
that
addresses
or
not
cannot
hurt
at
all
already
as
guidance
to
the
I
use.
And
then
we
see
how
that
plays
out
there.
C
A
B
F
F
All
right,
so,
hopefully
you
see
my
slides
now
so
just
a
very
quick
update,
so
the
MLB
Draft
in
the
last
night
yes
I
was
talking
about.
This-
is
the
same
slide.
I
used
last
idea,
so,
basically
for
Tim
overlay,
we
decided
that
it
will
be
good
to
have
information
about
the
the
sender
of
the
message
encoded
in
the
message
itself,
so
that
you
know
that
B
prefix
before
ID
and
supplamine,
and
we
decided
that
they
want
to
do
the
same
for
our
GP
and
MLB
as
well.
F
So
last
night
Jeff
had
presented
his
proposal
in
the
pin
working
group
for
extending
Argentine
MLD,
and
that
has
now
been
adopted.
That's
the
just
IGF
him
in
PMO
the
extension.
The
initial
rest
on
that
draft
did
describe
not
just
how
to
extend
Argentine
movie,
but
also
the
actual
beer
extension.
That's
we
discussed
last
time
it's
better
to
have
that
extension
in
this
draft
in
a
year
working
with
drafts,
so
the
new.
What
is
new
is
that
Tim
Mischel
up
to
this
draft
that
only
discusses
the
extension
mechanism
itself
and
then
in
this
draft.
F
So
what's
next
in
a
pin
working
group
you're
meeting
here
a
week
from
now
I
hope
many
of
you
can,
although
you
can
join
it
in
working
with,
we
will
discuss
the
pin
draft.
One
thing
that
they
might
have
to
discuss
is
whether
the
extension
should
be
like
a
T&V
mechanism,
American
and
multiple
extensions
or
just
a
single
extension
type,
which
is
now
in
a
draft
but
I
hope
we
can
conclude
quickly
in
the
pin
working
group
and
here
in
beer,
don't
think
there
is
much
to
discuss.
F
F
F
F
D
Giving
you
a
unique
who
is
originated
that
I'm,
basically
thinking
along
the
lines
of
know,
things
like
v6
encapsulation
coming
in,
and
people
running
before,
prefixes
at
the
same
time,
and
so
on,
I'm
not
saying
must
be
done.
I'm
just
I
was
just
looking
on
it.
Actually
what
we're
doing
and
how
people
are
deploying
it?
What
kind
of
tricks
to
prepare
I
realized
that
I
mean
Istanbul
also.
F
F
Yeah
so
I
think
yeah
I'm
happy
for
any
any
comments.
I
can
get
otherwise.
I
would
say
mostly
waiting
for
the
team
working
with
to
sit
inside
exactly
what
the
general
expenses
mechanism
can
look
like
and
then
basing
that
they
have
to
decide.
You
know,
but
the
other
thing
is
they
may
have
to
change
this
option
into
being
a
TLV
kind
of
thing.
If
that's
necessary
and
you
need
to
decide
yeah,
they
won't
turn
now
multiple
prefixes
here.
One
thing
I
may
be
realized
a
little
bit
it's
what
about
address
family
you
know.
F
Should
we
just
assume
that
if
they
get
an
urgent
email
system,
the
address
somewhere
will
be
a
prefix
of
all
this
before
and
missing,
you
know
we
fix
if
it's
MOV,
or
is
it
better
to
actually
encourage
a
family
here,
I
think
for
PIM
at
least
the
decision
was
to
just
say
that
the
if
I
remember
correctly,
that
did
not
just
the
message
header
that
could
be
useful
to
have
accessibility.
Perhaps.
B
Yeah
secure
we're
at
the
top
of
the
hour
on
a
30-minute
meeting
we're
going
into
a
subject.
That's
gonna
require
lots
of
discussion
on
a
draft
that
just
got
revved.
So
what
I'd
like
to
propose
and
we'll
get
a
sense
of
the
room
here
before
we
move
on
I
would
like
to
have
this
discussion,
but
I
would
like
you
to
be
prepared
for
it,
and
I
would
like
a
timeslot
carved
out
when
we're
not
pushed
against
the
wall,
and
we
can
openly
discuss
without
those
time
barriers.
B
So
my
suggestion
would
be:
let's
move
this
to
an
interim.
Even
you
know
what
sway
to
the
rest
of
working
groups
for
the
107
Ramotar
kind
of
fizzling
out
and
we'll
schedule
one
out
in
a
couple
of
weeks
where
we
can
have
the
interim
working
group
meeting
just
discuss
the
v6
rex
draft
reasonable.
Or
do
you
want
to
continue
today?
I.
B
There
we
go:
okay,
I
was
afraid
that
was
happening
already
and
kind
of
forced
us
into
that
doing
wrong.
Are
you?
Okay,
with
that?
I
mean
I'm,
sorry
for
dumping
this,
but
you
know
we
wedge
you
in
right
here
at
the
last
we
push
another
30
minutes
and
we're
still
against
the
wall.
I'm
hoping
you
would
see
if
we
dedicated
a
interim
just
to
that
draft,
that
we'd
have
a
better
discussion
and
a
better
opportunity
for
you
to.
You
know
express
your
case:
reasonable,
okay,
okay,
Wow.
Anyone
else
have
feedback
on
that.
Any
more
input.