►
From YouTube: IETF98-HOMENET-20170327-0900
Description
HOMENET meeting session at IETF98
2017/03/27 0900
B
B
B
B
B
D
B
Okay,
just
quick
agenda
bash
would
do
quick
update
on
our
drafts.
As
you
may
have
noticed,
we've
actually
got
a
very
short
amount
of
scheduled
sorry
of
schedule,
actual
talks
on
the
agenda.
We
originally
requested
a
90-minute
session.
We've
got
two
and
a
half
hour
session,
the
Suffolk
actually
on
the
agenda
when
he
isn't
even
second
hour
and
a
half
not
even
lat,
but
well
touch
on
that
in
a
moment.
B
So
we've
got
we
should
go
out
and
do
this
to
talk
about
the
Babel
profile
and
Ted
and
Daniel
me:
go
have
produced
a
simpler
version
of
home
that
name
in
architecture
for
our
consideration,
which
I
believe
would
be
intended
to
replace
the
most
more
complicated
version.
But
well
that's
a
TED
talk
to
that
when
he
comes
up.
B
E
Is
that
better,
okay,
so
I
accepted
to
be
editor
of
the
Babel
profile
for
home?
That
draft,
which
was
meant
to
be
a
technical
but
rather
consensual
draft.
So
it
has
two
parts,
so
I
will
wondering
whether
make
it
to
draft
or
one
mark,
and
then
we
can
do
just
one
draft.
There
is
a
first
part
which
tells
you
how
you
parameterize
Babel.
E
So
there's
our
things
that
don't
happen
on
the
wire.
There
are
purely
local
interaction
between
the
two
demons
and
they
tell
you
things
like,
for
example,
if
you
are
announcing
an
external
prefix
with
ipv6,
then
you
should
ensure
that
Babel
is
announcing
its
or
specific
default
route
and
gives
the
details
hey.
E
There
was
consensus.
There
was
almost
unanimity
on
all
the
points
already
raised,
except
one
on
which
the
minority
opinion
didn't
feel
really
strongly
about
it
and
so
dash.
0
1
was
a
complete
document,
absolutely
perfect
in
all
ways,
just
send
it
to
the
iesg
and
be
done
with
it.
There
is
a
Polish
proverb
that
says
that
man
makes
plans
and
God
laughs
next
place.
E
Requirement
5
in
the
draft
I
didn't
write
it
entirely.
That
says
roughly
that
that
a
home
net
implementation
of
Babel
must
implement
H
Mac
based
authentication
with
reference
to
the
right
RSC
and
must
enable
it
if
signal
to
do
so
by
H,
NCP
next
and
I
have
no
idea.
I
wrote
it,
but
they
have
absolutely
no
idea
what
that
means.
So,
basically,
this
is
not
precise
enough
to
ensure
interoperability
and,
as
far
as
I
know,
nobody
has
any
plans
to
implement
it.
E
So
I
first
raised
the
issue
in
private
with
mark
than
in
private,
with
both
chairs
and
Marcus
stenberg.
Then
I
sent
a
detailed
mailing
to
the
mailing
list
which
will
find
in
the
archives
on
far
so
january.
This
year
and
I
did
not
receive
and
the
helpful
advice
on
the
mailing
list
next,
please
so
in
order
to
implement
requirement
five,
you
need
to
have
a
consensus
mechanism
that
allows
hnc
denotes
to
decide
that
we
want
to
enable
authentication
on
a
given
link.
E
The
consensus
mechelen
can
be
as
simple
as
we
always
enable
authentication
that
is
a
consensus
mechanism,
but
the
consensus
mekin
it
needs
to
be
defined.
Second,
you
don't
want
to
become
figuring.
All
of
your
whole
net
returns
with
a
authentication
key.
So
what
you
need
here
is
a
second
consensus
mechanism
which
allows
the
HNC
p
note
to
agree
on
an
authentication
key
that
they
asked
to
battle.
E
So
we
need
to
define
the
algorithms.
We
need
to
define
the
packet
format
and
we
need
to
provide
a
reference
implementation
neck.
Please
I'm,
really
proud
to
have
been
working
with
helmet
on
the
last
over
the
last
two
years.
I
think
we
are
very
serious
and
home
that
about
having
work
in
code,
everything
that
we've
done
in
this
working
group
as
either
has
been
implemented
either
once
or
twice
or
I
love.
E
This
word
price
and
I
would
not
like
to
be
to
innovate
by
being
the
editor,
the
first
document
that
nobody
has
any
plans
to
implement
at
leas,
so
I'm
stuck
here.
I
have
a
few
suggestions,
so
the
simplest
but
perhaps
problematic,
and
the
1
I'm
in
favor
of
would
be.
Let's
drop
requirement
five
and
say
well:
authentication
is
the
problem
at
the
lower
layers,
use
wpa
use
wpa
to
put
a
guy
with
a
Kalashnikov
in
front
of
every
ethernet
plug.
E
The
second
suggestion
I
have
is
would
be
to
find
someone
who
is
willing
to
do
the
work
that
is,
who
is
willing
to
describe
the
needed
algorithms,
who
is
willing
to
define
the
packet
format
and
who
is
willing
to
work
on
the
reference
implementation?
I'm,
not
volunteering,
to
do
that,
because
I'm
not
competent
to
work
on
security
stuff,
of
course,
I'd
be
quite
willing
to
help
the
second.
The
third
suggestion
I
have
I'm
trying
to
be
exhaustive
here
is
fire
me,
the
canoe
editor
and
well,
I'm
open
to
other
ideas.
C
B
So
I'm
slightest
pointed
that
we
don't
have
a
cure
people,
volunteering
to
help
or
a
deal.
They
prefer
other
suggestions.
Sorry
there's
a
very
sensitive
mic,
or
rather
very
narrow,
Mike,
okay,
so
slightly
spongy,
we
don't
have
a
cure
people,
preferring
helpful
suggestions
of
how
we
get
out
of
this
impasse.
B
B
G
Time,
yes,
there
is
gonna,
see
Apple.
Regarding
for
your
point
about
the
Hegira
viewing
for
that
matter,
the
broader
ITF
we
don't
every
protocol
doesn't
necessarily
need
an
authentication
mechanism.
It's
that
every
document
needs
a
security
considerations,
security
discussion,
so
there's
a
lot
of
work
that
went
through
this
on
the
security
requirements
and
what
we
could
do
to
solve
them.
That
could
be
useful
and
documented
in
the
document,
but
it
doesn't
need
to
be
a
hard
requirement
on
the
protocol.
G
Yet
if
so,
my
personal
recommendation
would
be
to
option
one
to
remove
requirement
five,
because
one
of
the
main
goals
in
my
opinion
of
home
net
is
that
I
can
buy
a
bunch
of
routers
from
different
vendors.
I
plug
them
in
and
I'm
done.
If
that
involves,
I
plug
them
in
I,
go
into
the
one
from
this.
It
has
this
web
UI
to
copy
this
key
and
I
go
to
the
other
one
to
type
it
in
that.
Oh
crap,
that's
in
the
wrong
language.
It's
never
going
to
work.
G
H
I
think
that's
it
defining
something
in
the
text
that
decides
how
to
pick
a
key
for
able
shouldn't
be
that
complicated.
I
feel
a
little
bit
like
you.
I
would
like
to
help,
but
I
feel
like
I'm,
not
competent
to
touch
security,
stuff
but
I'm
sure
it's
a
matter
of
a
few
lines
of
code.
It's
not
so
complicated!
Please
we
need
Marcus.
Marcus
can.
A
I
Ted
lemon,
so
a
I
think
that
you
know
DTLS
seems
like
it
would
solve
this
problem
once
again
excuse
you,
TLS
seems
like
we
would
solve
this
problem.
We
don't
have
a
threat
model
or
security
model.
I
I'll,
just
maybe
I'll
just
be
Elvis
right,
so
things
kind
of
heavy,
so
yeah.
So
so
we
don't
have
a
security
model.
We
don't
have
a
threat
model,
we
don't
know
what
we
could
reasonably
accomplish
and
we
don't
know
we
can't
reasonably
accomplish,
and
so
it's
no
surprise
that
nobody's
enthusiastic
about
implementing
something
that
we
don't
even
know
how
to
deploy
and
I.
A
Hey
so
you
would
advocate,
for
us
at
least
Julia
Julius
has
in
his
slides
an
assumption
that
we
want
to
continue
with
the
predation
of
having
a
reference
implementation
for
everything
that
we
put
into
our
internet
drafts
and
our
RFC's
I
think
I
just
heard
okay.
Well,
maybe
we
could
relax
at
this
time.
It's
better
to
go
ahead
and
at
least
have
some
text.
A
I
mean
that
would
that
would
there's
a
proud
tradition
in
the
IETF
of
the
security
considerations,
section
sprinkling
ipsec
or
whatever
the
you
know,
the
the
favorite
security
mechanism
of
the
day
is
and
saying
yep
I've
got
a
security,
and
you
know
maybe
that's
what
we
need
to
do
because
that's
all
we
know
how
to
do.
Is
that
what
you're
saying
so.
I
Sorry
I,
actually,
when
I
got
up
to
the
mic,
intended
to
say
something
a
little
more
detailed
than
what
I
actually
said.
If
we
don't
have
a
mechanism
that
we
can
actually
implement,
that
will
it
will
work
to
authenticate
that
table
implementations
to
each
other,
then
we
can
never
have
interoperability,
because
a
million
gable
implementations
out
there,
some
of
which
implements
security
and
some
of
which
don't
which
is
actually
exactly
the
scenario
that
that
I'm
sorry
he
was
talking
about
so
so
we
act.
I
What
the
right
thing
to
do
is
actually
put
some
security
mechanism
that
we
think
will
work
if
we
can
figure
out
how
to
key
it
and
then
solve
the
keying
problem
later,
because
I
don't
think
we
know
how
to
solve
the
keying
problem
right
now.
Does
that
make
sense
in
other?
In
other
words,
assume
that
you
have
keys,
do
you
have
keys
that
you
shared
in
some
secure
way
and
having
done
that,
you
can
now
sign
your
communications
I.
Don't.
E
Think
that
the
mechanism,
the
authentication
mechanism,
is
what
the
issue
is:
I
think
that
the
main
problem
is
the
interaction
between
H,
NCP
and
devil
right.
So,
as
data
pointed
out,
you
really
do
want
the
keys.
You
really
don't
want
to
be
configuring
Babel.
You
want
H
NCP
to
take
care
of
the
configuration
and
everything
to
happen
in
hnc
p,
and
you
have
a
chance
ed
to
decide
on
everything,
including
the
keys
that
Babel
is
using,
and
that
means
defining
the
HNC
p
mechanism
and
do
that,
and
that
is
the
bed
that
worries
me.
So.
B
Julius
left
terrified
somewhere
to
understand
that
Babel
already
has
a
specified
H
night
based
authentication
mechanism,
because
what
you're
saying
is
that
the
problem
is
scope
to
simply
how
do
we
securely
distribute
the
keys
within
the
network,
so
is
to
configure
Babel
itself,
so
we're
not
asking
how
how
to
secure
Babel
but
just
how
to
distribute
these.
Yes,.
E
H
It
just
kept
estas
speaking
just
to
contradict
that.
It's
actually
very
simple,
with
agency
p,
to
get
to
get
a
pre-shared
key
that
we
can
just
give
out
to
Babel.
Assuming
agency
is
running
in
a
secure
mode
or
using
DTS
on
links
that
are
unsecured,
it's
just
a
theory
and
a
simple
consensus
among
the
writers.
We
do
that
all
the
time
just
the
tlv
containing
some
some
key
and
we
can
auto
generate
a
key
for
babel.
G
David's
Ganassi:
well,
if
we
assume
that
we
have
keys,
then
what
kind
of
like
that
was
easy
and
I
not
sure.
That's
the
right
assumption
to
make,
because
if
we
design
all
these
protocols
with
an
assumption
and
then
there's
no
running
code
whatsoever,
and
then
we
realize
oh
that
never
managed
to
get
that
assumption
to
work.
Then
we
just
have
all
these
paragraphs.
I
don't
help
as
people
point
out.
There
are
many
mechanisms.
G
I
So,
just
to
throw
additional
gasoline
on
the
fire
I,
this
is
Ted
lemon
again.
I
think
that
actually,
what
Pierre
just
described
is
not
the
right
way
to
solve
the
problem,
because
what
you
really,
if
you're
doing,
pre-shared
keys,
that
are
that
are
a
symmetric
than
what
you
want
is
to
have
a
key
pair
that
you
want
to
have
a
key,
that's
shared
between
each
pair
of
communicating
devices,
not
not
a
key
that
everybody
agrees
on.
H
To
I
think
agency
p
works
like
works
this
way,
so
in
hnc
p,
it's
it's
based
on.
You
know,
trust
I
mean
it's
a
bit
more
advanced
security
model
in
agency
p,
the
idea
being
that
every
time
you
would
need
to
modify
that
key
that
Babel
uses
you
just
updates
the
key.
So
if
you
need
to
revoke
someone,
you
know
reebok
some
router,
it's
a
chance.
If
it
does
that,
and
just
change
is
the
key
that
is
used
by
babel.
B
I
A
I
don't
know,
certainly
there
are
deployments
where
their
group
keys
versus
pairwise
for
everyone
I
mean
it's.
This
gets
into
the
whole
debate
of
you
ease
up,
you
know,
ease
of
key
distribution
versus
your,
you
know
your
threat
model
and
and
the
security
right
so
I
mean
I,
know
the
number
of
solutions
that
have
have
some
sort
of
group
keying
involved,
like
I,
think
you
did
this
arguments
between
Ted
and
Pierre
is
degenerating
and.
J
I
am
paralyzed
on
an
actual
authentication
of
routing
protocols
is
ran,
Atkinson
and
I
I'm.
Actually,
the
original
author
of
the
ospf
authentication
and
the
rip
authentication,
both
of
which
are
deployed
and
with
ospf
all
of
the
routers
on
a
given
link,
have
to
use
the
same
key.
There
is
no
distinguishing
the
router
a
originated.
The
message,
as
opposed
to
router,
see
if
router
is
a
B
and
C
share
the
same
length.
So
there
there
is
ospf
is
in
existence,
example
that
you
don't
necessarily
need
unique
keying
for
rib.
J
F
J
Really
do
in
practice
is
they
use
provisioning
systems
and
a
specific
example
is
that
an
ISP
that
is
running,
something
like
netcom
might
or
might
not
actually
be
netcom,
and
they
probably
are
not
using
yang
today,
but
they
have
ssh
or
TLS
as
a
way
to
protect
the
provisioning
session
between
a
centralized
database.
That
knows
that
the
configuration
of
all
the
devices
and
the
key
is
just
one
element
of
that,
and
they
send
that
over
a
secure,
authenticated
channel
that
may
or
may
not
be
the
best
way
to
do
it.
J
J
B
The
questions
the
group
plan
is:
do
we
have
people
here
in
the
room
or
on
the
list
or
Java?
Who
would
help
with
number
two?
It
sounds
like.
We've
certainly
got
some
expertise
in
the
Robin
as
far
as
our
routing
protocol
securities
concern
below
it.
As
per
previous
discussion,
it's
really
actually
the
institution
keys
is
the
problem
with
the
HNC
p,
rather
than
a
ranking
protocol
per
se.
I
Object
to
that
to
that
proposal,
this
is
not
the
same
situation
as
a
network.
That's
operated
by,
like
you
know,
I
mean
we
used
to
use
rip
back
at
deck
when
I
when
I
first
started
doing
networking
stuff
right
was
actually
Rick,
v1,
I
think
which
is
kind
of
explosive.
But
let's
not
get
into
that,
and
you
know
we
could
have
operated
a
network
where
we
had
to
go
type
the
keys
in
or
where
we
shared
the
keys
with
HNC
he.
But
this
is
not
the
same
situation.
I
Anything
that
connects
to
the
network
in
principle
can
join
the
HNC
peak
conversation,
and
that
means
that
if
you
want
debug
ability,
you
have
to
know
who
you're
talking
to
you
have
to
know
who
sent
the
message
and
to
know
who
sent
the
message.
It
has
to
be
signed
with
a
key
that
belong
to
that
particular
entity,
not
a
key
that
is
shared
amongst
all
entities
that
are
communicated.
That's
the
issue,
and
so
now.
My
point
here
is
not
that
you
should
accept
that
what
I
just
said
is
true.
I
I
may
be
completely
full
of
here,
but
we
need
to
actually
do
the
threat,
analysis
and
figure
out
if
what
I
said
is
true
rather
than
jumping
to
a
solution,
but
I,
don't
think
that
I
don't
think
that
we
can
legitimately
go
forward
without
doing
that
work
and
that's
work
that
we've
kind
of
been
punting
on
for
lo
these
many
years.
I
am
definitely
interested
doing
that
work.
I
A
I'm
going
to
make
a
proposal,
we've
got
the
wonderful
opportunity
that
this
is
9
a.m.
on
monday.
We
have
some
people
that
seemed
at
least
you
know
have
expertise
and
maybe
even
motivation
if,
by
the
end
of
the
week
you
guys
get
together
and
say:
yes,
we
are
the
group.
Ok,
I
can.
I
can
ask
for
call
hands
right
now.
You
know
for
volunteers
to
raise
hands
if
you
guys
get
together
with
a
you
know,
coherent
way
forward
by
the
end
of
the
week
this
week.
A
I
A
We
get
a
raise
of
hands
of
people
that
would
like
to
join
in
on
the
security
discussion
with
Ted,
with
the
ultimate
goal
of
people
fulfilling
number
two
here
with
Julius
awesome.
You
see
those
names,
you
see
those
people
look
around
there's
at
least
five
people
in
the
room,
so
you
guys
get
together
with
Ted
and
Julius
afterwards
and
try
to
solve
this
by
the
end
of
the
week.
K
Howard
relaying
from
Marcus
Steinberg.
He
wanted
to
point
out
that
the
potential
scalability
issue
that
technically
we
can
support
to
go
technically.
We
can
support
multiple
keys,
but
not
for
N
squared
keys
for
end
devices.
So
there's
the
potential
scalability
but
I
think
he's
also
going
to
be
paying
attention
on
business
up.
I
Oh
goody,
we
don't
have
the
monitor
screen
all
right,
so
I'm,
Ted,
lemon
and
Danny
me
go
above
me
a
little
while
ago
to
get
to
work
on
this
simple
net
naming
and
service
discovery
architecture,
because
the
working
group
didn't
seem
all
that
excited
about
the
previous
complicated
home
net
naming
and
service
discovery
architecture.
Maybe
I
should
chose
in
a
better
title.
I
So
next
slide,
so
we
got
together
and
Daniel
produced
a
kind
of
a
you
know.
Intention
document
and
I
took
what
he
did
and
kind
of
at
the
very
last
minute
before
I
TF
took
the
old
document
sucked
the
bits
out
of
it
that
I
think
are
relevant
to
what
we
actually
possibly
might
have
consensus
to
do
and
produced
a
new
draft
that
is,
it
was
published
before
the
deadline.
Has
anybody
seen
that
document?
Oh.
I
Boy
all
right,
all
right.
Well,
so
so
I'll
just
tell
you
about
it.
So
this
is
a
first
draft,
as
I
said:
I
suck
the
bits
out
of
the
old
on
that
naming
architecture
document.
So
there
are
still
a
few
little
crumbs
left
over
from
that
document
that
need
to
be
cleaned
up,
but
it's
pretty
solid
in
terms
of
the
general
structure.
I
think
all
the
stateful
stuff
and
all
the
security
is
gone.
There's
no
external
visibility
of
name.
So
you
can't
publish
on
that
zone
anymore
at
all.
I
The
hope
and
the
intention
in
the
way
that
the
document
is
written,
is
that
you
could
pile
a
second
document
on
top
of
that,
that
adds
that
functionality
back
and
I
certainly
intend
to
write
that
document,
whether
it
will
get
working
group
consensus
or
not,
I,
don't
know,
let's
see,
and
you
know,
unsurprisingly,
it
relies
on
DNS
SD
discovery
proxy,
which
is
the
new
name
for
the
DNS
SD
hybrid
proxy
next
slide.
So
there
there
are
a
few
differences.
What
happened
to
us?
I
Oh
I,
see
yeah
the
that
was
a
late
night
slide
issue.
So
there's
a
few
different
differences
from.
What's
specified
in
the
simple
architecture
versus
what's
in
the
the
discovery
proxy
document,
the
discovery
proxy
presents
the
discovery.
Proxy
is
a
single
functional
block.
I
split
into
two
functional
blocks,
the
so
the
two
functional
blocks
of
the
Korean
proxy
in
the
relaying
proxy,
and
the
other
thing
is
that
the
discovery
proxy
relies
on
the
manager
of
the
network
providing
meaningful
names
for
the
links
and
obviously
that's
not
going
to
happen
on
a
home
net.
I
So
we
just
have
to
come
up
with
names
and
they
don't
mean
anything,
and
there
are
some
issues
with
that
next
slide.
So
the
querying
proxy
answers
DNS
protocol
request
from
hosts
and
only
from
hosts
whenever
it
gets
a
request
it
generates
proxies,
which
it
sends
to
all
of
the
relaying
proxies
that
it
knows
about,
and
then
it
just
sits
there
and
waits
for
answers
to
come
in
and
combines
the
responses.
I
It
does
the
name
rewriting
that's
specified
in
in
the
project
in
the
discovery
proxy
document.
Let's
see
it
only
does
DNS
protocol,
it
doesn't
do
mdns,
it
does
query
aggregation
as
specified
in
the
in
the
discovery
proxy
document
for
hosts
that
don't
support.
Dns
push
if
hosts
do,
support
DNS
push
it
does
the
DNS
push
support
and
there
can
be
one
or
more
querying
proxies
per
home.
I
That
and
every
home
netrunner
has
to
support
the
querying
proxy
function,
just
because
you
know
otherwise
you
might
buy
to
them
that
routers,
neither
which
supports
it
and
not
be
able
to
do
service
discovery
next
slide.
So
the
relaying
proxy
gets
DNS
protocol
queries
from
querying
proxies.
It
sends
mdns
protocol
requests
to
the
link
that
is
each
individual
occurring
or
relink.
I
Roxy
sends
mdns
protocol
requests
to
the
link
that
it
is
serving
and
when
it
gets
responses
back,
it
just
realized
them
back
to
the
querying
proxies,
there's
no
state
being
held
in
the
in
the
relaying
proxy.
Probably
although
there
there
could
be
some
debate
about
that,
because,
if
you're,
if
you're,
if
you're
putting
on
of
an
existing
mdns
implementation,
that
might
actually
already
do
some
caching.
I
So
let's
see
it
doesn't
do
any
name
rewriting.
It
assumes
essentially
the
DNS
push
support
model,
although
I'm
not
convinced
that
we
actually
need
to
do
dns
push
as
opposed
to
just
sending
multiple
responses.
Since
we're
talking
to
the
divine
entity
that
we
already
know
supports
it,
but
it
might
be
better
to
do
it
just
because
that
way,
you
know,
if
you
look
at
the
protocol,
you
won't
be
confused
and
we
don't
have
to
actually
then
specify
the
relaying
proxy
to
query
and
proxy
protocol.
I
There's
one
late,
relaying
proxy
/
link.
If
there's
two
ho
met
routers
connected
to
a
link,
h
NCP
chooses
one
of
those
routers
to
serve
as
the
relaying
proxy
for
that
link
and
all
home
that
routers
obviously
have
to
support
really
proxy
next
slide.
Name
conflicts.
This
is
not
really
different
than
what's
in
the
hybrid
sorry.
The
discovery
proxy
document
mdns
does
name
defense
on
the
link.
So
we
don't
have
to
worry
about
names
being
named
conflicts
on
the
link.
I
So
if
there
are
conflicts,
then
a
one
way
to
deal
with
that
is
that
we
can,
in
the
case
of
conflicts,
only
reveal
the
link
sub
domain
to
the
to
the
user.
That's
one
option.
Another
option
is
that
we
can
just
always
present
the
link
sub
domain,
so
the
user
just
always
sees
that
little
ugly,
number
I,
don't
love
that
solution,
and
then
you
know,
there's
an
unanswered
question
and
it's
unanswered,
probably
because
I'm
just
ignorant
as
to
how
big
of
a
problem
this
is:
let's
go
to
the
next
slide.
I
So
these
are
the
these
are
the
sets
of
cases
that
I
think
can
cause
naming
conflicts.
I
had
a
naming
conflict
on
my
laptop,
it's
called
macbook
pro
and
as
soon
as
I
connected
the
IETF
network.
For
some
reason
there
was
another
device
on
the
network
called
macbook
pro
I.
Don't
know
why.
So
this
can
just
happen
by
accident.
I
It
can
happen
because
somebody's
trying
to
attack
a
device
like
if
you
got
a
printer
somebody
might
try
to
pose
as
the
printer
and
capture
all
of
your
documents
and
then
kind
of
man
in
the
middle
you.
So
that's
a
possible
reason
why
there
could
be
named
conflict
I've,
never
actually
seen
that
happen,
but
obviously
it's
not
a
bad
idea
to
defend
against
it,
although
we
don't
actually
have
a
defense
against
it.
I
Another
thing
which
I've
seen
in
networks
that
dude
the
discovery
proxy
wrong
is
that
if
you
have
a
device,
that's
prison
on
one
link
and
then
it
appears
on
another
link.
The
discovery
proxy
may
defend
the
name
on
the
second
link,
causing
the
device
to
renumber
its
name.
They
usually
just
increment
a
number
and
then
that
kind
of
produces
ugly
result.
Another
thing
that
can
happen
is
you've,
got
a
device's
got
to
network
interfaces,
and
if
they
present
the
same
name
on
different
links,
then
you
have
a
conflict.
I
So
one
of
the
problems,
the
reason
why
we
can't
actually
solve
this
is
that
mdns
doesn't
have
a
unique
identifier
per
device
as
far
as
I
know.
So
so
we
can't
just
look
at
the
identifier
and
say:
oh,
these
are
the
same
device.
We
don't
need
to
do
this
ambigua
shin,
which
would
be
awfully
nice.
We
can't
use
the
link
local
address
because
it
might
be
different.
I
You
know,
even
if
its
serial,
you
might
connect
with
the
Wi-Fi
at
one
point
and
then
with
your
Ethernet
at
another
point,
that
a
different
mac
address
doesn't
work
I,
don't
love
the
solutions
that
we
have
I'd
like
to
come
up
with
a
better
solution,
but
there
is
no
solution,
that's
perfect!
I
Either
we
either,
we
have
to
add
a
new
protocol
which
is
somewhat
impractical
or
we
have
to
do
some
kind
of
heuristic
to
deal
with
the
name
conflict
issue
and
whatever
that
heuristic
is
I,
have
a
feeling
is
going
to
have
some
edge
cases
that
are
going
to
be
difficult.
So
this
is
something
that
we
should
decide
on.
I'm
not
going
to
you
know.
I
I
could
go
either
way,
I
mean
I'm
a
geek,
so
I
don't
care
about
the
little
weird
numbers
that
much
but
I
have
a
feeling
that
that
it
may
cause
a
little
bit
of
pain
for
end
users,
but
I,
don't
know
so
that's
we
need
just.
We
need
to
figure
that
out
next
slide
yeah.
So
so
there
are
some
regrets
about
about
going
to
the
simple
architecture
I'm.
I
I
I'm
not
entirely
happy
with
it,
although
I
think
it's,
it's
probably,
you
know
a
good
choice
from
from
a
from
the
standpoint
of
being
able
to
support
less
capable
routers,
we
don't
have
a
security
model.
The
old
the
old
architecture
was
heading
in
the
direction
of
a
security
model.
Didn't
really
have
a
security
model
either,
but
it
was
getting
there.
We
don't
have
a
registration
protocol
which
means
that
we're
just
using
mdns
and
mdns
has
issues.
There
are
things
about
emptiness
that
don't
work.
I
It
would
be
awfully
nice
to
have
a
registration
protocol
and
if
we
don't
do
the
registration
protocol
in
this
document,
I
don't
think
that
we
realistically
are
going
to
have
a
registration
protocol.
So
that's
a
regret.
There
is
no
clean
way
to
enumerate
all
services,
that's
just
not
how
MBS
works.
I
If
you,
if
you're
clever,
you
can
sit
and
sniff
on
the
wire
and
watch
services
services
announced
when
they
come
on
the
wire,
but
that
really
depends
on
all
the
all
of
the
stars
being
right
and
we
know
what
happens
when
all
the
stars
of
rights.
It's
probably
not
a
good
idea
anyway,
and
of
course
we
don't
have
the
states,
so
there's
no
place
to
connect
that
list.
Even
if
we
had
one-
and
you
know
we're
not
fixing
mdns
I,
guess
that
really
goes
back
to
the
registration
protocol
thing
so
next
slide.
I
So
basically,
this
is
the
this
is
the
last
slide
breathe
a
sigh
of
relief,
so
we
need
to
decide
whether
we
want
to
do
this
or
what
I
was
proposing
before,
if
you're
not
familiar
with
this
or
what
I
was
proposing
before
you
probably
have
a
strong
opinion
about
this.
I
F
I
I
actually
have
a
document
that
I
that
I
did
in
DNS
SD
the
talks
about
the
registration
protocol
issue,
the
the
the
order
that
we
could
put
in
the
water
is
whether
we
specify
it
in
our
architecture.
We
specified
our
architecture
than
we
need
to
probably
get
dns
SD
to
actually
solve
the
problem.
I'm
sure
they'd
love
that
and
you
know,
there's
a
disambiguation
problem.
You
need
to
figure
that
out
and
we
need
to
figure
out
how
important
ugly
versus
clean
presentation
is
to
us.
So
those
are
those
are
the
decisions
before
the
working
group.
I
L
Hi
Ted
item:
for
the
note
takers,
my
name
is
Stuart
cheshire.
I.
Think
the
suggestion
that
the
DM
SSD
working
group
take
some
of
this
on
is
not
a
bad
one.
I
have
recently
been
getting
more
involved,
as
an
industry
organization
called
the
thread
group
which
I
think
was
originally
spearheaded
by
nest.
L
L
There
is
a
little-known
feature
and
if
you
look
in
RFC
67-63
search
for
underscore
services
and
an
serve
a
query
for
underscore
services
on
other
school
DNS
SD
enumerates
all
the
service
types.
Now
there
may
be
devices
that
don't
support
that
correctly
and
that's
an
issue
in
all
protocols.
If
it's
not
implemented
correctly,
it's
not
there
to
work,
but
at
least
in
principle.
There
is
a
way
to
do
this:
exhaustive
bootstrap,
where
you
get
the
list
of
services
and
then
fit
your
service
type.
M
Just
as
you
rightly
pointed
out
in
the
previous
session
that
one
should
not
go
off
and
design
security
solutions
without
a
threat
model,
I
feel
that
it
would
be
useful
to
have
some
sort
of
a
user
model
articulated.
You
know
before
we,
you
know
really
hone
in
on
specific
solutions
for
this
work.
So,
for
example,
it
seems
to
me
that
you're
pointing
at
a
residential
user
on
what
sorts
of
things
could
we
assume
about
that
user?
Does
the
user
know
a
priority?
What
service
they
are
searching
for
on
what
you
know?
N
N
I'm,
sorry,
probably
missing
something
but
I
have
to
I
have
to
say
that
I
think
what
Kerry
just
said
is
is
right
that
it's
I'm
starting
to
feel
like
the
target
is
not
very
clear
here
and
we
have
a
whole
bunch
of
stuff,
including
a
long
and
boring
discussion
that
we've
had
about
names
that
that
all
happened,
because
we
wanted.
You
know
the
big
set
of
cool
stuff
that
was
in
the
other
architecture
document
that
made
for
things
to
be
complicated
and
now
we've
whittled
that
down
in
this
document.
N
It
looks
to
me
so
that
most
of
those
controversial
decisions
that
we
were
making
didn't
need
to
happen
anyway,
and
we
could
we
could
just
get
around
all
of
them
right.
So
I
I
now
feel
like
we
need
to
step
up
one
level
and
sort
of
make
a
little
bit
clearer,
exactly
which
target
were
trying
to
hit
right.
We
had
some.
We
had
some
use
cases
early
on.
It
feels
to
me
just
looking
at
it
and
again.
I
did
this
very
quickly
like
while
you
were
talking.
N
So
I'm
sorry
if
I'm
missing
something,
but
it
feels
to
me
like
what
we're
actually
doing
is
throwing
away
some
of
use
cases
that
we
had
before
in
order
to
make
this
simpler.
That's,
okay!
That's
that's
a
perfectly
reasonable
thing
to
do,
but
I
think
we
have
to
do
it
consciously
rather
than
yeah,
but
rather
than
to
try
to
simplify
yeah.
That's.
I
Exactly
right
that
you
know,
I
feel
the
same.
Frustration
like
like
you
know
whether
whether
the
the
kitchen
sink
approach
that
I
chose
last
time
was
the
right
approach
or
not.
This
is
definitely
the
most
pared
down
approach
that
I'm
even
willing
to
contemplate
and
it's
pretty
pared
down
and
I'm,
not
in
love
with
it,
but
it
does
have
the
virtue
of
being
pretty
easy
to
come
to
consensus
on,
and
we
already
basically
know
how
to
do
it.
I
So
I'd
rather
do
something
more
ambitious,
but
the
fact
of
the
matter
is
here:
we
are
how
many
years
since
the
working
group
was
chartered-
and
we
don't
have
an
architecture
for
naming
yet
so
maybe
that's
an
indication
that
we
need
to
set
our
sights
a
little
lower
elf.
M
Roth
drums
in
the
interest
of
giving
you
something
to
do
that's
more
ambitious.
I
wonder
if
there
are
other
local
naming
mechanisms,
local
name
and
protocols
that
you
might
want
to
at
least
leave
hooks
for
or
consider
for
future
inclusion
of
trying
to
to
about
the
design
principle.
Don't
cut
yourself
off
from
other
things
that
you
might
want
to
include
venture
hit.
Have
you
already
considered
that
and
and.
E
I
Nice
return
of
service-
oh
yeah,
I've,
been
here
a
while
so
yeah
I
think
that's
a
great
suggestion
and
and
I
I
don't
mean
to
say
and
therefore
you
go.
You
go
deal
with.
It
also
look
at
it,
but
I
think
you
may
know
more
than
I
do
so.
Oh
no.
B
Okay,
so
since
I'm
getting
is
that
weird
too
early
to
be
looking
adopting
this
and
as
yet,
we
haven't
adopted
the
earlier
advanced
home,
nickname
in
architecture
document
either,
but
unfortunately
means
that
we're
not
in
a
position
to
do
anything
until
I
think
we
see
at
least
one
more
Rev
of
this
stop.
It
takes
a
look
at
the
feedback
they
getting
today,
so
I'm
guessing,
there's
Patek
to
push
something
out
fairly
soon
and
please,
if
you
have
to
be
back
to
Ted
again,
it's
nine
o'clock,
Monday
yeah.
B
F
B
B
E
O
B
P
The
request
is
fair
and
appropriate,
and
it's
what
we
do
in
the
IETF,
because
we
like
cross
area
cross
working
group
review,
especially
given
that
the
place
where
I'm
looking
at
here,
so
what
I'm
going
to
describe
at
this
point
in
time,
and
I'm
only
at
the
end
of
this
going
to
ask
the
clarifying
questions
is
that
this
is
my
current
assessment
of
where
we
sit
at
the
moment.
There
are
other
people
who
are
engaged
in
discussions.
P
P
Second,
one:
the
expected
future
operation
of
home
that
resolution
for
dns,
validating
stub
resolvers
requires
a
break
in
the
DNS
SEC
chain
of
trust,
I
mean
so
this
you,
you
already
know.
You've
heard
it
before
so
to
achieve
that.
Second,
one,
the
document
being
that
the
draft
additionally
asks
Dianna
to
insert
an
unsecure
delegation
into
the
root
zone,
the
ask
for
that
is
not
covered
in
IETF
policy
terms,
and
it
actually
tries
to
put
an
entry
into
someone
else's
registry.
P
P
Obviously,
there's
the
status
quo,
which
is
ck
dot
home,
that
special
use
domain,
with
the
request
for
an
insecure
delegation
to
the
route,
and
so
that's
your
status
quo
as
it
stands.
Right
now.
Second
option
would
be
to
seek
a
dominant
special
use
domain
without
the
delegation
request
and
ask
the
IETF
iesg
IAB
to
convince
the
discussion
with
the
I
kin
community
to
achieve
an
insecure
delegation
there's
another
one
which
is
to
seek
a
home
DARPA
insecure
delegation
as
per
RFC
3172.
P
Or
the
last
one
go
for
a
dot
home
that
special
used
to
main
with
asking
the
isg
IAB
arm
IETF
to
go
off
and
talk
to
the
I
kin
community,
but
if
that
doesn't
work
full
back
to
doing
something
in
upper.
So
these
are
some
of
the
areas
that
we're
thinking
about,
and
I
thought
it
would
work
it's
worthwhile
to
highlight
that
to
the
working
group
to
say
this
is
not
an
easy
conversation
to
have.
There
are
lots
of
aspects
to
this.
Q
I
Was
some
debate
about
exactly
what
to
do
yeah
yeah?
That
would
be
if
that
would
be
10
shape.
You
would
point
to
something
that
would
return.
I,
don't
know
what
you're
talking
about
answer:
hey
yeah,
so
I
guess
you
know.
From
my
perspective,
you
know
ray
and
I
were
talking
about
this
earlier
and.
I
I'm
wondering
like
does
it?
Does
it
seem
like
a
bad
idea
to
you
guys
just
to
because
we
have
a
number
of
other
related
problems
like
this
I
mean
dot.
Onion
doesn't
need
a
delegation.
We
actually
wanted
to
secure
denial
of
existence
for
not
onion,
but,
for
example,
localhost
currently
has
a
secure
denial
of
existence,
which
is
bad.
So
there
are.
There
are
other
cases
where
we
have
stuff
that
really
ought
to
be
in
the
root
zone.
'isn't.
I
A
I
No
I
mean
I,
don't
really
want
to
go
down
that
rat
hole,
basically,
what
I'm,
just
what
I'm?
What
I'm
asking
is
like
is
the
right
process
to
just
do
what
we
are
talking
about.
Doing
special
use
domain
names
registry
and
then
separate,
have
a
separate
process
in
DNS
off
that
just
deals
with
all
of
the
cleanup
for
the
cases
where
we
really
need
a
delegation
in
the
root
zone
and
don't
have
one,
one
of
which
would
be
home
that
so.
A
The
clarifying
point
is:
is:
are
you
asking
the
group
to
be?
You
know
one
work
item
amongst
a
general
thing:
that's
going
on
Indiana
dns
off
anyway,
or
remove
ourselves
from
that
general
thing
and
I.
Think
that's
the
important
you
know
higher
level
question
in
a
administrative
sense
to
Terry
is
that
am
I
making
sense,
I!
Think.
R
Hoffman
so
a
couple
of
things:
please
don't
do
the
status
quo
because
I'm,
sorry,
please
don't
you
the
status
quo
going
into
IETF
last
call,
because
the
discussion
and
I
HAF
last
call-
will
be
useless.
It'll
be
useless
to
you,
it'll
be
useless
to
the
iesg.
It
will
be
on
many
topics
that
turn
out
not
to
be
important.
So
please
don't
do
that
I!
You
know
pick
another
one.
R
If
you
feel
like
doing
status
quo,
please
rewrite
the
I
in
a
consideration
section
that
is
I
pointed
out
some
issues
after
working
group
last
call
here.
The
authors
worked
on
them
and
that
scares
me
that
is,
it
didn't
come
back
to
the
working
group.
It
just
was
like
the
others.
Oh
yeah,
you're
right
and
just
did
that
that
to
me
seems
like
not
a
good
way
to
have.
R
This
working
group
understand
what
is
being
asked
of
the
IHF,
and
I
hf
last
call
we've
seen
some
ITF
last
calls
recently
that
are
hundreds
of
messages,
long
very
hard
to
follow
the
threads.
I
was
on
one
of
those
I'm,
the
Shepherd
on
and
I
assure
you
trying
to
be
a
shepherd
on
one
of
those
to
make
sure
that
people's
responses
are
dealt
with
is
impossible
because
threads
turned
into
Travis
I.
R
So
please
be
clear
and
crisp,
and
then
my
last
request
is,
if
you're
going
to
do
what
Ted
just
suggested
of
let's
open
this
up.
Please
don't
assume
its
dns
off.
Dns
has
just
had
a
couple
of
failures
on
coming
to
consensus.
On
things
like
this
I
mean
you
can
put
Indiana
stop.
If
you
want
it
to
be
a
failure,
which
is
I,
mean
I,
can't
guarantee
a.
S
G
Yadda
yadda,
so
I
I
wanted
to
make
it
clear
the
working
of
the
you
guys
really
are
in
trust.
You
have
a
a
project
ahead
of
you
and
you
have
some
potential
requirements
to
put
it
into
the
whatever
you're
doing,
but
you
need
to
be
really
really
clear
about
what
the
implications
of
some
of
those
requirements
are.
So
if
you
decide
to
go
a
particular
path-
and
that
means
a
very
lengthy
process
somewhere
else
outside
the
ITF
and
uncertain
results.
If
that's
okay,
then
you
know
by
all
means,
but
but
don't
test.
G
T
Suzanne
wall
fence,
Denisov
culture
well,
I
would
dispute
a
few
of
Paul
Hoffman's
words
as
far
as
how
Deanna's
often
stood
on
some
of
these
questions,
I
think
it
is
important
to
note
that
one
of
the
things
that's
come
out
of
the
inquiry
on
dns
op
is
that
many
of
the
issues
arising
are
out
of
scope
and
out
of
confidence
for
deanna's
off.
These
are
not
strictly
dns
issues.
They
just
express
themselves
in
that
way.
So
the
clarifying
question
for
the
working
group,
given
the
process
and
operational
discussions
that
seem
to
arise
from
this.
A
Have
a
question
for
this
because
last
I
ETF
I
mean
it
sounds
like
we're
repeating
this
same
set
of
options
and
the
working
group
you
know
knew
that
it
was
walking
into
something
that
might
be
difficult
in
order
to
get
the
thing
that
it
really
wanted,
and
it
was
given
the
option.
Oh,
we
could
take
this
other
thing.
Did
that
aqua
version
not
really
what
we
want.
It
could
be
more
expedient.
That
was
the
heart
of
the
discussion.
Last
time
and
I
just
went
back
and
reread
the
notes
it
was.
A
A
N
This
is
andrew
sullivan,
so
I
got
up
to
I'm
speaking
with
no
hat
just
even
though
my
hat
is
like
fading
away.
I
just
want
to
be
clear
that
I
think
Stephen,
no
hat
I
want
to
quibble
actually
with
both
yari
and
the
statement
you
just
made.
The
working
group
is
not
in
charge.
This
is
an
ietf
document.
N
A
You
for
that
clarification,
don't
want
to
suggest
for
a
second
that
the
IETF
is
not
ultimately
in
charge
here,
I
misspoke
a
little
bit.
The
the
consensus
of
the
working
group
was
clear
and
I.
Think
now
we're
saying
the
same
thing.
B
Terry
this
is
hopefully
just
a
clarifying
question.
Is
it
in
an
email
to
a
small
group?
A
few
days
ago,
you
said
that
you
believe
that
if
we
leave
the
request
me
insecure
delegation
in,
but
we
will
not
be
able
to
publish
the
RFC
until
that
is
resolved,
is
there
an
opportunity
to
perhaps
to
publish
where
we
are
not
blocking
on
that
decision?.
P
It's
possible
I,
won't
say
a
hundred
percent,
but
it's
possible.
Remove
the
insecure
delegation
you're,
not
then
trying
to
push
something
into
another
entities:
registry
and
you're-
really
just
talking
about
a
special-use
domain
and
to
date,
I've
not
seen
anything
substantive
in
terms
of
the
6761
review
to
say
that
that
can't
happen.
That.
B
P
B
Do
the
other
one
of
considerations
for
us
is
that
the
insecure
delegation
is
only
required
in
the
what's
currently
exceedingly
rare
case
of
a
validation,
stub
resolver.
These
things
are
more
like
unicorns,
just
open,
ponies,
yeah
I
think
it's
very
important
that
we
do
get
a
domain
reserved
as
soon
as
possible,
whether
that
be
got
home.
B
That's
all
got
home,
not
offer
I
think
it
would
be
very
unfortunate
if
we
yep
if
this
whole
process
was
delayed
because
of
that
need
from
this
cure
delegation,
but
I
do
also
feel
it's
important
as
a
working
group
that
we
somehow
at
least
flag.
This
is
our
ability
of
this,
not
least
because
we're
not
the
only
people.
You
need
this
issue
with
the
mou
resolved.
M
Ralph
drums
actually
have
two
responses.
The
first
mark
us
what's
changed
and
just
to
be
the
clarification
to
that
about.
What's
changed
is
andrew,
pointed
out.
The
working
census
has
not
changed,
but
there
has
been
more
official
external
review
than
there
was
as
of
the
last
working
with
meeting
so
we've
had
a
dns
off
working
group
review
and
we've
had
a
it's
an
indie
area,
Directorate
review
that
have
provided
more
information
that
the
working
group
may
want
to
consider
when
it
comes
to
consensus
about
what
to
do
so.
So
that
has
changed.
M
M
There
is
a
concern
about
separating
the
two
requests,
one
for
the
especially
use
the
main
name
registry
and
the
root
zone
entry
in
that,
if,
if,
if
those
two
are
separated
and
a
bunch
of
code
starts
getting
deployed
with
just
home
yet
and
then
we
find
out
as
after
we
developed
the
process
that
we
can't
actually
get
the
root
zone
entry
for
home
net,
then
we're
stuck.
We
can't
go
back
really
and
take
back
all
of
those
deployed
devices
to
get
the
home
DARPA.
M
B
I
Ted
lemon,
so
I,
don't
know
if
you're
going
to
believe
this
is
a
clarifying
question
or
not,
but
and
if
it's
not
that's
fine,
but
is
it?
Is
it
generally
understood
that,
regardless
of
what
the
outcome
of
this
discussion
is,
we
need
to
have
the
discussion
with
I
can
about
precisely
what
the
MOU
says
or
do
people
really
just
not
want
to
open
that
can
of
worms?
I
mean
is
that
what's
going
on,
I
can't.
P
N
My
name
is
Andrew
Sullivan
and
I
am
NOT.
The
chair
of
the
IEP,
but
I'm
still
on
the
IAB
for
four
days
left
and
I
am
quite
sure
that
there
is
no
appetite
to
reopen
an
agreement
where
another
party
might
have
a
very
different
opinion
about
what
we
want
to
do.
What
we
ought
to
be
able
to
do
there,
then
then
we
might
think
when
you
have
an
agreement,
and
you
want
to
reopen
that
agreement
and
you
want
to
start
negotiating
anything
goes
on
the
table.
N
So
if
you,
if
you
want
to
reopen
an
agreement
with
somebody,
the
possibility
is
that
you're
going
to
end
up
negotiating
for
something
and
you're
going
to
have
to
give
something
up
and
I'm
not
sure
what
it
is
you
want
to
give
up
in
order
to
get
this
benefit.
If
you
want
to
get
it,
but
you
know
you're
going
to
have
to
reopen
some
things
wide
in
order
to
do
that.
N
So
so,
if
that's
the
discussion
that
people
want
to
have
first
of
all,
I'm
quite
sure
that
this
is
not
the
working
group
of
which
it
ought
to
be
done
and
and
secondly,
I'm
not
really
sure
that
we
want
the
result
that
we're
asking
for
their
because
it
could
be
quite
interest.
I.
I
L
I
Stuart
cheshire
listening
to
this
discussion
to
something
that
puzzles
me
and
I'm
wondering
if
there's
some
mistake
in
thinking
going
on
I'm
hearing
that
in
order
to
make
this
work,
we
need
the
insecure
delegation.
But
the
idea
behind
the
special
use
names
registry
was
that
there
are
certain
parts
of
the
namespace
that
have
different
properties
and
the
idea
was
to
actually
codify
that
and
have
a
place.
B
L
Guess
when
you
put
it
that
way?
Yes,
it
is
because,
if
you
don't
require
any
host
changes,
you
don't
the
name
is
not
special.
If
it's
not
special,
it
needs
to
go
into
the
does
not
need
to
go
in
the
registry.
That's
kind
of
a
circular
argument,
but
if
you
want
to
name
that
special
properties
it
that
implies,
it
is
special
in
some
way.
If
it's
not
special,
it
shouldn't
be
special
useless.
L
U
U
So
that
is
what
that
is
the
only
thing
that
makes
it
special
it
that
yep,
there
is
other
things
that
fall
out
of
that
there's
nothing
that
in
the
special
uses
registry,
the
system
that
that
an
unmodified
machine
shouldn't
go
out
to
work
that
you
have
to
actually
modify
a
resolver
to
do
things
with
it.
Okay,
Oh
make.
U
U
P
P
A
P
A
And
I,
the
one
thing
that
I
saw
fall
out
of
this
is
and
I
think
what
Stewart's
comments
sort
of
backed
it
up
is
it
raised
suggested,
hang
on.
Maybe
we
can
separate
this
remove
the
secure
delegation
piece
and
still
get
a
special
use.
That's
that's
something
that
we
teetered
on
last
time
and
the
decision
was
well
we'll
give
it
a
try
and
if
and
we'll
see,
if
that's
going
to
be
the
big
deal
that
it
is,
we
should
give
the
opportunity
I
think
for
the
working
group
to
allow
absolutely
unless
or
thing.
A
Want
to
open
up
everything
to
Andrews
point
earlier
right,
but
that
was
that
was
literally
added
at
the
last
minute.
Last
time.
Oh
wait:
you're
gonna
need
an
insecure
delegation.
Is
that
a
problem?
Maybe
we're
not
sure
yet?
Okay,
we'll
see
all
right.
So
if
we
can
I
mean
that
was
added
at
the
last
minute
mile
time
in.
B
A
The
hang
up,
let's
get
it
back
out
and
I
think
that
I
mean
we're
still
within
the
cut
within
the
context
of
the
working
group
consensus,
which
was
the
the
TLD
name
rather
than
a
dot
r
/
Associated
one
it.
If
that
means
we
end
up
with
a
host
requirement.
We
can
weigh
that,
but
you
know,
let's,
let's
not
throw
the
baby
out
with
the
bathwater.
Are
you
okay,.