►
From YouTube: IETF92-SUNSET4-20150325-1520
Description
SUNSET4 meeting session at IETF92
2015/03/25 1520
A
If
you
haven't
seen
it
yet
this
week.
This
is
the
note.
Well,
it
looks
the
same
as
it
has
in
every
other
working
group
you've
been
in.
You
should
read
it
at
some
point
and
understand
what
it
means.
This
might
not
be
that
time
we
do
need.
We
have
a
jabber
scribe
bones
here.
We
do
still
need
a
note
taker.
We
can't
really
go
on
until
we
get
one,
so
we
get
to
sit
in
uncomfortable
silence
until
someone
volunteers.
A
A
C
B
A
We
really
want
to
spend
some
time
talking
about
how
we
continue
to
make
board
progress
on
the
working
group
itself.
Talk
about
future
work
if
we
think
there's
future
work
done
or
take
beyond
these
two
drafts
and
also
sort
of
gauge
interest
on
the
working
group.
Do
we
need
to
continue
and
we
have
the
people
that
are
willing
to
contribute
to
reviewing
documents,
writing
documents
and
participating
on,
especially
on
the
mailing
list,
in
order
to
help
us
make
forward
progress
there.
C
Jeff
Tom
leaves
the
o
trong
virginie,
so
I'm,
not
an
author
of
gap.
Analysis
actually,
but
I've
been
helping
for
the
netbook
the
last
step
of
that
that
document.
Actually
it
was
almost
ready
to
publish
it
seemed
pretty
stable.
Some
text
suggested
by
Lee
Howard,
was
added
in
there.
That
was
a
related
to
Jeff
George,
a
PVC
support.
So
basically
that
text
says
that
we
should
do
a
review
of
the
existing
IRC
and
basically
figure
out
figure
out
if
there's
anything
that
would
prevent
a
proper
ipv4
sunset
in
the
existing
specifications.
C
So
this
document,
the
gap
analysis,
is
almost
ready
for
last
column
unless
someone
suggests
that
it's
not
ready
or
there
something
missing.
So
the
next
step
would
be
what
has
been
suggested.
This
may
be
having
this
document
reviewed
by
people
who
actually
do
ipv6
only
deployment
and
getting
their
feedback
if
there's
anything
any
gap
in
the
gap
analysis
basically,
but
besides
that
it
would
be,
would
be
ready
for
La
Scala.
Any
question
comment
on
capitalizes
and
it's
possible
last
column
and.
A
I'd
like
to
try
and
get
a
couple
of
volunteers
to
make
a
good
substantive
review
of
the
document.
We've
had
folks
do
that
in
the
past,
but
I
think
that'd
be
a
good
step
in
terms
of
sort
of
getting
this
back
moving
again.
So
is
there
folks
willing
to
volunteer
to
read
and
review
the
document
and
post
post
the
review
to
the
list
and
your
name
for
the
minutes,
Luke
on.
B
C
So
no
ipv4
have
been
added
as
a
note
on
this
one.
We
make
several
changes
so
a
lot
of
addition.
On
that
side.
We
also
focus
more
following
Toronto
on
the
no
ipv4
option
for
dhcpv6
I.
Think
that's
one
of
the
direction
that
was
suggested
in
Toronto.
Then
there
are
other
things,
of
course,
to
to
add.
Looking
at
the
minutes
from
Toronto
I
wasn't
there,
but
a
few
thing
I
could
distill
from
this
discussion.
C
One
of
them
was
that
we
need
more
use
case
steps
basically
into
ipv4
Sun
setting
and
how
this
would
be
used.
We
don't
want
it
on
and
off
switch,
basically
something
that
would
turn
off
ipv4.
All
of
a
sudden.
Some
of
the
comments
that
were
made
was
that
there
are
still
ipv4
devices
activate
active
in
the
home
and
even
if
a
nice
p
does
not
provide
ipv4
anymore,
it
might
be
desirable
for
a
lot
of
people
to
keep
ipv4
running
locally.
So
we
want
to
add
these
options.
C
Different
scenarios
and
step
in
the
ipv4
Sun
setting
that
would
be
desirable,
so
we--it's
mentioned
their
local
connectivity
is
one.
One
of
the
question
on
that
side
is:
do
we
want
to
keep
ipv4
link-local
for
that
or
do
you
want
the,
for
example,
the
home,
rather
to
continue
giving
out
the
hcp
v4
addresses,
while
not
having
upstream
connectivity,
which
one
is
the
best
option?
C
C
Yeah
so
I
think
in
the
last
last
x
minute.
We
had
also
some
basic
some.
Some
people
asked
to
have
more
details
on
the
timing
and
the
different
steps,
so
we'll
try
to
include
that
in
the
next
version
of
the
document
as
well.
There
were
also
some
questions
about
security
considerations.
Could
this
be
used
for
attacks?
If
you
have
ideas
on
that
side,
that
would
be
willing
to
hear
them
the
less
we
heard
a
few
ones
so
far,
especially
on
Ras
that
shouldn't
be
used
to
carry
the
know.
C
So
the
idea
would
be
to
find
some
middle
ground
for
for
ipv4
usage.
Most
in
the
home,
we
haven't
found
any
scenario
for
the
enterprise.
Yet,
if
you
come
up
with
ideas
of
our
v4
would
be
could
be
used
in
an
enterprise
scenario.
Locally
haven't
heard
any
scenario
around
that,
but
that
might
be
a
possibility.
C
Yeah
there's
the
manual
configuration
of
a
ride
as
well.
If
you,
what
would
be
the
behavior
of
a
router
home
cpe,
something
off
the
shelf
or
maybe
a
bit
old
that
has
an
option,
turn
off
ipv4,
what's
the
exact
behavior
that
would
be
expected.
In
that
case,
we
should
put
that
in
the
document
as
well
and
besides
that,
it's
pretty
much
pretty
much
that
actually.
So.
C
A
We
actually
should
be
doing
because
then
at
least
we
can
say,
the
working
group
has
discussed
this
at
length
and
we
believe
that
this
is
the
right
way
to
go,
and
here
are
reasons
why
I
don't
think
we
were
at
that
point
when
we
asked
for
the
review
in
six
in
v6
ops
before
and
that
resulted
in
discussion
that
was
kind
of
all
over
the
map.
It
provided
us
some
useful
feedback,
but
I
think
at
this
point.
A
What
we
need
is
for
some
folks
to
look
at
this
and
see
whether
or
not
it's
something
they
believe
is
the
right
course
of
action,
and
if
not
talk
about
why
they
think
not,
and
you
know
that
we
can
actually
start
having
some
discussion
around
how
to
get
this.
To
a
point
where
we
feel
confident
that
the
working
group
it
has
consensus
behind
it,
then
we
can
kind
of
push
this
forward
again
for
first,
some
additional
reviews
so
along
those
lines,
I'm
looking
for
volunteers
to
review
this
document
as
well.
A
Originally,
we
had
had
integrated
several
drafts
together,
including
one
that
had
some
IPR
encumbrance
and
the
last
time
that
we
discussed
this.
The
consensus
was
to
remove
that
and
and
have
it
be
a
separate
document
in
order
to
eliminate
any
confusion
or
concern
there.
That
document
has
been
peeled
off
and
is
now
in
the
individual,
individual
submission,
Q
and
so
what's
remaining
is
the
other
non
IPR
encumbered,
CGN
port
allocation
stuff.
A
A
Well,
the
cable
ABS
document,
well
the
authors
that
that
originally
wrote
that
that
section
had
had
originally
their
own
document
that
talked
about
a
specific
port
allocation
method
that
had
some
cablelabs
IPR
associated
with
that
entire
section
of
the
document
was
removed
and
put
back
as
its
own
separate
document
now,
and
so
the
document
stands
alone,
with
other
types
of
port
allocation
methods
without
requiring
that
one,
okay
and
so
I.
The
only
thing
I
do
see
is
that
the
system
still
is
having
an
IPR
file
on
it
and
I'm
not
sure
entirely.
That's.
B
A
B
I
think
the
right
way
to
handle
this,
because
the
way
that
I
PR
works
is
kind
of
a
little
bit
arcane.
What
I
would
suggest
that
you
do
is
actually
do
a
new
working
group
document
or
I.
Guess
it's
still
an
individual
submission.
So
do
an
individual
submission
with
a
new
name
and
ask
the
people
who
submitted
the
original
IPR
to
look
at
the
document
and
see
if
they
still
want
to
submit
IPR
on
it.
B
And
hopefully
the
answer
will
be
no
and
then
you'll
be
done,
because
otherwise
just
there's
no
way
to
just
take
IPR
off
a
document
and
and
what
you
did
sounds
like
it
was
exactly
the
right
thing
to
do,
but
we
just
need
to
make
sure
that
everybody
agrees.
It
was
the
right
thing
to
do
and
we
don't
wind
up
in
a
you
know.
B
A
B
D
Have
to
make
an
explicit
decision
as
chairs
as
to
whether
it's
replaced
by
or
not
and
I
think
Ted
suggestion
was
change.
The
file
name
first
then
adopt
it
so
that
it's
that
such
the
new
one
does
an
individual
summation
is
replaced
by
the
working
group
documents.
You
have
the
replaced
by
history.
There
I
think
that
was
your
suggestion.
Correct.
A
And
then
the
other
there's
a
there's,
a
relatively
new
document
dealing
with
ipv6
only
DNS,
it's
a
double-0
draft.
It
needs
more
reviews,
it's
fairly
limited
at
this
point,
but
this
would
be
the
other
doctor
that
we
would
be
considering.
This
is
not
technically
a
charter
item
for
us,
but
I
think
it
fits
in
the
right
area
of
discussion
in
terms
of
talking
about
how
you
do
dns
in
either
an
ipv6
only
or
at
ipv6
only
plus
transition
technology
kind
of
world.
A
But
after
we
leave
the
meeting,
we
get
basically
no
discussion
on
the
mailing
list
at
all,
which
leads
me
to
believe
that
we've
got
a
lot
of
folks
that
are
coming
in
because
sunset
or
looks
mildly
interesting.
But
it's
not
interesting
enough
for
them
to
actually
sign
up
on
the
mailing
list
and
continue
participating.
A
You
know
in
conversations
that
I've
had
with
the
working
group
chairs
in
the
80s.
The
sense
we
kind
of
got
was
that
this
was
a
little
too
far
out
on
the
edge,
because
ipv6
only
is
a
pretty
new
thing
for
most
folks
they're,
not
operating
ipv6,
only
networks
there
any
yet
they're
operating
dual
stack
networks
or
they're
just
now
considering
rolling
out
v6,
and
so
this
isn't
something
that
people
are
really
thinking
about
yet,
and
so
people
didn't
think
they
could
contribute
or
whatever
but
I,
think
in
the
last
12
to
18
months.
A
What
we're
talking
about
here
is
both
talking
about
things
that
might
be
necessary
in
order
to
turn
off
ipv4
in
a
network,
given
that
most
of
the
protocols
the
IETF
has
design
were
intended
to
be
very
robust
and
very
resilient.
A
lot
of
them
don't
have
off
switches
per
se
and
so
trying
to
go
in
and
tell
them
that
there
is
no
ipv4
and
there
never
will
be
there.
A
There
are
some
details
to
work
through
around
that,
and
also
considering
when
you're
running
an
ipv6
only
network
are
there
still
problems
where
features
are
missing
in
the
protocols
or
other
things
that
don't
work
properly.
There's
about
the
combination
of
operational
considerations
and
protocol
considerations
there,
and
so
if
this
is
something
you
think
is
important
for
the
ITF
to
be
considering,
it
would
be
useful
for
you
to
come
to
the
mic
and
say
so
or
if
you
don't
think
so
say
why.
E
Lee
Howard
I
do
think
this
is
really
important.
I
think
this
is
actually
probably
the
most
important
thing
on.
Etf
is
working
on
I.
Think
it's
premature,
which
is
a
delightful
thing.
I
think
that,
yes,
there
are
people
deploying
ipv6,
only
networks
and
segments
of
networks.
They
generally
appear
as
weld
gardens
right
now
are
also
things
that
we
refer
to
sometimes
as
ipv6,
only
which
are
actually
I've
native
ipv6,
plus
something
with
ipv4
next
slide
right
now,
I'm
not
saying
advanced
immed.
I
mentioned
that,
that's
there.
E
D
So
they
favor
I'm
not
going
to
directly
answer
your
question,
but
I
want
a
answer
part
of
her
and
respond
to
or
add
to.
I
guess
I
agree
with
one
of
at
least
points,
which
is
one
of
the
other
benefits
that
this
working
group
has
had.
Besides
the
question
of
how
you
get
to
ipv6,
only
well,
specifically
the
gap
analysis
document,
which
I
think
was
the
previous
slide.
D
Okay,
and
so
that
benefit
is
that
whenever
somebody
else
comes
along
to
says,
I'm
going
to
propose
this
thing
and
I
make
it
be
ipv4
only
okay,
then
we
can
direct
them
to
this
work
group
and
say
either
you're
doing
the
wrong
thing
or
there's
something
that
needs
to
go
in
the
gap
and
document.
So
as
long
as
we
have
the
gap,
analysis
document
is
still
open
that
serving
a
function
which
is.
Is
there
anything
else
that
needs
to
be
in
there?
D
Because
if
you,
anybody
else
is
doing
something
before
only
then
either
it's
already
covered
in
that
document
and
we've
got
a
gap
dead
in
the
gap
analysis
document
as
soon
as
we
declare
that
we're
done
with
that
document,
then
perhaps
going
dormant
in
the
hopes
that
well
are
we
done
well,
we
don't
know
until
the
gap
stop
coming
right
and
so
not
closing,
but
going
dormant
I.
Think
as
we
suggest,
you
is
probably
the
right
thing
and
not
closing
because
still
provides
an
avenue
to
say
if
somebody
else
is
doing
something.
D
That's
ipv4
Lenoir
brings
that
proposal
into
the
IETF
then
will
either
come
back
and
say
no,
you
didn't
listen
or
there's
a
gap
that
it
needs
to
be
added
into
here
and
maybe
there's
some
work
there
and
at
least
keeping
a
mailing
list
open
to
collect
that
sort
of
stuff
and
respond
to
would
be
beneficial.
That's
my
opinion.
Okay.
F
Michael
Abramson
yeah
just
have
to
agree
that
this
is
important.
Work
I
want
to
be
able
to
provide,
or
you
know
how
once
someone
show
up
and
not
have
to
give
them
my
TV
for
a
dress,
and
they
then
use
some
kind
of
translation
mechanism
in
the
network
in
order
to
reach
ipv4
space
for
services.
I
don't
want
to
I
want
to
be
able
to
get
away
from
dual
stack
as
soon
as
possible.
Basically,
this
is
practically
feasible,
would
devices
and
operating
systems,
and
so
on
so
yeah
we
really
need
this
sounds.
A
A
Analysis
draft
was
observing
that
the
IETF
has
done
an
ipv6
gap
analysis
in
the
past
and
that
it's
sort
of
sitting
and
no
one
really
knows
whether
the
gaps
are
resolved
or
not,
and
that
there
are
about
3,000
rfcs
according
to
the
numbering,
not
in
terms
of
actual
numbers
of
our
sees
that
have
never
been
looked
at
with
this
context
in
mind,
because
that
RC
or
that
that
review
was
done
around
RFC
3300
and
so
there's
more
work
to
be
done
there.
But
you
know
closing
out
a
review
and
then
statically.
G
Okay,
Davy
so
from
VI,
and
I'm
the
author
of
the
sunset
for
360
90s
I
to
work
is
the
latest
start
and
because,
from
the
very
beginning,
I
found
the
s
is
very
by
ed.
It's
more
either
more
how
to
say
to
move
to
that
v6
owning
environment,
because
the
application
context
is
an
independent
from
the
IP
layer
context,
so
so
I
I'd
start
to
want
to
fund
some
problems
or
some
issues
related
to
the
deployment
went
up:
basics
owning
the
s
in
the
network.
G
Actually,
there
are
some
some
transition
technologies,
have
the
v6
owning
dance
functional
in
devices
where
it's
act
in
proxy
manner.
So
that's
the
way.
The
reason
I
come
up
with
to
to
write
down
the
draft
to
address
some
issues.
I
will
continue
to
working
on
that
part.
But
I
have
a
question
because
she's
a
overlapping
topic,
one,
is
only
six
and
before
one
is
in
the
ass,
so
I
want
to
know.
Is
it
was
allowed
to
document
that
continued.
The
document
in
this
working
group
or
move
to
the
SOP
working
group.
C
Just
only
well
I
believe
you
might
have
a
more
friendly
environment
to
discuss
here
then
in
the
60s
up
sexually,
but
pressure.
I
read
this
and
I
thought
it
was
actually
interesting.
Once
we
we
detail
a
bit
more
of
the
steps
in
before
sun
setting.
I
believe
that
the
last
step
is
actually
not
only
removing
before
on
the
host,
but
also
removing,
maybe
second
access
to
before,
which
is
something
that
was
discussed.
C
I
think
it
was
by
a
camera
on
something
he
didn't
want
that
to
happen,
but
that
would
be
maybe
the
last
step
and
dns
might
be
part
of
the
last
step.
So,
for
example,
when
you're
getting
a
request
for
record
and
if
you
are
doing
in
any
requests
or
with
requests,
you
shouldn't
be-
you
shouldn't
have
in
the
answer
all
the
v4
information.
If
you
know
in
advance
that
you
don't
need
it,
so
I
thought
it
was
an
interesting
concept.
So
personally,
I
think
you
should
be
continuing
to
discuss
this
in
sunset.
For
okay.
A
So
unless
there
are
other
comments
on
the
stuff
we've
talked
about
so
far,
the
other
thing
I
wanted
to
bring
up
here
was
the
there's
been
a
conversation
between
the
the
working
group
chairs
of
visa
and
v6
ops
and
sunset
for
with
some
eighties
copied
about
this
idea
of
ipv4
as
a
service.
You
can
see
the
premise
here,
and
you
know,
of
course,
because
this
is
a
slot
I
lifted
from
fred
baker.
A
It's
focused
on
the
operational
side
of
this,
because
v6
ops
is
an
operational
working
group,
but
there
may
be
more
to
it
than
that.
There
may
actually
be
some
additional
protocol,
standardization
work
or
other
things
like
that.
It
makes
it
a
better
fit
here,
and
so
I
am
curious
to
see
what
people
think
either
80s
or
otherwise
about
where
this
belongs
and
whether
it's
interesting
work.
E
Lee
Howard,
not
an
ad
but
co-chair
of
e-cigs
ops
I,
want
to
I'm
going
to
read
a
sentence
from
each
of
the
charters
to
say
why.
I
asked
the
question
about
whether
this
work
was
appropriate
in
v6,
ops
or
in
sunset,
for
so
the
v6
ops
charter
says
that
we
develop
guidelines
for
the
operation
of
a
shared
ipv4
ipv6
internet
and
provide
operational
guidance
on
how
to
deploy
ipv6
into
existing
ipv4
only
networks.
E
The
sunset
for
charter
says
talks
about
the
ability
of
ipv6,
only
portions
of
the
internet,
to
continue
to
interact
connection
portions
of
the
internet
that
remain
ipv4
only
so
there's
a
difference
there
between
adding
v6
to
existing
v4
networks
and
running
a
v6
only
network
with
some
kind
of
transition
technology
that
that's
what
the
two
charters
look
like
when
I
put
them
next
to
each
other,
which
is
why
I
asked
the
question
and
it's
more
about.
I
think
when
I
asked
it
when
I
asked
look
at
my
ad
s,
I
think
it's
more
about.
E
What's
the
intent,
then
what
are
the
actual
words
we're
not
going
to
get?
Let's
not
get
stuck
in
where's.
Where
should
the
work
be
done
because
of
what
the
words
say?
Let's
make
sure
that
we
agree
with
what
the
working
groups
want
to
do?
Let's
follow
the
consensus
of
the
working
groups
and
do
the
work
that
needs
to
be
done,
but
let's
make
sure
we
have
consensus
on
that.
B
A
You
know
I
would,
I
would
certainly
entertain
suggestions
about
whether
or
not
they're
additional
things
to
be
added
to
this
list.
You
know,
obviously
this
is.
This
is
a
fairly
new
discussion
and
said
there
may
be
additional
things
that
fit
here,
but
if
people
have
questions
or
comments
about
this,
we
certainly
have
a
few
more
minutes
to
discuss
it
or
independent
of
that.
We
have
plenty
of
time
for
open
discussion.
B
F
Michael
Lorenzen
again
so
we're
to
handle
this.
This
is
like
we
had
a
discussion
before,
but
is
it
okay
to
include
India
in
the
are
a
message
that
there
is
no
I
dv4
available
on
the
wire,
and
there
is
a
big
discussion,
but
it
is
right
or
wrong
or-
and
it's
it's
a
matter
of
a
taste
and
opinion
I
would
say
you
mean
you
can
be
strict
about
it.
You
can
be
pragmatic
about
it.
F
There
is
no
right
answer,
so
if
this
I
mean,
if
we,
if
we
think
that
doing
a
TV
for
us
a
service
is
a
way
of
Sun
setting
before
then
I'm
fine.
With
doing
this
approach
and
I
think
that
has
a
point
that
this
might
attract
more
more
people
following
this
working
group,
which,
yes,
it
is
a
good
thing.
Okay,.
G
Come
on
I
think
the
discussion
about
v4
as
a
service
is
very
critical
to
what
we're
going
to
do
in
this
working
group,
because
I
think
that
the
major
constraints
to
sun
setting
before
are
not
going
to
necessarily
technical.
But
you
know
economic,
and
so,
if
you're
going
to
do
that
without
lots
of
backlash,
the
work
on
v4
as
a
service
needs
to
our
progress
in
the
vermicelli.
G
A
Another
question
I
would
have
for
the
group
is,
is:
does
there
need
to
be
like
a
use
cases
document
where
we
talk
about
the
different
use
cases
around
ipv4
is
a
service.
I
mean
siit
is
in
some
ways
its
own
use
case,
because
it's
talking
about
how
to
do
I
give
you
six
only
in
a
data
center
but
I'm
wondering
if
there's
value
in
documenting
some
additional
use
cases
where
either
ipv6
only
is
already
in
use
or
could
potentially
be.
A
You
know
we
had
talked
about
them
and
no
ipv4
graft,
adding
timelines
and
other
things
it
might
be
more
appropriate
for
that
to
be
in
a
separate
draft.
We
talk
about
this
stuff
a
little
more
generically
in
terms
of
you
know,
ways
to
transition
away
and
things
like
that.
If
people
have
feelings
on
that
one
way
or
another,
please
come
to
the
mic.
G
Tamanna
come
again
a
gap
from
the
gap
from
the
governesses
document.
I
think
it
will
be
good
to
say
for
each
of
the
letters
who
wants
a
shot
down
v6.
We
could
link
to
a
specific
use
case,
because,
if
you
do
action
x
here
are
the
implications,
and
here
are
the
relevant
use
cases
from
the
defroster
service
that
we
used
to
mitigate
it.
That
we
want
me
to
fill
in
both
bodies
of
what
thank
you.
E
Reeling
for
Android
chencho,
who
I
think
once
mid
relay,
he
asked:
how
did
all
stack
implementations
today
decide,
there's
no
ipv6
and
why
this
decision
process?
Why
does
this
decision
process
need
to
be
different
from
the
process
for
ipv4
I.
Think
my
answer
to
his
question.
Sorry:
Lee
Howard.
My
answer
to
his
question
is
that
devices
today
decide
there's
no
ipv6
because
they
don't
have
any
support
for
ipv6,
they
don't
know
or
care
or
they
don't
get
an
RA.
F
Michael
areum's
yeah
I
seem
to
remember
that
there
is
nothing
stopping
the
device
from
doing
dates,
vb6
blindly,
without
seeing
RA,
but
I
am
not
aware
of
anyone
actually
doing
that
because
I
mean
that
would
be
the
equivalent
that's
div
for
a
favorite
and
as
far
as
I
know,
there
is
nothing
in
the
standard
or
anything
that
says
that
that
is
disallowed.
It
says,
if
you
want
to
you
can,
but
nobody
does
yeah.