►
From YouTube: IETF97-SUNSET4-20161117-1110
Description
SUNSET4 meeting session at IETF97
2016/11/17 1110
A
Okay,
we
start
this
sunset
phone
meeting,
so
there
is
no
magic
I'm,
neither
where's
nor
much
I'm
Eric
drink,
yeah
I'm
a
lifeboat
or
whatever
right,
I'm
a
guy
in
these
guys
Markus
to
leave
the
ATF
yesterday
to
go
to
Amsterdam
and
what
is
unable
to
join
so
I'm
you're,
agreeing
and
I'm
will
be
acting
as
your
chairman.
Here
we
have
a
jab
escribe.
Thank
you,
Michael
for
doing
it.
I
am
still
missing
a
minute
taker
Tim
in
the
taker.
A
Let's
go
further
note:
well,
we
are
Thursday
second
session.
So
mostly
you
know
that
everything
you
say
here,
even
the
public,
basically
blue
sheets,
so
they
are
circulating,
don't
forget
to
fill
them
out.
That's
maybe,
next
time
we
get
a
bigger
room.
Maybe
the
agenda
for
today
a
quick
session
introduction.
A
That's
what
I'm
doing
here
then
we
have
given
to
Lee
45
minutes
talking
about
is
old
and
new
draft
and
Emily
stack
will
be
joining
us
at
the
end
to
talk
about
the
specific
problem
about
the
localhost
OHS
name
in
HTTP,
mainly
but
basically,
no
application.
I
want
to
remind
because
it
may
be
open
to
discussion
some
point
of
time
today
with
elise
session
I
took
some
extract
from
the
sunset
for
charter.
A
It
really
says
the
working
group
will
point
on
specific
areas
of
concern
which
may
be
applicable
here,
provide
recommendation
and
satellites
protocol
that
facilitated
by
blahblahblah.
You
can
read
and
at
the
end
the
second
bold
statement,
the
working
group
will
report
on
common
issues,
provide
recommendation
and
so
on
and
so
to
keep
this
in
mind,
because
it
may
be
useful
for
the
description
during
the
least
session.
B
Hi
I
had
I
had
I
had
their
mi
mi
mi
audio
am
I,
am
I,
audible,
I
know
oh
yeah,
thanks
Davy
you're
right
next,
you
can
hear
me
yes,
ll
decide
this
way,
so
I
had
so
much
fun
at
our
last
meeting
that
I
decided
to
come
back
and
talk
some
more
before
I
get
into
the
draft.
I
want
to
sort
of
review
some
action
items
from
the
last
me.
This
sort
of
the
notes
that
I
took
away
from
our
last
face
meeting.
First
of
all,
is
we
asked
that
suggested.
B
The
IV
could
make
a
statements
to
SD
OS
on
ipv6
done.
We
are
still
working
the
mechanics
of
actually
getting
our
liaisons
to
send
that
to
the
stos.
Not
all
stos
need
that
statement,
for
instance,
or
not
all
of
our
liaisons
need
to
for
that
statement.
For
instance,
I
can
has
actually
done
you
know.
They've
got
the
website
they're,
not
doing
networking
protocols,
they're
they're,
in
pretty
good
shape.
B
The
statement
doesn't
apply
iesg
statement
on
ipv4
work,
so
the
iesg
said
you
know
we
probably
could
say
something
about
continued
ipv4
work
or
stopping
a
ipv4
work,
but
it
would
be
much
stronger
to
have
an
ietf
consensus
statement
on
that
and
that's
why
I'm
back
so
that's
what
I'm
doing
that
one
we
could
update
the
v4
historic
draft.
I've
got
a
note
on
that.
A
minute
draft
PHP,
Phillip,
Holland
Baker,
had
ideas
about
ipv4
sunset
is
complicated
and
what
the
steps
might
be.
B
I've
asked
him
a
couple
of
times:
hey
do
you
want
to
work
on?
A
document
can
I
help?
What
would
you
like
to
see
in
it
and
I
haven't
heard
back?
So
that's
what
status
is
they're
updating
the
I
Dean
its
checkered
to
check
for
ipv4
literals?
That
was
done.
While
we
were
in
Buenos
Aires
that
was
fantastic
cleaning
up
documents
that
have
V
for
liberals
examples
of
dependencies,
I,
don't
think
that's
going
to
I.
B
Don't
think
this
probably
gonna
be
a
major
effort
to
go
back
and
revise
existing
rfcs
that
have
those,
but
it's
something
I
think
everybody
ought
to
be
paying
attention
to.
As
we're
seeing
document
drafts
coming
through
and
I
think
we
are
seeing
that
and
then
finally
running
v6
up
winning
the
the
the
IETF
nat64
SSID
as
our
default
SSID.
Well,
you've
heard
about
that
the
plenary
last
night
genres
ASCII,
said
hey.
We
should
totally
do
this.
I
think
there
was
very
positive
response
to
that.
B
So,
and,
and
I'm
very
curious
why
people
who
aren't
using
it
aren't
using
it,
I
will
say
that
I'm
not
using
it,
because
my
primary
email
account
isn't
working
on
that
SSID.
I
can't
pop
my
mail
from
that
point
for
my
primary
mail
server,
so
I've
opened
a
ticket
with
a
knock
and
said
this
is
an
issue
for
me.
B
If
everybody
would
please
get
on
that,
SSAT
find
out
what
breaks
open
a
ticket
with
the
knock,
then
we
can
start
working
through
what
are
the
broken
issues
and
either
then
reveal
issues
back
to
IETF
that
need
work
or
reveal
issues
to
you
know
the
the
company's
some
of
that
think
that
was
it
Spotify
that
was
mentioned
to
the
tech
plenary.
So
we
can
go
thurs
escape.
C
D
David's
can
I
see
Apple
like
John's
remarks.
Question
I
won't
make
any
comment
on
what
the
correct
one
is
there.
There
is
no
such
thing
and
we
can
write
or
four
days
about
it.
Nat64
is
the
de
facto
one
that
is
being
used.
It's
the
one,
that's
being
deployed
where
network
operators
today
fact
so
I,
don't
think
there
is
value
in
wondering
what
the
perfect
one
or
the
best
one
is.
We
just
need
to
pick
one
and
move
on
like
otherwise
we'll
never
transition.
So.
C
B
B
C
B
C
D
F
Palette,
I
think
that's
that's
actually
the
problem.
We
need
to
first
define
what
is
our
goal
and
our
lawless
break
things
or
allow
the
people
to
keep
working
without
breaking
things
and,
at
the
same
time
make
sure
that
every
single
keep
working
in
the
future
which
ipv6
hungry.
Because
if
that's
the
case,
I
mention
already
in
the
in
the
plenary
mailing
list.
What
we
need
to
do
is
not
use
just
a
half
solution
like
nat64.
F
We
need
a
solution
that
behaves
like
in
the
real
world
and
the
real
war
is
people
having
private
ipv4
addresses
and
probably
as
more
the
times
goals
on
we'll
have
ipv6
only
access
and
that's
not
not
64,
because
applications
still
use
little
addresses
like
Spotify
skype
and
so
on.
So
what
we
need
to
do
is
to
try
that
solution
in
our
own
network
as
primary
as
SSID
and
at
the
same
time,
in
the
select.
F
If,
for
example,
we
choose
X
for
a
4,
64
X
lat
in
the
Select
diamond
in
our
first
hop
router
have
some
kind
of
logging
that
allows
us
to
identify
what
applications
are
using
the
select,
which
means
that
in
future
meetings
we
can
have
tall
those
application
vendors.
This
is
not
working
sort
it
out,
and
then
we
can
go
to
a
solution
like
only
not
64,
but
first
we
need
an
intermediate.
The
stage
German.
G
Koi
I
think
there
are
a
lot
of
networks
around
Eugene
has
been
sadya,
not
64
vis
v6
only
because
it's
from
operational
perspective,
it's
much
better
than
heaven
doorstep
and
there's
like
a
lotta
stuff
and
I.
Do
not
think
that
introducing
this
as
a
default,
IETF
SSID
will
break
addition,
because
there
are
other
SSID
always
fall
back
to
do
a
stack.
If
you
have
problem
so
I
think
we've
done
a
tripe
at
some
point
right,
so
it
will.
It
was
communicated
to
users.
Please
try
v6!
B
Sorry
I
would
think
this
is
great
for
the
list,
though
right
we've
started
this
conversation
on
the
list.
Let's
carry
it
on
there.
Alright,
so
I
mentioned
that
I
would
come
back
and
ok
doesn't
work
next
slide
and
next
slide.
So
I
have
not
updated
v4
historic,
because
I
didn't
think
that
folks
were
actually
ready
to
talk
about
it
anymore
just
yet.
These
are
the
three
fairly
minor
notes
that
I
had
from
the
last
meeting
on
the
updates
to
make.
B
So
if
you
want
other
updates
net,
send
it
to
the
list
and
I'll
get
them
done
next
slide.
So
today's
draft
and
work
on
ipv4
next
slide,
the
abstract
says
the
IETF
will
stop
working
on
ipv4,
except
where
needed,
to
mitigate
documented
security
issues
to
facilitate
the
transition
to
ipv6
or
2
enable
ipv4
decommissioning.
This
is
what
I
was
trying
to
get
at.
This
is
in
some
ways
similar
to
the
previous
drafts,
but
this
is
again
the
goal
of
this
document
is.
B
We
had
asked
the
iesg
to
make
a
statement
about
not
chartering
new
ipv4
work
and
that's
so
that's
that's
what
I'm
try
to
get
it
here
next
slide.
I
think
it'll
be
incredibly
boring
if
I
actually
read
all
the
slides
to
you,
because
they're
just
sort
of
beads
of
text
like
this.
But
if
you'll
take
20
seconds
to
read
this.
B
B
B
The
one
note
I
want
to
emphasize
here-
and
I
have
it
emphasized
on
the
slide-
is
that
ipv4
focused
activities
in
some
in
support
of
security
transition
and
decommissioning
will
continue,
and
maybe
I
should
say,
orchid
decommissioning
where
accompanied
by
a
problem
statement.
If
nobody
commits
based
on
operational
experience,
if
nobody
can
say
this
is
an
actual
problem,
is
just
a
philosophical
problem
or
a
speculative
speculated
problem.
I,
let's
not
work
on
it.
Okay
next
slide.
B
So
it's
will
update
protocols
and
features
to
facilitate
decommissioning,
will
explicitly
support
ipv6
or
if
it's
IP
version
agnostic,
because
it's
a
higher
in
the
stack
for
instance.
Then
that's
fine,
except
for
we
still
do
ipv4
up,
except
that
before
specific
transition
technologies,
which
I
come
back
to
you
on
the
next
slide.
B
To
say
we
will
not
initiate
any
new
ipv4
extension
technology
development
and
the
point
there
is
we
can
work
on,
and
this
is
a
potential
point
for
discussion.
We
could
work
on
additional
transition
mechanisms.
Maybe
somebody
has
a
great
idea.
We
haven't
come
up
with
yet
and
it's
not
too
late
to
design
and
deploy
it
I
doubt
it,
but
any
training
future
transition
mechanisms
we
might
work
on,
or
you
know,
or
enhancing
our
existing
transition
mechanisms.
B
We
won't
work
on
ipv4
extension
mechanisms,
so
ipv4
address
sharing,
probably
isn't
a
place
that
we
really
want
to
spend
a
whole
lot
more
time,
because
there's
only
so
much
further,
we
can
go
next
slide.
There
is
security
considerations,
pretty
much
the
same
that
you've
seen
before.
Maybe
there
will
be
an
issue
that
we've
discovered
an
ipv4
I,
don't
know
I
think
it's
been
fairly
robustly
tested,
but
it
possible
that
there
are
inherent
security
flaws
in
the
ipv4
spec.
B
I
I
We
drafted
updates
to
probably
a
hundred
different
rfcs,
so
I
fully
expect
that
if
we
start
along
this
path,
we're
going
to
need
to
spend
quite
a
bit
of
time,
updating
rfcs
to
get
to
this
point
where
we
actually
have
default
being
v6
only
and
I'm,
in
full
support
of
this
kind
of
work
going
forward.
Thank
you
for
bringing
it
to
us.
I
think.
B
So
I
well
I
think
that
we
still
have
adopted
as
a
working
group
a
an
ipv4
gap
in
our
transition.
Captain
alisis
document
right
and
that's
that
document
is
still
open,
is
still
a
working
group
document
and
I
think
it's
specific
goal
is
to
list
rfcs
that
need
to
be
updated.
So
please
forward
that
and
we'll
get
right
on
that
happy
to
help
yeah.
D
Hi
David
skin
Ozzy,
again
I,
have
kind
of
a
question
on
or
asking
for
cooperation
that
should
I
think
appear
in
the
draft
regarding
new
work.
That
can
be
dual
stack.
What
I
mean
by
that
two
examples
that
come
to
mind
are
home
net
and
the
multiple
interface
PVD
work
they're,
both
v6
centric
as
oh
I'm,
a
host
and
I
have
these
two
v6
prefixes,
where
I
do
with
them.
However,
all
these
properties
that
we're
getting
from
the
network
also
apply
to
v4
in
the
case
of
home
net.
D
The.
If
my
memory
care
tell
me
if
I'm
wrong
with
my
recollection.
The
whole
net
documents
is
that
your
home
network
may
support
ipv4
from
reading
the
draft.
It
sounds
like
you're
saying:
oh
no.
No,
it
shouldn't
even
say
that
so
I
think
that
should
be
made
clear,
because
I
agree
that
these
things
should
be
more
of
these
eccentric,
but
things
that
do
both
should
be
okay.
Can
you
go
back
to
statement
104.
B
Okay,
so
the
bullet
says
the
work
will
be
capable
of
operating
without
ipv4
right,
so
new
IETF
work,
even
even
home
net,
explicitly
supports
ipv6
or
is
version
agnostic,
so
homenet
specifically
supports
ipv6.
It
also
happens
to
support
ipv4,
which
is
great,
but
so
I,
so
I
think
I
think
that
your
point
is
actually
covered
in
the
text.
All.
J
Shy-
and
the
other
thing
I
remember
from
the
home
net
architecture
document
is
whether
you
then
say
doing
something:
the
best
way
for
v6
only,
whether
that
might
somehow
break
be
four
operations.
I
think
that's
maybe
another
thing
to
consider
in
the
statement,
and
maybe
we
will
you
put
it
on.
It
goes
better.
M
K
I
Trance
cutter,
can
you
go
to
the
next
slide?
Maybe
when
I
read
the
draft
almost
I
think
the
only
thing
that
jumped
out
at
me
is
kind
of
weird
was
the
not
initiate
new
technology
development
elm
and
when
you
talk
to
over
it
actually
I
I
would
summarize
you're.
Just
now,
I
would
summarize
what
you
said
as
well:
we've
pretty
much
covered
that
waterfront
already,
there's
not
really
anything
new
to
be.
I
You
know
no
more
blood
to
be
squeezed
out
of
that
stone
which,
if
that's
true,
you
don't
even
need
to
say
so,
and
if
it's
not
true,
the
technology
will
be
developed
anyway,
because
that's
just
how
things
work
so
I
mean
I,
don't
really
care
if
you
put
that
in
the
document
or
not,
but
I
think
it's
kind
of
you
know
either
it's
true
anyway
or
if
it's
not
true,
then
it's
not
going
to
matter.
So
it's.
B
A
reasonable
point,
the
reason
I
wanted
to
say
it
is
that
people
keep
coming
to
us
with
great
ideas
for
new
versions
of
IP,
for
instance,
and
new
versions
of
extension,
technion
new
proposed
extension
technologies,
I'd
kind
of
like
to
give
the
iesg
the
club
just
say
we
don't
even
have
to
talk
about
this.
We've
already
said
we're
not
doing
it
point
taken
so.
H
I
use
the
example
of
router
ID
and
so
for.
Ospf
is
Chris
powers
again
I'm
curious,
the
feeling
in
the
room,
though,
on
you
know,
interfaces
between
routers
that
use
v4
addresses
so
that
those
are
clearly
v4
dresses
and
not
32-bit
integers.
Now
what
I'm
suggesting
is
that
that'd
be
extremely
low
priority
in
getting
rid
of
compared
based
on
the
impact
on
the
overall
transition
to
v6
I'd
like
to
be
very
clear
about
that
that
I'm,
not
just
talking
about
router
IDs,
so
I.
H
H
B
Me
ask
so
in
that
example,
which
I
think
is
a
really
interesting
example.
New
new
communications
might
well
use
IP
use
links
with
ipv4
addresses
and
be
required
to
understand
that,
but
they
should
also
be
able
to
run
over
ipv6
only
links
and
networks,
yo
you're
right
ospf,
you
tues,
never
gonna.
Do
it
you're
right
and
we
have
not
actually
said
we're
stopping
working,
ospf,
e2
right,
I,
don't
think
we've
said
always
made
that
statement.
No.
H
Yeah
yeah,
so
do
you
want
so
you've
nodded?
Do
you
want
me
to
propose
some
wording
to
to
do
this?
You
want
to
come
up
wording
so
well,
I'd
like
to
get
a
little
more
feedback.
B
H
What
they
look
like,
let's
think
of
us
p
FV
to
as
you
know,
it
carries
mpls
information
in
the
TE,
opaque
ill
essays
right,
so
you
could
have
been
so
v6
goes
over
and
pls.
So
the
fact
that
you've
got
v4
addresses
you
know
they
could
be
some
I.
So
some
strange
addresses
but
to
happen
to
be,
you
know,
v4
dresses,
but
a
miniscule
quantity
of
them.
Given
in
the
scheme
of
things,
it
seems
like
a
lot
of
it
seems
like
basically
a
way
to
kill
ospf
all
of
ospf
relative
to
I
esaias
instead,
so.
N
H
B
B
N
H
N
N
I
Aaron
Hughes
again
to
this
point,
the
way
I
interpret
this
draft
is
that
we
begin
work
on
ospf,
be
four
and
bgp
v5
and
resolve
these
issues.
We
get
rid
of
the
32-bit
identifiers
as
we
get
rid
of
the
problems
where
we
cannot
wait
will
be
required
to
have
altered
protocol
support.
I
mean
why
not.
If
we're
going
to
move
forward,
we
move
all
the
way
forward
to
a
v6,
only
operating
environment.
So.
B
I
do
think
a
lot
of
rhubarb.
Sorry
that
that's
a
phrase
for
muttering
in
the
background
I
do
think
that
we
need
to
make
sure
that
our
protocols
can
run
v6
only
but
I'm,
I
might
be
content
well,
an
ospf
tp2
is
it?
Is
it
an
unusual
case
that
we
need
probably
need
to
talk
a
lot
more
about,
but
I
I'm
content
to
say
to
just
have
a
short
draft
saying
you
know,
router,
IDs
or
not
IP
addresses
carry
on
good.
H
B
Matters:
yes,
yes,
it's
not
just
the
router
ID
and
and
that
right
jump,
and
but
those
are
different
things.
That's
not
to
say
that
we
don't
want
to
start
new
work
on
routing
protocols
and
there's
no
routing
80
in
here
that
I
see
right
now.
So
that's
not
oh
hey
there
you
go
so
there
may
be
other
reasons
you
wanted
to
do
routing
protocols,
but
I'm,
not
gonna
I.
Don't
think
that's
in
scope
for
us
here
well,
actually
based
on
our
charter.
Maybe
it
is.
O
A
lot
of
cisco
speaking
as
myself,
not
throwing
any,
I
was
gonna
say
that
one
of
my
concerns
here-
I'd
not
opposed
to
this
sounds
great.
Is
that
yes
need
some
wordsmithing,
because
new
ITF
work,
maybe
you
mean
brand
new
idea
for
converse,
is
continuing,
say:
Wes
canopy
to
atf
work,
for
example,
but
there's
of
course
new
to
the
ATF
voice.
We
have
you
too
ITF,
work,
etc.
Some
of
that
things
to
be
clarified,
I
think
on
page
one,
for
example,
you
talk
about
it,
says
ipv4
only
for
features
of
vital
operation.
O
To
me,
that's
the
door
right
that
it's
open
where,
if
I
say
well,
I
need
to
update
those
22
or
whatever
for
vital
operational
issues.
That's
it
right
that
that's
the
door,
that's
open,
of
course,
everywhere
else
in
the
text,
except
that
sentence
says
transition
security
and
something
else
not
operations.
O
B
M
O
B
B
Yeah
I
heard
in
all
of
the
above,
not
at
the
mic,
so
so
yeah
it
but
I,
but
I'm,
seeing
Chris,
say
yeah,
but
we
just
talked
about
OS.
We
have
v2,
that's
a
specific
example.
It
you
know
it's
open
work,
it's
still
things
something
we
can
work
on
and
having
a
routing
ad
say.
No,
no.
You
can't
work
on
ospf.
V2
is
a
serious
consideration
that
matters
in
the
real
world.
So
we
need
to
be
very
sure
what
we
want
to
do
about
it.
I'll
update
it
to
you
know.
B
If
the
working
group
wants
to
adopt
the
dress,
the
draft
I
will
work
on
whatever
the
working
group
tells
me
to
do.
But
when
we
go
to
IETF
consensus,
we're
going
to
have
you
know
it's
going
to
be
allowed
long
last
call,
or
maybe
it
won't
people
and
they'll,
be.
You
know,
rough
consensus
that
no
forget
ospf.
You
too.
N
Michael
Abramson
so
with
the
example
of
ospf
here,
if
someone
came
and
said,
I
want
something
you
know:
52
I,
don't
care
to
to
make
that
same
functionality
knows
baby
3,
I'm
going
to
get
really
upset.
There
needs
to
be
at
least
be
feature
parity,
the
ice
to
understand
that
people
still
want
this
functionality
now
52,
which
is
fine,
but
not
caring
about
those
be
33
and
making
sure
that
they
can
do
the
same
is
really
bad.
B
No-No
feature
can
be
added:
that's
ipv4
only
unless
there
is
a
Nike,
v6,
comparable
feature
or
equivalent
feature
in
an
equivalent
system
and
even
maybe
give
the
example
of
ospf
v2
v3
with
I'm,
seeing
some
nods
and
shrugs
and
saying
maybe
that's
the
right
way
to
finesse
it
I'm,
hoping
somebody
was
taking
note
taking
I'm
hoping
you
got
that
because
I
just
said
it
out
loud
Tim
I
help
you
yeah
some
something
like
what
I
said
will
be
close
enough.
Then
we'll
fight
about
analyst.
We.
I
Should
just
move
this
to
the
ospf
working
group
is
the
only
example
anybody
can
come
up
with
is
ospf
it.
It
is
convenient
that
both
v2
and
v3
live
in
the
same
working
group.
Yeah.
A
B
That's
a
great
question,
so
I
think
as
a
you,
the
punches
said
there
it's
covered
under
advice,
but
I
wait.
We
haven't,
we
have
an
ad
here
who
can
tell
us
whether
it
fits
the
Charter
and
if
it
doesn't,
we
can
just
you
know.
P
P
P
B
Guess
is
that
we
would
take
a
hum
to
see
whether
the
working
group
wants
to
adopt
it.
I
would
then
spin
a
revision
based
on
comments
made
here
and
notes
made
here
named
for
the
working
group.
If
we
adopted
there
will
be
more
wordsmithing
online.
At
some
point
we'll
say:
gene
no
more
comments
are
being
made.
We
seem
close
enough
and
the
working
of
chairs
will
do.
B
It
will
issue
a
working
group
last
call
either
that
could
be
at
the
next
meeting
or
a
meeting
and
saying:
do
you
think
it's
ready
we'll
take
a
hum
or
it
could
be
on
the
mate
just
on
the
mailing
list,
and
then
we
run
probably
to
two
to
four
weeks
whichever
to
see.
If
anybody
has
any
further
comments
and
then
if
there
are
no
further
comments
or
the
strong
support,
then
it
goes
to
IETF
last
call,
which
is
same
two
to
four
week
process,
which
will
probably
generate
a
lot
of
comments.
B
A
Any
more
questions
fully
so
question
for
myself
now,
which
is
the
same
as
you:
we
will
do
a
ham
quickly
to
see
whether
the
working
group
wants
to
get
this
document
that
Duquette
it's
a
working
group
document,
so
we'll
ask
the
first
one
will
be
yes,
I
won
this
as
a
working
group
document
and
the
second
I'm
would
be
no
I.
Do
not
want
this,
as
you
can
group
document,
so
we
would
like
to
give
to
f
this
document.
Is
the
working
group
document
kiss
em
now.
A
Thank
you
for
those
of
you
that
do
not
want
to
add
up.
This
document
is
yoking
group
document,
please
em.
Now,
okay,
it
was
to
be
expected,
but
a
clear
physically
for
the
noting
a
clear
adoption
there.
Thankfully,
so
the
next
session
is
about
the
locale
owes
name
and
it's
emily
and
by
day
for
those
of
you
attending
removed.
As
I
am
acting
as
a
chair
and
not
with
the
full
power
of
the
chair
at
dinner,
I
was
unable
to
upload
the
latest
version
of
emory
slides.
M
Hi
and
I'm
Emily
stark
I'm
here
from
the
chrome
team,
I'm
pretending
to
be
my
quest.
I
was
hoping
he
might
appear
remotely
so
that
he
can
answer
all
the
hard
questions,
but
looks
like
not
so
no
hard
questions
so
I
I'm
presenting
a
pretty
simple
proposal
that
might
put
together
I've
been
tangentially
involved
in
some
of
the
issues
here,
but
this
is
really
Mike's
proposal.
He
just
going
to
be
here
so
so.
M
The
the
problem
that
we
are
trying
to
solve
arises
for
the
fact
that
6761
advises
users
that
they
can
assume
that
that
local
host
names
resolve
to
loop
back
IPS,
but
in
fact
the
the
sections
that
actually
outline
the
behavior
of
name
resolution,
libraries
and
and
DNS
servers
says
this
frames.
This
has
a
should
not
not
a
must
so
DNS
servers
and
numerous
Aleutian
libraries
are
actually
free
to
resolve
local
host
names
to
anything
they'd
like
including
something
on
the
public
internet,
and
that
is
surprising.
Several
implementation
implementations
do
do
this.
M
We've
encountered
them
in
the
wild,
so
the
implication
of
this
is
a
few
things.
It
makes
local
host
names
difficult
to
use
or
I'm
impossible
to
use
for
security
decisions
and
I'll
give
some
examples
of
that
in
a
moment.
But
it
means
that
there's
no
guarantee
that
local
host
names
actually
resolve
to
to
look
back.
M
They
can
go
anywhere
and
and
because
of
that,
we
are
not
able
to
give
certain
functionality
that
we
would
like
to
give
to
local
host
names,
which
may
encourage
developers
to
hard-code
address
literals,
and
that
is
probably
not
good
for
all
of
you.
People
who
are
trying
to
kill
IP
before,
because
it
proliferates
IP,
address
laurels
and
in
applications
so
I'm
gonna
there.
We
go.
M
Ok,
so
just
a
little
bit
more
on
the
motivation
here
and
comes
from
w3c,
where
there's
a
speck
that
defines
a
secure
context
in
the
web
platform
and
very
roughly
a
secure
context
is
currently
defined
as
when
a
frame
and
all
of
its
ancestors
are
HTTPS
or
the
WebSockets,
equivalent
or
or
a
loopback
IP,
but
localhost
is,
is
very
conspicuously
missing
from
this
list
of
URLs
that
define
a
secure
context
and
that's
a
pain
for
developers,
developers
well,
I
guess.
M
Another
key
thing
here
is
that
a
secure
context
used
to
to
grant
special
privileges
and
functionality
to
web
applications,
so
certain
powerful
web
platform
features
like
the
geolocation
API,
for
example,
are
only
available
to
applications
that
are
running
in
secure
contexts,
so
developers
want
to
test
these
features.
They
want
to
test
them
on
localhost,
but
we
are
currently
unwilling
to
to
give
them
to
localhost,
because
we
don't
actually
know
what
what
localhost
is.
It
could
be
could
be
anything
so
letting
developers
test
secure
contacts
features
on
localhost.
M
Moreover,
you
can
you
could
imagine
that
a
an
application
might
want
to
talk
to
a
local
service.
We
don't
want
a
local
service
to
we
if
that
local
service
is
being
talked
to
from
a
secure
context.
That
secure
contacts
is
only
really
allowed
to
talk
to
it
if
it
is
also
a
secure,
URL
and-
and
so
currently,
we,
the
the
mixed
content
specification,
which
defines
how
secure
content
is
allowed
to
load
sub
resources
from
from
insecure
for
load,
insecure
sub
resources.
M
Currently,
that
spec
doesn't
allow
local
host
and
will
trigger
mixed
content,
warnings
and
web
browsers
for
for
localhost
and
it's
using
the
same
definition
that
secure
context
uses.
So
basically,
the
proposal
is
basically
it's
just
like
replace
the
shades
with
the
musts
appropriately.
So
there
are,
you
know
like
three
or
four
places
in
6761
that
define
the
behavior
of
name
resolution.
M
Libraries
and
gayness
servers
with
respect
to
local
host
names,
and
the
proposal
is
to
change
those
roads
to
musts
so
that
applications
can
assume
or
or
constrain
their
dns
lookups
for
local
host
names
to
to
loop
back.
M
So
that's
basically
it
it's
pretty
simple
proposal
kind
of
removes
and
need
a
need
for
proliferating,
loopback,
address,
literals
and
and
will
be
very
useful
to
us
over
in
w3c
lands
to
to
add
local
host
to
the
lists
of
URLs
that
that
define
secure
contacts.
Q
Hi
Stan
York
and
my
my
head
was
exploding
sort
of
because
I
was
having
this
collision
between
my
previous
ipv6
world.
In
my
current
dns
world
and
and
just
reading
this
because
I
had
actually
double
checked,
6761
was
what
I
thought
it
was
I
guess.
My
question
is:
why
are
we
having
this
happen?
Did
Mike
bring
this
to
DNS,
op
or
anything
like
that,
and
the
mailing
list?
I,
don't
remember
ever
seeing
in
a
list.
I
am.
M
Q
My
feedback,
I
guess,
would
be
for
him
to
say
for
him
to
bring
this
DNS
op,
because
this
is
clearly
an
operational
and
we've
been
having
all
sorts
of
fun,
with
RFC,
6761
and
special
use
names
and,
in
fact,
we're
having
an
interim
in
a
couple
of
weeks
to
talk
about
that
or
not
it's
or
month
or
so,
or
something
right
Terry.
It's
someone
that
space,
so
I
would
say
that
this
would
be
something
that
he
should
send
in
there
and
we're
watching
a
pacman
eat,
Mark,
Andrews,
ok!
Q
R
Video
called
Enoch
I
I,
second,
that
that
question
I
was
wondering
why
we're
presented
here.
Second,
is
setting
all
the
problems
in
6761
aside.
The
discussion
whether
or
not
localhost
should
resolve
to
defined
results
is
like
decades
old.
That
doesn't
mean
that
it
doesn't
deserve
an
answer,
but
there's
lots
of
history
in
baggage
which
might
lead
to
certain
biased
responses.
So
just
be
aware
that
this
is
old,
stuff
and
muddy
waters,
I'm
not
sure
I
understand
how
reliable
the
result
is
really
meant
to
be
again.
R
Setting
6761
moving
this
from
a
show
to
a
must
doesn't
guarantee
any
any
any
future
performance.
I
guess
is
that
it's
the
term
that
you
usually
use
it
may
or
may
not
be
implemented.
Today,
questions
for
local
host
may
leak
to
the
root
service
today,
and
actually,
at
that
place
the
responses
annex
domain.
So
what
you
probably
really
want
and
again
a
warning.
This
is
not
leading
anywhere.
M
So
to
two
things
I
think
I
just
want
to
say:
I
think
how
this
ended
up
here
is
the
issue
of
proliferation
of
ipv4,
literals
and
so
I
think
that
the
relevance
to
this
group
is
like
if
we
can
remove
a
common.
You
know
and
a
that's
thing
that
pushes
developers
in
the
directions
of
ipv4
literals,
then
that
makes
it
easier
to
kill
off
ipv4.
M
To
your
second
point,
yeah,
like
we
just
changing
RFC,
doesn't
change
the
simple
fact
that
implementations
are
not
gonna,
probably
ever
update,
I
think
what
we
would
do
is
make
this
change
and
then
in
the
secure
context,
spec,
maybe
I,
don't
know
if
it
would
be.
I
probably
wouldn't
be
normative,
but
like
make
it
make
a
note
that
this
is
the
state
of
the
world
and
then
browsers
would
in
fact,
on
some
platforms.
M
Chrome
already
forces
local
house
to
resolve
to
loop
back,
so
we
would
sort
of
implement
it
in
the
browser
and
that
would
make
us
feel
safe
about
giving
local
host
secure
context.
So
it's
sort
of
the
purpose
is
not
so
much
that
implementations
will
change
overnight,
but
to
sort
of
bolster
the
case
for
the
user
agent
kind
of
pretending
that
this
is
the
state
of
the
world.
M
Don't
think
it's
a
justification
so
much
as
as
a
thing
that
makes
sense
to
do
in
parallel,
like
I
think
this
is
continuously
surprising.
22
people
and
it's
I
think
it's
just
sort
of
like
how
how
it
should
be
like
people
expect
a
local
host
to
resolve,
to
look
back
and
it
should
resolve
to
look
back
and,
and
it's
a
change
that
makes
sense
to
do
in
parallel
with
what,
with
with
what
we
would
do
for
first
gear
contacts.